From owner-freebsd-hackers Tue Nov 26 15:42:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03659 for hackers-outgoing; Tue, 26 Nov 1996 14:36:21 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA03640 for ; Tue, 26 Nov 1996 14:36:14 -0800 (PST) Received: from dirac.phys.washington.edu (dirac.phys.washington.edu [128.95.93.1]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id LAA12868 for ; Tue, 26 Nov 1996 11:35:58 -0800 (PST) Received: by dirac.phys.washington.edu (951211.SGI.8.6.12.PATCH1042/UW-NDC Revision: 2.25 ) id LAA02956; Tue, 26 Nov 1996 11:34:43 -0800 From: "William R. Somsky" Message-Id: <199611261934.LAA02956@dirac.phys.washington.edu> Subject: Re: Replacing sendmail To: hackers@freefall.freebsd.org Date: Tue, 26 Nov 1996 11:34:42 -0800 (PST) In-Reply-To: <199611260631.WAA13912@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Nov 25, 96 10:31:51 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 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