Linux: Prozess inkl. Unterprozessen (Children/Childs/Grandchilds) beenden ("killen")

Um unter Linux (z.Bsp. Debian Jessy) eine komplette Prozessstruktur (Prozessbaum) mit einem Befehl sofort zu beenden, hilft folgendes Syntax:

kill `pstree -l -p PID |grep "(*)" -o |tr -d '()'`

Beispiel:

Sie haben ein Backup mit der PID (Prozess ID) 12345 gefunden, welchen Sie sofort beenden möchten. Wie viele solcher Prozesse haben Backups häufig Unterprozesse (Childs) laufen, welche durch die «normalen Kill-Befehle» nicht immer automatisch mit beendet werden. Der Befehl für den Beispiel PID 12345 würde also lauten:

kill `pstree -l -p 12345 |grep "(*)" -o |tr -d '()'`

Virtualmin: Datenbank Prefix für SubServer anpassen (Domainname als Prefix)

Wenn Sie in VirtualMin einen SubServer (Unter-Server) zu einem bestehenden Server einrichten, dann wird dabei (sofern ausgewählt) auch eine mySQL Datenbank automatisch angelegt.

Dabei wird in den Standardeinstellungen nur der Prefix des neuen SubServers als Datenbankname ausgewählt:

Beispiel:
Ihre bestehende Domain (= aktueller virtueller Server):

mydomain.com

Prefix des erstellten SubServers ist "test" ... dann heißt Ihre neue mySQL Datenbank:

test

Das kann nicht nur zu ärgerlichen und nervigen Problemen führen (wenn z.Bsp. ein anderer Benutzer die gleiche Idee für seine Domain hat), sondern wird mit der Zeit auch sehr unübersichtlich. Besser ist es daher, die Domain des virtuellen Servers als Prefix für den Datenbanknamen zu verwenden.

  1. Gehen Sie dafür in die "Server Templates" in Virtualmin
  2. Wählen Sie die "Settings for Sub-Servers" aus
  3. Dort wählen Sie aus der DropDownbox den Eintrag "mySQL Database"
  4. Aktivieren Sie bei "Default database name" den Eintrag "Template"
  5. Geben Sie in das angezeigte Feld folgenden Text ein:
    ${USER}_${PREFIX}
  6. Klicken Sie auf "Save"

Wenn Sie jetzt einen neuen SubServer erstellen (sh. Beispiel oben), dann wird Ihnen folgende mySQL Datenbank angelegt:

mydomain_test

Debian 8 (jessie): "systemd-fsck" deaktivieren

Das kommt groß in Mode: Das System prüft und korrigiert was das Zeug hält und keiner fragt den Administrator (root) … der hat ja sowieso nix zu melden und keine Ahnung von seinem System !?

Seit Debian V8 (Codename «jessie») prüft das System jetzt bei JEDEM Booten mit «fsck» auf Fehler. Leider auch bei Servern mit diversen TB Platten und RAID Systemen ... und das kann dauern … richtig dauern. Ist ja nur ein Server, den braucht schon keiner im System ;o/

Um diesen Wahnsinn zu beenden, hilft folgende Einstellung:

nano /etc/default/rcS

Dort die Option «FSCKFIX» auf «no» setzen:

FSCKFIX=no

SVN: Struktur automatisch in einem Befehl anlegen

Um in einem SVN (= Versionsverwaltung) die benötigten Verzeichnisse automatisch mit einem Basis-Commit erstellen zu lassen, benutzt man folgenden Befehl:

svn mkdir --parents file:///home/customer/svn/project/{trunk,tags,branches} -m "initial dir creation"

Debian VirtualBox headless: VirtualBox Extension Pack

Wenn Sie unter Linux Debian (hier Debian jessie) ein Update der VirtualBox Software durchgeführt haben (z.Bsp. automatisch durch ein Linux Update von Debian V7 auf Debian V8), dann erhalten Sie meist Fehlermeldungen, welche Sie zur Installation des "Oracle VM VirtualBox Extension Pack" auffordern.

Wenn Sie den folgenden Installationsbefehl ausführen, ...
VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.3.18-96516.vbox-extpack
... dann erhalten Sie eine Fehlermeldung:
Extension pack 'Oracle VM VirtualBox Extension Pack' is already installed. In case of a reinstallation, please uninstall it first
Deinstallieren Sie das (alte) Extension Pack daher mit folgendem Befehl:
VBoxManage extpack uninstall 'Oracle VM VirtualBox Extension Pack'
Anschließend können Sie das aktuelle Extension Pack wieder problemlos installieren:
VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.3.18-96516.vbox-extpack

Linux: Screen Session durch PID wieder aufnehmen

Wenn Sie unter Debian, Ubuntu oder einer anderen Linux Distribution den "screen" Befehl benutzen, um eine Bash Session z.Bsp. per SSH über einen Session-Timeout hinweg zu behalten, dann können Sie diese screen-Session sehr einfach wieder aufnehmen:

Starten Sie "screen" einfach mit dem Paramter "-r" zur Wiederaufnahme:

screen -r

Wenn Sie diverse screen-Sessions (screen-Sitzungen) offen haben, dann können Sie auch eine bestimmte Session ansprechen:

Der Befehl "screen -r" liefert Ihnen dann eine Auflistung der aktiven Screens:
There are several suitable screens on:
6722.pts-2.demo      (Detached)
9263.pts-0.demo      (Detached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.
Geben Sie nun den folgenden Befehl (angepasst für Ihre gewünschte Sitzung) ein:
screen -r 9263.pts-0.demo

Hilfereiche Java Fehlermeldung

Java zeigt bei einigen Installationen in letzter Zeit folgende (aussagekräftige) Fehlermeldung an:

Wenn Sie, wider Erwarten, nicht reagieren können, dann klicken Sie bitte auf das rote Kreuz zum Schließen der Installation. Starten Sie anschließend die Installation erneut als Administrator:

1. Halten Sie die «Strg» Taste auf Ihrer Tastatur gedrückt
2. Klicken Sie die Installationsdatei mit der rechten Maustaste an
3. Wählen Sie aus dem Popupmenü den Eintrag «Als Administrator ausführen ...»

mySQL: Laufende Prozesse auflisten

Um bei einem laufenden mySQL Server alle laufenden (aktiven und wartenden) Prozesse und Befehle auflisten zu können, nutzen Sie folgenden Befehl auf der Kommandozeile:

mysqladmin -u[Benutzer] -p[Passwort] processlist
Alle Prozesse ds Servers erhalten Sie als "root". Im folgenden Beispiel ersetzen Sie das Passwort "12345" bitte durch Ihr "root" Passwort:
mysqladmin -uroot -p12345 processlist
Dieser Befehl kann Ihnen dabei helfen, kritische, langsame oder abgestürzte Befehle zu erkennen. Meist ist im ersten Blick nur der komplette mySQL Prozess auffällig langsam oder braucht besonders viel CPU Zeit; durch den o.a. Befehl können Sie hingegen den einzelnen Verursacher innerhalb des mySQL Servers herausfinden. Das kann die Suche nach der Ursache erheblich vereinfachen und beschleunigen.

modx: Backend verstecken (hide the modx-manager)

Um in einer modX Installation das Backend zu verstecken, führen Sie einfach folgende Schritte aus:

  1. Denken Sie sich einen alternativen Namen aus:
    In diesem Beispiel benutze ich «max»
    Bitte ersetzen Sie im folgenden immer «max» durch Ihre gewählte Bezeichnung
  2. Benennen Sie das Verzeichnis «manager» um in «max»
  3. Öffnen Sie die Datei «core/config/config.inc.php»
  4. Gehen Sie zum Bereich der Manager-Pfad-Definition und ersetzen Sie in Zeile 2+3:
    if (!defined('MODX_MANAGER_PATH')) {
      $modx_manager_path= '/your-path-to-public/manager/';
      $modx_manager_url= '/manager/';
      define('MODX_MANAGER_PATH', $modx_manager_path);
      define('MODX_MANAGER_URL', $modx_manager_url);
    }

    zu
    if (!defined('MODX_MANAGER_PATH')) {
      $modx_manager_path= '/your-path-to-public/max/';
      $modx_manager_url= '/max/';
      define('MODX_MANAGER_PATH', $modx_manager_path);
      define('MODX_MANAGER_URL', $modx_manager_url);
    }
  5. Löschen Sie den Cache indem Sie einfach alle Dateien und Verzeichnisse im Order «/core/cache» löschen

Ab jetzt können Sie sich unter «/max» anstelle von «/manager» anmelden.

Die Anzahl der Brute-Force-Loginversuche wird deutlich abnehmen und dadurch ist Ihre modx Installation wieder ein wenig sicherer geworden.

WordPress und die Sicherheit

Wir bieten derzeit ein paar WordPress Plugins an und freuen uns über die positive Resonanz und aktive Nutzung durch unsere Kunden. Aber neuerdings versucht das WordPress Team, neue Plugins nach individuellen Richtlinien zu prüfen. An sich ist eine solche Prüfung eine gute Sache und längst überfällig. Wenn jedoch jeder freiwillige WordPress Helfer (also "Mitarbeiter") seinen eigenen und dann noch flexiblen Wunsch-Maßstab ansetzt - dann wird eine effektive Prüfung Glückssache.

Genau in diesem Dilemma befinden wir uns derzeit mit unsererm neuesten Plugin "Abuse Protector" für WordPress.

Es schützt WordPress Systeme vor den steigenden, nervigen und teils riskanten Bot-Angriffen. Dabei gibt es diverse Angriffsmuster. Bemerkt unser Plugin einen solchen Angriff, meldet es diesen sofort an unsere Datenbank ... nicht mit dem Namen der Webseite sondern zum Schutz mit einem Schlüssel (API Key) kodiert. Dadurch können alle anderen Seiten mit unserem Plugin beim ersten Besuch einer solchen IP diesen Zugriff direkt blockieren - natürlich profitiert jeder davon. Denn ein Angriff in Kapstadt kann nach wenigen Sekunden auch Ihren Blog schützen.

Und WordPress ? Man hat uns untersagt, das Plugin mit dem folgenden Lizenzzusatz zu vertreiben:

"Die kommerzielle Nutzung und Verbreitung ist untersagt"

WordPress: "Das müsse man jedem erlauben."

Das sehen wir anders, denn wir haben das Plugin in unserer Freizeit erarbeitet und wir sehen es partout nicht ein, dass eine Firma damit Geld macht und Sie als unseren Kunden ggf. dafür zahlen sollen. Zudem soll das Plugin den API-Key nicht automatisch bei der Installation erzeugen. Man fordert, dass unserere Kunden sich bei uns extra registrieren und sich einen API-Key manuell abholen oder zuschicken lassen. Dann soll der Key in dem Plugin manuell eingetragen werden. Der Weg sei besser (sagt das WordPress Team).

Das finden wir garnicht, denn (neben dem Zusatzaufwand für unsere Kunden):

  • Was passiert denn bei einem Fehler beim Aptippen des API-Keys ?
  • Oder beim fehlerhaften Kopieren des Keys (z.Bsp. Vergessen des letzten Zeichens) ?

Wir müssten dann sofort jeden Key mit unserem Server verifizieren und unsere Kunden um Korrektur bitten ... viel zu viel Aufwand für ein einfaches Plugin, oder ? Wer soll denn diesen Aufwand (zusätzliche bereiche auf unserer Webseite) programmieren, pflegen und schützen ? Wir ? Klar. Aber das System ist kostenlos und wir haben auch nicht alle zeit der Welt für kostenlose Plugins und Arbeiten.

Fazit: Wir werden das Plugin nur auf unserer Seite anbieten und nicht auf WordPress.

Zudem bauen wir das Plugin um für andere CMS Systeme ... denn dort hat man Interessen an unserem System.