Home Server, Teil 4 – Konfiguration: CUPS, Samba und NFS

Projekt 'Home-Server'

Der Server läuft, fühlt sich frei und wohl, besonders viel sinnvolles tut er bislang aber noch nicht. Dies ändert sich nun. Über CUPS wird ein Drucker eingebunden, der Samba-Server wird eingerichtet um Datei- und Druckdienste für Windows Clients anzubieten. Weiterhin werden UNIX Clients mittels NFS bedient.

CUPS – Einbindung des Druckers

CUPS

CUPS steht für Common UNIX Printing System und ermöglichst die Einrichtung und Administration von Druckern über ein bequemes Webinterface. Dazu werden im Fedora Core die Services cups und cups-config-daemon benötigt. Nach der Installation erlaubt CUPS nur eine lokale Administration, d.h. der Browser muss lokal auf dem Server laufen. Dies wird als erstes geändert. Der Pfad zur Konfigurationsdatei lautet: /etc/cups/cupsd.conf.

/etc/cups/cupsd.conf

# cupds.conf @ server

ServerAdmin        mephisto@home

LogFilePerm        0600
MaxLogSize         67108864
LogLevel           info

Printcap           /etc/printcap

Listen             127.0.0.1:631
Listen             192.168.100.253:631

HostNameLookups    On
MaxClients         64
MaxClientsPerHost  16

Browsing           Off


<Location />
  Order Deny,Allow
  Deny From All
  Allow From 127.0.0.1
  Allow From 192.168.100.1
</Location>

<Location /admin>
  AuthType Basic
  AuthClass System

  Order Deny,Allow
  Deny From All
  Allow From 127.0.0.1
  Allow From 192.168.100.1
</Location>

# End of file

Die vorinstallierte Konfigurationsdatei enthält sehr viel hilfreiche Kommentare, ich empfehle daher vor der Ö?nderung eine Sicherheitskopie (z.B. als ‘cupsd.conf-dist’). Mit Serveradmin kann eine E-Mail Adresse angegeben werden, an die CUPS Nachrichten sendet. Vorerst ist die Einrichtung eines lokalen E-Mail Services zwar nicht geplant, da der lokale DNS Domain aber ‘home’ sein wird, dürfte dann die hier angegebene E-Mail Adresse passen.

Der Parameter LogFileParm definiert die Rechte der Logdateien, die CUPS erzeugt. Mit 0600 sind sie nur für den root-User einsehbar. Mit MaxLogSize läßt sich die maximale Länge einer Logdatei begrenzen, anschließend beginnt die Rotation. Die etwas krumme Zahl gibt eine Größe von genau 64 MB an. Die Angabe LogLevel definiert, was alles protokolliert wird. Mit ‘info’ wird bis auf Debuginformationen alles protokolliert. Auf einem Home-Server wird aber in der Regel nicht soviel gedruckt, dass dies je zu einem Problem werden sollte. Durch Angabe einer Printcap-Datei über den Parameter Printcap wird eine Druckerdefinitionsdatei im ‘printcap’ Format erzeugt. Einige UNIX Tools möchten auf diese zugreifen.

Die beiden Listen Angaben sorgen dafür, dass der CUPS Dienst zu einem lokal für den Server zur Verfügung steht (127.0.0.1), zum anderen auch im Private LAN (192.168.100.253). Der Port 631 ist der Standard CUPS Port. Mit HostNameLookups wird die DNS Prüfung der Clients aktiviert (Reverse-Lookups), die Parameter MaxClients und MaxClientsPerHost begrenzen die Zahl der gleichzeitigen Zugriffe auf den CUPS Dienst. Mit maximal 64 Verbindungen und maximal 16 Verbindungen pro Client sollte in einem privaten Netzwerk keine Limitierung auftreten. Mit dem Parameter Browsing wird die Suche nach anderen CUPS Servern im Netzwerk abgeschaltet.

Über die Location Definitionen werden die Zugriffsberechtigungen angegeben. Ein direkter Druck der Clients über CUPS ist nicht geplant, die Clients sollen alle über den Samba-Server drucken. Aus diesem Grund ist der Zugriff nur für den Server selbst sowie den Arbeitsplatz-PC nötig, über den die Administration erfolgt. Dies wird über die beiden Allow From Zeilen eingestellt (die Loopback Adresse 127.0.0.1 erlaubt dem Server den Zugriff). Im Fall der Webaministration soll sich CUPS nicht mit dem Zugriff von der richtigen IP Adresse begnügen, zusätzlich ist hier auch noch eine Benutzeranmeldung gewünscht. Dies erledigen die AuthType und AuthClass Einstellungen. Die Anmeldung erfolgt dann als root-User.

Die geänderte Konfigurationsdatei kann im Betrieb aktiviert werden. Dies geschieht am einfachsten mit dem folgenden Befehl:

[root@server]# /etc/init.d/cups reload
Reloading cups:                [  OK  ]
[root@server]#

Über http://192.168.100.253:631/admin kann nun die Webadministration aufgerufen werden, über den Menüpunkt ‘Drucker verwalten’ kann man einen am Server angeschlossenen Drucker einbinden:

CUPS Webadministration

CUPS Druckereinrichtung

Samba – Dienste für Windows Clients

Samba

Zu den Hauptaufgaben des Home Servers zählt die Bereitstellung von auf dem Server gespeicherten Dateien sowie des gemeinsam genutzten Druckers für die beiden Windows-PCs. Diese Aufgabe wird von dem Samba-Server übernommen. Während der Drucker unkritisch ist, sollen private Daten natürlich nur meiner Frau und mir zugänglich sein. Der Zugriff auf die Dateien muss daher abhängig von der angemeldeten Person sowie sicherheitshalber auch von dem Client abhängig sein.

Zunächst sind daher auf dem Server die Accounts für die User einzutragen, die später gezielt Zugriff bekommen sollen. Dies kann über die direkte Ö?nderunge der Dateien /etc/passwd, /etc/shadow und /etc/group erfolgen, über die Scripts adduser und groupadd oder über die grafischen Tools. Die folgenden Befehle erzeugen die drei User-Accounts ‘tom’, ‘jerry’ und ‘media’ sowie eine Gruppe ‘privat’ für die beiden ersten Accounts.

[root@server]# groupadd -g 700 privat
[root@server]# adduser -g 700 -c Tom tom
[root@server]# adduser -g 700 -c Jerry jerry
[root@server]# adduser -s /bin/nologin -c "Multimedia" media
[root@server]# passwd tom
Changing password for user tom.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
[root@server]# passwd jerry
Changing password for user jerry.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
[root@server]# passwd media
Changing password for user media.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

Anmerkung: Bei Fedora Core 3 verwendet der ‘adduser’ Befehl als Default die Gruppen-ID 100, die Standard-Usergruppe ist aber 500 (von den grafischen Tools verwendet). Es empfiehlt sich daher, den Default im Script /etc/default/useradd von 100 auf 500 zu ändern. Wer sich Kopien der Konfigurationsdateien mit Hardlinks anlegt, darf für die drei Dateien /etc/passwd, /etc/shadow und /etc/group diese nun erneuern – die Scripts legen die Dateien neu an.

[root@server]# smbpasswd -a tom
New SMB password:
Retype new SMB password:
Added user tom.
[root@server]# smbpasswd -a jerry
New SMB password:
Retype new SMB password:
Added user jerry.
[root@server]# smbpasswd -a media
New SMB password:
Retype new SMB password:
Added user media.
[root@server]#

Samba besitzt eine eigene Datei mit Usern und Kennwörtern, greift aber auf die UNIX Useraccounts zurück. Um einen Samba User anlegen zu können, muss ein entsprechender UNIX Account existieren. Da letzteres jetzt der Fall ist, können nun die Samba Accounts angelegt werden. Die Useraccounts und Kennwörter sollten mit den Windows Benutzernamen und Kennwörtern übereinstimmen, damit nach der Windows Anmeldung ein direkter Zugriff auf den Server ohne weitere Kennwortabfragen möglich ist.

Im Fall der Samba Konfigurationsdatei spare ich mir das einzelne durchgehen der Einstellungen und beschränke mich auf die wichtigen Sachen. Wer zu einer Einstellung eine Frage hat, sollte diese in der Manpage beantwortet finden:

[root@server]# man smb.conf

Generell lauscht der Samba Server auf beiden LAN Interfaces des Servers und läßt aus dem Private und Guest LAN mit Ausnahme des Routers jeden Client zu. Die Druckerdefinitionen holt er sich aus der von CUPS erzeugten Printcap-Datei, weiterhin werden die Einstellungen der Groß-/Kleinschreibung der Dateinamen für Windows angepaßt. Alle in CUPS definierten Drucker stehen allen Clients im Private und Guest LAN zur Verfügung. Es gibt insgesamt vier Verzeichnisfreigaben:

/etc/samba/smb.conf

# smb.conf @ server

[global]

   server string        = Servers (connected as %U@%M)
   netbios name         = server
   workgroup            = Home
   security             = share
   time server          = yes
   bind interfaces only = yes
   interfaces           = eth0, eth1
   hosts allow          = 192.168.100. EXCEPT 192.168.100.254, 192.168.101.

   # Only if two networks should be served!
   wins support         = yes
   dns proxy            = yes

   socket options       = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
   log file             = /var/log/samba/%m.log
   log level            = 1
   deadtime             = 1440
   null passwords       = no

   dos charset          = CP850
   unix charset         = ISO8859-1
   display charset      = LOCALE

   unix extensions      = yes
   encrypt passwords    = yes
   case sensitive       = no
   preserve case        = yes
   browse list          = yes

   locking              = yes
   blocking locks       = yes
   posix locking        = yes
   strict locking       = yes

   printcap name        = /etc/printcap
   printing             = cups
   load printers        = yes

[privat]
   path                 = /files/privat
   comment              = Private Daten
   guest ok             = no
   writeable            = yes
   browseable           = no
   create mask          = 0664
   directory mask       = 0775
   hosts allow          = 192.168.100.1, 192.168.100.2, 192.168.100.3


   valid users          = tom, jerry

[share]
   path                 = /files/share
   comment              = File Storage
   guest ok             = no
   writeable            = yes
   browseable           = yes
   valid users          = tom, jerry


[media]
   path                 = /files/share/mmedia
   comment              = Multimedia
   guest ok             = no
   writeable            = no
   browseable           = yes
   valid users          = tom, jerry, mmedia

[guests]
   path                 = /files/guests
   comment              = Gäste Bereich
   guest ok             = yes
   writeable            = yes
   browseable           = yes

[printers]
   comment              = All Printers
   path                 = /var/spool/samba
   browseable           = yes
   guest ok             = yes
   writable             = no
   printable            = yes
   use client driver    = yes

# End of file

  • privat: Hier liegen die privaten Dokumente. Zugriff gibt es nur für mich und meine Frau und das auch nur von unseren Arbeitsplatz-PCs sowie dem Notebook aus. Über die Einstellungen create mask und directory mask wird dafür gesorgt, dass eine Datei, die von einem von uns beiden geschrieben wird, immer auch von dem anderen bearbeitet werden kann (über Gruppenschreibrechte). Diese Freigabe ist versteckt, d.h. ein Client zeigt ihn nicht in der Auswahl an.
  • share: Dies ist die Standardfreigabe. Hier liegen meine Downloads, Manuals und all das andere Zeug was sich im Laufe der Jahre ansammelt und das man ohne den PC sowieso nicht benötigen würde. Zugriff haben alle Clients aus dem Private und Guest LAN, aber nur, wenn ich oder meine Frau darauf zugreifen.
  • media: Hier liegen diverse Multimedia Dateien, also MP3 Kopien der eigenen CDs, TV-Aufnahmen, Bilder von der Digitalkamera, usw. Sie können unabhängig vom Client von mir und meiner Frau sowie mit dem Pseudo-User Account ‘media’ gelesen werden. Dieser Account wird z.B. auch von der Xbox im Wohnzimmer genutzt, die nur noch sporadisch zum Spielen und meistens als Multimedia-Center dient. Die Freigabe erlaubt nur lesenden Zugriff, der Schreibzugriff ist nur über die share Freigabe möglich.
  • guests: Auf diesen Share kann jeder zugreifen, unabhängig vom Client und unabhängig von dem Account, unter dem der Benutzer arbeitet. Er ist primär für den Datenaustausch mit ‘Gast-PCs’ gedacht.

Die tatsächlich verwendeten Freigaben sehen etwas anders aus, ich habe diese Beispiele gewählt um zu zeigen, welche Möglichkeiten Samba bei der Definition der Freigaben bietet. Samba bietet noch weitaus mehr Varianten. Wer besondere Anforderungen hat, möge in der Dokumentation nachschlagen. Samba erlaubt Freigaben, bei denen jeder Windows Server heute noch passen muss (die man allerdings auch nur selten wirklich benötigt).

Samba Web Administration Tool

/etc/xinetd.d/swat

# Samba Web Administration Tool

service swat
{
	disable     = no
	port        = 901

	socket_type = stream

	wait        = no

	only_from   = 127.0.0.1 192.168.100.1
	user        = root
	server      = /usr/sbin/swat
	log_on_failure	+= USERID
}

Wer sich mit dem direkten Editieren der Konfigurationsdatei nicht anfreunden kann, kann das Samba Web Administration Tool, kurz SWAT, verwenden. Es erlaubt ein bequemes einrichten des Samba Servers, ohne sich mit der Syntax der Konfigurationsdatei rumschlagen zu müssen. Das SWAT wird über den xinetd Daemon gestartet, der auf Netzwerkanfragen lauscht und bei Bedarf den entsprechenden Service startet.

Nach der Installation ist SWAT beim Fedora Core 3 deaktiviert. In der entsprechenden Datei ist die disable Option auf no zu setzen, unter only_from sind die IP Adressen einzutragen, die Zugriff auf das Webinterface bekommen sollen. Nach der Ö?nderung muss der xinetd Daemon veranlasst werden, die Konfiguration neu zu laden:

[root@server]# /etc/init.d/xinetd reload
Reloading configuration:                                   [  OK  ]
[root@server]#

Das SWAT wird im Browser mit der folgenden URL aufgerufen: http://192.168.100.253:901. Die Anmeldung erfolgt mit dem root-User.

Das SWAT Webinterface

NFS – Dateidienste für UNIX Clients

Der NFS Dienst wird eigentlich nur dann benötigt, wenn man UNIX (z.B. Linux) Clients im Netzwerk hat. Im Fall von Linux kann in der Regel auch problemlos auf Samba Freigaben zugegriffen werden, in dem Fall wird ebenfalls kein NFS benötigt. Wer den “direkten UNIX Dateizugriff” wünscht, muss nur in der Datei /etc/exports die Verzeichnisse eintragen, die er freigeben möchte. Je Freigabe ist anzugeben, welche Clients wie auf das Verzeichnis zugreifen dürften.

/etc/exports

# exports @ server

/files/share        192.168.100.0/24(rw,sync)
/files/guests       *(rw,sync)

# End of file

In dem links angegebenen Beispiel kann jeder Client auf dem Private LAN lesend und schreibend auf das Verzeichnis /files/share (entspricht der Samba Freigabe ‘share’) zugreifen, jeder Client sowohl aus dem Private LAN als auch aus dem Guest LAN lesend und schreibend auf das Verzeichnis /files/guests. Anschließend ist nur noch dem NFS Daemon die geänderte Konfiguration mitzuteilen:

[root@server]# /etc/init.d/nfs reload

Wer kein NFS benötigt, sollte es abschalten, z.B. über das Text Mode Setup Utility. Die davon betroffenen Services sind im Teil 3 des Projektberichts aufgelistet.

Datensicherung per Shellscript

Für die Datensicherung wurde eine eigene Festplatte bereitgestellt, die auch nur einmal täglich für die Datensicherung aktiviert wird. Ansonsten sorgt das Startupscript aus Teil 3 dafür, dass sich die Platte nach 15 Minuten in den Standby Modus schaltet. Die Datensicherung wird von einem Shellscript vorgenommen, in dem am Anfang des Script die zu sichernden Verzeichnisse und Sicherungsparameter angegeben werden können.

Das Script unterscheide zwischen täglichen und monatlichen Backups. Prinzipiell sind beide Sicherungen vom Inhalt her identisch, allerdings kann getrennt angegeben werden, wieviele Backups bereitgehalten werden sollen (ältere Backups werden automatisch gelöscht). Zu beachten ist, dass ein monatliches Backup auch nur am ersten Tag eines Monats ausgeführt werden.

/etc/cron.daily/backup

#!/bin/sh
renice +19 -p $$ >/dev/null 2>&1
/morpheus/bin/backup

Die TAR Dateien werden mit ‘compress’ komprimiert, wer die bessere Komprimierung von BZIP2 nutzen möchte, wechselt beim ‘tar’ Befehl die Option ‘z’ durch ein ‘j’ aus. Die Sicherungen erfolgen mit relativen Pfaden, daher läßt sich ein Backup problemlos an beliebiger Stelle auspacken.

Das Backupscript kann man entweder über den crontab oder den anacron Daemon starten. Der Fedora Core nutzt von Haus aus den anacron Daemon, um “verpasste” Cronjobs nachzuholen. Es bietet sich an, das Backup hier einzubetten. Dazu wird im Verzeichnis /etc/cron.daily ein Script abgelegt, das das eigentliche Backupscript aufruft.

#!/bin/bash
#
#                                                           Mephisto, 08.02.2005
# ------------------------------------------------------------------------------
# Server backup script: this script will backup data according to a list of
# backup definitions made below. The backup disc will be mounted before starting
# the backup and umounted after the backup has finished. The backup files will
# be named
#            M.-.tgz      in case of a monthly backup
#            D.-.tgz      in case of a daily backup.
# ------------------------------------------------------------------------------
#
# Definition of backups: START:DIRECTORY:MONTHLY:DAILY
#
#   START     = Working directory where the backup will be started from
#   DIRECTORY = Directory to backup as well as target directory on backup disc
#   MONTHLY   = Number of monthly backups to hold
#   DAILY     = Number of daily   backups to hold

backupDef[0]="/files:privat:12:14"        # Private documents
backupDef[1]="/files:crypted:12:14"       # Crypted ISO images
backupDef[2]="/files/home:tom:6:14"       # Admin home directory
backupDef[3]="/:servercfg:24:30"          # Hardlinks to changed config files
backupDef[4]="/:etc:3:7"                  # Linux configuration directory

backupRoot="/backups"                     # Mount point of backup disc

backupOwner="tom"                         # Owner of backup directories/files
backupGroup="privat"                      # Group of backup directories/files

# ------------------------------------------------------------------------------
# Removes obsolete backup copies. The following parameters are expected:
#   $1    = number of copies to be held
#   $2..n = list of files (newest first)

function RemoveObsolete () {
  hold=$1
  shift
  if test "$hold" -lt "$#"; then
    shift $hold
    while test "$1" != ""; do
      echo "Backup file removed: $1"
      rm $1
      shift
    done
  fi
}

# ------------------------------------------------------------------------------
# This function performs a single backup. The working directory must already be
# set when calling this function. The following parameters are expected:
#   $1 = Name of directory to backup
#   $2 = Type of backup (either 'M' for monthly or 'D' for daily)
#   $3 = Number of backups to hold

function PerformBackup () {

  if [ "$2" == "M" ]; then
    fname=$backupRoot/$1/$2.$1-`date +"%Y-%b"`.tgz
  else
    fname=$backupRoot/$1/$2.$1-`date +"%y-%m-%d"`.tgz
  fi

  echo "Creating backup file: $fname"
  tar cfz $fname $1
  chown $backupOwner $fname
  chgrp $backupGroup $fname
  chmod 750 $fname

  RemoveObsolete $3 `ls -t $backupRoot/$1/$2.$1-*.tgz`
}

# ------------------------------------------------------------------------------
# MAIN
#
# Anything below is the main script code. First, the backup disc is mounted. The
# next step is to process the backup definitions, the last step is to unmount
# the backup disc.

mount $backupRoot

for (( n = 0; n < ${#backupDef[*]} ; n++ )); do

  # The backup definition is contained in one single string with the single
  # parts delimited by colons. First we will split up the definition into
  # single variables.

  def=${backupDef[n]}

  for (( i = 0; i < 4; i++ )); do
    token=${def%%:*}   
    def=${def#*:}
    case "$i" in
      0) startDir=$token ;;
      1) directory=$token ;;
      2) numMonthly=$token ;;
      3) numDaily=$token ;;
    esac
  done

  # The target backup directory will be created if not already existing. The
  # script changes to the start directory. The backup definition will only be 
  # processed if the script successfully changed to the start directory.

  mkdir -p $backupRoot/$directory
  chown $backupOwner $backupRoot/$directory
  chgrp $backupGroup $backupRoot/$directory
  chmod 750 $backupRoot/$directory

  cd $startDir

  if [ "`pwd`" != $startDir ]; then
    continue
  fi

  if test `date +"%d"` = "01"; then
    PerformBackup $directory "M" $numMonthly
  else
    PerformBackup $directory "D" $numDaily
  fi

done

cd /tmp
umount $backupRoot

exit

# End of file

Damit die Datensicherung den Zugriff auf den Server nicht zu sehr belastet, wird mit dem renice Befehl zunächst die Priorität der laufenden Shell erniedrigt.

Das nächste Kapitel widmet sich dem Thema DHCP und DNS. Es wird ein DHCP Server eingerichtet, der seine Einträge brav ins das DNS einträgt sowie der dazugehörige DNS Server mit eigener Zone für den LAN Bereich, der auch nicht von den DNS Servern des Providers abhängig ist.

2 Kommentare zum Artikel “Home Server, Teil 4 – Konfiguration: CUPS, Samba und NFS”

Schreibe einen Kommentar


Beim Speichern ihres Kommentars wird auch ihre IP Adresse gespeichert (nur für den Website-Betreiber einsehbar)!