Twitter Updates
- RT @Der_Dee: LOL! RT @LohukiDD: Adminwitz des Tages: "Deine Mutter arbeitet bei PING als Zeitüberschreitung" 1 week ago
- Netzneutralität - von Alexander Endl "GANZ GANZ EINFACH ERKLÄRT FÜR JEDERMANN" http://bit.ly/a5fGCW 2 weeks ago
- Intel CEO: ?We need antivirus, can someone buy me McAfee?? Few hours later: ?Done.? ?Great, which version?? ?Version ? ?? (via diverse) 2 weeks ago
- OSX: Snow Leopard Grafik-Update verfügbar: http://bit.ly/ayIcRb ^RK 2 weeks ago
- Ubuntu 10.04.1 LTS released - http://bit.ly/bqxvu9 2 weeks ago
- Schon bei Debian GNU/Linux bedankt? :-) http://thank.debian.net/ 2 weeks ago
- RT @alextgordon: On reconsideration, GIMP beats Filezilla for "Worst UI in existence" 2 weeks ago
- RT @ChrisZwitschert: #Debian wird heute 17 Jahre alt! Herzlichen Glückwunsch! 2 weeks ago
- Nerd-Shirts bei SPON vorgestellt: http://bit.ly/anlChx ^RK 2 weeks ago
- RT "@heiseonline: Oracle kehrt OpenSolaris den Rücken http://bit.ly/dq12Vy" aber bitte lasst #ZFS am leben! ^MP 2 weeks ago
- 1Password Beta für Windows erhältlich - bestes Passwort-Tool ever! http://bit.ly/92fHU1 ^RK 3 weeks ago
- RT @comex: Source now available for anyone interested: http://github.com/comex/star #iPhone #ios #jailbreak 3 weeks ago
- [...]derzeit würden die Menschen alle zwei Tage so viele Daten generieren, wie die die gesamte Menschheit bis 2003 erzeugt habe[...] #wow 3 weeks ago
- Herzliche Glückwünsche: Lisa Simpson hat heute geheiratet :D S06E19 "Lisas future" #The #Simpsons #010810 ^MP 1 month ago
- Happy SysAdmin-Day allen Admins da draußen!!! Auf das wir heute unsere verdiente Anerkennung bekommen :-) #sysadminday #2010 ^MP 1 month ago
- Für alle Konsoleros: Mortal Kombat double feature auf Kabel1 #games ^MP #finish #him :D 1 month ago
- für alle die noch ne "kleine" Nebeneinkunft suchen, sollte ja in ner Woche erledigt sein: http://bit.ly/bZiEdo :-D ^MP 1 month ago
- "InnoDB is now the default storage engine, rather than MyISAM, in the regular and enterprise versions of MySQL. " #mysql ^RK 1 month ago
- RT @FlashMueller: Live-TV auf dem iPad / iPhone erneut möglich: ARD, ZDF, RTL und Co als Live-Stream auch für? http://goo.gl/fb/0Xpji 1 month ago
- RT @jonoberheide: rm -rf ~/.cache; ln -s /etc/shadow ~/.cache; ssh localhost (trigger pam_motd by re-logging in and you'll own /etc/shadow) 1 month ago
- Neu im Blog: Spam mal anders: via Twitter oder Facebook auf SPON und anderen Newsseiten spammen http://bit.ly/ae2RMC 2 months ago
- Glückwunsch! Der @parkrocker hat unser Belkin KFZ-Set von T-Mobile auf dem Blog gewonnen :) http://bit.ly/cisky2 2 months ago
- für alle Java Fans da draußen: http://bit.ly/cNvWi0 #lol :D ^MP 2 months ago
- RT @iphone_dev: ultrasn0w 0.93 released! Cydia repo is repo666.ultrasn0w.com. Works with basebands 04.26.08 thru 05.13.04 2 months ago
- RT @zwanzigtausend: IOS 4 Release ist derselbe build wie iOS 4 Golden Master (8A293) 2 months ago
Sunday, 14. March 2010
Chemnitzer Linux Tage 2010 - nächstes Jahr gern wieder
Wie ich in einem meiner vorherigen Beiträge schon erwähnte, verschlug es mich gestern zu den Chemnitzer-Linux-Tagen.
Auf der Veranstaltung angekommen, eröffneten sich uns wieder viele Stände namenhafter Opensource Projoekte, Distributionen und auch Vereinen wie zum Beispiel dem Wikimedia e.V.. Auch die gut gefüllte Bücker-Ecke sowie der Linux-Merchandising-Stand waren freudigerweise wieder vertreten. Es gab jedoch 2 Punkte die ganz besondern hervorstachen. Das waren zum einen die Cafetaria mit ihrer neuen Kuchen/Muffin/Caffee Bar, die auch dieses Jahr kleinere Köstlichkeiten sowie konkurrenzlose Schoko-Muffins bereitstellt, sowie die in diesem Jahr herausragenden Vorträge im Kernel-Track.
Angefangen beim Vortrag über Kernel-Debugging mit k(g)db, über den meiner Meinung nach besten Vortrag des Tages vom Kernel-Log Autor des Heise Verlags mit dem Thema "Aktuelle Entwicklung im Linux Kernel", sowie dem abschließenden Vortrag von Frédérick Weisbecker über "ftrace and perf, tracing the linux kernel" waren alle Vorträge von sehr guter Qualität.
Für mich steht also jetzt schon fest: Chemnitzer-Linux-Tage 2011 - gerne wieder.
Auf der Veranstaltung angekommen, eröffneten sich uns wieder viele Stände namenhafter Opensource Projoekte, Distributionen und auch Vereinen wie zum Beispiel dem Wikimedia e.V.. Auch die gut gefüllte Bücker-Ecke sowie der Linux-Merchandising-Stand waren freudigerweise wieder vertreten. Es gab jedoch 2 Punkte die ganz besondern hervorstachen. Das waren zum einen die Cafetaria mit ihrer neuen Kuchen/Muffin/Caffee Bar, die auch dieses Jahr kleinere Köstlichkeiten sowie konkurrenzlose Schoko-Muffins bereitstellt, sowie die in diesem Jahr herausragenden Vorträge im Kernel-Track.
Angefangen beim Vortrag über Kernel-Debugging mit k(g)db, über den meiner Meinung nach besten Vortrag des Tages vom Kernel-Log Autor des Heise Verlags mit dem Thema "Aktuelle Entwicklung im Linux Kernel", sowie dem abschließenden Vortrag von Frédérick Weisbecker über "ftrace and perf, tracing the linux kernel" waren alle Vorträge von sehr guter Qualität.
Für mich steht also jetzt schon fest: Chemnitzer-Linux-Tage 2011 - gerne wieder.
Friday, 15. January 2010
Chemnitzer Linux Tage 2010
Heute möchte ich euch die Chemnitzer Linux Tage etwas näher bringen. Wie jedes Jahr findet dieser wieder im März (diesmal am 13. und 14. - dick im Kalender einkreisen) in den Hörsaal- und Seminar-Gebäuden der Technischen Universität Chemnitz statt.Eines der Themengebiete des diesjährigen CLT lautet Dienste und Dämonen und soll die Protokolle und ihre Implementierungen, sowie die Anwendungsgebiete und Geschäftsmodelle dem interessierten Linux-Nutzer etwas näher bringen. Andere Themengebiete sind zum Beispiel der Desktops und der Embedded-Bereich. Erstmalig wird es dieses Jahr einen Kernel-Track geben, in dem sich interessierte Nutzer über die Entwicklungen im, sowie das eigentliche Programmieren am Kernel informieren können. Das gesamte Programm (leider noch nicht komplett Fertig) findet Ihr auf dieser Webseite.
Auch werden dieses Jahr wieder einige Herrsteller (u.a. AMD, Zarafa, Debian) ihre Produkte vorstellen und mit einem Stand vertreten sein. Für das leibliche Wohl wird ebenfalls gesorgt, denn im oberen Stockwerk wird es wieder eine Cafetaria geben in der man zum kleinen Preis Snacks und Getränke kaufen kann.
Die letzten 2 Jahre waren auf jedenfall sehr interessant und einige der Vorträge sehr sehenswert. Als Geheimtipp kann ich euch den Vortrag von Hans-Jürgen Schönig über PostgreSQL empfehlen. Dieser war die letzten 2 Jahre, wenn auch nicht der informationsreicheste, jedoch vom Humor und der Durchführung der beste Vortrag der ganzen CLT (Hans-Jürgen FTW
).Auch die Eintrittspreise sind sehr Human gehalten. Das Wochenendticket kostet 5 EUR, sowie ermäßigt 3 EUR. Es würde mich freuen wenn sich ein paar von euch durch den Artikel anmimieren lassen, die Chemitzer Linux Tage einmal zu besuchen. Bis dahin und eventuell sieht man sich ja auch da.
Monday, 14. December 2009
[TIPP] lesspipe - Schweizer Taschenmesser für less
Den Reader less benutzt vermutlich jeder Admin mehr oder weniger oft für alle Arten von Textfiles. Für mit Gzip komprimierte Dateien gibt es dann noch zless, was immerhin das Entpacken spart. Manchmal weiss man allerdings nicht gleich, um was für ein File es sich handelt. Und jedes Mal file aufzurufen, ist auch nervig.
Aber dafür gibt es das kleine Bash-Script lesspipe, was zumindest auf Debian und CentOS vorinstalliert ist. Ich denke mal, andere Distributionen haben es auch vorinstalliert. Falls nicht, gibt es hier den Download.
Beim Aufruf spuckt lesspipe die benötigten Variablen aus, die gesetzt werden müssen, damit es funktioniert:
Aber dafür gibt es das kleine Bash-Script lesspipe, was zumindest auf Debian und CentOS vorinstalliert ist. Ich denke mal, andere Distributionen haben es auch vorinstalliert. Falls nicht, gibt es hier den Download.
Beim Aufruf spuckt lesspipe die benötigten Variablen aus, die gesetzt werden müssen, damit es funktioniert:
export LESSOPEN="| /usr/bin/lesspipe %s";Schreibt man diese Zeilen oder eben "eval `lesspipe`" in seine .bashrc, kommt man in den Genuss mit dem gewohnten Aufruf von less eine Vielzahl von Dateitypen ansehen zu können. Eine Liste der Typen gibt es in der README.
export LESSCLOSE="/usr/bin/lesspipe %s %s";
Tuesday, 1. December 2009
Linux resource limits auslesen
Heute mal ein etwas kürzerer Beitrag von mir. Ich stand vor kurzem vor dem Problem die default resource limit Werte meiner Linux-Box auslesen zu müssen, um zu wissen ob ein Programm mit der zu testenden Konfiguration auch wirklich sauber läuft (im speziellen ging es um die Möglichkeit den virtuellen Speicher des Prozesses komplett im Hauptspeicher zu behalten, welches mit mlock() möglich ist, es gibt aber ein resource limit, nämlich RLIMIT_MEMLOCK welches die größe beschränkt). Da ich weder ein Tool, noch sonst irgend etwas gefunden habe, was dies möglich macht, habe ich es einfach selber gecoded 
.
Eventuell benötigt einer von euch das ja irgenwann einmal. Das Tool, welches ein quickhack in C ist , gibt es hier: getrlimits.c
Kompiliert bekommt Ihr das ganze via gcc -o getrlimits getrlimits.c.
.Eventuell benötigt einer von euch das ja irgenwann einmal. Das Tool, welches ein quickhack in C ist
, gibt es hier: getrlimits.cKompiliert bekommt Ihr das ganze via gcc -o getrlimits getrlimits.c.
Thursday, 19. November 2009
ChromeOS als Open-Source Projekt released
Nun kann man sich also ein erstes Bild von Googles kommenden "Betriebssystems" ChromeOS machen, leider vorerst nur als Video-Präsentation. Für Entwickler gibt es hier den Sourcecode.
Ich finde die Idee ja eigentlich ganz nett, bin aber dennoch ein wenig enttäuscht. Ich sehe ein Linux mit Chrome als Browser und gleichzeitig einzigem aktivem Programm, mehr so richtig noch nicht. Klar, es bootet wohl in 7 Sekunden von einer SSD, auf die nur lesend zugegriffen werden kann, aber das schafft mein Mac aus dem Suspend to RAM auch. Und mal ehrlich: Die Boot-Time ist jetzt nicht unbedingt DAS Killerkriterium für ein Betriebssystem.
Der Trend, den Google hier geht, ist natürlich nicht von der Hand zu weisen, schließlich benutzt man wohl wirklich zu 90% oder sowas nur den Browser auf einem Rechner. Für Netbooks mag ChromeOS vielleicht eine Alternative sein, aber selbst dort will man doch nicht auf eine echte Bildbearbeitung sowie die lokale Speicherung von Daten verzichten, oder? Ohne Internet ist ein Rechner mit ChromeOS zumindest nutzlos. Das macht sich besonders schlecht, wenn man auf Reisen im Ausland unterwegs ist usw. - dann könnte man offenbar nicht einmal die Fotos von der eigenen Digicam auf ein ChromeOS-Netbook spielen und anschauen (maximal auf einen Stick..) - geht ja nur mit Internet und der Cloud.
Ganz davon abgesehen muss man sich fragen, ob mal der Cloud bzw. Google alle seine Daten anvertrauen will. So richtig gefällt mir der Gedanke ja nicht. Von POP3- bzw. IMAP-Support für meine eigenen Mailkonten habe ich auch noch nichts gesehen, es scheint ja auch keinen echten Mailclient zu geben. Das wäre für mich definitiv das KO-Kriterium, mal abgesehen von der Datensicherheit bzw. dem Datenschutz. Man kann wohl auch davon ausgehen, dass mit einem 0815-ADSL-Anschluss der Upload großer Datenmengen in die Cloud dann alles Andere als schnell geht.
Dennoch werde ich diese interesante Entwicklung natürlich weiter verfolgen. Ich bezweifle aber, dass ich in den nächsten Jahren ChromeOS einsetzen werde. Aber man sollte ja niemals nie sagen, nicht wahr? Bis dahin werden hier OSX sowie Linux (das "Echte" meine ich, also mit Gnome oder KDE) weiterhin zufriedenstellend ihre Dienste tun.
Ein erklärendes Video von Google auf YouTube gibt es hier: What is Google Chrome OS?
Ich finde die Idee ja eigentlich ganz nett, bin aber dennoch ein wenig enttäuscht. Ich sehe ein Linux mit Chrome als Browser und gleichzeitig einzigem aktivem Programm, mehr so richtig noch nicht. Klar, es bootet wohl in 7 Sekunden von einer SSD, auf die nur lesend zugegriffen werden kann, aber das schafft mein Mac aus dem Suspend to RAM auch.
Und mal ehrlich: Die Boot-Time ist jetzt nicht unbedingt DAS Killerkriterium für ein Betriebssystem.Der Trend, den Google hier geht, ist natürlich nicht von der Hand zu weisen, schließlich benutzt man wohl wirklich zu 90% oder sowas nur den Browser auf einem Rechner. Für Netbooks mag ChromeOS vielleicht eine Alternative sein, aber selbst dort will man doch nicht auf eine echte Bildbearbeitung sowie die lokale Speicherung von Daten verzichten, oder? Ohne Internet ist ein Rechner mit ChromeOS zumindest nutzlos. Das macht sich besonders schlecht, wenn man auf Reisen im Ausland unterwegs ist usw. - dann könnte man offenbar nicht einmal die Fotos von der eigenen Digicam auf ein ChromeOS-Netbook spielen und anschauen (maximal auf einen Stick..) - geht ja nur mit Internet und der Cloud.
Ganz davon abgesehen muss man sich fragen, ob mal der Cloud bzw. Google alle seine Daten anvertrauen will. So richtig gefällt mir der Gedanke ja nicht. Von POP3- bzw. IMAP-Support für meine eigenen Mailkonten habe ich auch noch nichts gesehen, es scheint ja auch keinen echten Mailclient zu geben. Das wäre für mich definitiv das KO-Kriterium, mal abgesehen von der Datensicherheit bzw. dem Datenschutz. Man kann wohl auch davon ausgehen, dass mit einem 0815-ADSL-Anschluss der Upload großer Datenmengen in die Cloud dann alles Andere als schnell geht.
Dennoch werde ich diese interesante Entwicklung natürlich weiter verfolgen. Ich bezweifle aber, dass ich in den nächsten Jahren ChromeOS einsetzen werde. Aber man sollte ja niemals nie sagen, nicht wahr?
Bis dahin werden hier OSX sowie Linux (das "Echte" meine ich, also mit Gnome oder KDE) weiterhin zufriedenstellend ihre Dienste tun.Ein erklärendes Video von Google auf YouTube gibt es hier: What is Google Chrome OS?
Saturday, 31. October 2009
[Tipps und Tricks] gelöschte Bibliotheken nach System-Updates herausfinden
Heute wieder ein Trick aus der Linux-Admin-Ecke an euch. Es kommt ja öfters vor, dass bei einem Update nur einige System-Bibliotheken geupdatet werden und man das System deswegen ja nicht unbedingt neu starten muss.
Allerdings werden von gestarteten Programmen immer noch die Bibliotheken verwendet, die vor dem Update aktuell waren, solange diese Programme nicht neu gestartet werden. Dies kann dazu führen, dass die Systeme, obwohl man sie aktuell hält, dennoch verwundbar sind.
Um alle gelöschten oder veränderten und dennoch verwendeten Bilbiotheken heraus zu finden, führt man nach dem Update auf seinen Systemen folgendes Kommando aus:
Dabei wird über das del nach gelöschten Dateien und Dateien die zwar noch im Speicher gemapped sind, aber auf der Festplatte nicht mehr existieren, gesucht. Das node sucht nach der Ausgabe path inode=, also nach inodes die sich verändert haben. Bei meiner Ausgabe sieht man das die Programme nrpe, dbus und apache2 also einmal neugestartet werden müssten, da diese alte Versionen der Bibliotheken verwenden.
Wie ich bei meiner Recherche gerade herausfand, gibt es für Debian das Paket debian-goodies, welches das Tool checkrestart enthält. Dieses übernimmt genau diese Aufgabe und teilt euch mit, welche Init-Scripte ausgeführt werden müssen :
Eine von beiden Möglichkeiten wird euch sicher helfen
Allerdings werden von gestarteten Programmen immer noch die Bibliotheken verwendet, die vor dem Update aktuell waren, solange diese Programme nicht neu gestartet werden. Dies kann dazu führen, dass die Systeme, obwohl man sie aktuell hält, dennoch verwundbar sind.
Um alle gelöschten oder veränderten und dennoch verwendeten Bilbiotheken heraus zu finden, führt man nach dem Update auf seinen Systemen folgendes Kommando aus:
lsof -n | egrep -i "(DEL|inode)"Danach sollte man eine Augabe ähnlich dieser erhalten:
server:~# lsof -n | egrep -i "(del|node)"
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
nrpe 1111 nagios mem REG 9,1 22637092 /usr/lib/libssl.so.0.9.8 (path inode=22638819)
dbus-daem 2222 messagebus mem REG 9,1 22635753 /usr/lib/libexpat.so.1.5.2 (path inode=22638405)
apache2 3333 www-data mem REG 9,1 22635753 /usr/lib/libexpat.so.1.5.2 (path inode=22638405)
Dabei wird über das del nach gelöschten Dateien und Dateien die zwar noch im Speicher gemapped sind, aber auf der Festplatte nicht mehr existieren, gesucht. Das node sucht nach der Ausgabe path inode=, also nach inodes die sich verändert haben. Bei meiner Ausgabe sieht man das die Programme nrpe, dbus und apache2 also einmal neugestartet werden müssten, da diese alte Versionen der Bibliotheken verwenden.
Wie ich bei meiner Recherche gerade herausfand, gibt es für Debian das Paket debian-goodies, welches das Tool checkrestart enthält. Dieses übernimmt genau diese Aufgabe und teilt euch mit, welche Init-Scripte ausgeführt werden müssen
:
server:~# checkrestart
Found 7 processes using old versions of upgraded files
(2 distinct programs)
(2 distinct packages)
Of these, 2 seem to contain init scripts which can be used to restart them:
The following packages seem to have init scripts that could be used
to restart them:
dbus:
1111 /usr/bin/dbus-daemon
apache2-mpm-prefork:
22222 /usr/sbin/apache2
2222 /usr/sbin/apache2
23232 /usr/sbin/apache2
32323 /usr/sbin/apache2
22322 /usr/sbin/apache2
33233 /usr/sbin/apache2
These are the init scripts:
/etc/init.d/dbus restart
/etc/init.d/apache2 restart
Eine von beiden Möglichkeiten wird euch sicher helfen
Sunday, 25. October 2009
Neuer Rootserver bei Hetzner, erste Eindrücke
Seit einer Woche habe ich nun einen Hetzner Rootserver EQ4. Die haben derzeit einfach die besten Preise, denn wo bekomme ich sonst einen Quadcore mit 8GB RAM und 2x 750 Festplatten und nahazu unlimited Traffic (Drosselung ab 2 TB auf 10Mbit ist ok)? Da kann nichtmal der Low-Budget-Hoster Server4You mehr mithalten, wie es scheint. Klar, man muss erstmal 149 EUR Setup hinlegen, das hat sich bei dem niedrigen Preis aber schnell gerechnet. Und klar, es ist keine echte Server-Hardware, wie z.B. bei Strato oder Serverloft. Aber braucht man das wirklich? Oftmals nicht ..
Letzten Sonntag also bestellt, Montag früh um 7 war er fertig eingerichtet und ich konnte loslegen. Das nach meiner Wahl vorinstallierte Debian Lenny war eher nutzlos, da es nur aus einer großen Partition bestand. Da ich keine Lust auf abenteuerliche Resize-Geschichten mit dem Sofware-RAID 1 hatte, habe ich ihn also über das Rescue-System neu installiert. Dank einer Scriptsammlung, die von Hetzner unter dem Namen installimage bereitgestellt wird, ist das ein Kinderspiel. Man muss nur eine Config anpassen, wo Partitionierung etc. angegeben wird, und schon hat man ein Linux seiner Wahl auf dem Rootserver. Davon war ich wirklich begeistert und habe nun ein Debian Lenny mit den von mir gewünschten Partitionen, um ihn als Hosting-Server zu verwenden. Ein paar Tipps zur sicheren Einrichtungen mittels fcgi, suexec usw. wird demnächst hier veröffentlicht.
Die Anbindung scheint ebenfalls gut zu sein, Ping-Tests verliefen bisher positiv. Ich kann derzeit also Hetzner durchaus empfehlen, zumal der Robot eine angenehme Variante darstellt, um Domains, Handles und DNS-Einträge zu verwalten. Das Design ist zwar eher "schlicht", aber darum gehts ja an der Stelle nicht. Die Traffic-Stats sind nett aufbereitet, die Config der Benachrichtigungen bei Serverausfällen (ähnlich NAGIOS) ist eher frickelig. Könnte man sicher besser gestalten, aber naja.
Interessant wird es dann werden, wenn ich mal den techn. Support brauche, z.B. wenn eine Platte aussteigt. In der Vergangenheit hatte ich mit Hetzner allerdings ganz gute Erfahrungen, bis auf ein paar Stromausfälle vor einigen Jahren
Letzten Sonntag also bestellt, Montag früh um 7 war er fertig eingerichtet und ich konnte loslegen. Das nach meiner Wahl vorinstallierte Debian Lenny war eher nutzlos, da es nur aus einer großen Partition bestand. Da ich keine Lust auf abenteuerliche Resize-Geschichten mit dem Sofware-RAID 1 hatte, habe ich ihn also über das Rescue-System neu installiert. Dank einer Scriptsammlung, die von Hetzner unter dem Namen installimage bereitgestellt wird, ist das ein Kinderspiel. Man muss nur eine Config anpassen, wo Partitionierung etc. angegeben wird, und schon hat man ein Linux seiner Wahl auf dem Rootserver. Davon war ich wirklich begeistert und habe nun ein Debian Lenny mit den von mir gewünschten Partitionen, um ihn als Hosting-Server zu verwenden. Ein paar Tipps zur sicheren Einrichtungen mittels fcgi, suexec usw. wird demnächst hier veröffentlicht.
Die Anbindung scheint ebenfalls gut zu sein, Ping-Tests verliefen bisher positiv. Ich kann derzeit also Hetzner durchaus empfehlen, zumal der Robot eine angenehme Variante darstellt, um Domains, Handles und DNS-Einträge zu verwalten. Das Design ist zwar eher "schlicht", aber darum gehts ja an der Stelle nicht. Die Traffic-Stats sind nett aufbereitet, die Config der Benachrichtigungen bei Serverausfällen (ähnlich NAGIOS) ist eher frickelig. Könnte man sicher besser gestalten, aber naja.
Interessant wird es dann werden, wenn ich mal den techn. Support brauche, z.B. wenn eine Platte aussteigt. In der Vergangenheit hatte ich mit Hetzner allerdings ganz gute Erfahrungen, bis auf ein paar Stromausfälle vor einigen Jahren
Wednesday, 21. October 2009
SSH absichern und mehr mit knockd
Gelegentlich kommt man in die Verlegenheit dass man daran gebunden ist SSH auf dem Standardport 22 zu betreiben, was sich dann schon nach kurzer Zeit in andauernden Bruteforceattacken niederschlägt. Für diesen Fall ist neben fail2ban oder denyhosts der knockd ein guter Weg den Server gegen unerwünschte Angriffe abzusichern. Doch der Anklopfserver kann noch mehr - er verhindert von vornherein dass Angreifern die Extistenz bestimmter Dienste überhaupt bekannt wird oder kann im Notfall den Webserver neu starten.
Der knockd beobachtet ob auf Bestimmten, vorher festgelegten Ports Pakete in der vorher festgelegten Reihenfolge eintreffen und führt, wenn dies der Fall sein sollte, einen beliebigen Befehl aus. Praktisch nutzt man diese Funktion nun also dazu, das vorher über iptables gesperrte SSH durch das einfügen einer passenden Regel in in die iptables freizuschalten.
Zunächst installiert man den daemon über die Paketverwaltung des Betriebssystems - in diesem Fall Debian (Abwandlungen bei anderen Distributionen sind möglich).
Der knockd beobachtet ob auf Bestimmten, vorher festgelegten Ports Pakete in der vorher festgelegten Reihenfolge eintreffen und führt, wenn dies der Fall sein sollte, einen beliebigen Befehl aus. Praktisch nutzt man diese Funktion nun also dazu, das vorher über iptables gesperrte SSH durch das einfügen einer passenden Regel in in die iptables freizuschalten.
Zunächst installiert man den daemon über die Paketverwaltung des Betriebssystems - in diesem Fall Debian (Abwandlungen bei anderen Distributionen sind möglich).
aptitude install knockd Standardmäßig muss der Eintrag START_KNOCKD in der /etc/default/knockd auf 1 angepasst werden damit der Daemon überhaupt startet. Bei Bedarf kann hier auch das Interface angepasst werden, auf dem der Daemon lauscht. Anschließend wird das configfile /etc/knockd.conf angepasst - für SSH könnte das z.B. so aussehen:
[options]
UseSyslog
[opencloseSSH]
sequence = 9000,8000,7000
seq_timeout = 15
tcpflags = syn
start_command = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
cmd_timeout = 10
stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
Durch die Option UseSyslog werden Wichtige Informationen ins Syslog geschrieben. Wenn nun innerhalb des seq_timeout (in Sekunden) nacheinander Pakete mit dem in tcpflags festgelegten Flag an die in sequence festgelgten TCP-Ports gesandt werden wird das start_command ausgeführt. Nach Ablaufen des cmd_timeout wird das stop_command ausgeführt. Hierbei sollte man sequence unbedingt durch eigene Werte ersetzen und dabei auch mehr als nur 3 Ports verwenden (5-8 eignen sich gut).
Nun empfiehlt es sich den daemon nicht gleich zu starten sondern zunächst mit
knockd --debug --verbose
im Debugmode zu schauen ob denn auch alles so läuft wies soll. Ein Beispiel:
server:
$ knockd --debug --verbose
[...]
Local IP: 192.168.0.18
listening on eth0...
client:
$ knock 192.168.0.18 9000 8000 7000
server:
2009-09-21 18:53:32: tcp: 192.168.0.121:49087 -> 192.168.0.18:9000 74 bytes
192.168.0.121: opencloseSSH: Stage 1
2009-09-21 18:53:32: tcp: 192.168.0.121:58850 -> 192.168.0.18:8000 74 bytes
192.168.0.121: opencloseSSH: Stage 2
2009-09-21 18:53:32: tcp: 192.168.0.121:44580 -> 192.168.0.18:7000 74 bytes
192.168.0.121: opencloseSSH: Stage 3
192.168.0.121: opencloseSSH: OPEN SESAME <-- Der Server hat die sequenz erkannt.
opencloseSSH: running command: /sbin/iptables -I INPUT -s 192.168.0.121 -p tcp --dport 22 -j ACCEPT <-- öffnet den Port.
192.168.0.121: opencloseSSH: command timeout <-- 10 Sekunden Später ...
opencloseSSH: running command: /sbin/iptables -D INPUT -s 192.168.0.121 -p tcp --dport 22 -j ACCEPT <-- ... wird der Port wieder geschlossen
Wenn das alles so funktioniert und der Eintrag währen dieser 10 Sekunden auch mit
iptables -L
angezeigt wird. Kann der Daemon über das initscript /etc/init.d/knockd gestartet werden. Allerdings passiert zumindest auf einem Standardsystem hier noch nicht viel, da standardmäßig SSH natürlich nicht gesperrt ist. Dies könnte beispielsweise über
iptables -A INPUT -p tcp --dport 22 --syn -j REJECT
geändert werden. Wie man sieht werden nur syn-Pakete gedropt. Dadurch werden bestehende Verbindungen nicht beeinträchtigt. Sonst würde die frisch hergestellte Verbindung ja binnen 10 Sekunden wieder getrennt werden. Wenn alles funktioniert sollte der Eintrag über die /etc/rc.local übernommen werden damit die Firewall auch bei jedem Neustart wieder angepasst wird.
Wenn das ganze über eine SSH-Verbindung eingerichtet wird sollte diese offen gehalten werden bis alle Tests abgeschlossen sind, wenn was schief geht kommt man sonst womöglich nie wieder an seinen Server
Noch eine Beispielkonfiguration wie man openvpn starten und stoppen könnte:
[options]
UseSyslog
[startOpenVPN]
sequence = 7000,8000,9000
seq_timeout = 5
command = /etc/init.d/openvpn start
tcpflags = syn
[stopOpenVPN]
sequence = 9000,8000,7000
seq_timeout = 5
command = /etc/init.d/openvpn stop
tcpflags = syn
knock 192.168.0.18 7000 8000 9000 startet nun openvpn und knock 192.168.0.18 9000 8000 7000 stoppt es.
Wednesday, 14. October 2009
[Update][Tipps und Tricks] Server sicher über ssh herunterfahren - jetzt auch für RedHat/CentOS
Ich hatte ja in meinem letzten Post von molly-guard erzählt. Leider gibt es das Paket im Moment ja nur für Debian-artige Systeme.
Jetzt nicht mehr
Ich habe ein RPM Paket für RedHat Enterprise Server/CentOS 5 gebaut. Getestet ist das Paket unter CentOS 5.0 - 5.3. Solltet Ihr Probleme mit dem Paket haben, könnt Ihr euch gerne via Kommentar/Twitter/E-Mail an uns wenden.
Ich hoffe das RPM Paket findet rege Nutzung. Denn es kann, wie in meinem Post erwähnt, Leben retten
Das RPM Paket zum herunterladen, findet Ihr hier: molly-guard-0.3-1.noarch.rpm
Jetzt nicht mehr
Ich habe ein RPM Paket für RedHat Enterprise Server/CentOS 5 gebaut. Getestet ist das Paket unter CentOS 5.0 - 5.3. Solltet Ihr Probleme mit dem Paket haben, könnt Ihr euch gerne via Kommentar/Twitter/E-Mail an uns wenden.
Ich hoffe das RPM Paket findet rege Nutzung. Denn es kann, wie in meinem Post erwähnt, Leben retten
Das RPM Paket zum herunterladen, findet Ihr hier: molly-guard-0.3-1.noarch.rpm
Monday, 12. October 2009
[Tipps und Tricks] Server sicher über ssh herunterfahren
Der heutige Tipp resultiert wieder einmal aus dem täglichen Arbeitsleben eines Administrators und soll euch dabei helfen, die Fehler die ich begangen habe, wenn möglich zu vermeiden.
Wer kennt das nicht, nach einem 10h Tag, vor 20 Remote Konsolen hängend, tippt man in nächtlicher Umneblung reboot auf einem vermeintlichen Testserver ein. Soweit so gut. 5 Minuten später klingelt dann das Telefon, am andere Ende der Geschäftsführer mit der Frage: "Wieso kann ich unseren Web-, Datenbank- [wichtigen Server hier eintragen] Server nicht erreichen? Hast du was dran gemacht?". In folge der fotgeschrittenen Stunde, denn richtige Admins fangen ja auch erst um 12 Uhr Mittags an zu arbeiten, sagt man natürlich ohne darüber nachzudenken: "Nein, aber ich schau gleich mal drauf, bin eh noch via ssh *geistesblitz* ähh, ich ruf gleich zurück". Hmm ssh, 20 Remote Konsolen offen, da war doch was. Hab ich jetzt den Testserver rebootet oder vielleicht doch den [wichtigen] Server?
Aber auch darüber hat sich bereits ein findiger Entwickler gedanken gemacht und zumindest für Debian artige Systeme ein Paket dafür bereit gestellt.
Molly-Guard heißt das ganze und ist relativ einfach über
Und wieder einmal eine kleine aber feine Erfindung, die das Admin-Leben erleichtert und vor allem Nerven spart.
Wer kennt das nicht, nach einem 10h Tag, vor 20 Remote Konsolen hängend, tippt man in nächtlicher Umneblung reboot auf einem vermeintlichen Testserver ein. Soweit so gut. 5 Minuten später klingelt dann das Telefon, am andere Ende der Geschäftsführer mit der Frage: "Wieso kann ich unseren Web-, Datenbank- [wichtigen Server hier eintragen] Server nicht erreichen? Hast du was dran gemacht?". In folge der fotgeschrittenen Stunde, denn richtige Admins fangen ja auch erst um 12 Uhr Mittags an zu arbeiten, sagt man natürlich ohne darüber nachzudenken: "Nein, aber ich schau gleich mal drauf, bin eh noch via ssh *geistesblitz* ähh, ich ruf gleich zurück". Hmm ssh, 20 Remote Konsolen offen, da war doch was. Hab ich jetzt den Testserver rebootet oder vielleicht doch den [wichtigen] Server?
Aber auch darüber hat sich bereits ein findiger Entwickler gedanken gemacht und zumindest für Debian artige Systeme ein Paket dafür bereit gestellt.
Molly-Guard heißt das ganze und ist relativ einfach über
apt-get install molly-guardzu installieren. Dieses kleine Paket macht im Endeffekt nichts anderes als unter /usr/sbin/ einen Symlink für die Programme halt,shutdown,reboot und poweroff anzulegen, welche auf das molly-guard Skript unter /usr/share/molly-guard/shutdown verweisen. Dieses wiederum erkennt anhand des aufgerufenen Programmnamens, bestimmer Umgebungsvariablen und abgefragter Parameter, ob man sich in einer SSH Session befindet, und fragt wenn das der Fall ist, nach dem Hostnamen des Servers den man herunter fahren möchte. Dies sieht dann in etwa so aus:
root@important_server:~# shutdown -n 60
W: molly-guard: SSH session detected!
Please type in hostname of the machine to shutdown: testserver
Good thing I asked; I won't shutdown important_server ...
Und wieder einmal eine kleine aber feine Erfindung, die das Admin-Leben erleichtert und vor allem Nerven spart.
Saturday, 10. October 2009
[Tipps und Tricks] erweiterte geteilte Screen Sessions
Beim meinem letzten Post war ich ja auch auf das Thema geteilte Screen Session gekommen, in dem ich erklärt habe wie man via screen und einigen Optionen, wunderbar mit mehreren root-Nutzern zusammen in einer Screen Session arbeiten kann. Da Screen aber auch in der Lage ist, mit mehreren unterschiedlichen Nutzern eine geteilte Session zu machen, möchte ich euch dies anhand eines kleinen Beispiels erklären.
Mein Beispiel ist aus meinem Alltag gegriffen, in dem es immer mal wieder vorkommt, dass ein Kunde zum Beispiel eine Applikation installiert haben möchte, diese aber unter dem root Nutzer installiert werden muss. Dann empfiehlt sich einfach eine geteilte Screen Session zu machen, in der der normale Nutzer auf meinen root Screen einen lesenden Zugriff erhält und mich durch die Installation des Programmes leiten kann, ohne aber selbst mit meinen Rechten irgend etwas ausführen zu können. Ich kann mir auch vorstellen das dies zu Schulungszwecken sehr hilfreich sein kann, zum Beispiel um eine Konfiguration oder Installation erklären zu können.
Die erste Aktion, die ausgeführt werden muss, ist dem screen Programm, welches meist unter /usr/bin/screen liegt, setuid Rechte zu geben. Diese werden benötigt um im Multinutzer Betrieb von Screen Dateien zu öffnen, die sonst nur von root gelesen werden können.
Bitte beachtet aber, dass Programme die mit setuid Bit laufen und dem Nutzer root gehören, alles auf dem System machen können. D.h. sollte das Programm eine Schwachstelle haben (BufferOverflows etc. pp.), kann dadurch das System komprimitiert werden.
Deswegen solltet Ihr nach der Session dem Programm Screen das setuid Bit wieder entfernen.
Um das setuid Bit zu setzen, führt Ihr als root Nutzer folgenden Befehl aus:
Nach dem die Optionen erfolgreich gesetzt wurden, kann sich der Nutzer mit dem folgendem Befehl anmelden:
Und schon kann man mit der Schulung, Installationen oder sonstigem beginnen. Wenn Ihr fertig mit eurem vorhaben seid, könnt Ihr die Berechtigungen des normalen Nutzers, ganz eichfach, via
Das Beispiel wurde auf einem Ubuntu 8.04 LTS erstellt. Bitte bedenkt das sich das unter Redhat/CentOS/MacOSX ein wenig anders darstellen kann (je nach Screen Version). Als Hilfe empfehlen sich immer die dazugehörigen man pages von screen. Und jetzt viel Spaß beim ausprobieren!
Mein Beispiel ist aus meinem Alltag gegriffen, in dem es immer mal wieder vorkommt, dass ein Kunde zum Beispiel eine Applikation installiert haben möchte, diese aber unter dem root Nutzer installiert werden muss. Dann empfiehlt sich einfach eine geteilte Screen Session zu machen, in der der normale Nutzer auf meinen root Screen einen lesenden Zugriff erhält und mich durch die Installation des Programmes leiten kann, ohne aber selbst mit meinen Rechten irgend etwas ausführen zu können. Ich kann mir auch vorstellen das dies zu Schulungszwecken sehr hilfreich sein kann, zum Beispiel um eine Konfiguration oder Installation erklären zu können.
Die erste Aktion, die ausgeführt werden muss, ist dem screen Programm, welches meist unter /usr/bin/screen liegt, setuid Rechte zu geben. Diese werden benötigt um im Multinutzer Betrieb von Screen Dateien zu öffnen, die sonst nur von root gelesen werden können.
Bitte beachtet aber, dass Programme die mit setuid Bit laufen und dem Nutzer root gehören, alles auf dem System machen können. D.h. sollte das Programm eine Schwachstelle haben (BufferOverflows etc. pp.), kann dadurch das System komprimitiert werden.Deswegen solltet Ihr nach der Session dem Programm Screen das setuid Bit wieder entfernen.
Um das setuid Bit zu setzen, führt Ihr als root Nutzer folgenden Befehl aus:
chmod u+s /usr/bin/screenDanach läuft Screen als setuid Programm. Um das setuid Bit nach der Screen Session wieder zu entfernen, führt Ihr wieder als root Nutzer folgenden Befehl aus:
chmod u-s /usr/bin/screenNach dem setzen der Rechte könnt Ihr, wie schon im letzten Artikle beschrieben, eine Screen Session mit eigenem Namen als root Nutzer aufrufen:
screen -S root_lese_sessionNachdem Ihr diese erstellt habt, müssen ein paar Optionen gesetzt werden, sodass ein normaler Nutzer lesenden Zugriff auf den Screen erhält. Dazu führt Ihr die folgenden Kommandos im Screen aus:
(strg+a) + :multiuser onDie Kommandos haben dabei folgende Bedeutung:
(strg+a) + :acladd nutzername
(strg+a) + :aclchg nutzername -rwx "#?"
(strg+a) + :aclchg nutzername +rx "0,detach"
- (strg+a) + :multiuser on schaltet den Multinutzer Betrieb ein
- (strg+a) + :acladd nutzername fügt den Nutzer nutzername (also z.B. hans) der Zugriffsdatenbank von Screen hinzu, nachdem dieses Kommando ausgeführt wurde, hat der Nutzer alle Rechte in dieser Screen Session
- (strg+a) + :aclchg nutzername -rwx "#?" entfernt die Leserechte (-r), die Schreibrechte (-w) und die Screenkommando Rechte (-x) für alle offenen Screens und Kommandos in dieser Session ("#?")
- (strg+a) + :aclchg nutzername +rx "0,detach" fügt für den Nutzer auf Screen 0 die Lese- und Ausführrechte wieder hinzu, somit kann der Nutzer Screen 0 lesen und sich von diesem wieder abmelden ((strg+a)+(strg+d))
Nach dem die Optionen erfolgreich gesetzt wurden, kann sich der Nutzer mit dem folgendem Befehl anmelden:
screen -x root/root_lese_sessionUnd jetzt kann die freudige Session beginnen. Bei jedem Tastendruck leuchtet der Screen kurz weiß auf, sodass man als root Nutzer merkt wenn der normale Nutzer hätte etwas eingeben wollen. Das einzige was der normale Nutzer jetzt noch darf, ist sich vom Screen via (strg+a)+(strg+d) abzumelden.
Und schon kann man mit der Schulung, Installationen oder sonstigem beginnen. Wenn Ihr fertig mit eurem vorhaben seid, könnt Ihr die Berechtigungen des normalen Nutzers, ganz eichfach, via
(strg+a) + :acldel nutzernamewieder löschen.
Das Beispiel wurde auf einem Ubuntu 8.04 LTS erstellt. Bitte bedenkt das sich das unter Redhat/CentOS/MacOSX ein wenig anders darstellen kann (je nach Screen Version). Als Hilfe empfehlen sich immer die dazugehörigen man pages von screen. Und jetzt viel Spaß beim ausprobieren!
Thursday, 8. October 2009
Linux Professional Institute - LPIC
Da ich seit gestern LPIC-1 zertifiziert bin (Co-Autor Maddin war es bereits seit einer Weile..), möchte ich mal ein paar Worte dazu hier verlieren. Während die Microsoft-Jünger aus dutzenden Schulungen (aka Gehirnwäschen bzw. Werbeveranstaltungen) wählen können, sieht es für Linux eher mau aus. Zwar bieten Suse und RedHat eigene Zertifizierungen an, die Beschränken sich dann aber tatsächlich nur die jeweilige Distrubution und sind nicht allgemein anerkannt.
Dafür wurde LPI gegründet und wird u.A. von IBM subventioniert. Derzeit gibt es 3 Stufen, die man als Administrator (für Entwickler etc. werden keine Zertifizierungen angeboten) erreichen kann: LPIC-1, LPIC-2 und LPIC-3. Die ausgestellten Zertifkate sind weltweit anerkannt, so dass man als Bewerber um einen Posten als Linux-Admin mit einer oder mehreren LPIC-Stufen unter Umständen (!) bessere Karten hat. Garantie gibt es dafür freilich keine. Bei LPIC-1 geht es um Grundlagen der Administration eines Linux-Rechners wie z.B. die Shell, Bootloader und Installation. LPIC-2 geht dann schon etwas mehr ans Eingemachte wie Serverdienste, Kernel oder Hardware. In der 3 (die es wohl in Deutschland noch gar nicht so richtig gibt, soweit ich informiert bin..) dann um Sicherheit oder Virtualisierung.
Auch wenn das auf den ersten Blick für einen Admin, der seit Jahren mit Linux arbeitet, einfach aussieht: Man sollte die Prüfungen nicht unterschätzen. Ich kann jetzt nur für LPIC-1 sprechen, aber mir sind auch einige Sachen begegnet, wo ich Lücken hatte. Zum Beispiel beim Thema X11 oder Drucker musste ich mir Vieles noch aneignen, da sie in meiner täglichen Arbeit als Server-Admin nie begegnet sind. Auch sed oder awk hatte ich noch nie groß benutzt, schließlich gibt es ja PERL. Fragen zu diesen Themen sind aber nunmal Bestandteile bei der LPIC-1 Prüfung, so dass man diese lernen muss.
Zur Übung hat sicher der Simulator auf lpi-academy.de als nützliches Tool erwiesen. Aber Vorsicht, die Fragen sind derzeit nicht auf dem neuesten Stand der Prüfung. Als Buch kann ich auf jeden Fall die LPIC-Reihe von Heinlein empfehlen, ebenso die Materialien von der Linup Front GmbH. Natürlich sollte man idealerweise noch einen entsprechenden Kurs in einem Trainings-Center belegen, um das Wissen aufzufrischen. Bei mir fand der Kurs im Com-Center Dresden statt und war mit Dozenten wie Heiko Schlittermann (bekannt u.A. aus der Linux-User-Group Dresden) recht informativ und hilfreich für die Prüfung.
Ohne entsprechenden Kurs und Erfahrungen mit Linux wird man die Prüfung allerdings wohl kaum bestehen. Es wird, im Gegensatz zu den MS-Zertifizierungen, nicht das auswendig lernen von Fakten abgefragt, sondern die Erfahrungen aus der Praxis im Umgang mit Linux. Dabei spielt die Distribution übrigens keine Rolle, es wird z.B. beim Paket-Management auf alle "Welten" wie Debian, Fedora oder RedHat eingegangen, was auf jeden Fall gut ist. Ich habe bereits in der Schulung gemerkt, dass die Teilnehmer ohne Vorkenntnisse zum Thema Linux echte Probleme hatten, dem Stoff zu folgen. Einige meinten auch, sie werden die Prüfung gar nicht erst ablegen, sondern es bei dem Kurs belassen, da keine Aussicht auf Bestehen der Prüfung besteht. Das ist natürlich schade, aber zeigt deutlich, dass die Anforderungen nicht zu gering sind und man sich als Inhaber des Zertifikates ein wenig freuen darf!
Selbst ich als "alter Hase", der seit vielen Jahren mit Linux beruflich als auch privat arbeitet habe bei den LPIC-Schulungen noch einige neue Dinge und Kniffe kennengelernt, kann die Zertifizierung daher eigentlich durchaus empfehlen. Allerdings ist der "Spaß" natürlich nicht ganz billig. Derzeit fördert aber das Arbeitsamt für berufstätige Admins, die länger als 4 Jahre im Job sind, die LPIC-1 und LPIC-2 Schulungen. Weitere Informationen dazu gibts hier. Wenn man also, wie ich, die Vorgaben des Amts erfüllt und einen Arbeitgeber hat, der die Zeiten dafür freiräumt, sollte man sich die Chance auf mehrere Tausende Euro Förderung für die Schulung(en) nicht entgehen lassen..
Dafür wurde LPI gegründet und wird u.A. von IBM subventioniert. Derzeit gibt es 3 Stufen, die man als Administrator (für Entwickler etc. werden keine Zertifizierungen angeboten) erreichen kann: LPIC-1, LPIC-2 und LPIC-3. Die ausgestellten Zertifkate sind weltweit anerkannt, so dass man als Bewerber um einen Posten als Linux-Admin mit einer oder mehreren LPIC-Stufen unter Umständen (!) bessere Karten hat. Garantie gibt es dafür freilich keine. Bei LPIC-1 geht es um Grundlagen der Administration eines Linux-Rechners wie z.B. die Shell, Bootloader und Installation. LPIC-2 geht dann schon etwas mehr ans Eingemachte wie Serverdienste, Kernel oder Hardware. In der 3 (die es wohl in Deutschland noch gar nicht so richtig gibt, soweit ich informiert bin..) dann um Sicherheit oder Virtualisierung.
Auch wenn das auf den ersten Blick für einen Admin, der seit Jahren mit Linux arbeitet, einfach aussieht: Man sollte die Prüfungen nicht unterschätzen. Ich kann jetzt nur für LPIC-1 sprechen, aber mir sind auch einige Sachen begegnet, wo ich Lücken hatte. Zum Beispiel beim Thema X11 oder Drucker musste ich mir Vieles noch aneignen, da sie in meiner täglichen Arbeit als Server-Admin nie begegnet sind. Auch sed oder awk hatte ich noch nie groß benutzt, schließlich gibt es ja PERL. Fragen zu diesen Themen sind aber nunmal Bestandteile bei der LPIC-1 Prüfung, so dass man diese lernen muss.
Zur Übung hat sicher der Simulator auf lpi-academy.de als nützliches Tool erwiesen. Aber Vorsicht, die Fragen sind derzeit nicht auf dem neuesten Stand der Prüfung. Als Buch kann ich auf jeden Fall die LPIC-Reihe von Heinlein empfehlen, ebenso die Materialien von der Linup Front GmbH. Natürlich sollte man idealerweise noch einen entsprechenden Kurs in einem Trainings-Center belegen, um das Wissen aufzufrischen. Bei mir fand der Kurs im Com-Center Dresden statt und war mit Dozenten wie Heiko Schlittermann (bekannt u.A. aus der Linux-User-Group Dresden) recht informativ und hilfreich für die Prüfung.
Ohne entsprechenden Kurs und Erfahrungen mit Linux wird man die Prüfung allerdings wohl kaum bestehen. Es wird, im Gegensatz zu den MS-Zertifizierungen, nicht das auswendig lernen von Fakten abgefragt, sondern die Erfahrungen aus der Praxis im Umgang mit Linux. Dabei spielt die Distribution übrigens keine Rolle, es wird z.B. beim Paket-Management auf alle "Welten" wie Debian, Fedora oder RedHat eingegangen, was auf jeden Fall gut ist. Ich habe bereits in der Schulung gemerkt, dass die Teilnehmer ohne Vorkenntnisse zum Thema Linux echte Probleme hatten, dem Stoff zu folgen. Einige meinten auch, sie werden die Prüfung gar nicht erst ablegen, sondern es bei dem Kurs belassen, da keine Aussicht auf Bestehen der Prüfung besteht. Das ist natürlich schade, aber zeigt deutlich, dass die Anforderungen nicht zu gering sind und man sich als Inhaber des Zertifikates ein wenig freuen darf!
Selbst ich als "alter Hase", der seit vielen Jahren mit Linux beruflich als auch privat arbeitet habe bei den LPIC-Schulungen noch einige neue Dinge und Kniffe kennengelernt, kann die Zertifizierung daher eigentlich durchaus empfehlen. Allerdings ist der "Spaß" natürlich nicht ganz billig. Derzeit fördert aber das Arbeitsamt für berufstätige Admins, die länger als 4 Jahre im Job sind, die LPIC-1 und LPIC-2 Schulungen. Weitere Informationen dazu gibts hier. Wenn man also, wie ich, die Vorgaben des Amts erfüllt und einen Arbeitgeber hat, der die Zeiten dafür freiräumt, sollte man sich die Chance auf mehrere Tausende Euro Förderung für die Schulung(en) nicht entgehen lassen..
Tuesday, 6. October 2009
[Tipps und Tricks] Remote Shell ein mal eins
Heute möchten wir euch 3 kleine, aber wirkungsvolle Tipps für das tägliche Arbeiten an entfernten Computern geben.
In Zeiten wo Administratoren für immer mehr, und vor Allem, immer weiter entferntere Systeme zuständig sind, haben sich im Unix bereich 2 Tools heraus kristallisiert, die für die tägliche Arbeit unabdingbar sind: screen und ssh.
In Zeiten wo Administratoren für immer mehr, und vor Allem, immer weiter entferntere Systeme zuständig sind, haben sich im Unix bereich 2 Tools heraus kristallisiert, die für die tägliche Arbeit unabdingbar sind: screen und ssh.
- Shared SSH Sessions
- auf dem entfernten System wird durch die "wiederverwendung" der schon bestehenden Verbindung, Speicher gespart
- die Slave Verbindungen müssen sich am entfernten System nicht mehr authentifizieren (sehr hilfreich bei gescripteten Sachen)
- Screen lock
- Geteilte Screen Session
Des öfteren arbeitet man mit mehreren Remote Shells auf einem Server. Gerade wenn man am testen, konfigurieren oder debuggen auf einem Server ist, ist dies meist unabdingbar. Um dann auf dem Server durch die angehäuften Shells nicht zuviel Speicher zu nutzen (es kann ja auch mal sein, man arbeitet auf einer Appliance oder einem Router mit etwas weniger Speicher), bietet SSH die Möglichkeit sogenannte Master Verbindungen aufzubauen. Diese sind in der Lage, ihre Verbindung mit mehreren Slave Verbindungen zu teilen. Dazu wird auf dem lokalen System ein Master Socket angelegt, über den die Slave Verbindungen zugreifen können. Daraus resultieren 2 Vorteile:
ssh -M -o ControlPath=/Pfad/zum/Master/Socket user@hostDabei steht ide Option -M für Master und unter der Option -o ControlPath=/Pfad/zum/Master/Socket wird der Pfad zum Kontroll Socket für die Slave Verbindungen angegeben. Der Socket wird dabei unter den jeweiligen Benutzer mit Lese- und Schreibrechten angelegt (0600), ist also für andere Nutzer (ausser natürlich root) nicht les- und schreibbar. Die Slave Verbindungen startet man dann ganz einfach via
ssh -S /Pfad/zum/Master/Socket user@host
Ist man einmal via SSH auf einem entferntem System angemeldet, ist nichts schlimmer als wenn diese Session durch Verbindungsfehler, sei es die schlechte Verbindung (z.B. nach China) oder das versehentlich geschlossene Fenster, wieder beendet werden. Für solche (und noch viele andere) Zwecke gibt es screen. Screen erstellt einen virtuellen Terminal, der losgelöst vom SSH Prozess auch dann weiter existiert, wenn dieser durch irgendwelche Gründe beendet wird. Hat man jetzt via screen einen Screen gestartet, kann die Verbindung wegbrechen wie sie möchte. Nach einer Wiederverbindung auf das System kann man sich ganz einfach via screen -r den Screen zurück holen und da weiter machen wo man aufgehört hat. Was aber wenn man sensible Daten auf seinem Screen verfolgt (z.B. Log Ausgaben) oder dieser beim Verlassen des Arbeitsplatzes vor fremden Zugriff geschützt werden soll? Auch dafür gibt es eine Lösung: In der laufenden Sceen Session aktiviert man mit der Tastenkombination (strg+A) + (strg+x) (unter Debian, bei anderen Systemen hilft ein Blick in die Hilfe, zu erreichen via (strg+a) + :help + enter) den Screen Lock. Danach ist der Screen nur noch über das Login zu erreichen. Je nach dem was für ein Lock Programm oder eine Version von Screen verwendet, kann man den Screen mit dem Nutzer Passwort oder einem selbst gewählten Passwort entsperren.
Nun soll es ja auch vorkommen, dass mehr als ein Adminstrator für die Systempflege zuständig ist und man gemeinsam auf einem System an einer Konfiguration arbeitet oder einen Fehler debuged. Aber auch dafür gibt es mit Screen eine Lösung, die vor allem dann sehr toll ist, wenn man gemeinsam Dateien editieren möchte oder jemanden etwas erklären möchte. In diesem Post werde ich euch die geteilte Screen Session mit gleichen Nutzern erklären. Es gibt auch Möglichkeiten mit unterschiedlichen Nutzern eine geteilte Screen Session zu machen, z.B. root als ausführende Kraft und ein normaler Nutzer der nur einen Read-Only Zugriff auf den Screen hat. Nun aber zu ersterer Variante mit dem gleichen Nutzer. Als erstes startet man einen Screen mit einem angepassten Socketnamen via
screen -S SocketnameUm den Screen jetzt Multinutzer fähig zu machen, aktiviert man mit der Tastenkombination (strg+a) + :multiuser on diese Funktionalität. Mit dem zweiten Benutzer kann man jetzt via
screen -x Socketnameauf die Session zugreifen. Und simsalabim, schreibt der eine Nutzer sieht es der andere Nutzer sofort.
Saturday, 19. September 2009
[Script] Zeitstempel aus dmesg in lesbare Zeitangaben umwandeln
Jeder Linux-User mit einem aktuellen Kernel auf seiner Maschine kennt sicher die Meldungen aus dem dmesg-Buffer, die u.A. zur Bootzeit generiert werden. Aber auch nach dem Bootvorgang werden teils kritische Meldungen vom Kernel in dmesg geschrieben. Ein kleines Beispiel:
Das kleine Perlscript dmesg.pl erledigt die Umrechnung on-the-fly für uns. Wir bekommen dann eine verständliche Ausgabe, hier für unser obiges Beispiel:
Das Script liest einfach die Uptime aus /proc/uptime in Sekunden aus und errechnet aus der aktuellen Unix-Time sowie den Einträgen aus dmesg dann den korrekten Zeitstempel. Aber Vorsicht, auf Maschinen, die bereits recht lange laufen, kommt es leider zu Differenzen. Den konkreten Grund konnte ich bisher noch nicht klären, vermutlich aber liegt es daran, dass die Kernel-Uptime nicht immer korrekt hochgezählt wird, v.A. unter Last. Ein weiterer möglicher Grund sind inkorrekte Zeitmessungen nach automatischen Taktänderungen der CPU, zumindest weist ein Bugreport auf kernel.org darauf hin. Auf meinem frisch gebooteten Linux-Laptop hingegen stimmte die Umrechnung stets zu 100%.
Falls Jemand eine andere Erklärung für die Differenzen hat oder das Script optimieren möchte, freue ich mich auf Kommentare. Die Bash-Variante war leider sehr langsam, daher die Perl-Lösung.
[3631596.049121] e1000: eth0: e1000_watchdog: NIC Link is DownEs war also offenbar zu irgendeinem Zeitpunkt an diesem Server die Netzwerkverbindung für einige Zeit getrennt. Nur wann genau war das? Gestern oder vor 3 Monaten? Bei Servern, die teilweise Monate (oder gar Jahre!) am Stück laufen, ist der Zeitpunkt kaum zu erraten. Die Angabe in den eckigen Klammern vor jeder Meldung stellt die Zeit seit dem Systemstart dar, leider nicht wirklich menschlich lesbar. Klar, man könnte mittels uptime und date nun die Sekunden manuell berechnen und somit einen Zeitpunkt ermitteln. Aber eigentlich gibt es dafür ja Perl!
[3631647.485033] e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
Das kleine Perlscript dmesg.pl erledigt die Umrechnung on-the-fly für uns. Wir bekommen dann eine verständliche Ausgabe, hier für unser obiges Beispiel:
[ Wed Jul 1 10:33:11 2009 ] e1000: eth0: e1000_watchdog: NIC Link is DownLegt man nun einen Alias wie z.B. alias dmesg='perl /path/to/dmesg.pl' an (z.B. gleich in der .bashrc), bekommt man immer den lesbaren Output.
[ Wed Jul 1 10:34:02 2009 ] e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
Das Script liest einfach die Uptime aus /proc/uptime in Sekunden aus und errechnet aus der aktuellen Unix-Time sowie den Einträgen aus dmesg dann den korrekten Zeitstempel. Aber Vorsicht, auf Maschinen, die bereits recht lange laufen, kommt es leider zu Differenzen. Den konkreten Grund konnte ich bisher noch nicht klären, vermutlich aber liegt es daran, dass die Kernel-Uptime nicht immer korrekt hochgezählt wird, v.A. unter Last. Ein weiterer möglicher Grund sind inkorrekte Zeitmessungen nach automatischen Taktänderungen der CPU, zumindest weist ein Bugreport auf kernel.org darauf hin. Auf meinem frisch gebooteten Linux-Laptop hingegen stimmte die Umrechnung stets zu 100%.
Falls Jemand eine andere Erklärung für die Differenzen hat oder das Script optimieren möchte, freue ich mich auf Kommentare. Die Bash-Variante war leider sehr langsam, daher die Perl-Lösung.
Friday, 11. September 2009
[TIPP] Forwarding entfernter Dienste via SSH
Um das normalerweise aus Sicherheitsgründen nur von localhost aus erreichbare Webinterface eines RAID-Controllers oder auch die webbasierte CUPS-Config eines entfernten Rechners zu erreichen, kann man sich der Forwarding-Funktionalität von SSH bedienen.
Hier ein Beispiel, um das auf einem Server arbeitende Webinterface eines 3Ware-RAID Controllers auf dem lokalen Rechner aufzurufen. Der entsprechende Dienst läuft auf Port 888 des entfernten Hosts und wird auf den Port 8080 unserene Rechners weitergeleitet:
Anschließend haben wir im Browser ganz einfach Zugriff auf https://localhost:8080 und können bequem die Einstellungen vornehmen, ohne uns vorher mühsam auf dem Server einzuloggen und in der Konfiguration des RAID-Controller-Dienstes (3dm2 wäre das in diesem Fall) den Remote-Zugriff zu aktivieren, was ja auch unter Umständen ein Sicherheitsrisiko sein kann.
Wenn wir die SSH-Session, die beim Login mit hergestellt wird, beenden, ist das Forwarding automatisch wieder deaktiviert. Zu beachten ist noch, dass lokale Ports kleiner als 1024 nur von root belegt werden können. Dafür gibt's aber i.d.R. keinen Grund ..
Weitere Info's dazu bekommt man im OpenSSH-Manual, mit SSH kann man nämlich noch viele weitere tolle Sachen anstellen, wie z.B. mit dem Schalter -X entfernte grafische Programme lokal auszuführen.
Hier ein Beispiel, um das auf einem Server arbeitende Webinterface eines 3Ware-RAID Controllers auf dem lokalen Rechner aufzurufen. Der entsprechende Dienst läuft auf Port 888 des entfernten Hosts und wird auf den Port 8080 unserene Rechners weitergeleitet:
ssh -L 8080:localhost:888 root@remotehost
Anschließend haben wir im Browser ganz einfach Zugriff auf https://localhost:8080 und können bequem die Einstellungen vornehmen, ohne uns vorher mühsam auf dem Server einzuloggen und in der Konfiguration des RAID-Controller-Dienstes (3dm2 wäre das in diesem Fall) den Remote-Zugriff zu aktivieren, was ja auch unter Umständen ein Sicherheitsrisiko sein kann.
Wenn wir die SSH-Session, die beim Login mit hergestellt wird, beenden, ist das Forwarding automatisch wieder deaktiviert. Zu beachten ist noch, dass lokale Ports kleiner als 1024 nur von root belegt werden können. Dafür gibt's aber i.d.R. keinen Grund ..
Weitere Info's dazu bekommt man im OpenSSH-Manual, mit SSH kann man nämlich noch viele weitere tolle Sachen anstellen, wie z.B. mit dem Schalter -X entfernte grafische Programme lokal auszuführen.
Kommentare