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.

Startseite der Web-Statistik mit 'srg' Anonymisierte Beispielseite der Web-Statistik mit 'srg'

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


Geschrieben von root | Permanenter Link | Kategorien: Benutzung, Verwaltung

03.07.2011 13:11


Geschrieben von root | Permanenter Link | Kategorien: Projekt

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.

Starten des Streaming-Servers und Empfangen des Streams auf einem Ubuntu-Client Verbindungsaufnahme zum Streaming-Server mit VLC als Client


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

Geschrieben von root | Permanenter Link | Kategorien: Benutzung

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

Druckfreigabe auf dem LHS mit Samba Eingerichtete Netzwerkdrucker auf einem Windows-XP Client


Drucker ausprobieren

Testdruck auf einem Windows-XP Client Testdruck auf einem Windows-XP Client


In PDF-Dokumente drucken

Ein mit dem PDF-Drucker des LHS anonym erstelltes PDF-Dokument wird per Webserver freigegeben. Ein mit dem PDF-Drucker des LHS erzeugtes PDF-Dokument wird im Benutzerordner gespeichert.

Testdruck: job_75-smbprn_00000004_Testseite.pdf


Geschrieben von root | Permanenter Link | Kategorien: Benutzung

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.

NFS-Administration per Webmin


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)

Beispiel für einen NFS-Client

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. ;-)


Geschrieben von root | Permanenter Link | Kategorien: Benutzung

03.07.2011 08:16

Paketzahl am 03.07.2011

dpkg --get-selections | grep --count 'install'
Anzahl der installierten Software-Pakete: 1335


Geschrieben von root | Permanenter Link | Kategorien: Status

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


Geschrieben von root | Permanenter Link | Kategorien: Status

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.

  1. Kopieren: dd if=/var/spool/urandom.dat of=/home/urandom.dat
  2. Nur lesen: dd if=/home/urandom.dat of=/dev/null
  3. Kopieren: dd if=/var/spool/urandom.dat of=/home/urandom.dat
  4. 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


Geschrieben von root | Permanenter Link | Kategorien: Verwaltung

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


Geschrieben von root | Permanenter Link | Kategorien: Status

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.


Geschrieben von root | Permanenter Link | Kategorien: Status

02.07.2011 15:09

Snapshot-Auslastung

lvs | egrep 'LV|var'
  LV        VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  var       vg1  owi-ao   7,45g                                      
  var.snap  vg1  sri-ao   1,49g var     10,11                        

Zeitlicher Verlauf der Auslastung von 27.06. bis 01.07.2011 Bitte anklicken!


Geschrieben von root | Permanenter Link | Kategorien: Status