Se siete intezionati a migrare da un server all’altro anche la webmail creata con Squirrelmail, e’ buona cosa sapere che i vari utilizzatori, nel tempo, potrebbero aver salvato diverse personalizzazioni nel loro spazio.
Tra queste cose che l’utente sicuramente rivorra’ anche nel nuovo server spiccano: le preferenze (filtri, impostazioni, ecc…) e la rubrica.
Per esportare il tutto vi bastera’ copiare tutti i file .pref e .abook dalla directory data/:
cp -av /path/to/your/squirrelmail/data/*.pref squirrelmail-backup/
cp -av /path/to/your/squirrelmail/data/*.abook squirrelmail-backup/
A few people have asked for an updated version of my Securing WordPress Admin Access With SSL guide. So here is an updated version for WordPress 2!
The situation has not changed much since WordPress 1.5: WordPress 2.0 still does not support HTTPS access to the admin area when the rest of the blog is served via normal HTTP and I still do not like logging in to my server over unencrypted connections, especially not when using public WLANs. Getting around this WordPress limitation requires quite a few steps:
As mentioned recently, Debian Sarge’s installer doesn’t work on my Dell Inspiron 9300. I like Debian but I think it’s a shame that the sarge installer was already outdated on the day of its release.
The official sarge installer still uses a 2.4 kernel by default but includes a 2.6 kernel that can be used by booting with "install26" or "expert26". But even that kernel, 2.6.8, is too old for the Inspiron 9300. It still doesn’t recognize the hard disk.
January 22nd, 2006: There’s an updated version of this guide for WordPress 2 now: Securing WordPress 2 Admin Access With SSL
As one can guess from the look of this site, I’m using WordPress as my blog engine. At this time WordPress does not support HTTPS access to the admin area when the rest of the blog is served via normal HTTP. This is a bit unfortunate. I do not like logging in to my server over unencrypted connections, especially not when using public WLANs. Getting around this WordPress limitation requires quite a few steps:
The Exim 4 source code supports authentication with SASL since version 4.43. Debian started enabling this feature in exim4_4.50-2. After I’ve had upgraded to that version and replaced my saslauthd authenticators with brand-new cyrus_sasl authenticators, I’ve noticed that auth.log got flooded with entries like ‘exim4: OTP unavailable because can't read/write key database /etc/opiekeys: No such file or directory.’
Debian’s latest MySQL packages are compiled with --with-mysqld-ldflags = -all-static.
That means libc.so.6 is linked statically now. But glibc’s getpwnam and getpwuid implementations still need the shared libraries. The needed libraries must be copied into the chroot because mysqld calls those functions after calling chroot. I’ve updated the mysql-chroot script accordingly.
(The rest of the chroot setup procedure still works as described in Chrooting MySQL on Debian.)
Here’s a little trick to log PHP errors to syslog from an apache chroot. Instead of creating a $CHROOT/dev/log socket in the chroot and configuring syslog to listen on that, just define a bogus virtual host that logs to syslog.
<VirtualHost 127.0.0.2:80>
ServerName JustForOpeningSyslog
Redirect permanent / http://127.0.0.1/
ErrorLog syslog
</VirtualHost>
Now apache calls openlog(3) with LOG_NDELAY before being chrooted by libapache2-mod-chroot, and libapache2-mod-php4’s syslog(3) calls work just fine.
(Idea stolen from syslog(3) and chroot(2).)
It’s quite easy to chroot bind9 and apache on Debian. (See this page for bind9 and libapache2-mod-chroot or libapache2-mod-security for apache.)
But I’ve found no guide for chrooting MySQL, so here’s my short recipe:
I’ve recently changed my network connection at home to a provider which assigns dynamic addresses. Exim always provided a broken HELO/EHLO name to my smarthost since then because my externally visible hostname changes each time I connect. I’m now using Exim’s Perl interface to lookup the assigned hostname when connecting my smarthost: