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>