Ian,
Ben has answered most of these already.
> -----Original Message-----
> From: Ian Stokes-Rees [mailto:[log in to unmask]]
> Sent: Monday, December 23, 2002 5:30 PM
> To: [log in to unmask]
> Subject: Installing v1.4.0 questions
>
>
> I am working through upgrading our machines from v1.2.x to v1.4.0
> following the details on the GridPP web site. The LCFG
> install has gone
> fairly smoothly, but when it comes to actually getting the individual
> machines up and running I am encountering several problems.
> I think these
> stem from i) the site-cfg.h file; and, ii) the individual machine
> profiles. If anyone can help me with the following
> questions, I'd greatly
> appreciate it:
If you would like to send me your site-cfg file I can take a look.
>
> 1) Where do the root passwords come from on the various node
> machines? Is
> this from some previous install? I thought LCFG allowed
> installation of
> other nodes "from scratch" requiring only PXE, a boot disk,
> and a PXE boot
> server which knows what name that machine should be given. LCFG then
> matches this up with a profile and installs whatever is
> required. I think
> some part of this understanding must be wrong.
>
So you only need to consider pxe if you want to use that instead of
of boot floppy.
So the machine at installation uses the values obtained from
the dhcp server to determine its name and so what profile it should
download by looking for http://lcfg.gridpp.rl.ac.uk/profiles/hostname.xml
> 2) Where do nodes get their certificates and keys from? How does LCFG
> know where to get these to plonk them into the right location?
>
The keys and certs are installed by hand.
> 3) Where do user passwords come from?
>
So local pool accounts are created on CE, SE, WN. These do not
require passwords. The method presented in the LCFG notes is the
simplest case where the nodes can be dedicated.
> 4) Is /tmp/edg-release really where LCFG configuration details are
> permanently stored? For example, this is the only place I
> can find the
> rpmlist directory which has the 2.0.4 error (should be 2.0.5, if I
> understood the emails earlier this month correctly).
>
/tmp/edg-release is just a staging area during the gpp-install script.
/var/obj/conf/profile/source
and
/opt/local/linux/6.2/rpmlist
are the two significant directories.
> 5) The v1.2.0 setup put in a "gatekeeper" machine. I don't understand
> what the purpose of this machine is. I see that it also acts
> as the UI
> for us, but don't know what _else_ being the "gatekeeper" implies.
>
So the gatekeeper runs on the node that is often called the CE. You can
cleanly divide the machine types into two groups. CE, WN and SE have
pool accounts and have no interactive logins. The UI has local accounts
for real people which is why installing the UI separately into your local
NIS is often a sensible idea.
There is some confusion though about what a CE is. Correctly middleware
developers refer the WNs and a head node with the gatekeeper on as a CE
since this is presented as a single CE to the grid. This node that is
presented to the out side world is often called the CE since this is
the node that is presented. The CE is where the queues can be accessed.
> 6) Is it correct that UI machines are tied in to LCFG just
> like any other
> -- with a configuration file in the /var/obj/conf/profile/source?
>
It can be, and you can after some extra fiddling LCFG install a UI into
a local NIS.
> 7) How does LCFG map the .xml files generated by mkxprof to a
> particular
> machine?
>
I think the earlier answer about dhcp answers this.
> Cheers,
>
> Ian.
>
> --
> Ian Stokes-Rees [log in to unmask]
> Particle Physics, Oxford
> http://www-pnp.physics.ox.ac.uk/~stokes
>
|
