Systemverwaltung und Wartung
Wichtig zu wissen, dass es zcat, zless, bzcat, bzless, xzcat, xzless gibt:
$> zless /usr/share/doc/firefox-esr/changelog.Debian.gz
Dies macht nämlich das Lesen von Dokumentation, die oft in komprimierter Form vorliegt, viel einfacher.
Eine Datei komprimieren:
$> cp /etc/services .
cp: „./services“ überschreiben? j
$> gzip services
gzip: services.gz already exists; do you wish to overwrite (y or n)? y
$> ls -l services*
-rw-r--r-- 1 root root 7554 Aug 9 09:24 services.gz
-rw-r--r-- 1 root root 7554 Mai 5 12:34 services-via-stdout-zipped.gz
$>
Entpacken kann man nun mit ‚gzip -d‘ oder ‚gunzip‘:
$> gzip -d services.gz
$> ls -l services*
-rw-r--r-- 1 root root 19605 Aug 9 09:24 services
-rw-r--r-- 1 root root 7554 Mai 5 12:34 services-via-stdout-zipped.gz
Den Vorgang wiederholen, wobei ‚gunzip‘ verwendet werden soll:
$> gzip services
$> ls -l services*
-rw-r--r-- 1 root root 7554 Aug 9 09:24 services.gz
-rw-r--r-- 1 root root 7554 Mai 5 12:34 services-via-stdout-zipped.gz
$> gunzip services.gz
$> ls -l services*
-rw-r--r-- 1 root root 19605 Aug 9 09:24 services
-rw-r--r-- 1 root root 7554 Mai 5 12:34 services-via-stdout-zipped.gz
$>
Wenn wir nicht direkt an der Datei selber operieren wollen (Originaldatei nicht komprimieren), muss mit stdout (Option ‚-c‘) gearbeitet werden:
$> gzip -c services > services-mit-Option-c-gepackt
$> ls -l services*
-rw-r--r-- 1 root root 19605 Aug 9 09:24 services
-rw-r--r-- 1 root root 7554 Aug 9 09:33 services-mit-Option-c-gepackt
-rw-r--r-- 1 root root 7554 Mai 5 12:34 services-via-stdout-zipped.gz
Beim Entpacken der Datei hilft leider die Tab-Taste nicht, weil das Suffix nicht mitgegeben wurde:
$> gunzip services-mit-Option-c-gepackt
gzip: services-mit-Option-c-gepackt: unknown suffix -- ignored
$>
Schlimmer noch: Das Kommando weigert sich direkt! Deshalb erst umbenennen:
$> mv services-mit-Option-c-gepackt services-mit-Option-c-gepackt.gz
$> gunzip -v services-mit-Option-c-gepackt.gz
services-mit-Option-c-gepackt.gz: 61.6% -- replaced with services-mit-Option-c-gepackt
$>
Was passiert, wenn gzip mehrmals hintereinander ohne ‚-d‘ angewendet wird:
$> ls -l services*
-rw-r--r-- 1 root root 19605 Aug 9 09:24 services
-rw-r--r-- 1 root root 19605 Aug 9 09:33 services-mit-Option-c-gepackt
-rw-r--r-- 1 root root 7554 Mai 5 12:34 services-via-stdout-zipped.gz
$> gzip services
$> ls -l services*
-rw-r--r-- 1 root root 7554 Aug 9 09:24 services.gz
-rw-r--r-- 1 root root 19605 Aug 9 09:33 services-mit-Option-c-gepackt
-rw-r--r-- 1 root root 7554 Mai 5 12:34 services-via-stdout-zipped.gz
$> gzip services.gz
gzip: services.gz already has .gz suffix -- unchanged
Auf direktem Wege funktioniert es nicht, vielleicht via stdout:
$> gzip -c services.gz > services.gz.gz
$> ls -l services*
-rw-r--r-- 1 root root 7554 Aug 9 09:24 services.gz
-rw-r--r-- 1 root root 7589 Aug 9 09:39 services.gz.gz
-rw-r--r-- 1 root root 19605 Aug 9 09:33 services-mit-Option-c-gepackt
-rw-r--r-- 1 root root 7554 Mai 5 12:34 services-via-stdout-zipped.gz
$>
Das ist dann tatsächlich möglich, bringt aber keinen Gewinn, im Gegenteil ist die Datei durch die neuen Kontrollinformationen größer geworden!
Mit mehreren Dateien arbeiten
Wir erzeugen drei Dateien:
2047 echo INHALT > datei1.txt
2048 echo INHALT > datei2.txt
2049 echo INHALT > datei3.txt
Wir testen, ob sich die drei Dateien OHNE direkt (ohne separates Verzeichnis) archivieren lassen:
2051 pwd
2052 tar cvf drei-textdateien.tar datei*
2053 ls -l drei-textdateien.tar
2054 file drei-textdateien.tar
Den Inhalt (table of content) lediglich auflisten:
$> tar tf drei-textdateien.tar
$> ls -l
insgesamt 24
-rw-r--r-- 1 root root 7 Aug 9 09:45 datei1.txt
-rw-r--r-- 1 root root 7 Aug 9 09:45 datei2.txt
-rw-r--r-- 1 root root 7 Aug 9 09:45 datei3.txt
-rw-r--r-- 1 root root 10240 Aug 9 09:52 drei-textdateien.tar
$> cat datei?.txt
INHALT
INHALT
INHALT
$> echo Datei1 > datei1.txt
$> echo Datei2 > datei2.txt
$> echo Datei3 > datei3.txt
$> cat datei?.txt
Datei1
Datei2
Datei3
Werden beim Entpacken des Archivs im selben Verzeichnis einfach die alten Dateien überschreiben? Wir testen es:
$> tar xvf drei-textdateien.tar
datei1.txt
datei2.txt
datei3.txt
$> cat datei?.txt
INHALT
INHALT
INHALT
$> ls -l
insgesamt 24
-rw-r--r-- 1 root root 7 Aug 9 09:45 datei1.txt
-rw-r--r-- 1 root root 7 Aug 9 09:45 datei2.txt
-rw-r--r-- 1 root root 7 Aug 9 09:45 datei3.txt
-rw-r--r-- 1 root root 10240 Aug 9 09:52 drei-textdateien.tar
$>
JA, und zwar OHNE Rückfrage!! Daher ist es besser die Dateien in ein separates Verzeichnis zu legen:
$> mkdir dateien
$> mv datei?.txt dateien/
$> tar cvf dateien.tar dateien/
dateien/
dateien/datei2.txt
dateien/datei3.txt
dateien/datei1.txt
$>
Beim Erzeugen von Archiven können die Dateien von verschiedenen Orten zusammengerufen werden. Es verhält sich das Kommando ‚tar‘ dabei so, wie es unter https://www.gnu.org/software/tar/manual/html_node/directory.html beschrieben ist:
$> cat /file*
123
123
$> ls -l /archiv/
insgesamt 12
-rw-r--r-- 1 root root 8 Aug 9 11:08 datei1.txt
-rw-r--r-- 1 root root 8 Aug 9 11:08 datei2.txt
-rw-r--r-- 1 root root 8 Aug 9 11:09 datei3.txt
$> tar -c -vf /tmp/myarchiv.tar /file* -C /archiv datei2.txt datei3.txt
tar: Entferne führende „/“ von Elementnamen
/file1
/file2
datei2.txt
datei3.txt
$> tar tf /tmp/myarchiv.tar
file1
file2
datei2.txt
datei3.txt
$>
Ein weiteres Beispiel:
$> tar -cvf /tmp/wichtige-files.tar /etc/fstab /etc/services /etc/network/* -C /archiv datei1.txt datei2.txt
tar: Entferne führende „/“ von Elementnamen
/etc/fstab
/etc/services
/etc/network/if-down.d/
/etc/network/if-down.d/upstart
/etc/network/if-down.d/avahi-autoipd
/etc/network/if-down.d/postfix
/etc/network/if-down.d/wpasupplicant
/etc/network/if-post-down.d/
/etc/network/if-post-down.d/wireless-tools
/etc/network/if-post-down.d/avahi-daemon
/etc/network/if-post-down.d/wpasupplicant
/etc/network/if-pre-up.d/
/etc/network/if-pre-up.d/wireless-tools
/etc/network/if-pre-up.d/wpasupplicant
/etc/network/if-pre-up.d/ethtool
/etc/network/if-up.d/
/etc/network/if-up.d/upstart
/etc/network/if-up.d/avahi-autoipd
/etc/network/if-up.d/postfix
/etc/network/if-up.d/avahi-daemon
/etc/network/if-up.d/openssh-server
/etc/network/if-up.d/wpasupplicant
/etc/network/if-up.d/ntpdate
/etc/network/if-up.d/ethtool
/etc/network/if-up.d/mountnfs
/etc/network/interfaces
/etc/network/interfaces.d/
/etc/network/interfaces_ok
/etc/network/run
datei1.txt
datei2.txt
$>
Aber Achtung, die Option ‚-C‘ akzeptiert keine Dateijoker:
$> tar -cvf /tmp/wichtige-files.tar /etc/fstab /etc/services /etc/network/* -C /archiv datei*
tar: Entferne führende „/“ von Elementnamen
/etc/fstab
/etc/services
/etc/network/if-down.d/
/etc/network/if-down.d/upstart
/etc/network/if-down.d/avahi-autoipd
/etc/network/if-down.d/postfix
/etc/network/if-down.d/wpasupplicant
/etc/network/if-post-down.d/
/etc/network/if-post-down.d/wireless-tools
/etc/network/if-post-down.d/avahi-daemon
/etc/network/if-post-down.d/wpasupplicant
/etc/network/if-pre-up.d/
/etc/network/if-pre-up.d/wireless-tools
/etc/network/if-pre-up.d/wpasupplicant
/etc/network/if-pre-up.d/ethtool
/etc/network/if-up.d/
/etc/network/if-up.d/upstart
/etc/network/if-up.d/avahi-autoipd
/etc/network/if-up.d/postfix
/etc/network/if-up.d/avahi-daemon
/etc/network/if-up.d/openssh-server
/etc/network/if-up.d/wpasupplicant
/etc/network/if-up.d/ntpdate
/etc/network/if-up.d/ethtool
/etc/network/if-up.d/mountnfs
/etc/network/interfaces
/etc/network/interfaces.d/
/etc/network/interfaces_ok
/etc/network/run
tar: datei: Funktion stat fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
tar: datei.lnk: Funktion stat fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler
$>
Nur eine einzelne Datei (‚etc/hosts.allow‘) aus dem Archiv extrahieren:
$> tar cJf /root/etc-vor-DNS-install.tar.xz /etc
tar: Entferne führende „/“ von Elementnamen
$> ls -l
insgesamt 1040
-rw-r--r-- 1 root root 1063120 Aug 9 12:11 etc-vor-DNS-install.tar.xz
$> file etc-vor-DNS-install.tar.xz
etc-vor-DNS-install.tar.xz: XZ compressed data
$> tar tf etc-vor-DNS-install.tar.xz | grep hosts
etc/ghostscript/
etc/ghostscript/cidfmap.d/
etc/ghostscript/cidfmap.d/90gs-cjk-resource-gb1.conf
etc/ghostscript/cidfmap.d/90gs-cjk-resource-korea1.conf
etc/ghostscript/cidfmap.d/90gs-cjk-resource-japan2.conf
etc/ghostscript/cidfmap.d/90gs-cjk-resource-cns1.conf
etc/ghostscript/cidfmap.d/90gs-cjk-resource-japan1.conf
etc/ghostscript/fontmap.d/
etc/ghostscript/fontmap.d/10gsfonts.conf
etc/hosts.allow
etc/apache2/conf-enabled/other-vhosts-access-log.conf
etc/apache2/conf-available/other-vhosts-access-log.conf
etc/icinga2/conf.d/hosts/
etc/icinga2/conf.d/hosts/localhost.conf
etc/icinga2/conf.d/hosts/localhost/
etc/icinga2/conf.d/hosts/localhost/load.conf
etc/icinga2/conf.d/hosts/localhost/apt.conf
etc/icinga2/conf.d/hosts/localhost/ssh.conf
etc/icinga2/conf.d/hosts/localhost/swap.conf
etc/icinga2/conf.d/hosts/localhost/disk.conf
etc/icinga2/conf.d/hosts/localhost/users.conf
etc/icinga2/conf.d/hosts/localhost/http.conf
etc/icinga2/conf.d/hosts/localhost/icinga.conf
etc/icinga2/conf.d/hosts/localhost/procs.conf
etc/avahi/hosts
etc/ImageMagick-6/type-ghostscript.xml
etc/hosts.deny
$> ls -l
insgesamt 2412
-rw-r--r-- 1 root root 1402963 Aug 9 12:12 etc-2017-08-09_12-12.tgz
-rw-r--r-- 1 root root 1063120 Aug 9 12:11 etc-vor-DNS-install.tar.xz
$>
$>
$> # ACHTUNG: Die Datei muss mit relativen Pfad angegeben werden:
$> tar xvJf etc-vor-DNS-install.tar.xz etc/hosts.allow
etc/hosts.allow
$>
$> # Zur Kontrolle:
$> ls -l
insgesamt 2416
drwxr-xr-x 2 root root 4096 Aug 9 12:13 etc
-rw-r--r-- 1 root root 1402963 Aug 9 12:12 etc-2017-08-09_12-12.tgz
-rw-r--r-- 1 root root 1063120 Aug 9 12:11 etc-vor-DNS-install.tar.xz
$> ls -l etc
insgesamt 4
-rw-r--r-- 1 root root 451 Jul 10 10:29 hosts.allow
$>
Bandlaufwerke mit ‚tar‘ ansprechen
Neben der normalen Arbeitsweise mit Dateien kann ‚tar‘ auch direkt auf Blockebene arbeiten:
$> dd if=/dev/zero of=/root/my-virtual-tape.img bs=1M count=250
250+0 Datensätze ein
250+0 Datensätze aus
262144000 Bytes (262 MB) kopiert, 0,930163 s, 282 MB/s
$> tar cJf /root/my-virtual-tape.img /etc
tar: Entferne führende „/“ von Elementnamen
$>
Überprüfen, ob es funktioniert hat:
$> mount /root/my-virtual-tape.img /mnt
mount: Falscher Dateisystemtyp, ungültige Optionen, der
Superblock von /dev/loop0 ist beschädigt, fehlende
Kodierungsseite oder ein anderer Fehler
Manchmal liefert das Systemprotokoll wertvolle Informationen –
versuchen Sie dmesg | tail oder ähnlich
$>
$> dmesg | tail -5
[30064.249408] e1000: eth1 NIC Link is Down
[30064.249435] e1000 0000:00:08.0 eth1: Reset adapter
[30066.309668] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[30069.141566] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[35231.086612] loop: module loaded
$>
Alles klar: Dies macht ja auch absolut keinen Sinn, Blockebene bedeutet hier „kein Dateisystem vorhanden“.
Sprechen wir daher einfach das Device direkt an:
$> tar tJf /root/my-virtual-tape.img | grep fstab
etc/fstab~
etc/fstab
$>
Bitte auswendiglernen, welche Gerätedateien für Bandlaufwerke in Frage kommen (S. 227 oben):
/dev/st0 - erstes SCSI-Tape, rückspulend
/dev/nst0 - erstes SCSI-Tape, NICHT rückspulend
/dev/ft0 - erstes Floppy-Tape, rückspulend (Nicht verwechseln mit Floppy Disks: /dev/fd0)
/dev/nft0 - erstes Floppy-Tape, NICHT rückspulend
Welche Tools werden in dem Zusammenhang verwendet? Dies sind nur ein paar wichtige:
dd
dump/restore
tar
mt (zum Steuern der Bandlaufwerke)
Siehe dazu auch https://www.cyberciti.biz/faq/linux-tape-backup-with-mt-and-tar-command-howto/
Backups mit Linux
Siehe Seite 223 - 225
Was muss gesichert werden? Siehe hier:
$> ls -ld /home /etc /var
drwxr-xr-x 158 root root 12288 Aug 9 14:23 /etc
drwxr-xr-x 16 root root 4096 Jun 21 08:50 /home
drwxr-xr-x 13 root root 4096 Jun 9 10:15 /var
Zu den Backupstrategien:
Kosten
Wiederherstellbarkeit (Testfall, verschiedene Softwarelösungen einsetzten, KISS-Regel)
Off Side Backups (Gebäudebrand, Hochwasser)
Zu den Sicherungsarten siehe auch http://www.grundlagen-computer.de/backup/backup-strategien-inkrementell-differentiell-und-vollbackup
Netzwerkfähige Backuplösungen:
rsync
amanda
bacula / bareos (für große VMs ungünstig, da die Lösungen mit vituellen Tapes arbeiten!)
BackupPC
backy (Einsatz in VM-Hosting-Umgebungen), siehe https://chemnitzer.linux-tage.de/2016/de/programm/beitrag/272
TIPP am Rande: https://de.wikipedia.org/wiki/SmartOS
Das Werkzeug schlechthin: rsync
Siehe Seite 230 f, grundlegendes:
Entwickelt vom Samba-Team, um die Daten des PDC mit dem BDC zu replizieren (wie zu Zeiten zu Windows NT 4.0; PDC: Primary Domain Controller, BDC: Backup Domain Controller)
Beherrscht differentielle Datenübertragung (Delta-Algorithmus)
Unidirektionales Übertragen (keine Konfliktbehandlung, Bidirektional sind z.B. unison, osync)
Lokales oder netzwerkbasiertes Arbeiten ist möglich
Bei netzwerkbasiertem Arbeiten wird per Default SSH verwendet (damit ist der Schalter ‚-e‘ erst einmal überflüssig)
Beim Synchronisieren muss dem Quellverzeichnis ein endender Splash mitgegeben werden, sonst wird es als Unterverzeichnis auf das Ziel kopiert.
Das Ganze nun praktisch, fangen wir mit letzterer Problematik an:
$> id
uid=1000(tux) gid=1000(tux) Gruppen=1000(tux),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),113(lpadmin),115(scanner),121(bluetooth)
$> mkdir QUELLE ZIEL
$> cp -v /etc/host* QUELLE/
„/etc/host.conf“ -> „QUELLE/host.conf“
„/etc/hostname“ -> „QUELLE/hostname“
„/etc/hosts“ -> „QUELLE/hosts“
„/etc/hosts.allow“ -> „QUELLE/hosts.allow“
„/etc/hosts.deny“ -> „QUELLE/hosts.deny“
$> du -sh /usr/share/doc/bash
208K /usr/share/doc/bash
$> cp -r /usr/share/doc/bash QUELLE/
$> rsync -av QUELLE ZIEL
sending incremental file list
QUELLE/
QUELLE/host.conf
QUELLE/hostname
QUELLE/hosts
QUELLE/hosts.allow
QUELLE/hosts.deny
QUELLE/bash/
QUELLE/bash/CHANGES.gz
QUELLE/bash/COMPAT.gz
QUELLE/bash/INTRO.gz
QUELLE/bash/NEWS.gz
QUELLE/bash/POSIX.gz
QUELLE/bash/RBASH
QUELLE/bash/README
QUELLE/bash/README.Debian.gz
QUELLE/bash/README.abs-guide
QUELLE/bash/README.bash_completion.gz -> ../bash-completion/README.gz
QUELLE/bash/README.commands.gz
QUELLE/bash/changelog.Debian.gz
QUELLE/bash/copyright
QUELLE/bash/inputrc.arrows
sent 189,067 bytes received 377 bytes 378,888.00 bytes/sec
total size is 187,741 speedup is 0.99
$>
Wir prüfen den Inhalt von ZIEL:
$> ls -F ZIEL
QUELLE/
$>
Hier ist genau dieser Fehler passiert, dass QUELLE als UNTERverzeichnis kopiert wurde, wir beheben es:
$> rm -rf ZIEL/*
$> rsync -av QUELLE/ ZIEL
sending incremental file list
./
host.conf
hostname
hosts
hosts.allow
hosts.deny
bash/
bash/CHANGES.gz
bash/COMPAT.gz
bash/INTRO.gz
bash/NEWS.gz
bash/POSIX.gz
bash/RBASH
bash/README
bash/README.Debian.gz
bash/README.abs-guide
bash/README.bash_completion.gz -> ../bash-completion/README.gz
bash/README.commands.gz
bash/changelog.Debian.gz
bash/copyright
bash/inputrc.arrows
sent 189,054 bytes received 376 bytes 378,860.00 bytes/sec
total size is 187,741 speedup is 0.99
$> ls -F ZIEL
bash/ host.conf hostname hosts hosts.allow hosts.deny
$>
Übertragung mit Statusinfos nach Änderung einer Datei:
$> echo '10.20.30.123 mySuperServer' >> QUELLE/hosts
$> rsync -av --progress --stats QUELLE/ ZIEL
sending incremental file list
hosts
427 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=17/21)
Number of files: 21 (reg: 18, dir: 2, link: 1)
Number of created files: 0
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 187,769 bytes
Total transferred file size: 427 bytes
Literal data: 427 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 1,011
Total bytes received: 36
sent 1,011 bytes received 36 bytes 2,094.00 bytes/sec
total size is 187,769 speedup is 179.34
$> tail -1 ZIEL/hosts
10.20.30.123 mySuperServer
$>
Wichtige Optionen:
archiv: Wenn möglich alle Eigenschaften erhalten: ‚-a‘
verbose: ‚-v‘
Statusinformationen: ‚–progress –stats‘
Unix-Hardlinks beachten (Inode-Nummern!): ‚-H‘
Komprimieren: ‚-z‘
Löschen, was nicht auf der sendenden Seite existiert (Master/Slave-Mirror): ‚–delete‘
Testlauf only: ‚-n‘ oder ‚–dry-run‘
Wir testen den Master/Slave-Mirror:
$> echo '###' >> QUELLE/hosts
$> \rm QUELLE/host.conf
$> rsync -av --progress --stats --delete --dry-run QUELLE/ ZIEL
sending incremental file list
deleting host.conf
./
hosts
Number of files: 20 (reg: 17, dir: 2, link: 1)
Number of created files: 0
Number of deleted files: 1 (reg: 1)
Number of regular files transferred: 1
Total file size: 187,746 bytes
Total transferred file size: 431 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 535
Total bytes received: 43
sent 535 bytes received 43 bytes 1,156.00 bytes/sec
total size is 187,746 speedup is 324.82 (DRY RUN)
$>
AUFGABE:
Mit ‚rsync‘ das auf dem Server liegende Verzeichnis ‚/etc‘ als root sichern. Dazu ‚PermitRootLogin‘ in der Datei ‚/etc/ssh/sshd_config‘ auf ‚yes‘ setzen.
‚PermitRootLogin‘ wieder auf ‚no‘ setzen, einen dedizierte Benutzer anlegen, der das Verzeichnis /etc nur lesend sichern darf.
Das Sichern mit dem dedizierten Benutzer automatisierbar machen (Autologin)
Ein paar angetestete Lösungsvorschläge:
Zurücksetzen von ‚PermitRootLogin yes‘ auf ‚PermitRootLogin without-password‘:
root@d8:~# vi /etc/ssh/sshd_config
root@d8:~#
root@d8:~# grep --color PermitRootLogin /etc/ssh/sshd_config
PermitRootLogin without-password
#PermitRootLogin yes
# the setting of "PermitRootLogin without-password".
root@d8:~#
root@d8:~# systemctl restart sshd
root@d8:~#
Wir testen als einfacher Benutzer, welche Dateien nicht lesbar sind:
tux@d8:~$ cp -r /etc/ etc_bk 2> read.errors
tux@d8:~$
tux@d8:~$ cat read.errors
cp: „/etc/security/opasswd“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/.pwd.lock“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/subgid-“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/subuid-“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/passwd-“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/shadow-“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/group-“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/gshadow-“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/shadow“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/gshadow“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: Zugriff auf „/etc/lvm/backup“ nicht möglich: Keine Berechtigung
cp: „/etc/at.deny“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/exim4/passwd.client“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/ssh/ssh_host_rsa_key“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/ssh/ssh_host_dsa_key“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: Zugriff auf „/etc/ssl/private“ nicht möglich: Keine Berechtigung
cp: „/etc/iscsi/iscsid.conf“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/sudoers.d/README“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
cp: „/etc/sudoers“ kann nicht zum Lesen geöffnet werden: Keine Berechtigung
tux@d8:~$
Kein Wunder, sehen wir uns mal drei solcher problematischen Dateien an:
tux@d8:~$ ls -l /etc/sudoers /etc/shadow /etc/ssh/ssh_host_rsa_key
-rw-r----- 1 root shadow 965 Aug 10 13:39 /etc/shadow
-rw------- 1 root root 1675 Sep 21 2016 /etc/ssh/ssh_host_rsa_key
-r--r----- 1 root root 714 Sep 22 2016 /etc/sudoers
tux@d8:~$
Vor dem Ändern der Dateireichte von /etc (was generell nicht empfehlenswert ist!!), legen wir als root ein Backup an:
root@d8:~# cp -a /etc/ /root/etc_orig
root@d8:~#
root@d8:~# getfacl /etc
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: etc
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
root@d8:~#
root@d8:~# setfacl -R -m u:tux:r-x /etc
root@d8:~#
root@d8:~# getfacl /etc
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: etc
# owner: root
# group: root
user::rwx
user:tux:r-x
group::r-x
mask::r-x
other::r-x
root@d8:~# su - tux
tux@d8:~$
tux@d8:~$ cp -a /etc /home/tux/etc_von_tux_kopiert
tux@d8:~$
tux@d8:~$ du -s etc_*
4004 etc_bk
4076 etc_von_tux_kopiert
tux@d8:~$ exit
Damit konnte der Nutzer zwar alles kopieren, leider aber akzepiert der ssh-Daemon nicht einmal diese kleine, via File ACLs vorgenommene Rechteerweiterung. Beim Loginversuch des Nutzers kommt die Meldung „Read from socket failed: Connection reset by peer“. Daher müssen wir die ACLs für den Benutzer ‚tux‘ auf dem Server später wieder entfernen!
Auf dem Client-Rechner wird nun das Backup-Zielverzeichnis angelegt, die nächsten Schritte sind dann allerdings auch noch nicht erfolgreich:
$> mkdir backup-10.44.30.126
$>
$> rsync -n -a --progress --stats 10.44.30.126:/etc /home/tux/backup-10.44.30.126/
Connection closed by 10.44.30.126
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.1]
$>
URSACHE: Es läuft zwar auf dem Server der sshd (Port 22), aber das Programm ‚rsync‘ fehlte dort noch. Nach der Installation mit ‚apt-get install rsync‘:
$> rsync -n -a --progress --stats 10.44.30.126:/etc /home/tux/backup-10.44.30.126/Read from socket failed: Connection reset by peer
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.1]
$>
Das Rechteerweiterungs-Problem:
$> ssh tester@10.44.30.126
Read from socket failed: Connection reset by peer
$>
Die Meldung „Read from socket failed: Connection reset by peer“ weist auf ein größeres Problem hin. Im Syslog lesen wir „WARNING: UNPROTECTED PRIVATE KEY FILE!“. Daher entfernen wir die ACLs für den Benutzer ‚tux‘ auf dem Server wieder mit:
$> setfacl -R -x u:tux: /etc
Danach ist ein Login per ssh wieder problemlos möglich. Lösungsmöglichkeiten, wenn am grundlegenden Konzept festgehalten werden soll, dass sich der Client die Daten selber ziehen soll:
Die Daten als ‚root‘ kopieren (Wobei aus Sicherheitsgründen nur mit einem eigenen, clientseitigen Schlüsselpaar operiert werden sollte. Dank der sinnvollen Voreinstellung in der ‚/etc/ssh/sshd_config‘, die da ‚PermitRootLogin without-password‘ lautet, ist sowieso kein Benutzername/Passwortpaar-Login möglich).
Ein Szenario mit einem dedizierten Benutzer umsetzten, wie es für die ähnlich gelagerte Software ‚rdiff-backup‘ unter https://www.howtoforge.com/linux_rdiff_backup beschrieben ist.
Zum Daemon-Mode von ‚rsync‘ siehe S. 232, hier ein paar wichtige Merkmale
Die Option ‚–deamon‘ aktiviert den standalone Daemon Mode.
Konfigdatei: /etc/rsync.conf
Port: 873 (unverschlüsselt!)
Besonderheit beim clientseitigen Zugriff: Zwei Doppelpunkte (‚::‘) trennen Server- und Sharename:
$> rsync ftp.halifax.rwth-aachen.de::debian-cd/
--------------------------------------------------------------
The features compression (-z) and checksums (-c) are disabled.
More information about this server is available via HTTP:
http://ftp.halifax.rwth-aachen.de/
--------------------------------------------------------------
drwxr-xr-x 98 2017/06/18 06:44:09 .
lrwxrwxrwx 5 2017/06/18 04:47:23 current
lrwxrwxrwx 10 2017/06/18 04:47:30 current-live
-rw-r--r-- 12,475 2017/06/18 06:12:01 ls-lR.gz
drwxr-xr-x 30 2017/06/18 02:28:17 9.0.0-live
drwxr-xr-x 150 2017/06/18 04:36:46 9.0.0
drwxr-xr-x 20 2005/05/23 18:50:12 project
$>
Ein Kopiervorgang sieht dann z.B. so aus:
$> rsync ftp.halifax.rwth-aachen.de::debian-cd/project/build/9.0.0/source /tmp
--------------------------------------------------------------
The features compression (-z) and checksums (-c) are disabled.
More information about this server is available via HTTP:
http://ftp.halifax.rwth-aachen.de/
--------------------------------------------------------------
$> echo $?
0
$>
$> date
Do 10. Aug 14:46:10 CEST 2017
$> ls -l /tmp/source
-rw-r--r-- 1 tester tester 4 Aug 10 14:45 /tmp/source
$> cat /tmp/source
dvd
$>
Einrichtung eines rsync-Servers
Datum: 2017-08-11
OS: Debian 8.9 (Jessie)
Meist ist ‚rsync‘ schon vorinstalliert, das Paket bringt eine Beispielkonfiguration mit:
$> cp /usr/share/doc/rsync/examples/
logrotate.conf.rsync rsyncd.conf
$> cp /usr/share/doc/rsync/examples/rsyncd.conf /etc
Damit haben wir die Datei an die richtige Stelle kopiert und wollen sie erstmal nur inspizieren:
$> grep -v '^\s*#\|^$' /etc/rsyncd.conf
[ftp]
comment = public archive
path = /var/www/pub
use chroot = yes
lock file = /var/lock/rsyncd
read only = yes
list = yes
uid = nobody
gid = nogroup
strict modes = yes
ignore errors = no
ignore nonreadable = yes
transfer logging = no
timeout = 600
refuse options = checksum dry-run
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz
Dies ist der originale, aktive Inhalt, den wir nicht ändern brauchen. Wir legen nur den Freigabeordner und eine Testdatei an:
$> mkdir -p /var/www/pub
$> echo Willkommen... > /var/www/pub/willkommen.txt
Und kontrollieren und starten nun den rsync-Daemon, zuerst aber prüfen wir, ob er vielleicht schon läuft:
$> pgrep -a rsync
$> lsof -i:873
$> lsof -i:22
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 655 root 3u IPv4 13744 0t0 TCP *:ssh (LISTEN)
sshd 655 root 4u IPv6 13746 0t0 TCP *:ssh (LISTEN)
ssh 27160 tux 3u IPv4 175023 0t0 TCP 10.44.30.220:41954->lux.ptsa.de:ssh (ESTABLISHED)
ssh 30660 tux 3u IPv4 207026 0t0 TCP 10.44.30.220:42243->lux.ptsa.de:ssh (ESTABLISHED)
$>
Er läuft natürlich noch nicht, wir versuchen ihn, manuell zu starten:
$> rsync --daemon
$> pgrep -a rsync
31429 rsync --daemon
$> lsof -i:873
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rsync 31429 root 4u IPv4 218618 0t0 TCP *:rsync (LISTEN)
rsync 31429 root 5u IPv6 218619 0t0 TCP *:rsync (LISTEN)
$>
Das Starten mittels rsync --daemon war erfolgreich, der Dienst läuft nun. Nun schauen wir nach, was der Server zu bieten hat:
$> rsync localhost::
ftp public archive
$>
Mit der zuletzt ausgeführten Zeile haben wir einen direkten Zugriff auf den Server durchgeführt, der erst einmal nur die verfügbaren Shares auflistet.
Nun folgt ein richtiger Kopiervorgang:
$> mkdir /tmp/ftp
$> rsync -av --stats --progress localhost::ftp/ /tmp/ftp/
receiving incremental file list
./
willkommen.txt
14 100% 13.67kB/s 0:00:00 (xfr#1, to-chk=0/2)
Number of files: 2 (reg: 1, dir: 1)
Number of created files: 1 (reg: 1)
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 14 bytes
Total transferred file size: 14 bytes
Literal data: 14 bytes
Matched data: 0 bytes
File list size: 64
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 50
Total bytes received: 143
sent 50 bytes received 143 bytes 386.00 bytes/sec
total size is 14 speedup is 0.07
$>
$> ls -lisa /tmp/ftp/
insgesamt 12
1832170 4 drwxr-xr-x 2 root root 4096 Aug 11 10:57 .
1831425 4 drwxrwxrwt 17 root root 4096 Aug 11 11:09 ..
1832193 4 -rw-r--r-- 1 root root 14 Aug 11 10:57 willkommen.txt
$>
Testen, ob der endende Slash auch bei der Nutzung des rsync-Daemons erforderlich ist:
$> rm -fv /tmp/ftp/*
„/tmp/ftp/willkommen.txt“ wurde entfernt
$> rsync -av --stats --progress localhost::ftp /tmp/ftp
receiving incremental file list
./
willkommen.txt
14 100% 13.67kB/s 0:00:00 (xfr#1, to-chk=0/2)
Number of files: 2 (reg: 1, dir: 1)
Number of created files: 1 (reg: 1)
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 14 bytes
Total transferred file size: 14 bytes
Literal data: 14 bytes
Matched data: 0 bytes
File list size: 64
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 50
Total bytes received: 143
sent 50 bytes received 143 bytes 386.00 bytes/sec
total size is 14 speedup is 0.07
$>
$> ls -lisa /tmp/ftp/
insgesamt 12
1832170 4 drwxr-xr-x 2 root root 4096 Aug 11 10:57 .
1831425 4 drwxrwxrwt 17 root root 4096 Aug 11 11:11 ..
1832193 4 -rw-r--r-- 1 root root 14 Aug 11 10:57 willkommen.txt
$>
Wir sehen, dass hierbei der endende Slash bei Quelle NICHT erforderlich ist.
Im Gegensatz zu direkten Verzeichnisoperationen:
$> rm -fv /tmp/ftp/*
„/tmp/ftp/willkommen.txt“ wurde entfernt
$> ls -lisa /tmp/ftp/
insgesamt 8
1832170 4 drwxr-xr-x 2 root root 4096 Aug 11 11:14 .
1831425 4 drwxrwxrwt 17 root root 4096 Aug 11 11:11 ..
$> rsync -av /var/www/pub /tmp/ftp/
sending incremental file list
pub/
pub/willkommen.txt
sent 143 bytes received 39 bytes 364.00 bytes/sec
total size is 14 speedup is 0.08
$> ls -lisa /tmp/ftp/
insgesamt 12
1832170 4 drwxr-xr-x 3 root root 4096 Aug 11 11:14 .
1831425 4 drwxrwxrwt 17 root root 4096 Aug 11 11:15 ..
1832193 4 drwxr-xr-x 2 root root 4096 Aug 11 10:57 pub
Dies ist allerding nicht das, was wir wollten! Das Verzeichnis ‚pub‘ ist ein Unterverzeichnis von /tmp/ftp geworden!
Immer, wenn wir mit ‚rsync‘ Verzeichnisse direkt ansprechen, muss der endende Slash an den Namen des Quell-Verzeichnisses angehängt werden:
$> rm -fvr /tmp/ftp/*
„/tmp/ftp/pub/willkommen.txt“ wurde entfernt
Verzeichnis wurde entfernt: „/tmp/ftp/pub“
$>
$> rsync -av /var/www/pub/ /tmp/ftp/
sending incremental file list
./
willkommen.txt
sent 131 bytes received 38 bytes 338.00 bytes/sec
total size is 14 speedup is 0.08
$> ls -lisa /tmp/ftp/
insgesamt 12
1832170 4 drwxr-xr-x 2 root root 4096 Aug 11 10:57 .
1831425 4 drwxrwxrwt 17 root root 4096 Aug 11 11:30 ..
1832193 4 -rw-r--r-- 1 root root 14 Aug 11 10:57 willkommen.txt
Nun haben wir wieder eine Ordnersynchronisation vorliegen, wie es meistens gewünscht ist.
Erforschen wir nun, ob der manuell gestartete rsync-Daemon als Background-Job der Shell läuft:
$> jobs
$> ps aux | grep rsync
root 31429 0.0 0.0 4424 2012 ? Ss 11:02 0:00 rsync --daemon
root 32396 0.0 0.1 4576 2192 pts/7 D+ 11:35 0:00 grep rsync
$>
Nein - man sieht besonders gut mittels der Kommandozeile ps aux | grep rsync, dass es kein Job ist. Es handelt sich eben um einen echten Daemon (siehe das Fragezeichen (‚?‘) in der Spalte TTY, was bedeutet, dass der Prozess keine Verbindung zu einem Terminal hat).
Daher können wir den Daemon nicht einfach mittels der Jobkontrolle beenden, sondern so:
$> killall rsync
$> killall rsync
rsync: Kein Prozess gefunden
$> rsync localhost::
rsync: failed to connect to localhost (::1): Connection refused (111)
rsync: failed to connect to localhost (127.0.0.1): Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(128) [Receiver=3.1.1]
$>
Leider gibt es laut man-Page von rsync (Abschnitt „DAEMON OPTIONS“) keinen Schalter, der das Logging im Vordergrund möglich macht. Mit Hilfe der Gerätedatei, die fürs eigene, aktuelle Terminal verantworlich zeichnet, gelingt es aber:
$> tty
/dev/pts/7
$>
$>
$> rsync --daemon --no-detach --log-file=/dev/pts/7
2017/08/11 11:50:36 [388] rsyncd version 3.1.1 starting, listening on port 873
2017/08/11 11:50:43 [393] connect from jessie (10.44.30.250)
2017/08/11 11:50:43 [393] module-list request from jessie (10.44.30.250)
-- STRG+C gedrückt --
^C2017/08/11 11:50:53 [388] rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(632) [Receiver=3.1.1]
$>
Wir können hierbei einen entfernten Zugriff beobachten, der mittels der Kommandozeile rsync 10.44.30.220:: ausgelöst wurde. Mit STRG + C lässt sich der Daemon dann wieder beenden.
Abschließend soll nun der Daemon über den systemeigenen init-Dienst ‚systemd‘ gestartet werden.
Zuerst interessiert uns hierbei, ob Debian überhaupt eine Unit-Datei für den rsync-Daemon mit ausliefert. Die erste Kommandozeile gibt allerdings keine Informationen aus, weil der Service nicht läuft, d.h. systemctl start rsync noch nicht ausgeführt wurde. Daher müssen wir systemctl list-unit-files verwenden:
$> systemctl list-units | grep rsync
$>
$> systemctl list-unit-files | grep rsync
rsync.service disabled
$>
Nun Starten und Aktivieren wir den Daemon:
$> systemctl start rsync
$> systemctl list-units | grep rsync
rsync.service loaded active running fast remote file copy program daemon
$>
$> ps aux | grep rsync
root 527 0.0 0.1 4424 2316 ? Ss 11:54 0:00 /usr/bin/rsync --daemon --no-detach
root 529 0.0 0.1 4576 2340 pts/7 S+ 11:54 0:00 grep rsync
$> systemctl status rsync
● rsync.service - fast remote file copy program daemon
Loaded: loaded (/lib/systemd/system/rsync.service; disabled)
Active: active (running) since Fr 2017-08-11 11:54:25 CEST; 29s ago
Main PID: 527 (rsync)
CGroup: /system.slice/rsync.service
└─527 /usr/bin/rsync --daemon --no-detach
Aug 11 11:54:25 Gast1 systemd[1]: Started fast remote file copy program daemon.
Aug 11 11:54:25 Gast1 rsyncd[527]: rsyncd version 3.1.1 starting, listening on port 873
$> systemctl enable rsync
Synchronizing state for rsync.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d rsync defaults
Executing /usr/sbin/update-rc.d rsync enable
$>