[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150806123009.GB17399@openwall.com>
Date: Thu, 6 Aug 2015 15:30:09 +0300
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: bind (was: new Owl ISOs & templates)
On Mon, Aug 03, 2015 at 12:14:39PM +0300, gremlin@...mlin.ru wrote:
> During the update of my servers, I found we should move the config
> files into a separate bind-default-config subpackage.
Why is that, and why single bind out? This sounds like a distro-wide
policy issue, and we'd need some very good reasons to adopt that policy.
I am not aware of such reasons currently.
> Also, absolutely all files in the /usr/share/doc/bind* should be
> moved to bind-doc subpackage (neither should be left in the main
> package): people who may want to read something beyond the manual
> pages generally are able to install bind-doc :-)
This is also a distro-wide policy issue. The choice we made previously
was to put into -doc subpackages only the unusually large pieces of
documentation, while keeping more basic and smaller documentation in the
main packages. Putting everything into -doc appears to defeat the
purpose of having -doc subpackages at all, because the same effect can
be achieved by installing with the --excludedocs option to rpm.
On a related note, these recent bind updates also revealed that our
current definition/use of the bind-slave control(8) facility is a bit
problematic. Many Owl sysadmins were unaware of it, and had chmod'ed
the slave directory manually, often to other than one of the exact two
modes that the facility recognizes. This results in those custom set
permissions getting lost on package update. Maybe we should have %post
print a warning when `control bind-slave` returns "unknown". Maybe we
should also have it inform the sysadmin of the control facility on the
first package install. Or maybe we should drop this facility altogether
and have the package default to mode 1770 ("enabled") for the slave
directory. Unfortunately, I don't recall why we chose to have this
facility in the first place. Do you (or anyone else)? I thought it was
to avoid unnecessarily having a writable directory within the chroot
jail, but we do have two other writable directories anyway:
%dir %attr(1770,root,named) %_chrootdir/var/run
%dir %attr(1770,root,named) %_chrootdir/var/tmp
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
