PIKT Installation and Setup
[posted 2001/06/07]
Date: Fri, 01 Jun 2001 02:39:41 -0400
From: Harlan Stenn <[email protected]>
How do you get new versions of pikt installed and running on all of your platforms/boxes? Is it any different when you get a new box?
Feel free to post this message and your response to the list if you think it will be generally useful.
Harlan:
This will be my typical rather long-winded response. :-)
People have such different environments, that it's hard for me/us to advise in general how to go about this.
Nonetheless, here is how I would do the PIKT installation and setup of a new machine at our site.
- Make the necessary piktc_svc entry in /etc/rpc.
- Determine where the PIKT home dir will be. Usually, we prefer to locate it
in a data directory (e.g., /pub/mba_disk_17/pikt), but sometimes we locate it
directly in / (e.g., /pikt). If we locate it outside of /, we always link
it to /pikt (e.g., /pikt -> /pub/mba_disk_17/pikt).
For the rest of this discussion, we'll do everything in /pikt (actual dir, not a link).
- Do the following:
# cd / # tar xvf /usr/local/pikt/tmp/pikt.tar pikt/ pikt/bin/ pikt/bin/bak/ pikt/lib/ pikt/lib/alerts/ pikt/lib/objects/ pikt/lib/programs/ pikt/lib/configs/ pikt/lib/configs/systems/ pikt/lib/configs/macros/ pikt/lib/configs/defines/ pikt/etc/ pikt/etc/PIKT.conf pikt/var/ pikt/var/histories/ pikt/var/histories/crontabs/ pikt/var/log/
This creates the necessary directory structures (with several extras, like the histories/crontabs directory, thrown in).
The pikt.tar has all the recommended/necessary ownerships and permissions. All dirs are empty, save /pikt/etc, which has our standard PIKT.conf:
drwxr-x--- 6 root daemon 213 Jun 1 09:54 . drwxr-x--- 3 root daemon 105 Jun 1 08:45 ./bin drwxr-xr-x 2 root daemon 69 Jun 1 08:45 ./bin/bak drwxr-x--- 6 root daemon 229 Mar 8 11:30 ./lib drwxr-x--- 2 root daemon 69 Jun 1 08:46 ./lib/alerts drwxr-x--- 2 root daemon 69 Jun 1 08:47 ./lib/objects drwxr-x--- 2 root daemon 69 Jun 1 08:47 ./lib/programs drwxr-x--- 5 root daemon 188 Jun 1 08:47 ./lib/configs drwxr-x--- 2 root daemon 69 Jun 1 08:47 ./lib/configs/systems drwxr-x--- 2 root daemon 69 Jun 1 08:47 ./lib/configs/macros drwxr-x--- 2 root daemon 69 Jun 1 08:46 ./lib/configs/defines drwxr-x--- 2 root daemon 111 Jun 1 08:46 ./etc -rw-r----- 1 root daemon 781 May 21 09:54 ./etc/PIKT.conf drwxr-x--- 4 root daemon 147 May 10 1998 ./var drwxr-x--- 3 root daemon 110 Jun 1 08:50 ./var/histories drwxr-x--- 2 root daemon 69 Jun 1 08:50 ./var/histories/crontabs drwxr-x--- 2 root daemon 69 Jun 1 08:50 ./var/log
- Copy in place the PIKT binaries. For Solaris, we always maintain current
binaries in the globally (across our entire site) NFS-shared
/usr/local/pikt/bin/solaris.
# cp -p /usr/local/pikt/bin/solaris/pikt* /pikt/bin
We do something similar for SunOS.
As for our Linux boxes, we use several different distros, and in any case, we have no (as of now) NFS global share. So, we just do a separate binary build on each system, then cp the built binaries into /pikt/bin.
- Start the piktc_svc:
# /pikt/bin/piktc_svc # ps -ef | grep pikt | grep -v grep root 24063 1 1 09:58:05 ? 0:00 /pikt/bin/piktc_svc - On the piktmaster, register the new system in the appropriate places in systems.cfg. Make any other customizations to the other .cfg files as necessary. (The eventual aim is--with the proper hostgroups, #if, and #ifdef entries--to make all per-machine customizations dependent on editing the systems.cfg alone.)
- On the pikstmaster, install and enable everything on the new system:
vienna# piktc -iev +A all +O all +P all +F all +H paris5 processing paris5... installing file(s)... Debug.alt installed ...
- If everything appears to install correctly, start up the piktd on the new
system:
vienna# piktc -rv +H paris5 processing paris5... (re)starting daemon (piktd)... daemon (re)started
- On the new system, verify piktd startup:
# ps -ef | grep pikt | grep -v grep root 24063 1 9 09:58:05 ? 0:05 /pikt/bin/piktc_svc root 24080 1 0 09:59:09 ? 0:00 /pikt/bin/piktdOr, on the piktmaster, you could verify with this:# vienna# piktc -sv +A all +H paris5 processing paris5... showing alert stata... EMERGENCY active ...
- Copy in place a standard PIKT startup script (appropriate for Solaris, would
be different for other OSes):
# scp /etc/rc3.d/S90pikt paris5:/etc/rc3.d/S90pikt
That's it!
Believe it or not, I can usually set up a new system in the above manner in 15-20 minutes.
We could automate this more, but crafting scripts to do PIKT setups on new machines has not yet been worth the bother.
What *is* a bother is upgrading our binaries to the latest PIKT version, which we have to do frequently, as I want to production test each new PIKT beta (dev) release.
For that, I have put together the following (unfinished) script. (I'll add comments in [] brackets. They are not part of the actual script.)
#!/bin/sh
vienna is where I do the general Solaris builds. I copy the vienna-built PIKT Solaris binaries to /usr/local/pikt/bin/solaris.
munich is where I do the general SunOS builds. I copy the munich-built PIKT SunOS binaries to /usr/local/pikt/bin/sunos.
On the murmansk and firenze Linux systems (we have other new Linux systems awaiting installation), I do separate builds. These are copied locally and not maintained in any global NFS share.
So, before running this script, we have: PIKT already up and running on vienna, munich, murmansk, and firenze; the appropriate binaries copied to /usr/local/pikt/bin/{solaris,sunos}
With the preliminaries out of the way, I run this script with
/usr/local/pikt/bin/upgrade.sh
The actual script body starts here:]
echo "killing piktd..." /pikt/bin/piktc -kv -H vienna munich murmansk firenze downsys
[Kill the piktd everywhere except on the "Gang of Four" and any down systems]
echo "" echo "killing piktc_svc..." /pikt/bin/piktc -Kv -H vienna munich murmansk firenze downsys
[Kill the piktc_svc everywhere except ...]
echo "" echo "cp'ing berlin binaries..." ssh berlin -n "mkdir -p /tmp/pikt/bin/solaris 2>/dev/null; cp /usr/local/pikt/bin/solaris/pikt* /tmp/pikt/bin/solaris" ssh berlin -n "mkdir -p /tmp/pikt/bin/sunos 2>/dev/null; cp /usr/local/pikt/bin/sunos/pikt* /tmp/pikt/bin/sunos"
[We have some systems that, for whatever reason, can't access /usr/local. So, we copy the PIKT binaries over to some /tmp directories on the berlin system (the NFS server serving /usr/local everywhere else).]
echo "" echo "rm'ing core & .lock files, making backups..." for sys in `/pikt/bin/piktc -L +H solaris sunos -H vienna munich downsys`; do echo $sys; rsh $sys -n "rm /core 2>/dev/null; rm /pikt/etc/*.lock 2>/dev/null; cp /pikt/bin/pikt* /pikt/bin/bak"; done
[Sometimes, killing a running piktd or piktc_svc will leave a core file. If so, clear it out. Clear out any orphaned .lock files. Backup the current binaries to the /pikt/bin/bak dir.]
echo "" echo "cp'ing new binaries, restarting piktc_svc..." for sys in `/pikt/bin/piktc -L +H solaris -H vienna no_usr_local downsys`; do echo $sys; rsh $sys -n "cp /usr/local/pikt/bin/solaris/pikt* /pikt/bin; /pikt/lib/programs/svcstart.pl -r"; done
[Copy in place the new binaries, but not on systems with no global /usr/local. Start the piktc_svc.]
for sys in `/pikt/bin/piktc -L +H no_usr_local -H nonsolaris downsys`; do echo $sys; rsh $sys -n "umount /mnt 2>/dev/null; mount berlin:/tmp /mnt; cp /mnt/pikt/bin/solaris/pikt* /pikt/bin; umount /mnt 2>/dev/null; /pikt/lib/programs/svcstart.pl -r"; done
[For systems with no global /usr/local, and excluding non Solaris systems and down systems, do a temporary mount of berlin's /tmp to /mnt, copy over the binaries, umount /mnt, and restart piktc_svc.]
echo "" echo "cp'ing new binaries..." for sys in `/pikt/bin/piktc -L +H sunos -H munich no_usr_local downsys`; do echo $sys; rsh $sys -n "cp /usr/local/pikt/bin/sunos/pikt* /pikt/bin"; done
[For SunOS systems with the global /usr/local, copy in place the new binaries, but don't start piktc_svc. If we do that here, this will hang.]
for sys in `/pikt/bin/piktc -L +H no_usr_local -H nonsunos downsys`; do echo $sys; rsh $sys -n "/etc/umount /mnt; /etc/mount berlin:/tmp /mnt; cp /mnt/pikt/bin/sunos/pikt* /pikt/bin; /etc/umount /mnt"; done
[Copy in place the binaries to SunOS systems with no global /usr/local, but don't start piktc_svc.]
echo ""
[At this point, all binaries should be refreshed everywhere.]
echo "restarting piktd..." /pikt/bin/piktc -rv +H solaris -H vienna downsys
[Start piktd on all Solaris systems except the piktmaster and down systems.]
echo "" echo "updating cksum files..."
[We routinely checksum the PIKT binaries to report possible tampering or out-of-date versions. We need to refresh the checksum .cfg #include files here:]
rm /pikt/lib/configs/objects/cksumfiles_piktbin_piktmaster_objects.cfg /pikt/lib/programs/CksumFilesPiktBin.pkt > /pikt/lib/configs/objects/cksumfiles_piktbin_piktmaster_objects.cfg rm /pikt/lib/configs/objects/cksumfiles_piktbin_solaris_objects.cfg /pikt/lib/programs/CksumFilesPiktBin.pkt > /pikt/lib/configs/objects/cksumfiles_piktbin_solaris_objects.cfg rm /pikt/lib/configs/objects/cksumfiles_piktbin_murmansk_objects.cfg /pikt/bin/piktc -x +C "=prgdir/CksumFilesPiktBin.pkt" +H murmansk > /pikt/lib/configs/objects/cksumfiles_piktbin_murmansk_objects.cfg rm /pikt/lib/configs/objects/cksumfiles_piktbin_firenze_objects.cfg /pikt/bin/piktc -x +C "=prgdir/CksumFilesPiktBin.pkt" +H firenze > /pikt/lib/configs/objects/cksumfiles_piktbin_firenze_objects.cfg echo "" echo "now log into the sunos systems and manually restart piktc_svc & piktd"
[To startup piktc_svc and piktd on all SunOS systems, on the piktmaster I do
# for sys in `piktc -L +H sunos -H berlin`; do slogin $sys; done
On each of the entered SunOS systems, I just manually restart:
# /pikt/bin/piktc_svc & # /pikt/bin/piktd
Note: We really need to figure out a way to do successful piktc_svc restarts on SunOS (and Linux? and ?) systems via ssh. The problem doesn't affect piktd, only piktc_svc. svcstart.pl won't help us here. It, too, will hang when ssh'ed to SunOS systems.
Of course, once piktc_svc is up and running on SunOS (and Linux? and ?) slaves, we can do 'piktc -r', 'piktc -R', 'piktc -x +C "=prgdir/svcstart.pl -r"' without problem.]
echo "" echo "then run: rm /pikt/lib/configs/objects/cksumfiles_piktbin_sunos_objects.cfg; /pikt/bin/piktc -x +C \"=prgdir/CksumFilesPiktBin.pkt\" +H munich > /pikt/lib/configs/objects/cksumfiles_piktbin_sunos_objects.cfg"
[Alas, we have to manually run the sunos checksum .cfg file refresh. I don't recall exactly why.]
echo "" echo "then run: /pikt/bin/piktc -iv +O all -H downsys"
[We then push the updated cksumfiles_piktbin_*_objects.cfg files (and others) to all systems, else the checksum alarm script will start squawking about checksum differences.]
Once the preliminaries are out of the way (binaries built and in place on the Gang of Four, and all Solaris and SunOS binaries installed to /usr/local/pikt/bin/{solaris,sunos}), upgrade.sh will run and upgrade more than 50 of our systems in under 10 minutes!
Some observations:
- This script is still a work-in-progress. It's what we use, it's "good enough" so far, and it's not intended for external use. Still:
- In general, upgrading the PIKT binaries basically entails on all systems:
- kill piktd
- kill piktc_svc
- rm any core and orphaned .lock files
- optionally, backup the current binaries
- copy in place the new binaries
- restart piktc_svc
- restart piktd
- optionally, refresh any checksum *objects.cfg files
- The script is idiosyncratic, because our site is idiosyncratic. What site doesn't have its oddities and quirks? That's one of the reasons why I favor the PIKT approach/philosophy, which is to acknowledge the many, many oddities and quirks and deal with them in a coherent, systematic fashion.
- It seems complicated--nay, it *is* complicated!--but I am so practiced at it that I can whip through all of this sort of thing in a very short while indeed. Your mileage may vary, of course. ;-)
Sorry for being so long-winded, but that's how we do the PIKT installation
and setup currently.
For more examples, see Developer's Notes.
