Hello listers, I uploaded zoom 2-06 to SourceForge at: https://sourceforge.net/projects/system-zoom/files
Here are the line items for this version: -) Updated zsetlifecycle to more completely apply system life cycle -) Function sendWarning() defined in userexits.stubs to send e-mail warning on expiring nodes -) New commands zsynctree and zsyncnodes freshen possible stale z/VM and Linux data -) Prefixed sudo before smcli calls when not running as root -) Changed default SMAPI wrapper from smaclient to smcli I wrote a short section in the first chapter "System Life Cycle". I have copied it here in case anyone is interested. ======================================================= Linux systems managed by zoom follow a life cycle. When a Linux system is built (clone to new virtual machines) or rebuilt (clone to existing virtual machines), the creation date is saved. An expiration date is set relative to the creation date. This can be set with user input, or if not specified the default is three months after the creation date. The zlsexpirations command lists expirations. The zsetlifecycle command applies this life cycle to managed system based on their creation and expiration dates. The zchexpiration command can add time to the expiration date. As times go by, systems get closer to their expiration dates. When the zsetlifecycle command runs, systems that are either 7, 3 or 1 days from their expiration date have an e-mail sent to the owner. When each system reaches its expiration date, it is 'destroyed'; that is, it is 'NOLOG'ed in user directory and changed to the artificial group 'deathrow'. System administrators can purge these systems manually which actually do the DIRM PURGE or VM:Secure equivalent. System synchronization is required when virtual machines or Linux attributes are modified 'out-of-band'. If the number of CPUs or amount of memory are modified using zoom (which calls SMAPI), those values are updated in the zoom tree. If however, these values are modified directly, with DirMaint for example, this is considered an 'out-of-band' change and the values in the zoom tree are now 'stale'. The zsynctree command will interrogate all systems and update the z/VM CPUs and memory values, and the Linux IP address, distribution and kernel levels. If it is run once a night, these important data about systems will never be more than one day out of date. These two commands work well with cron, so performing the daily maintenance described above is as easy as: # crontab -u zadmin -e # run zsetlifecycle against every system each night at 2 AM 0 2 * * * /usr/local/sbin/zsetlifecycle : # run zsynctree each night at 3 AM 0 3 * * * /usr/local/sbin/zsynctree ======================================================= I should point out that zoom does not have all the code needed to do provisioning. The commands that build (zbuildsystem - clone to new VM), rebuild (zrebuildsystem - clone to existing) and destroy (zdestroysystem - shut down Linux and NOLOG VM) call functions in the file userexits.stubs. At our shop we have the moving parts in the file userexits which send commands to an Ops Manager console, which then calls REXX EXECs doing the heavy lifting. I just didn't want to set anyone's expectations too high. -- -Mike MacIsaac ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/