Date: Sat, 15 Apr 2000 22:09:35 -0500 (CDT) From: Joe Greco <jgreco@ns.sol.net> To: andreas@klemm.gtn.com (Andreas Klemm) Cc: current@freebsd.org Subject: Re: Integrating QMAIL in the world Message-ID: <200004160309.WAA44065@aurora.sol.net> In-Reply-To: <20000413071642.A12908@titan.klemm.gtn.com> from Andreas Klemm at "Apr 13, 2000 7:16:43 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, Apr 14, 2000 at 05:21:24PM -0500, Joe Greco wrote: > > Remove Sendmail from the base system - or, at least, make it a "package" > > that is removable with the package management tool. Then be able to add > > another mailer (or an updated Sendmail) in its place. Ideally, Sendmail > > would be available as a package for installation as part of the base > > system, just like games or info or proflibs. > > Sounds all basically like a good idea to have different choices > for a MTA. > > But I don't like _basic_ system functionalities to be out sourced > completely to ports. Why not? They already are. You're kidding yourself if you think that the FreeBSD project is maintaining Sendmail and BIND. > Two examples: > > If I give people a FreeBSD-STABLE snapshot CD, I'd like to give > them a complete Unix, and for me a MTA belongs to a basic package. > > If I want to do a complete upgrade of all of my system ports, > because I come to the conclusion > - I installed to much experimental crap and don't get it > sorted out manually > - or I want to upgrade everything to the latest and greatest > I don't want to kill my MTA (sendmail) by performing a rm -rf /usr/local/* > action. Then solve _that_particular_problem_. For example, as I outlined several years ago, define "built-in" packages, which, when you do a "pkg_delete sendmail", actually nukes what is (now) in /usr/libexec/sendmail*, /etc/sendmail.cf, etc. Then, when you do a "pkg_add sendmail", well, I don't know if there's more merit to putting the executables in the /usr/libexec directory (I think my preference would be not to do that) or in /usr/local... but one of those. A really clever implementation would be to set up this stuff as install components, and then you can have sysinstall "select" the Sendmail component automatically for normal installs, but leave it up to the guy who's doing the Custom install. If not selected, none of Sendmail is installed. If selected, Sendmail is installed, as a component, but also as a package, so that doing "pkg_delete" removes /usr/libexec/sendmail* and friends. Of course, none of this is particularly new. I proposed it years ago, as a way to cut down on various forms of system bloat (not everyone needs perl5, or Sendmail, or BIND, or UUCP, or the C compiler) and to allow for easier upgrades of individual system components that are, in fact, NOT PART OF THE SYSTEM. They actually come from outside vendors, and are generally things that require upgrading more often than the actual Real-Base-Of- FreeBSD does. > FreeBSD - as is - has all the basic system functionality in the > base system and I wouldn't like to have a "neutral" "castrated" > Unix just for the sake, that you can start later to customize > things like sendmail and maybe other things Whee. Where's the GUI? I fail to be impressed! Yet it does not seem to be an issue that X11 isn't part of the base system. It is just something that is made easy to install, and in fact, users might not realize that X11 isn't "part of" FreeBSD. Hell, I'm proposing something that is much closer to a seamless system to include or remove the components in question than what we do with XFree86, yet the XFree86 solution is acceptable to us... > > I would love to see this happen with other components of the system as > > well, such as BIND. > > definitively not. I hate the Linux way to have a puzzle system. You have it now. Running BIND? Hope it's a recent version. Otherwise, poof. All sorts of problems. Got that ancient 2.2.5 system laying in the back closet? Didn't upgrade Sendmail? Heaven help you when somebody finds an exploit for your old Sendmail. We should make it easy to update parts of the system that realistically may _require_ updating in order to maintain the security of the overall system. We should not make it a "go figure it out, newbie" type project for beginning users to perform an upgrade of some essential networking utility, the next time an obvious root exploit is released. > Again FreeBSD != Linux. FreeBSD != Linux. FreeBSD == crap-for-ease-of-upgrading-or-replacing-built-in-packages. Linux == closer to that goal from what I've seen. This == bad for FreeBSD. > > While it is fantastic that FreeBSD comes out of the box so fully > > functional, it does make it a bit of a pain for those of us who intend > > to build servers - we have to disable the original before installing a > > new package. :-/ > > Well ... for that purpose I'd vote for the following: > > a) make more > NO_XXXX (sendmail, bind, whatever) > knobs in /etc/make.conf as needed > b) make the Makefiles in the install target more complete by > removing (old) occurrencies of sendmail, bind, if such a > NO_XXX knob has been set. > Then you get such an ISP server as you like after a make world > session Some of us don't "make world" to build our systems, and requiring the average newless cluebie to figure out how to do a "make world" in order to replace a version of Sendmail with a major security hole is ridiculous. > c) Split FreeBSD packaging any further (bin, man, doc, compat,...) > Add something like a package internet (sendmail, bind, ...) > Then you can install a sendmail, DNS free system as you like. Ah, finally we take the first step to something I proposed years ago. Keep following that path, and eventually you'll figure out that to make it really work well, it also needs to integrate into the packages/ports system to allow for after-the-fact removal and/or replacement (addition can probably be handled by sysinstall). Then you can argue my whole case for me. :-) > But I wouldn't for a generally castrated BSD. Nobody is. But I would certainly argue for a more flexible BSD, especially if it increased security, decreased the complexity of maintaining security, and offered other peripheral benefits at the same time. -- ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004160309.WAA44065>