WordPress – Changing Permalinks

Hi,

in the net you find tons of posts what changes you have to made if you wanna change your permalinks to postname. But mostly in combination with an apache webserver.

So im using nginx and this is a bit more difficult.

But i found the solution.

Simply add this line to your vhost configuration:


if (!-e $request_filename) {
rewrite ^.*$ /index.php last;
}

For apache just place an empty .htaccess file in your wordpress-folder, give it 666 permissions and insert this:


# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Spacewalk – Automatic Creation of a Kickstartable Tree

Spacewalk is a tool for (mainly) managing and provisioning server or client linux-systems.

I’m using for a few months now and yeah. Its not well documented, especially the provisioning part.

Spacewalk uses kickstart as provisioning tool.

You have to add a kickstartable tree. Then make your kickstart distribution and then finally your kickstart profile where you define the properties for your system.

The problem is the kickstartable tree. The documentation says, simple mount a distribution dvd and then use the path where the distro is mounted.

Uhm… no. wont work for CentOS 🙂

I found a script on the net wich dowloads all the distribution files that you need. its name is mkelfs.

The github entry was updated in Nov 2015 but it still works.

Just download it from here: https://github.com/stdevel/mkelfs/blob/master/mkelfs.py

Before you can use the command you have to create the folders in which the script deploys the distro data.

mkdir /var/satellite/kickstart_tree

Here is the command you need for CentOS 7 (dont be suprised, the reason why Centos is not in the parameters is that its a default value 😀 )

./mkelfs.py --release 7 --arch x86_64 -b centos7-x86_64

-b is the name of your base channel

CentOS 7 – Firewalld allow all traffic from a Server

I hate the default firewall in CentOS. 😀

Its so unneeded complicated that a simple Access-Rule seems to be as hard as climbing up the mount everest.

So, my problem was i wanted to configure a CentOS-Server for our backup system. Backup client was installed but the CentOS-Firwall was blocking the traffic.

Our backup-system needs several ports (in range) and communication comes from multiple servers.

But i didnt wanted to allow a port range because of security. So open up traffic for our backup-subnet was the way to go.

Here is the command:

firewall-cmd --permanent --zone=public --direct --add-rule ipv4 filter IN_public_allow 0 -s xx.x.xx.x/xx -j ACCEPT

firewall-cmd --reload

Have fun 😀

Dell MD3220 – reset preferred controller module

Recently, id resetted the controller modules of the Dell MD3220 Storage Array while troubleshooting some strange events (it didnt change anything, ok its not a windows system ;D ).

After this, the virtual disks changed their path to the second controller. Ok, its not “mission critical”, but you always get the message that the virtual disks are not one the preferred path.

So, as described in my last post, this is also one of the operations that cant be made with MD Storage Manager.

This command will help: smcli.exe your-md-dns-name-or-ip -c "reset storageArray virtualDiskDistribution;"

Ps: Here you can find the Command Line Guide for SMCLI:

http://ftp.respmech.com/pub/MD3000/CLIA20EN.pdf

Dell MD3220 – how to reset unreadable Sectors statistic

Hy,

recently, i had the problem that our Dell MD3220 Storage Array was showing Alerts regarding unreadable sectors on disk drives.
Stupidly it didnt say which disk is affected. I thought that this is a old message, which is not cleared.

So my first step was resetting the statistic. If there are really defective sectors, the message will show up again.

The trick is, you cant do this over the gui (Dell MD Storage Manager) – you have to use SMCLI (which is part of the installation of the storage manager).

Here is the command:

scmli.exe your-md-dns-name-or-ip -c "clear allVirtualDisks unreadableSectors;"

The message is gone in my case.

Ps: Here you can find the Command Line Guide for SMCLI:

http://ftp.respmech.com/pub/MD3000/CLIA20EN.pdf

KDE4 Lock Screen Background anpassen

Hallo,

wenn ihr unter KDE4 den Standard Screen-Locker eingestellt habt, könnt ihr dort auch ein eigenes Hintergrundbild verwenden.

KDE Plasma < 5.5

Dazu müsst ihr als erstes eurer Image in den entsprechenden Pfad kopieren.

cp Pictures/xxx.jpg /usr/share/kde4/apps/ksmserver/screenlocker/org.kde.passworddialog/contents/ui/

Danach öffnet ihr die Datei main.qml mit eurem favorisierten Editor

und geht zur Image {-Sektion

Dort tauscht ihr die Zeile

source: theme.wallpaperPathForSize(parent.width, parent.height)

durch den Pfad zu eurem Image.

source: xxx.jpg

KDE Plasma 5.5

Bei KDE-Plasma 5.5 funktioniert leider der oben genannten Mechanismus NICHT mehr…

Dort wird einfach folgender Befehl ausgeführt:

kcmshell5 screenlocker

Dort kann man über das Menü ein Bild auswählen.

LSI-Raid Controller Megacli Kommandos

Hallo,

einige meiner Server, die ich betreue, haben LSI-RAID-Controller verbaut. Bei den LSI-Controllern gibt es die Möglichkeit über Linux diese komplett zu Konfigurieren und Abzufragen.
Leider ist das Megacli-Kommando extrem umfangreich und auch sehr unübersichtlich. Daher wollte ich einfach mal ein paar nützliche Kommandos mit euch teilen.

Übersicht der konfigurieren Virtual-Drives und Status

`which megacli` -LDInfo -Lall -aALL

Output:
Virtual Drive: 0 (Target Id: 0)
Name :
RAID Level : Primary-6, Secondary-0, RAID Level Qualifier-3
Size : 9.093 TB
Sector Size : 512
Is VD emulated : No
Parity Size : 3.637 TB
State : Optimal
Strip Size : 256 KB
Number Of Drives : 7
Span Depth : 1
Default Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Disk's Default
Encryption Type : None
PI type: No PI

Is VD Cached: No

Status aller Festplatten mit den Werten Größe, Backplane, Slot, Firmware Status und Temperatur

`which megacli` -PDList -a0 | grep -e '^Coerced Size:' -e '^Enclosure Device ID:' -e '^Slot Number:' -e '^Firmware state:' -e '^Drive Temperature :'

Output:
Enclosure Device ID: 19
Slot Number: 0
Coerced Size: 1.818 TB [0xe8d00000 Sectors]
Firmware state: Online, Spun Up
Drive Temperature :39C (102.20 F)

Dann hatte ich das Problem, dass ich eine Festplatte getauscht habe, dabei die Global Spare eingesprungen ist und dadurch der Controller angefangen hat zu beepen.
Auch nach dem Rebuild blieb der Alarm. Per megacli kann man diesen auch stumm stellen.

megacli -AdpSetProp -AlarmSilence -aALL

Adapter 0: Set alarm to Silenced success.

Exit Code: 0x00

Man kann auch den Alarm permanent abschalten. Dazu folgendes Kommando:

megacli -AdpSetProp -AlarmDsbl -aALL

Mit folgendem Kommando kann man den Alarm wieder anschalten:

megacli -AdpSetProp -AlarmEnbl -aALL

WordPress XMLRPC Angriff

Hallo,

diesmal etwas in eigener Sache. Und zwar war mein Blog in letzter Zeit öfters down und ich habe mich gefragt, was da los ist.Der Server ging irgendwann in die Knie und warf beim Laden der Seite eine 502 – Bad Gateway Fehler.

Analyse des Angriffs

Im Log des Webservers tauchen folgende Meldungen auf:


/var/log/nginx/access.log

xx.xxx.xx.xxx - - [22/Jan/2015:03:36:59 +0100] "POST /xmlrpc.php HTTP/1.0" 403 529 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
xx.xxx.xx.xxx - - [22/Jan/2015:02:57:50 +0100] "POST /wp-login.php HTTP/1.1" 200 1326 "http://warpdrive-on.de/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0"

Nach kurzer google-Recherche stellte sich heraus, dass es in den letzten WordPress Versionen eine Sicherheitslücke gibt, und zwar die xmlrpc-Schnittstelle. Darüber können Blogeinträge über externe Programme hinzugefügt werden.

Schließen der Sicherhheitslücke

Da ich diese Möglichkeit sowieso nicht benutze, entschied ich, den Zugriff auf die Datei xmlrpc.php direkt im Webserver zu sperren.

Dies kann im nginx-Webserver in der virtual Host-Konfiguration mit folgendem Eintrag eingestellt werden:


/etc/nginx/sites-enabled/default

location /xmlrpc.php {
deny all;
}

Bot-Zugriffe mit fail2ban blockieren

Damit war das Problem erst einmal behoben. Da ich aber trotzdem noch zahlreiche Seitenaufrufe hatte (die Zahlen hatten nichts mit der Realität zu tun 🙂 ), dachte ich mir, wenn ich grad dabei bin sperre ich diese vermeindlichen Bots auch noch aus. Dazu gibt es die Möglichkeit, diese mit der Software Fail2ban zu blocken.

Als erstes legt man idealerweise im Nginx conf.d Verzeichnis eine Datei bots.map an.


/etc/nginx/conf.d/bots.map

map $http_user_agent $is_bot {
default 0;

~Sogou 1;
~Abonti 1;
~Pixray 1;
~Python 1;
~Spinn3r 1;
~libwww-perl 1;
~Wget 1;
~Curl 1;
~Ezooms 1;
~mShots 1;
~SemrushBot 1;
~Exabot 1;
~ZmEu 1;
~iCjobs 1;
~QuerySeekerSpider 1;
~Baiduspider 1;
~AhrefsBot 1;
~CareerBot 1;
~coccoc 1;
~MJ12bot 1;
~SeznamBot 1;
~spbot 1;
~ShowyouBot 1;
~adressendeutschland 1;
~PagesInventory 1;
~aboutWebSearch 1;
~Java 1;
~JCE 1;
~bitlybot 1;
~WeSEE 1;
~updown_tester 1;
~200PleaseBot 1;
~Nutch 1;
~HTTP_Request 1;
~AnyOther 1;
~Crawler 1;
~BLEXBot 1;
~yacybot 1;
~Cliqzbot 1;
}

Durch das Nginx-Module map wird entschieden, ob ein spezifizierter User-Agent als Bot definiert wird (die Variable $is_bot also als Wert 1 enthält) oder nicht.

Anschließend bindet man man die Datei als Include in die Nginx.conf ein:


/etc/nginx/nginx.conf

http {

include /etc/nginx/conf.d/bots.map;

}

Dann wird noch in der vhost konfiguration abgefragt, ob die is_bot Variable gesetzt ist und wenn ja, wird der Zugriff gesperrt.


/etc/nginx/sites-enabled/default

server {
...

if ( $is_bot ) {
return 444;

}

}

Um hier eine dauerhafte Lösung zu schaffen, sollten bereits abgewiesene Bots dauerhaft gesperrt werden. Dazu wird in Fail2ban eine Ressource angelegt, die das Access-Log des Webservers überwacht und schaut, ob der Statuscode 444 auftaucht. Diese IP-Adressen würden dann blockiert werden.

Zuerst legt man also eine neue Filter-Regel an. Im Verzeichnis /etc/fail2ban/filter.d/ eine Datei nginx-bots.conf angelegt.


/etc/fail2ban/filter.d/nginx-bots.conf

# Fail2Ban configuration file
#
# List of bad requests
#
# Server: Nginx
# Author: Sergej Müller
#

[Definition]

# Option: failregex
# Notes : Detection of 444 requests.
# Values: TEXT
#

failregex = ^ - .+ 444 0 ".+"$

# Option: ignoreregex
# Notes : Regex to ignore.
# Values: TEXT
#

ignoreregex =

Damit die Filterregel auch geladen wird, muss folgendes in der Datei /etc/fail2ban/jail.conf angehängt werden:


/etc/fail2ban/jail.conf

[nginx-bots]

enabled = true
port = http
filter = nginx-bots
logpath = /var/log/nginx/access.log
maxretry = 0
findtime = 86400
bantime = -1


Anschließend sowohl nginx als auch Fail2ban durchstarten und der Anti-Bot-Schutz ist aktiv.