Fedora directory users - Jul 2006 - FHS packaging - combine old and new with symlinks

As an attempt to compromise between the users who want the old layout 
and those who want an FHS style layout, I propose having the package do 
both.  That is, the files would be put on disk under /opt/fedora-ds, 
then symlinks would be created to those files and directories to 
correspond to the FHS layout.

For example, /var/log/fedora-ds/slapd-instance/access would just be a 
symlink to /opt/fedora-ds/slapd-instance/logs/access
or
/etc/fedora-ds/slapd-instance/dse.ldif would just be a symlink to 
/opt/fedora-ds/slapd-instance/config/dse.ldif

Rationale:
1) allows admins already familiar with fedora ds layout to continue to 
use current tools/processes (e.g. tar up contents/restore contents, 
which is much more difficult with FHS layout)
2) allows admins familiar with FHS to find files in familiar places

Richard Megginson wrote:
> As an attempt to compromise between the users who want the old layout 
> and those who want an FHS style layout, I propose having the package do 
> both.  That is, the files would be put on disk under /opt/fedora-ds, 
> then symlinks would be created to those files and directories to 
> correspond to the FHS layout.
> 
> For example, /var/log/fedora-ds/slapd-instance/access would just be a 
> symlink to /opt/fedora-ds/slapd-instance/logs/access
> or
> /etc/fedora-ds/slapd-instance/dse.ldif would just be a symlink to 
> /opt/fedora-ds/slapd-instance/config/dse.ldif
> 
> Rationale:
> 1) allows admins already familiar with fedora ds layout to continue to 
> use current tools/processes (e.g. tar up contents/restore contents, 
> which is much more difficult with FHS layout)
> 2) allows admins familiar with FHS to find files in familiar places

Hi,
  Sounds fine to me, just as long as nothing depends on those symlinks 
being present, e.g. start/stop scripts, backup/restore scripts, etc. For 
example, if one of my tools creates a new instance, but doesn''t symlink
it to the FHS place, that shouldn''t cause any lack of functionality.


BR,
Mike

Richard Megginson wrote:
> As an attempt to compromise between the users who want the old layout 
> and those who want an FHS style layout, I propose having the package do 
> both.  That is, the files would be put on disk under /opt/fedora-ds, 
> then symlinks would be created to those files and directories to 
> correspond to the FHS layout.
I have worked with systems that use symbolic links in similar capacities 
and usually find that in spite of having an understanding of symbolic 
links, I tend to get caught up in the iliusion that they are trying to 
create and do things that make sense in the illusory world but not in 
the real world.

For example copying /etc/named.conf to /etc/named.conf.bak before 
modifying it and then afterward discovering that /etc/named.conf and 
/etc/named.conf.bak are now both symbolic links to the same changed copy 
of the real file in /var/named/chroot/etc/named.conf.

I vote for either layout in preference to this proposed compromise.

But if pressed, my preference between FHS and /opt/fedora-ds would be 
for FHS.

-Mark Schwenk
  WellThot Inc.
  Helping buisnesses realize the value of free software
  http://wellthot.com/

Mark A. Schwenk wrote:
>
> For example copying /etc/named.conf to /etc/named.conf.bak before 
> modifying it and then afterward discovering that /etc/named.conf and 
> /etc/named.conf.bak are now both symbolic links to the same changed copy 
> of the real file in /var/named/chroot/etc/named.conf.
Which filesystem are you using?

Ext3:

# echo foobar > 1
# ln -s 1 2
# cp 2 3
# ls -al
-rw-r--r--  1 jacksonm users  7 Jul 17 22:17 1
lrwxrwxrwx  1 jacksonm users 10 Jul 17 22:18 2 -> 1
-rw-r--r--  1 jacksonm users  7 Jul 17 22:18 3


BR,
--
mike

Mike Jackson wrote:
> Mark A. Schwenk wrote:
> 
>>
>> For example copying /etc/named.conf to /etc/named.conf.bak before 
>> modifying it and then afterward discovering that /etc/named.conf and 
>> /etc/named.conf.bak are now both symbolic links to the same changed 
>> copy of the real file in /var/named/chroot/etc/named.conf.
> 
> 
> Which filesystem are you using?
> 
> Ext3:
> 
> # echo foobar > 1
> # ln -s 1 2
> # cp 2 3
> # ls -al
> -rw-r--r--  1 jacksonm users  7 Jul 17 22:17 1
> lrwxrwxrwx  1 jacksonm users 10 Jul 17 22:18 2 -> 1
> -rw-r--r--  1 jacksonm users  7 Jul 17 22:18 3
> 
> 
Ext3. Right you are. I was trying to quickly provide an example of how 
the symbolic links can bite back and didn''t think through it clearly.

How about this:

# mv /etc/named.conf /etc/named.conf.bak
# cp /etc/named.conf.bak /etc/named.conf

At this point /etc/named.conf.bak is a symbolic link to 
/var/named/chroot/etc/named.conf and /etc/named.conf is a regular file.

Then editing the /etc/named.conf file no longer modifies the real source 
file at /var/named/chroot/etc/named.conf.

-Mark Schwenk

Mark A. Schwenk wrote:
> Mike Jackson wrote:
>> Mark A. Schwenk wrote:
>>
>>>
>>> For example copying /etc/named.conf to /etc/named.conf.bak before 
>>> modifying it and then afterward discovering that /etc/named.conf
and
>>> /etc/named.conf.bak are now both symbolic links to the same changed
>>> copy of the real file in /var/named/chroot/etc/named.conf.
>>
>>
>> Which filesystem are you using?
>>
>> Ext3:
>>
>> # echo foobar > 1
>> # ln -s 1 2
>> # cp 2 3
>> # ls -al
>> -rw-r--r--  1 jacksonm users  7 Jul 17 22:17 1
>> lrwxrwxrwx  1 jacksonm users 10 Jul 17 22:18 2 -> 1
>> -rw-r--r--  1 jacksonm users  7 Jul 17 22:18 3
>>
>>
>
> Ext3. Right you are. I was trying to quickly provide an example of how 
> the symbolic links can bite back and didn''t think through it
clearly.
>
> How about this:
>
> # mv /etc/named.conf /etc/named.conf.bak
> # cp /etc/named.conf.bak /etc/named.conf
>
> At this point /etc/named.conf.bak is a symbolic link to 
> /var/named/chroot/etc/named.conf and /etc/named.conf is a regular file.
>
> Then editing the /etc/named.conf file no longer modifies the real 
> source file at /var/named/chroot/etc/named.conf.
That''s bad, and exactly what would/could happen with my proposal.  Even
if we swap the direction of the symlinks, it would still break in the 
other way i.e. if you tried to do the same thing under 
/opt/fedora-ds/slapd-instance/config - and if you tried to 
backup/restore with tar, you would either be getting only the symlinks, 
or if following symlinks, they would be broken upon restore.

So, is there a way to have both?  If not symlinks, then
what?
>
> -Mark Schwenk
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Richard Megginson wrote:
> That''s bad, and exactly what would/could happen with my proposal. 
Even
> if we swap the direction of the symlinks, it would still break in the 
> other way i.e. if you tried to do the same thing under 
> /opt/fedora-ds/slapd-instance/config - and if you tried to 
> backup/restore with tar, you would either be getting only the symlinks, 
> or if following symlinks, they would be broken upon restore.
> 
> So, is there a way to have both?  If not symlinks, then what?
I don''t think there is a way to have both that doesn''t create
more
problems that it solves.  If moving to FHS right now doesn''t have lots 
of clear advantages, perhaps things should stay as they are and energies 
  more fruitfully applied to other issues.

-Mark Schwenk

On Mon, 2006-07-17 at 15:52 -0600, Richard Megginson wrote:
> > Then editing the /etc/named.conf file no longer modifies the real 
> > source file at /var/named/chroot/etc/named.conf.
> That''s bad, and exactly what would/could happen with my proposal. 
Even
> if we swap the direction of the symlinks, it would still break in the 
> other way i.e. if you tried to do the same thing under 
> /opt/fedora-ds/slapd-instance/config - and if you tried to 
> backup/restore with tar, you would either be getting only the symlinks, 
> or if following symlinks, they would be broken upon restore.
> 
> So, is there a way to have both?  If not symlinks, then what?
> >
If the FHS layout is used, but all of the actual directory data winds up
under something like /var/lib/fedora-ds/<instance-name>/,
wouldn''t that
suffice for making backup/restores easy and the like?  Maybe there would
also be a corresponding /etc/fedora-ds/<instance-name> directory for
config files and such, but the actual DBs under /var.  I normally don''t
worry too much about backing up executables and libraries that are just
stock RPMs as I can always recreate that portion of the environment.
The data is certainly the other story.

-- 
David Hollis <dhollis@davehollis.com>