Date: Tue, 26 Nov 1996 11:34:42 -0800 (PST) From: "William R. Somsky" <somsky@dirac.phys.washington.edu> To: hackers@freefall.freebsd.org Subject: Re: Replacing sendmail Message-ID: <199611261934.LAA02956@dirac.phys.washington.edu> In-Reply-To: <199611260631.WAA13912@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Nov 25, 96 10:31:51 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Short of making pkg_control a humongous beast from hell with inate
> knowledge of every possible package you might want to enable or
> disable, it seems like a generic package control program is something
> of a bitch to do, and by calling it "pkg_control" that's exactly what
> you're suggesting it does.
>
> That's why I suggest doing this more incrementally by service type.
> In my examples, there would actually be something like 3 different
> commands:
>
> mail_control -enable qmail -disable sendmail
>
> access_control -incoming -enable ssh -disable rlogin,telnet
>
> lp_control -enable apsfilter
>
> Each command would have a much easier time of it since it only has to
> know about a limited set of services. By keeping the argument names
> orthogonal (though I think that -enable and -disable are a bit
> stretched in some of these examples :-), it's also easier to write a
> front end which can feed them all.
>
> Just my 2 cents.
Well, I'll toss my 2 cents in as well... (Or perhaps it's only
one cent, since this may turn our a half-*ssed idea. :-)
Even a mail_control would be difficult -- would it understand and know
how to setup/enable/disable/whatever, say, qmail, procmail, othermail,
wrsmail, spiffmail, bogusmail, etc, etc, etc?
I would think that the actions to be performed for any given package
would need to be specified individually for that package, and not
within the "tool" itself. Suppose we had something sort of like this:
We'd have a general tool which has all the interface and manipulation
pieces for performing general tasks like this (presenting the
user w/ choices, copying files, deleting files, modifiying files
according to some pattern, etc), but has no "what to do"
intellegence and which knows nothing of any specific package,
tool, utility or service.
For each "thingy" that can be manipulated (sendmail, qmail,
telnet, lpr, etc) there is a "maintainance control" file which
tells the general tool 1) what maintainance actions can be done
to this "thingy" (install, enable, disable, reset, cleanup, etc)
and the "commands" to execute to do this -- these would be "commands"
understood by the general tool, such as "add this line to the
/etc/foobar file", "delete any line containg 'bar' from the
/etc/barfoo file", and not necessarily true shell commands.
Perhaps it would look someting vaguely like:
(I'm just making this up, so don't take it too serioiusly.)
# Maintainance control for foomailer
# ... stuff for installing, enabling, etc ...
start: # start foomailer running
{
run /etc/foomailer -l foolog # execute /etc/foomailer
}
stop: # stop foomailer
{
killjob foomailer # kill any process called foomailer
delete /var/lock/foolock/* # delete any foolock files
}
reset: # reset foomailer from possible error conditions
{
@stop # do the "stop" action
@start # do the "start" action
}
prune: # clears out the foo logfiles to
{
prune 1000 /var/log/foolog # directive to prune to last 1000 lines
}
So then once you copied the foomailer files into place you could
execute the commands like: "thiny_cntl foomailer reset" or
"thingy_cntl foomailer prune" to perform those actions, and if
you like more hand holdy interfaces, "thingy_cntl -i foomailer"
would bring up an interactive thingy tool which would present a
menu of the available actions for foomailer.
If anyone was ambitious in writing this thing, you could have ways within
the tool to have parameters for some of the actions, and be able to
query the user for parameters if not supplied...
I'm not saying we should have something kind of like this (I'm definitly
_not_ saying we should have something _exactly_ like this), but I though
I'd toss the idea in the ring so others could kick it around and see if
there is anything useful they could wring out of it.
I guess the main point I'd like to suggest is that perhaps the way to go
is with a general tool that contains all the muscle for doing these things
and individual per-package/utility/service control files which contain all
the brains for what to do.
So, can anybody get anything out of this -- other than severe nausia?
________________________________________________________________________
William R. Somsky somsky@phys.washington.edu
Department of Physics, Box 351560 B432 Physics-Astro Bldg
Univ. of Washington, Seattle WA 98195-1560 206/616-2954
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611261934.LAA02956>