First of all, we defined our scenario. Let’s assume that we’d like to have a cluster of two servers, both running the latest CentOS (5.4), both up-to-date, both using the very same partitioning and both using DRBD and GFS(2). On most SuSE or Debian systems, the installation would be pretty straight-forward: You install the base system, set up the DRBD, format it with some OCFS and make Heartbeat monitor everything. So far so good. On RHEL/CentOS it seems to work a bit different, due to the different tools they’re using. When installing the installation-group “Cluster Storage” for example, yum fetches packages named openais and cman – tools you’ve probably never heard of, when you come form the Debian corner (as I do). But before I describe those in detail, let’s just configure our plain base-installation.

What do we need to do first? What’s one of the most important things on two systems that should run “symmetrically” and have the very same data available, with every change that’s being made every second? Exactly, the time would be one of those things. We need to assure that both systems use the very same time. Mostly, you’ll be using some x86_64 hardware for such setups, where the problems start: On 64-bit hardware, the timekeeping with TSC doesn’t run that perfect, which is why we should just deactivate it and leave HPET do its job alone. After installing ntpd we need to open our grub.conf and add the notsc option to our kernels. It should looks something like this:

===================================================================
RCS file: /etc/grub.conf,v
retrieving revision 1.1
diff -u -r1.1 /etc/grub.conf
— /etc/grub.conf 2009/11/13 13:30:26 1.1
+++ /etc/grub.conf 2009/11/13 13:32:26
@@ -13,9 +13,9 @@
hiddenmenu
title CentOS (2.6.18-164.6.1.el5)
root (hd0,0)
- kernel /vmlinuz-2.6.18-164.6.1.el5 ro root=LABEL=/
+ kernel /vmlinuz-2.6.18-164.6.1.el5 ro root=LABEL=/ notsc
initrd /initrd-2.6.18-164.6.1.el5.img
title CentOS (2.6.18-164.el5)
root (hd0,0)
- kernel /vmlinuz-2.6.18-164.el5 ro root=LABEL=/
+ kernel /vmlinuz-2.6.18-164.el5 ro root=LABEL=/ notsc
initrd /initrd-2.6.18-164.el5.img

Now, we can shutdown the ntpd and set its drift-file to 0.000. After that, simply reboot and check the dmesg for the HPET-lines and of course also check the time on both systems to be identically.

Now, what else should we configure until we start building our actual cluster? Probably, we should take a look into the system-config-securitylevel-tui tool. Depending on what environment you plan your cluster to run in, you either want to open each port by port manually in the firewall and configure your SELinux to allow CMAN/OpenAIS and DRBD to work properly – or you simply turn of those “toys” and configure the network-segment to be secure by itself. It depends to you and I’m not going to write how to reconfigure the firewall or your SELinux-environment. For my tests, I simply turned both off. Especially the combination of CMAN/OpenAIS and SELinux can become pretty tricky, when SELinux runs in any other mode than “Disabled”.

Now, let’s finally please our inner kid and install some software:

# yum groupinstall “Cluster Storage”
…
# yum install drbd83 kmod-drbd83
…

I’ve chosen to use drbd83 since it’s the next stable release and already obsoletes drbd82 in CentOS 5.4 – and drbd is simply just too old. Of course, upgrades might become tricky when using explicitly versioned packages, but on DRBD it’s always a bit tricky, since there could be configuration changes which would have to be implemented manually on future versions.

However, now let’s create the infamous and poorly documented /etc/cluster/cluster.conf. For testing, we could simply use something like this:

<?xml version=”1.0″?>
<cluster alias=”cluster-setup” config_version=”1″ name=”cluster-setup”>
<rm log_level=”4″/>
<fence_daemon clean_start=”1″ post_fail_delay=”0″ post_join_delay=”3″/>
<clusternodes>
<clusternode name=”server-1.cross” nodeid=”1″ votes=”1″>
<fence>
<method name=”2″>
<device name=”LastResortNode01″/>
</method>
</fence>
</clusternode>
<clusternode name=”server-2.cross” nodeid=”2″ votes=”1″>
<fence>
<method name=”2″>
<device name=”LastResortNode02″/>
</method>
</fence>
</clusternode>
</clusternodes>
<cman expected_votes=”1″ two_node=”1″/>
<fencedevices>
<fencedevice agent=”fence_manual” name=”LastResortNode01″ nodename=”server-1.cross”/>
<fencedevice agent=”fence_manual” name=”LastResortNode02″ nodename=”server-2.cross”/>
</fencedevices>
<rm/>
<totem consensus=”4800″ join=”60″ token=”10000″ token_retransmits_before_loss_const=”20″/>
</cluster>

Configuring OpenAIS this way isn’t actually the best way… it’s not even “good”. But for testing (and understanding how stuff works) it should be enough. Those rules expect manual intervention when one of the two server should become unavailable and needs to be brought back into the cluster.

The domain “.cross” is expected to be a hostname.domainname entry within the /etc/hosts of each server and defines the direct cross-cable-connection from one server to another. We need this connection to shrink down network latency and provide a way for OpenAIS and (in this example) also DRBD to directly communicate with each other. A better setup would be to set the heartbeat on top of a serial-line, since it would be most fault-tolerant.

Okay, next. What’s left? Exactly, the actual DRBD – so let’s set it up:

global { usage-count yes; }
common { syncer { rate 100M; } }
resource the-disk {
protocol C;
startup {
wfc-timeout 20;
degr-wfc-timeout 10;
# become-primary-on both; # Uncomment this only after tested!
}
net {
cram-hmac-alg sha1;
shared-secret “i4m501337″;
allow-two-primaries;
}
on server-1 {
device /dev/drbd1;
disk /dev/sdb;
address 10.100.0.1:7789;
meta-disk internal;
}
on server-2 {
device /dev/drbd1;
disk /dev/sdb;
address 10.100.0.2:7789;
meta-disk internal;
}
disk {
fencing resource-and-stonith;
}
handlers {
#outdate-peer “/sbin/handler”;
}
}

This configuration defines our two servers and tells DRBD to use /dev/sdb on both for the actual data. Our meta-disk will be internal and with address we defined – guess what? – the IP addresses of our two servers. Those are the .cross-domain addresses!

Next, we initialize our meta-disks (on both nodes), set our generation identifier, start the actual DRBD service and check the roles it currently runs in:

# drbdadm create-md the-disk
…
# drbdadm — 6::::1 set-gi the-disk
…
# service drbd start
…
# drbdadm role all
Secondary/Secondary

If all those steps succeed, we can try to promote both nodes to primary:

# drbdadm primary all
# drbdadm role all
Primary/Primary

And if this now worked out properly, we can enable the automatic promotion from within our drbd.conf:

# rcsdiff -u /etc/drbd.conf
===================================================================
RCS file: /etc/drbd.conf,v
retrieving revision 1.2
diff -u -r1.2 /etc/drbd.conf
— /etc/drbd.conf 2009/11/13 10:34:23 1.2
+++ /etc/drbd.conf 2009/11/13 15:16:26
@@ -9,7 +9,7 @@
startup {
wfc-timeout 20;
degr-wfc-timeout 10;
- # become-primary-on both; # Uncomment this only after tested!
+ become-primary-on both; # Uncomment this only after tested!
}
net {
cram-hmac-alg sha1;

Great. So we’re set up now? Nope. We’re not. Next, we need to change DRBDs boot order in order for it to work properly with the GFS auto-mounting on boot:

# rcsdiff -u /etc/init.d/drbd
===================================================================
RCS file: /etc/init.d/drbd,v
retrieving revision 1.1
diff -u -r1.1 /etc/init.d/drbd
— /etc/init.d/drbd 2009/11/13 10:57:15 1.1
+++ /etc/init.d/drbd 2009/11/13 10:58:15
@@ -1,6 +1,6 @@
#!/bin/bash
#
-# chkconfig: 345 70 08
+# chkconfig: 345 22 75
# description: Loads and unloads the drbd module
#
# Copright 2001-2008 LINBIT Information Technologies

And let it run on boot:

# chkconfig –level 345 drbd on

Great! So, now we are set up, right? Nope, wrong. We have a running DRBD setup now, but we still lack of a cluster-able file-system. GFS2 is a pretty good choice for such a task, so let’s try to format the DRBD-device on one of our nodes with it:

# mkfs.gfs2 -p lock_dlm -t cluster-setup:mycluster /dev/drbd1 -j 2

Before we can try to mount the device, we need to have OpenAIS/CMAN running, in order to manage our GFS consistency. Let’s start the cman service therefor (on both nodes!):

# service cman start

Starting cman and starting fenced could take several seconds, be patient. If you installed both servers identically and followed this documentation step by step everything should work out just fine.

At last, we can now mount our DRBD device into some folder (on both nodes) and start playing around with our fresh setup:

# mount -t gfs2 /dev/drbd1 /mnt/somefolder

I hope everything worked out for you and I also hoped that this brief summary helped you getting a bit easier into the actual setup of such a cluster setup. Feel free to ask any questions or provide feedback in any form.

Enjoy!

The first thing needed is a client computer running any kind of the supported OSs by the Amazon API tools and of course the tools themselves. After you’ve installed those and configured all credentials the right way, we can create a new pair of SSH keys for our new project. Due to the location I’m currently in, I’ve chosen to use Amazon Instances in the western EU. Execute the following line on your command-line:

ec2-add-keypair –region eu-west-1 test-keypair

The result should look something like this:

[Deprecated] Xalan: org.apache.xml.res.XMLErrorResources_en_US
KEYPAIR test-keypair e1:1a:d1:a1:a1:1c:10:a1:b1:d1:cb:11:11:1a:11:11:f1:11:ae:fe
—–BEGIN RSA PRIVATE KEY—–
XXX
—–END RSA PRIVATE KEY—–

You can now copy the lines from BEGIN… until END… (including those two) into a file which you’ll be using as SSH-key for connecting to your instance. Don’t forget to chmod 600 it!

Next, let’s see what base-images for creating our instance we could you – first, provided by Amazon themselves:

ec2-describe-images –region eu-west-1 -o ‘amazon’

The list is contained of several different OSs and versions, although in our current project we can’t make use of any of those. Therefor, we’re now searching for a perfectly fitting, really good operating system:

ec2-describe-images –region eu-west-1 -a | grep -i debian

And yet, we receive another list with several different versions of the Debian Linux distribution. After we’ve picked the one we’d like to run, we should check what instances are currently up and running:

ec2-describe-instances –region eu-west-1

If you’re using Amazon’s EC2 for the first time, there shouldn’t be any items listed. We can now start our very first instance, by copying the instance’s identifier (in the second column, a string starting with ami-) and pasting it into our command:

ec2-run-instances –region eu-west-1 -k test-keypair -g ‘http/s’ -g ‘ssh’ ami-b8446fcc

In this command, we tell Amazon to start up a new instance that’s built on top of the ami-b8446fcc-image, using the key-pair we just created before and using some custom built firewall-rules named “http/s” (which allows us to connect to port 80 and 443) and “ssh” (port 22).

We need to wait a few seconds, until the instance comes up. We can use the describe-instances command from above to check the instance’s status:

ec2-describe-instances –region eu-west-1

As soon as it’s up and running, the “pending” column should have been replaced by a dynamically allocated hostname and the status “running”. Keep in mind, that this hostname/ip is dynamically allocated! If you want a fixed IP, you need to allocate and assign an Elastic IP – I’ll show you later how to do so.
If our firewall rules worked out, we can now connect using SSH:

ssh -i ~/Library/EC2/id_rsa-test-keypair root@ec2-11-111-11-111.eu-west-1.compute.amazonaws.com

By default, Amazon sets up a Small Instance, that provides around 10 GB of hard drive, an Dual-Core AMD Opteron 2218 with 2600 MHz and around 1.7 GB of RAM. Small instances, in comparison to the bigger ones, also still provide a real swap-partition which is limited to 895 MB. Here, you could run into problems when installing some Oracle for example, since the DB would like to have 1 GB or more Swap-space. If 895 MB should not be enough, the only way to enlarge it seems to be to use a file within your file-system for that. Either, by placing it somewhere into / or by using /mnt for that. /mnt is a special mount in Amazon instances which provides you 147 GB of additional volatile storage. Amazon doesn’t guarantee in any way the storage to be stable/solid or even backed up – and usually /mnt is only used for bundling your instance. You might now think “so, where could I place my data, if / is only providing me 10 GB of space and /mnt should not be used for storing sensitive data?” – well, there’s a third possibility named Elastic Block Storage. An EBS is being displayed to your instance as regular block-device (/dev/sdb, …) that’s format- and mountable. There, sensitive data could be stored, by bind-mounting the directories you’d like to have your data in. I’m not going to explain how this works, else I’ll never finish writing this brief documentation.

However, since we’re connected to the instance now, we can set it up the way we want it, with whatever software we need on it. I’ve assumed, that most people would set it up as regular LAMP-instance, therefor I’ve also added the firewall-rule for HTTP/HTTPS. After we finished installing the software we need, there’s one more package that should be plugged into the system: The Amazon AMI Tools. Simply wget them from http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.zip and unzip the package. Those tools make use of Ruby, so ensure having it installed on your instance. Also, you need to have the private key (pk-.pem) and the certificate (cert-.pem) you created the instance with somewhere within your instance’s filesystem, for later use.

Before we bundle up our system now, let’s come back to the topic we had before: The hostname/IP. Amazon allocates some dynamic address, unless you tell them to give you a fixed (called Elastic) IP. You can do that by simply executing:

ec2-allocate-address –region eu-west-1

… within your client’s command-line (where the Amazon API Tools have been installed – not on the instance!). As result you’ll get some IP address that has now being allocated by Amazon for you. The IP isn’t bound to any instance yet – it’s just allocated for you to be able to use it. ATTENTION: You pay for Elastic IPs as long as you do not assign them to an instance. Yes, that’s right. Amazon charges you for every allocated but unused IP hourly. By that, they want to prevent people “collecting” addresses, I guess. To assign the address you just received to your instance, simply run:

ec2-associate-address –region eu-west-1 -i i-11e11b1e 79.125.11.11

The i- is your actual instance’s ID, where the last, dot-separated number is the IP you’ve received. And yes, those are fake numbers – so don’t even try.

Now it could take a bit for Amazon to reconfigure the instance, but as soon as it finished, you should be able to re-connect to the instance using the IP you just assigned to it.

As last task for today, let’s bundle up the image the way we have it now. Bundling an image allows you more than just eating up your credit card’s limit by dumping your S3 buckets. On the one hand, with bundles you can recover machines that crashed or lost data within a few blinks and on the other, you can created new instances out of a bundle (talking about “scalability”).

For bundling, we use the AMI tools we installed. First of all, let’s create a directory for the bundle:

mkdir /mnt/myimage

After that, run the bundle-vol-tool:

ec2-bundle-vol -k pk-.pem -c cert-.pem -s -u -d /mnt/myimage/

This command takes several parameters for the private key, the certificate, the size of the resulting bundle in MB and your User-ID (without dashes). The User-ID can be found within your Account Information on Amazon’s EC2 site. The command should ask you, what architecture you’d like to bundle the system for – i386 should work out perfectly for what we’re doing. The following procedure could take some time, since the tool collections every peace of the system and builds a bundle into the directory we specified. As soon as the tool finished, we can upload our bundle to our S3-bucket:

ec2-upload-bundle –location EU -b -m /mnt/myimage/image.manifest.xml -a -s

Again, we need to specify some credentials (our access-key and the secret-key) for the upload to work. Also, we need to pick a globally unique bucket-name for uploading the bundle, what shouldn’t be that hard as long as you don’t try stuff like “linux” or other common words. The bundle will then be uploaded to your (private) bucket, so you have it for later use.

From within the web-interface you could now simply create new instances out of the uploaded bundle, without even knowing how the actual system was set up or having the Amazon API tools installed on your client.

Cool stuff, enjoy!

First of all, let’s have a look at the drive itself. It’s plain. Really plain. No holes, no screws, nothing. How the f*ck shall we open this thing. Let’s take a look under its gum-feet. Nah, not even there. What he hack? So, as it seems, this drive can’t be opened. Wrong! Yes we can!

What do we need therefor?

A cloth, for not scratching the gloss

A strong thread

A modified paperclip

Okay, now we’re all set up. First of all, take the hard drive and turn it upside-down. Place it on the cloth to not scratch its lickable, glossy exterior.

Place it on the cloth

Next, take the thread and try to run it through the holes on the case’s bottom, so that you have something to pull the hard disk out of the case. Now try to bend the sides of the plastic-case out carefully and pull drive out piece for piece. You could also use some credit card or other thin piece of plastic (not metal, it will kill the plastic-borders!) for doing this. Warning, this could cause serious damage to your credit card!

Do the credit card-thing on the front-side, the left- and right-side. When pulled it out some millimeters on each of those side, take all the pieces of your thread and try to pull out the drive to the back (e.g. rotation of 90 degrees around the drive’s back-side). On the back, there’s the button for turning it on and off, so you won’t be able to pull it out vertically. If you’ve successfully managed to pull out the drive, the whole scenario should look similar to this:

Pulled out the drive

Pulled out the drive

Now, you can see the actual hard drive which is mounted to the bottom-part of the whole case. After inspecting the construction you can see that there were to glueing-points or any hooks we broke while opening the drive. This means, that if you’ve done it right, you won’t see that anything ever changed on that drive.

Now, I can finally get myself a 750GB (or even 1TB?) hard-drive and build that in.

Happy trying!

//btw: As you notice, LaCie builds in Hitachi Deskstars on these drives. These drives cost something around 50 bucks nowadays. The complete case is around 90 bucks.

conn nat-t
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
authby=secret
left=192.168.10.193
leftsubnet=10.1.0.0/24
leftfirewall=yes
right=%defaultroute
rightid=client@example.com
rightsourceip=10.100.0.2
auto=add

We added a new virtual IP (rightsourceip) for the client. The network of this IP will be defined on the server’s configuration. We need this for the whole scenario to work out, even if the client/Roadwarrior is behind a NAT. As rightid (client-id) we use the client’s e-mail address.
Server config:

config setup
plutostart=no

conn nat-t
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
authby=secret
left=10.1.0.4
leftsubnet=10.1.0.0/24
leftid=192.168.10.193
leftfirewall=yes
right=%any
rightid=client@example.com
rightsubnetwithin=10.100.0.0/24
auto=add


Here, we also defined the client’s e-mail address as rightid, defined that the right side could be anything (“%any”) and told the server to serve the virtual network 10.100.0.0/24 for the right side. By that, the configuration can be applied to different clients and the actual IP configuration is provided on the client’s side. Yet, I did not find out whether there’s a possibility to set up some DHCP server and provide connecting clients a dynamic address automatically.
However, this setup now also works with Roadwarriors that are behind NATs, what means that the actual setup could look like this:

[roadwarrior]—-[nat]—internet—[nat]—[server]—network

Isn’t this cool?
Enjoy.

We’re in a network (in my example 192.168.10.0/24) and there are two components we focus on: One client (a Linux laptop, 192.168.10.184) and a VMware Server (192.168.10.193). On this server, we have a VMware NAT-Network (10.1.0.0/24), where the gateway is has the 10.1.0.2 and our JumpHost has the 10.1.0.4. The client (our laptop) now wants to be able to simply connect other hosts within our 10.1.0.0/24 network. Besides, it would be nice to have some kind of security in bewteen these connections. So what would be better than using a VPN?

Of course, we could use simple SSH tunnels or some OpenVPN setup – but this would be boring. So, we decide to to use IPsec. In detail, we’re using strongS/WAN to setup the whole scenario.

Now first of all we have two problems: First of all, we have a NAT (from the view of IPsec/IKE: NAT-Traversal) through which we can’t tunnel layer 3 protocols. The only thing we can do, is to teach our VMware Server to forward UDP or TCP ports to Guests.

The second thing that might become a problem is the fact, that we’re not using the IPsec daemon within the VM to distribute another network – instead we are distributing his own network. But however, enough with the talk, let’s do the work.

Thanks to Tobias Brunner and Daniel Röthlisberger, strongS/WAN experienced in 2006 the implementation of the NAT-T feature. This feature, allows to “tunnel” IPsec (a layer 3 protocol) through layer 4 (UDP). So the first thing we need to do, is to tell our VMware Server to forward the UDP ports 500 and 4500 to our JumpHost-VM. After we’ve done this, we can start setting up the strongS/WANs on the client and the JumpHost himself.

In this scenario I used Debian SID on both systems, since Debian’s current stable release provides only an very old version of strongS/WAN. So:

aptitude install strongswan

… on both systems. After that, we open the /etc/ipsec.secrets on both hosts and insert the following line:

%any : PSK "abcdefghijklmnopqer"

Of course, you can replace the key by your own one. After that, we take the ipsec.conf of the client and insert our configuration:

config setup
plutostart=no

conn nat-t
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
authby=secret
left=192.168.10.193
leftsubnet=10.1.0.0/24
leftfirewall=yes
right=192.168.10.184
rightsubnet=192.168.10.0/24
auto=add

As mentioned in the title, we use IKEv2. To simplify the scenario, we use the secret we just configured as authentication method. The configuration should be adaptable pretty easy for certificate usage.
On the server we now also insert our configuration into the ipsec.conf:

config setup
plutostart=no

conn nat-t
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
authby=secret
left=10.1.0.4
leftsubnet=10.1.0.0/24
leftid=192.168.10.193
leftfirewall=yes
right=%any
auto=add

After restarting both daemons, executing ipsec up nat-t and also ipsec route nat-t you should be able to ping the hosts on our 10.1.0.0/24 network.

The tricky part in this setup is the leftid= parameter in out server’s configuration. Without that option the whole authentication procedure doesn’t work out, because the daemon will complain to not have any configuration for “[192.168.10.184]…[192.168.10.193]” and because of that not let the client connect. The reason for this is, that the client only sees the NAT-Router (our VMware Server, .193) and of course tries to sets up the connection using his IP. The NAT-Router then forwards the requests to the actual strongS/WAN daemon (10.1.0.4) which of course says “Wtf?! I’m the 10.1.0.4, what should I do with this package I received for 192.168.10.193?”. And this where the leftid= parameter comes in.

However, I think the stuff should be more clear now. If there are any questions left, feel free to ask. Enjoy!

Anyway, so that’s actually the whole setup.

hosts: files dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

Btw: Don’t forget to put your secret into /etc/pam_ldap.secret! Anyway, let’s go on…
/etc/pam.d/common-account:

account sufficient pam_unix.so
account sufficient pam_ldap.so
account required pam_deny.so

/etc/pam.d/common-auth

auth sufficient pam_unix.so
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

/etc/pam.d/common-password

password sufficient pam_unix.so nullok md5 shadow use_authtok
password sufficient pam_ldap.so use_first_pass use_authtok md5
password required pam_deny.so

The common-session doesn’t need to be changed on the setup we need. Now, edit /usr/share/migrationtools/migrate_common.ph and change the domain to yours. With the tools (migrate_base, *_passwd, *_group) contained in that directory you can migrate your actualy existing /etc/passwd and /etc/group to your ldap. Or you just create these entries manually. However, now let’s load the apache modules:

a2enmod ldap
a2enmod authnz_ldap

… and reconfigure our WebDAV VirtualHost:

...
DAV On
AuthType Basic
AuthName "WebDAV"
AuthBasicProvider ldap
AuthLDAPURL "ldap://127.0.0.1/ou=people,[your base here]"
AuthLDAPRemoteUserIsDN off
ForceType text/plain
Require valid-user
Require ldap-filter &(uid=*)
...

And last but not least, let’s restart all servics:

/etc/init.d/slapd restart
/etc/init.d/nscd restart
/etc/init.d/apache2 restart

Voila! The authentication of your WebDAV against LDAP should be working now. Now the only thing that’s left to do, is to remove the user www-data from the shadow group again. And maybe you’d like to change your LDAP-user’s passwords:

ldappasswd -x -D cn=admin,[your base here] -W uid=[username],ou=people,[your base here] -S

And the next time, I’ll show you how you can build yourself an automatic back-scratcher using a wall, glue and a cat.

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/my.serv.er.crt
SSLCertificateKeyFile /etc/apache2/ssl/my.serv.er.key
DocumentRoot /var/www/
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

ErrorLog /var/log/apache2/error.log
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature On
</VirtualHost>

The certificate-folder needs to be created and the certificates need to be generated:

~# mkdir /etc/apache2/ssl
~# openssl genrsa -out /etc/apache2/ssl/my.serv.er.key 1024
~# openssl req -new -days 365 -key /etc/apache2/ssl/my.serv.er.key -x509 -out /etc/apache2/ssl/my.serv.er.crt

Next, we add the WebDAV/PAM settings to our SSL-VHost, while /home/pub is the folder we’d like to publish:

...
DAVLockDB /var/lib/apache2/DAVLockDB
Alias /pub /home/pub/
<Location /pub>
DAV On
AuthType Basic
AuthName "WebDAV"
AuthPAM_Enabled On
#AuthPAM_FallThrough Off
AuthUserFile /etc/shadow
ForceType text/plain
Require valid-user
</Location>
...

And last but not least, we (unfortunatelly) need to add the user www-data to the group shadow:

adduser www-data shadow

Now we can restart our Apache and enjoy the pleasure of WebDAV. If it should not work, check the permissions you set for the directory you’re publishing.
And what could this be used for? For example, as self-made iDisk.
Enjoy.