Schlagwort: Gentoo

Note to myself: chroot Umgebung betreten

prego Schreib einen Kommentar

Mein Halbwissen ist noch aus Gentoo Zeiten und entsprechend 10 Jahre alt, deswegen muss ich immer nachdenken. Hoffentlich nun bald nicht mehr nachdem es mal konzentriert durch meine Finger geflossen ist.

Beispiel mit boot Partition sda1, root ist sda3

mkdir /mnt/sda3
mount /dev/sda3 /mnt/sda3/
mount /dev/sda1 /mnt/sda3/boot
mount -t proc none /mnt/sda3/proc/
mount -t sysfs sys /mnt/sda3/sys/
mount -o bind /dev /mnt/sda3/dev/
chroot /mnt/sda3 /bin/bash

Eventuell noch die /etc/resolv.conf rüberkopieren wenn das Netzwerk benötigt wird. Swap kann noch mit swapon /dev/sda2 oder so aktiviert werden.

Viele Server updaten 2

prego 2 Kommentare

Vor einigen Tagen hatte ich kurz ueber die Problematik geschrieben, wie man mehrere Debian-Server mit einem Befehl updaten kann. Ich hatte das mit einer kurze for-Schleife in bash gemacht die mir da ausreichte und gesagt ich wuerde mir onall noch einmal genauer angucken.

Heute nacht gabs nun von Debian wieder ein update, libxml2, und mein Nagios blinkte rot. Das hab ich zum Anlass genommen um nun eine „richtige“ Loesung zu implementieren. Es fiel nicht auf onall sondern auf pssh. Der Grund ist ganz einfach, dass pssh bei mir im portage-Tree ist, und onall nicht ;-)

Kurz 2-3 Ueberlegungen vorweg. Ich habe eine ssh-Key Infrastruktur ohne Passwort aufgebaut dafuer. Das ist natuerlich ein Sicherheitsrisiko. Ich empfinde es dennoch als sicher, da die Rechner alle nur in privaten Netzwerken sind bzw., wenn Sie feste IPs haben, via iptables beschraenkt sind. Bei den wichtigsten Servern ist darueber noch der standart SSH-Port veraendert und natuerlich ist der Zugriff ueberall noch per AllowUsers oder AllowGroups (man sshd_config) geregelt… Auch kann ich nur von einem bestimmten Rechner ohne Passwort mit dem entsprechenden Key zugreifen und der ist sicher ;-)

Nun zur eigentlichen Einrichtung:

  • pssh installieren
  • SSH-Key generieren -> ssh-keygen -t dsa -f ~./ssh/myKey
  • den Inhalt von ~./ssh/myKey.pub auf den remote Hosts in ~./ssh/authorized_keys kopieren
  • remote in der ~./ssh/authorized_keys vor den Key einfuegen from=“11.22.33.22″ um den Zugang auf diese IP zu beschraenken
  • remote die /etc/sudoers editieren und folgende Zeile einfuegen:
    USERNAME  HOSTNAME =  NOPASSWD: /usr/bin/aptitude
    wobei USERNAME der Benutzername mit dem key ist und HOSTNAME der hostname des Rechners ist. NOPASSWD muss so als solches stehenbleiben.

Jetzt kann man das ganze einmal testen ob es geklappt hat. Mit ssh USER@IP sollte man sich nun mit dem entsprechenden User auf dem entsprechenden Host ohne Passwort einloggen koennen. Wenn das geklappt hat kann man ausprobieren ob man sudo aptitude upgrade ausfuehren kann ohne Fehlermeldung das man nicht root sei. Geht das beides ohne Probleme nun zu pssh.

Von dem Rechner aus von dem ich nun die Verbindungen zu meinen Servern aufbauen kann muss nun noch einige Kleinigkeiten erledigt werden. Als erstes brauche ich eine Textdatei in der alle hosts drinstehen zu der ich eine Verbindung aufnehmen moechte. Fuer jede IP eine Zeile und bei Bedarf hinter die IP noch mit Doppelpunkt den Port dahinter. Bsp:

11.22.33.44
11.22.33.55:82
11.22.33:66
11.22.33.77:89

Ich habe die Datei einfach in ~/arbeit.ips bzw. eine zweite ~/privsv.ips abgespeichert. Bevor wir nun mit pssh testen koennen ob alles funktioniert bzw. die Updates ausfuehren muss noch der ssh-agent geladen werden mit unserem key. Dafuer einfach in der bash ssh-agent ausfuehren und anschliessend ssh-add. Beides sollte keine Fehlermeldungen ergeben.

Nun ist es soweit. Mit dem Befehl:

pssh -h arbeit.ips -o /tmp/psshtest uptime

koennen wir nun gucken ob alles funktioniert. Es sollte eine Ausgabe kommen ungefaehr so:

me@hostname ~/ $ pssh -h arbeit.ips -o /tmp/psshtest uptime
[1] 09:30:03 [SUCCESS] 11.22.33.44
[2] 09:30:03 [SUCCESS] 11.22.33.55 82
[3] 09:30:03 [SUCCESS] 11.22.33.66
[4] 09:30:03 [SUCCESS] 11.22.33.77 89
me@hostname ~/ $

Der Output des Befehls befindet sich in /tmp/psshtest/11.22.33.* Wenn alles weitere geklappt hat dann happy:

pssh -h arbeit.ips -o /tmp/psshout sudo aptitude upgrade -y

Einige koennen nun ankommen und sagen, dass das doch viel zu kompliziert sei. Mit Sicherheit argumentieren, oder auch damit, dass es doch viel einfachere Tools fuer Debian wie z.B. cron-apt, mit dem ich die Systeme doch auch up-tod-date halten koennte. Meine Antwort darauf ist: Ja, weiss ich. Ja kenne ich. Ich moechte aber immer noch die Updates per Hand einspielen um zu wissen was ich da einspiele.

~/.ssh/config ueberall

prego Ein Kommentar

Vor einiger sehr langer Zeit habe ich mal ueber „Saving SSH options for specific host“ geschrieben. Fuer mich ist die ~/.ssh/config nicht mehr wegzudenken. Bloed ist natuerlich, wenn ich diese Datei auf meinem Rechner zuhause habe, aber auf der Arbeit etc. auch haben moechte. Auf jeden Rechner auf dem ich die Datei haben will raufkopieren, nach jedem Update ueberall neu. Ganz schoen bloed und nervig.

Viel schoener waere es fuer mich, die Datei an einem Ort zu haben, wo sie immer aktuell ist, wo ich immer rankomme, und von wo ich sie mir schnell ziehen kann. Was bietet sich da mehr an als mein Webserver?! Auf der bash ist ein „wget myServer.tld/myFile -O ~/.ssh/config“ sehr schnell geschrieben ;-)

Meine ~/.ssh/config passe ich hauptsaechlich zuhause auf meinem Rechner an. Von daher reicht fuer mich eine simple Moeglichkeit diese Datei schnell und unkompliziert von da auf meinen Webserver zu bekommen. Am besten automatisch, dass ich mich nicht drum kuemmern muss. Hier meine Loesung:

  1. Auf dem Webserver einen rsync-User angelegt und ihn der Gruppe „www-data“ hinzugefuegt, so dass er in meine htdocs schreiben darf , und in die Gruppe „ssh-allow“ hinzugefuegt, so dass er sich auch via SSH einloggen darf (in der /etc/ssh/sshd_config: AllowGroups ssh-allow)
    (adduser myRemoteRsyncUser && adduser myRemoteRsyncUser www-data && adduser myRemoteRsyncUser ssh-allow)
  2. Auf meinem Desktop-PC einen User angelegt und fuer diesen einen ssh-key generiert
    (adduser myLocalRsyncUser && su – myLocalRsyncUser && ssh-keygen -t dsa -f .ssh/myKey)
  3. Die myKey.pub auf dem Websever in die entsprechende authorized_keys gepackt
    (scp /home/myLocalRsyncUser/.ssh/myKey.pub myRemoteRsyncUser@myServer.tld: -> ssh myRemoteRsyncUser@myServer.tld -> cat myKey.pub >> ./ssh/authorized_keys )
  4. Auf meinem lokalen Rechner rsync Befehl zum kopieren der config beim herunterfahren des Rechners automatisch ausfuehren lassen
    (in der /etc/conf.d/local.stop [Gentoo] den Befehl su myLocalRsyncUser -c „rsync -avu -e ssh /path/to/.ssh/config myRemoteRsyncUser@myServer.tld:/var/www/myRemoteSSHConfigFilename“)

Voila. Beim runterfahren wird nun die Datei automatisch auf meinen Webserver kopiert falls sich diese geaendert hat :-) EEEENDLICH!!

Wake On Lan via Speedport W701V

prego 5 Kommentare

Tja, es tut mir leid, ich komm nicht mehr raus… ;-) Aber das ist auch erstma der letzte Post dann (glaube ich) … Es sei denn ich finde noch weitere tolle Sachen die ich mit dem Dingens machen kann. Fuer einige wuerde sicherlich openvpn interessant sein, aber ich brauch das gerade (zumindest hier im Wohnheim) nicht.

Doch zurueck zum WakeOnLan. Fuer diejenigen die nicht wissen was das ist kurz gesagt: Man stellt den Computer ueber das Netzwerk an. Dafuer bedarf es verschiedener Vorraussetzungen die erfuellt sein muessen. Die Netzwerkkarte muss beim herunterfahren des Rechners in einen besonderen Status versetzt werden, die erlaubt, das sogenannte „Magic-Paket“ an sie zu senden. Des weiteren muss der Weg zwischen dem Computer von dem man das Aufwach-Signal schickt und dem Computer, der das Signal erhalten soll, frei sein. Im Klartext: Port 9 UDP muss offen sein und entsprechend weitergeleitet werden.

Da mein Rechner direkt an den Speedport angeschlossen ist, entfaellt die Sicherstellung dieses Weges. Das macht den Speedport zu einem idealen Ausgangspunkt um das WakeOnLan Magic-Paket zu senden. Nun, da ich SSH-Zugriff darauf habe, ist es noch viel besser.

busybox –help verraet mir auch unter Currently defined functions, dass es den Befehl ether-wake gibt. Na denn ma los:

  • cd /var/tmp
  • busybox touch pc-an
  • busybox vi pc-an
  • „i“ – /var/tmp/busybox ether-wake -i eth0 00:11:22:33:44:55 „Esc“ „:wq!“
  • chmod +x pc-an

Nun muss ich nur noch sicherstellen, dass meine Netzwerkkarte auch beim herunterfahren des Rechners in den WakeUp Status versetzt wird. Unter Gentoo-Linux dafuer folgende Punkte beachten:

  • in der /etc/conf.d/rc muss RC_DOWN_INTERFACE=“yes“ auf RC_DOWN_INTERFACE=“no“ geaendert werden.
  • in die /etc/conf.d/local.stop noch die Zeile „usr/sbin/ethtool -s eth0 wol g“ einfuegen und dann Rechner ausschalten

Nun steht dem Spass nix mehr im Weg. Man wie hab ich das vermisst. Frueher ging WOL im ATW, aber seitdem wir die managebaren Switche haben gehts nich mehr, zumindest bei mir nich. Jetzt kann ichs endlich wieder, von meinem Speedport aus. Das haette ich 3 Wochen eher gebraucht. Dann haette ich mir manche Fahrt von der Arbeit ins Wohnheim gespart, nur um eben den Rechner anzumachen, 2-3 Aufzeichnungen/PDFs kopieren und wieder wegzufahren. Cool, freu mich dass es klappt!