From owner-freebsd-arch Fri Feb 16 23:22:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id C921B37B4EC for ; Fri, 16 Feb 2001 23:22:17 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1H7MHm20405; Fri, 16 Feb 2001 23:22:17 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Feb 2001 23:22:17 -0800 (PST) From: Matt Dillon Message-Id: <200102170722.f1H7MHm20405@earth.backplane.com> To: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Summary of List of things to move from main tree to ports Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, here's my summary. Yah yah, I inject my own opinions. Too bad. This will be my last posting on the topic. Least Controversial: games There does not seem to be much resistance to the idea of moving most /usr/src/games out of the main source tree and into ports. People seem to content to argue about other things. My opinion is that while the base games are still fun to play, there are so many games in ports that are as interesting or more interesting that the usefullness of having the original set in the base tree is marginal at best, even if you play 'hack' all the time. My only exception is 'fortune', which many third party apps (like xscreensaver) just assume exists on the system. rdist (apparently already removed from current) Medium Controversial: UUCP (uucp, uucpd) Robert Watson suggests, and others agree that the best way to handle UUCP is to change the NO_UUCP make.conf option into a BUILD_UUCP make.conf option. I would interject that, in addition to that, we should not create the uucp directory hierarchy unless uucp is selected in make.conf (i.e. not create /var/spool/uucppublic, a directory which defaults to modes 777, by default). Robert Watson also makes the point about the suid/sgid nature of many uucp binaries, and I and others will attest to the fact that UUCP is simply not maintained anymore. That is a dangerous combination to have installed in the system by default. There are fewer people screaming for UUCP to stay in the base tree then, say, people screaming for rlogind to stay in the base tree. Despite Terry's waxing poetic about UUCP's dialup capabilities, every soul I know (except maybe Terry) who has ever used UUCP in the past no longer does (and I should know: I wrote AmigaUUCP!). However, if those people are going to make a big deal about it, I suppose we can take the intermediate step of having a BUILD_UUCP make.conf (opt-in) option for the next few years. Kerberos IV Robert Watson argues (several times) about the complexity of integrating certain packages, namely KRB4, into the system. A counter argument is made that such integration is not necessarily a good thing. I would interject that KRB4 is so undesireably complex that integration is pretty much the only way you can support it, which is why we should throw it out and push KRB5 the last few yards it needs to be pushed to get it in as well as KRB4. KRB4 is a nightmare, integrated or not. Lyndon Nerenberg provides an example - his shop - which relies on the massive integration provided in our KRB4 implementation. He makes a reasoned argument for GSSAPI. But it can also be argued fairly easily that GSSAPI is actually preventing us from moving forward with its extremely limited scope. It may not be a good idea to force oneself to stay in the past because the future doesn't support your favorite API. Terry brings up a good point in regards to PAM. I feel that PAM is the most likely future, but it can't be use to justify moving 'older' pieces off the system until the newer pieces actually use it in the proper way. That is, at the moment GSSAPI is more proven then PAM, but PAM has the momentum and will likely be able to take over completely sometime in the next few years. When that occurs, anyone still using KRB4 is going to be faced with a very tough decision. So as far as KRB4 goes, I think we are going to have to keep it around until PAM catches up and KRB5 reaches the same level of integration. I am personally amazed at KRB4's staying power, but the writing is on the wall. Highly Controversial: telnetd, rshd, rlogind, rexecd rmt, rcp, rlogin, rsh A number of people favor removing the server side utils. Virtually nobody favors removing the client side utils. Terry argues that he still uses the daemons (not a very good argument in my opinion), others argue that the daemons are useful within firewalled networks (also a terrible argument in my opinion). There was a reasonable argument by Nate in regards to mixed windows <-> UNIX networks where the windows boxes used the above standard utilities to access the UNIX boxes. While I will point out that it is relatively easy to use ssh on a windows box, it is still no where near as easy as it is to use ssh on a UNIX box. David O'Brien probably made the best argument, if you remove the all-caps phrases from his posting. The daemons are turned off by default, keeping the binaries around does not present a serious burden on the system. Yes, it could be argued that this slows the adoption of protocols like ssh, but the daemons are still used enough that we cannot justify removing them from the system. And, despite being old, the daemons do support kerberos connections as an option (though I will add: Not very well. There are terrible bugs with regards to streaming and EOF handling with the kerberized telnet, for example. It's good enough for terminal sessions but I don't trust them for anything else). ftp, ftpd Mostly specious arguments. There are obvious uses for ftp and even ftpd in regards to anonymous downloading. Since ftpd is most often used for anonymous operations on publically available files, there is no real argument for removing it even though some idiots will probably use it with sensitive materials. Nobody seriously argued for the removal of ftp, but that didn't stop others from freaking out and screaming loudly that it should stay in the system. sendmail bind I think only Cy Schubert is the only one in favor of moving sendmail and bind to ports. Most everyone else is very loud in wanting to keep it. However, even Cy is partial to using make.conf options to select what to build and/or install and others tend to agree that that is a reasonable approach. Chris brings up a very good point about certain major packages (e.g. sendmail) being actively maintained by committers whereas other packages do not have the same level of commitment. My opinion is that, like bind, sendmail is a core piece of the system. If we were to provide alternatives, they would also have to be brought into the main tree (e.g. on a vendor branch) and maintained as such. Then you could choose via rc.conf and you could disable elements with make.conf (unlike UUCP, which should be opt-in, if we are given sendmail & bind equivalents to choose from in the base system they should probably be opt-out in regards to (not) compiling them, then selected with rc.conf). I can see postfix being brought into the vendor branch and being maintained as the same level that sendmail is maintained. I don't really see qmail being maintainable at the same level that postfix is maintainable, and three MTAs in the base tree is probably too many. As Chris says, someone needs to be willing to seriously maintain it. Someone brought djbdns up. Security alone is not a good enough reason to try to bring something into the base tree. To be in the base tree the program must be supported and I don't know a single person willing to maintain (long term) the unreadable, uncommented djbdns code. I feel that the most likely course of action is that bind8 will eventually become bind9. While Paul does not produce the most secure code in the world, he's a lot easier to work with and he acknowledges that bind8 has reached the end of its usefullness. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message