Using Auto-Install for patches
Bob Van Valzah
standalone machines to set up and auto-install seems marvelous for this
purpose.
However, I can't figure out how to make it install patches as well as
the base OS. I suppose I can just throw pkgadd in my finish scripts,
but it seems like there should be something built into the auto-install
process to handle this. I can't be the only guy on the planet who
wants to automatically install the OS and the requisite patches at the
same time :-)
Am I missing something?
Bob
0000-Admin(0000)
: However, I can't figure out how to make it install patches as well as
: the base OS.
I discovered the same problem. Here's my uneducated analysis of
the situation. During the auto-install process, the filesystem is
mounted onto /a, so all of the pathnames in the installpatch scripts
will be wrong.
--
Jeff Rodriguez
Electrical & Computer Engineering rodr...@ece.arizona.edu
The University of Arizona Tel: (602) 621-8732
Tucson, AZ 85721 FAX: (602) 621-8076
Detlef Drewanz
We also had this Problem. Then I made a small shellscript that is to run
from auto-install-scripts. (For Solaris2.3)
-----
#!/bin/sh
# set_patch
# call it ONLY FROM auto-install-scripts
# D. Drewanz 12.09.1994 (d...@informatik.uni-rostock.de)
# Patch Directory
DIR=/export/Patches
if [ $# -eq 0 ]; then
TYP="mount"
echo "Setup Systempatches "
else
TYP=$1
fi
if [ $TYP = "patch" ]; then
# Get required Patches from a file
REQ_PATCHID=`cat $DIR/req_patches`
for patchid in $REQ_PATCHID
do
cd $DIR/$patchid
echo "Install Patch $patchid"
./installpatch -d $DIR/$patchid
cd ..
done
else
# 1. Mounting Patch-Database to /a
/sbin/mount -F nfs -o ro disthost:/export/install /a/export
# 2. Make a complete /usr
/sbin/mount -F nfs -o ro \
disthost:/export/install/export/exec/sparc.Solaris_2.3 /a/usr
/sbin/mount -F nfs -o ro \
disthost:/export/install/export/exec/kvm/sparc.sun4m.Solaris_2.3/kvm \
/a/usr/kvm
# 3. Start to Patch(rekursive)
/usr/sbin/chroot /a /export/install_info/tools/set_patches patch
# 4. Unmounting Filesystems
/sbin/umount /a/usr/kvm
/sbin/umount /a/usr
/sbin/umount /a/export
echo "Ready"
fi
---------------------------------
Hope this helps.
regards
--
+---------------------------------------------------------------+
| Detlef Drewanz e-mail: d...@informatik.uni-rostock.de |
| Dept. Network and Unix SystemManager |
| University of Rostock, Dept. of CS, Germany |
+---------------------------------------------------------------+
Alain Brossard EPFL-SIC/SII
|> : I'm using the auto-install feature of 2.4 and love it.
|> : However, I can't figure out how to make it install patches as well as
|> : the base OS.
|>
|> I discovered the same problem. Here's my uneducated analysis of
|> the situation. During the auto-install process, the filesystem is
|> mounted onto /a, so all of the pathnames in the installpatch scripts
|> will be wrong.
Of course! Just do a chroot /a .../installpatch ...
--
Alain Brossard, Ecole Polytechnique Federale de Lausanne,
SIC/SII, MA-Ecublens, C.P. 121, CH-1015 Lausanne, Suisse, +41 21 693-2241
bros...@sic.epfl.ch
Chad Adams
I never thaught of the chroot method someone else mentioned. I
create a /etc/rc2.d/S72aapatch.install script that installs them after
reboot and then deletes itself and reboots again. I also have a
/etc/rc3.d/S99auto.install script to do a /usr/ucb/lpc up all as that
will not work in the first one. It deletes itself after it runs also.
--
Chad Adams __ Educational Computing Network
Systems Programmer / ) / / University Park, IL USA
1-708-235-2200 / /_ __, __/ ECN, networking in IL since 1975
c-a...@bgu.edu (__/ / /_/_/_(_/_ "Wherever you go, there we are."
Alain Brossard EPFL-SIC/SII
|> In article <36d1j2$h...@news.CCIT.Arizona.EDU>, j...@mipl.ece.arizona.edu (0000-Admin(0000)) writes:
|> |> : I'm using the auto-install feature of 2.4 and love it.
|> |> : However, I can't figure out how to make it install patches as well as
|> |> : the base OS.
|> |>
|> |> I discovered the same problem. Here's my uneducated analysis of
|> |> the situation. During the auto-install process, the filesystem is
|> |> mounted onto /a, so all of the pathnames in the installpatch scripts
|> |> will be wrong.
|>
|> Of course! Just do a chroot /a .../installpatch ...
If I can be forgiven for following on my own article...
The ideal thing to do, is to have your post-install script setup the
chroot environment (mount local disks mostly) and then execute via
chroot your real post-install script. That way when writting the real
script you never have to worry about root being /a, etc.
Here is a snippet of Perl code which does the mount:
#
# Mount all the local file systems, get the information from /etc/mnttab
open ( MTAB, "/etc/mnttab" );
while( <MTAB> ) {
if ( m#^(/dev/dsk\S+)\s+(/\S+)# ) {
system( "mount -m $1 $2 > /dev/null 2>&1" );
}
}
close MTAB;
#
# Create a TMPFS /a/tmp for automatic cleanup afterwards
#
system "mount -F tmpfs swap /a/tmp";
# Generate a false/true /a/etc/mtab so that df works after a chroot
open ( MTAB, "/etc/mnttab" ); open ( mtab, ">/a/etc/mnttab" );
while( <MTAB> ) {
if ( m#^/dev/dsk# ) {
s#(\s+)/a(\s+)#$1/$2#;
s#(\s+)/a/#$1/#;
print mtab $_;
}
}
close mtab; close MTAB;
# 6- Now configure the upgraded machine
system "cp -p /usr/bin/perl /a/usr/bin";
system "cp -p $src_files/perl-lib/configure_host /a/tmp";
system "chroot /a /tmp/configure_host";
Greg Earle
Nope, you aren't. We wanted to auto-install the O/S (Solaris 2.3 Hardware:
5/94) and the Maintenance Supplement 1 patch CD-ROM at the same time. So
we did.
Run, do not walk, I repeat, *run* to get Casper Dik's (et al) FWI auto-install
package. It'll take you weeks (not man-weeks (-: ) to fully comprehend it all,
but you'll be damned glad you did. It allows you to do things like this,
and very easily at that.
Then after you've done everything & all the installs and all the machines are
up, and your users start discovering the 2 or 3 niggly-arse things that you
overlooked or didn't know about, then check out the update install script
that comes with it. It's genius. I came in to work today and my officemate
was down on his hands and knees in front of a printout of the update script,
bowing up and down and chanting "Ha Salami, ha salami .... <mumble> Great God
Casper ... <mumble> all praise be to Him <mumble> ... " :-) Turned out he'd
just finished reading & understanding the update install script and tested it
out in "don't do this but tell me what you'd do" mode, and it found
*everything* that we needed to "post-fix". Let's say he was REAL impressed ...
--
- Greg Earle WWW: http://www-mipl.jpl.nasa.gov/~earle/
Phone: (818) 353-8695 FAX: (818) 353-1877 [Call # again if
Internet: ea...@isolar.Tujunga.CA.US you get !FAX tone]
UUCP: isolar!ea...@elroy.JPL.NASA.GOV a.k.a. ..!{ames,usc}!elroy!isolar!earle
Mario Klebsch
d...@informatik.uni-rostock.de (Detlef Drewanz) writes:
lots of lines from a shellscript deleted ....
> # Get required Patches from a file
> REQ_PATCHID=`cat $DIR/req_patches`
> for patchid in $REQ_PATCHID
> do
> cd $DIR/$patchid
> echo "Install Patch $patchid"
> ./installpatch -d $DIR/$patchid
> cd ..
> done
Why do people always do solething like
cd ${xyy}
abc...
cd ..
in their scripts? What about using subshells? It is really easy!
for patchid in $REQ_PATCHID
do
(cd $DIR/$patchid
echo "Install Patch $patchid"
./installpatch -d $DIR/$patchid)
done
Mario
--
Mario Klebsch, DG1AM, m...@rob.cs.tu-bs.de +49 531 / 391 - 7457
Institut fuer Robotik und Prozessinformatik der TU Braunschweig
Hamburger Strasse 267, 38114 Braunschweig, Germany
Mario Klebsch
bros...@siisun.epfl.ch (Alain Brossard EPFL-SIC/SII) writes:
> Of course! Just do a chroot /a .../installpatch ...
But how is my ${SI_CONFIG_DIR} mounted into the chroot'td tree?
I would like to do a chroot in my post-install script, because then I
could test parst of my post istall script on a running system. But on
a running system I don't have a ${SI_CONFIG_DIR} at all. And I tried
to do the printer setup in a chrooted environment, and
failed. Probably because a deamon was not running. If there are any
good ideas out there I would like to know.
The reason, why I want to be able to run my post istall scripts on a
running system is, that I often have to do modifications on all
running systems and on every system that is added to our pool. It
would be a great help, if I can create a script for every change, and
this script can do the job on a running system, as well as on an
installing system.
Thanks,
Casper H.S. Dik
>But how is my ${SI_CONFIG_DIR} mounted into the chroot'td tree?
It is not mounted. We use an installpatch script that is
essentially the same as the one we use on running systems
and we do use a chroot. However, we first mount a tmpfs /tmp and
the source of the patches under /a. The source of the patches
is in /opt in our case and is already in /etc/vfstab at the
install patch point. You could use a loopback mount too and
mount the SI_CONFIG_DIR under /a with mount_lofs.
>I would like to do a chroot in my post-install script, because then I
>could test parst of my post istall script on a running system. But on
>a running system I don't have a ${SI_CONFIG_DIR} at all. And I tried
>to do the printer setup in a chrooted environment, and
>failed. Probably because a deamon was not running. If there are any
>good ideas out there I would like to know.
I think we do printer install at first boot. This script keeps
some state (a "configured" file) that can be removed to redo
the whole installation and next boot.
>The reason, why I want to be able to run my post istall scripts on a
>running system is, that I often have to do modifications on all
>running systems and on every system that is added to our pool. It
>would be a great help, if I can create a script for every change, and
>this script can do the job on a running system, as well as on an
>installing system.
In that case, you *definitely* want our auto-install stuff.
(ftp.fwi.uva.nl:/pub/solaris/auto-install). Apart from
a basic sets of scripts that does installation for your
and allows you to do table driven changes to your system
at starup through the start and finish script, there is
also a script called "install_check" that remounts the
SI_CONFIG_DIR (using the bootparams mechanism, so no extra
configuration is required) and check the install tree
for changes you made, and will apply these to the already
installed clients. It will re-install changed files,
fix symlinks, hardlinks, remake directories, install
new files, apply new patches, etc. And for those things
that aren't quite as simple, there's the escape hatch mechanism,
"update" shell scripts, which are run when they are younger than
the installed system or newer than the last update.
There was a simple rationale behind this script: if you
make auto-install work so well that no operator
post-install intervention is needed and you have all this
information stored on your server, why not write a
script that uses that information and check whether
the system still looks like a newly installed system or
whether changes are needed?
We have used this system now for quite some time and
are really happy with it. Every time there are changes,
new patches, etc., all systems are updated in the early monday
mornings, unattended. And the upside is that the install_check
script can also be run on servers (which would have a difficult
time net installing from themselves), though on servers
we do not automagically fix thing. We just check the servers
and the script mails the output.
install_check can also be made as careful as you like about user
processes on the system. E.g., our student workstations are rebooted,
when needed, every monday morning, users or not. (There are not supposed
to be long running processes there). But our research workstations
are rebooted only when there's no-one on the system, except on the
first monday of the month. Others again are rebooted only when
there are users on the system two weeks running.
(And when there's a real urgent fix, I can do:
rc -h @our-solaris -x @our-servers '/opt/install/install_check -f'
which applies all the changes to all systems in the our-solaris
netgroup, except the servers and reboots them. (Or doesn't reboot them,
or reboots only the ones w/o users, depending on the flags)
Casper
Frank Peters
>
>Why do people always do solething like
>
> cd ${xyy}
> abc...
> cd ..
>
>in their scripts? What about using subshells? It is really easy!
Because it requires forking yet another process...a relatively
expensive task. Each subshell forks and execs a shell process
which then (depending upon the shell) reads in various dot files
(.login, .profile, etc) and defines functions or aliases and so
on.
--
Frank Peters - UNIX Systems Group Leader - Mississippi State University
Internet: f...@CC.MsState.Edu - Phone: 601-325-7030 - FAX: 601-325-8921
WWW Home Page: http://www.msstate.edu/~fwp/