radicale behind Apache reverse proxy with Dovecot authentication

  • Requires mod_authn_dovecot for Apache 2.2 and 2.4, which can authenticate against Dovecot using email address or just username (depending on Dovecot configuration)
  • Requires auth_basic, authn_alias, authn_default, authz_default, authz_host and authz_user to be enabled for authentication.
  • For the reverse proxy: proxy, and proxy_http must be enabled in Apache.
  • Optional AppArmor changehat support provided (and accompanied AppArmor profiles for the web component in Apache and radicale itself.)

Apache configuration (/etc/apache2/conf.d/radicale.conf or equivalent)

ProxyPassMatch ((\.(ics|vcf))|((\.well-known\/)?(cal|card)dav)/)$ http://localhost:5232
<LocationMatch ((\.(ics|vcf))|((\.well-known\/)?(cal|card)dav)/)$>
   AuthType basic
   AuthName "Dovecot Authentication"
   AuthBasicProvider dovecot
   AuthDovecotAuthSocket /var/run/dovecot/auth-client
   AuthDovecotTimeout 5
   AuthDovecotAuthoritative On
   Require valid-user

   RewriteEngine On
   RewriteCond %{REMOTE_USER}%{REQUEST_URI} !^([^/]+/)\1
   RewriteCond %{REQUEST_URI} !^/.well-known/.+
   RewriteRule .* - [Forbidden]
   <IfModule security2_module>
      SecRuleEngine On
   </IfModule>
   <IfModule apparmor_module>
     AAHatName radicale
   </IfModule>
</LocationMatch>

Radicale configuration, relevant sections only (/etc/radicale/config)

[server]
hosts = 127.0.0.1:5232

[auth]
type = remote_user

[rights]
type = None

[storage]
filesystem_folder = /var/lib/radicale/collections

/etc/apparmor.d/usr.bin.radicale

/usr/bin/radicale {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/python>



  /bin/dash rix,
  /etc/radicale/* r,
  /proc/*/mounts r,
  /run/radicale/* w,
  /sbin/ldconfig rix,
  /sbin/ldconfig.real rix,
  /usr/bin/python2.7 ix,
  /usr/bin/radicale r,
  /var/lib/radicale/** rw,
  /var/log/radicale/* w,

}

/etc/apparmor.d/apache2/radicale

^radicale {
  #include <abstractions/apache2-common>
  #include <abstractions/base>
  #include <abstractions/nameservice>

  # for log writing (could be abstracted)
  /var/log/apache2/*.log w,


}

Boot LVM on mdraid (5, and others) on Ubuntu 14.04 on newer kernels

If you build a LVM mdraid5 on Ubuntu 14.04, and update the kernel you may be dropped into initramfs on reboot and be forced to manually activate the logical volumes on the volume group. This is due to a missing/incomplete udev rule for LVM which should be incorporated into initramfs.

/etc/udev/rules.d/85-lvm2.rules

# This file causes block devices with LVM signatures to be automatically
# added to their volume group.
# See udev(8) for syntax

SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_TYPE}=="disk", \
        RUN+="watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'"

Once you have added this udev rule, you should update initramfs on your system:

update-initramfs -u -k all

If you need to activate the logical volume groups from initramfs, execute the following commands to boot the system:

lvm vgscan
lvm vgchange -a y
exit

QEMU agent for graceful shutdown of Windows guests under libvirt/qemu-kvm

libvirt sending an ACPI shutdown doesn't always prompt Windows guests to shutdown. That's why there is a QEMU guest agent (which is also handy for freezing/thawing guest file systems.) Installing QEMU guest agent will also cause libvirt to block on shutdown commands until the guest has terminated.

libvirt XML definition required

<channel type='unix'>
<target type='virtio' name='org.qemu.guest_agent.0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>

You may also have to create /var/lib/libvirt/qemu/channel/target on the KVM host.

mkdir -p /var/lib/libvirt/qemu/channel/target
chown -R libvirt-qemu:kvm /var/lib/libvirt/qemu/channel/target

virtio-win drivers distributed by the Fedora Project contain the guest-agent and required virtioserial drivers for communication between guest and host and can be downloaded as an RPM package called virtio-win.

Once you have the RPM, you can either install it or convert it to a Debian package using alien. The ISO will be installed to /usr/share/virtio-win/virtio-win.iso and can be mounted in the guest.

virsh attach-disk GuestName /usr/share/virtio-win/virtio-win.iso hdc –type cdrom –mode readonly

Once you have restarted the guest with the XML definition changes, you can complete the following steps

  • Install virtioserial driver for PCI Simple Communication Controller under Device Manager, in the vioserial folder
  • Install the guest-agent located under the guest-agent folder for your architecture in the virtio-win ISO

libvirt 1.2.9 KVM qemu AppArmor support

If you want to use AppArmor support in libvirt 1.2.9, you will need to copy the following files over from the source:

cp libvirt-1.2.9/examples/apparmor/libvirt-lxc /etc/apparmor.d/abstractions
cp libvirt-1.2.9/examples/apparmor/TEMPLATE.lxc /etc/apparmor.d/libvirt
cp libvirt-1.2.9/examples/apparmor/TEMPLATE.qemu /etc/apparmor.d/libvirt
ln -s /etc/apparmor.d/libvirt/TEMPLATE.qemu /etc/apparmor.d/libvirt/TEMPLATE.kvm

This is due to the fact that libvirt looks for both TEMPLATE.lxc and TEMPLATE.qemu instead of just TEMPLATE to enable AppArmor support.

You may encounter the following error when trying to a KVM guest with AppArmor support enabled:

error: Failed to start domain test-domain
error: internal error: cannot load AppArmor profile 'libvirt-598505b5-1549-4164-97bd-d1d37fdd8995'

If you look at /var/log/libvirtd.log you may see the following error message:

2014-10-24 18:00:52.280+0000: 4468: error : virCommandWait:2533 : internal error: Child process (/usr/lib/libvirt/virt-aa-helper -p 0 -c -u libvirt-598505b5-1549-4164-97bd-d1d37fdd8995) unexpected exit status 1: virt-aa-helper: error: template does not exist
virt-aa-helper: error: could not create profile

2014-10-24 18:00:52.280+0000: 4468: error : AppArmorGenSecurityLabel:468 : internal error: cannot load AppArmor profile 'libvirt-598505b5-1549-4164-97bd-d1d37fdd8995'

This is due to the fact there is a bug in libvirt 1.2.9 which looks for /etc/apparmor.d/libvirt/TEMPLATE.kvm instead of /etc/apparmor.d/libvirt/TEMPLATE.qemu. This has been fixed via a patch which has not been integrated in a release upstream as of this post. You may symlink TEMPLATE.kvm to TEMPLATE.qemu to resolve this issue until it is resolved upstream.

Linux 3.17 KVM, qemu 2.1, libvirt 1.2.9 experiences (and how to cleanly disable TCP checksum offload in libvirt)

Update: This issue has been resolved in kernel 3.18.10 release. The below instructions are no longer required if your distribution has updated the kernel or backported the fix.

Due to latency issues that I was having with KVM and Windows 2008 R2 with Linux 3.10, I decided to update to Linux 3.17 series despite the TCP checksuming issue that I had been encountering (eg. virtio-net not working at all between guests due to the CHECKSUM_PARTIAL bug in 3.11 and above.)

I updated to Linux 3.17.1, and kept qemu at 2.0 (included in Ubuntu 14.04) and libvirt 1.2.2. Unfortunately, the TCP checksuming bug still exists. However, this resolved my Windows 2008 R2 latency issues. I am no longer seeing latency jumps to 1500ms or packet loss under load, this was using SRV-IO passthrough of a NIC.

Due to the issues I was experiencing with TCP checksuming, virtio-net and openvswitch I decided to update to libvirt 1.2.9 which includes new support for tuning guest network interfaces. This allows me to cleanly turn off TCP checksuming on an interface using the following interface definition (and thus allows all my guests to function properly):

<interface type='network'>
  <model type='virtio'/>
  <driver name='vhost'>
    <guest csum='off' tso4='off' tso6='off'/>
  </driver>
</interface>

Additionally, my Sophos UTM 9 guest (which is my firewall) no longer halts cleanly so I tried updating to qemu 2.1 – but this did not solve the issue. I have decided to leave the newer releases in place, as they have improved performance with the Windows guests as well.

For those interested, pre-built packages for Ubuntu 14.04 amd64 are available here.