Skip to end of metadata
Go to start of metadata

Note: please do not add to this page content - add comments and I will fold them in as I go.

Primary Server Build

Resin Apps

I tend to prefer a container instance per app - losing everything when one app needs to be restarted is annoying.

  • unity
  • confluence (depending on where it goes)
  • jive wildfire (IM platform) - not sure if it is loaded into a container or not though


  • screen
  • postgres 8 (8.0 / 8.1 either is fine) with -devel for headers
  • cronolog
  • apache2 (no apache 1 in brave new world)
  • irc server - currently ngircd but we don't overly care
  • ldap server (openldap or better)
  • java - 1.4 and 1.5; most reliable VMs you can get for given OS - IBM / Sun etc. SDK (not JRE) installs required.
  • openssl
  • fisheye (we can handle configuration for this - we have quite a few repositories)
  • mail + mailing list packages (currently using qmail with ezmlm)
  • python (2.4 or later)
  • ruby-latest (to be installed by bob)
  • tinydns
  • resin (3.0 series) - primary app server
  • jrockit (jdk 1.5 series) - primary jvm - if it doesn't work out we'll try something else
  • confluence - although putting jira+confluence together might make more sense - on this box or the existing jira one
  • daemontools


  • nagios
  • awstats
  • cacti


  • mysql

General Rules

  1. No users
  2. Very very limited despots. Probably only 2 or 3.
  3. No builds
  4. Preferably no compilation of tools - packaged tools only.
  • No labels


  1. My suggestions:

    • Name server - I would recommend tinydns. It's small and handles significantly more load that named can. We (Contegix) can provide a secondary if you wish regardless of which you use.
    • J2EE containers - Think about which container will be used and what applications will be in each.
    • JDK/JSDK - I highly recommend BEA JRockit. Yes, it's commercial but our internal testing in the real world show it handling significantly higher loads.
    • DBs - Unless you need MySQL, scrap it.


  2. One other suggestion - Put configuration files (like tinydns records or zone files) in Subversion.


  3. Speaking of configuration...

    Yes, we'll be scripting and automating the hell out various configuration files. We may also stick them into SVN, but ultimately, they aren't source files, just generated from our stuff.


    With each thing installed, could we get details of how your installations handle configuration, with full paths, notes, etc? ferinstance, that you guys use /etc/httpd/conf/vhosts/*.conf or whatnot for vhost configuration. We'll tweak up our Xircles stuff to play friendly with your supported configuration techniques and locations.