It Could Drive a Man to Drink
Okay, so today I finished an arduous task that, were it not for the learning curves and stupidness that I encountered, probably boiled down to about two hours of work. Instead, it took me about 15.
I now have a server that is running CentOS 5.2, that hosts a VMWare image that is also running CentOS 5.2. This is so we can take the VM image and drop it onto a client's machine in order to deploy the website that we wrote for them - cool huh? As it happens, this is exactly the right thing to do since the following are things you do *not* want to troubleshoot while you're freezing your ass off, on a borrowed terminal, in a customer's datacenter. When I'm done pounding this into shape, the most a tech will have to do is configure VMWare on the host machine.
Experts reading this should keep in mind that I'm really more familiar with Ubuntu than Redhat; so some of this nonsense is probably n00bish at best.
- Establishing a fresh VMWare image is as simple as grabbing an .iso for the net-installer of your choice, putting it on the filesystem on the host machine, and then mapping it to the CD-ROM drive of your new VM. Too bad the VMWare docs don't mention any of that.
- VMWare NAT and Bridge address translation/routing work a lot better when both your guest and host operating systems do not have firewall restrictions in place. Se next item.
- 'iptables' is impossible to figure out just by reading the man page. Wound up turning the damn thing off rather than figuring out how to poke a hole in it for port 80.
- CentOS 5.2 has Postgres 8.1 in it's 'yum' (like 'aptitude') repository, but is grossly incompatible with some really basic stuff that's available in 8.4. Postgresql.org has some nice tips on how to work around this.
- CentOS 5.2 ships with Python 2.4. Do not attempt to uninstall it or upgrade it as half of the operating system tools depend on it. Running 'yum remove python' will in fact, remove 'yum' itself. See next item.
- When using VMWare, take advantage of the 'Take a Snapshot' feature. Having an instant rollback on your drive image is a many splendid thing; so use it when you have something working after a change.
- Apache 2.2 is standard on CentOS. However, the permissions it uses are NOT solely user/group based. It uses 'selinux' permissions that are visible if you use 'ls -Z'. "WTF are those?" you say. Well, allow me to save you five hours of googling about: if you don't have your site's assets tagged via 'chcon -R root:object_r:httpd_sys_content_t $dirname', Apache will respond with a 405 for those files.
- 'mod_python' is also standard and available through 'yum'. Unfortunately, you can't bind it to anything other than the standard install of python2.4 without rebuilding it from source.
- Did I mention that httpd.conf sucks? Well, CentOS's default version sucks harder, since it comes pre-packaged with every module in existence installed and enabled. That and its spread out across 6 different .conf files in a semi-non-standard-location. Good luck figuring out which ones you can safely turn off without killing your config; or don't and prey that you're not exposing some file tree or CGI type you shouldn't like I did.
- Psycopg2 is not in the 'yum' repository, but can be build from scratch; just get the latest source from initd.org. Be sure to 'yum gcc' before you start.
- Django 1.0 does not work out of the box with the RedHat build of Postgresql 8.4:
File "/usr/lib/python2.4/site-packages/django/db/backends/postgresql/version.py", line 16, in get_version
major, minor = VERSION_RE.search(version).groups()
AttributeError: 'NoneType' object has no attribute 'groups'
You need to modify the VERSION_RE regex in version.py, and delete the trailing '\.' from the expression since there is no build number in the version string. Why it was coded like this, I don't know, since the major and minor version numbers are neatly matched and extracted before matching that period.
- Django debug mode is nice in that it gives you a stack trace when something blows up. Turn this off, and you get sent to 505.html instead - if you have one! It would seem the Django docs are a little light on deployment strategies.
- Its a good idea to modify your pg_hba.conf to 'trust' for localhost db access so you don't have to worry about password information in your app. Hey, it's just sitting there in a flatfile, so its not like this is that much less secure. It also makes the Django DB stuff work a little more smoothly when sitting inside an Apache thread.
I now have a server that is running CentOS 5.2, that hosts a VMWare image that is also running CentOS 5.2. This is so we can take the VM image and drop it onto a client's machine in order to deploy the website that we wrote for them - cool huh? As it happens, this is exactly the right thing to do since the following are things you do *not* want to troubleshoot while you're freezing your ass off, on a borrowed terminal, in a customer's datacenter. When I'm done pounding this into shape, the most a tech will have to do is configure VMWare on the host machine.
Experts reading this should keep in mind that I'm really more familiar with Ubuntu than Redhat; so some of this nonsense is probably n00bish at best.
- Establishing a fresh VMWare image is as simple as grabbing an .iso for the net-installer of your choice, putting it on the filesystem on the host machine, and then mapping it to the CD-ROM drive of your new VM. Too bad the VMWare docs don't mention any of that.
- VMWare NAT and Bridge address translation/routing work a lot better when both your guest and host operating systems do not have firewall restrictions in place. Se next item.
- 'iptables' is impossible to figure out just by reading the man page. Wound up turning the damn thing off rather than figuring out how to poke a hole in it for port 80.
- CentOS 5.2 has Postgres 8.1 in it's 'yum' (like 'aptitude') repository, but is grossly incompatible with some really basic stuff that's available in 8.4. Postgresql.org has some nice tips on how to work around this.
- CentOS 5.2 ships with Python 2.4. Do not attempt to uninstall it or upgrade it as half of the operating system tools depend on it. Running 'yum remove python' will in fact, remove 'yum' itself. See next item.
- When using VMWare, take advantage of the 'Take a Snapshot' feature. Having an instant rollback on your drive image is a many splendid thing; so use it when you have something working after a change.
- Apache 2.2 is standard on CentOS. However, the permissions it uses are NOT solely user/group based. It uses 'selinux' permissions that are visible if you use 'ls -Z'. "WTF are those?" you say. Well, allow me to save you five hours of googling about: if you don't have your site's assets tagged via 'chcon -R root:object_r:httpd_sys_content_t $dirname', Apache will respond with a 405 for those files.
- 'mod_python' is also standard and available through 'yum'. Unfortunately, you can't bind it to anything other than the standard install of python2.4 without rebuilding it from source.
- Did I mention that httpd.conf sucks? Well, CentOS's default version sucks harder, since it comes pre-packaged with every module in existence installed and enabled. That and its spread out across 6 different .conf files in a semi-non-standard-location. Good luck figuring out which ones you can safely turn off without killing your config; or don't and prey that you're not exposing some file tree or CGI type you shouldn't like I did.
- Psycopg2 is not in the 'yum' repository, but can be build from scratch; just get the latest source from initd.org. Be sure to 'yum gcc' before you start.
- Django 1.0 does not work out of the box with the RedHat build of Postgresql 8.4:
File "/usr/lib/python2.4/site-packages/django/db/backends/postgresql/version.py", line 16, in get_version
major, minor = VERSION_RE.search(version).groups()
AttributeError: 'NoneType' object has no attribute 'groups'
You need to modify the VERSION_RE regex in version.py, and delete the trailing '\.' from the expression since there is no build number in the version string. Why it was coded like this, I don't know, since the major and minor version numbers are neatly matched and extracted before matching that period.
- Django debug mode is nice in that it gives you a stack trace when something blows up. Turn this off, and you get sent to 505.html instead - if you have one! It would seem the Django docs are a little light on deployment strategies.
- Its a good idea to modify your pg_hba.conf to 'trust' for localhost db access so you don't have to worry about password information in your app. Hey, it's just sitting there in a flatfile, so its not like this is that much less secure. It also makes the Django DB stuff work a little more smoothly when sitting inside an Apache thread.