Open Source Archive -

Angriff auf Joomla!-Installation

Vor ein paar Tagen wurde eine auf meinem vServer laufende Joomla!-Instanz massiv angegriffen. Der Inhaber dieser Seite bekam in ca. einer Stunde über 600 Mails vom Nachrichtensystem. So etwas ist bedauerlich und nicht gerade schön mit anzusehen.

Was war passiert?

Die Analyse des Logs /var/log/mail.log zeigte, dass Mails im 5-6 Sekunden-Takt vom Server an den Administrator gesendet wurden.

Was wurde kurzfristig unternommen?

Zu allererst wurde der Versand der Systemmails der Joomla!-Installation deaktiviert. Damit konnte die Spam-Welle vorerst gestoppt werden. Bei der weiteren Analyse stellte sich heraus, dass die User-Registrierung aktiv war und sich über 600 User registriert hatten. Die dazu verwendeten eMail-Adressen hatten alle die Domain-Endung .ru. Im nächsten Schritt wurde die Registrierung ebenfalls deaktiviert. Warum diese aktiv war, kann ich leider nicht mehr nachvollziehen. Alle verdächtigen registrierten User der Seite wurden gelöscht.

Wie ging es weiter?

Da ich zu dem Zeitpunkt immer noch nicht genau wusste was genau passiert war, habe ich ein älteres Backup der Datenbank eingespielt (zum Glück werden Backups der Datenbanken, wie im Artikel „MySQL- Sicherung ohne Passwort im Script“ beschrieben, täglich automatisch angelegt). Nach dem Einspielen stellte sich heraus, dass hier nur die bekannten Administratoren als Benutzer in der Joomla!-Installation gespeichert waren. Die Registrierung wurde wieder deaktiviert und so die Sicherheitslücke geschlossen. Abschließend habe ich nachgeschaut, ob Dateien oder Verzeichnisse der Joomla!-Installation in den letzten Tagen verändert wurden. Dazu wechselte ich in das entsprechende Verzeichnis

cd /var/www/html/joomla

1	cd /var/www/html/joomla

und suchte die Änderungen der Dateien der letzten fünf Tage

find . -mtime -5 -type f

1	find . -mtime -5 -type f

Ausgabe:

./logs/error.php
./configuration.php

1 2	./logs/error.php ./configuration.php

sowie den Änderungen der Verzeichnisse

find . -mtime -10 -type d

1	find . -mtime -10 -type d

Ausgabe:

./tmp

./tmp

Die Dateien und Verzeichnisse wurden dann meinerseits überprüft. Da es hier keinerlei Auffälligkeiten gab, konnte auf das Einspielen eines Backups der kompletten Installation verzichtet werden.

Was war nun tatsächlich passiert?

Es konnten sich von außen User registrieren. Die so erstellten Accounts wurden aber nicht aktiviert, da die angegeben eMail-Adressen wahrscheinlich nicht valide waren. Das System verschickte jedoch bei jeder neuen Registrierung eine entsprechende eMail an den Superadministrator. So kam es zu einer massiven Welle von Registrierungsbestätigungen. Da die registrierten Accounts nicht aktiviert werden konnten, hatten die Aktionen keine Auswirkungen auf das System.

Kann das nochmal vorkommen?

Durch die deaktivierte Registrierung kann es zu dieser Art von Angriffen nun nicht mehr kommen.

Nextcloud-Client – Quelle kaputt

Wer den Nextcloud-Client wie im Artikel „Nextcloud-Client für Debian 9“ beschrieben installiert hat, wird evtl. festgestellt haben, dass die Quelle von opensuse.org kaputt ist.

Abhilfe schafft ein Austausch des vorhandenen Eintrags in der /etc/apt/sources.list.d/nextcloud-client.list. Dazu öffnet man diese mit:

nano /etc/apt/sources.list.d/nextcloud-client.list

1	nano /etc/apt/sources.list.d/nextcloud-client.list

Nun wird die Zeile

deb http://download.opensuse.org/repositories/home:/ivaradi/Debian_9.0/ /

1	deb http://download.opensuse.org/repositories/home:/ivaradi/Debian_9.0/ /

durch

deb http://ppa.launchpad.net/nextcloud-devs/client/ubuntu zesty main

1	deb http://ppa.launchpad.net/nextcloud-devs/client/ubuntu zesty main

ersetzt und die neue Quelle mit

apt-key adv --recv-key --keyserver keyserver.ubuntu.com AD3DD469

1	apt-key adv --recv-key --keyserver keyserver.ubuntu.com AD3DD469

verifiziert.

Viel Spaß!

Stretch auf den Raspberry Pi

Gestern habe ich nun auch meinen Raspberry Pi Raspbian Stretch spendiert. Ich war dabei etwas skeptisch, ob Flightradar mit dem neuen stabilen OS zurecht kommt. Meine Bedenken waren aber völlig unbegründet.

Zuerst wird in der /etc/apt/sources.list

sudo nano /etc/apt/sources.list

1	sudo nano /etc/apt/sources.list

„jessie“ durch „stretch“ ersetzt und die Datei mit Ctrl + o gespeichert und der Editor mit Ctrl + x verlassen. Dann werden die Quellen neu eingelesen

sudo apt update

1	sudo apt update

und Stretch installiert.

sudo apt dist-upgrade

1	sudo apt dist-upgrade

Zum Schluss sollte man mit

sudo apt autoremove

1	sudo apt autoremove

noch etwas aufräumen.

InfinityBook Pro 13 – Randnotiz

Im Moment läuft bei mir auf dem InfinityBook Pro 13 der Firma TUXEDO Debian Testing mit Kernel 4.12. Wie schon erwartet (siehe Artikel „TUXEDO InfinityBook Pro 13 – Teil 3„), konnte die Akkulaufzeit mit Kernel 4.11 noch einmal deutlich gepusht werden. Im Normalbetrieb mit WLAN und angeschlossener Funkmaus konnte ich eine Steigerung von 5:20 Stunden auf immerhin 7:00 Stunden verzeichnen. Damit kommt es zu einem Zuwachs von immerhin knapp über 30% gegenüber Ubuntu 16.04 LTS. Im hier schon oft erwähnten Standby-Test gibt das Pro 13 übrigens erst nach immerhin 14 Stunden auf.

geschätzte Akkulaufzeit während des Betriebs

Fazit

Ab Kernel 4.11 kann man, wie auch unter der von TUXEDO angepassten Xubuntu-Version, mit deutlich längeren Akkulaufzeiten des TUXEDO InfinityBook Pro 13 rechnen. Damit kann auf dem Gerät schon fast das Energieverbrauchsniveau wie unter Windows 10 erreicht werden.

TUXEDO InfinityBook Pro 13 – Teil 4

Ubuntu 16.04, Windows 10 und Debian 9 konnte ich bislang auf dem TUXEDO InfinityBook Pro 13 testen. Nun geht es an das Innere des Pro 13. Das Gerät wird wie hier von TUXEDO beschrieben geöffnet.

Quelle: YouTube

Nach dem Lösen von 15 Schrauben und der Entfernung des Bodens erhält man einen Überblick über die Erweiterbarkeit, die zur Verfügung stehenden Schnittstellen bzw. die austauschbaren Komponenten.

Das TUXEDO InfinityBook Pro 13 von innen

Die wichtigsten Komponenten und Schnittstellen sind auf dem Bild farblich markiert. Oben links sieht man den Lüfter, welcher bei Bedarf mit Pinsel, Sauger oder Druckluft leicht vom eingezogenen Staub befreit werden kann. Rechts daneben befinden sich zwei SO-DIMM-Sockel, in denen beim Testgerät ein 16GB-Riegel verbaut ist. Da nur ein Sockel belegt ist, besteht die Möglichkeit den RAM des InifinityBook problemlos zu erweitern. Rechts daneben sieht man drei M.2-Ports. Der obere mit 42mm ist mit dem WLAN-Modul belegt. Daneben befindet sich die CMOS Batterie, welche gewechselt werden kann. Der darunter liegende 60mm-Steckplatz ist frei. Wiederum darunter, im 80mm-Port, befindet sich die M.2 NVMe SSD 250 GB Samsung 960 EVO. Unten links hat man die Option eine 2,5″ HDD/SSD in den für SATAIII-Festplatten vorgesehenen Stauraum einzubauen.

InfinityBook Pro 13 mit zusätzlich eingebauter 2,5″ SSHD

Rechts daneben ist der Akku verbaut, welcher mit ein paar Handgriffen (lösen von 5 Schrauben) ausgebaut bzw. gewechselt ist.

Die Lautsprecher des InfinityBookPro 13 liegen, wie man auf den Bildern erkennen kann, links neben dem SATAIII-Port und rechts neben dem Akku.

Fazit

Das TUXEDO InfinityBook Pro 13 lässt sich recht gut und leicht erweitern. Arbeits- und Festplattenspeicher können einfach hinzu gesteckt werden. Der Arbeitsspeicher kann maximal bis auf 32 GB DDR4 aufgerüstet werden. Beim Massenspeicher hat man die Wahl zu einer M.2 SSD zu greifen oder eine 2,5″ SATAIII HDD, SSHD bzw. SSD zu verwenden. Der Akku ist zwar fest verbaut, lässt sich jedoch gut demontieren und bei Bedarf durch einen neuen ersetzen. Die CMOS-Batterie sowie das WLAN-Modul können ebenfalls schnell gewechselt werden.

Bei der Montage bzw. Demontage sollte man darauf achten, dass sensible Aluminiumgehäuse vor Kratzern entsprechend zu schützen.

Vorschau

Im nächsten Artikel werde ich berichten, wie sich das TUXEDO InfinityBook Pro 13 mit dem von TUXEDO angepassten Xubuntu schlägt.

Wie wäre es mit einem Rolling Release?

Ein Rolling Release ist schon eine feine Sache. Ständig wird das Betriebssystem mit neuen Software- und Sicherheitspaketen versorgt. Neuere Kernel finden zeitnah den Weg ins Projekt. Das System ist somit immer aktuell.

Was gibt es nun für Möglichkeiten? Typische Vertreter der Rolling Releases sind Arch, Gentoo, Solus oder Manjaro. Ich habe mich jedoch vor einigen Tagen für Debian Testing entschieden. An dieser Stelle muss man aber erwähnen, dass es sich beim Testing-Zweig nur solange um ein Rolling Release handelt bis Testing den Status Freeze erreicht. Dieser Status hält ca. drei bis vier Monate an. In dieser Zeit werden keine neuen Softwarepakete und Kernel mehr aufgenommen. Nur noch Sichereitsupdates fließen in das Projekt, bis Debian eine neue stabile Version veröffentlicht. Testing wird dann zu Stable und alles beginnt von neuem. Da es also einen gewissen Zeitrum gibt, wo keine Neuerungen in Debian Testing einfließen, ist Testing kein wirkliches Rolling Release.

Entsprechende Images werden wöchentlich hier zur Verfügung gestellt.

Wie wechselt man hingegen von Debian Stretch auf Debian Testing. Das ist relativ einfach. Zuerst bearbeitet man die /etc/apt/sources.list. Hierbei sollten alle Fremdquellen auskommentiert werden. Danach werden die Einträge „Stretch“ durch „Testing“ ersetzt. (siehe Screenshot)

Das Upgrade wird dann wie folgt angestoßen.

# apt update && apt dist-upgrade

1	# apt update && apt dist-upgrade

Bevor man sich auf Debian Testing einlässt, sollte man zuvor natürlich ein Backup anlegen!

Es kann natürlich beim Einsatz zu Problemen kommen. Bugs werden i.d.R. aber schnell gefixt.

TUXEDO InfinityBook Pro 13 – Teil 3

Nachdem ich Ubuntu und Windows auf dem TUXEDO InfinityBook Pro 13 getestet habe, wollte ich wissen, wie sich das frisch veröffentlichte Debian 9 Stretch auf diesem Gerät schlägt. Hatte man bei der Installation von Debian 8 noch arge Installationsprobleme mit dem Kernel 3.16, so verlief das EFI-Setup mit Stretch problemlos. Die Funktionstastenbelegung funktioniert nach dem Setup fast komplett. Der Flugmodus über die Taste F11 lässt sich mit einem kleinen Eingriff in die Konfiguration des Grub aktivieren. Die verbaute Hardware wird vollständig erkannt. Um allerdings das WLAN-Modul zu aktivieren, ist es nötig den unfreien Intel-Treiber iwlwifi (non-free) einzuspielen. Dieses Problem trat schon beim Vorgängermodell auf. Da das Pro 13 über eine LAN-Schnittstelle verfügt, kann das Paket aber problemlos aus den Quellen contrib non-free installiert werden. Die Webcam sowie der Card-Reader funktionierten auf Anhieb und die Grafik läuft einwandfrei.

Debian 9 Stretch Übersicht (GNOME-Version 3.22)

Debian 9 verrichtet ansonsten seinen Dienst erwartungsgemäß stabil und zuverlässig. Das System startet einen Tick schneller als unter Ubuntu, in knapp 16 Sekunden. Allerdings muss man bei der Performance der Akkulaufzeit ein paar Abstriche machen. Nach 7:30 Stunden im üblichen Standby-Test geht dem Gerät die Puste aus. Allerdings kam ich beim Arbeiten mit dem InfinityBook auf eine ähnliche Laufleistung wie unter Ubuntu. Das Notebook quittierte seinen Dienst nach 5:10 Stunden. Verantwortlich hierfür ist der, wie unter der LTS, eingesetzte Kernel 4.9. Später sollte eine deutliche Verbesserung spürbar sein, wenn neuere Kernel über die Backports frei gegeben und auch eingespielt werden. Die CPU-Temperatur liegt im Normalbetrieb bei ca. 46°C. Dabei ist der Lüfter nicht zu hören.

Natürlich habe ich auch wieder etwas „Duke Nukem 3D: Megaton Edition“ via Steam gezockt, um die CPU etwas an die Grenzen zu führen. Die Temperatur stieg in den Spitzen auf maximal 100°C. Der Lüfter machte dann natürlich ordentlich Geräusche. Das InfinityBook ist eben kein Gaming Notebook, sondern richtet sich eher an Entwickler, Reisende, Normalanwender, aber auch Blogger.

Fazit

Das TUXEDO InfinityBook Pro 13 kam im Test mit Debian 9 Stretch gut zurecht. Es wurden im Test mit dem Gerät normale Aufgaben mit LibreOffice, Gimp, Inkscape, Firefox etc. erledigt. Selbst nicht so anspruchsvolle Spiele laufen auf dem InfinityBook gut. Allerdings wirkt hier der Lüfter störend.

Die Akkulaufleistung ist mit Debian 9 vergleichbar wie unter Ubuntu 16.04 LTS. Mit dem Kernel 4.9 kommt dabei die getestete Linux-Distribution auch hier nicht ansatzweise an ein Windows heran. Die Problematik ist bekannt. Jedoch besteht im Hinblick auf neuere und aktuellere Kernel etwas Hoffnung.

Alles in Allem kann man aber sehr gut auf dem InfinityBook mit Debian 9 stable arbeiten. Das TUXEDO InfinityBook Pro 13 ist also auch für eingefleischte Debianer einen Blick wert. Wobei man beim WLAN-Modul zu einem unfreien Treiber greifen muss.

Vorschau

Im nächsten Artikel werde ich berichten, wie das TUXEDO InfinityBook Pro 13 von innen aussieht und wie es um die Erweiterbarkeit bestellt ist.

MySQL- Sicherung ohne Passwort im Script

Nach dem ich nun nieder geschrieben hatte, wie ich meine SQL-Datenbanken automatisch sichere, kamen einige gute Anregungen in den Kommentaren. Darauf hin habe ich das System etwas umgestellt. Dazu wurde zu allererst der Storage vom root auf einen User übertragen. Somit konnte ich auch den Cronjob für den User einrichten. Der Eintrag, wie im ersten Artikel „MySQL-Sicherung“ in /etc/crontab wurde wieder entfernt. und der Cron neu gestartet.

Als eingeloggter User habe ich dem selbigen mit

crontab -e

1	crontab -e

folgenden Befehl eingetragen.

0 2 * * * /home/user/MySQLscript.sh

1	0 2 * * * /home/user/MySQLscript.sh

Dann wurde eine ~/.my.cnf

nano ~/.my.cnf

1	nano ~/.my.cnf

mit entsprechendem Inhalt erstellt. Diese enthält das MySQL root Passwort.

[client]
user=root
password=meinpasswort

[client]

user=root

password=meinpasswort

„meinpasswort“ musste hier natürlich angepasst werden. Nach dem Abspeichern wurden der Datei die Rechte 600 vergeben.

chmod 600 ~/.my.cnf

1	chmod 600 ~/.my.cnf

Im Anschluss habe ich ein neues Script mit dem Inhalt

#!/bin/sh
mysqldump in********** | gzip > /samba_share/backup/in**********/in**********-$(date +%Y-%m-%d).sql.gz
mysqldump cc********** | gzip > /samba_share/backup/cc**********/cc**********-$(date +%Y-%m-%d).sql.gz
mysqldump bc********** | gzip > /samba_share/backup/bc**********/bc**********-$(date +%Y-%m-%d).sql.gz
mysqldump kt********** | gzip > /samba_share/backup/kt**********/kt**********-$(date +%Y-%m-%d).sql.gz
mysqldump wo********** | gzip > /samba_share/backup/wo**********/wo**********-$(date +%Y-%m-%d).sql.gz
mysqldump ne********** | gzip > /samba_share/backup/ne**********/ne**********-$(date +%Y-%m-%d).sql.gz
mysqldump cy********** | gzip > /samba_share/backup/cy**********/cy**********-$(date +%Y-%m-%d).sql.gz
mysqldump pe********** | gzip > /samba_share/backup/pe**********/pe**********-$(date +%Y-%m-%d).sql.gz
mysqldump ma********** | gzip > /samba_share/backup/ma**********/ma**********-$(date +%Y-%m-%d).sql.gz
mysqldump pr********** | gzip > /samba_share/backup/pr**********/pr**********-$(date +%Y-%m-%d).sql.gz
mysqldump ro********** | gzip > /samba_share/backup/ro**********/ro**********-$(date +%Y-%m-%d).sql.gz
mysqldump bcc********* | gzip > /samba_share/backup/bcc*********/bcc*********-$(date +%Y-%m-%d).sql.gz
mysqldump pi********** | gzip > /samba_share/backup/pi**********/pi**********-$(date +%Y-%m-%d).sql.gz

#!/bin/sh

mysqldump in********** | gzip > /samba_share/backup/in**********/in**********-$(date +%Y-%m-%d).sql.gz

mysqldump cc********** | gzip > /samba_share/backup/cc**********/cc**********-$(date +%Y-%m-%d).sql.gz

mysqldump bc********** | gzip > /samba_share/backup/bc**********/bc**********-$(date +%Y-%m-%d).sql.gz

mysqldump kt********** | gzip > /samba_share/backup/kt**********/kt**********-$(date +%Y-%m-%d).sql.gz

mysqldump wo********** | gzip > /samba_share/backup/wo**********/wo**********-$(date +%Y-%m-%d).sql.gz

mysqldump ne********** | gzip > /samba_share/backup/ne**********/ne**********-$(date +%Y-%m-%d).sql.gz

mysqldump cy********** | gzip > /samba_share/backup/cy**********/cy**********-$(date +%Y-%m-%d).sql.gz

mysqldump pe********** | gzip > /samba_share/backup/pe**********/pe**********-$(date +%Y-%m-%d).sql.gz

mysqldump ma********** | gzip > /samba_share/backup/ma**********/ma**********-$(date +%Y-%m-%d).sql.gz

mysqldump pr********** | gzip > /samba_share/backup/pr**********/pr**********-$(date +%Y-%m-%d).sql.gz

mysqldump ro********** | gzip > /samba_share/backup/ro**********/ro**********-$(date +%Y-%m-%d).sql.gz

mysqldump bcc********* | gzip > /samba_share/backup/bcc*********/bcc*********-$(date +%Y-%m-%d).sql.gz

mysqldump pi********** | gzip > /samba_share/backup/pi**********/pi**********-$(date +%Y-%m-%d).sql.gz

erstellt und dieses mit

chmod +x ~/MySQLscript.sh

1	chmod +x ~/MySQLscript.sh

ausführbar gemacht. Um die Datenbanken besser auseinander halten zu können, bekamen alle Datenbanken dieses Mal ein separates Verzeichnis.

cd /samba_share/backup

1	cd /samba_share/backup

mkdir in********** cc********** bc********** kt********** wo********** ne********** cy********** pe********** ma********** pr********** ro********** bcc********* pi**********

1	mkdir in******** cc****** bc****** kt****** wo****** ne****** cy****** pe****** ma****** pr****** ro****** bcc***** pi********

Nun werden die Datenbank-Sicherungen jeden Morgen 2:00 Uhr in von einander getrennten Verzeichnissen komprimiert abgelegt.

Der Servercow-Storage wurde mit der Nextcloud-App „External Storage“ in die Cloud eingebunden und die Sicherungen landen so regelmäßig auf meinem Notebook.

MySQL-Sicherung

Inspiriert durch den Artikel „Backup oder Datensicherung eines root-Servers / vServers / VPS„von Bitblokes habe ich mir Gedanken gemacht, wie ich meine MySQL-Datenbanken vernünftig und regelmäßig sichern kann. Die Snapshots von Servercow sind schon sehr gut, um ein Backup des ganzen Servers zu erstellen. Jedoch ist man hin und wieder auf eine einzelne Datenbank angewiesen.

Da ich bei Servercow einen zusätzlichen RAID5 HDD-Netzwerkspeicher von 150 GB und diesen in meine Nextcloud eingebunden habe, kann ich dort bequem meine Datenbanksicherungen ablegen. Bei jeder Synchronisation zu Hause, landen dann die Sicherungen auf meinem Notebook.

Da ich bisher meine Datenbanken manuell mit mysqldump durchgeführt habe, wollte ich das Ganze nun automatisieren.

Dazu wurde das Script MySQLscript.sh

# nano /root/MySQLscript.sh

1	# nano /root/MySQLscript.sh

mit folgendem Inhalt erstellt.

#!/bin/sh
mysqldump -u root -pmeinpasswort in********** > /samba_share/backup/in**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort cc********** > /samba_share/backup/cc**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort bc********** > /samba_share/backup/bc**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort kt********** > /samba_share/backup/kt**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort wo********** > /samba_share/backup/wo**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort ne********** > /samba_share/backup/ne**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort cy********** > /samba_share/backup/cy**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort pe********** > /samba_share/backup/pe**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort ma********** > /samba_share/backup/ma**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort pr********** > /samba_share/backup/pr**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort ro********** > /samba_share/backup/ro**********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort bcc********* > /samba_share/backup/bcc*********-$(date +%Y-%m-%d).sql
mysqldump -u root -pmeinpasswort pi********** > /samba_share/backup/pi**********-$(date +%Y-%m-%d).sql

#!/bin/sh

mysqldump -u root -pmeinpasswort in********** > /samba_share/backup/in**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort cc********** > /samba_share/backup/cc**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort bc********** > /samba_share/backup/bc**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort kt********** > /samba_share/backup/kt**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort wo********** > /samba_share/backup/wo**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort ne********** > /samba_share/backup/ne**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort cy********** > /samba_share/backup/cy**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort pe********** > /samba_share/backup/pe**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort ma********** > /samba_share/backup/ma**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort pr********** > /samba_share/backup/pr**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort ro********** > /samba_share/backup/ro**********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort bcc********* > /samba_share/backup/bcc*********-$(date +%Y-%m-%d).sql

mysqldump -u root -pmeinpasswort pi********** > /samba_share/backup/pi**********-$(date +%Y-%m-%d).sql

Dabei ist „in**********“ der Name meiner ersten Datenbank. Der Eintrag „meinpasswort“ im Script muss natürlich durch das MySQL root Passwort ersetzt werden.

Im Anschluss wird das Script ausführbar gemacht

# chmod +x MySQLscript.sh

1	# chmod +x MySQLscript.sh

und der Befehl mit

# nano /etc/crontab

1	# nano /etc/crontab

in den crontab eingetragen.

0 2 * * *       root    /root/MySQLscript.sh

1	0 2 * * * root /root/MySQLscript.sh

So wird nach dem Neustart von Cron jeden Tag um 2:00 Uhr eine Sicherung jeder einzelnen Datenbank im Verzeichnis /samba_share/backup abgelegt.

# /etc/init.d/cron restart

1	# /etc/init.d/cron restart

Upgrade auf Roundcube 1.3.0

Gestern wurde Roundcube in Version 1.3.0 released. Ich habe das Upgrade heute gleich auf meinem vServer angestoßen. Dazu wurde der Download von Roundcube 1.3.0 in /var/www/html abgelegt.

# cd /var/www/html

1	# cd /var/www/html

# wget https://github.com/roundcube/roundcubemail/releases/download/1.3.0/roundcubemail-1.3.0-complete.tar.gz

1	# wget https://github.com/roundcube/roundcubemail/releases/download/1.3.0/roundcubemail-1.3.0-complete.tar.gz

Der Tarball wurde entpackt,

# tar xfz *.tar.gz

1	# tar xfz *.tar.gz

das neue Verzeichnis betreten

# cd roundcubemail-1.3.0

1	# cd roundcubemail-1.3.0

und das Upgrade ausgeführt. Der Pfad muss hierbei entsprechend angepasst werden. Da meine Roundcube-Installation in /var/www/mail/rc liegt, sieht die Eingabe wie folgt aus:

# ./bin/installto.sh /var/www/mail/rc

1	# ./bin/installto.sh /var/www/mail/rc

Das Upgrade verlief ohne Probleme. Zum Schluss konnten das temporäre Upgrade-Verzeichnis und der Download gelöscht werden.

# cd ..

# cd ..

# rm -r roundcubemail-1.3.0

1	# rm -r roundcubemail-1.3.0

# rm *.tar.gz

1	# rm *.tar.gz