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/
