Da in der Wörterpresse-Wohnung vier Rechner stehen, und nicht alle einen Monitor zur Verfügung haben, war es natürlich wünschenswert sich per ssh von einem auf den anderen einloggen zu können.

Was ist zu tun? Auf allen Maschinen das Paket openssh-server installieren:

apt-get install openssh-server

Anschließend kann man sich problemlos von jeder Maschine auf eine andere einloggen (Voraussetzung man ist als User dort auch bekannt.) Bei jedem Einloggen ist das Passwort einzugeben. Dafür bzw. dagegen (gegen die Passwortabfrage nämlich) ist natürlich auch ein Kraut gewachsen. Die Methode der Authentifizierung mit keys. Dazu muss man sich zuerst auf jeder Maschine einen Schlüssel erzeugen:

ssh-keygen -t rsa

Dieser Aufruf erzeugt den privaten Schlüssel für die Maschine und den öffentlichen, der auf den jeweiligen Servern vorhanden sein muss. Da ich mit der Zeit mit den ganzen Schlüsseln etwas durcheinander gekommen bin, habe ich die öffentlichen Schlüssel direkt nach dem Erzeugen umbenannt: id_rsa.hostname.pub Wobei hostname der Name des Rechners ist, zu dem der öffentliche Schlüssel gehört. Dieses File wird dann auf sämtliche Server-maschinen verteilt:

scp id_rsa.hostname.pub user@servername:~/.ssh

Anschließend auf dem jeweiligen Server einloggen und das zugehörige File in die Datei authorized_keys mergen:

cat id_rsa.hostname.pub >> authorized_keys

Wichtig: Bei allen Dateien in ~/.ssh sollte ein chmod og-r * durchgeführt werden. Die Files dürfen keinesfalls für Fremde lesbar sein!

Nachdem diese Files also überall verteilt wurden, kann man sich in Zukunft ohne die Eingabe eines Passwortes anmelden.

PS: Die keys können auch noch mit einem Passwort gesichert werden. Und das sollten sie auch. Um dann die erneute Eingabe der Passwörter zu verhindern, gibt es das Werkzeug ssh-agent. Es wird auf der Konsole mit

eval $(ssh-agent)

gestartet. Anschließend mit

ssh-add ~/.ssh/id_rsa

Das Passwort für den entsprechenden Schlüssel hinzufügen. Der Agent verwaltet dann die Passwörter.

Im Grunde geht doch nichts über File-Sharing. Und per mail kann ja kein Mensch eine vernünftige Menge an Datenvolumen austauschen. Also: ein ftp-Server m u s s her!

Gesagt getan: war ja auch nicht weiter schwierig, nachdem ich mich für einen der Daemons entschieden hatte:

apt-get install proftpd

Aber dann fingen die Probleme an. Und zwar mit der Konfiguration. Es sollte ja schließlich auch ein Anonymous-Login möglich werden. ABER: Die Sicherheit! Und bei der Menge an Möglichkeiten, die ich in das Config-File eintragen kann, können sich natürlich auch jede Menge Sicherheitsmängel einstellen. Und da wildes und schnelles Rumprobieren zu keinem sinnvollen Ergebnis geführt hat, werde ich mich in den nächsten Tagen zuerst mal mit dem Linux-Berechtigungskonzept näher auseinandersetzen. Ja, hätte ich schon längst tun sollen *schäm*. Ich werd’s jetzt nachholen, versprochen!

Offene Fragen sind:

• Wie vererbt sich eine Berechtigung des Directories auf die
• darunter liegenden existierenden Files?
• darunter liegenden neu angelegten Files?
• Wer darf wann wo und wie löschen, lesen, ausführen?
• Welche Rechte bekommt eine Datei, die von einem Dienst angelegt wird (proftpd zum Beispiel?)
• Welche Rechte bekommt eine Datei, die von einem User über ftp erstellt wird?
• Wie funktioniert das Umask im Proftpd - Config - File?

Danach werde ich das Config-File mal komplett leeren und Schritt für Schritt aufbauen. Immer eine Zeile hinzufügen und dann die Änderungen nachverfolgen. Erst, wenn ich genau weiß, was dort eigentlich passiert, kann der Server auch für die Öffentlichkeit freigeschaltet werden. (Sollte man ja immer so machen, aber ich mach’ da leider oft halbe Sachen…)

in den letzten zwei Tagen habe ich mich als totaler Linux-Anfänger mal an die zwei Server gewagt, die mir im Augenblick am wichtigsten erschienen

NFS –> für die Freigabe von Shares unter Linux

Samba –> für die Freigabe von Linux-Verzeichnissen an Windows Clients

Beides war erstaunlicherweise leichter zu konfigurieren, als ich zuerst vermutet hatte. Auch wenn die Sicherheit vermutlich noch etwas auf der Strecke geblieben ist.

Zuerst zum NFS-Server:

- das Paket installiert apt-get install nfs-kernel-server

- schauen, ob alle Server laufen mit rpcinfo -p
Es sollte der portmapper, der nfs, der nlockmgr und der mountd sein. War auch so, also schonmal alles Bestens.

Anschließend das File /etc/exports erstellen bzw. bearbeiten. Dort werden die freizugebenden Verzeichnisse eingetragen.
/srv/nfs 192.168.178.*(rw,async)

Danach noch die hosts zulassen (DNS habe ich leider noch nicht zum Laufen gebracht, weil mir da noch Erfahrungen mit der Materie fehlen…)

/etc/hosts.deny ALL : ALL #sicherheitshalber mal alles verbieten…

/etc/hosts.allow portmap : 192.168.178.0/255.255.255.0 : Allow
rpc.mountd : dito

Auf dem Client: mount -t nfs belenus:/srv/nfs /mnt/nfs

Fertig!

Auch der Samba-Server lief nach einigen Konfigurationsschritten. Erstaunlich, das hätte ich so nicht gedacht.

Die entsprechenden Pakete waren per default installiert, so dass kein apt-get notwendig war.

Zuerst in /etc/samba/smbusers die Zuordnung von Linux-Kennung zu Windowskennung durchführen.

Linuxuser = Windowsuser

Anschließend ein Sambapasswort vergeben: smbpasswd (-a) Linuxkennung
(Das (-a) ist beim Neuanlegen eines Sambausers zu verwenden. Bei Kennwortänderung - ohne -a!)

Die Konfiguration des Servers erfolgt in /etc/smb.conf. Hier mein Config-File:

[global]
workgroup = Windows-Workgroupname
security = user
encrypt passwords = yes
username map = /etc/samba/smbusers

[samba]
path = /srv/samba
writeable = true
username = Linuxuser

#Home-Dir of all users is provided by samba
[homes]
writeable = true
browseable = false

Das war’s auch schon. Die Konfigurationsmöglichkeiten sind natürlich noch weit größer. Aber für die Anbindung eines Windows-Clients in meinem privaten Home-Netzwerk ist es so ausreichend. Unter Windows dann im Explorer auf den Server browsen (Netzwerkumgebung –> Workgroup –> Servername –> Verzeichnis). Eine weitere Möglichkeit ist das mounten auf einen Laufwerksbuchstaben:

net use m: \\Servername\Freigabename /user:windowsusername

Problematisch erscheint mir, dass Änderungen von Freigaben, Usernamen und Passwörtern auf dem Samba-Server erst nach Ab- und Anmelden am Windows übernommen werden. Ein erneutes mounten der gleichen Freigabe mit geändertem Usernamen funktioniert nicht. Die Fehlermeldung dazu: “Die angegebenen Anmeldeinformationen stehen mit vorhandenen
Anmeldeinformationen in Konflikt.”

Heute war eigentlich bloss ein wenig Bash-Scripting angesetzt. Ziel sollte es sein, die CGI-Scripte in das CSS der Wörterpresse einzubinden. Das hat aber - mangels HTML und CSS und überhaupt-Kenntnissen nicht geklappt. Naja, habe mich dann entschieden dort nicht weitere Zeit zu investieren. Das einzige öffentliche CGI-Script zeigt also schwarze Schrift auf weißem Grund ohne das zugehörige bunte Drumherum. :-(

Was aber eigentlich spannend war, das sind die Scripte, die passwort-geschützt sind.

Dort kann ich mir
1. das access-log der Wörterpresse
und
2. das error-log der Wörterpresse
anschauen.

Und 3. sämtliche Computer in meinem home-office über das Internet ( mittels Bash-Script via WOL) starten. Das dürfte sich über kurz oder lang bestimmt mal als hilfreich erweisen.

Hier nun kurz zur Vorgehensweise:

a) die (eher schlecht, als recht dokumentierten) Scripte zum Auslesen der Log-Files

#!/bin/bash
echo “Content-type: text/html”
echo -e “\n\n”
echo “< html>< body>”
echo “< b>Logfile des Apachen von” $(date +’%a %b %d’) “< /b>< /br>”
cat /var/log/apache2/access.log | grep “$(date ‘+%d/%b/%Y’)” | while read; do echo $REPLY “< /br>“; done
echo “< /body>< /html>“

Zur Beschreibung:
1. die zuständige bash deklarieren
2. das Logfile ausgeben und greppen, anschließend zeilenweise mit einem html-Zeilenumbruch versehen
Dieser grep-Befehl macht folgendes: Er sucht nach dem aktuellen Datum in der Form: dd/Mon/YYYY. Das Format muss dazu in >’< eingeschlossen werden (Übergabe der Parameter). Der Befehl date in $(), damit er bearbeitet wird. Und das gesamte Konstrukt in >“<, damit ein String draus wird.
b) die Schritte bis zum funktionierenden WOL

1. Im Bios WOL aktivieren
2. mit apt-get install ethtool wakeonlan die notwendigen Programme installieren
3. Als shutdown-Script die Wakeonlan-Funktionalität jedes mal neu sicherstellen

#! /bin/sh
test -f /usr/sbin/ethtool || exit 0

. / lib/ lsb/ init-functions

log_begin_msg “Aktiviere Wake-On-LAN auf eth0…”
ethtool -s eth0 wol g
log_end_msg $?

Dieses shutdown-script in /etc/init.d unterbringen und in das Runlevel 2 /etc/rc2.d soft-verlinken
Dort als shutdown-script markieren: K02aktiviere_wol
Das K heißt, dass das script beim shutdown als zweites ausgeführt wird.
Anschließend ein cgi-script erstellen und verlinken

#!/bin/bash
echo “Content-type: text/html”
echo -e “\n\n”
echo “< html>”
echo “< body>“wakeonlan 00:13:…

echo “< /br> Maschine Belenus will be started. Have some patience…< /br>”
echo “< /body>”
echo “< /html>“

Und: es geht sogar! Einziger Nachteil. Ein mehrfaches Klicken auf den Link führt dazu, dass der Computer nach dem shutdown sofort wieder hochfährt. Scheinbar irren die Magic-Packets noch einige Zeit im LAN rum…

zwei Tools zu diesem Zwecke habe ich immerhin schon gefunden:

Mersenne Primzahlen ausrechnen. Ist ein Distributed Computing Project. Da sind die Maschinen voll ausgelastet und es gibt sogar einen (naja) sinnigen Hintergrund. Und hier steht auch, wie man das ganze als mprimed zum laufen bringt.

Ansonsten gibt es stress. Ein Werkzeug, mit dem eine beliebige Anzahl von Nutzern definiert werden kann, die eine komplexe Rechenoperation ausführen.

apt-get install stress
stress -c 5 &
top

Das liefert dann genau 5 Prozesse mit ca. 20% Systemauslastung. Not bad.

Eine weitere Möglichkeit ist das Tool cpuburn

apt-get install cpuburn
burnK7 &

Das erzeugt genau einen derartigen Prozess. Vorher wird noch laut und deutlich die Warnung auf den Bildschirm geschrieben, dass für die Hardware keine Haftung übernommen wird.

Der Apache ist ja ein sehr fähiger Indianer. Er kann mehrere Domains bedienen. Nur, wie bringt man ihm das bei?
Dafür gibt es das Config-File, in welchem man die Virtual Hosts definieren kann. Bei mir liegt das hier:

/etc/apache2/sites-available/default

Standardmäßig gehen sämtliche Anfragen auf diesen blog. Bei einem passenden Vorsatz wird auf ein alternatives Root-Verzeichnis umgelenkt. Dazu habe ich einfach den einen Eintrag in der default-Datei kopiert und nur zwei Zeilen geändert:

DocumentRoot /var/www/Directory/
Servername www.Directory.lstr8.dynalias.com

Und das war’s dann auch schon.
Das endgültige RootDirectory für den blog konnte ich nicht so einfach ändern, da Wordpress scheinbar schon recht genau weiß, dass alles in dem Verzeichnis /var/www/blog zu finden ist. Also hängt es/sie immer den /blog/ dazwischen, und dann findet sich der Apache nicht mehr zurecht. Nagut. Für’s erste geht es ja auch mit der Umleitung auf http://…/blog, oder?