Couple related issue around the generated db2* and similar scripts in /usr/lib{,64}/dirsrv/slapd-%{instance}.
- Can these be recreated easily without messing with an otherwise working instance?
- I think this is a bad location to put generated files. I would suggest /var/lib/dirsrv/slapd-%{instance}/bin instead. The use of /usr seems to violate the FHS:
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.
On 11/20/2012 11:21 AM, Orion Poplawski wrote:
Couple related issue around the generated db2* and similar scripts in /usr/lib{,64}/dirsrv/slapd-%{instance}.
- Can these be recreated easily without messing with an otherwise working
instance?
running setup-ds.pl --update seemed to do the trick.
On 11/20/2012 11:21 AM, Orion Poplawski wrote:
Couple related issue around the generated db2* and similar scripts in /usr/lib{,64}/dirsrv/slapd-%{instance}.
- Can these be recreated easily without messing with an otherwise
working instance?
- I think this is a bad location to put generated files. I would
suggest /var/lib/dirsrv/slapd-%{instance}/bin instead. The use of /usr seems to violate the FHS:
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.
Right. We want to get rid of these instance specific scripts - https://fedorahosted.org/389/ticket/528
389-users@lists.fedoraproject.org