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/piktd
    Or, 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.

 
Home | FAQ | News | Intro | Samples | Tutorial | Reference | Software
Developer's Notes | Licensing | Authors | Pikt-Users | Pikt-Workers | Related Projects | Site Index | Privacy Policy | Contact Us
Page best viewed at 1024x768 or greater.   Page last updated 2019-01-12.   This site is PIKT® powered.
Copyright © 1998-2019 Robert Osterlund. All rights reserved.
Home FAQ News Intro Samples Tutorial Reference Software
PIKT Logo
PIKT Page Title
Learn about the
pikt
program