Difference between revisions of "Agile testbed"
From PDP/Grid Wiki
Jump to navigationJump to search| Line 44: | Line 44: | ||
All changes need to be communicated by e-mail to [mailto:CTB-changelog@nikhef.nl CTB-changelog@nikhef.nl]. | All changes need to be communicated by e-mail to [mailto:CTB-changelog@nikhef.nl CTB-changelog@nikhef.nl]. | ||
(This replaces the earlier [[CTB Changelog]].) | (This replaces the earlier [[CTB Changelog]].) | ||
| + | |||
| + | If changes affect virtual machines, check if [[Agile testbed/VMs]] and/or [[NDPF System Functions]] need updating. | ||
=== creating a new virtual machine === | === creating a new virtual machine === | ||
| − | + | In summary, a ''new'' virtual machine needs: | |
| − | + | # a name | |
| − | + | # an ip address | |
| − | + | # a mac address | |
| − | |||
| − | + | and, optionally, | |
| + | * a recipe for automated customization | ||
| + | * a host key for SSL | ||
| − | + | The name/ip address/mac address triplet of machines '''in the ''testbed'' domain''' should be registered in /etc/hosts and /etc/ethers on '''bleek.nikhef.nl'''. The choice of these is free, but take some care: | |
| + | * '''Check''' that the name doesn't already exist | ||
| + | * '''Check''' that the ip address doesn't already exist | ||
| + | * '''Check''' that the mac address is unique | ||
| − | + | For machines with '''public IP addresses''', the names and IP addresses are already linked in DNS upstream. Only the mac address needs to be registered. | |
| + | '''Check''' that the mac address is unique. | ||
| − | + | After editing, | |
| − | + | * '''restart''' dnsmasq | |
| − | + | /etc/init.d/dnsmasq restart | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
* on span.nikhef.nl, run | * on span.nikhef.nl, run | ||
/usr/local/bin/keygen <hostname> | /usr/local/bin/keygen <hostname> | ||
| Line 135: | Line 110: | ||
** With Debian preseeding, this may be automated by either setting <tt>d-i netcfg/dhcp_options select Retry network autoconfiguration</tt> or <tt>d-i netcfg/dchp_timeout string 60</tt>. | ** With Debian preseeding, this may be automated by either setting <tt>d-i netcfg/dhcp_options select Retry network autoconfiguration</tt> or <tt>d-i netcfg/dchp_timeout string 60</tt>. | ||
* Sometimes, a storage device is re-used (especially when recreating a domain after removing it '''and''' the associated storage). The re-use may cause the partitioner to see an existing LVM definition and fail, complaining that the partition already exists; you can re-use an existing LVM volume by using the argument: <tt>--disk vol=vmachines/blah</tt>. | * Sometimes, a storage device is re-used (especially when recreating a domain after removing it '''and''' the associated storage). The re-use may cause the partitioner to see an existing LVM definition and fail, complaining that the partition already exists; you can re-use an existing LVM volume by using the argument: <tt>--disk vol=vmachines/blah</tt>. | ||
| + | |||
| + | |||
| + | === importing a VM image from another source === | ||
| + | |||
| + | === Migrating a VM to another host === | ||
| + | |||
| + | (that shares storage with it) | ||
| + | |||
| + | === decommissioning a VM === | ||
| + | |||
| + | |||
| + | === User management === | ||
| + | |||
| + | ==== adding a new user to the testbed ==== | ||
| + | |||
| + | ==== removing a user from the testbed ==== | ||
| + | |||
| + | ==== granting management rights ==== | ||
| + | |||
| + | ==== adding a non-Nikhef user to a single VM ==== | ||
| + | |||
| + | |||
| + | === Requesting and installing server certificates === | ||
| + | |||
| + | Host or server SSL certificates for volatile machines in the testbed are kept on span.nikhef.nl:/var/local/hostkeys. The FQDN of the host determines which CA should be used: | ||
| + | * for *.nikhef.nl, the TERENA eScience SSL CA should be used, | ||
| + | * for *.testbed, the testbed CA should be used. | ||
| + | |||
| + | ==== Generating certificate requests for the TERENA eScience SSL CA ==== | ||
| + | |||
| + | * Go to bleek.nikhef.nl:/var/local/hostkeys/pem/ | ||
| + | * Generate a new request by running ../[https://ndpfsvn.nikhef.nl/cgi-bin/viewvc.cgi/pdpsoft/trunk/agiletestbed/make-terena-req.sh?view=co make-terena-req.sh] ''hostname''. This will create a directory for the hostname with the key and request in it. | ||
| + | * Send the resulting newrequest.csr file to the local registrar (Paul or Elly). | ||
| + | * When the certificate file comes back, install it in /var/local/hostkeys/pem/''hostname''/. | ||
| + | |||
| + | ==== Requesting certificates from the testbed CA ==== | ||
| + | |||
| + | Kindly ask Dennis. The CA key is on his eToken, which means no one else can generate host certificates. Some time in the future this will be replaced by a simple CA setup on the testbed itself. | ||
| + | |||
| + | |||
==== Automatic configuration of machines ==== | ==== Automatic configuration of machines ==== | ||
