cvs commit: src/etc Makefile

[Brian Somers]

On Thu, 7 Oct 2004 10:19:22 +0300, Ruslan Ermilov <ru at FreeBSD.org> wrote:
> Hi Brian,
> 
> On Thu, Oct 07, 2004 at 07:52:45AM +0100, Brian Somers wrote:
> > On Wed, 6 Oct 2004 23:45:41 +0300, Ruslan Ermilov <ru at freebsd.org> wrote:
> > > On Tue, Oct 05, 2004 at 11:02:04PM +0100, Brian Somers wrote:
> > > > On Tue, 5 Oct 2004 20:20:56 +0300, Ruslan Ermilov <ru at freebsd.org> wrote:
> > > > > > Shouldn't this be:
> > > > > > 
> > > > > >     ln -fhs ../var/named/etc/namedb ${DESTDIR}/etc/namedb
> > > > > > 
> > > > > No.
> > > > 
> > > > If I mount an alternate filesystem hierarchy somewhere, isn't it a bit
> > > > useless/dangerous for symlinks to point outside of it?
> > > > 
> > > Please explain in more detail, I don't get it.  (There are several
> > > symlinks already exist in /etc, and most of them are absolute.)
> > 
> > Well, it looks like there's rmt -> /usr/sbin/rmt and termcap ->
> > /usr/share/misc/termcap.  I'd vote for making these relative too ;*)
> > 
> > I don't think these are as important as it's pretty rare that a person
> > needs to change /etc/termcap these days, and even more rare that they
> > would want to change /etc/rmt.
> > 
> > People with removable disks might want to configure them on one system
> > and then attach them to another, and part of that configuration might
> > be to set up a nameserver.  It would be an easy mistake to change
> > /mnt/etc/namedb/named.conf, ship the disk, then find out that you've
> > just broken the machine you configured from...
> > 
> There's a chicken and egg problem with relative symlinking that uses
> "..".  While having it relative would "fix" an issue that you mention
> above, it will equally create a problem if one has /etc as a symlink
> to some other directory, not necessarily one-level deep from root.
> Let's don't go this road again and again.  We've learned the hard way
> (with /usr/lib symlinks to /lib, please see bsd.lib.mk commit logs for
> details) that relative symlinking that uses ".." is generally a bad
> idea, and that it should only be used when we're confident that
> resolving ".." will give us a sane path.  Out of 798 system symlinks
> on a 5.x box here, 602 use relative ".." symlinking, but they are all
> safe:
> 
> 	/usr/share/locale/*/* (559 symlinks)
> 	/usr/share/man/en.ISO8859-1/man*
> 	/usr/share/nls/*/*
> 	/usr/share/openssl/man/en.ISO8859-1/man*
> 
> I currently don't like the idea of making /etc symlinks relative
> using ".." very much.

Well, I guess the ``clueful admin'' will have one of three opinions:

a)  If you're going to move something and re-symlink it, you'd better
    ``find something -type l'' and deal with the [relative] output.
b)  All symlinks should be absolute otherwise moving a directory that
    contains symlinks doesn't work.
c)  All symlinks should be next up against the wall when the revolution
    comes.

Personally, I'm with Peter.  Symlinks are just broken, and moving a
directory hierarchy to another place and symlinking it to fool the rest
of the world is something you'll learn to be sorry you did!

I'm not someone that usually whinges (hey, bind 8->9 is something that's
well worth the trauma), but I think we've got to be really careful with the
early adopters of RELENG_5.  IMHO we'd be better to say ``manually move
your DNS config to /var/named/etc/namedb or change named_flags'' in UPDATING
and just leave things alone, so that when people ``forget'' to read UPDATING
and reboot their machine, they can wait the 2 minutes for sshd to fail to
resolve their from address and go and do what UPDATING says.

-- 
Brian <brian at Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
      <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !