Fedora directory users - Jun 2006 - Re: New filesystem layout for directory server and admin server files

Richard Megginson <rmeggins@redhat.com> kirjoitti:
> --
> In order to be more linux friendly, we are currently considering changing
the layout from having everything under
> /opt/fedora-ds to putting files in their FHS specific paths
FHS has it''s place. However, as a very large user of this software, I
am strongly against this idea.

One of the biggest strengths of this software is that it is completely
self-contained, which allows much simpler troubleshooting, research and
development of administration tools, and testing multiple versions. It is easier
to see if a file is missing or has the wrong permissions, and fix it. It is
easier to backup and restore. I could go on and on. When an entire network
depends on the LDAP infrastructure, these type of things really matter.

I think this is a bad idea, and a waste of time. Time which could be much better
spent on bring proper autoconf support.


BR,
Mike

mj@sci.fi wrote:
> One of the biggest strengths of this software is that it is completely 
> self-contained, which allows much simpler troubleshooting, research and 
> development of administration tools, and testing multiple versions. It 
> is easier to see if a file is missing or has the wrong permissions, and 
> fix it. It is easier to backup and restore. I could go on and on. When 
> an entire network depends on the LDAP infrastructure, these type of 
> things really matter.
This is an argument for compiling critical binaries statically by 
default (something I wish Redhat would do with RPM, so that upgrading 
isn''t such a mission), but as to the filesystem layout, having a non
FHS
package on the system means I must partition my system differently just 
for FDS, which isn''t ideal.

I think it would be ideal to include the option for supporting both 
standalone and FHS, to keep everyone happy.

Regards,
Graham
--

Graham Leggett wrote:
> mj@sci.fi wrote:
>
>> One of the biggest strengths of this software is that it is 
>> completely self-contained, which allows much simpler troubleshooting, 
>> research and development of administration tools, and testing 
>> multiple versions. It is easier to see if a file is missing or has 
>> the wrong permissions, and fix it. It is easier to backup and 
>> restore. I could go on and on. When an entire network depends on the 
>> LDAP infrastructure, these type of things really matter.
>
> This is an argument for compiling critical binaries statically by 
> default (something I wish Redhat would do with RPM, so that upgrading 
> isn''t such a mission), but as to the filesystem layout, having a
non
> FHS package on the system means I must partition my system differently 
> just for FDS, which isn''t ideal.
Meaning you have to make /opt bigger, or on its own (large) partition.  
Note that a large FDS deployment will usually have to do a custom disk 
partition, in order to have the database files on a separate physical 
disk than the database transaction logs.  For a small deployment, it may 
not matter.

So are you saying that in a typical FHS deployment, the /var partition 
is by far the largest, and is on a separate partition than /?  If not, 
then it doesn''t make any difference - /opt is just as "bad"
as /var.
>
> I think it would be ideal to include the option for supporting both 
> standalone and FHS, to keep everyone happy.
We will most likely not go the route of having two separate packages, 
one /opt layout and one FHS layout.  This is just too much work to have 
to QA two packages for every OS/platform combination.  It''s also a lot 
of work for our documentation - it would either make the documentation 
really confusing by having to specify two different paths for 
everything, or create a lot more work by having two different doc sets.  
It seems the leading contender so far is to use the FHS layout for the 
"real" files, and have the /opt layout be mostly symlinks to 
files/directories in the FHS style layout.

Another option would be to allow the installer to specify the prefix.  
This is really frowned upon in RPM-land, but it may make sense for 
Fedora DS.  You would get the FHS style layout by default, but you could 
specify /opt/fedora-ds as the prefix, in which case you get the FHS 
style layout underneath /opt/fedora-ds.
>
> Regards,
> Graham
> -- 
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

On Mon, 2006-07-03 at 08:20, Richard Megginson wrote:
> So are you saying that in a typical FHS deployment, the /var partition 
> is by far the largest, and is on a separate partition than /?  If not, 
> then it doesn''t make any difference - /opt is just as
"bad" as /var.
If you didn''t plan out what you were going to deploy on the
machine in question there isn''t much reason to expect extra
space to be sitting around in one place more than any other.
That is, if you do have /var on a separate partition, you
probably planned the size for what you already have there.
And it''s probably easier to add /opt as a separate partition
than to move /var in a typical RH layout.
> We will most likely not go the route of having two separate packages, 
> one /opt layout and one FHS layout.
Moving locations is always traumatic.  Personally I like
stand-alone packages that aren''t going to be installed on
every machine you have to live under /opt, but if it is
ever going to move, do it soon to minimize the number of
people who will be affected by already having it installed
in the wrong place.

-- 
  Les Mikesell
   lesmikesell@gmail.com

Is all this partitioning stuff still being done ? I though it had
gone away once Linux aquired  decent filesystem capabilities.
I''ve installed probably 100 systems in the past few years,
all with one big partition for all the /var /usr /tmp etc trees.
If I want separate physical disks, I just call them /home2 /home3
or whatever and point the applications at those paths.
I can''t remember the last time I configured a system with
separate filesystems for /opt and /var

Recent Fedora Core releases default to one big partition
using LVM.

Am I smoking crack ?

> Is all this partitioning stuff still being done ? I though it 
> had gone away once Linux aquired  decent filesystem capabilities.
> I''ve installed probably 100 systems in the past few years, 
> all with one big partition for all the /var /usr /tmp etc trees.
> If I want separate physical disks, I just call them /home2 
> /home3 or whatever and point the applications at those paths.
> I can''t remember the last time I configured a system with 
> separate filesystems for /opt and /var
> 
> Recent Fedora Core releases default to one big partition using LVM.
> 
> Am I smoking crack ?
As someone who has to deal with high-security systems, user quotas,
databases, and several other fairly common things, I can tell you it
makes my life a hell of a lot easier to split a machines disk(s) into
separate filesystems.  You can''t put a quota on "/home", for
example, if
it''s just a part of one big giant "/".

You''ll also have a hard time mounting "/usr/bin" r/o if
it''s part of
"/".

There are a ton of reasons people still do this, and in my experience
it''s far more common to do it than not to.

On Mon, 2006-07-03 at 11:19 -0400, Morris, Patrick
wrote:
> > Is all this partitioning stuff still being done ? I though it 
> > had gone away once Linux aquired  decent filesystem capabilities.
> > I''ve installed probably 100 systems in the past few years, 
> > all with one big partition for all the /var /usr /tmp etc trees.
> > If I want separate physical disks, I just call them /home2 
> > /home3 or whatever and point the applications at those paths.
> > I can''t remember the last time I configured a system with 
> > separate filesystems for /opt and /var
> > 
> > Recent Fedora Core releases default to one big partition using LVM.
> > 
> > Am I smoking crack ?
> 
> As someone who has to deal with high-security systems, user quotas,
> databases, and several other fairly common things, I can tell you it
> makes my life a hell of a lot easier to split a machines disk(s) into
> separate filesystems.  You can''t put a quota on "/home",
for example, if
> it''s just a part of one big giant "/".
> 
> You''ll also have a hard time mounting "/usr/bin" r/o if
it''s part of
> "/".
> 
> There are a ton of reasons people still do this, and in my experience
> it''s far more common to do it than not to.
The current default is to span drives with LVM and spread everything
across it.  That''s a reasonable default for an installer that
can''t
know the machine''s intended use, but probably not the best choice
if you do.  Disk head motion is still the slowest common computer
operation and giving your most intense application it''s own drive(s)
is one of the best ways to improve performance.  I also like to
do software RAID1 mirrors of partitions for critical data so I could
recover data from any single drive after any kind of problem.

-- 
  Les Mikesell
    lesmikesell@gmail.com