The infrastructure team that we have at Adaptris is great; but sometimes when they setup a new vm image for me, there’s some things that are not quite right. I guess it’s because I’m a very particular kind of guy when it comes to how machines are setup. I thought that I’d write about how the development machines are setup. They’re setup just so which means that I can get working on them straight away1.
Our development machines are migrating to use CentOS 6 which is a source RPM rebuild of a prominent North American Enterprise Linux vendor; we still have quite a few machines that are based on Centos 5 but new machine deployments tend to be the latest stable release.
Generally speaking, we always run our machines at runlevel 3. That’s always been a choice we’ve explicitly taken; we don’t need the additional X11 overhead. There’s only one exception; you can’t install Progress Sonic 8.5 without X11 (the installer won’t run in console mode) - I’m sure that there are ways round this but when sh ./install.bin -i console doesn’t work like any other normal InstallAnywhere compiled installer, then that’s a little annoying.
Fixing the locale
It seems to me that our first set of kickstart scripts weren’t properly tested; when executing java for the first time, the file.encoding system property is sometimes ANSI_X3.4-1968 which basically means that the installation hasn’t set the locale properly, you can see this when you use locale command and it has a bit of a whine and moan about the default locale.
This is easily fixed by using localedef to define the locales properly
Removing unused packages
While the default installation is all well and good; my background has always led me to remove what I think are unnecessary packages, this is probably a function of growing up with only a 20Mb hard disk. These days I’m sure we could leave them installed and it wouldn’t have much impact but a little bit of spring cleaning never hurt anyone.
For a virgin Centos 6, runlevel 5 system, then there are always a bunch of RPMs that can be removed impacting any day-to-day activities. The standard list that I remove is as follows; of course YMMV depending on what the machine needs to do; it’s not such a big deal to yum install them afterwards.
That’s right I remove emacs; I don’t use it, vi is king, and always will be; nano if you have to.
The CentOS repositories are great and all but you’ll probably end up wanting some extra things that aren’t installed by default (by kickstart or otherwise).
As you’re probably aware git and mercurial are DVCS implementions. Internally, our source control is hosted under mercurial because at the time we migrated from CVS, git wasn’t really for Windows (yes it had a Windows port, but it was difficult and awkward); that’s probably changed with SmartGit and TortoiseGit being available. To me, Windows users still seem to be an afterthought for git; whether or not git is better or worse than mercurial isn’t an issue, there’s plenty of opinion on the web about that, I’m happy to use both and I’m not going to inflame opinions in the diehard fans of either camp.
Freenx is an application/thin-client server based on nx technology. Basically it allows us to tunnel an entire X11 session over ssh. You can find more about it at www.nomachine.com
Denyhosts is awesome. I install it everywhere that has a public IP address and accessible via SSH. Before I found out about denyhosts back in 2005, I had a hand-cranked script that parsed /var/log/secure for SSH hacking attempts on our servers; that worked well enough and is still used in some places. It wasn’t a bad script, just denyhosts is much better at it than anything a dilettante like myself could write. So this is a quick guide to setting up denyhosts up for your linux machine.
This creates a list of usernames that are considered restricted (all of them with an id < 500) which will force denyhosts to reject all attempts to login with say mysql; you should also at this point edit the allowed-hosts file to add in all the hosts that you never want to deny. This step is quite important because otherwise you might end up barring your own IP address when you can’t remember your own password.
I also add in/modify the following lines in /etc/denyhosts.conf to enable synchronization and emailling of when hosts are added into the deny file.
And that is that, we’re now ready to actually start deploying the application in question; java-based or otherwise.
By the time I’ve finished all of this I’m happy that I can install java/ant/maven on the machine and it’ll work to my satisfaction. ↩︎