Stoppt die Vorratsdatenspeicherung! Jetzt klicken &handeln! Willst du auch an der Aktion teilnehmen? Hier findest du alle relevanten Infos und Materialien:
 
 

Kurztipp: Mit Bash neuste Datei(en) in einem Verzeichnis finden

Geschrieben am 31. März 2011 um 16:52 Uhr 2 Kommentare

In meinem Fall möchte ich den aktuellsten MySQL-Dump ermitteln.

ls -tl /var/backups/mysql/*.sql.gz|head -n1|awk '{print $8}'

Um z.B. die drei aktuellsten Dateien zu finden, verwendet man head -n3.

 

apticron+apt-listbugs: Nie mehr ein Update verpassen

Geschrieben am 1. Dezember 2007 um 13:58 Uhr Kein Kommentar

Der geplagte Sysadmin hat den ganzen Tag soviel zu tun – eines davon ist, die ausstehenden Patches im Auge zu behalten. Üblicherweise werden dazu RSS-Feeds und Mailinglisten abonniert und im Falle von Debian regelmäßig

aptitude update && aptitude dist-upgrade

ausgeführt, um nach Aktualisierungen der Debian-Pakete zu suchen.

Was für selbst compilierte Software nicht so richtig geht, ist für die Debian-Pakete möglich: Die Automatisierung des Checks.

Es gibt einige Admins, denen der manuelle Updatevorgang auch noch zu müselig ist und die das Update (mit Parametern) ebenfalls via cron erledigen. Ich bin allerdings der Meinung, dass dies zu “gefährlich” ist, da es in manchen Fällen vorkommt, dass die geupdateten Dienste nicht mehr starten oder andere Fehler produzieren. Ein waches wachsames Auge des Sysadadmins kann da schon helfen.

Also suchte ich nach einer Möglichkeit zeitnah über neue Pakete und deren Bugfixes informiert zu werden und fand sie:

apticron informiert via Mail, sobald neue Pakete zur Verfügung stehen. Im Zusammenspiel mit dem Perl-Skript apt-listbugs sieht man in der Infomail (und auch bei jedem manuellem Updatevorgang) auch gleich, welche Bugs gefixt wurden und kann so nach Wichtigkeit das Update planen.

So sieht eine Beispielmail dann im Ergebnis aus:


apticron report [Sat, 01 Dec 2007 06:35:14 +0100]
========================================================================

apticron has detected that some packages need upgrading on: 

	fqdn.tld
	[ 123.123.123.123 ]

The following packages are currently pending an upgrade:

	libmysqlclient15off 5.0.32-7etch3
	mysql-client-5.0 5.0.32-7etch3
	mysql-common 5.0.32-7etch3
	mysql-server-5.0 5.0.32-7etch3

========================================================================

Package Details:
Lese Changelogs...
--- Änderungen für mysql-dfsg-5.0 (libmysqlclient15off mysql-client-5.0 mysql-common mysql-server-5.0) ---
mysql-dfsg-5.0 (5.0.32-7etch3) stable-security; urgency=high

  * SECURITY:
    Fix for CVE-2007-5925: The convert_search_mode_to_innobase function in
    ha_innodb.cc in the InnoDB engine in MySQL 5.1.23-BK and earlier allows
    remote authenticated users to cause a denial of service (database crash)
    via a certain CONTAINS operation on an indexed column, which triggers an
    assertion error. (closes: #451235)

 -- Norbert Tretkowski <nobse@debian.org>  Thu, 15 Nov 2007 18:51:30 +0100

mysql-dfsg-5.0 (5.0.32-7etch2) stable-security; urgency=high

  * Security release prepared for the security team by the Debian MySQL
    maintainers. The patches were mostly taken from the Ubuntu project.
  * CVE-2007-2583: The in_decimal::set function in item_cmpfunc.cc in MySQL
    allowed context-dependent attackers to cause a denial of service (crash)
    via a crafted IF clause that results in a divide-by-zero error and a NULL
    pointer dereference. Closes: #426353
  * CVE-2007-2691: MySQL did not require the DROP privilege for RENAME
    TABLE statements, which allows remote authenticated users to rename
    arbitrary tables. Closes: #424778
  * CVE-2007-2692: The mysql_change_db function in MySQL did not restore
    THD::db_access privileges when returning from SQL SECURITY INVOKER
    stored routines, which allowed remote authenticated users to gain
    privileges. Closes: #424778
  * CVE-2007-3780: It was discovered that MySQL could be made to overflow
    a signed char during authentication. Remote attackers could use crafted
    authentication requests to cause a denial of service.
  * CVE-2007-3782: Phil Anderton discovered that MySQL did not properly
    verify access privileges when accessing external tables. As a result,
    authenticated users could exploit this to obtain UPDATE privileges to
    external tables.

 -- Christian Hammers <ch@debian.org>  Tue,  6 Dec 2007 21:54:01 +0100

========================================================================

You can perform the upgrade by issuing the command:

	aptitude dist-upgrade

as root on fqdn.tld

It is recommended that you simulate the upgrade first to confirm that
the actions that would be taken are reasonable. The upgrade may be
simulated by issuing the command:

	aptitude -s -y dist-upgrade
--  apticron

Zu installieren sind beide Tools ganz leicht über aptitude.

Notizzettel: DKIM und Postfix

Geschrieben am 25. November 2007 um 16:05 Uhr Kein Kommentar

Da ich mich mit DKIM im Zusammenhang mit Postfix noch einmal auseinander setzen will, hier mal als Merkzettel 2 Links zu Tutorials bzw. Konfigurationshinweisen…

Wenn ich das mal mit etwas Zeit umgesetzt habe, kommt hier sicherlich noch eine genauere Beschreibung meinerseits.

Ungeziefer jagen…

Geschrieben am 15. November 2007 um 11:11 Uhr Kein Kommentar

Wieder mal ein schönes Kunstwerk zum Schmunzeln… ;)

Tux jagt MSN

Quelle: linux-lernen.info (von Chris)

Linktip: ClamAV zur Spambekämpfung nutzen

Geschrieben am 12. November 2007 um 13:38 Uhr Kein Kommentar

Aus aktuellem Anlass möchte ich nochmals an die Möglichkeit erinnern, durch zusätzliche Signaturen in Clam-AV Spam zu erkennen. Gerade der PDF- und Bilder-Spam wird dabei sehr zuverlässig ausgesiebt.

ClamAV zur Spambekämpfung nutzen @ adminlife.net

Patch erzeugen mit diff

Geschrieben am 4. November 2007 um 11:44 Uhr 1 Kommentar

Es gibt Dinge, die macht man nicht oft genug, um sie sich wirklich zu merken. Daher kann ich ja mal meinen Blog als Notizzettel verwenden, wenn ihr gestattet.

Um einen Patch einer Datei zu erhalten macht man einfach folgendes:

diff -u datei.org datei.bearbeitet > datei.patch

Die Dateinamen sprechen für sich, die Option -u führt dazu, dass nicht nur die geänderte Zeile angegeben wird, sondern auch noch umgebende Zeilen. Wenn sich also durch Anwendung mehrerer Patches die Zeilennummern geändert haben, so findet man leichter die richtige Position.

Ein Beispiel dazu findet ihr unter der Quelle: DOLINUX Protokoll vom 21.11.2001

Apache2: Download von PHP-Files als Text zulassen

Geschrieben am 3. Oktober 2007 um 2:40 Uhr 6 Kommentare

Um php-Files innerhalb eines bestimmten Pfades statt der Ausführung sondern die Auslieferung als Download zu ermöglichen (z.B. für den WordPress-Downloadordner) muss man nur in das oberste Verzeichnis, welches dieses Verhalten zeigen soll, eine .htaccess-Datei mit folgendem Inhalt anlegen:

?View Code APACHE
# filename .htaccess (with dot!)
 
<FilesMatch "\.php$">
ForceType text/plain
</FilesMatch>

Der Download sollte ohne Neustart oder Reload des Apache-Webservers sofort funktionieren. Man kann es in diesem Fall auch nur als Viewer verwenden (allerdings ohne Syntax-Highlighting), denn der Browser zeigt die Datei direkt an.

Wer den Download erzwingen und die Anzeige im Browser vermeiden will, wählt statt des oben verwendeten Typs lieber:

?View Code APACHE
ForceType application/octetstream

Da es sich in dem Beispiel um einen regulären Ausdruck handelt, kann man es natürlich noch für vielfältig andere Formate und MIME-Typen verwenden.

duplicity-Patch für FTP mit Portangabe (0.4.4RC2)

Geschrieben am 2. Oktober 2007 um 15:00 Uhr 4 Kommentare

UPDATE: Der Patch wurde in den 0.4.4RC3 aufgenommen. :) Es besteht also kein Grund mehr für das manuelle Patchen. (zum offiziellen Changelog)

Da Daniel in dem HOWTO zu ftplicity nach einer Möglichkeit zur Verwendung eines anderen Ports beim Verbinden mit seinem FTP-Server gefragt hat und diese Möglichkeit bei duplicity scheinbar nicht ganz gegeben ist, habe ich mal fix einen Patch für die entsprechende Datei erstellt.

Das Interessante dabei ist, dass die Funktionen schon alle da sind (Port aus der URL herausfinden usw.), sie aber für FTP einfach nicht genutzt werden.

Patch für duplicity 0.4.4RC2 (backends.py)

Dieser Patch gestattet es, auch in FTP-URLs einen Port anzugeben a la “user@host:port/dir”. Der Port wird verwendet sobald eine Port-Angabe exisitiert und vom Port 21 (Standard) abweicht.

Die zu patchende Datei liegt in der Standardinstallation von der duplicity-Seite in /usr/lib/python2.4/site-packages/dulicity

Die Verwendung ist zwar bei mir getestet, erfolgt aber dennoch ohne Gewähr!

Auf Kommentare bin ich gespannt.

Bugs, bugs, bugs

Geschrieben am 28. September 2007 um 14:12 Uhr Kein Kommentar

Hier nur ein paar aktuelle Nachrichten zu – teils krassen – Sicherheitsproblemen kurz notiert:

Die Bugs sind bereits alle gefixt, die Updates sollten schnellstens eingespielt werden.

Offen ist noch dieser, zumindestens gibt es noch kein neues Debian-Paket:

Aber nicht nur wir müssen unsere Hausaufgaben machen:

Schon wieder ein neuer Etch-Kernel

Geschrieben am 1. September 2007 um 23:22 Uhr Kein Kommentar

Kommt mir das nur so vor oder ist die Häufigkeit der Kernel-Updates gerade etwas höher?!

Laut Log habe ich gerade am 25.08.2007 den Kernel aktualisiert (ja, mit etwas Verzögerung), aber nun schon wieder? Und wenn ich mir so ansehe, was so gefixt wurde, treibt mich auch gerade nicht so die Eile, denn nichts davon betrifft eines meiner Systeme direkt.

Nichts destotrotz möchte/muss/sollte man ja synchron mit Debian-Paketen bleiben und daher werde ich Upgrades demnächst durchführen.

Hier die Fixes @ Debian-Security — DSA-1363-1 linux-2.6

automysqlbackup: versionierte Sicherung von mysql-Datenbanken

Geschrieben am 26. August 2007 um 18:44 Uhr 10 Kommentare

Die Sicherung von Datenbanken ist immer wieder eine Aufgabe, die man schnell vergisst und, wenn man sich dann damit befasst, für Kopfschmerzen sorgen kann.

Die Gründe:

  • Während des Betriebs des Datenbankservers ist es meist nicht möglich einen konsistenten Abzug der Datendateien zu erhalten.
  • Ein Anhalten des Datenbank-Server hat aber Auswirkungen auf das gesamte System.
  • Selbst wenn man die Dateien kopieren kann, ist es nicht 100%ig sicher, dass man nach einem Absturz die Daten in einen neuen DB-Server mit vielleicht veränderter Versionsnummer einspielen/ einkopieren kann.

Es bietet sich daher an, statt der Datenbankdateien nur die gespeicherten Daten zu sichern. Dies ist mittels eines sog. dumps (eng. “Halde”) möglich, bei dem die Daten im Klartextformat ausgegeben und optimalerweise gleich in die Befehle eingeschlossen werden, die die Daten automatisiert wieder in einen neuen Datenbankserver einspielen können.

Auch wenn MySQL bereits von Hause aus Tools mitbringt, die diese Sicherungsmethode ermöglichen und auch Hilfstools wie phpMyAdmin eine Option zum Erzeugen von DB-dumps bieten, suchte ich eine noch simplere Methode, die ggf. noch Mehrwert bietet.

automysqlbackup

Das Projekt automysqlbackup ist unter sourceforge gelistet und derzeit in der Version 2.5 aktuell. Das Projekt scheint nicht mehr weiterentwickelt zu werden, denn der letzte Release ist vom 14.02.2006. Dies ist aber nicht weiter problematisch, da es sich im Prinzip nur um einen Wrapper für das mysql-tool mysqldump handelt und damit nicht sonderlich wartungs- oder weiterentwicklungsbedürftig ist.

Die Vorteile der Nutzung von automysqlbackup sind (von der Homepage):

  • Backup aller oder ausgewählter Datenbanken
  • gesamtes Backup in eine Datei oder einzelne Dateien pro Datenbank
  • Platzsparend durch wahlweise Komprimierung mit gzip oder bzip2
  • Sicherung auch von entfernten Servern
  • Manueller Start oder cron-job-Steuerung möglich
  • Ermöglicht die Zusendung des Logs oder der DB-Sicherung an eine bestimmte Mailadresse

Nach Befolgung der Installationsanweisungen auf der Homepage erzeugt das Tool regelmäßige Backups in dem gewählten Ordner und ermöglicht durch verschiedene Ordner ein versioniertes Backup, durch das man auch Zugriff auf ältere Versionen einer Datenbank hat.

Alles in allem ein sehr sinnvolles Tool und ich möchte es nicht mehr missen.

Fragen? Probleme? –> Schreib mir!

ftplicity: inkrementelle Backups sicher ablegen

Geschrieben am 17. August 2007 um 17:54 Uhr 74 Kommentare

ACHTUNG: Die in diesem Artikel besprochenen Versionen sowohl von ftplicity als auch duplicity sind bereits veraltet. Die grundsätzlichen Erklärungen sind zwar weiterhin valid, aber die Syntax oder Konfigurationsparameter könnten sich geändert haben. Bitte verwendet den Such-Tag “duplicity” bzw. den Such-Tag “ftplicity” und die Kommentare, um aktuelle Informationen zu finden.

Nachdem ich durch einen Beitrag von Matthias wieder mal erinnert wurde, dass nicht Jeder Backups macht bzw. sie aktuell hält, dachte ich, dass ich mal kurz einen Teil meiner Backuplösung vorstelle:

Vorteile

In einem (schon älterem) Artikel der c’t (13/2006) wurde ein Tool vorgestellt mit dem man eine einfache und sichere Backup-Strategie für z.B. Root-Server fahren kann. Das Tool heißt ftplicity und ist im Prinzip nur ein Wrapper für das umfangreichere duplicity. Wie der Name schon sagt, kann möchte ftplicity nur via FTP kommunizieren, denn dies ist laut c’t (und auch meiner Erfahrung nach) der häufigste und simpelste Weg einen Backupspace zu erreichen.

Nun beseitigt ftplicity bzw. das dahinterliegende duplicity gleich mehrere Probleme, die bei dem “plain old Dir-to-FTP-sync” enstehen:

  • Übertragungsqualität: FTP tendiert bei längeren durchgehenden Übertragungen (= eine große Datei) zu Fehleranfälligkeit und der ganze Upload muss noch einmal begonnen werden oder (was viel schlimmer ist) die Backupdatei ist zerstört/ fehlerhaft und lässt sich im Ernstfall nicht mehr richtig wiederherstellen.

    Lösung: kleine Dateien übertragen durch Erstellung von Volumes

  • Vertraulichkeit: Wer einen zweiten Server mit guter Anbindung hat braucht sich um diesen Punkt nicht zu sorgen, aber alle anderen, die entweder etwas Platz bei einem Bekannten in Anspruch nehmen oder von Ihrem Provider einen gewissen Platz an FTP-Space zur Verfügung gestellt bekommen (z.B. Strato, Hetzner) müssen sich schon fragen, ob denn der jeweilige Serveradmin nicht nachts mal aus Interesse sich durch das Mailbackup wühlt.

    Lösung: Verschlüsselung der Daten mittels GPG

  • Authentizität: Das oben genannte Problem wirft ebenfalls die Frage auf, wie weit man den so gesicherten Daten noch vertrauen kann, wenn “Unbekannte” auf die Daten Zugriff hatten. Nichts wäre wohl schlimmer, als dass man sich mit dem Restore auch gleich eine passwd-Datei mit neuen SSH-Usern runterzieht (nette Idee, btw).

    Lösung: Die Signatur der Daten mittels GPG, welche auch beim Restore geprüft werden.

  • Datenvolumen: Je mehr Daten man gesichert hat, desto leichter findet ein Restore statt. Allerdings nimmt damit auch das Übertragungsvolumen zu, was erstens mehr Backupzeit kostet und zweitens in den meisten Hosterverträgen auch begrenzt ist.

    Lösung: Inkrementelle Backups (nur geänderte Daten) unter Nutzung der erprobten rsync-Bibliothek

Diese Probleme werden also von der hier vorgestellten Lösung bereits vermieden. Aber – richtig eingerichtet – kann es noch mehr:

Weitere Vorteile

  • Einzelrestore: Wer kennt das nicht: Schnell mal die Config vom Mailserver bearbeitet und statt die alte Zeile auszukommentieren löscht man sie… und siehe da, rien ne va plus! Der Mailserver startet nicht mehr und man kann sich partout nicht mehr an die besagt Zeile erinnern. Wohl dem, der ein Backup von den Configdateien hat und noch wohler dem, der nicht das ganze Backup wiederherstellen muss, um die Einzeldatei zu erhalten.

    Lösung: ftplicity besitzt einen Befehl, mit dem man Einzeldateien oder -ordner an einen beliebigen Ort wiederherstellen kann

  • Versionierung: Manchmal wäre es schön, wenn man eine Datei nicht nur in dem Zustand des nächtlichen Backups erhielte, sondern sich auch mal die Config ansehen könnte, wie sie vor zwei Wochen war.

    Lösung: Ein Argument des oben erwähnten Befehls ermöglicht es, ein Datum oder einen Zeitraum für die wiederherzustellende Datei anzugeben.

So, als ich diese Punkte damals alle las, war für mich klar: Das will ich haben! Wenn es DIR jetzt auch so geht, dann lies jetzt weiter, denn ein kleines Howto folgt. weiterlesen…

Hacking in action

Geschrieben am 17. August 2007 um 3:23 Uhr Kein Kommentar

Im Blog von Matthias Kellermann (www.adminlife.net) habe ich einen sehr interessanten Link gefunden.

Ein erfahrener Linuxer untersucht dabei einen Server eines Freundes, stellt fest, dass dieser gehackt wurde und untersucht den ganzen Vorfall.

Hier gehts zur interessanten Analyse…

screen: Start eines Linux-Programms als daemon

Geschrieben am 16. August 2007 um 19:53 Uhr 2 Kommentare

Auch wenn es vielleicht nur mich interessiert:

Das Problem: Ein Programm soll im Hintergrund laufen, also unabhängig von der aktuellen (Putty-)Sitzung, damit es auch noch dem Logout weiterläuft.

Die Lösung: Es gibt diverse Methoden für diese Problemstellung, das Programm screen ist für mich aber die schönste:
screen -dmS SITZUNGSNAME Programm.sh

Es startet das Programm in einer separaten Sitzung. Die offenen Sitzungen kann man sich mit
screen -ls
anzeigen lassen und (sofern nur eine läuft) sich mit
screen -r
mit der Sitzung verbinden um die Programmausgaben zu sehen.

Wichtig ist, sich dann mittels “Ctrl+A” danach “D” von der Sitzung zu trennen, damit man das Programm nicht aus Versehen beendet.

Die noch viel weitreichenderen Möglichkeiten findet man wie immer mit
screen --help
oder
man screen

Ich hoffe, das kann so manchen helfen, der nach einer schnellen, sauberen Lösung sucht.

PS: Es macht natürlich nur für Programme Sinn, die auch von selbst im Loop laufen (z.B. Server).

Neuere Beiträge »