|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
Unix Configuration Management Tools
I think that the real "higher ground"
is security will be won (if it ever is)
in two strongly-related areas: software quality (process)
and (automated) configuration management.
Tom Perrine
San Diego Supercomputer Center
Unix configuration management is far from being a new topic. But it is a very difficult
one and few of many many proposed systems successes in lessening the load on sysadmin.
For example, I do not believe that cfengine
is a right solution to the problem.
Wikipedia defines configuration
management in
the following way
In
information technology and
telecommunications, the term configuration management or configuration
control has the following meanings:
- The management of
security
features and assurances through control of changes made to
hardware,
software,
firmware,
documentation,
test, test fixtures and test documentation of an
automated information system, throughout the development and operational
life of a system. Source Code Management or
revision control is part of this.
- The control of changes--including the recording
thereof--that are made to the hardware, software, firmware, and documentation
throughout the
system lifecycle.
- The control and adaption of the evolution
of complex systems. It is the discipline of keeping evolving software products
under control, and thus contributes to satisfying quality and delay constraints.
Software configuration management (or SCM) can be divided into two areas.
The first (and older) area of SCM concerns the storage of the entities produced
during the software development project, sometimes referred to as
component repository management. The second area concerns the activities
performed for the production and/or change of these entities; the term
engineering support is often used to refer this second area.
- After establishing a
configuration, such as that of a telecommunications or
computer system, the evaluating and approving
changes to the configuration and to the interrelationships among system
components.
- In
distributed-queue dual-bus (DQDB) networks, the function that ensures
the resources of all nodes of a DQDB
network
are configured into a correct dual-bus topology. The functions that are
managed include the head of bus, external timing source, and
default
slot generator
functions.
Software for automation of Unix and application configuration management reduces
the cost and increases the productivity of system administrators. According
to Forrester Research, 44% of downtime is due to configuration errors.
Much of this downtime is avoidable.
Unmanaged configuration changes impact an organization’s ability to prevent outages,
understand the impact of planned changes, and especially in today’s regulatory environment,
adhere to corporate and government policies. Knowing who changed what and when is
vital to complying with today’s security requirements.
Tom Perrine of the San Diego Supercomputer Center recently offered this guidance
to an Internet newsgroup aimed at university security administrators. It offers
sage advice for anyone managing and securing networks of heterogeneous UNIX systems.
I actually do not share his excitement over cfengine -- IMHO badly architectured
agent-based system. Also in a way this is a attempt to reinvent TCL and as many
such attempts it is badly done.
Let me take a small step back and philosophize
from a wider perspective.
The local Cray folks have a saying: "Wanna-bees
worry about GigaFLOPS, and nanoseconds; real computer companies worry about
*cooling*..."
I think that the real "higher ground" is security
will be won (if it ever is) in two strongly-related areas: software quality
(process) and (automated) configuration management.
Let's face it, the quality of most commercial
software is pretty pitiful at worst, and sub-standard at best. As an industry,
we have pretty much ignored 40 years of software process research and lessons
learned. The first paper on what we now call "buffer overflows" was published
in 1965. This paper and those related to it was influential in the design
of Multics, portions of the original UNIX system-call interface, and security
kernels. They called this problem "insufficient argument validation" in those
papers), and it also influenced language design and the move towards higher-level
languages.
We have ignored all the "formal methods", strong
specification, structured design and adequate testing strategies. We have forgotten
(or never learned) all the lessons of Mythical Man-Month, Peopleware, The Psychology
of Computer Programming, Software Tools, and many other books, methodologies
and studies. As in the security arena, we have most of the technology and lessons
figured out, we just don't apply them :-(
Configuration management is related (a
part of any proper development process), but we often fail to use it in non-software-development
areas, even if we do use it for software. There is no reason for a person
to *ever* ask "What version of *anything*, is this?" and not get a good answer.
There is *no* reason for computers to have "version drift" where patches or
software are inconsistent. Again, we have the technology, whether it is cfengine,
SMS, or vendor-supplied or home-grown scripts, it is just not being applied.
So why are these basic technologies not being
applied? The answer is short-term thinking, similar to that that drives the
quarterly earnings drives of most US companies.
Let's face it, it initially takes longer to establish
a proper software development (or any other) process. You have a steeper, longer
initial spending/development curve, and pay more of the costs "up front", and
dramatically lower costs in the maintenance and update phase. (You also have
fewer bugs to fix, pushing the support costs even lower, but I digress.)
... ... ...
So I guess I believe that "wanna-bees"
worry about exploits and patches; real security people are more concerned with
process and management..."
For more of my heretical views, see "Security
as Infrastructure: Are you shooting rabbits, or building fences", a USENIX LISA
Invited Talk.
http://www.sdsc.edu/~tep/Presentations/1998.LISA.Security.Infrastructure/index.htm
Sorry for the rant, but this has been a hot-button
for several years, as you may have noticed.
Tom Perrine
San Diego Supercomputer Center
Notes:
- Those pages are written by people for whom English is not a
native language. Some amount of grammar and spelling errors
should be expected.
- This is a Spartan WHYFF (We Help You For Free) site. It
cannot replace the best teachers and
the
best books.
- The site contain some obsolete pages as it develops like a
living tree... Some links on older pages
are broken. Please
try to use Google, Open directory, etc. to find a replacement link
(see
HOWTO search the WEB for details).
We would appreciate if you can
mail us a correct link.
|
|
Ruby script
Silk Tree propagate /etc/passwd and
/etc/group files from a master to a list
of hosts via SSH. Neither the sending nor the receiving end connect to each
other as root. Instead there is a read-only sudo sub-component on the
receiver's side that makes the final modifications in /etc. Many checks are
made to ensure reliable authorization updates. ACLs are used to enforce a
simple security policy. Differences between old and new versions are shown.
Two small scripts are included for exporting LDAP users and groups.
About: The "Schily" Tool Box is a set of tools written or
managed by Jörg Schilling. It includes programs like: cdrecord,
cdda2wav, readcd, mkisofs, smake, bsh, btcflash, calc, calltree,
change, compare, count, devdump, hdump, isodebug, isodump, isoinfo,
isovfy, label, mt, p, sccs, scgcheck, scpio, sdd, sfind, sformat,
smake, sh, star, star_sym, suntar, gnutar, tartest, termcap, and ved.
Changes: The source for "copy" (an accurate sparse file
enabled copy program) has beeen added. The source for the "mountcd"
program from SchilliX has been added. The source for "udiff", a diff
program with human readable output has been added. Star has been
bumped to 1.5-final. bsh and sh now skip BASH time stamps from the
.history file. smake adds MAKE_SHELL_FLAG/MAKE_SHELL_IFLAG macros.
Apr 18, 2008 |
freshmeat.netMrTools is a suite of tools for managing large, distributed environments. It
can be used to execute scripts on multiple remote hosts without prior installation,
copy of a file or directory to multiple hosts as efficiently as possible in
a relatively secure way, and collect a copy of a file or directory from multiple
hosts.
Release focus: Initial freshmeat announcement
Changes:
Hash tree cleanup in thread tracking code was improved in all tools in the suite.
Mrtools Has now adopted version 3 of the GPL. A shell quoting issue in mrexec.pl
was fixed. This fixed several known limitations, including the ability to use
mrexec.pl with Perl scripts and awk if statements. This fix alone has redefined
mrexec.pl's capabilities, making an already powerful tool even more powerful.
Written in Perl
Feb 8, 2008 |
freshmeat.net
Scmbug integrates software configuration management (SCM) with bug-tracking.
It aims to solve the integration problem once and for all. It will glue any
source code version control system (such as CVS/CVSNT, Subversion, and Git)
with any bug tracking system (such as Bugzilla, Mantis, Request Tracker, Test
Director).
Feb 7th 2008 | freshmeat.net
About: System Configuration Collector (SCC) is yet another configuration
collector. It consists of a client and a server part. The client collects configuration
data in a structured snapshot, compares the new snapshot with the previous one,
and adds differences to a logbook. Then the snapshot and the logbook are converted
to HTML for local inspection. Optionally, the data can be sent to a system running
the server software. On the server, summaries of the data are generated, and
search/compare operations on the snapshots and logbooks are available via a
Web interface.
Changes: Some changes to support ServerOrientedLinux have been implemented.
The determination of an active name has been corrected. This release avoids
messages when the LVM directory is absent on a cluster node. Config files in
/etc/rc.d have been added.
The package also contain Solaris binary of
chpasswd clone, which
is extremely useful for mass changes of passwords in corporate environments which
include Solaris and other Unixes that does not have chpasswd utility (HP-UX is another
example in this category). Version 1.3.2 now includes Solaris binary
of chpasswd which works
on Solaris 9 and 10.
freshmeat.net
cgipaf is a combination of three CGI programs.
- passwd.cgi, which allow users to
update their password,
- viewmailcfg.cgi, which allows users
to view their current mail configuration,
- mailcfg.cgi, which updates the mail
configuration.
All programs use PAM for user authentication. It is possible to run a script
to update SAMBA passwords or NIS configuration when a password is changed. mailcfg.cgi
creates a .procmailrc in the user's home directory. A user with too many invalid
logins can be locked. The minimum and maximum UID can be set in the configuration
file, so you can specify a range of UIDs that are allowed to use cgipaf.
Written in shell. Looks very similar to Titan as simple configuration
management tool with the security/hardening bent.
ProShield is a system administration program for Ubuntu/Debian Linux. It helps
ensure your system is secure and up-to-date by checking many different aspects
of your system. Regular use is recommended.
Whether you are a Linux novice or a system administrator with a dozen servers,
ProShield is designed to be useable by all. ProShield's main goal is to help
secure a newly installed box (computer), as well as maintain the security of
an existing box on a maintenance basis. It's part security, part security administration.
The main features of ProShield are:
- Helps you backup your system weekly.
- Checks for new software releases, in order to see if installed software
is reasonably up to date. Smart-suggestion to upgrade if an important
package is released.
- Disk-space check to find any partitions that are 70% full or more.
- Checks for extra root accounts.
- Checks account & password files for correct access control permissions.
- Makes sure a few security-hazardous packages are not installed.
- Checks to make sure a packet sniffer is not running.
- Removes unneeded packages from the local package archive.
- Checks to see if 'apt' is fetching unnecessary information when checking
for software updates.
- Makes sure system time is accurate.
- Checks to make sure the user isn't logged into the system (GUI) as root.
- Checks the configuration of the ssh server ([sshd] if installed) for
insecure settings.
- At runtime, ProShield will also check to see if there has been a new
version released, and can download and install it at the user's preference.
When the program is done analyzing your system, it displays an "advisory report",
and then (if necessary), guides you through a series of interactive questions
to help you solve any problems it found.
ns4 is a configuration management tool which allows the automated
backup of node configurations. Commands are defined within a configuration file,
and when they are executed, the output is sent to a series of FTP servers for
archiving. As well as archiving configurations, it allows scripts to be run
on nodes; this allows configurations to be applied en masse and allows conditional
logic so different bits of scripts are run on different nodes.
[Oct 1, 2007] Several useful articles
I’m assuming that you have Subversion
installed; in other words, you should have the
svn and
svnadmin
commands and they should work properly. I’m also assuming that
you’ll be performing the following tasks as
root.
The ideal situation to begin applying
this tutorial is right after your server has been freshly installed.
However, for practical purposes, any server that’s configured
and running will do.
Okay. That’s enough of the lists and introductions.
Time for some action.
Creating the Subversion repository
If you’re familiar with UNIX, you’ll know
/var
is the customary directory for files that pertain to the whole
system and are changed. So, following tradition, we’ll create
a /var/preserve/config
repository. Type the following command at your console:
[rudd-o@amauta2 ~]# svnadmin create \
/var/preserve/config
(note the backslashes are being used to
add whitespace)
That should create a
/var/preserve/config
directory, with a couple of files in it. Those files are not
meant to be editing, and they’ll be opaque to us for the rest
of the tutorial. As usual, I’d advise you to secure that directory
so only root
can read and write files to it.
Now, you’ll create two directories directly
into the repository. You’ll use these directories to travel
back and forth between known configuration states.
trunk/
will contain the current configuration tags/
will contain snapshots (we’ll learn more about them later)
To perform this task, just type:
[rudd-o@amauta2 ~]# svn create \ file:///var/preserve/config/trunk/
\ file:///var/preserve/config/tags/ \ -m 'Creating trunk
and tags directories'
The -m
argument specifies a message to attach to the operation. You
can consult these messages afterwards through the
svn log
command.
Preparing the configuration
directory
In true UNIX tradition,
/etc is
the place to go for system-wide configuration. For the rest
of the tutorial, I’ll assume those are the files you want to
keep in check.
To track files in
/etc, you
need to both:
- place its contents into the Subversion
repository
- make it into a working copy
That’s easily accomplished via the following
command:
[rudd-o@amauta2 ~]# svn checkout \ file:///var/preserve/config/trunk/
/etc
Once you’ve done that,
/etc will
be a working copy. Time to add existing files into Subversion.
Checking existing configuration
files into the repository
[rudd-o@amauta2 ~]# cd /etc [rudd-o@amauta2
/etc]# svn status
You should see a long listing of files,
like this:
? 4Suite ? acpi ? adjtime
The question marks at the beginning of
each line mean that Subversion has no idea what those files
are doing there. So, you’ll add them to the repository:
[rudd-o@amauta2 /etc]# svn add *
You’ll see
svn working
intensely to add those files. Note that the files are not being
added to the repository yet — they’re only being queued for
addition. To commit these files into the repository:
[rudd-o@amauta2 /etc]# svn commit \ -m
'Initial addition of files'
And svn
should start doing its magic. Once it’s done, it’ll tell you
the revision number.
Followup maintenance
Okay, let’s review a few things you need
to keep in mind from now on.
When configuration files are
added to /etc
Check for added files with
svn status /etc.
You should see them listed with a question mark.
You should use
svn add
to add them to the working copy, and then
svn commit
the added files into the repository. Many people make the mistake
of configuring freshly installed files. Do not do that. Instead,
commit
new files first, then edit. That way, you’ll have a way to track
modifications right back to the pristine configuration files.
When configuration files are
deleted from /etc
Check for deleted files with
svn status /etc.
You should see them listed with an exclamation sign.
After doing the check,
svn delete
them. Don’t forget to commit
at the end.
The idea of storing files without full path is questionable: "In my configuration
scheme, each configuration file is in a single directory or in one of its subdirectories.
The configuration files are be named uniquely, and the directories denote
machines or platforms rather than
location."
10 Jun 2004 (DeveloperWorks)
The average developer spends more time navigating, learning,
and debugging configuration files than you'd expect. But you can save that
time -- and loads of energy and frustration -- with one of the tools you
probably use every day: your CVS tree. Take these tips on backing up, distributing,
and making portable your peskiest Linux™ (and UNIX®) config files.
Working with configuration files can be a bewildering part of using Linux
and computers in general. No standards exist, though several have been proposed.
For example, Samba and rsync use INI-style configurations; passwd is in a decades-old
colon-separated format that doesn't allow colons in any field; sudo comes with
a visudo program to keep people from entering wrong information in the sudoers
file; Emacs uses Lisp for configuration files. And the list goes on...
Now, I'm not complaining about the variety of configuration files. I understand
the historical and practical reasons for this Configuration Tower of Babel.
Changing the Samba configuration format, for instance, would annoy thousands
upon thousands of administrators. In another example, Emacs' internal language
is Lisp, a powerful high-level language, so using anything else for Emacs configuration
files would be ridiculous.
No, my point is the effect all this variety has on the Linux user: a large
portion of a Linux user's computer time is spent learning, writing, and debugging
configuration files. Thus, it is useful to have a system in which these configuration
files (1) are backed up automatically, (2) are distributed automatically, and
(3) work on multiple flavors of UNIX and distributions of Linux. This article
explains how to achieve the first two goals, and gets you started on the road
to achieving the third one.
The Plan
We'll use CVS to hold the configuration files. Feel free to use any other
versioning system. Subversion is gaining popularity quickly. The FSF has GNU
tla (GNU arch), another nice versioning system. The essential features you need
are provided by all those and many others, including the non-free ones like
Rational® ClearCase®.
In my configuration scheme, each configuration
file is in a single directory or in one of its subdirectories. The configuration
files are be named uniquely, and the directories denote
machines or platforms rather than
location. Thus, the file name maps uniquely to a location in the filesystem.
For example, passwd will always be used for /etc/passwd, while
cshrc will be used for /home/tzz/.cshrc for user
tzz.
For a few programs I use daily, I'll show how I handle multiple platforms
with the help of my configuration system and changing the configuration files
themselves.
All the examples I show use the C shell to set environment variables. Modifying
them to use GNU bash or something else should not be terribly difficult.
Setting up CVS
You probably already have CVS installed on your machine. If not, get it (see
the
Resources section) and install it. If you are using another versioning system,
try to set up something similar to what I show below.
First of all, you need to create a CVS repository. I'll assume you have access
to a machine that can be used as a CVS server through OpenSSH or Pserver CVS
access (Pserver is the communication protocol for CVS; see
Resources for more information). Then, you need to create a module called
config, which I will use to hold the sample configuration files.
Finally, you need to arrange a way to use your CVS repository remotely non-interactively,
through OpenSSH, Pserver, or whatever is appropriate. This last point is highly
dependent on your particular system administration skills, level of paranoia,
and environment, so I can only point you to some information in the
Resources. I will assume you have configured non-interactive (ssh-agent)
logins through OpenSSH for the rest of this article.
Listing 1. Set up the CVS repository on a machine
# assume that /cvsroot is your repository's home
> setenv CVSROOT /cvsroot
# this will use $CVSROOT if no -d option is specified
> cvs init
# check that it worked
> ls /cvsroot
# you should see one directory called CVSROOT
CVSROOT
|
Now that the repository is set up, you can continue using it remotely (you
can do the steps below on the CVS server, too -- just leave CVSROOT as in Listing
1).
Listing 2. Remotely add the config module to CVS
# user tzz, machine home.com, directory /cvsroot is the CVSROOT
> setenv CVSROOT tzz@home.com:/cvsroot
# use SSH as the transport
> setenv CVS_RSH ssh
# use a temporary directory for the module creation
> cd /tmp
> mkdir config
> cd config
# tzz is the "vendor name" and initial is the "release tag", they can
# be anything; the -m flag tells CVS not to ask us for a message
# if this fails due to SSH problems, see the Resources
> cvs import -m '' config tzz initial
No conflicts created by this import
# now let's do a test checkout
> cd ~
> rm -rf /tmp/config
> cvs co config
cvs checkout: Updating config
# check everything is correct
> ls config
CVS
|
Now you have a copy of the config CVS module checked out in
your home directory; we'll use that as our starting point. I'll use my user
name
tzz and home directory /home/tzz in this article, but, of course, you should
use your own user name and directory as appropriate.
Let's create a single file. The CVS options file, cvsrc, seems appropriate
since we'll be using CVS a lot more.
Listing 3. Create and add the cvsrc file
> cd ~/config
> echo "cvs -z3" > cvsrc
> echo "update -P -d" >> cvsrc
> cvs add cvsrc
# you really don't need log messages here
> cvs commit -m ''
> ln -s ~/config/cvsrc ~/.cvsrc
|
From this point on, all your CVS options will live in ~/config/cvsrc, and
you will update that file instead of ~/.cvsrc. The specific options you added
tell CVS to retrieve directories when they don't exist, and to prune empty directories.
This is usually what users want. For the remaining machines you want to set
up this way, you need to check out the config module again and
make the link again.
Listing 4. Check out the config module and make the
cvsrc link
> cd ~
# set the following two for remote access
> setenv CVSROOT ...
> setenv CVS_RSH ...
# now check out "config" -- this will get all the files
> cvs checkout config
> cd ~/config
> ln -s ~/config/cvsrc ~/.cvsrc
|
You may also know that Linux allows for hard links in addition to the symbolic
ones you just created. Because of the limitations of hard links, they are not
suitable to this scheme. For instance, say you create a hard link, ~/.cvsrc,
to ~/config/cvsrc and later you remove ~/config/cvsrc (there are many ways this
could happen). The ~/.cvsrc file would still hold the old contents of what used
to be ~/config/cvsrc. Now, you check out ~/config/cvsrc again. The ~/.cvsrc
file, however, will not be updated. That's why symbolic links are better in
this situation.
Let's say you change cvsrc to add one more option:
Listing 5. Modify and commit cvsrc
> cd ~/config
> echo "checkout -P" > cvsrc
> cvs commit -m ''
|
Now, to update ~/.cvsrc on every other machine you use, just do the following:
Listing 6: Modify and commit cvsrc
> cd ~/config
> cvs update
|
This is nice and easy. What's even nicer is that the CVS update shown above
will update
every file in ~/config, so
all the files you keep under this CVS scheme will be up-to-date at once
with one command. This is the essence of the configuration scheme shown here;
the rest is just window dressing.
Note that once you've checked out a module, there's a directory in it called
"CVS." The CVS directory has enough information about the CVS module that you
can do update, commit, and other CVS operations without specifying the CVSROOT
variable.
Automatic updates and commits
For automatic updates and commits, I have written a very simple Perl program,
maintain.pl. The longest part of the program is the help text, so you can imagine
it's not full of complex code. I will go through it regardless, but keep in
mind that a shell script could do the same job if needed.
The only thing maintain.pl does not do is make the symbolic links. Since
that has to be done just once, and on some systems you do
not want the links wholesale, the complexity of the task compared to the
simplicity of doing it manually was simply too much. I know because I wrote
the symbolic link code and got rid of it later.
I had to write and maintain yet another configuration file that mapped out
many filenames. There were many exceptions; for example, two Linux and Solaris
systems I use have radically different setups. There were just too many things
to worry about, and I found that manually installing the links was much easier.
Of course, your experience may vary -- I encourage you to try to find the most
appropriate approach for your own environment.
... ... ...
Conclusion
I hope you found this article interesting and useful. Take what you can from
it -- I've spent years perfecting my setup, and it should serve you in good
stead.
Convert to this scheme a little at a time, don't get overwhelmed. You can
easily spend days rewriting your configurations -- so do it gradually and you'll
enjoy the process.
The greatest benefit you'll see is the automatic update function. On any
of your machines, you can commit a file and it will show up everywhere else
the next time maintain.pl is run! Even if you disagree with the directory structure,
think about the power of the automatic updates and how they can be useful to
you.
The second benefit you get is configuration archiving. Every version of your
configurations will be in the revision control system! If you make a mistake,
you can go back to an earlier version. If you lose a whole machine to, say,
disk failure -- you can recover all the time-consuming configuration files you
wrote for it in minutes.
Don't be tempted to convert everything to this scheme. Convert just the things
you want to keep or reuse. Binary files don't work well with CVS -- at the very
least, you won't have the diff capability that CVS provides for
text files. Also, CVS has trouble with renaming directories, although it's certainly
possible if you also rename the directory in the repository.
Finally, keep good backups of your CVSROOT repository, wherever it is. I
hope you never need them.
Resources
- Download the
maintain.pl script and the
maintain.conf configuration file used in this article.
- Read all of Ted's
Perl articles in the
Cultured Perl columns on developerWorks.
-
CVS home contains many CVS-related links. Free software versioning systems
include
Subversion and
GNU arch (also known as GNU
tla). Commercial offerings include
Rational ClearCase.
-
Essential CVS (O'Reilly & Associates, 2003) by Jennifer Vesperman
is a good CVS overview, and
CVS Pocket Reference, 2nd edition (O'Reilly & Associates, 2003)
by Gregor Purdy is an excellent quick reference to CVS -- I highly recommend
it.
-
Open Source Development with CVS, 3rd Edition (Paraglyph Press,
2003) by Karl Fogel and Moshe Bar is a freely available online book; you
can also
purchase a copy at the bookstore.
-
Version Control with Subversion (O'Reilly & Associates, 2004)
is an interesting read.
-
dotfiles.com is an excellent resource for learning about configuring
the C shell, bash, Emacs, and many, many other Linux and UNIX programs.
It's highly recommended; just don't blame us when you spend your whole weekend
browsing the site.
-
OpenSSH is a standard, free, and very good implementation of the SSH
protocol.
CVS Pserver is good for allowing anonymous CVS access, but it is insecure.
- OpenSSH non-interactive logins with the help of an ssh-agent are explained
in
OpenSSH key management (developerWorks, July 2001), a three-part series
by Daniel Robbins.
-
AppConfig is a CPAN module for parsing command-line options and configuration
files. In
Cultured Perl: Application configuration with Perl (developerWorks,
October 2000), Ted demonstrates how the
AppConfig module can
handle local configuration storage for Perl programs, and how such configurations
can be stored in a database that can then be accessed from any machine on
the network.
- You may also want to read
Understanding Linux configuration files (developerWorks, December 2001),
which explains those configuration files on a Linux system that control
user permissions, system applications, daemons, services, and other administrative
tasks.
- Meanwhile,
Debugging configure (developerWorks, December 2003) discusses what to
do when good config files go bad, and an automatic configuration script
doesn't work. Tips for users as well as for developers help you to keep
failures to a minimum.
About the author
Teodor Zlatanov graduated with an M.S. in computer engineering from Boston University
in 1999. He has worked as a programmer since 1992, using Perl, Java™, C, and
C++. His interests are in open source work, Perl, text parsing, three-tier client-server
database architectures, and UNIX system administration. Suggestions and corrections
are welcome; contact Ted at tzz@bu.edu
The Machine Inventory Database (MID) is a Perl-based CGI interface to manage
the machines on and off your network, both from the IP assignment perspective
and the asset-tracking perspective. On top of acting as a frontend to a handful
of MySQL tables, it handles IP assignment and acts as a frontend to the configuration
files for BIND, YP, and DHCPD to reduce the chance for typos in the configuration
files which tend to bring down service.
Just do it (Score:1)
by choi (189590) on
Monday July 19, @07:47PM (#9743061)
| nothing prevents you from just installing cvs and importing/checking out
your config directories. i think it's really not that much work to justify a
distro on its own. |
Do it yourself (Score:1)
by Matt Perry (793115)
<perrym3@gmail.
c o m> on Monday July 19, @07:51PM (#9743096)
| Why not just do it yourself? I keep all of my config files in CVS on my
Debian and RedHat boxes. It's pretty easy to set things up to do this. |
| [
Reply to This ] |
| |
Gentoo
does this. (Score:4, Informative)
by djcapelis (587616)
on Monday July 19, @07:54PM (#9743121)
(http://new.se.foml.inodetech.com/)
|
|
Gentoo offers several choices in managing the configuration files in
/etc, one of these options is the dispatch-conf
script which keeps all changes in RCS. This is mostly for updating...
so it's not everything, but it's definitely a strong start and you could likely
use the same system to keep track of your own modifications.
|
Nothing
is stopping you from doing this. (Score:5, Informative)
by Feztaa (633745)
on Monday July 19, @08:02PM (#9743198)
(http://rbpark.ath.cx/
| Last Journal:
Wednesday June
30, @04:56AM) |
|
Just go into your
/etc/, do a 'mkdir RCS', and then start checking your
config files in and out of RCS to edit them. There's no code anywhere in linux
that says 'if there's a directory I don't recognize, then crash spectacularly',
so just adding the RCS directory itself isn't going to adversely affect anything.
That's actually a really good idea, too, I'm not sure why I never thought of
it myself... |
| [
Reply to This ] |
Re:Nothing is stopping you from doing this.
(Score:5, Informative)
by Atzanteol
(99067) on Monday July 19, @09:14PM (#9743767)
|
There's no code anywhere in linux that says 'if there's a
directory I don't recognize, then crash spectacularly'
I beg to differ... I had an issue just last week where I tried checking
/etc into a CVS repository. It turns out
that /etc/devfs.d/ doesn't like *anything* in it that
doesn't belong (like a CVS directory). This caused
/dev to be very slim upon a reboot, and things like 'hda' et al
were missing.
Now, I'm not sure if this is purely a Gentoo issue or not (I'm not
terribly familiar with devfs), but it's something to remember. Back
up /etc/ before doing ANYTHING! lesson learned...
:-) |
| [
Reply to This |
Parent ] |
-
Re:Nothing is stopping you from doing this. by Bombcar
(Score:2) Tuesday July 20, @12:08AM
|
works
for my user accounts (Score:5, Interesting)
by x00101010x (631764)
on Monday July 19, @08:04PM (#9743224)
(http://slashdot.org/~x00101010x/
| Last Journal:
Monday February
16, @04:44AM) |
|
I keep my entire home directory in a Subversion repository. Works great for
linux and my windows boxes. Firefox and thunderbird user directories are compatible
across platforms.
I just add 'svn up' to my login script and 'svn ci --message "%HOST%@%TIME%%DATE%"'
to my logout script.
No reason it shouldn't work for a whole system with an initial 'svn up' somewhere
in rc.local and periodic updates in a chron job. Just do a commit whenever you
change things on your template system and 5 minutes later it'll be on all your
boxen.
There was a slashdot article about putting a home directory under version control
a few months ago from which I got the idea, too lazy to find the link at the
moment though. |
| [
Reply to This ] |
|
|
BitKeeper
(Score:2)
by twoflower (24166)
on Monday July 19, @08:36PM (#9743457)
|
| Larry McVoy designed BitKeeper with the specific aim of doing this. I believe
they also offer special single-user free licenses for this; you may want to
check the BitKeeper documentation to see if there are any Linux distributions
who actually took him up on this. |
| [
Reply to This ] |
|
|
Most
distros have CVS installed, right? (Score:1)
by Neil Blender
(555885) on Monday July 19, @08:41PM (#9743490)
|
so:
[user@localhost]# su
password:
[root@localhost]# cd /
[root@localhost]# cvs import . -m 'my linux distro' mydistro username start
|
| [
Reply to This ] |
|
|
Yes,
Gentoo... (Score:2, Informative)
by andrewdk (760436)
on Monday July 19, @08:49PM (#9743568)
(http://turbogfx.homelinux.org/)
|
| YEs, Gentoo can do this. Just emerge rcs, make an
/etc/config-archive dir, setup /etc/dispatch-conf.conf,
and just do dispatch-conf in place of etc-update.
An old idea for modern
times... (Score:3, Insightful)
by Deagol (323173)
on Monday July 19, @11:24PM (#9744742)
(http://slashdot.org/)
|
| I think it was OpenVMS (fuzzy memories of a freshman computer class)
that had version control built into the filesystem. I'm amazed that
this hasn't been introduced into the more popular filesystem(s) yet. I've wished
for it on many occasions.
Or am I just being impatient? Will Reiser4 provide this capability?
|
FreeBSD
(Score:2, Interesting)
by Scythe0r (197724)
on Tuesday July 20, @12:14AM (#9745206)
|
|
You should really check out a utility for FreeBSD called
mergemaster. You run it after rebuilding/upgrading
your system and it compares the latest "vanilla" system configuration files
to what you've got.
You can choose to overwrite your file, keep your file or merge the two together.
I like to think of it as the ultimate choice in system housekeeping. |
-
Re:FreeBSD by Rysc (Score:2)
Tuesday July 20, @06:38AM
-
1 reply beneath your current threshold.
|
System
Restore (Score:2)
by yotaku (26455)
on Tuesday July 20, @01:51AM (#9745748)
(http://yotaku.homeip.net/)
|
|
As many people have pointed out having versioning on the config of a system
is hardly a new idea. If you think about what might happen if you try to make
this idea simple and easy to use it might end up being something like System
Restore for Windows, which stores versions before updates, and if you're smart
you make a check point before installing any questionable software or drivers.
And then allows you to roll back if something goes wrong and the uninstall doesn't
fix it. |
|
|
|
changetrack
(Score:1)
by Christopher
Cashell (2517) on Tuesday July 20, @04:19AM (#9746397)
(http://www.zyp.org/
| Last Journal:
Saturday August 18, @01:39AM) |
sudo apt-get install changetrack
For non-Debian users, download
changetrack
[sourceforge.net] from SourceForge.
changetrack uses RCS as it's backend, not CVS (support for CVS is on the Todo
list), but the end result is the same. It is specifically intended for tracking
system files like those in
/etc. |
|
dispatch-conf
(Score:1)
by trickycamel (696375)
on Tuesday July 20, @09:21AM (#9747791)
|
| Gentoo does this for your files in
/etc. Use dispatch-conf and forget about etc-update.
You can set it to use RCS, so no more overwrites of your configs.
RCS and vim (Score:1)
by wolf31o2 (778801)
on Tuesday July 20, @10:43AM (#9748872)
(http://www.gentoo.org/)
|
At work, we have a simple wrapper for vim that does all of the RCS stuff
for us, like checking in and checking out files. We use it on all of our production
servers, as it gives use nice revision control over our files.
#!/bin/bash
ORIGVI=rcsvi
case $1 in
-r[0-9]*) VERSION=$1; shift
;;
esac
[ $# -eq 1 ] || { echo usage: vi [-rrev] filename >&2; exit 1; }
DIR=`dirname $1`
FILE=`basename $1`
### let vi handle error conditions
cd $DIR || exec $ORIGVI $1
[ -d $FILE ] && exec $ORIGVI $FILE
### skip certain directories
{ [ -r $HOME/.rcsvirc ] && . $HOME/.rcsvirc; } ||
{ [ -r /etc/rcsvirc ] && . /etc/rcsvirc; } ||
EXCLUDE="/tmp | /tmp/* | /etc/skel |
/etc/skel/* | /home | /home/* |
/usr/home | /usr/home/*"
[ -n "$EXCLUDE" ] && eval "case $PWD in $EXCLUDE) exec $ORIGVI $FILE
;; esac"
### create RCS directory if not exist
[ -d RCS ] || { mkdir RCS || exit $?; }
### check $FILE for existence, break possible lock or exit, check in
[ -e $FILE ] && { [ -e RCS/$FILE,v ] && { rcs -l $FILE || exit 1; }
ci -q -l $FILE </dev/null; }
[ -n "$VERSION" ] && { co $VERSION $FILE; chmod u+w $FILE; }
### edit $FILE
$ORIGVI $FILE
### check in $FILE
ci -u $FILE
# EOF
|
|
|
cfengine
(Score:2, Informative)
by bandix (184495)
<<ten.knupkeeg>
<ta> <xidnab>> on Tuesday July 20, @06:36PM (#9754240)
(http://www.geekpunk.net/)
|
You'll spend years fooling around with RCS and CVS for configuration versioning
before realizing that what you really need is cfengine. CVS or svn for source
code, cfengine for configuration. Cut to the chase:
http://www.cfengine.org/ |
Perl script to generate GNU-style ChangeLogs for CVS
cvs2cl.pl generates GNU-style ChangeLogs for
a CVS working copy. There are many options to control the output.
Cfruby allows managed system administration using Ruby by David Powers
and
PjotrPrins. It is both a library of Ruby functions for system administration
and an Cfengine-like clone. Cfruby is current deployed on servers, clusters
and workstations. See below for an introduction on both.
Cfruby can be downloaded from
http://rubyforge.org/projects/cfruby/
as a gem. You can also access the SVN repository through the Rubyforge
web interface.
It is important to understand that Cfruby is really two in one:
- Cfrubylib is a pure Ruby library with classes
and methods for system administation. This includes file copying,
finding, checksumming, package management, user management etc.
etc.
- Cfenjin is a simple scripting language
for system administration - allowing for scripting of configuration
tasks (without knowledge of Ruby). Naturally Cfenjin uses Cfrubylib
itself.
So, if you are looking for a Ruby API check out Cfrubylib. But if
you are looking for a scripting language check out Cfenjin.
To confuse matters more: you can use Ruby mixed with Cfenjin style
scripting - but that is for those who have a weird streak - also known
as geekishness.
Cfrubylib
Cfrubylib is a Ruby library for system administration. It can do
most of the common tasks like file tidying, editing etc. etc. Best to
study the API and code in:
http://cfruby.rubyforge.org/cfrubylib/
and the source repository:
http://rubyforge.org/viewvc/lib/libcfruby/?root=cfruby
More written documentation can be found in the source repository:
http://rubyforge.org/viewvc/documentation/libcfruby/?root=cfruby
Why reinvent the wheel? And you'll find it gives a lot more power
than most configuration tools. Cfrubylib includes cfyaml - a YAML configurator.
And support for FreeBSD Portage, Linux Debian, Linux Gentoo and OS-X
Fink packages. Adding support for your favourite package manager should
be straightforward.
Cfenjin
Cfenjin is a GNU Cfengine clone written in Ruby. It does not offer
a full replacement for Cfengine (for one we don't have a client/server
protocol, though cfrubylib has some support for that itself) - but it
is Ruby and consists of few lines of code using Cfrubylib.
Documentation has been written, bits and pieces, but for now it is
probably the best idea to study the examples in:
http://rubyforge.org/viewvc/documentation/cfenjin/examples/?root=cfruby
after reading the tutorial below.
Enjoy!
mValent Integrity tracks changes to deployed
servers and monitors configuration drift alerting IT teams to potentially critical
problems. By comparing application environments in mValent Integrity for differences
in granular configuration items, IT teams rapidly isolate root causes of production
incidents. These teams can then model fixes to problems to validate their impact
and automatically deploy them.
- Rich Compare Capabilities – mValent Integrity's
Compare function aids troubleshooting by quickly pinpointing differences
between multiple server instances or across infrastructure stacks representing
different application environments.
- Versioning and Rollback - Running 'snapshots'
of application infrastructure environments, plus the ability to recover
quickly from unwanted changes.
- Tracking and Alerts - Knowing when a change
has been made - no matter what changed - and accurately reporting on the
specific properties before and after the change, gives IT teams early warning
on potential problems.
- Point-in-Time Views - By keeping a running
record of changes to a granular level, mValent Integrity reports on all
changes that occurred between two points in time, or show that no unapproved
changes took place.
- Audit Reports – Show the changes made to
an individual server or a whole production environment by time period or
by user.
Configuration Collector (SCC) is yet another
configuration collector. It consists of a client and a server part. The client
collects configuration data in a structured snapshot, compares the new snapshot
with the previous one, and adds differences to a logbook. Then the snapshot
and the logbook are converted to HTML for local inspection. Optionally, the
data can be sent to a system running the server software. On the server, summaries
of the data are generated, and search/compare operations on the snapshots and
logbooks are available via a Web interface.
Changes: This
release will not update the keep file when running in interactive mode. It ignores
differences in the main log file when moving data to "split" hosts. Split conditions
have been extended with a simple process check. A correction for Debian for
large lines with many fields. Include files have been added for logrotate.conf.
Includes for Apache have been corrected. Netscape Fasttrack server has been
added.
Remote Server Management Tool is an Eclipse plug-in
that provides an integrated graphical user interface (GUI) environment and enables
testers to manage multiple remote servers simultaneously.
What is Remote System Management Tool?
Remote Server Management Tool is an Eclipse plug-in
that provides an integrated graphical user interface (GUI) environment and enables
testers to manage multiple remote servers simultaneously. The tool is designed
as a management tool for those who would otherwise telnet to more than one server
to manage the servers and who must look at different docs and man pages to find
commands for different platforms in order to create or manage users and groups
and to initiate and monitor processes. This tool handles these operations on
remote servers by using a user-friendly GUI; in addition, it displays configuration
of the test server (number of processors, RAM, etc.). The activities that can
be managed by this tool on the remote and local server are divided as follows:
- Process Management:
This utility lists the process running on UNIX and Windows® servers. One
can start and stop processes. Along with process listing, the utility also
provides details of the resources used by the process.
- User Management:
This utility facilitates creation of users and groups on UNIX servers; it
also provides options for listing, creating, deleting, and modifying the
attributes of users and groups.
- File Management:
This utility acts as a windows explorer for any selected server, irrespective
of its operating system. One can create, edit, delete, and copy files and
directories on local or remote servers. Testers can tail the remote files.
How does it work?
This Eclipse plug-in was written with the Standard
Widget Toolkit (SWT). The tool has a perspective named Remote System Management;
the perspective consists of test servers and a console view. The remote test
servers are mounted in the Test Servers view for management of their resources
(process, file system, and users or groups).
At the back end, this Eclipse plug-in uses the
Software Test Automation Framework (STAF). STAF is an open-source
framework that masks the operating system-specific details and provides common
services and APIs in order to manage system resources. The APIs are provided
for a majority of the languages. Along with the built-in services, STAF also
supports external services. The Remote Server Management Tool comes with two
STAF external services: one for user management and another for proving system
details.
APRIL 18, 2005
(COMPUTERWORLD)
- With the growing interest in adopting best practices across IT
departments, particularly according to standards such as the Information Technology
Infrastructure Library (ITIL), many organizations are deciding to implement
a configuration management database (CMDB). A CMDB should help them discover
and manage the elements in their IT infrastructure so they can better understand
the relationships among components and facilitate changes effectively. This
is important because there is a significant business value in having a single
"source of record" that provides a logical model of the IT infrastructure to
identify, manage and verify all configuration items in the environment.
Having reliable data requires more than a database.
It requires a well-conceived configuration management strategy; without knowing
what's in your environment, you can't hope to control it, maintain it or improve
it.
Since configuration items are at the heart of
the CMDB, it's important to understand what they encompass. A configuration
item is an instance of a physical, logical or conceptual entity that is part
of your environment and has configurable attributes specific to that instance.
Examples of configuration items would be a computer system (attributes could
include a serial number or IP address) or even an employee (with configurable
attributes such as hours worked and department number).
Getting Started: Developing the Right
Strategy
Once you have determined that you may need a
CMDB, how do you select the approach that's best for you? Everything begins
with ITIL, the industry framework for IT service management. To get started
on developing a configuration management strategy, set your objectives according
to ITIL goals, which state that configuration management accounts for all the
IT assets and configurations within the organization and its services. According
to ITIL, the ideal CMDB should also provide accurate information on configurations
and their documentation to support all the other service management processes.
In addition, it must provide a sound basis for incident management, problem
management, change management and release management. It must be able to verify
the configuration records against the infrastructure and correct any exceptions.
If you think that creating a CMDB is a major undertaking, you're right. But
it can be done effectively if you follow the right approach for your organization.
Lessons Learned: The Evolution of the
CMDB
The concept of a CMDB has evolved over the years
from a collection of isolated data stores to integrated data stores to a single,
central database. Each time, it gets closer to being the source of record for
configuration data without taking a toll on the infrastructure. However, those
who have tried these approaches find that they have serious drawbacks that make
them difficult or impossible to scale. A better alternative is the federated
data model. This approach features a centralized database linked to other data
stores with a common data model that carries information from one point to another,
without the need to rewrite code. I will describe this model in more detail
after providing an overview of how it evolved.
The predecessors to CMDBs, popular in the 1990s,
consisted of several applications that stored their own data, including configuration
data. This approach could meet ITIL's goal of accounting for IT assets and services,
but because the data wasn't integrated, the approach fell short of other objectives,
such as understanding dependencies and relationships among configuration items.
With isolated data stores, your asset management application may not see data
from a discovery application, and your service-impact management application
may not be able to modify service-level agreements.
IT organizations also tried to create CMDBs by
directly integrating their various data sources and applications, connecting
each data consumer to each provider from which it needed data. This approach
allowed different configuration management processes to share data, greatly
improving the CMDB's usefulness as a means to integrate applications and IT
processes they support. But it required a lot of resources to create and maintain
what tend to be brittle, hard-coded connections between systems.
Recently, vendors have been offering a single,
all-encompassing CMDB to hold configuration data that's accessible by all applications
that need the data. But an all-encompassing database isn't feasible in
a large, distributed organization. It creates an access bottleneck because all
requests for and updates to data pass through the same path. It also
requires a massive migration to get all of your data into the single database,
creating a complicated data model that must change if any application integrated
with the CMDB changes.
Putting It All Together With a Federated
Data Model
The most effective approach is the federated
data model. It's the best way to share configuration data without the high setup
and maintenance costs associated with the pure centralized approach. It puts
primary and widely shared configuration-item data in a common data store and
federates other noncritical attribute data from other application databases.
According to a recent Gartner Inc. study ("Defining a Configuration Management
Database," by P. Adams and R. Colville, November 2004), "A practical approach
for a successful implementation of a configuration management database will
require a federated data model with a consistent view that receives at least
some data from element-specific tools (for example, desktop configuration management,
server configuration management, network management and storage management)."
This federated approach to a CMDB offers a single,
common set of information on each configuration item and its relationships with
other configuration items in a manner that can be leveraged by all relevant
IT processes -- creating cost-saving synergy among different service management
functions. A federated data model enables you to fully integrate critical service
and infrastructure management applications and break down the traditional functional
silos that often exist within an IT organization, all of which streamlines delivery
of IT services.
Important Benefits of a Federated Approach
- The CMDB can focus its functionality on
configuration items and their relationships. This functionality includes
partitions for multiple "snapshot" versions, reconciliation of data from
multiple sources and federated data. The overhead required to provide this
functionality isn't wasted on data that doesn't need it.
- You don't have to migrate related
data or modify the CMDB to hold this information.
With the boundary drawn at configuration items and their relationships,
the question of whether to store some new type of data in the CMDB is already
answered. You store it instead as part of the CMDB Extended Data and save
the trouble of changing the data model in the CMDB to accommodate the new
type of data. You also avoid pitfalls inherent in trimming the data model
if you later decide to move data out of the CMDB. In addition, you don't
need to undertake several data migrations and application integrations to
move your change requests, help desk tickets and other configuration item-related
data into the CMDB. Applications that use this data can continue to access
it where you currently store it.
- Transactional data can be stored
in databases that are better able to handle a high volume of requests, instead
of in the CMDB. Data is provided more efficiently.
Instead of getting all their data from the CMDB, data consumers can get
it from individual data stores that are optimized to provide the specific
type of data being requested.
- The CMDB doesn't become a bottleneck.
With requests for related data on its own being handled by other databases,
the CMDB doesn't have to accommodate all such traffic in addition to configuration
item-related requests. You can spread the load across multiple systems.
What should this federated model look like?
This model refines ITIL's idea of a CMDB by breaking
up the CMDB and its infrastructure into three layers. These are the CMDB itself;
related data linked to or from the CMDB, called the CMDB Extended Data; and
applications that interact with these two layers, called the CMDB Environment.
The CMDB and CMDB Extended Data layers together
contain the information ITIL suggests be stored in a CMDB. Separating this information
into two layers is what distinguishes the federated CMDB approach from other,
less-successful CMDB approaches. The CMDB holds only configuration items and
their relationships. However, not all available configuration-item attributes
must be stored in the CMDB. In fact, to keep the CMDB scalable and manageable,
you should store only the key attributes here and link to the less-important
ones in the CMDB Extended Data.
The CMDB Extended Data layer holds related data,
such as help desk tickets, change events, contracts, service-level agreements,
a definitive software library and much more. Although these things aren't configuration
items, they contain information about your configuration items and form an important
part of your IT infrastructure. In addition, the CMDB Extended Data layer holds
any configuration-item attributes judged as unnecessary to be stored in the
CMDB.
The data in the CMDB Extended Data layer is linked
to the configuration item data in the CMDB. By definition, federated configuration-item
attributes are linked from their instances in the CMDB, allowing requests to
the CMDB to reach these attributes. But for other types of extended data, the
link can be in either or both directions. For example, a change-request record
could have a link through which you can access the instances of the configuration
items it will change, and each configuration-item instance could have a link
through which you can access the change requests that affect it.
To pursue ITIL's goals for configuration management,
you should consider the advantages of a federated data model and what it can
do for you.
Doug Mueller is the chief technology
officer at the Service Management business unit of BMC Software Inc. and a co-founder
of Remedy Corp., now a part of BMC.
Doug Mueller is the chief technology officer for the Service Management Business
Unit of BMC Software and a co-founder of Remedy, now a part of BMC.
The software is designed to help businesses unify
service- and infrastructure-management tools to promote database management
consistency and simplified integration among processes.
By Darrell Dunn,
InformationWeek
Jan.
21, 2005
URL:
http://www.informationweek.com/story/showArticle.jhtml?articleID=57702869
BMC Software on Monday will announce the availability of
its Atrium Configuration Management Database (CMDB), intended to help customers
unify their service and infrastructure management.
Based on industry-standard IT Infrastructure
Library requirements for enterprisewide database management with consistency
and simplified integration among different management processes, the CMDB is
also the first offering by BMC to be branded under the Atrium name, says Andrej
Vlahcevic, senior product marketing manager for change and configuration management
at BMC.
Over the course of the year, BMC plans to introduce
other management products under the Atrium brand. "A lot of people see a CMDB
as a common set of information that captures data on the configuration and relationship
of items in your IT environment," Vlahcevic says. "We believe it has to be more."
The Atrium database was designed to integrate both service and infrastructure-management
applications, he says, as well as complement the company's existing line of
discovery tools.
The Atrium CMDB includes a reconciliation engine
that lets users combine input from multiple data sources and identify and reconcile
any differences to establish a configuration profile. "If you don't have strong
reconciliation, the CMDB will end up with repetitive data that ultimately will
create confusion," Vlahcevic says.
The Atrium CMDB was designed with industry standards
in mind, he says, including those endorsed by the Distributed Management Task
Force and the Common Information Model. The platform supports all primary IT
Infrastructure Library configuration item classes and more than 80 potential
relationship types that can be leveraged to characterize an IT environment.
The Atrium CMDB is integrated with eight existing
BMC applications, including the IT Discovery Suite, Service Impact Manager version
5.0, and Remedy IT Service Management Suite version 6.0. It's available now
and can be purchased as part of any BMC Remedy IT Service Management version
6.0 products and the Service Impact Manager version 5.0.
PIKT® is a registered trademark of the University of
Chicago. Copyright © 1998-2005 Robert Osterlund. All rights reserved.
PIKTis cross-categorical, multi-purpose software to monitor and
configure computer systems, report and fix problems,
manage system security, arrange job scheduling,
format documents, install files, assist command-line work, and perform many
other common systems administration tasks. PIKT
is used primarily for system monitoring, and secondarily for
configuration management, but its flexibility and extendibility
evoke many other uses limited only by your imagination. One reviewer said of
PIKT, "this is by far one of the most interesting/powerful
tools I have seen for Linux administration." Another wrote that
PIKT "excels at handling a diverse collection of
machines, saves time and eliminates repetition, and gives you a global
view of your site." PIKT has been compared favorably
to commercial software costing hundreds of thousands of dollars. Yet
PIKT costs you nothing! Who uses
PIKT? The
answer might surprise you. To learn more, read the
Introduction
pages. For example uses and configurations, visit the
Samples
pages.
What is PIKT
- An acronym: Problem Informant/Killer
Tool.
- An innovative new paradigm for administering
heterogeneous networked workstations.
- System monitoring software that both reports
and, wherever possible, fixes problems.
- A cross-categorical, multi-purpose toolkit
with uses limited only by your imagination.
- A content management system for websites,
an aid in configuration management, and a basis for building system security.
- An embedded scripting language and accompanying
script interpreter.
- A sophisticated script and system configuration
file preprocessor for use with the Pikt scripting language or any other
scripting language of your choice.
- A cross-platform, centrally run job scheduler
(like cron), customizing file installer (like rdist), command shell enhancement,
and comprehensive script and configuration management software.
- Available for Linux and many other flavors
of Unix, including AIX, Digital UNIX, FreeBSD, HP-UX, IRIX, OpenBSD, Solaris,
and others.
PIKT
is Open Source software distributed under the GNU GPL.
What is PIKT not?
- A GUI-enhanced system. This is in
the works, but as an option only.
- An all-purpose programming language.
PIKT is tailored to systems administration,
designed to work hand-in-hand with other languages, not to replace them.
- Available for Mac OS X and other Unix variants.
(Not yet anyway.) Nor is it available for Windows. (Perhaps
some day.)
- The last word in system monitoring software.
(But maybe it's farther back in the dictionary.)
Why the name "PIKT"?
PIKT is like a military picket, "a group of soldiers
or a single soldier stationed, usually at an outpost, to guard a body of troops
from surprise attack" (Webster's New World College
Dictionary). A pickets' primary mission is to
warn of the enemy's advance, but to fight if necessary. Similarly,
PIKT's primary task is to warn of problems, but
to fix those problems when needed.
How do you pronounce "PIKT"?
"PIKT" rhymes with "ticket".
This document is a basic introduction about few
useful tools for a sysadmin that wants to install OS, to perform simultaneous
operations on multiple machines via ssh and to upgrade a machine already installed
using an automatic (or manual) procedure. For more detailed information please
refer to the bibliography added in the following paragraphs.
IMPORTANT: this document is based on our experience
with a farm running Scientific Linux CERN 3.0.4 and should not be considered
a general guide, it is not exhaustive and cover only few items involved in farm
administration.
It is already described in another document:
how it is possible to setup a kickstart installation
server. Here we will add only few notes about the customization of the kickstart
file, providing an example:
that must be changed accordingly with a specific
site configuration. This example was written with the idea to install a Scientific
Linux CERN OS, from which we removed few packages (or turned off few services)
not strictly needed for machines not located at CERN. To find all the possible
options for a kickstart file please refer to:
In our kickstart file example it is shown how it is possible
to add (or remove) different groups of packages, for example:
@ Text-based Internet
add the packages: mutt,
fetchmail and elink.
It is possible to use a graphical tool redhat-config-packages
to show the full list of package in a group like Text-based
Internet.
To add/remove a single rpm it is possible to use a single line like:
-phone
to exclude the installation of the
phone rpm. Vice-versa to add a rpm it is possible
to use:
+<package name>
for example if you want to install
wget it is sufficient to add:
+wget
In our example of kickstart file there are few services
explicitly started or stopped using chkconfig.
The pcmcia service is turned off:
chkconfig pcmcia off
vice-versa ntpd is turned
on:
chkconfig ntpd on
to have time synchronization.
In the kickstart file it is possible to include operations
to be performed after the OS installation, at the first reboot. In our kickstart
file few example are present as a reference, in the section
%post. We will comment about them in the APT section.
As an example if you want to configure the INFN AFS cell add the following lines
in the post-install section of the kickstart file:
mv /usr/vice/etc/ThisCell /usr/vice/etc/ThisCell.orig
cat >> /usr/vice/etc/ThisCell <<EOF
infn.it
EOF
The CERN Scientific Linux distribution uses the APT tool
as package manager. You can find more detailed information about APT here:
In this distribution by default APT comes with CERN configuration
to use the CERN RPM repository. Details of this configuration, with some explanation
about apt commands, are available here:
In our kickstart file example we included a post-install
section to re-configure APT in order to use a local RPM repository (see also
http://grid-it.cnaf.infn.it/fi
