Re: Plea for base system trim
On Wed, 5 Mar 2003, Subscriber wrote: Would the powers that be please consider removing sendmail, bind and openssl from the base system, as was done for perl with 5.0? This topic has been discussed ad nauseum, and the consensus has always been that those three things (and openssh) should stay in. Please see the archives for the reasoning. For example, as BIND maintainer I actually _support_ the theory of removing BIND, however the reality is a little different. There are three main components of BIND; the named stuff (sbin/named, sbin/ndc, etc.), the userland stuff (dig, host, etc.), and the resolver library. Of those three things, we actually need the last two in order to include ourselves in a useful definition of Unix system (although I'd LOVE to nuke nslookup, if I thought I could ever live down the whining and crying it would cause). So keeping BIND in the base actually serves a purpose. Similar arguments can be made for the other components you listed. Now that said, I've been working off and on to make it easier to replace parts of the base with stuff from the ports. Both BIND ports have PORT_REPLACES_BASE_ Makefile options, and I know that they are useful because I use them at work. I have a proposal document and some patches that both need polishing to create a standard way to do this. My long term goal (although this is not necessarily shared by other people in the project) is to make it easier to create a modular system that takes advantage of the ports exclusively for contrib code. Of course, we've been talking about this for 8 years too, so don't hold your breath. :) Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. That sounds like a mistake to me, but I'm not familiar with the details. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
D'oh, I forgot the other half of my response (I KNOW you're disappointed by this). :) A big part of the reason that perl was cut is that bmake'ing the build was a NIGHTMARE. By contrast, the BIND bmake glue is not terribly difficult to maintain. The other contributing factors were the license (not BSD friendly, although not as bad as some other things), the fact that we'd already cut other interpreted languages like tcl, and the fact that the perl state of the art moves faster than our major release cycles. Of course, it doesn't help that perl weenies (of which I'm one) tend to like the bleeding edge, and FreeBSD is (rightfully) more of a comfortable, don't upgrade it if it already works kind of place. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
Thus spake Subscriber [EMAIL PROTECTED]: Would the powers that be please consider removing sendmail, bind and openssl from the base system, as was done for perl with 5.0? Please don't restart this flamewar. When we have a better installer, then it may be possible in the future to select between multiple mailers (for example), but nobody is going to rip out widely-used functionality because someone has a pet peeve. (And yes, this *is* just a pet peeve; if it were not, you'd see people complaining about ntpd, ipfilter, pnpinfo, etc. instead.) Check the archives. As far as security updates are concerned, keep in mind that base system components are actually *better* supported by the FreeBSD security officer than are ports. If you really want the ports version of something, put the appropriate NO_* option in your make.conf and install the ports version instead. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, Mar 05, 2003 at 09:54:13AM -, Subscriber wrote: Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. I hate having two versions installed; it makes me fear that there will be problems caused by the wrong version being used. You are right to hate having two versions installed --- it is pointless in most cases. Please complain to the apache+mod_ssl and openssl port maintainers. It sounds to me like they are doing something very wrong. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
Subscriber wrote: Would the powers that be please consider removing sendmail, bind and openssl from the base system, as was done for perl with 5.0? There are /etc/make.conf variables to control this so you can do it for yourself: #NO_BIND= true# do not build BIND #NO_OPENSSH=true# do not build OpenSSH #NO_OPENSSL=true# do not build OpenSSL (implies NO_OPENSSH) #NO_SENDMAIL= true# do not build sendmail and related programs Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, Mar 05, 2003 at 07:43:15AM -0600, Jacques A. Vidrine wrote: On Wed, Mar 05, 2003 at 09:54:13AM -, Subscriber wrote: Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. I hate having two versions installed; it makes me fear that there will be problems caused by the wrong version being used. You are right to hate having two versions installed --- it is pointless in most cases. Please complain to the apache+mod_ssl and openssl port maintainers. It sounds to me like they are doing something very wrong. At least in the case of net/net-snmp the problem is that the shared lib version of the openssl port was bumped when the base wasn't which screws up the dependencies. :-( -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Plea for base system trim
I use this command in my build script to force apache13+modssl to use the openssl in base. # Use base openssl (OpenSSL 0.9.7a as of Feb 19 2003) cd /usr/ports/www/apache13-modssl cp Makefile Makefile- sed -ie 's/^\.include.*Makefile\.ssl.*$/OPENSSLBASE=\/usr/' Makefile- Makefile You wrote: On Wed, Mar 05, 2003 at 09:54:13AM -, Subscriber wrote: Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. I hate having two versions installed; it makes me fear that there will be problems caused by the wrong version being used. You are right to hate having two versions installed --- it is pointless in most cases. Please complain to the apache+mod_ssl and openssl port maintainers. It sounds to me like they are doing something very wrong. Cheers, - -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] Adrian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, Mar 05, 2003 at 08:54:28AM -0800, Brooks Davis wrote: At least in the case of net/net-snmp the problem is that the shared lib version of the openssl port was bumped when the base wasn't which screws up the dependencies. :-( That's part of the problem. The port bumped the shared library version, even though it installed ABI-compatible library. Moreover, it bumped it to a new version number that was only 1 higher, almost designed to cause trouble :-) If all OpenSSL-using ports used `-rpath', then this wouldn't be a problem. But that is kind of a burden. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
I have both apache-modssl and net-snmp running, but do NOT have the openssl port installed. Everything builds and runs fine, with no mods to anything. I conjecture that the problem others experience is that they have installed the openssl port, which I have never done. This is on both current and stable. On Wed, Mar 05, 2003 at 06:00:13PM +0100, Adrian Steinmann wrote: I use this command in my build script to force apache13+modssl to use the openssl in base. # Use base openssl (OpenSSL 0.9.7a as of Feb 19 2003) cd /usr/ports/www/apache13-modssl cp Makefile Makefile- sed -ie 's/^\.include.*Makefile\.ssl.*$/OPENSSLBASE=\/usr/' Makefile- Makefile You wrote: On Wed, Mar 05, 2003 at 09:54:13AM -, Subscriber wrote: Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. I hate having two versions installed; it makes me fear that there will be problems caused by the wrong version being used. You are right to hate having two versions installed --- it is pointless in most cases. Please complain to the apache+mod_ssl and openssl port maintainers. It sounds to me like they are doing something very wrong. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, Mar 05, 2003 at 01:15:29PM -0500, Barney Wolff wrote:
I have both apache-modssl and net-snmp running, but do NOT have the
openssl port installed. Everything builds and runs fine, with no
mods to anything. I conjecture that the problem others experience
is that they have installed the openssl port, which I have never done.
This is on both current and stable.
Oops, not net-snmp, net-snmp4 (aka ucd-snmp). net-snmp doesn't appear
to have a dependency on openssl at all.
Here's a log:
[10:19am] [EMAIL PROTECTED] (/usr/ports/net/net-snmp4): pkg_info openssl\*
pkg_info: can't find package 'openssl*' installed or in a file!
[10:19am] [EMAIL PROTECTED] (/usr/ports/net/net-snmp4): portversion openssl
** No package matching 'openssl' was found.
[10:19am] [EMAIL PROTECTED] (/usr/ports/net/net-snmp4): sudo make
Password:
You may use the following build options:
WITH_PORTSSL=yes Use the OpenSSL Version delivered by the ports.
With FreeBSD 5, net-snmp4 requires automaticly
the OpenSSL ports-version. In the 5 case, you
don't need to define WITH_PORTSSL (default).
WITHOUT_SSL=yes Disable the OpenSSL support.
=== Extracting for ucd-snmp-4.2.6
Checksum OK for ucd-snmp-4.2.6.tar.gz.
=== Patching for ucd-snmp-4.2.6
=== Applying FreeBSD patches for ucd-snmp-4.2.6
=== Configuring for ucd-snmp-4.2.6
=== ucd-snmp-4.2.6 depends on file: /usr/local/libexec/autoconf213/autoconf - found
=== ucd-snmp-4.2.6 depends on executable: libtool - found
=== ucd-snmp-4.2.6 depends on file: /usr/local/bin/perl5.6.1 - found
=== ucd-snmp-4.2.6 depends on shared library: crypto.4 - not found
===Verifying install for crypto.4 in /usr/ports/security/openssl
openssl-0.9.7a.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
Attempting to fetch from http://www.openssl.org/source/.
[...]
The problem is that this line forces WITH_PORTSSL with recent OS versions.
.if defined(WITH_PORTSSL) || ${OSVERSION} = 500100 || (${OSVERSION} = 470103
${OSREL} == 4)
-- Brooks
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgp0.pgp
Description: PGP signature
Re: Plea for base system trim
On Wed, 5 Mar 2003, Adrian Steinmann wrote: I use this command in my build script to force apache13+modssl to use the openssl in base. # Use base openssl (OpenSSL 0.9.7a as of Feb 19 2003) cd /usr/ports/www/apache13-modssl cp Makefile Makefile- sed -ie 's/^\.include.*Makefile\.ssl.*$/OPENSSLBASE=\/usr/' Makefile- Makefile You could instead do: sed pattern Makefile makefile The lowercase makefile will be used by make in preference to Makefile. You are right to hate having two versions installed --- it is pointless in most cases. Please complain to the apache+mod_ssl and openssl port maintainers. It sounds to me like they are doing something very wrong. Seconded. Getting the lib version numbers out of synch for the same openssl version in base and ports sounds like a big, big accident waiting to happen. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed Mar 05, 2003 at 02:29:00PM -0800, Doug Barton wrote: On Wed, 5 Mar 2003, Adrian Steinmann wrote: I use this command in my build script to force apache13+modssl to use the openssl in base. # Use base openssl (OpenSSL 0.9.7a as of Feb 19 2003) cd /usr/ports/www/apache13-modssl cp Makefile Makefile- sed -ie 's/^\.include.*Makefile\.ssl.*$/OPENSSLBASE=\/usr/' Makefile- Makefile You could instead do: sed pattern Makefile makefile The lowercase makefile will be used by make in preference to Makefile. Juste jumping in... Couldn't you just: sed -i.orig -e pattern Makefile For example: [EMAIL PROTECTED] cat foo this is a test [EMAIL PROTECTED] sed -i.orig -e 's/test/gizmo/' foo [EMAIL PROTECTED] diff -u foo.orig foo --- foo.origWed Mar 5 17:54:09 2003 +++ foo Wed Mar 5 17:54:13 2003 @@ -1 +1 @@ -this is a test +this is a gizmo Much simpler, unless I missed something. A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On 2003-03-05 02:14:16 (-0800), Doug Barton [EMAIL PROTECTED] wrote: On Wed, 5 Mar 2003, Subscriber wrote: Would the powers that be please consider removing sendmail, bind and openssl from the base system, as was done for perl with 5.0? For example, as BIND maintainer I actually _support_ the theory of removing BIND, however the reality is a little different. There are three main components of BIND; the named stuff (sbin/named, sbin/ndc, etc.), the userland stuff (dig, host, etc.), and the resolver library. Of those three things, we actually need the last two in order to include ourselves in a useful definition of Unix system Is it actually possible for one to build a custom release without the ``unnecessary'' BIND bits? I haven't grepped the source, forgive me, but what does 'NO_BIND=true' actually do? If I were to make a release like that, would that end me up without resolver as well? Likewise, would building 'NO_SENDMAIL=true' build me a pristine system void of Sendmail bits, or will there always be some stuff left? If those two knobs do what they promise to do, it should be fairly trivial to compare a custom release tree with the installed base, and nuke the things one doesn't like from the base-system at will? Or am I missing something? :-) I'm pretty happy about having BIND and Sendmail in the base-system. Disk space costs nearly nothing these days, and as long as they're not running (and have their executable bits stripped, 'just in case'), I don't particularly mind them taking up a few bytes of room. (although I'd LOVE to nuke nslookup, if I thought I could ever live down the whining and crying it would cause). :-) Perhaps a NO_NSLOOKUP flag? ;-) So keeping BIND in the base actually serves a purpose. Similar arguments can be made for the other components you listed. Definitely! Now that said, I've been working off and on to make it easier to replace parts of the base with stuff from the ports. Both BIND ports have PORT_REPLACES_BASE_ Makefile options, and I know that they are useful because I use them at work. I just spotted those flags a few days ago. They're very useful. Now my fiddling with the BIND port is reduced to making stuff live under /var/namedb instead of /etc/namedb as I like having / mounted read-only as much as possible. - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #193: Did you pay the new Support Fee? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, 5 Mar 2003, The Anarcat wrote: Juste jumping in... Couldn't you just: sed -i.orig -e pattern Makefile No, because sed -i is evil, and will cause you to have hairy palms. -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed Mar 05, 2003 at 03:52:22PM -0800, Doug Barton wrote: On Wed, 5 Mar 2003, The Anarcat wrote: Juste jumping in... Couldn't you just: sed -i.orig -e pattern Makefile No, because sed -i is evil, and will cause you to have hairy palms. What? A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Thu, 6 Mar 2003, Philip Paeps wrote: Is it actually possible for one to build a custom release without the ``unnecessary'' BIND bits? I haven't grepped the source, forgive me, but what does 'NO_BIND=true' actually do? If I were to make a release like that, would that end me up without resolver as well? It's not as thorough as I think it should be. I plan to get cracking on this now that I've got my ports more or less whipped into shape pre-freeze. Perhaps a NO_NSLOOKUP flag? ;-) Yeah, I'll add that along with the PIGS_WILL_FLY flag. I just spotted those flags a few days ago. They're very useful. Good news, thanks. Now my fiddling with the BIND port is reduced to making stuff live under /var/namedb instead of /etc/namedb as I like having / mounted read-only as much as possible. One way you can do this fairly easily with PORT_REPLACES_BASE is to have your chroot tree look something like this: /var/named/other stuff you need /var/named/etc/namedb/named.conf (etc) Then have /etc/namedb be a symlink to /var/named/etc/namedb, with 'directory /etc/namedb;' in your named.conf file. That way, both named and ndc see the same picture of the system, in and out of the chroot tree. I already use this at work, and I plan to add a lot of this config to the base itself here pretty soon. But you can easily get a head start on it now using what I described above. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On 2003-03-05 16:46:04 (-0800), Doug Barton [EMAIL PROTECTED] wrote: On Thu, 6 Mar 2003, Philip Paeps wrote: Is it actually possible for one to build a custom release without the ``unnecessary'' BIND bits? I haven't grepped the source, forgive me, but what does 'NO_BIND=true' actually do? If I were to make a release like that, would that end me up without resolver as well? It's not as thorough as I think it should be. I plan to get cracking on this now that I've got my ports more or less whipped into shape pre-freeze. Thanks! The possibility of having a way to completely erradicate the 'superfluous' bits of BIND sounds very appealing. I'd be happy to break some machines to help test this :-) Perhaps a NO_NSLOOKUP flag? ;-) Yeah, I'll add that along with the PIGS_WILL_FLY flag. *grin* Now my fiddling with the BIND port is reduced to making stuff live under /var/namedb instead of /etc/namedb as I like having / mounted read-only as much as possible. One way you can do this fairly easily with PORT_REPLACES_BASE is to have your chroot tree look something like this: /var/named/other stuff you need /var/named/etc/namedb/named.conf (etc) Then have /etc/namedb be a symlink to /var/named/etc/namedb, with 'directory /etc/namedb;' in your named.conf file. That looks a lot cleaner than what I've got now. Good project for tomorrow morning. Also gets rid of the confusing (to some) directory /' in the config, and allows those obsessed with editing /etc/namedb/named.conf to find themselves at home. That way, both named and ndc see the same picture of the system, in and out of the chroot tree. Speaking of ndc, I think that's a BIND8-ism. Could the port be convinced to symlink it to rndc when set to replace the base, or would that confuse other things? Currently, I'm just aliasing it in my shell, but that seems a bit hackish :-) I already use this at work, and I plan to add a lot of this config to the base itself here pretty soon. But you can easily get a head start on it now using what I described above. Briliant! I'll have people congratulate me on the cleanliness of my nameserver by lunchtime tomorrow :-P - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. If you see a man approaching you with the obvious intent of doing you good, you should run for your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
At 2:07 AM +0100 2003/03/06, Philip Paeps wrote: Speaking of ndc, I think that's a BIND8-ism. Indeed, it is. With BIND-9, ndc won't even work -- Unix sockets aren't supported, and IP sockets are secured with crypto keys. Could the port be convinced to symlink it to rndc when set to replace the base, or would that confuse other things? Currently, I'm just aliasing it in my shell, but that seems a bit hackish :-) That could potentially be done, but keep in mind that there are some things that ndc can do that rndc can't -- ndc start being one of the big ones. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Thu, 6 Mar 2003, Philip Paeps wrote: That way, both named and ndc see the same picture of the system, in and out of the chroot tree. Speaking of ndc, I think that's a BIND8-ism. Not _exactly_ true, but yes, ndc is what you use to manage BIND 8. All comparisons to tools that you may or may not use to manage future versions of BIND are apples and oranges. -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On 2003-03-06 02:17:19 (+0100), Brad Knowles [EMAIL PROTECTED] wrote: At 2:07 AM +0100 2003/03/06, Philip Paeps wrote: Speaking of ndc, I think that's a BIND8-ism. Indeed, it is. With BIND-9, ndc won't even work I discovered that the unpleasant way. Typing ndc gave me a long list of socket errors and other general unhappiness. Even after quite a while, I still find myself forgetting the 'r' in ndc. Good I have an alias :-) Could the port be convinced to symlink it to rndc when set to replace the base, or would that confuse other things? Currently, I'm just aliasing it in my shell, but that seems a bit hackish :-) That could potentially be done, but keep in mind that there are some things that ndc can do that rndc can't -- ndc start being one of the big ones. Mmm, true. For all purposes, however, rndc is the ndc of BIND9, and I doubt I'm the only DNS-admin who's typed ndc so often it's become a nervous tic :-) I didn't realise the 'ndc start' bit though. Sounds a bit like a chicken/egg situation? Life's little existential mysteries, eh? - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #329: Server depressed, needs Prozac To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
