running Apache2 with SSL on Opensuse 11.0

Gone are the days when we only have to edit a simple httpd.conf for Apache to run and do our bidding. I spent an ample amount of time trying to figure out how to make Apache2 on OpenSuse 11.0 run with SSL. So, I'm writing these down for all my fellow idiots in hopes that whoever is responsible for this travesty would somehow realize that enabling SSL should be simple enough to mere idiots like myself and thousands moreout there.

So here goes...

First up, make sure you tell Apache2 that you want SSL. So, add the `SSL' to the global configuration variable `APACHE_SERVER_FLAGS' found in `/etc/sysconfig/apache2'.

Second, edit `/etc/apache2/listen.conf' and add the IP-port combination of where you want apache2 to listen. In my configuration, I added the following :

Listen 10.10.10.3:80
Listen 10.10.10.4:443

Third, make virtual host settings in `/etc/apache2/vhosts.d' (Just copy the templates and go from there, you might want to do other funky things with your virtual hosts). To be more explicit about what I meant about copy, here's what I did on the prompt:

# cp /etc/apache2/vhosts.d/vhost.template /etc/apache2/vhosts.d/vhost.conf
# cp /etc/apache2/vhosts.d/vhost-ssl.template /etc/apache2/vhosts.d/vhost-ssl.conf

In my case, the only important thing I wanted to setup on my vhost configs was my DocumentRoot. So, I placed /srv/www/htdocs for non-SLL requests(vhosts.conf) and /srv/www-ssl for SSL requests (vhost-ssl.conf).


Fourth, comment out the `Include /etc/apache2/sysconfig.d/include.conf' in `httpd.conf'. It causes Apache2 to not run for reasons that I do not want to know of.

Fifth and the most important, all configurations that are wrapped in the following tags should be commented out:

<IfDefine SSL>
<Ifdefine !NOSSL>
<IfModule mod_ssl.c>

As far as I can remember, these exists in `listen.conf', `ssl-global.conf' and `vhost.d/vhost-ssl.conf'.

So, here's my sort-of-rant about the whole SSL thing(this is highly influence by the frustration brought about by the comment-out-IfDefines part): First, enabling SSL should be easy (very minimal changes in the configuration). As a matter of fact, it would be so much better if it were already enabled by default.

Second, for some freak of nature the IfDefines did not work. It caused me to go around in circles trying to find out why apache would not listen to port 443 even if `SSL' was already set in `APACHE_SERVER_FLAGS'. I decided to remove all IfDefines/IfModules around all SSL related configurations and it everything worked smoothly like a well lubricated orifice. I'm guessing this problem is OpenSuse sepcific -OR- it could also be user specific, meaning, I missed something... somewhere... over the firggin' rainbow.

Anyway, if ever I get the time, I'll try to research more on this issue and if it IS a bug, I'll probably bring this up on OpenSuse's mailing list.

Configuring rum(4) Interface for DHCP on OepnBSD 4.3

A couple of posts back, I wrote about making my D-Link USB wireless adapter (DWA-110) work with OpenBSD 4.3. This time, I'll post how I made it work as an AP and "un-securely" assign IP addresses to any host.

First, I created a file `/etc/hostname.rum0' and put the necessary information needed for the interface to work as an AP. In my case, I placed this line (this very self-explanatory, no need to explain each part):

inet 172.168.255.1 255.255.255.0 172.168.255.255 media autoselect mode 11g mediaopt hostap nwid jakosalem chan 11

Second, I wanted DHCP to listen to the rum(4) interface and spew out IP addresses for requesting hosts. I did this by adding the interface name `rum0' to the `/etc/dhcpd.interfaces' file and then, I edited `/etc/dhcpd.conf' and placed the following lines:

default-lease-time 3600;
max-lease-time 86400;

subnet 172.168.255.0 netmask 255.255.255.0 {
option routers 172.168.255.1;
option broadcast-address 172.168.255.255;
range 172.168.255.100 172.168.255.254;
}

Lastly, to make DHCP run everytime I boot, I added the line `dhcpd_flags=""` to `/etc/rc.conf.local'.

And that's about it - DHCP for wireless clients at home. Wohoooo!

NOTE: This configuration lacks security measures - OBVIOUSLY - to the point where an any security-pundit would most likely choose to slash his/her wrists rather than think about the sheer absurdity of this configuration. I'll post a more secure configuration when I'm bored enough and have nothing else to do.