Setup Needs for VDT Test Machines

Software Packages

• bash — we all use it

  Question: do we want a standard default bash setup script?

• a working C/C++ compiler — for building software locally

  Use gcc/g++ on Linux. Elsewhere, we need to think about this per platform.

  Test: compile and run a simple test program:

  #include <stdio.h>
  int main(int argc, char * argv[]) {
      printf("Hello, world!\n");
      return 0;
  }

• Condor (in /opt) — how can the VDT control when this is updated?
• cron — runs our tests
• diff — handy for debugging
• emacs — not necessary, but preferred
• gzip — gunzip required for VDT installs (vdt-untar)
• less — hard to imagine life without it, but technically optional
• C library, including headers & static libraries (maybe in a development package) — required by just about everything
• C++ library, including headers & static libraries (maybe in a development package) — required by just about everything
• Expat XML parser library — required by some Perl modules (see below)
• libtermcap
• make — needed for builds
• NTP — sync machine time/date
• OpenSSL — needed by some packages
• pacman (in /opt) — how can the VDT control when this is updated?
• patch — for certain builds
• Perl 5.8 or later — used to bootstrap a VDT install and run the test framework
• Perl modules:
  • Class::Phrasebook::SQL
  • DBD::Pg (PostgreSQL connector) — and the minimal set of PostgreSQL parts that are needed to make it work
  • DBI (database interface)
  • Data::Dumper (test framework (vdt-run-tests))
  • Digest::MD5
  • File::Flock
  • File::MkTemp
  • File::Spec
  • Getopt::Long (test framework, etc.)
  • HTML::Parser
  • HTML::Tree
  • LWP::Simple
  • Log::LogLite
  • Mail::Send
  • Pod::Usage
  • Schedule::At
  • Term::ReadKey
  • Test::Harness::Straps (test framework)
  • Test::More (test framework)
  • Time::Local
  • XML::Parser
  • XML::Simple
• Python — required for pacman and some VDT components
• Python development parts — required for some VDT components
• readline library — something links against it
• sudo — used frequently and needed by some VDT components
• symlinks - (Suse 9 only) This package needs to be built from source, it is otherwise unavailable on Suse 9. It is used in a test in install.t
• tar — required for VDT installs
• wget — handy for installs, should be optional if pacman works right
• xinetd — required by some VDT components (can fall back on inetd)
• Whatever else is needed to make Condor run (check port page) — historically, this requirement has often entailed getting a compatability library or two, especially libstdc++.
• On some x86-64 systems, we need all of the libraries and whatever else it takes to run 32-bit binaries.

Users

On every machine, we want a standard set of user accounts created. Some details to consider:

• CSL users should have the same UID as their CSL account; other users can be numbered as desired, but each user should have the same UID on every machine.
• Users should use bash, where available (which is everywhere, today). If not available, we'll have to come up with something.
• For every user, create a group of the same name and add the user to that group.
• Make sure every user has a home directory in the normal location for that platform (e.g., /home on Linux, /Users on Mac OS X). Make sure permissions are 0755 on each user’s home directory (not doing so causes VDT installations within the home directory to fail).
• Give selected users full administrative rights (e.g., can use sudo on Linux, is in the wheel and admin groups on Mac OS X).

Creating users properly on Mac OS X is tricky from the command line. Tim has a script that does most or maybe all of the necessary steps.

How can the VDT maintain the list of users? We add users as needed to help us with debugging. Also, how can we remove user accounts when they are no longer needed?

Some key users (and UIDs):

• vdttest (1000)
• roy (8471)
• cat (16501)
• kronenfe (5995)
• adesmet (3014)
• voms (?)

Configuration

Most of the configuration items below are underspecified as written. In all cases, we can use the existing WHAT configuration, the actual configuration we find currently on the machines, and just plain common sense to figure out the right requirements. Note that configuration may be host-specific in some cases.

• Install host and service certificates, if available (each host gets a different set of certificates)
• Disable SELinux
• Disable firewall
• Configure NTP to sync against CS server(s)
• Disable X11 startup at boot
• Disable automatic software updates
• Configure CPAN to get its download list from tds.net
• Create cron entries for reboot and for running tests
• Adjust file ownerships and permissions as needed (list can be extracted by inspecting WHAT, is platform dependent)
• Make sure some directories exist
• Make sure the /vdt symlink exists
• Tweak the Condor configuration
• Do something to Hawkeye?
• Use correct paths for user directories on Mac OS X (/Users instead of /home, and /private/var/root instead of /root)
• Make sure desired services (Condor, ntpd, ?) are running and will run upon reboot
• Make /etc/hosts right
• Distribute a /root/.ssh/authorized_keys files?
• Install the vdttest user certificate and key files
• Install the VDT test harness scripts — can we continue to get these out of our SVN?