Um Kontrolle darüber zu haben, wie viel Last der Apache wegnimmt bzw. generell zu sehen, was gerade läuft, müßen wir status_module / ExtendedStatus aktivieren.

Dort (irgendwo) folgendes eintragen:

Apachen neustarten:

Wie Ihr (hoffentlich) gesehen habt, ist das der Eintrag für ein 64-Bit Suse System. (Zeile 1 = lib64)
Falls eure mod_status.so wo anders liegt, dann einfach den Pfad ändern.

Das ganze läßt sich dann wie folgt von der Browseroberfläche aufrufen:

Wer nicht möchte, das man diese Datei so öffendlich aufrufen kann, der sollte den Pfad ändern (/server_status).
Am sichersten wäre es allerdings eine Passwortabfrage zu generieren.

Als erstes mal die aktuelle Version suchen. Wir nehmen NICHT das rpm Packet sonder das tar.gz packet.

Wir benötigen zum installieren python

danach das ausgewählte Paket downloaden

entpacken das ganze und ins Verzeichnis wechseln

und installieren

da es nicht viel Installationstext ist, können wir das ruhig mal schnell überfliegen. Nicht das irgendwo ein ERROR auftaucht.

Es werden diverse default Scripts mit beigelegt. Diese müßen jetzt noch entsprechend umbenannt werden. Da wir das Installationsverzeichniss später wieder löschen wollen, kopieren wir diese Dateien gleich an die richtige stelle.

Nun müßten diese Scripte noch entsprechend angepasst werden.

Das Script ist für Redhat oder Fedora geschrieben. Also gleich mal die erste nicht auskommentierte Zeile auskommentieren.
Bei Version 2.6 ist es Zeile 12 ( # SECURE_LOG = /var/log/secure)
Und dafür die Raute bei Zeile 18 rausnehmen ( SECURE_LOG = /var/log/messages )

In Zeile 108 finden wir
DENY_THRESHOLD_INVALID = 5 => das sind die Fehlversuche für Benutzern die es gar nicht gibt
Setzen wir den auf 1. Denn der Benutzername gibt es ja nicht.. warum 4 weitere Versuche zulassen

In Zeile 119 finden wir
DENY_THRESHOLD_VALID = 10 => das sind die Fehlversuche bei vorhanden Benutzern (kann bleiben)

In Zeile 129
DENY_THRESHOLD_ROOT = 1 => das ist der root. Da ich viel mit dem Root arbeite setze ich den für meinen Fall auf 3. Das müsst ihr aber selbst entscheiden.

In Zeile 500 finden wir dann den letzten wichtigen Eintrag. Wie lange soll diese IP Adresse geblockt werden.
Wir tragen hier ERSTMAL 1 Minute ein. Wenn wir das Blocken später getestet haben, könnt Ihr es selbst entscheiden, ob 5 min oder 5 Tag.
Hilfe findest du in den Zeilen 49 – 64
DAEMON_PURGE = 1m

Optimal
In Zeile 219 finden wir eine Einstellung, wo man seine Email Addy angeben kann. Man erhält bei Sperrung entsprechenden Staus.

Das wars schon. Mit [ESC] :wq beenden wir das ganze und gehen zum:

Zeile 14 müßen wir bearbeiten:
ALT: DENYHOSTS_BIN = „/usr/bin/denyhosts.py“
NEU: DENYHOSTS_BIN = „/usr/local/bin/denyhosts.py“

Das wars schon. Mit [ESC] :wq beenden

Nun wollen wir ja sicherlich, dass diese Sicherheitseinstellung auch beim nächsten neustart automatisch mitstartet.

Den Dienst selbst starten wir mit:

Das ganze sollte bei Erfolg sich so melden
starting DenyHosts: /usr/bin/env python /usr/local/bin/denyhosts.py –daemon –config=/usr/share/denyhosts/denyhosts.cfg

Nun wollen wir das ganz noch schnell testen. Damit wir uns aber nicht selbstaussperren, öffnen wir eine 2te SSH Sitzung und geben dort entweder ein Namen ein, den es nicht gibt (sofortige Sperrung) oder 3 mal ein falsches root pass ein.
Klappt das, dann könnt Ihr euch nicht unmittelbar danach einwählen. Wartet eine Minute. Wenn Ihr eine Email Addy eingetragen habt, könnt Ihr die Zeit dazu nutzen um diese abzurufen. Denn dort müßte jetzt ein Mail sein, das ein User (ihr) gesperrt worden seit.
Wenn nach einer Minute die Passwortabfrage wieder sichtbar ist, habt ihr anscheint alles richtig gemacht. Denkt daran, die 1m in der config wieder hoch zu setzen. 1d (1Tag) wäre bei einem Server, wo nur Ihr zugriff habt, das mindeste. Hab Ihr Kunden, die auch per SSH zugreifen, sollte man den wert wohl runter stellen. Der Default von 1h sollte hier ausreichend sein. (Strafe muss ja schließlich sein :-> )
Nicht vergessen denyhost zu restarten

da liegen die geblockten IPs drin. Einfach rauslöschen. Die Änderung ist sofort wirksam (also ohne denyhost restart)

Der FCKEditor selbst ist bisher der einzigste Editor, der sauber und korrekt mit Joomla zusammenarbeitet.

Allerdings sind hier ein paar Einstellungen notwendig, damit der Bilderupload funktioniert:
Die config.php in im Filemanger muß hier den akteuellen Gegebenheiten Angepasst werden:
In unseren Fall hießt das:

Die config.php liegt bei uns im folgenden Pfad

In der config.php ist nun folgendes Eingetragen was dem jeweiligen System angepasst werden muß:

Für unsere System heißt das, das diese Einstellung 2 Ordner zu weit rausspringt.
Entfernen wir ../../ ist der Pfad korrekt und der Editor zeigt schon mal erste Reaktionen.

Die anderen beiden Einstellungen sind in der config ja entsprechend auskommentiert.

Problem:

Setzt man den FCKEditor ein und man möchte nun z.b. ein Bild (das sich bereits auf dem Server befindet) auswählen, und dieser dann den kompletten Dokumenten-Verzeichniss anzeigt, dann habt Ihr einen falschen Vhost.

Kurzfristige Lösung wäre den Pfad per Hand immer anzupassen: ALSO:

/srv/www/htdocs/ks0125/html/images/stories/key.jpg => geht nicht
/images/stories/key.jpg => Klappt

Man kann aber auch in die VHOST seines Apachen gehen und den Documenten Root entsprechend anpassen:

FALSCH:

RICHTIG: (KEIN / am Ende)

Ab der Version 10.3 von OpenSuse (andere Distris wären denkbar) werden „nur“ noch 15 Partionen unterstützt.
Dies hat was mit dem neuen libata zu tun. Dieser Dienst ist für die Ansprechung der Festplatten zuständig.
Hat man mehr als 15 Laufwerke, der muß die Installation mit folgenden Boot-Befehl starten:

Es wird nun die alte libata verwendet.