Linux

Das war sie also meine erste PHP Conference. Alles in allem eine wirklich gute Sache, wie es halt immer ist, es gibt gutes und weniger gutes zu sagen und ich werde hier einiges von dem was ich so gehört und erlebt habe, zusammentragen.

Da dieser Artikel etwas länger wird, erstmal ein kurzer Teaser, damit ihr wißt auf was ihr euch beim lesen einlasst.

Ich werde auf die Vorträge, dich ich besucht habe, eingehen und jeweils (soweit aktuell schon vorhanden) die Folien verlinken (Gesamtuebersicht der Folien auf joind.in) bzw. sonstige Informationen (zB. zum Speaker etc.) zusammentragen, und auch meine jeweilige Meinung zum Thema und auch zum Vortrag schreiben.

Außerdem werde ich noch einige persönliche Eindrücke von der Conference einfliessen lassen.

Wenn ihr also jetzt noch nicht total ermüdet seid, viel Spaß beim weiterlesen.
 

Hier erstmal eine Liste der Vorträge, die ich mir angehört habe (Details gibts dann weiter unten):

IPC - 10. Oktober 2011

•         PHP 5.4 – An Update (Johannes Schlüter - Oracle)    
•         Git-Crashkurs (Tobias Günther fournova GmbH
•         Keynote: Rechts überholt – Überlebensstrategien für das große Innovations-Rennen  (Gernot Pflüger)
•         Security 202 – Are you sure your Site is secure? (Arne Blankerts - thePHP.cc)
•         PHP Testing Tools (Sebastian Bergmann - thePHP.cc)
•         Redis – Your advanced in-memory key-value Store (Jordi Boggiano Nelmio)

IPC - 11. Oktober 2011

•         PHP & MySQL – A Dream Team (Johannes Schlüter - Oracle)
•         Profiling PHP Applications (Derick Rethans)
•         Keynote: How the Web Evolves with Hypermedia (David Zuelke)
•         Designing HTTP Interfaces and RESTful Web Services (David Zuelke - Bitextender GmbH)
•         Symfony2 by Code (Lukas Smith Liip AG)
•         Scalable high-performance Architectures (Stefan Priebsch - thePHP.cc)
•         PHPopstar – Vom Folienableser zum spannenden Vortrag

IPC - 12. Oktober 2011

•         Practical DevOps for Developers (Johann-Peter Hartmann - SektionEins GmbH)
•         Keynote: Cloud by Example (Amazon Webservices) (Dr. Matt Wood - Amozon)
•         Handys und Tablets: Webentwicklung jenseits des Desktops (Patrick Lauke - Opera Software ASA)
•         Doctrine 2: Next Generation ORM (Benjamin Eberlei - SimpleThings GmbH)
•         Vom lokalen Build zum Deployment (Manuel Pichler - Qafoo GmbH)

Gibt schon einige gute Anleitungen zum Thema "Anpassen der eigenen Shell", egal ob Bash oder ZSH oder sonstwas.

zB. hier: http://blog.pimpmyshell.de/2007/12/10/pimp-your-prompt/

oder hier: http://wiki.ubuntuusers.de/Bash/Prompt

Deshalb ohne große Worte, hier meine PS1: (wie der Promt dadurch aussieht, sieht man ja dann gleich mit ;))

[Di 16.05.2011 19:57, sweo@mymachine:~] $ cat ~/.bashrc
....
PS1='[${debian_chroot:+($debian_chroot)}\D{%a %d.%m.%Y} \A, \u@\h:\w] \$ '
....

Datum und Uhrzeit und der aktuelle Pfad (Home als ~), das genügt mir schonmal.

Dazu noch einige wichtige Aliase, zB.:

# some more ls aliases
alias ll='ls -l'
alias la='ls -A'
alias l='ls -la -h'

Inbesondere das einfache l ist wesentlich besser als ls -la -h .

Wenns interessiert hier noch meine komplette .bashrc:

Root Meldungen an eine externe Emailadresse weiterleiten

Viele Meldungen eines Linux Systems, (in diesem Fall Debian), werden an root@localhost gesendet, um den root zu informieren. Um diese Mails auch extern zu lesen bietet es sich an im Homeverzeichnis des root (also unter /root :)) eine neue Datei namens .forward anzulegen und in diese die jeweilige externe Emailadresse reinzuschreiben.

Hier ein Beispiel:

root@yourmachine:/# vi /root/.forward

your@emailadress.com

Dadurch werden alle Meldungen, die an root@localhost gehen, automatisch an die hier angegebene Emailadresse weitergeleitet.
 

Root Meldungen an mehrere externe Emailadresse weiterleiten

Möchte man nun, dass mehrere Empfänger die Meldungen, die an root@localhost gehen, weitergeleitet bekommen, hilft die Datei /etc/aliases weiter.

Hier trägt man einfach im Format => root: firstUnixUser secondUnixUser thirdUnixUser usw, die Namen der Nutzer ein, die die root@localhost Emails empfangen sollen. Danach den Befehl newaliases um die neuen Aliases bekannt zu machen.

Anschliessend trägt man wie oben beschrieben in der .forward Datei des jeweiligen Nutzers die entsprechende externe Emailadresse ein. Die .forward Datei liegt dann natürlich jeweils im Homeverzeichnis des Nutzers und nicht mehr unter /root.

Hier das Beispiel dazu (UnixUser sind hier sweo und testuser, diese müssen dann natürlich angepaßt werden):

root@yourmachine:/# vi /etc/aliases
root: sweo testuser

root@yourmachine:/# newaliases

root@yourmachine:/# vi /home/sweo/.forward
mail@sweo.de

root@yourmachine:/# vi /home/testuser/.forward
mail@tesuserdomain.com

Durch dieses Vorgehen werden nun alle Meldungen an root@localhost an die beiden externen Adressen der User sweo und testuser weitergeleitet. Dass diese natürlich UnixUser mit eigenem Homeverzeichnis sein müssen, versteht sich von selbst. :)

Dieses Vorgehen bietet sich nicht nur an, um reine Systemmeldungen zu erhalten, sondern vor allem für Dinge wie Monitoring.

Einfach im Monitoringtool als Empfänger etwaiger Meldungen und Alerts root@localhost eintragen und alle in /etc/aliases eingetragenen User werden mit informiert wenn das Monitoring anschlägt.

Immer mal wieder kommt die Aufgabe, sich in einem Linuxsystem relevante Systeminformationen zur Hardwareausstattung, zur Kernelversion, zu den installierten Paketen usw. anzeigen zu lassen.

Um nicht jedesmal alle Befehle einzeln eingeben zu müssen, kommt hier ein kleines Shell-Script, was wesentliche Infos zusammenfasst und in eine Datei schreibt.

 #!/usr/bin/sh 

 rm  /tmp/systeminfo    
   
 echo -e "\n`tput smso`Platform info`tput rmso`" >> /tmp/systeminfo 
 uname -a >> /tmp/systeminfo 
 
 echo -e "\n`tput smso`Release info`tput rmso`" >> /tmp/systeminfo 
 cat /etc/*-release >> /tmp/systeminfo  
 
 echo -e "\n`tput smso`CPU info`tput rmso`" >> /tmp/systeminfo 
 cat /proc/cpuinfo  >>  /tmp/systeminfo 
 
 echo -e "\n`tput smso`Memory info`tput rmso`" >> /tmp/systeminfo 
 dmesg | grep -i memory >>  /tmp/systeminfo 
 
 #echo -e "\n`tput smso`Package info`tput rmso`" >> /tmp/systeminfo 
 #rpm -qa >> /tmp/systeminfo 
 
 cat /tmp/systeminfo  

Die Infos über die installierten Pakete sind hier auskommentiert, wenn man die mit haben will einfach de beiden Zeilen wieder mitnehmen.

Das cat zum Anzeigen der Systeminfo ist gleich mit drin am Ende.

Achja, und nicht wundern über die tput's, die sind nur zum Highlighting der Überschriften und dienen der Übersichtlichkeit.
 

Erscheint diese Meldung im error.log des Apache, wenn er nicht mehr starten will, bedeutet das, dass der Apache nicht ordentlich runtergefahren ist und sich ziemlich viele semaphore-arrays des Apache-Users angesammelt haben.

Diese kann man sich so anzeigen lassen:

ipcs -s | grep www-data

www-data ist der Apache-User. (Oder wie er halt sonst so heißt)

Löschen kann man diese überflüssigen Arrays so:

ipcs -s | grep www-data |  perl -e 'while (<STDIN>) {@a=split(/\s+/); print `ipcrm sem $a[1]`}'

Danach startet auch der Apache wieder.

Nachdem ich vor kurzem von der SpamAttacke auf den MailServer eines Kumpels berichtet habe und davon wie ich letztendlich die IPs der versendenden Rechner per iptables geblockt habe, hat unser Hoster reagiert und das Tool Fail2ban installiert, dass ich hier mal kurz vorstelle.

Fail2ban ist, um es mit den Worten auf der Fail2ban Seite zu formulieren, ein Scanner, der die Logfiles, zB. des Apache oder auch eines Mailserver, wie postfix oder die auth.log für ssh Zugriffe, usw. durchsucht und mittels konfigurierbarer RegEx-Regeln entscheidet, ob eine IP geblockt werden soll, oder nicht. Damit kann zB. verhindert werden, dass von einer IP übermässig oft versucht wird, per ssh auf den Server zuzugreifen. Die Anzahl der möglichen Versuche ist einstellbar, default ist hier 3. Fail2ban nutzt zum Blocken der IPs die schon auf einem System vorhandenen Möglichkeiten, wie iptables oder shorewall und richtet, wenn eine Regel in den Logfiles anschlägt, einen entsprechenden neuen Eintrag mit der IP in der firewall (zB. iptables) ein.

Fail2ban ist in Python geschrieben und bringt einen eigenen Server daemon mit, der multithreaded ist und auf einem Unix socket auf Kommandos des zugehörigen fail2ban-clients lauscht.

Um die Arbeitsweise und die Konfiguration von Fail2ban zu zeigen, hier ein Beispiel:

Wie es die Überschrift schon sagt, hier zwei Links, um den Alltag auf Unixrechnern zu erleichtern:

Unix-Dateirechte-Setzer (chmod)

Mal wieder auf der Suche nach dem richtigen Oktal-Code für chmod. Dieses kleine Formular hilft schnell weiter,

Hier mal nen kurzer Befehl, um IPs, die einem irgendwie auf die Nerven gehen auf einem Unix System zu blocken:

iptables -A INPUT -s abcd -j DROP

-> abcd ersetzen mit der IP die geblockt werden soll.

iptables -L

zeigt dann alle geblockten IPs.

Ein gutes Tool,welches einem das Blocken von IPs erleichtert und automatisiert ist Fail2ban, das ich hier näher beschreibe.

Nachdem gestern der Server eines Freundes in den Genuß einer SpamAttacke kam und ein Script fröhlich von einem australischen Server aus über seinen Server massenweise Mails verschicken wollte (grund war ein gehackter Mailaccount der mit dem Passwort test gesichert war :) ) mußten wir schauen, wie wir das Problem in den Griff bekommen. 

Da auf dem Server Postfix als MTA eingesetzt wird, kommen hier ein paar Tipps, wie man bei Postfix die Queue löschen kann, die Logs einstellt oder auch einfach nur den Dienst startet oder stoppt. Betriebssystem des Servers ist Debian.