[Bug 576839] Review Request: bdii - The Berkeley Database Information Index (BDII)

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=576839

--- Comment #4 from Mattias Ellert <mattias.ellert at fysast.uu.se> 2010-04-06 07:50:04 EDT ---
(In reply to comment #1)
> Just a suggestion at the moment.
> 
> Can the bdii be made to run as user bdii or whatever.

The default configuration from upstream is to run as user ldap.

> Also same comment as glue-schema about the tags rather than trunk in 
> the svn path if possible.

For the bdii there are important fixes in trunk, especially w.r.t. having
consistent licensing information in the sources, so using the old tag was not
possible. There is however a new tag (5.1.0) available now, and I have based
the new version on this one.

(In reply to comment #2)
> This looks more fundamental:
> 
> install package.
> 
> 1) /etc/rc.d/init.d/bdii status
>  /etc/rc.d/init.d/bdii status
> BDII Stopped                                               [  OK  ]
> 
> gives an extra blank line and status code of 0

The extra blank lines are fixed in the new version, I have sent the patch
upstream. The patch also fixes the status code (is now 3).

> 2) # service bdii start
> Starting SLAPD: SLAPD failed to start                      [FAILED]
> 
> /usr/sbin/slapd -f /etc/bdii/bdii-slapd.conf -h ldap://localhost:2170 -u ldap
> -d 256
> @(#) $OpenLDAP: slapd 2.4.19 (Feb 24 2010 09:09:19) $
> 
> mockbuild at x86-07.phx2.fedoraproject.org:/builddir/build/BUILD/openldap-2.4.19/openldap-2.4.19/build-servers/servers/slapd
> daemon: bind(7) failed errno=13 (Permission denied)
> daemon: bind(7) failed errno=13 (Permission denied)
> slapd stopped.
> connections_destroy: nothing to destroy.

The new version has the necessary SELinux management in the RPM scriptlets to
allow the service to run.

> running the startup with "-x" includes amongst others things.
> 
> + chown -R ldap:ldap /var/run/bdii/db
> + sudo -u ldap rm -f /var/run/bdii/db/stats/DB_CONFIG
> + sudo -u ldap rm -f /var/run/bdii/db/glue2/DB_CONFIG
> + sudo -u ldap rm -f /var/run/bdii/db/DB_CONFIG /var/run/bdii/db/glue2
> /var/run/bdii/db/stats
> + sudo -u ldap rm -f /var/run/bdii/old.ldif
> + sudo -u ldap cp /etc/bdii/DB_CONFIG /var/run/bdii/db
> 
> 
> yikes!!    

(In reply to comment #3)
> I probably should have been slightly more verbose than "yikes" in my previous
> comments.
> 
> These chowns and sudos look to be working around the files not being owned
> by user ldap in the first place, can they be marked as owned by ldap in
> the first place. I realise the init.d script will need some rewriting.
> More over I think the "ldap" user is already used to such an important
> degree serving quite possibly NSS information that running the bdii as a new
> user , presumably bdii makes sense.

The FHS says about /var/run: "This directory contains system information data
describing the system since it was booted. Files under this directory must be
cleared (removed or truncated as appropriate) at the beginning of the boot
process." So any directory hierarchy inside /var/run must be recreated in the
startup script, since it could in principle disappear at reboot, if e.g.
/var/run is configured as a tmpfs.

New version:

Spec URL: http://www.grid.tsl.uu.se/review/bdii.spec
SRPM URL: http://www.grid.tsl.uu.se/review/bdii-5.1.0-1.fc12.src.rpm

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.