Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Jan 2015 12:22:38 +0100
From:      Michelle Sullivan <michelle@sorbs.net>
To:        Roger Marquis <marquis@roble.com>
Cc:        Mark Linimon <linimon@lonesome.com>, freebsd-ports@freebsd.org
Subject:   Re: BIND REPLACE_BASE option
Message-ID:  <54B3AE7E.2070306@sorbs.net>
In-Reply-To: <20150112062240.0B2C1B1A@hub.freebsd.org>
References:  <mailman.1.1420977600.74846.freebsd-ports@freebsd.org> <20150111235449.A14AEF52@hub.freebsd.org> <20150112040129.GA16097@lonesome.com> <20150112062240.0B2C1B1A@hub.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
I'm going to wade in with a +1 at the top for your original message, and
add some thoughts of my own inline.

Roger Marquis wrote:
> Mark Linimon wrote:
>> It was believed to be a bad design pattern to let ports modify anything
>> in base.
>
> Believed by who?  Surely not those of us advocating FreeBSD in mixed
> environments where the Linux and Windows admins are pushing for something
> closer to a monoculture.

Dunno about who believed what, however it has always struck me as odd
that servers are installed in the base and then only patched with the
OS.  The notable exceptions are things like BIND where you could select
a later BIND from the ports tree and install over the base version. 
This initially I found confusing and likely to cause more security
issues than it resolved...  However, I then thought about it, and
realised that what should really have been considered is this (in my
opinion):

*NO* servers installed in Base (no sendmail, no NTPD, no BIND etc) then
in the ports tree a "dns/bind-base" port where it would install a bind
server into the base OS, a 'mail/postfix-base', a 'mail/sendmail-base'
etc... or better still a /usr/ports/base where you can find postfix,
sendmail, bind etc...

This way there are no base ports installed by default, base packages are
available with the OS and the specific '-base' port can always be
patched as part of freebsd-update, it can be built as part of a /usr/src
building/patching process and therefore it can be patched as the user
needs in short order (particularly important when you have issues such
as the latest root exploit for ntpd... not saying the way that security
moved and patched it in a few days wasn't good, it was awesome...
however the problem is I had servers ranging from 6.0 -> 9.3 at various
patch levels - I now have most of my servers either 6.x or 9.2+ (the 6.x
servers are all behind firewalls with only specific services (apache
and/or postfix) exposed where necessary so the exploit is mitigated)...

BUT the patching from 7.3, 8.4 and 9.0 of 27 of the servers 15 of them
became unbootable for a variety of reasons... Corrupt loader on 2
occasions, unable to initiate network interface or RAID card on several
occasions and changing of critical permissions in others (9.3-RELEASE ->
9.3-p5 broke sudo-1.8(latest) on 3 of the machines by changing
permissions on 'something')... having /usr/ports/base where one could
find 'ntpd' and install it in base would be an excellent solution as one
could update/patch oneself if security@ didn't consider the priority as
high as the user.  It would also mean that the base source code is not
polluted and one can install what one needs as and when needed.

>
>> Apparently 10.0 seemed like the appropriate time to get rid of the
>> bad pattern.
>
> "seemed like the appropriate time" isn't a business case and "bad
> pattern" it likely wasn't considering A) someone requested it, B) someone
> spent money and/or time writing it and C) many people were using it.

Roger, you can forget arguing that, I've tried it falls on deaf ears and
people just put you on ignore like they have with me... doesn't matter
if you're right or not..  Some at the top have a mark to make and being
right or wrong won't get in the way of that mark.

>
>> We've been essentially rewriting the entire ports infrastructure
>> in-place
>> for the past 6 or 7 years.  IMVHO this was entirely necessary: the old
>> pkg_* tools were buggy, underdocumented, and no longer suited to the
>> task

Which is why pkg_* tools are now removed when you 'delete-old' and all
the *.mk keep changing to remove pkg_* support even though those of us
that have spent the time to put it back have found that it still works
with little changes...  Everything in the source seems to point to
someone making their mark to remove the pkg_ tools rather than any
specific need...  Why it couldn't have been left for pre 10.x and then
make 10.x pkgng only I don't know... oh wait I do.. it didn't have many
people using it so it was decided to force people to change...  Lets
think of that for a moment... people tried it decided it wasn't "ready"
and didn't migrate, so Bapt wrote patches and deployed on 1/9/2014 not
to EOL pkg_* but specifically to break pkg_* then discouraged anyone
from back patching (including security fixes) to the quarterly to force
the upgrade on production systems.
>
> Not sure what this has to do with a small number of mission-critical
> ports that need to write to base to accommodate large, cross-platform,
> installed bases.  Could you elaborate?
Breaking out the servers from /usr/src is good idea, removing -base
functionality (IMHO) is not... but it is a good idea to make it simpler
because the -base options (especially when not always translated in
version changes) did cause me a few issues in the past.

>
>> They are mostly due to the idea of not shipping things that do not work
>> consistently, and in the way one "might expect".  On rare occasion, yes,
>> that will mean breaking POLA.
>
> Are you saying, then, that bind, postfix and other ports that have
> overwritten base for years "do not work consistently"?  That hasn't been
> my experience nor that of those who I work with.

No, nor mine (everything worked fine for me - except when there was a
major version bump and I forgot to add the -base option)

>
>> AFAIK the companies that embed FreeBSD into their products are primarily
>> interested in the kernel, the networking stack, the file systems, and so
>> on. I do not know of any such company that even _uses_ FreeBSD ports.
>
> I see your point but it indicates your experience is missing a large
> portion of FreeBSD users.  The financial institution where I work for
> example, runs hundreds of FreeBSD boxes and uses ports and port options
> on all of them.
>
>> Thus, they could have no influence on the outcome.
>
> If large numbers of BSD servers and engineers with decades of BSD
> advocacy really have no influence, and it appears we don't, at least
> the reason for our favorite OS' shrinking user-base is clear.
+1 (I'm on that list)
>
> Statements like "buggy, underdocumented, and no longer suited to the
> task" and "could have no influence on the outcome" are perhaps a downside
> of exclusively developer-driven ecosystems.
Perhaps someone should have looked at fixing bugs and fixing
documentation.  Classic example, about a year ago I started writing
ports.  Took me some time (a lot longer than getting my first C ever
program written) to get a working port of my own creation... took longer
to get it committed (though I can thank people on #freebsd (for doc
help) and Koobs (committer) for their time and patience that I was
actually successful.)

>   Redhat's understands this,
> which is why they involve sales, sysadmins and management in similar
> decisions, not just devs who are looking to spend less time maintaining
> "old" code.  (They're also paying people to maintain code, something I
> wish we could find a way to do.)

Which is why $employer are now planning on moving all my servers to Redhat..
>
>> tl;dr: the FreeBSD ports community is pretty well self-contained.
>
> Do you mean in contrast with, for example, the Debian community?
> <https://www.debian.org/devel/join/>;

I'd more call 'relevance' than argue that... ;-)

Michelle

-- 
Michelle Sullivan
http://www.mhix.org/




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54B3AE7E.2070306>