Hi Junichi, *,
At 03:31 08-12-03, Junichi Tanaka wrote:
>[...]
>BWT, I have a question.
>At "Appendix E", there is the following statement:
>- edit the redhat73-cfg.h file in the release source directory and do the
> ":/tmp" trick, i.e.:...
>What is this purpose? and after rebooting all nodes,
>is it necessary to edit "redhat73-cfg.h" again
>in order to make it back?
This "trick" triggers the actual invocation of the updaterpms LCFGng object.
The way LCFG operates is as follows:
* when the object runs, the new configuration is stored in a local
state file for the object
* whenever a new configuration is "pushed" to the nodes, the new
configuration for every object is compared to this "saved state"
* only if this state is different, will the object be run.
All objects specified in the boot.services are run at boot time on
the clients, and at this time the "initial state" is saved in
/var/obj/status/
Changes are then noted with respect this initial configuration.
Now, for the updaterpms object, there is a small problem: the list of
RPMs to install is *not* a LCFGng resource, but is contained in an
external file (call "UI-rpm", for instance). Changes to this file,
like a new kernel RPM) are not recornised by the LCFGng system as
a "modified state", and this the updaterpms object is not run!
But, any change to the resources/configuration of updaterpms will trigger
a run of the object,and this - almost as a side effect - install the
new RPMs as specified in the rpmlist file :-)
This is what will happen if you add a useless directory (like /tmp) to
the updaterpm.rpmdir configuration.
It will work even regardless of which resource in updaterpms is
modified. Another safe and easy choice is setting "updaterpms.offline" to
any value but "yes", like:
+updaterpms.offline upd031204171100-13897
Here at NIKHEF, it is set to an automatically generated value based
on date and time (code snipped below), so it is guaranteed to be different
whenever mk_xprof is run with a special commandline argument.
As long as updaterpms.offline is NOT "yes", it will freshen the RPMs on
the client. If you add a updaterpms.offline to each node profile, you can
trigger per-client RPM updates reasily. Or put it in a common include
file to trigger fabric-wide upgrades.
Cheers,
DavidG.
PS:
It MUST be noted that this trick with /tmp is, however, a security
risk. Everyone can (on the worker nodes, for example using a grid job and
a proper input sandbox) install "random" RPMs in /tmp. For example I could
put my own kernel-2.4.20-24.7smp.i686.rpm file in /tmp. Depending on
local configuration, this RPM will actually be installed from the untrusted
/tmp directory.
So better change it back later (after all nodes are rebooted)!
>From: Emanuele LEONARDI <[log in to unmask]>
>Date: Thu, 4 Dec 2003 16:57:56 +0100
>
> > Release LCG1-1_1_3 has just been tagged in the LCG CVS repository.
> >
> > This includes a fix for a critical security bug in the Linux kernel: it
> > is recommended that all sites update to the new version as soon as
> possible.
> >
> > Some new software for CMS has also been added on WNs.
> >
> > A full list of changes and a detailed update procedure are included in
> > the usual lcg1-notes.txt file: read this document carefully as the
> > update procedure is a bit more critical than usual and requires some
> > extra steps.
> >
> > Please report on the RollOut list when your site is updated.
TOK=`date '+%y%m%d%H%M%S'`
TOK="upd$TOK-$$"
for node in "$@"
do
if [ `grep -c '^+updaterpms.offline' $node` -eq 0 ]; then
echo "+updaterpms.offline $TOK" >> $node
else
mv $node $node.bak
sed -e 's/^+updaterpms\.offline .*/+updaterpms\.offline '$TOK'/' <
$node.bak > $node
if [ -s $node ]; then
rm -f $node.bak
else
rm -f $node
mv $node.bak $node
fi
fi
touch $node
done
--
David Groep
** National Institute for Nuclear and High Energy Physics, Grid/VL group **
** Room: H1.57 Phone: +31 20 592 2179, PObox 41882, NL-1009 DB Amsterdam NL **
|
