Installation der Pakete:

apt-get install snmp

Wer auch zukünftig seine OID’s auflösen möchte, muss sich nun neu im Non-Free Repository bedienen. Dort steht das entsprechende Paket “snmp-mibs-downloader” bereit.

apt-get install snmp-mibs-downloader

Das wars, der SNMPD-Deamon müsste mal “laufen”. Test mittels dem entsprechenden init.d Script möglich

/etc/init.d/snmpd status

Dort müsste man den Erfolg der bisher äussert komplexen Installation nun mittels “snmpd is running” bestätigt kriegen.

Weiter gehts mit der Konfiguration:

Offiziell steht das Tool snmpconf bereit, mit welchem man per Wizzard den Dienst konfigurieren kann. Ich pers. finde dieses Tool allerdings eher verwirrend und ineffizient. In diesem Beispiel sollen lediglich die Systeminformationen plus ein paar “externe” Scripts auf Distanz mittes SNMP v1/v2 abgefragt werden können, daher reicht eine recht magere Konfiguration.

/etc/snmp/snmpd.conf

# Netzwerk
agentAddress  udp:161
 
#Zugriffsteuerung
rocommunity public nagioshost.hallo.welt
 
# Kontaktinformationen
syslocation Ich bin hier
syscontact ich@hallo.welt
 
# Systemchecks
includeAllDisks  10%
load   12 10 5
 
#Erweiterungen
exec meintest   /usr/local/bin/meintest.sh

Erwähnenswert ist hier der “neue” Parameter agentAddress , welcher den Deamon standartmässig nur auf localhost (udp:127.0.0.1:161) bindet. Hier wahlweise die gewünschte Interface-Adresse verwenden, oder wie in meinem Beispiel auf allen IP’s des Systems horchen lassen. Alle übrigen Parameter haben sich bei Squeeze wenig verändert. Die Zugriffsteuerung wurde sogar wesentlich vereinfacht über ein view konzept – welches im aufgezeigten Beispiel allerdings komplett weggelassen wurde. Die definierte Host/Community Kombination hat so einen kompletten Lesezugriff.

Den Deamon neu starten – fertig:

/etc/init.d/snmpd restart

Auch hier lohnt es sich danach ein weiteres mal den “status” abzufragen:

/etc/init.d/snmpd status

Sofern vorhanden, müssen nun noch die entsprechenden Regeln in der Firewall ergänzt werden (TCP/UDP Port 161), damit der Zugriff auf Distanz auch wirklich klappt.

Alte Zertifikate sichern:

cd /etc/courier/
mv imapd.pem imapd.pem.old
mv pop3d.pem pop3d.pem.old

Neue Zertifikate erstellen:

mkimapdcert
mkpop3dcert

Courier-SSL Dienste neu starten:

/etc/init.d/courier-pop-ssl restart && /etc/init.d/courier-imap-ssl restart

So – schon hat man wieder 1 Jahr lang Ruhe..

Sehr informativ sind die Table Schemas.

Folgendes Query listet alle Tabellen, deren Storage Engine, Kollation und die Anzahl Datensätze zurück:

SELECT table_schema, table_name, engine, table_collation, table_rows 
from information_schema.tables 
where table_schema like 'mydb%';

Resultat (z.B. WordPress Blog DB):

mysql> select table_schema, table_name, engine, table_collation, table_rows 
from information_schema.tables 
where table_schema like 'mydb%';
+--------------+-----------------------+--------+-----------------+------------+
| table_schema | table_name            | engine | table_collation | table_rows |
+--------------+-----------------------+--------+-----------------+------------+
| mydb1  | wp_commentmeta        | MyISAM | utf8_general_ci |          0 |
| mydb1  | wp_comments           | MyISAM | utf8_general_ci |          3 |
| mydb1  | wp_contact_form_7     | MyISAM | utf8_general_ci |          1 |
| mydb1  | wp_links              | MyISAM | utf8_general_ci |          2 |
| mydb1  | wp_options            | MyISAM | utf8_general_ci |        269 |
| mydb1  | wp_postmeta           | MyISAM | utf8_general_ci |         69 |
| mydb1  | wp_posts              | MyISAM | utf8_general_ci |        103 |
| mydb1  | wp_prli_clicks        | MyISAM | utf8_general_ci |          1 |
| mydb1  | wp_prli_groups        | MyISAM | utf8_general_ci |          0 |
| mydb1  | wp_prli_link_metas    | MyISAM | utf8_general_ci |          0 |
| mydb1  | wp_prli_links         | MyISAM | utf8_general_ci |          1 |
| mydb1  | wp_term_relationships | MyISAM | utf8_general_ci |        163 |
| mydb1  | wp_term_taxonomy      | MyISAM | utf8_general_ci |         56 |
| mydb1  | wp_terms              | MyISAM | utf8_general_ci |         50 |
| mydb1  | wp_usermeta           | MyISAM | utf8_general_ci |         16 |
| mydb1  | wp_users              | MyISAM | utf8_general_ci |          1 |
+--------------+-----------------------+--------+-----------------+------------+
16 rows in set (0.74 sec)

Natürlich sind hier auch weitere Informationen abrufbar. Erste Hilfe bietet hier einmal mehr die mySQL Dok

Ein einfaches

SHOW FULL PROCESSLIST;

auf der mySQL-Konsole dieses Servers brachte folgendes Query mit sehr kurzen Intervallen und einer grossen Laufzeit zum vorschein:

SELECT * FROM hits ORDER by userid DESC

Somit war auch die verdächtige Datenbank – und dadurch auch der verantwortliche Account erruiert. Ein kurzer Blick auf das Schema dieser Datenbank/Tabelle zeigte folgendes:

• > 1’000’000 Datensätze!
• Kein Index auf userid!

Als erstes wurde mal userid indexiert, was zwar die Queryperformance deutlich verbesserte – aber die Last des Servers immernoch überdurchschnittlich beanspruchte.

Ich konnte mir spontan nicht erklären, wesshalb jemand den kompletten Inhalt dieser Tabelle auslesen sollte. Alleine der fehlende Index und das “Select *” waren für mich ein Indiz, dass hier KEIN Profi am Werk war. Mich packte der Ergeiz und ich warf einen Blick auf den PHP-Code der entsprechenden Applikation. Es handelte sich dabei um ein gut frequentiertes Toplisten-Script. Irgendwo im Code fand ich folgendes:

..
{
  $useridgen=mysql_query("SELECT * FROM hits ORDER BY userid DESC");
  $idgenaray=mysql_fetch_array($useridgen);
  $userid=$idgenaray[userid]+1;
}
..

Toll, diese Funktion macht also nichts anderes als die nächste ID für einen Datenbankeintrag zu ermitteln.
Auto_Increment war hier offenbar ein Fremdwort..

Nach einer Rücksprache mit dem betroffenen Kunden wurde die Applikation so minimal wie möglich angepasst.

{
  $useridgen=mysql_query("SELECT max(userid) as userid FROM hits");
  $idgenaray=mysql_fetch_array($useridgen);
  $userid=$idgenaray[userid]+1;
}

Das neue Query liefert durch den SELECT max() nur noch genau 1 Datensatz zurück (statt > 1’000’000 vorher)! – erfüllt aber genau dieselbe Funktion innerhalb dieses Scriptes. Das Script selbst musste somit nicht weiter angepasst werden.

Die Auswirkung dieses Korrektur lässt sich auf folgenden Graphen auf beeindruckende Art und Weise erkennen:

Praxisbeispiel:
Ein Kundenserver viel immer wieder durch schlechte Performance auf. Es handelte sich dabei um eine Forensoftware von Woltlab, welche mit ein paar Hacks erweitert wurde. Insgesammt umfasst die Datenbank an die 1.5 Millionen Posts in 300’000 Threads. Das Datenvolumen der Datenbank lag zu diesem Zeitpunkt bei rund 1.4GB. Zu Stosszeiten waren jeweils an die 250 User und Bots unterwegs..

Ein einfaches

SHOW FULL PROCESSLIST;

auf der mySQL-Konsole brachte folgendes Query mit einer sehr grossen Laufzeit zum vorschein:

SELECT
bb2_threads.*,
bb2_icons.*,
bb2_boards.*,
bb2_users.username as lastposter
FROM bb2_threads
LEFT JOIN bb2_icons USING (iconid)
LEFT JOIN bb2_boards ON (bb2_threads.boardid=bb2_boards.boardid)
LEFT JOIN bb2_users ON (bb2_threads.lastposterid=bb2_users.userid)
WHERE bb2_threads.closed!=3 
ORDER BY bb2_threads.lastposttime DESC LIMIT 0, 5

Dieses Query ermittelt also die 5 aktuellsten Threads sammt Titel, Author und die entsprechenden ID’s für die Verlinkung und zeigt diese infos auf der Startseite an. Das Query hatte unverändert auf der Konsole trotz allen notwendigen Indexen eine Laufzeit von gut 3s – verursacht durch die gigantische Datenmenge und den notwendigen Filesort.

Nachdem ich mich in das Datenbankschema eingearbeitet habe – konnte ich das Query “etwas” bereinigen:

SELECT
bb2_threads.threadid,
bb2_threads.views,
bb2_threads.lastposterid,
bb2_threads.topic,
bb2_threads.lastposter
FROM bb2_threads
LEFT JOIN bb2_boards ON (bb2_threads.boardid=bb2_boards.boardid)
WHERE bb2_threads.closed!=3 
ORDER BY bb2_threads.lastposttime DESC LIMIT 0, 5

Der Output ist 100% identisch zum Original. Die Abfrage dauert jetzt allerdings nur noch knapp 0.2s!

Nur diese eine Anpassung hatte folgende Auswirkung auf die Serverlast (Ab KW51):

• Slow Query Log
• Max Connections
• Worker Threads
• Key Buffer
• Query Cache
• Sort Buffer
• Joins
• Temp Tables
• Table (Open & Definition) Cache
• Table Locking
• Table Scans (read_buffer)
• Innodb Status

Kompatibel mit allen gängigen mySQL Versionen.

Bereitgestellt wird der Tuning Primer von Day32.com. Download: mySQL Tuning primer

Archivinhalt auflisten – ohne entpacken

Inhalt komplett auflisten:

 tar -tvf MEINTAR.tar.gz

Inhalt auflisten und filtern:

 tar -tvf MEINTAR.tar.gz | grep suchwort

Diese Information ist eine gesunde Basis für die nächsten Schritte

Einzelne Dateien entpacken

Einzelne Datei aus einem TAR entpacken:

 tar -zxvf MEINTAR.tar.gz ordner1/ordner2/datei1.jpg

Einzelne Ordner/Pfade rekursiv aus einem TAR entpacken:

 tar -zxvf MEINTAR.tar.gz ordner1/ordner2/

Richtig flexibel wird das entpacken mit Wildcard-Filtern:

Rekursiv aus TAR mit Wildcard-Filter entpacken:

tar xfv MEINTAR.tar.gz  --wildcards --no-anchored 'settings*'

Einzelne Dateitypen aus TAR mit Wildcard-Filter entpacken:

tar xfv MEINTAR.tar.gz  --wildcards --no-anchored '*.jpg'

Ihre Nachricht hat einige oder alle Empfänger nicht erreicht.
      Betreff:  ***** 
      Gesendet am:      dd.mm.yyyy HH:MM
Folgende(r) Empfänger kann/können nicht erreicht werden:
'*****' am dd.mm.yyyy HH:MM
573 573  
Authentifizierte Verbindungen nicht moeglich. Bitte nutzen Sie den Port 587 oder kontaktieren Sie uns unter 0800 800 800. 
Connexions authentifiees pas possible. Veuillez utiliser le port 587 ou nous appeler au 0800 800 800.
Collegamenti autenticati non possibili. Prego voi uso la porta 587 oppure contattare il numero 0800 800 800.
Authenticated connections not possible. Please use port 587 or contact us on 0800 800 800.

Offenbar hat dieser Schritt bei vielen Providern erheblichen Supportaufwand produziert. Zumindest eröffneten Hostpoint und Cyon Statustickets zu dieser Problematik. Ebenfalls wurde auf der Swinog Mailingliste ordentlich darüber diskutiert.

Offiziell will man dadurch das versenden von Spam über Mailserver ohne Authentifizierung/Verschlüsselung unterbinden (z.B. durch Viren). Ob die entsprechenden Mailserver unter Port 587 (Submission) aber sicherer konfiguriert sind bezweifle ich. Zumal auch hier eine Verschlüsselung (TLS) nicht zwingend erforderlich ist.

apt-get install cowsay
ln -s /usr/games/cowsay /usr/bin/cowsay

Das wars eigentlich schon.

Ein erster Test:

cowsay "blog.alonso.ch"

Müsste zu folgendem Resultat führen:

 ________________
< blog.alonso.ch >
 ----------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Unter /usr/share/cowsay/cows/ sind ausserdem diverse Templates vorhanden, welche alternativ über den Parameter -f verwendet werden können.

Ein weiteres Beispiel:

cowsay -f bunny "blog.alonso.ch"

Müsste zu folgendem Resultat führen:

 ________________
< blog.alonso.ch >
 ----------------
  \
   \   \
        \ /\
        ( )
      .( o ).

Natürlich kann die Kuh auch über die Pipe gefüttert werden.

Ein letztes Beispiel:

cat /proc/meminfo | grep MemFree | cowsay -f tux

Müsste zu folgendem Resultat führen:

  ____________________
< MemFree: 369624 kB >
 --------------------
   \
    \
        .--.
       |o_o |
       |:_/ |
      //   \ \
     (|     | )
    /'\_   _/`\
    \___)=(___/

Natürlich kann die Kuh noch viel mehr, siehe Manpage