Packaging questions (cricket)
The following is an except from a correspondence with Josip Rodin, who
has been advising me on packaging matters. He suggested that I forward
my questions here for more feedback.
Thanks for any help...
----- Forwarded message from Matt Zimmerman <mdz@csh.rit.edu> -----
Date: Sun, 22 Aug 1999 14:57:56 -0400
From: Matt Zimmerman <mdz@csh.rit.edu>
To: Josip Rodin <joy@cibalia.gkvk.hr>
Subject: Re: Bug procedure
On Sun, Aug 22, 1999 at 02:21:15PM +0200, Josip Rodin wrote:
> On Fri, Aug 20, 1999 at 03:09:28PM -0400, Matt Zimmerman wrote:
> > I have started working on a new package, for the Cricket data collection
> > and display software <http://www.munitions.com/~jra/cricket/>. I am
> > [...]
> Great! If you need any assistance from me, just say.
Well, I'd like your feedback on the directory structure I'm experimenting with.
Cricket is a collection of Perl programs used to 1) gather data from various
sources (e.g. SNMP, script output, etc.) and store them in a database (provided
by the soon-to-be rrdtool package) and 2) retrieve and display these data in a
graphical format via a CGI program. The "usual" installation procedure (as
described in the program documentation) is to untar the distribution into a
dedicated user's home directory, run a script to substitute the correct
location of the Perl interpreter, and symlink the CGI part into a directory
that is part of the web namespace. The directory structure looks something
like this:
cricket-0.70
|-- doc (documentation)
| `-- neta-paper
|-- images (used by the CGI)
|-- lib (Perl modules used internally)
| |-- Common
| |-- ConfigTree
| `-- RRD
|-- sample-config (a sample configuration tree)
`-- util (auxiliary and example programs called to do data collection)
The user-visible part of the package is installed in the cricket-0.70
directory, and consists of programs like 'compile', 'collector', 'grapher.cgi',
etc.
Most of these programs are not called interactively, and have very generic
names, which makes me very hesitant to put them in /usr/bin. My current
plan is this:
- Configuration tree in /etc/cricket
- 'compile' (a program to convert the ASCII configuration into a database
format for use internally) in /usr/sbin as 'cricket-compile'
- 'collector' and friends (all architecture-independent) installed in
/usr/share/cricket and called from a cron job (conffile /etc/cron.d/cricket)
- Perl library modules under /usr/share/cricket/lib
- Documentation and examples in /usr/doc/cricket
- CGI programs in /usr/lib/cgi-bin/cricket
- Databases in /var/lib/cricket
--- postscript: I have since changed this to /var/state/cricket
I have not yet decided what to do with the images...policy states that
packages should avoid touching the web server document root. Should
I install them under /usr/share/cricket and tell the user to Alias that
directory to /cricket/images with the web server or some such?
Also, this package needs a UID for the collector to run under, as it needs to
create database files, etc. How should this be handled, and in which
installation script? Should I ask the user what to do, or create a user
without prompting? I looked to other packages for examples, and found that
squid creates a 'proxy' user (in preinst) without prompting, so I gave my
package that behavior for the time being (though I am using postinst). If the
user already exists, a message is printed explaining the situation, and no
changes are made. I noticed that the squid package just exits silently if the
'proxy' user already exists...it seems that this does not handle the case where
the desired username is being used for local purposes, in which case I imagine
that Squid would break badly. Should I try to detect this situation (that is,
whether the user was created by my package or by the local admin, and act
appropriately), or is squid doing the right thing?
The other interesting part is its methodology for finding its configuration.
The scripts do a little Perl-ism:
$Common::global::gInstallRoot = (($0 =~ m:^(.*/):)[0] || "./") . ".";
To find where they are installed, so as to locate the 'lib' directory
immediately beneath. This actually works OK for the collector (in
/usr/share/cricket), as it will find the correct 'lib'. For 'compile',
I manually edited it to use /usr/share/cricket as its 'root'. This part
is kind of a mess.
One of the library modules is used to read the configuration, and it does
the following:
my($base) = "$ENV{'HOME'}/cricket-config";
GetOptions( "loglevel:s" => \$logLevel,
"base:s" => \$base, @_);
Common::Log::setLevel($logLevel);
$Common::global::gConfigRoot = $base;
It seems that my options are (at least):
- Change the initial default of $base, in the declaration, to be /etc/cricket
(this is somewhat intrusive, but is what I have been using for testing and
it works well)
- Replace the Cricket programs with a wrapper script that calls them with the
options '--base=/etc/cricket' (this would break in the event that a user would
want to actually use the tools with an alternate configuration, for instance
when testing)
- Arrange for a symlink to be created in the cricket user's home directory,
called 'cricket-config', pointing to /etc/cricket. This breaks when the
tools are called by any user other than Cricket, and is messy.
What would you recommend?
Lastly (for now ;-) ), the collector will need a logfile to write to, so that
the user can tell what is going on. The correct prodedure for this would seem
to be:
- Have the collector write its logfile to /var/log/cricket
- Add a conffile /etc/logrotate.d/cricket to have the logfile rotated in
a reasonable default way
Since logrotate is not essential, I will have to depend on it somehow. While
log rotation is not required for the package to be functional, its logging is
pretty verbose, and if left unattended the logfile can grow quite large (I use
Cricket extensively at work, and my configuration generates about 24mb of
logfiles per week). Should I Recommend or Suggest logrotate? Recommend
seems more appropriate to me, so that the unwary do not have their
disks filled.
This should be quite a good learning package, no? ;-)
--
- Matt
----- End forwarded message -----
--
- Matt
Reply to: