Managing the security training sites
These are the quick notes about how to set up and run a bunch of virtual grid sites for training purposes.
Overview
The virtual machines for these sites are managed with Xen Cloud Platform (XCP) on blade 0, partition b. Log in as root@pool-bl0b.inst.ipmi.nikhef.nl. to manage these virtual machines or use a client tool such as Xen Centre.
The sites live on vlan 41, which is only available on bl0b. There is only one host with an interface to the outside, called melkstal.nikhef.nl (in the Open/Experimental network). This host serves as the gateway for all the participants in the training and the site administrators. It also serves as a NAT box. Participants won't log into melkstal directly; port forwarding has been set up so using ssh to a specific port on melkstal will land the user on the root account on a machine in the virtual domain, using their ssh public key.
On the inside of vlan 41, the network addressing is divided up by virtual site (to connect make sure to have your ssh-keys in your keyring):
| IP range | domain name | login method | details |
|---|---|---|---|
| 10.1.0.0/16 | darknet | ssh root@melkstal.nikhef.nl | management systems and example site |
| 10.1.1.0/16 | frogstar | ssh -p 2201 -A root@melkstal.nikhef.nl | |
| 10.1.2.0/16 | traal | ssh -p 2202 -A root@melkstal.nikhef.nl | |
| 10.1.3.0/16 | krikkit | ssh -p 2203 -A root@melkstal.nikhef.nl | |
| 10.1.4.0/16 | megadodo | ssh -p 2204 -A root@melkstal.nikhef.nl | |
| 10.1.5.0/16 | magrathea | ssh -p 2205 -A root@melkstal.nikhef.nl | |
| 10.1.6.0/16 | vogsphere | ssh -p 2206 -A root@melkstal.nikhef.nl |
Each site runs a number of machines to represent what is typical for a Grid site:
| machine name | machine type | metapackage |
|---|---|---|
| ui | User interface | emi-ui |
| wms | Workload management system and site BDII (currently not functioning) | emi-wms, emi-lb |
| ce | CREAM Compute Element | emi-cream-ce |
| headnode | batch system head node (HTCondor) | condor |
| wn | Worker node | emi-wn |
| jeep | general purpose machine | none |
There is one management host to help install and configure all other machines: cobbler.darknet. This system runs cobbler to help systems install with DHCP, DNS and kickstart files. It also runs saltstack to manage state on each system.
Installing and re-installing machines
Installation of new machines is done on the XCP master node. Log in as
root@pool-bl0b.inst.ipmi.nikhef.nl
In the home directory you will find this script which will create basic machine definitions from a template. It will give the machines a new interface with a generated MAC address.
The next step is to take the list of machines and their mac addresses (using another script) to cobbler.darknet and to define the systems in cobbler. There is a script for that. For example:
echo 22:05:e5:52:19:cc wms.darknet | ./cobbler-add-machine.sh
Right now, the script only adds machines consecutively to the darknet site.
It is also possible (but more tedious) to add machines via cobbler's web interface.
Once the machines are defined in cobbler it is time to start them. This is again done on the XCP node with the command
xe vm-start vm=wms.darknet
This will install a basic system, using cobbler for DHCP and for downloading the kickstart file.
As part of the basic installation, the package salt-minion will be installed with cobbler.darknet as the master. Once the installation is done, accept the key on cobbler with
salt-key -a <hostname>
One the link between master and minion is established, run the high state on the minion to implement all the state modules defined for it.
cobbler# salt 'machine.domain' state.highstate
Be patient as this command can take a long time to complete.
re-installation
It may be necessary to start from scratch with a machine. This is easier than a new installation, as the definition already exists in XCP and cobbler. The only thing that needs to be reset is the bootloader. The script Media:Vm-reinstall1.sh does just that. It also reboots the machine, so it will go into installing right away.
After the re-installation it is still necessary to run the state.highstate command to make sure the machine is in proper working condition (and ssh public keys are installed, otherwise logging in becomes quite difficult!).
cobbler# salt 'machine.domain' state.highstate
The previous ssh and salt keys are preserved during the installation, so it should not be necessary to re-initialize. Should this fail, check the following:
- Does the minion ping from the salt master?
cobbler# salt 'ce.vogsphere' test.ping
- If so, everything is ok.
- If not, check the logfile of the master to see if a different key was presented
/var/log/salt/master
- Log on to the console of the VM and restart the minion:
pool-bl0b# xe console name-label=ce.vogsphere
- Restart the minion. Check the minion logfile. If the key is rejected because it changed, the minion will halt again.
- In that case, make sure to remove the minion key from cobbler
salt-key -d ce.vogsphere
More troubleshooting
A machine may not be entirely configured after running the High State. This could especially be true of the CE's which run CREAM. You may find that a consecutive run will not invoke YAIM again; to force its run just remove
/etc/siteinfo/site-info.def
So it will be reloaded and trigger the running of YAIM.
Especially since not all dependencies have been figured out between the state items, it may be necessary to run highstate a few times. This can also be done from the minion, by invoking
salt-call state.highstate
Darknet CA
The test sites will need certificates, so a local simple CA is set up on cobbler.darknet in /srv/ca.
New certificates can be generated with the gen-host-cert.sh script. This automatically places the cert and key in /srv/salt/host_keys.
Issuing CRLs can be done by calling
./make-crl /var/www/html/7140638d.r0
Saltstack setup
After systems are installed with Cobbler, saltstack takes over. The machine cobbler.darknet is the salt master. Test the connection to the minions by running a ping test.
salt '*' test.ping
All machines should report in. If not, log in to the machine and check the salt minion log
/var/log/salt/minion
The saltstack description of the system is kept in a collection of YAML files under
/srv /srv/pillar /srv/salt
The pillar is just static data. The salt tree contains references to various machine types and modules, als well as files that are copied over to the minions such as ssh keys.
git repository
The salt tree is maintained with git. Set up a remote: git clone ssh://root@cobbler.darknet/root/salt
and check out the 'useyaim' branch. Whenever this branch gets pushed, the repository under /srv will be automatically updated (via a post-receive hook).
Adding users
Adding administrators for one of the sites mentioned above is done by adding their ssh public keys to the corresponding file /srv/salt/ssh_keys/domain.pub and running the salt state command:
salt '*.<domain>' state.highstate
Adding ordinary users for a site is done by adding their details in the pillar, much like the examples already given in /srv/pillar/users/frogstar.sls:
users:
dent:
fullname: Arthur Dent
shell: /bin/bash
home: /home/dent
uid: 604
groups:
- users
Take care to keep the uids unique. After adding the user, put the ssh public key in /srv/salt/ssh_keys/dent.pub. Again running
salt '*.frogstar' state.highstate
will update all frogstar machines to include the new user.
All these users will be present on all of the training sites.
list of current state files
Warning: this list is always outdated.
pillar/top.sls + set environments (just 'base') pillar/versions.sls + selects tomcat5 or tomcat6, based on OS pillar/vos.sls + static list of VOs to support, including pool account settings and vomses pillar/users/darknet.sls + (admin) users in the darknet domain pillar/users/frogstar.sls + (admin) users in the frogstar domain salt/top.sls + top file, defines what's what salt/condor/init.sls + settings common to all types of condor machines salt/condor/worker.sls + settings for a condor worker node (WN) salt/condor/submitter.sls + settings for a condor submitter (CE) salt/condor/manager.sls + settings for the condor manager (LRMS) salt/condor/config.local/manager + the literal configuration files salt/condor/config.local/worker + salt/condor/config.local/submitter + salt/users/frogstar.sls + adds the ssh keys for the users to root's authorized_keys salt/users/init.sls + create users according to the pillar salt/users/poolaccounts.sls + create poolaccounts according to the vos pillar salt/grid/bdii/init.sls + setup of a (top level) BDII salt/grid/yaim/init.sls + downloads a templated version of site-info.def salt/grid/yaim/siteinfo/users.conf + the siteinfo files salt/grid/yaim/siteinfo/wn-list.conf + salt/grid/yaim/siteinfo/vo.d + salt/grid/yaim/siteinfo/vo.d/tutor + salt/grid/yaim/siteinfo/vo.d/pvier + salt/grid/yaim/siteinfo/vo.d/dteam + salt/grid/yaim/siteinfo/groups.conf + salt/grid/yaim/siteinfo/site-info.def + salt/grid/repositories/emi3.sls + yum repositories for EMI-3 (for WMS) salt/grid/repositories/init.sls + yum repositories UMD-3 salt/grid/wn/init.sls + setup of WN salt/grid/gridmapdir.sls + populate the gridmapdir according to pillar data salt/grid/trustanchors.sls + yum repositories of certificate repositories, plus extra CAs salt/grid/ui/init.sls + setup of UI salt/grid/ui/vo-glite_wms.conf + templated files for the UI salt/grid/ui/vo-glite_wmsui.conf + salt/grid/ui/glite_wmsui_cmd_var.conf + salt/grid/cream/init.sls + CREAM setup (with condor batch system) salt/grid/cream/blah.config + templated version of blah.config salt/grid/hostcert/init.sls + install host certificates salt/grid/wms/init.sls + configure a WMS salt/network-gateway/init.sls + just for melkstal salt/sysctl.sls + adds sysctl settings to improve ZMQ performance salt/ca + CA files for the DARKNET CA and the e-infra tutor CA salt/timezone.sls + Sets the timezone to whereever.
