debian

Setting up WordPress Multisite on Debian 5.0 (lenny)

This post explains how to install WordPress 3.x on a Debian lenny and to set up a multisite installation on your Debian server.

All the blogs will log into the same file /var/log/apache2/access.log; the first column will be the blog host and port (see the LogFormat configured below).

This chapter is based on information collected at http://codex.wordpress.org/Create_A_Network and in /usr/share/doc/wordpress/README.Debian.

All WordPress blogs will use the same shared PHP code in /usr/share/wordpress.

Assumptions

  • Main website will be http://domain.com
  • Blogs will be under http://${blogname}.domain.com

File uploaded into the main blog (www.domain.com) will be stored in /srv/www/wp-uploads/domain.com/%year/%month/

Files uploaded into the *.domain.com blogs will be stored in /usr/share/wordpress/wp-content/blogs.dir/${blog_id}/files/%year/%month/, where ${blog_id} is the numeric id of the blog, as managed by the Multisite feature.

Configuration of Debian lenny-backports repository and installation

WordPress 3.x is not in lenny so we have to use the backport repository.
Excute this as root:

echo "deb http://backports.debian.org/debian-backports lenny-backports main" >> /etc/apt/sources.list

cat < /etc/apt/preferences
Package: *
Pin: release a=lenny-backports
Pin-Priority: 200
EOF

apt-get update
apt-get -t lenny-backports install wordpress

Installation of non free swf plugin

As stated in /usr/share/doc/wordpress/README.Debian WordPress originally comes with a Flash-based tool that allows to upload files. However, that tool violates the Debian Policy, as stated in the
bug #591195. That is why this tool is not shipped with the Debian package anymore. If you want to enable this feature, you need to install the Flash file yourself with the following command:

   
wget -O /usr/share/wordpress/wp-includes/js/swfupload/swfupload.swf http://core.svn.wordpress.org/branches/3.0/wp-includes/js/swfupload/swfupload.swf

Configure your DNS server

Add the following records in your zone (I suppose you know how to deal with your DNS zone):

; wp multisite
$ORIGIN        IN A       ${IP}
www            IN A       ${IP}
*.domain.com.  IN CNAME   www

Apache configuration

Configure the vhost_combined log format in /etc/apache2/apache2.conf modifying the default one:

   
LogFormat "%{Host}i:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined

Configure apache in /etc/apache2/sites-available/wordpress-multisite :


UseCanonicalName    Off

ServerAlias *.domain.com domain.com
ServerName www.domain.com
DocumentRoot /srv/www/domain.com/

Options All
ServerAdmin you@domain.com

# Store uploads of www.domain.com in /srv/www/wp-uploads/$0
RewriteEngine On
RewriteRule ^/wp-uploads/(.*)$ /srv/www/wp-uploads/%{HTTP_HOST}/$1


        Options FollowSymLinks
        AllowOverride All


CustomLog /var/log/apache2/access.log vhost_combined

# this is needed when activating multisite, WP needs to to a 
# fopen("http://randomname.domain.com") to verify
# that apache is correctly configured
php_admin_flag allow_url_fopen on


Configure /etc/wordpress/htaccess:


RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
## uploaded files
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]
## real files dealt directly
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
## other go through index.php
RewriteRule . index.php [L]

Enable the config executing this as root:

a2ensite wordpress-multisite
a2enmod rewrite && a2enmod vhost_alias
/etc/init.d/apache2 restart

Setting some permissions

# required to allow the main site to upload content
chown www-data /srv/
chown www-data /srv/www/

# required to allow subdomains site to upload content
chgrp www-data /usr/share/wordpress/wp-content/blogs.dir/
chmod g+w /usr/share/wordpress/wp-content/blogs.dir/

# required in order to be able to install/update themes/plugins 
# from the webgui (only on the main site)
chown -R www-data:www-data /usr/share/wordpress/wp-content/
chown -R www-data:www-data /usr/share/wordpress/wp-admin/ 

Creating main site

At this stage we can create the main site using this bash script:

bash /usr/share/doc/wordpress/examples/setup-mysql -n main domain.com

This script creates the DB & tables and it also creates a file called /etc/wordpress/config-domain.com.php.

You should end up with the following files:

  • /etc/wordpress/config-domain.com.php
  • /srv/www/domain.com symlink to -> /usr/share/wordpress
  • /srv/www/wp-uploads/domain.com/

Activating Network (aka multisite)

At this stage you should log into http://domain.com and follow the on screen instructions.
Once you are in the backend you can than click into the “Tools -> Network” link and enable the mulsite, this will create some tables in your db and it will ask you to copy&paste some lines into /etc/wordpress/config-domain.com.php:

define( 'SUBDOMAIN_INSTALL', true );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'domain.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

define( 'AUTH_KEY', 'blabla' );
define( 'SECURE_AUTH_KEY', 'blabla' );
define( 'LOGGED_IN_KEY', 'blabla' );
define( 'NONCE_KEY', 'blabla' );
define( 'AUTH_SALT', 'blabla' );
define( 'SECURE_AUTH_SALT', 'blabla' );
define( 'LOGGED_IN_SALT', 'blabla' );
define( 'NONCE_SALT', 'blabla' );

define( 'MULTISITE', true );

# for debugging purposes only
# define('WP_DEBUG', true);

After that you’re ready to go 😀

Logging as super admin and going into the SuperAdmin webgui area you can create new subdomains (blogs), and users, when you can create blogs an email is sent to the owner, you can personalize templates, decide how much storage space you want to assign to every single blog, etc, etc.

At this point you should be able to also install/upgrade plugins and themes straight from the web gui.
Note that define('WP_CORE_UPDATE', false); in your config file will disable the auto update, your wordpress update cycle will be managed using Debian apt tool.

That’s it folks, any question please comment 🙂

Complimenti Debian. Si salvi chi puo’!

MANNAGGIA A DEBIAN! ‘Sta volta hanno fatto una cazzata!

Avete server Debian installati dal 2006 in poi? AGGIORNATE IMMEDIATAMENTE OPENSSL E RICREATE TUTTE LE VOSTRE CA, CERTIFICATI PEM, CHIAVI SSH DI CLIENT E SERVER.

Leggete qui:

http://www.debian.org/security/2008/dsa-1571

Ed anche qui:

http://wiki.debian.org/SSLkeys (c’e’ un tool che dovrebbe aiutarvi a capire quali server SSH sono vulnerabili e quali no… anche se non e’ detto che non possa generare falsi positivi/negativi).

“”Luciano Bello discovered that the random number generator in Debian’s openssl
package is predictable. This is caused by an incorrect Debian-specific change
to the openssl package (CVE-2008-0166). As a result, cryptographic key
material may be guessable.””

“Well, it looks like it’s more toward the minutes or seconds range, because dowkd.pl contains a simple list of around 260,000 fingerprints for these vulnerable keys… that is, if you’re vulnerable, I can look your SSH server’s host key fingerprint up in a rather small database to find your private key.Yikes.”

“It was a modification from the debian package maintainers that has cause the issue. In short they disabled the random portion of encryption process, also known as the iv, salt, seed. Which means basically means all the keys are predictable, because the randomness has been removed. This in turn creates weak keys, and a target for brute force and man in the middle attacks. The bug is limited to Debian systems, and its clones, since it was introduced by the Debian maintainers.”

Modificare il codice di un pacchetto critico come OpenSSL, frutto di lunghi studi matematici sulla crittografia e fare sta cazzata. Complimenti!!!!

Pare che la patch malsana risalga al 2 Maggio 2006. Ben 2 anni. Vi rendete conto di quanti server in tutto il mondo possono essere vulnerabili?!!!?!

Ci aspettano ore di davanti ai computer per aggiornare caterve di macchine. COMPLIMENTI!

Update:

Per sshd basta usare questi comandi:

# apt-get update
# apt-get install libssl-dev openssl
# rm /etc/ssh/ssh_host*
# dpkg-reconfigure openssh-server

Ovviamente la fingerprint del vostro server ssh cambiera’.

Update2:

Ovviamente  se usate certificati SSH RSA per accedere ai server senza password (o anche con la password) dovete ricrearli con ssh-keygen ed aggiornare authorized_keys su ogni macchina a cui avete accesso. CHE PALLE!

Ovviamente tutti i consigli solo se il vostro server e’ stato isntallato dopo il 2006 o la vostra chiave RSA e’ stata creata dopo il 2006.

Update 3:

Lavorando ad un nuovo embedded…

Esattamente lo stesso mese di qualche anno fa, 2005, (vedere il post a riguardo su questo blog), realizzai un sistema embedded basato su Linux per un cliente.

La richiesta del committente era la realizzazione di un sistema che fosse collegato ad un PLC, a sua volta collegato a macchine di taglio lamiera, per la ricezione di dati e allarmi dalla macchina di taglio, e la successiva scrittura di questi dati su un RDBMS centralizzato.

Il sistema embedded era munito di LCD con risoluzione 640×480 e touchscreen per l’interazione.

All’avvio il sistema doveva aprire un browser (javascript capable) che doveva puntare ad una webapplication scritta da un’altra azienda, che serviva per pilotare le macchine.

Realizzai qualcosa in un mesetto:

  • l’embedded in se’: kernel + file system layout minimale + busybox + dropbear (ssh) + xorg + opera 9 (versione minimal): circa 100mb facendo un lavoro certosino di taglio di file inutili. Il dom dell’embedded era di 128MB
  • un daemon scritto in C che leggeva la seriale, parsava i dati (mi sono divertito con gli operatori bit a bit, grazie al K&R, per estrapolare gli allarmi dai char letti sulla seriale), ed utilizzava unixODBC per scriverli sul server MS SQL Server (?!?!**##%%$) della applicazione web fatta dall’altra azienda

Ne’ risulto’ un bel lavoro.
Dall’inizio avevo cercato di evitare Xorg e di usare qualcosa tipo links2 in modalita’ framebuffer, ma l’applicativo web di terze parti faceva uso massivo di Javascript…
Poi provai con Dillo, ma anche li il supporto Javascript era penoso.
Poi provai con Firefox, funzionava ma chiedeva troppo tempo al boot…
Poi sono approdato a Opera9! Opera e’ davvero un bel browser, molto personalizzabile, forse piu’ facilmente di Firefox perche’ basta editare il file opera.ini.
Date un occhio a http://del.icio.us/pallotron/opera.

Opera9 aveva gia’ una funzionalita’ di kiosk mode interna, senza bisogno di installare addon come nel caso di Firefox.

Questo lavoro produsse la pubblicazione di un howto da me scritto che illustrava come usare il portage di Gentoo Linux per realizzare sistemi embedded. E’ ancora un valido documento. Ho visto che molta gente approda ad esso cercando con Google. Ne realizzai anche una versione English.In questi giorni mi sono trovato nella situazione di dover realizzare un altro embedded. Nel frattempo la mia considerazione di Gentoo e’ andata scemando. Per una serie motivi che se volete possiamo discutere.BTW mi sono messo all’opera per vedere che strumenti offre Debian per realizzare lo stesso lavoro.Premetto che sia l’embedded precedente che quello odierno sono basati su cpu x86 compatibili. No ARM.

Quindi per realizzare un sistema usabile e funzionante non si deve fare cross-compiling delle applicazione per la CPU target.

Debian mi ha permesso di essere molto piu’ spedito nella creazione di questo nuovo embedded. Ho utilizzato debootstrap, dando comandi simili a questi:

main # mkdir -p /opt/lenny-root
main # debootstrap lenny /opt/lenny-root http://ftp.debian.org/debian/
[ ... attendere prego ... ]

Alla fine del processo otterrette un sistema debian standard minimal (in questo caso la relase lenny) nella directory prescelta.

A questo punto mountare /proc, copiare /etc/hosts e chrottarsi:

main # mount proc /opt/lenny-root/proc -t proc
main # cp /etc/hosts /opt/lenny-root/etc/hosts
main # chroot /opt/lenny-root /bin/bash

A partire da questo punto ho installato il software necessario al cliente usando apt.
Ho installato Firefox, Xorg, dropbear, Splashy, ed un RPM della National Instruments fornitomi dal cliente che installa un envoirnment chiamato Labview che include anche un plugin di Firefox.

E’ un ambiente molto utilizzato da 20 anni in automazione industriale:

For more than 20 years, NI LabVIEW graphical development has revolutionized the development of scalable test, measurement, and control applications. Regardless of experience, engineers and scientists can rapidly and cost-effectively interface with measurement and control hardware, analyze data, share results, and distribute systems.

Il cliente ha gia’ scritto applicazione LabVIEW, il terminale embedded deve puntare all’applicazione di monitoring della infrastruttura automatizzata.

Il cliente voleva anche che il processo di boot non mostrasse tutte le scritte tipiche del boot dei kernel UNIX. Ma qualcosa di grafico con una barra di scorrimento, qualcosa alla Ubuntu/Windows.

L’ho realizzata con Splashy.
E’ stato sufficiente installarlo, leggere la documentazione, realizzare delle bmp con pochi colori come questa, con le immagini da usare, configurare qualche file di xml per definire colori della barra ed i comportamenti.

Mentre che c’ero ho anche utilizzato lilo in modalita’ grafica con immagine bmp e menu’ di scelta dove l’utente al boot puo’ scegliere se partire con lo splash, senza splash (per vedere i messaggi del kernel), oppure in una modalita’ “configurazione”.

La modalita’ “configurazione” viene usata per configurare l’apparecchio.
In pratica a dopo il boot, e dopo aver effettuato il login uno script in .bashrc legge la command line del kernel leggendo /proc/cmdline ed eventualmente esegue uno script bash che fa domande sulla configurazione e poi scrive i file che deve scrivere…

Il filesystem dell’embedded e’ cosi’ organizzato:

  • / in read only
  • /usr compressa con squashfs
  • una partizione /rw di pochi mega in read write

In totale tutto sta in 164MB. OK non proprio dimensioni embedded, ma in realta’ questo non e’ proprio un embedded nel vero termine della parola… e’ piu’ un dispositivo da affiancare ad una macchina di taglio, e poi dovendo anche avere Xorg… Considerato che il dom che ho a disposizione e’ di 256MB direi che vado tranquillo, ma sono convinto che con un po’ di lavoro certosino fatto di strace, ldd, e altri tool posso minimizzare di molto!
Ed ora pappatevi un video che ho girato l’altra notte mentre ci lavoravo, in questo video il sistema impiega ben 4’30” dall’accensione elettrica al caricamento di una pagina di test con un plugin Labview. Ma nel momento in cui scrivo sono riuscito a ridurre il tempo di caricamento a soli 2’20″… purtroppo l’embedded che ho e’ solo 166mhz… 129MB di ram… e si sa firefox non e’ che sia leggerissimo… beh casomai il cliente optera’ per ferragglia piu’ prestante.