This is more of a future reference post, but if you have the same problem we sometimes face with lots of developers logging into the same remote win2003 server, where both terminal sessions are taken. And sometimes both are taken by the developer who's just gone on holidays! So then you either have to drag you butt down to the server room to kill sessions from the terminal or even worse ring up the data centre for a hosted box.

Well fret no more! you can run the following commands easily to kill any remote sessions to a box from a winXP (and vista i presume?) or parallels for the macl33t

1: Open windows command prompt

2: to view current connections: qwinsta /server:myserver

This results in an output of

3: kill a session by: rwinsta [sessionID] /server:myserver

i.e. rwinsta 2 /server:myserver

If the title makes sense then the rest of the article will be a breeze.

For some the hardest part of Apache is the fact that there is no GUI (Graphical User Interface) for the configuration. To me it's the reason I love apache! While it might be a bit daunting if you are new to Apache the power and flexibility that the text file configuration gives you is simply not feasible in an GUI.

At RedBalloon we have a number of different sites and a number of different servers so being able to manage the config files and lay them out to suit our needs it a huge boost. On top of this, we version our config files using subversion which gives us backups, rollback and a version history.

The windows installer sets up a basic and very well commented config which is a great base to start from. We typically add the following line at the end to allow simple loading of the virtual host config files:

Each vhost file consists of a number of related virtual host sections:

We deliberately add listen directives at the top of the vhost file to easy migration of sites from one machine to another. All settings for a particular site are in one spot.

The sites in any one file are all related - i.e. for redballoon we have the main consumer site, our suppliers extranet site etc all in the one config.

The inner sections of the virtual host looks as follows:

By moving all of the common/repeated lines out to well named include files the vhost section is very simple to read and understand. It also makes it easy to add an alias across common sites or change the cfinstance the website is using.

Each of the include files is just the lines that would be directly in the file pulled out to an external file.

Eg - the cfinstance/example1-instance

Gotchas

SSL certificates

If you are using SSL sites with name based virtual hosting there is a limitation which is: You can only have one SSL certificate - This works fine if all the sites are under the same domain - i.e. site1.example.com & site2.example.com and you have a wildcard certificate - *.example.com. The reason for this limitation is that when the server sends the SSL cert it doesn't yet know which domain you are looking for as it happens at the negotiation phase. Once the SSL cert is in use though the request proceeds correctly and serves the correct site.

Wildcard sites - *.example.com

Apache supports the * operator for sites which mean any subdomain site will match this virtual host. With name based virtual hosting only the first site on a particular IP address will be able to do this. So it wouldn't work to have *.example1.com and *.example2.com on the same IP address. To get around this you need seperate IP addresses for each group of sites.

Conclusion

Apache configs are not as scary as you think - and the documentation is great. They allow you loads of control of the server, are easy to backup and can be used with version control and can be edited with any editor of choice.