Squeeze is over

Anyone still using Debian Squeeze? LTS has ended. Do your final update:
deb http://archive.debian.org/debian/ squeeze contrib main non-free
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb http://archive.debian.org/debian squeeze-lts main contrib non-free

# apt-get update -o Acquire::Check-Valid-Until=false

Debian UnattendedUpgrades copy-paste-config

Hello there, here is some Debian Auto-Update 'Copy-Paste-Config' for the impatient:
# apt-get install unattended-upgrades apt-listchanges

# joe /etc/apt/apt.conf.d/50unattended-upgrades

At least edit the mail address so you can receive the neccessary information.

# joe /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
# joe /etc/apt/apt.conf.d/local
(keep the old config)
Dpkg::Options {
   "--force-confdef";
   "--force-confold";
}
# joe /etc/apt/listchanges.conf
[apt]
frontend=pager
email_address=your@mail.addy
confirm=1
save_seen=/var/lib/apt/listchanges.db

which=both

Done.

create SAN CSR with openssl

Generate some new private rsa key:
# openssl genrsa -out key 4096

Populate a custom conf-file for using:
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = DE
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Baden-Wuerttemberg
localityName = Locality Name (eg, city)
localityName_default = Goeppingen
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default =
commonName = domain.org
commonName_max = 64

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = domain.org
DNS.2 = autodiscover.domain.org
DNS.3 = exchange.domain.org
DNS.4 = fancy-other-name.domain.org

Check the output
# openssl req -text -noout -in san_domain_com.csr

Generate the CSR for your favorite CA:
# openssl req -sha256 -new -out san_domain_com.csr -key key -config openssl.conf

The pain of DNSSEC

dnssec
Just kidding. But there are indeed a few obstacles when you try to introduce DNSSEC with your domain.
- First check that the domain-provider you're with, allows you to put your Keys into the nic database of your country through some webinterface or other automated process. I started off with my default provider telling me: "Ah, thats so rare at the moment, you have to open a support ticket for each change you like. And, you know, if its too much, we'll bill you for the extra service if we please... Anyway, it's not in the webinterface".
Now I'm using http://www.schlundtech.de/ for my DNSSEC secured domains. With them you at least only have to tell them once to enable the DNSSEC-features for your customer id in the interface and you're done.
- The other thing is: You have to administer two DNS servers of and on your own! Make "bind" your friend here.
After passing that hurdle just go with any popular HOWTO available on that topic. I found that one quite good.
After rolling your DNS zone out, of course do some testing. I found two utilities comfotable to use. For your <major browser> to show you if a domain is DNSSEC secured and has the appropriate TLSA record in it, check out DNSSEC validator plugin. For basic zone checking I use the verisign debugger.

The future is encrypted

hpkp
Do you know the new hotness in TLS/SSL security regarding webservers? Try HPKP (RFC draft). What's that again? Certificate pinning for your webserver/vhost. Imagine a government or rogue CA creating a valid certificate for your domain and eavesdropping on connections to your server (for whatever specific reason). You can mitigate that by telling visitors of your page (aka their browsers) which certificate to expect. There's a great link to a mozilla developer site that explains it in detail. For short: You extract the fingerprint of your public key you used for the certificate and put that into your http header.Actually HPKP checking is already in Chrome and enabled by default. For FF I see it planned for Jan/2015. Sure, one obstacle remains: Using that technique you rely on "trusted first visit". Well, maybe also consider introducing DNSSEC in your domain(s). But that's another story.

trapped in "initramfs" prompt?

initramfs
Lately I was trapped in the "initramfs" prompt on a server that was rebooted. The reason for it being stuck there was obivously some hdd change due to raid failure/rebuild. After panicing for a few seconds I tried to fix the situation. I tried two different approaches. Depending on your personal situation one or the other might suffice. One situation could be solved by:
Activate LVM from initramfs prompt
# lvm vgscan
# lvm vgchange -a y
# mount -t ext4 /dev/primary_vg/root_lv /root
# exit
(Note to myself: LVM can be enabled/activated in initramfs> prompt if this is the only issue that prevents the system from booting)

Now for the more complex "the ramdisk did not recognize my md-raid right"-situation:
Assemble MD-Raid from initramfs prompt
# rm /etc/mdadm/mdadm.conf
# mdadm --assemble --scan
# mount -t ext4 /dev/md127 /root
# exit

Worked and got the system booting, but I couldn't quite fix the initramfs from there. So I restarted back into some rescue system and finally did the following:
(starting from "initramfs>" prompt)
Fix broken initramfs from rescue system
# mkdir /target
# mount /dev/md0 /target
and depending on your partitioning: # mount /dev/md1 /target/boot/
# mount -o bind /dev /target/dev
# mount -o bind /dev/pts /target/dev/pts
# mount -o bind /sys /target/sys
# mount -o bind /proc /target/proc
# chroot /target

Finalizing with:
# update-grub
# update-initramfs (maybe with opts: -k -t or -u)
Test it by rebooting, and finished.

"php_flags" ignored with apache2 having suPHP enabled

I recently stumbled upon a problem regarding setting display_errors on/off on a webserver. One of the systems I maintain has configured apache2 with php5.x and suPHP module enabled. In this situation php_flags set in either the vhost or .htaccess files are not effective. Luckily i found out how to deal with that anyway: Just put a separate php.ini (maybe start with a copy from the system-wide one) in the documentroot of the vhost you try to set custom settings with! Voila. Now use that one for your special settings.