Re: [Fedora-directory-users] 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.
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.
389-users@lists.fedoraproject.org
-
David Boreham -
Graham Leggett -
Les Mikesell -
Mike Jackson -
Morris, Patrick -
Rich Megginson