Date: Tue, 26 Nov 1996 09:11:18 -0800 (PST) From: "Brant Katkansky" <bmk@pobox.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: bmk@fta.com, jgreco@brasil.moneng.mei.com, brantk@atlas.com, peter@taronga.com, hackers@freebsd.org Subject: Re: Replacing sendmail Message-ID: <199611261711.JAA15695@itchy.atlas.com> In-Reply-To: <10627.848988232@time.cdrom.com> from "Jordan K. Hubbard" at "Nov 25, 96 10:03:52 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > MTA selection can be handled by doing 'pkg_control -disable sendmail; > > pkg_control -enable qmail'. Of course, for novices, this operation > > would be hidden behind the slick UI that hasn't been written yet. > > Ok, well, the real question I still have here is "what determines > the intelligence behind the enable/disable action?" The intelligence is determined by the script/program which is called by pkg_control. > What I mean by this is that while it's relatively easy to quantify > the enable/disable actions for sendmail/qmail, by calling your > utility "pkg_control" you're intimating that this thing will work > effectively for *all* packages which might be enabled or disabled. That is the intent. > To use a totally contrived example, let's say I wanted to disable all > forms of remote login access except for ssh (as many people do). > I would expect to be able to say: > > pkg_control -enable ssh > pkg_control -disable rlogin,telnet > > [yes, I know that rlogin and telnet aren't packages but ssh is, so > already we're into a real grey area, just as with sendmail]. > > The actions behind making this happen are quite different than the > sendmail/qmail selection actions, and this package-specific > intelligence has to go *somewhere*, right? Sure. With the current model that Joe has suggested, each of these actions would cause a script to be executed. Currently, what would be done is the executable would be made suid/!suid, made mode 000, or removed. Nothing would be done to system configuration files (/etc/sysconfig, for example). That's not to say that it couldn't be done in the future. Our current configuration scheme does not lend itself well to anything but manual configuration. > Or let's say I wanted to install apsfilter as my default printer > filter. I might want to say: > > pkg_control -enable apsfilter > > Which would entail yet another entirely different set of operations. ...which would be controlled entirely by a set of scripts/programs for each package. I've got to admit, this is probably not a perfect way of doing things. I'm open to suggestions. > 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 I don't have any real strong objections to doing it this way, but I do think that we're not really thinking along the same lines. > 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. Joe's model for pkg_control doesn't "know" anything about services, nor does it need to. It knows about "packages" and "actions". Think of it as a front end to external utilities which will perform most of the work. I don't see it as any less maintainable. Using the incremental approach, you _still_ need to define for each package what steps are required to perform a given step. I'm not completely sold on Joe's model, but I am running with it for the time being. The C code for it has been already written (and is actually pretty simple, BTW). I'll be working on the back end scripts for sendmail, and a few other things tonight. I'm not going to invest a ton of time into this until we have something close to a consensus as to how (and if!) it should be done. It just occurred to me that maybe it's the _name_ we're hung up on. If we called it something else, would some of your objections disappear? -- Brant Katkansky (bmk@pobox.com, brantk@atlas.com) Software Engineer, ADC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611261711.JAA15695>