[Fedora-directory-users] New filesystem layout for directory server and admin server files

[Richard Megginson]

mj at sci.fi wrote:
> Les Mikesell <lesmikesell at gmail.com> kirjoitti:
>>
>>
>> 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.
>
>
> As FDS is the basis of a commercial product, RHDS, let's talk about 
> the commercial aspect for a moment. Things which are changed in FDS 
> will eventually go into RHDS. There are already folks with lots of 
> RHDS servers deployed or being deployed into commercial environments. 
> We are already talking about a large number of installations.
>
> One of the reasons why I argue so strongly to use RHDS in commercial 
> environments is that it includes all dependencies in an isolated 
> manner, and doesn't change interfaces often. IMO, those features make 
> it currently the most suitable server for commercial usage.
But there are a lot of people for whom this is a problem.  For example, 
we ship 3 versions of NSPR, NSS, LDAP C SDK, ICU, etc.  that are private 
to RHDS.  In addition, we ship our own versions of bdb, cyrus sasl, 
netsnmp, and other software that are in most cases identical to what is 
already included or available for the OS.  To remedy this situation, we 
are going to switch FDS/RHDS to build and run against those OS 
libraries, and to not include them in the DS package.  So we are already 
committed to not including all of the dependencies in an isolated 
manner.  This change will affect the linux and solaris ports.  I'm not 
sure how it will affect the HP-UX port.  HP already takes our software 
and repackages it in the HP-UX depot format.

In general, we need to use one copy of the software, and the software 
should be forward and backward compatible.  We have this assurance with 
NSPR, NSS, and mozldap (since it's under our control :-), so if we need 
to update NSS on the system to fix a security problem or introduce some 
new functionality, we can do so with a very high degree of assurance 
that we will not break any existing apps that dynamically link with 
those NSS libs we are replacing.

One way we will be able to mitigate this situation is to allow the use 
of local, isolated libraries.  For example, let's say that we do go the 
FHS route.  All of the library dependencies will be in /usr/lib - nspr, 
nss, mozldap, icu, bdb, netsnmp, sasl.  FDS/RHDS will have a private lib 
directory in /usr/lib/fedora-ds (or /usr/lib/redhat-ds).  We will build 
the software in such a way that you could put a private copy of e.g. 
mozldap in /usr/lib/fedora-ds that the server will use without affecting 
the rest of the software in the system.

Finally, if/when we do change the layout, we will be providing migration 
tools to make upgrades as seamless as possible.
>
> To the people who are complaining about the filesystem layout, 
> understand that FDS is the basis for a complex and _stable_ commercial 
> product. You don't just start fiddling with it if it ain't broken... 
> Moving to FHS is certainly not going to increase sales or product 
> stability, although it might make a few systems engineers who have 
> never heard of RFC 2251 happy for a day or two.
I think it is an orthogonal issue to RFC2251.  A lot of people in the 
linux community have certain assumptions about where to find software, 
config, log files, etc.  This is the market in which we now find 
ourselves - FDS being used as a NOS directory for linux - hence a lot 
more requests for features like out-of-the-box support for POSIX, NIS, 
automount, samba, etc.  And support for FHS, since that is what the 
other linux NOS directory server (openldap) uses, as well as other 
related software such as autofs, nis, pam, etc.

In the past (i.e. Netscape/iPlanet), most of our customers were very 
large enterprises which used our DS for portals, mail servers, PKI, etc. 
and just figured out how to make it work for their NOS apps.  These 
types of customers typically didn't really care where the software was 
installed as long as it was easy to manage, since none of the other 
large enterprise software had any consistency about where it was installed.
>
> Or am I wrong to assume that these type of proposed changes would also 
> make it into RHDS?
You are correct - RHDS is the downstream for FDS, and there is no way we 
would be able to make a drastic change like this to FDS without RHDS 
picking it up.

As far as doing FHS for explicit business reasons - the same could be 
said about RPM packaging - we added support for RPMs when we already had 
a good package with installer.

>
> -- 
> mike
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20060703/9b4c22b8/attachment.bin>