Updates on a few things.
Release v1_0_0 of the EDG software was finally tagged on Friday. This is
in fact the first release to be tagged and claimed to be complete,
including configuration objects.
(What versions constitute the release is defined by the LCFG .h files in
http://datagrid.in2p3.fr/cgi-bin/cvsweb.cgi/edg-release/rpmlist/ and the
tagging of this in CVS is when the release becomes official, and fixed.)
Yesterday I rebuilt the lists of rpms for the release which currently live
in http://datagrid.in2p3.fr/distribution/rpmlists/ The procedure for
doing this has changed slightly since I last did this a couple of weeks
ago: the lists now include all RedHat 6.2 RPM's which are listed in the .h
files. The "download pages" (like
http://datagrid.in2p3.fr/distribution/rpmlists/CE.v1_0_0.i386.rpms.html )
which can be used with wget to grab files from the repository now include
RPM's from the base RH62 distribution, since these are in the repository
too now. (This is partly for convenience, but also avoids the problem
with the wrong version of rpm being installed that some people saw last
week.)
Today I did try doing a kickstart install with the new lists, but it seems
they are now too large and anaconda throws up size errors due to the very
large number of packages.
However, it was already sounding better to come up with an LCFG-based
solution, assuming they are published reasonably promptly (ie the
discussion on Thursday at the Applications Teach-in) I've been looking at
making a kickstart-like procedure for installing the site's LCFG server,
so we can then do normal LCFG installs and configurations for the
different elements.
I'm trying this out with a central webserver which has a modified copy of
RedHat 6.2, with the LCFG RPM's present, and included in the hdlist and
comps files. You then install off this using a normal RH62 bootnet.img
disk, specify your IP address, keyboard type etc, and accept the default
sets of packages (which includes LCFG Profile Server as one of the sets.)
This should still allow us to quickly rollout new releases to everyone,
including the smaller sites (once we come up with a working solution) but
means we don't have to worry about translating the configuration
information from LCFG objects into scripts to run after or during
kickstart. And since installing a node from a working, local LCFG Profile
Server is essentially the same as a kickstart install, it should be
straightforward to do: I think it is very important to find as painless a
way of rolling out new versions as possible, bearing in mind the short
official release cycle and the fluidity of everything still.
One thing Alex raised on Thursday was the issue with BOOTP: the LCFG
machine expects to act as the BOOTP server for its testbed machines, but
this may conflict with existing BOOTP/DHCP servers depending on how your
network is wired.
You can configure the LCFG server's dhcpd, which provides BOOTP, to refuse
clients whose ethernet MAC addresses aren't in its /etc/dhcpd.conf, but
the LCFG server itself can't stop another BOOTP/DHCP server on the network
grabbing a booting testbed client and giving it an IP number. To do that,
you need to have control/access to the DHCP server on your network (since
you can tell it to ignore specific MAC addresses, using the deny booting
keyword.) How many of you are in a position to do that for your testbed
machines?
Another option is to get BOOTP support turned off altogether (deny bootp)
in your non-testbed DHCP/BOOTP server. (None of the normal boxes here are
still using BOOTP, for example.)
So, to summarise:
o The lists for v1_0_0 are on the datagrid.in2p3.fr server if anyone wants
to try a manual install of it.
o I think we should drop kickstart as a way of installing CE's etc.
o I'm coming up with a recipe for installing the local LCFG servers,
reusing the kickstart stuff. (This will be provided from a central web
server so all you should need is a standard boot floppy.)
Cheers,
Andrew
|