Remco Bressers’ Blog

As a followup on my blog post Wordpressmobile.mobi is Spyware i’m now going to review the Wapple Architect plugin for Wordpress. The original developer (Rich Gubby) replied about this plugin on my previous blog post and asked me to review the plugin.

Here we go…

I looked through the documentation which tells me i have to open an account at wapple.net, which happens to be owned by the creator of the plugin. On the Wapple page, it then generates an “Architect Dev Key” which you need for the configuration of the plugin. This key is bound to your domainname, which i think is rather restrictive. A blog can have multiple domainnames.
After filling the key, the rest is all self explanatory and stupid simple. It just works.

Alright.. let’s test it out. On my Nokia E71, the layout looks rather simple to me but there’s plenty of possibilities to enhance this. I did notice some strange timeout issues on blog items which i didn’t have before installing the plugin. I don’t know for sure, but it looks like it has something to do with a very short timeout somewhere in the process. As far as i looked into the code, it creates a cookie on your device for 3600 seconds. Within that time, there will be no calls to Wapple made. This means the connection to Wapple is OK because it does build the first page all the time.

On the iPhone, i’m having similar issues.

The default layout looks far better on the iPhone (as all things look better on an iPhone ), but on the iPhone i’m having similar timeout issues which happens after only a few seconds of waiting time.

Maybe the developer can look into this.

The next problem i’m having on the iPhone is the page rendering. It renders almost perfectly on many different platforms, but on the iPhone the content is too wide for the screen, which means it doesn’t do a very good job on detecting the edge of the screen.

Looking into the code

Well, the last time i looked into the code of a mobile Wordpress plugin, i was shocked by ads and callback code which was hacked into it. I was pleased to see that this plugin was free of any ad code or any callback options you don’t want. There’s one big ‘but’ in this one, because it does call home to verify the API key and to detect what type of mobile device it is. Ofcourse you’re well aware of that before you install the plugin, but this could be used by the author to influence your blog and get a hold on your personal data (you filled it in yourself on Wapple.net). It’s not disturbing though. You are well aware of the fact that you’re registering for an API key to use on your own blog, so you know the author has your information just as Google has everytime i seek something on the net. The code for the plugin looks very tidy and you can see it’s written by someone who wants you to know how the stuff works. That’s very nice and i wish every developer works like this.

The pros:

• Clean code. No phone-home or hidden ads or any other crap
• Install, get the key, fill it in and it works. It’s that simple
• Easy configuration and pretty customisable

The cons:

• Use of multiple domains would be nice as you can only get one key per Wordpress installation
• Rendering on the iPhone is far from ideal, but this doesn’t seem to be such a big bug to me
• Use of your own ads (Google Adsense) is still impossible. This would be a killing app for me for this plugin

Overall, i’m pretty pleased with this plugin and i started using it today. Thanks Rich!

You can get the plugin at http://wordpress.org/extend/plugins/wapple-architect

Money, money, money.. that’s what this world is about apparently. I have some Google ad’s on my page just to get some smoke out of the chimney. There has to be some money to keep the stuff running. Actually, it doesn’t deliver me anything at all. No problem, i don’t care.

BUT!

I was Googlin’ for a nice plugin to make my blog better readable for mobile users. The first URL sure looked like a good one. It’s wordpressmobile.mobi and it has a nice free Wordpress plugin. Hmm.. Free as in beer?

After stumbling through the code, i noticed the following piece of it :

$campaign = ($rand <= $admobshare) ? ‘pub-3132018019261025′ : get_option(’wordpress_mobile_plugin_google’);
$rand = ‘Sharing ‘.$admobshare.’% to plugin author’;

Alright, so it’s Google ad number is pub-31320189261025. Why didn’t he tell me about it? Maybe i should just make a good backup of my Wordpress installation and install the plugin. So i did. And YES, it’s a great plugin and YES the creator did a great job. You can change the ads from the settings menu in Wordpress.. And NO, you will STILL get “some” ads from the author of the plugin.. WHAAAAAAAT..

But… even scarier..

Most people just unzip the plugin and after activating the thing, they don’t even bother to configure it. It works? Then it’s ok. What you don’t know is that it defaults all the ads to it’s own so they are making money without you even noticing.

Sure looks like spyware to me. It pings back to the author. It even mails the author that a new user is using his plugin. What’s next? Is he going to make a tarball of my complete Wordpress installation which he sends to all his friends at facebook?

I see this “method” poppin’ up once every few weeks and it sure doesn’t make me very happy to know that this kind of “moneymaking” is not labelled spam or spyware, where every piece of Windows junk with some “call-home plugin” is. Just my thoughts and i hope someone would let me know some GOOD arguments for not putting this on the website OR in the readme (where it should be). Hell no! It shouldn’t even be in there

Just my 2 cents and just some frustrations i need to get rid of . Maybe it will help other people get a safe Wordpress installation. For now, no mobile support. I’m sorry.

edit: Oh yeah, if you want to know how to disable his own ads, mail me.

Today, we’re going to talk about pfSense. A software stateful-firewall based on the excellent pf firewall in FreeBSD. It’s an easy to install from-ISO appliance.

From the pfSense website:

pfSense is a free, open source customized distribution of FreeBSD tailored for use as a firewall and router. In addition to being a powerful, flexible firewalling and routing platform, it includes a long list of related features and a package system allowing further expandability without adding bloat and potential security vulnerabilities to the base distribution. pfSense is a popular project with more than 1 million downloads since its inception, and proven in countless installations ranging from small home networks protecting a PC and an Xbox to large corporations, universities and other organizations protecting thousands of network devices.

pfSense is a nice piece of software, but the developers don’t seem to be very interested in integrating IPv6 support in the interface. Too bad, because IPv6 is hot and will replace IPv4 within the next few years. I’m not going to integrate IPv6 in the GUI of pfsense with this tutorial, but after following the instructions you will have a working IPv6 router/firewall with support for stateless autoconfiguration. The configuration is built from my own needs, so if it doesn’t match your expectations please add your features.

For this setup i use pfSense 1.2.3-RC1 which is out for quite a while and pretty stable in it’s use.

I’m not going to discuss the installation of pfSense. If you can’t install the pfSense ISO, you shouldn’t be doing IPv6 on it anyway . First of all, make sure you enable SSH in pfSense. You can find the feature at “System” > “Advanced”

After enabling, connect (via SSH) to the pfSense box. Ofcourse, if you’re sitting behind the box you can do it on the console also .

You will be presented a nice text menu:

*** Welcome to pfSense 1.2.3-RC1-pfSense on myFirewall ***

WAN*                     ->    bce0    ->    123.123.123.1
LAN*                     ->    bce1    ->    192.168.0.254

pfSense console setup
***********************
0)  Logout (SSH only)
1)  Assign Interfaces
2)  Set LAN IP address
3)  Reset webConfigurator password
4)  Reset to factory defaults
5)  Reboot system
6)  Halt system
7)  Ping host
8)  Shell
9)  PFtop
10)  Filter Logs
11)  Restart webConfigurator
12)  pfSense PHP shell
13)  Upgrade from console
14)  Disable Secure Shell (sshd)

We want to go to the CLI shell. Select 8.

On my box, i’m using Broadcom network interfaces. On FreeBSD these are named ‘bce0′ and ‘bce1′. You can find the respective names with the ‘ifconfig’ command. On my setup, bce0 is the outside interface and bce1 is the inside interface.
My setup is fully native-IPv6, which means that i’m not doing any tunnelling at all. On the outside interface, i have an IPv6 address from my provider’s /64 block he used for my connection. On the inside, i have  a /64 of IPv6 addresses which are publically reachable (global-unicast). Ofcourse i’m using fake addresses to prevent my firewall being bombed all-over .

Let’s say, these are my network variables :

• The WAN IPv6 network is : 2001:4cb8:a95:1::/64
• The WAN IPv6 address is : 2001:4cb8:a95:1::2
• The WAN IPv6 default gateway is : 2001:4cb8:a95:1::1
• The LAN IPv6 network is : 2001:4cb8:b95:1::/64
• The LAN IPv6 address is : 2001:4cb8:b95:1::1

With this information, we’re going to create our boot-script to configure the interfaces and routing.

cd /usr/local/etc/rc.d
vi 00_config-ipv6-if.sh

#!/bin/sh
#
# IFOUT = outside interface
# IFIN = inside interface
# DFGW = default gateway
IFOUT="bce0"
IFIN="bce1"
DFGW="2001:4cb8:a95:1::1"

####### Configure the stuff

# Configure the interfaces
ifconfig $IFOUT inet6 alias 2001:4cb8:a95:1::2 prefixlen 64
ifconfig $IFIN inet6 alias 2001:4cb8:b95:1::1 prefixlen 64

# Set the default route
route -n add -inet6 default $DFGW

# Configure IPv6 forwarding
sysctl net.inet6.ip6.forwarding=1

# My /etc/rtadvd.conf looks like this
#
# bce1:\
#   :addrs#1:addr="2001:4cb8:b95:1::":prefixlen#64:tc=ether:
#
# Startup rtadvd
/usr/sbin/rtadvd -d -D -c /etc/rtadvd.conf $IFIN

Ok, that’s pretty much all there is to enable IPv6 and configure the static routing to the ISP.
Next, we need to change permissions on this file :

chmod 755 /usr/local/etc/rc.d/00_config-ipv6-if.sh

After bootup, IPv6 will be running on the pfSense box, but it won’t do a thing. This is because we need to change the filter (PF) also. This is going to be our next script.

cd /usr/local/etc/rc.d
vi 10_config-ipv6-pf.sh

#!/bin/sh
#
# IFOUT = outside interface
# IFIN = inside interface
# DFGW = default gateway
IFOUT="bce0"
IFIN="bce1"

####### Configure the stuff

# Configure PF
# pfSense puts it's rules in /tmp/rules.debug for debugging purposes after boot
# We will use these rules, add IPv6 additions, read the config with pfctl and
# disable and enable PF
cat /tmp/rules.debug | sed "/User-defined rules follow/{
p;s/.*/\
pass in quick on $IFIN inet6 from any to any\\
pass out quick on $IFIN inet6 from any to any\\
pass out quick on $IFOUT inet6 from any to any\\
pass quick proto ipv6-icmp from any to any\\
pass in on $IFOUT inet6 proto tcp from any to any port 22\\
/;}" > /tmp/rules.config-ipv6.txt

# Read the new PF configuration file
pfctl -f /tmp/rules.config-ipv6.txt
pfctl -d; pfctl -e

And change the permissions also:

chmod 755 /usr/local/etc/rc.d/10_config-ipv6-pf.sh

Finally, we need to configure the router advertisement daemon (rtadvd) to get stateful autoconfiguration to work.

vi /etc/rtadvd.conf

bce1:\
  :addrs#1:addr="2001:4cb8:b95:1::":prefixlen#64:tc=ether:

After rebooting the pfSense firewall (or run script 00 and 10) IPv6 will work on your box.
But.. when you change filter rules (or anything actually) in the GUI, the filter settings are overwritten and your IPv6 connectivity will break.
After some searching on the box, i noticed that after changing things in the GUI the function filter_configure_sync() is called and the rules will be flushed.
This function can be found in /etc/inc/filter.inc (line 78). In the function, there’s a hook to a plugin directory. When the function filter_configure_sync() is called, the function will look in the /usr/local/pkg/pf directory for scripts, which will be executed. This only happens if scripts end with “.sh” as the extension.
We will symlink the 10_config-ipv6-pf.sh script to this location to make it work.

ln -s /usr/local/etc/rc.d/10_config-ipv6-pf.sh /usr/local/pkg/pf/

Congratulation! You got yourself a working IPv6 setup.

If you want to know more ins and outs about IPv6, i suggest reading the book “Running IPv6″ by Iljitsch van Beijnum. You can find more information at http://runningipv6.net/

OpenVZ is a great piece of software to do container (or VPS) hosting on a Linux box. It doesn’t come with any fancy management tools and it’s pretty raw, but it’s very solid and stable and does the job very well.

For this howto, you will need vzdump. You can download it from the contrib directory on the openvz.org server.

Backing up a container can be a test, because the best method to do it is very sloppy explained in the manual. There are 3 options to do a backup :

Method 1:

• Stop the container (e.g. vzctl stop 101)
• Backup the container (e.g. vzdump 101)
• Start the container (e.g. vzctl start 101)

Method 2:

• Suspend the container for a while (e.g. vzdump –suspend 101)

Method 3:

• Make a live snapshot of the container (e.g. vzdump –dumpdir /home –snapshot 101)

Method 1 is ofcourse slow because backing up a container can be a very lengthy process when it’s a full-blown LAMP server. For instance. A full backup of the webserver this site is running on takes about 2 hours. You don’t want to do that. Trust me.

Method 2 is a lot nicer. It makes a backup of the running container. After it’s done, it pauses the container and starts the backup again with rsync. This way, you only need to backup differences between the live container and the paused container. Suspending usually takes only a few minutes.

But, we want method 3. And trust me.. you want it too . Making a live snapshot, which you backup to a seperate location doesn’t give you any downtime which is good. It uses LVM2 to make a snapshot of the /vz filesystem (which also has to be in LVM2 ofcourse). For buffering changes, it needs about 512MB of snapshot space. I usually create a much bigger snapshot logical volume because i don’t like to use minimal requirements.

I this example, i use a seperate disk especially for OpenVZ storage. The volume group is called ‘SAN’ (it’s mounted on iSCSI) and the VG is 100GB big.
/vz is mounted on a logical volume called ‘openvz’ (/dev/SAN/openvz). This logical volume is 90GB big, so this leaves me 10GB of unallocated space to be used for snapshotting and other things in the future. Don’t forget to keep some space unallocated when building your data “disk”. If you do so, you will never be able to use LVM2 snapshots.

The rest is actually a piece of cake. vzdump creates a snapshot of /dev/SAN/openvz in /dev/SAN/vzsnap. This snapshot is then backed up to a seperate directory to a tarball.

You can put the following in /etc/crontab to do a daily backup, starting at 2:00, for a single container :

00 2 * * * root /usr/bin/vzdump --dumpdir /home/backups --snapshot --compress --mail some@mailaddress.com 101

Or for all containers :

00 2 * * * root /usr/bin/vzdump --dumpdir /home/backups --snapshot --compress --mail some@mailaddress.com --all

Et voila! There’s your superb backup for OpenVZ.

After writing a blog article about creating your own Mozilla Weave server, i started to get excited about Weave. It’s a pretty darn usable application.

I know it’s pretty early to start writing a blog about using Mozilla Weave in Thunderbird, but i’m writing this to have a complete howto available at the moment the Weave extension DOES work in Thunderbird.

Mozilla recently announced preliminary Thunderbird support in Weave 0.2.6 so i just had to test this. There’s no documentation available anywhere and it seems that it’s just the extension installing correctly, but that’s about it at the moment.

First of all, you will need at least the first Alpha version of Thunderbird 3. Right now, i’m testing it with Thunderbird Shredder, which is version 3.0a2 (2008072418) to be exact. You can download it from the Mozilla FTP at ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/

Let’s say you have Thunderbird 3 installed already. Next step will be to download the latest Weave. You can download it at http://people.mozilla.com/~cbeard/weave/dist/latest-weave.xpi and place it on your desktop or somewhere else. Why do i type bold? Well, if you’re using Firefox to download it, it will try to install Weave on your Firefox and that’s not what we want .

All screenshots are clickable, so you can see what i’m doing. At first, open up Shredder.

Click on the ‘Tools’ > ‘Addons’ buttons to open up the extensions dialog for Shredder. On your left, there’s an ‘Install’ button. Hit that.

You just downloaded the latest Weave to your desktop, so let’s install the thingie.

Shredder will give you a warning that the author has not been verified. Well.. this is pretty normal as it is all Alpha software. Just install anyway. It’s not gonna work anyway at this moment .

After the installation, you have to restart Shredder for the extension to become available. After that, the beautiful Weave icon will appear in the lower-right corner of your Shredder screen. If you click on that, you will see the preferences of Weave. Well.. For now that’s actually all you can do with it. To bad, but i believe that Weave can become very handy for synchronizing account data, e-mail, contacts etcetera.

When you try to login, nothing will happen.

Stay tuned for more…

Running iSCSI target on a Fedora system is as easy as “yum install iscsitarget” and configure the thing. Unfortunatly, on CentOS, the iSCSI Enterprise Target (IET) daemon is not in the default Yum repositories, because CentOS usually uses TGT (Linux SCSI Target Framework).

Ok, i could dive into using TGT on a CentOS box, but that’s not what i wanted to use on a corporate SAN. So, let’s find it out the hard way and build from source.

The iSCSI Target system

First, some prerequisites :

# yum install kernel-devel openssl-devel gcc rpm-build

Download the latest IET from the Sourceforge repo and put the tgz in /usr/src

# cd /usr/src
# tar xvf iscsitarget-0.4.15.tar.gz
# cd iscsitarget-0.4.15
# make
# make install

Alright. IETD is installed and ready to use. The iscsi-target init.d script is installed and will be started at boot-time. Nice! One bad thing is, that every time you install a new kernel, you need to recompile ietd. Write this down on your forehead or somewhere you will look at every single day

Configuring ietd is a piece of cake if the documentation would be easy findable, but it isn’t (or wasn’t).
First, lets decide who can connect to the IET daemon :

# vi /etc/initiators.allow

iqn.2008-07.my-sanhead:mydiskname 192.168.1.0/24

Yep, quite a strange string. It’s called an IQN (iscsi qualified name) and i use this naming convention:
iqn.<year>-<month>.<hostname>:<LVM diskname>
The IQN is an identifier for your iSCSI target. A target can consist of multiple disks and/or lun’s. The iSCSI initiator uses the IQN to connect to these disks/lun’s. The subnet 192.168.1.0/24 is allowed to use this iSCSI target.

Next, we’ll create the initiators.deny file, which is pretty straightforward :

 # vi /etc/initiators.deny

ALL:ALL

Time to create the IQN in the ietd configuration file.

# vi /etc/ietd.conf

Target iqn.2008-07.my-sanhead:mydiskname
        IncomingUser username 12345
        OutgoingUser username 123456789012
        Lun 0 Path=/dev/SAN/diskname,Type=fileio,IOMode=wb
        Alias iSCSI for diskname
        ImmediateData Yes
        MaxConnections 1
        InitialR2T Yes

I use the following conventions, as defined in the RFC :

For IncomingUser: Password always 5 characters
For OutgoingUser: Password always 12 characters

I use LVM as a disk backend. The disk can also be /dev/sdb or whatsoever.

The iSCSI Initiator

For the initiator, we’re also going to use a CentOS system, as this is my OS of choice. In Ubuntu/Debian/Fedora/Whatever-linux-u-may-have there usually is an open-iscsi in the repository. If not, you can always compile it from source at http://www.open-iscsi.org.

Let’s install the prerequisites :

# yum install iscsi-initiator-utils
# yum install open-iscsi

Next, define the initiatorname. This is in the exact same form as the targetname, but it should not be the same. This initiatorname is the name (in IQN) of your computer.

# vi /etc/iscsi/initiatorname.iscsi

InitiatorName=iqn.2008-07.mydesktoppc:someuniquename

Next, we’re going to configure the authentication and some specials in the iscsid config.

# vi /etc/iscsi/iscsid.conf

node.startup = automatic
node.session.auth.authmethod = CHAP
node.session.auth.username = username
node.session.auth.password = 12345
node.session.auth.username_in = username
node.session.auth.password_in = 123456789012
node.session.timeo.replacement_timeout = 120
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.noop_out_interval = 10
node.conn[0].timeo.noop_out_timeout = 15
node.session.initial_login_retry_max = 10
node.session.cmds_max = 128
node.session.queue_depth = 32
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072
discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768
node.session.iscsi.FastAbort = No

For more information about these setting, please refer to the open-iscsi page.
Next up, start the thing :

# service iscsi start

Bingo! You just started the iSCSI daemon (all cheer). Now, we’re going to discover our targets on the target iSCSI host. I assume 192.168.1.1 is the target host in this example.

# iscsiadm -m discovery -t st -p 192.168.1.1
192.168.1.1:3260,1 iqn.2008-7.my-sanhead:mydiskname

As you can see, it found the target we created before. Now, let’s login to it:

# iscsiadm -m node -p 192.168.1.1  -T iqn.2008-7.my-sanhead:mydiskname --login

Et voila! If you do a ‘dmesg’ on your box, you will find a new disk inserted (/dev/sdc or whatever).

Have fun!

updated: Fri Jul 18 : Added SSL VirtualHost configuration for a secure environment.
updated: Fri Oct 17 : Just increased version numbers to Weave 0.2.7.

Mozilla Weave is a pretty neat extension to the pretty neat Firefox 3 browser. This extension can synchronize your bookmarks, cookie data, saved passwords, history and form data to a WebDAV server maintained and hosted by Mozilla.

Since Weave is only at version 0.2.7 (at the time of writing), the project is heavily in development and the WebDAV server is dead slow and offline from time to time. The nice thing about free mozilla stuff is that almost everything is possible, even building your own WebDAV server.

We don’t just want a WebDAV server, but we want the exact same setup as Weave uses, including tight user authentication and security on the storage. The only thing that really bothers me, is that there’s still no satisfying solution for quota support in WebDAV, except for using patched mod_dav and Apache versions.

As a base system, i’m using CentOS 5.2

Apache

First, we’re going to install Apache, and configure the stuff

# yum install httpd
# vi /etc/httpd/conf/httpd.conf

Make sure the mod_dav and mod_dav_fs modules are loaded in the configuration file

LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so

<IfModule mod_dav_fs.c>
    DAVLockDB /var/lib/dav/lockdb
</IfModule>

The last section is there by default, but i’ll just post what’s really needed to get things working.

Now, we’re going to build the VirtualHost

<VirtualHost *:80>

    ServerName          weave.yourdomain.com
    DocumentRoot        /home/www/weave.yourdomain.com/www

    ErrorLog            /var/log/httpd/weave_yourdomain_com-error.log
    CustomLog           /var/log/httpd/weave_yourdomain_com-access.log combined

    <Directory "/home/www/weave.yourdomain.com/www">

        Options Indexes FollowSymLinks
        AllowOverride AuthConfig Limit
        Order allow,deny
        Allow from all
        AuthType Basic
        AuthName "WebDAV Restricted"
        AuthUserFile /home/www/weave.yourdomain.com/passwords
        require valid-user

    </Directory>

    <Location />
        DAV On
    </Location>

</VirtualHost>

As you can see, we’re using the directory /home/www/weave.yourdomain.com/www as our DocumentRoot. Valid users from the file /home/www/weave.yourdomain.com/passwords can browse to the DocumentRoot. We will restrict further user-access by using .htaccess files in the “users” directory lateron.

The <Location /> statement enables DAV on the DocumentRoot.

Now, let’s save the thing and create the necessary directories:

cd /home/www
mkdir -p weave.yourdomain.com/www/user/remco
chown -R apache:apache weave.yourdomain.com

For each user, we’ll create a .htaccess file in their directory:

cd /home/www/weave.yourdomain.com/www/user/remco
vi .htaccess

    require user remco

chown apache:apache .htaccess

Finally, we’ll make the passwords file:

htpasswd -c /home/www/weave.yourdomain.com/passwords remco
New password:
Re-type new password: 

That’s it for the installation. Next up: Weave!

Weave

I’m using Weave 0.2.7, downloaded from http://people.mozilla.com/~cbeard/weave/dist/
If you never used Weave before. It’s necessary to first make a profile at Mozilla. After Weave is succesfully configured and syncing to a Mozilla server, you can change properties.

If you have configured Weave, click on the Weave logo in the bottom right of your screen and select ‘Preferences’. After that, sign out on your current Weave login at Mozilla. Click on the Advanced tab and change your Server Location to http://weave.yourdomain.com and start a Sign In.

Et Voila! You are connected to your own Weave WebDAV server. Start syncing at real speeds
If you encounter problems, you can always look at the activity log. If you STILL encounter problems, try to flush server data.

Weave over HTTPS / SSL

If you want to have a secure connection, you will need SSL for that. Installation is already done when you have installed Apache on CentOS 5. If you have doubt, check to see if you have mod_ssl and openssl installed with Yum or whatever tool you’re using.

To use SSL, you have to create the next VirtualHost next to the VirtualHost you already created on port 80. Ofcourse you can also completely disable the VirtualHost on port 80 if you really really don’t want a plain connection.

The configuration you have to add is the following :

<VirtualHost *:443>
        ServerName      weave.yourcomain.com
        DocumentRoot    /home/www/weave.yourdomain.com/www
        ErrorLog                /var/log/httpd/weave_yourdomain_com-error.log
        CustomLog               /var/log/httpd/weave_yourdomain_com-access.log combined
    <Directory "/home/www/weave.yourdomain.com/www">
        SSLRequireSSL
        Options Indexes FollowSymLinks
        AllowOverride AuthConfig Limit
        Order allow,deny
        Allow from all
        AuthType Basic
        AuthName "WebDAV Restricted"
        AuthUserFile /home/www/weave.yourdomain.com/passwords
        require valid-user
    </Directory>
    <Location />
        DAV On
    </Location>
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>
SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
</VirtualHost>

Note

Note that when you are using a self-signed certificate (like i do), you need to browse to https://weave.yourdomain.com/ and accept the certificate, before it will work in Weave. If you don’t do this, Weave will give you the error “Username / password incorrect”.

Note #2

If you happen to be running Weave 0.2.5 and notice a huge memory and CPU increase, disable the TAB synchronization. There’s a known bug in 0.2.5 that eats your memory. 0.2.6 solves this issue.

Download Weave now at:
http://people.mozilla.com/~cbeard/weave/dist/latest-weave.xpi

Thunderbird?
I also started a blog about using Weave in Thunderbird. You can see it here.