Got error ‘Primary script unknown’ after update PHP-FPM + Apache 2.4

After a update_versions in DirectAdmin I got this error on a sites error log:

[client] AH01071: Got error 'Primary script unknown\n'

The URL it self gave:

File not found.

Yesterday everything was working fine. After updating Apache 2.4.x and PHP-FPM (5.6) I figured it had to do something with those services.

But the app (CodeEgniter) was running in a subfolder. The main folder contained a WordPress install and was working fine.

So after some time I tried to play with the .htaccess file, and I succeeded. I changed this old .htaccess:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
RewriteBase /fc2/

To this new variation:

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

Don’t ask me why, but the Primary script unknown is gone.

So in this case it had nothing to do with ProxyHandler, ProxyPass or other configuration issues between PHP-FPM and Apache. Just a little .htaccess error which results in a bug.

Days of the week array

This snippet will give you the days of the week but human-readable in your own language.

today=$(date +%u)



Now you can use $today and $yesterday as variables in folder names, usefull for back-ups.

Move Proxmox VM to another node

If you migrate a VM to another node via Proxmox it will rsync the server twice. But you never know how long the first one will take. So before I use the migrate function I use this little line to do a manual rsync.

This way I can rsync whenever I want and start the migrate on the end of the evening so the night will not take unexpected long 🙂

/usr/bin/rsync -aHAX --delete --numeric-ids --sparse /var/lib/vz/private/100 root@

Install SpamFighter and BlockCracking with Exim and dkim

This is what I use to set-up my DirectAdmin boxes with Exim, SpamAssassin, SpamFighter, BlockCracking and dkim.

cd /usr/local/directadmin/custombuild 

./build set clamav yes
./build set exim yes
./build set eximconf yes
./build set eximconf_release 4.4
./build set blockcracking yes
./build set easy_spam_fighter yes
./build set spamassassin yes
./build set sa_update daily

./build update
./build exim
./build clamav
./build spamassassin
./build exim_conf

wget -O /etc/exim.dkim.conf

service exim restart

After that you can use the file /etc/virtual/domainips to set the interface IP for exim:


MySQL automatic restore script

We had a .sql export from a MySQL databaseserver from all the databases. In our case the filenames were made up like:


So I wrote a little bash script to recreate all the databases and import it’s data:



for file in `ls $folder/mysqldump-*.sql`
echo $file
IFS='-' read -r -a array <<< "$file"
echo ${array[2]}
echo "create database ${array[2]}" | mysql -u da_admin -ppassword
mysql -u da_admin -pnAcQKhIK ${array[2]} < $file


After a little while all databases were full with content again 🙂

Install Dutch Language in DirectAdmin Enhanced skin

I use this code to install the Dutch Language (Nederlandse taal) on all my servers. It will get automatically updated if there is a new version available.

cd /usr/local/directadmin/data/skins/
unzip -o
chown -R diradmin:diradmin enhanced/images/
chown -R diradmin:diradmin enhanced/lang/
chown diradmin:diradmin enhanced/files_custom.conf
chmod -R 755 enhanced/images/
chmod -R 755 enhanced/lang/
chmod 755 enhanced/files_custom.conf
rm -f

After running this code you can select the Dutch Language (nl) in the Modify User page in DirectAdmin.

How to reinstall the default Enhanced skin

If you need to reinstall the default DirectAdmin skin Enhanced you can use this code:

rm -f /usr/local/directadmin/data/skins/enhanced
cd /usr/local/directadmin/data/skins/
mkdir -p enhanced
tar -xzf enhanced.tar.gz

After this code the enhanced skin will be updated and be default again. Please not that you update DirectAdmin before reinstalling (and updating) the default Enhanced skin.

Nginx expire dates for static files

If you are using nginx as proxy this snippet will help you set the correct expire dates for static files like css, jpg etc:

[code]location ~* \.(txt|xml|js)$ {
expires 8d;

location ~* \.(css)$ {
expires 8d;

location ~* \.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav|mp4|m4v|ogg|webm|aac)$ {
expires 8d;

location ~* \.(jpg|jpeg|png|gif|swf|webp)$ {
expires 8d;

This is will ensure the webserver to tell the browser that the served files are valid for 8 days and will not be downloaded again.