Configuring a System
(NOTE: Some of the techniques shown or described on this page--marked in purple--require new features in the latest official PIKT 1.19.0 release (pikt-current.tar.gz) that are unavailable in any previous version.)
PIKT isn't just for reporting and fixing problems. You can use it for centralized configuration management as well, to configure and manage important system configuration files such as: inetd.conf, syslog.conf, ntp.conf, fstab, inittab, ...; hosts, hosts.allow & hosts.deny; passwd, group & shadow (if you dare); ssh_config & sshd_config; mail config files like Sendmail's sendmail.cf or the Postfix main.cf; printers.conf and other CUPS files; httpd.conf and all the rest of the Apache web server include files; and many others besides.
Indeed, you can have PIKT manage any text configuration file, including: application license and configuration files; web pages (we use PIKT as a content management system (CMS) to administer over 1,000 web pages on several webservers at pikt.org); individual user profiles (.bashrc, .emacs); crontabs, and so on.
For example, in the piktmaster files.cfg, you might have the following directive:
#includeHere is the nsswitch_conf_files.cfg #include file:
///////////////////////////////////////////////////////////////////////////////
//
// nsswitch_conf_files.cfg
//
///////////////////////////////////////////////////////////////////////////////
nsswitch.conf path "/etc/nsswitch.conf" mode 644 uid 0 gid =rootgid
# this file is managed by PIKT // standard warning
#fix
# /etc/nsswitch.conf:
# $Header: /var/cvsroot/gentoo-x86/sys-libs/glibc/files/nsswitch.conf,v 1.1
2005/05/17 00:52:41 vapier Exp $
passwd: compat
shadow: compat
group: compat
# passwd: db files nis
# shadow: db files nis
# group: db files nis
hosts: files dns
networks: files dns
services: db files
protocols: db files
rpc: db files
ethers: db files
netmasks: files
netgroup: files
bootparams: files
automount: files
aliases: files
#unfix
///////////////////////////////////////////////////////////////////////////////
The #fix directive says to fix or freeze anything up to and including the #unfix--that is, retain comments, stop macro expansion, and in general suppress any special text preprocessing
Here is a piktc command to install nsswitch.conf on Linux systems:
# piktc -iv +F nsswitch.conf +H linux processing zurich... installing file(s)... nsswitch.conf installed processing budapest... installing file(s)... nsswitch.conf installed processing kiev... installing file(s)... nsswitch.conf installed ...Just to be clear: Post-installation, all Linux systems would have an /etc/nsswitch.conf file with contents
# this file is managed by PIKT # /etc/nsswitch.conf: # $Header: /var/cvsroot/gentoo-x86/sys-libs/glibc/files/nsswitch.conf,v 1.1 2005/05/17 00:52:41 vapier Exp $ passwd: compat shadow: compat group: compat # passwd: db files nis # shadow: db files nis # group: db files nis hosts: files dns networks: files dns services: db files protocols: db files rpc: db files ethers: db files netmasks: files netgroup: files bootparams: files automount: files aliases: filesAfter doing some reconfiguration--for example, changing the passwd line to
passwd: nis files
if you now want to diff your changes against the existing configuration, you might use the command
# piktc -fv +F nsswitch.conf +H zurich processing zurich... fetching file(s)... nsswitch.conf fetched diffing file(s)... diff -r /pikt/lib/configs/staging/etc/nsswitch.conf /pikt/lib/configs/diffing/etc/nsswitch.conf 4c4 < passwd: nis files --- > passwd: compatSeeing the expected diffs, and confident that your changes are correct, you might then reinstall (and back up) nsswitch.conf on the Linux systems with:
# piktc -ivb +F nsswitch.conf +H linuxOf course, reinstalling all PIKT-managed files on all systems with
# piktc -iv +F all +H allwould also install all instances of nsswitch.conf in the appropriate place (in /etc) on every system.
If you are wondering, PIKT file installs are extremely fast. Recently, with a single 'piktc -iv +F metalog.conf +H all' command, we updated the metalog.conf file on 84 different PIKT slave system in less than two minutes! (MetaLog is a Syslog replacement.) Installing multiple files is equally speedy. We routinely install and/or diff dozens of Pikt scripts across all systems at a rate above 20 systems per minute.
To give another example, here is how you might configure /etc/motd to solve the problem of easily maintaining and installing customized message-of-the-day files across many systems.
///////////////////////////////////////////////////////////////////////////////
motd path "/etc/motd" mode 644 uid 0 gid 0
// add a funny bit
#indent
#include [/usr/bin/fortune]
#unindent
// machine-specific messages follow
#if finance | tech | madrid
Matlab R2007a is installed and available for use. To run this latest
version, use the command: "/opt/local/bin/matlab"
Please send all operational questions to dmitri.shostakovich
Send UNIX-related technical questions to systems Enjoy!
#endif // finance | tech | madrid
#if tech
Some fans on paris6 have failed in recent days, causing the system to
overheat and more than once shut down. In order to cool the system
and disk electronics, we have moved paris6 into the Machine Room.
#endif // tech
// a standard blurb
To read this message in full, use the command: more /etc/motd
To suppress display of this message, use the command: touch ~/.hushlogin
///////////////////////////////////////////////////////////////////////////////
Note how we #include process output from the Unix fortune command to add a dash of humor. (The Unix fortune command outputs a random, hopefully interesting, and usually humorous adage or "fortune cookie.") Since PIKT stanza content must be indented, and since the output of the fortune command is not indented, we have to wrap #indent ... #unindent directives around the #include.
Note, too, how the #if ... #endif directives will insert special messages for the appropriate systems.
On the piktmaster system, you would install the /etc/motd file customized for the tech systems with the command:
# piktc -iv +F motd +H techAfter installation, the motd file (with the indicated ownerships and permissions) on a tech system would look something like:
Computers are useless. They can only give you answers.
-- Pablo Picasso
Matlab R2007a is installed and available for use. To run this latest
version, use the command: "/opt/local/bin/matlab"
Please send all operational questions to dmitri.shostakovich
Send UNIX-related technical questions to systems Enjoy!
Some fans on paris6 have failed in recent days, causing the system to
overheat and more than once shut down. In order to cool the system
and disk electronics, we have moved paris6 into the Machine Room.
To read this message in full, use the command: more /etc/motd
To suppress display of this message, use the command: touch ~/.hushlogin
You could, as another example, use PIKT to manage inetd.conf. After (re)configuring an inetd_conf_files.cfg file then installing or refreshing an updated inetd.conf with the piktc command
# piktc -iv +F inetd.conf +H allyou might then restart the inetd everywhere with the command
# piktc -Xv +C "/etc/init.d/inet restart" +H allYou can also combine the inetd.conf install and inetd restart in a single command, as in
# piktc -ixv +F inetd.conf +C "/etc/init.d/inet restart" +H allYou can use PIKT to manage just about all of your system configuration files (and other text data files). Just after a new operating system installation, and after setting up PIKT on the new system, you could install the PIKT-managed configuration files with
# piktc -ivb +F all +Hwhere the '-ivb' says to do a verbose install, with backup of the original file versions.
If you every need to restore a file to its previous version, you could, for example, do
# piktc -Bv +F ntp.conf +H
Over time, you would continue to employ PIKT to manage your system configuration files. You could routinely diff them against the piktmaster's central configuration, and/or do a checksum comparison, for example:
# piktc -m5v +F all +H all ... processing cologne... checksumming file(s)... sshd_config checksums differ sshd_config checksummed ...
where '-m5' says to compare MD5 checksums. (You can also run MD4 and various other system checksums, if you wish.)
Regular reinstalls would (re)set the ownerships and permissions properly, or perhaps you might have some other PIKT monitoring script routinely ensuring correct file attributes.
Not only will the '-f' and '-m#' piktc options allow you to doublecheck your config file edits before committing to a file install, they are also a handy security feature: If a hacker (or an errant sysadmin!) has done an unauthorized edit of any slave inetd.conf file, the 'piktc -f' and/or 'piktc -m#' commands will tell you that.
Besides the convenience of administering system config files from a central configuration, and in addition to its security aspects, there is also the benefit of having a central backup (as it were) in case you accidentally delete or mangle inetd.conf, say, on any of the PIKT slave systems.
If you do a daily backup to disk of the PIKT configuration on your piktmaster, imagine being able to recall any system's inetd.conf or any other system configuration file going as far back as you want from one central location (the piktmaster system), without having to micro-manage CVS setups across all systems or resort to tape backups!
Some other piktc file-management options:
What if you want to view an existing license file on your database server(s)? You could use the '-w' (view) option, as in:
# piktc -w +F =license +H dbserverYou can also vieW the centrally configured version(s) of the dbserver license file(s) using the '-W' option, as in:
# piktc -W +F =license +H dbserverThe '-l' option lists one or more files on slave systems
# piktc -lv +F ldap.conf +H alland the '-t' option deletes them
# piktc -tv +F ldap.conf +H allWith so many different piktc file management options, and when combined with the power of PIKT preprocessing, macros, #include files, process includes, and other PIKT features, you can cook up some clever and sophisticated file management solutions. Here's one:
In a sudoers configuration file, you could have
User_Alias PARTTIMERS=\
#verbatim [/pikt/lib/programs/SudoParttimers.pl]
The current contents of the sudo_parttimers_files.cfg file might be
larry,moe,curly,
sporty,ginger,baby,posh,scary,
john,paul,george,ringo
In the client-side target /etc/sudoers file, then, the final result would be
User_Alias PARTTIMERS=\
larry,moe,curly,
sporty,ginger,baby,posh,scary,
john,paul,george,ringo
which is in a form acceptable to the sudo program.
Why on earth would you want to go to the trouble of isolating the PARTTIMERS list in its own separate include file? The reason is that you can have a script (not shown) update this list for you automatically. The script could be written in Perl, Python, or some other scripting language, including the Pikt script language (see Standalone Scripts).
The #verbatim directive says to include file content, or process output, "as is". If you are preprocessing this with a 'piktc -I ...' command, you incorporate output from the SudoParttimers.pl script directly into the sudoers file, and also update the on-disk sudo_parttimers_files.cfg file. If you omit the -I option from the piktc command, you simply reference the on-disk file. You might think of the on-disk file as a sort of data cache for the SudoParttimers.pl program (which might take a while to run, so you wouldn't want to run it absolutely every time, as this would slow you down).
Again, why go to all this trouble, and introduce all this complexity? The reason is that the PARTTIMERS change constantly, hence a static, maintained by-hand sudoers file is constantly at risk of being out-of-date. Using the auto-configuring files technique, PIKT can update your configurations for you automatically.
Using PIKT for configuration management has tremendous advantages: speed, convenience, backups, security, customization, error-checking, quality assurance, automation, etc. You might be surprised by how much time and effort this one PIKT facility alone might save you!
 prev page
|
1st page |
next page 
|
