Juli 2011 Archive
10.07.2011 16:42
Proxy-Statistik
Der Linux Home Server (LHS) dient auch als Web-Proxy. Die Logdateien des Proxy-Dienstes 'squid' können mit dem Softwarepakte 'srg' im Heimnetzwerk bereitsgestellt werden.
Nachfolgend Auszüge aus der Konfiguration:
/etc/default/srg
# Top level directory for output reports REPORTBASE=/var/www/srg # Configuration file location CONFIGFILE=/etc/srg/srg.conf # Number of days to keep daily SRG reports for. Reports older than this many # days will be automatically removed. DAILY_REPORT_RETAIN_DAYS="15"
Das Softwarepaket installiert selbst das Script für die tägliche Aktualisierung.
root@bluestar:~# dpkg -L srg | grep
'/etc/'
/etc/srg /etc/srg/srg.conf /etc/srg/filtered_sites /etc/srg/ip2user /etc/cron.daily /etc/cron.daily/srg /etc/default /etc/default/srg
03.07.2011 12:42
Streaming-Server
Mit den Programmpaketen icecast2 und und ices2 kann man den Linux Home Server dazu bringen, Musik ins Heimnetz zu streamen.
Auszug aus der Konfigurationsdatei /etc/icecast2/icecast.xml
<icecast> <limits> ... </limits> <authentication> <source-password>????????????</source-password> ... </authentication> <hostname>bluestar.domo.reto</hostname> <listen-socket> <port>8000</port> </listen-socket> ... </icecast>
Auszug aus der Konfigurationsdatei /home/test/music/ices-playlist.xml
<?xml version="1.0"?> <ices> <background>0</background> ... <stream> <metadata> <name>It's my Music</name> ... </metadata> <input> <module>playlist</module> <param name="type">basic</param> <param name="file">playlist.txt</param> ... </input> <instance> <hostname>localhost</hostname> <port>8000</port> <password>????????????</password> <mount>/live</mount> ... </instance> </stream> </ices>
URL
http://bluestar.domo.reto:8000/live
In der Datei /home/test/music/playlist.txt stehen zeilenweise die Namen der Audio-Dateien, welche vom Streaming-Server ausgegeben werden sollen.
Die Passwörter '????????????' in den beiden Konfigurationsdateien müssen übereinstimmen.
test@bluestar:~/music$
ices2 ices-playlist.xml
03.07.2011 12:27
Drucken mit dem LHS
Der Linux Home Server (LHS) bietet sich als Druckserver mit den Diensten CUPS und Samba an.
Es steht noch eine Beschreibung aus, wie ein Benutzer diese Druckdienste in Anspruch nehmen kann. In diesem Beitrag gibt es als Vorgeschmack schon einmal einige Bildschirmfotos.
Drucker einrichten
Drucker ausprobieren
In PDF-Dokumente drucken
Testdruck: job_75-smbprn_00000004_Testseite.pdf
03.07.2011 11:41
Dateiserver für Linux-Clients
Bereits in einem früheren Artikel wurde gezeigt, wie die Dienste des LHS auch von Arbeitsplatzrechnern unter GNU/Linux in Anspruch genommen werden können.
Etwas unelegant wirkte dabei die Benutzung von Samba als Dateiserver. Schließlich können Linux-Rechner unter einander auch gut mit dem alt hergebrachten NFS arbeiten.
NFS läuft bereits einige Tage im Probebetrieb mit aktiviertem Virenschutz per clamfs. Für eine ausführliche Beschreibung fehlt mir aktuell leider die Zeit, daher muss ich mich hier auf einige wenige Punkte beschränken.
exportfs -v
/srv/nfs/downloads *.domo.reto(ro,async,wdelay,root_squash,no_subtree_check,fsid=1,mountpoint) /srv/nfs/public *.domo.reto(rw,wdelay,root_squash,no_subtree_check,fsid=2,mountpoint)
Die freigegeben Ordner im Verzeichnis /srv/nfs werden per clamfs bereitgestellt, um zentral nach Viren zu scannen.
mount -l | grep '/srv/nfs'
clamfs on /srv/nfs/downloads type fuse.clamfs (rw,nosuid,nodev,allow_other,default_permissions) clamfs on /srv/nfs/public type fuse.clamfs (rw,nosuid,nodev,allow_other,default_permissions)
cat /etc/clamfs/public.xml
<clamfs> <clamd socket="/var/run/clamav/clamd.ctl" check="yes" /> <filesystem root="/var/lib/samba/shares/public" mountpoint="/srv/nfs/public" public="yes" /> <cache entries="8192" expire="28800000" /> <!-- time in ms --> <stats atexit="yes" every="3600" /> <!-- time in sec --> <log method="syslog" /> <mail server="localhost" to="root@localhost" from="clamfs@localhost" subject="ClamFS: Virus gefunden" /> </clamfs>
grep 'clamfs' /etc/fstab
clamfs#/etc/clamfs/public.xml /srv/nfs/public fuse noauto 0 0 clamfs#/etc/clamfs/downloads.xml /srv/nfs/downloads fuse noauto 0 0
Der Mount-Befehl für die o.g. Verzeichnisse erfolgt per crontab zeitlich verzögert nach dem Systemstart, damit der Dienst clamav-daemon vorher gestartet werden kann.
Und so sehen die importierten Verzeichnisse auf einem Ubuntu-Client aus:
mount | grep ' nfs '
bluestar:/srv/nfs/downloads on /mnt/downloads type nfs (rw,soft,retrans=16,bg,retry=60,addr=192.168.1.2) bluestar:/srv/nfs/public on /mnt/public type nfs (rw,soft,retrans=16,bg,retry=60,addr=192.168.1.2)
Der Benutzer main hat in diesem Fall sowohl auf dem Client-Rechner als auch auf dem Server die UID 1000. Das ist für die Benutzung von nfs ungemein hilfreich. ;-)
03.07.2011 08:16
Paketzahl am 03.07.2011
dpkg --get-selections | grep
--count 'install'
Anzahl der installierten Software-Pakete: 1335
03.07.2011 08:00
Prozessor-Statistik 08:00
iostat -ct
Linux 2.6.32-5-vserver-686 (bluestar) 03.07.2011 _i686_ (4 CPU) 03.07.2011 08:00:00 avg-cpu: %user %nice %system %iowait %steal %idle 0,72 0,50 3,72 5,47 0,00 89,60
02.07.2011 23:00
Snapshot-Performance
Der im folgenden beschriebene kleine Test soll einen ersten Einblick in die Belastung des Systems verschaffen, welche durch die Verwendung von LVM-Snapshots entsteht.
Verwendet wird eine mit Zufallsdaten gefüllte Datei von 3,2 GB Größe.
ls -l /var/spool/urandom.dat
-rw-r--r-- 1 root root 3221225472 2. Jul 16:08 /var/spool/urandom.dat
Vor dem eigentlichen Test wird zur Schaffung vergleichbarer Voraussetzungen ein doppelter Kopierlauf ins 'Nirgendwo' durchgeführt.
dd if=/var/spool/urandom.dat of=/dev/null
dd if=/var/spool/urandom.dat of=/dev/null
Der eigentliche Test besteht aus vier Operationen.
- Kopieren:
dd if=/var/spool/urandom.dat of=/home/urandom.dat
- Nur lesen:
dd if=/home/urandom.dat of=/dev/null
- Kopieren:
dd if=/var/spool/urandom.dat of=/home/urandom.dat
- Nur lesen:
dd if=/home/urandom.dat of=/dev/null
Folgende Zeiten und Datendurchsätze wurden ermittelt:
Mit Snapshot | Ohne Snapshot | |
---|---|---|
Kopieren | Dauer: 812 s Rate: 4,0 MB/s |
Dauer: 317 s Rate: 10,2 MB/s |
Nur lesen: | Dauer: 183 s Rate: 17,6 MB/s |
Dauer: 156 s Rate: 20,7 MB/s |
Kopieren | Dauer: 825 s Rate: 3,9 MB/s |
Dauer: 323 s Rate: 10,0 MB/s |
Nur lesen: | Dauer: 157 s Rate: 20,5 MB/s |
Dauer: 154 s Rate: 20,9 MB/s |
Bei aktiviertem Snapshot dauern Kopiervorgänge etwa um den Faktor 2,5 länger. Es wäre also zu überlegen, ob statt der ständig aktiven Snapshots nicht besser regelmäßige, vielleicht sogar stündliche Mini-Backups auf der Festplatte des Servers angefertigt werden sollten, z.B. mit rsnapshot.
Übrigens wird im zweiten Kopiervorgang der Speicherplatz des Snapshots im vollen Umfang belastet, obwohl in die gleiche Zieldatei geschrieben wird.
LV LSize Origin Snap% Zeitpunkt home.snap 7,45g home 0,00 vor dem ersten Kopieren home.snap 7,45g home 40,53 nach dem ersten Kopieren home.snap 7,45g home 81,07 nach dem zweiten Kopieren
02.07.2011 16:08
Snapshot-Statistik 16:08
iostat -dktzN | egrep
'Device|var'
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn vg1-var 8,18 27,93 4,78 2860077 489940 vg1-var.snap 0,01 0,06 0,00 5709 4 vg1-var-real 4,09 14,02 2,35 1435640 240748 vg1-var.snap-cow 0,48 0,01 1,91 1177 195836
02.07.2011 16:07
Snapshot-Struktur
dmsetup table | grep
'var'
vg1-var-real: 0 15622144 linear 253:0 27328896 vg1-var.snap: 0 15622144 snapshot 253:6 253:7 P 8 vg1-var.snap-cow: 0 3121152 linear 253:0 109330816 vg1-var: 0 15622144 snapshot-origin 253:6
Wie wirken diese vier Devices nun zusammen? Ich übertrage die Ausführungen von Richard WM Jones in seinem Blog-Beitrag "How LVM does snapshots".
vg1-var vg1-var.snap | | | | +---------------+ | v v v vg1-var-real vg1-var.snap-cow
Ich zitiere aus dem o.g. Artikel:
F13x64snap-cow at the bottom right is the actual storage used for the snapshot exception list. It is just a plain linear mapping of some blocks from the underlying block device. F13x64snap is the virtual device. When read, the read consults the exception list in the snapshot cow, and if not there, consults the real device. Writes to F13x64snap go to the exception list. Finally, writes to the virtual origin device F13x64 go to the snapshot cow (or snapshot cows plural). There is no explicit connection here — in fact it goes via a hash table stored in kernel memory."
Ersetzen Sie beim Lesen einfach F13x64 durch vg1-var.