Merry Christmas everyone (and if you don't celebrate it, then Happy
${HOLIDAYS} :)). Hopefully you'll find some nice "stocking stuffers" in
this package.I just updated zoom to version 1-19 on http://sourceforge.net/projects/system-zoom/files with a significant number of new features. The "line item" list in the README.txt is as follows: -) Enhanced zsetenvironment to do more to set up a newly installed zoom server -) Added code in zsetenvironment to append entries to the /etc/sudoers file -) Added steps in Ch 5 of the PDF "zoom on SLES" to set up zoom Web access with HTTPS -) Added concept of node-groups with three new commands z{ls|mk|rm}nodegroups -) Added code so that adding entries to known_hosts files is done automatically -) Added a RESTful API - zrestapi in cgi-bin/ directory -) Added a search pattern to zls{nodes|clients|servers|cecs|lpars|zvms} commands -) Added -f|--file flag so zaddclients can read clients to add from a file -) Allowed for long host names (FQDNs) with the global variable hostnameType -) Use the CP ACCOUNT value in the user directory to set the system's initial node-group -) Added command zcpwebscripts to copy newly Web scripts to virtual hosts directories -) Added -l|--long flag to many commands - verbosity flags are more for debugging -) Much streamlining of processing NODE-LISTs for all commands -) Reworked zlsemory and deleted zlsmem that was run on each node - Linux lsmem is fine -) Split Web UI zsystemstable into two to show Linux and z/VM systems separately -) Updated Web UI main menu to reflect separate Linux and z/VM tables -) Added a NODE-LIST filter to Web UI Linux table to display specific nodes Please let me expound. Coming to my new job this past August reinforced the need for both scalability and security in zoom. For scalability, consider numbers in the neighborhood of 35 LPARs, an average of 100 Linux systems per LPAR, and the need for perhaps 7 administrators. If to set up SSH 'passwordless' communication needing 2 keys copied, then 35 * 100 * 7 * 2 = 49000 keys to be copied. If to maintain an audit trail, Apache virtual hosts are needed on each z/VM LPAR, then 35 * 7 = 245 virtual hosts need to be defined. You probably don't want to either of these tasks manually (I know I don't :)). So this release of zoom strives to automate them (see zmkadministrator and the new zsetenvironment). zoom also focuses on security in the form of audit trails and secure Web communications. Let me mention three relatively new significant constructs to zoom: Apache virtual hosts, 'node-groups' and an experimental 'RESTful' API. 1) Apache virtual hosts can be created where, for each zoom administrator, the name of the virtual host is the administrator's Linux user name, and the port that is listened on is the user's UID. Then, any operation performed through Apache is logged both in the Apache logs and (hopefully) by zoom. There is documentation and an option for setting up secure https: as well as http: communication, but of course you'll need certificates for the former. Also, the default is to use LDAP for authentication. 2) Node-groups are simply a way of grouping Linux servers together. The z/VM user directory has an ACCOUNT value that was traditionally used for, well, accounting. If you don't need or use the ACCOUNT value, it can also be repurposed for grouping virtual machines and thus Linux systems. So when zoom servers and clients are added to the 'tree' (aka database), ACCOUNT values will automatically become the primary node-group. Many and perhaps most zoom commands accept a NODE-LIST. Before node-groups, it was either a single value, a comma-separated list, a range (e.g. linux1-linux22) or ':' (colon) which is the zoom wild-card for 'everything'. Now 'node-groups' can also be a valid specifier. So if you have 5 clusters of 20 Linux systems in your organization, you can create node-groups such as cluster1, ... cluster5. If you wanted to run a Linux command, to perhaps query the kernel level on each member of a cluster, you can use the command 'zruncommand cluster<N> uname -r'. 3) Having a RESTful API is just another way to leverage the power of the command line. zoom has always had a browser interface, which both leverages the command line and shows you the constructed command. Now there is an experimental RESTful API to expose a few operations in /srv/www/cgi-bin/zrestapi which allows you to use a, let's call it a URI as opposed to a URL. For example, if I wanted to shut down (power off) all the systems in cluster 1, and my Linux UID is 1234, then I could issue a RESTful 'call' such as http:, or even better: https://my.zoom.server:1234/cgi-bin/zrestapi?powerOffLinux+cluster1 Again this is just a prototype. You’ll probably want a two-stage operation of expanding node-groups into a list of systems, and verification. So you’ll need a mechanism of getting some sort of popup Window with words such as: “Are you sure you want to power off linux1,linux2,linux3,...,linux20?”. That will be coming ... That’s all for now. Again, a disclaimer: none of this code has been heavily tested, and much of the new code is very much ‘alpha’ (you have been warned :)). But it will improve. Stay tuned ... -Mike MacIsaac Note: I speak for myself, not my employer. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] 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/
