Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 176452 - Review Request: oddjob - a D-BUS service which runs odd jobs on behalf of client applications
Summary: Review Request: oddjob - a D-BUS service which runs odd jobs on behalf of cli...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jef Spaleta
QA Contact: David Lawrence
Depends On:
Blocks: FE-ACCEPT 179154
TreeView+ depends on / blocked
Reported: 2005-12-22 22:40 UTC by Nalin Dahyabhai
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-03-10 20:35:33 UTC
Type: ---

Attachments (Terms of Use)

Description Nalin Dahyabhai 2005-12-22 22:40:58 UTC
Spec Name or Url:
SRPM Name or Url:

Description: A method for running privileged applications on behalf of unprivileged clients.  Clients issue requests to oddjobd over the system message bus (D-BUS).  In addition to access controls provided by D-BUS, the oddjobd server provides an ACL facility to control who can issue requests for helpers.

Comment 1 Jef Spaleta 2006-01-06 07:32:11 UTC
This isn't compiling correctly under mock against development.
build.log reports:

checking for mount... /bin/mount
checking for umount... /bin/umount
checking ldap.h usability... no
checking ldap.h presence... no
checking for ldap.h... no
configure: error: Could not locate LDAP headers.
error: Bad exit status from /var/tmp/rpm-tmp.13491 (%build)


Comment 2 Nalin Dahyabhai 2006-01-06 20:35:05 UTC
Build failure under mock is fixed in 0.21-2, in the same location.

Comment 3 Jef Spaleta 2006-01-06 21:59:40 UTC
Okay it builds in mock I'll start the formal review this evening.
A couple of small questions about the build.log

There is a check for xmlto which fails. Is this spurious or does this represent
some sort of optional functinality which could be turned on if xmlto was one of
the buildrequires? 

There is also a check for gfortran, is that just buildtime noise or would there
be something fortran specific that would be built if gfortran was available at
build time?

Comment 4 Nalin Dahyabhai 2006-01-06 22:27:38 UTC
xmlto is used to convert the doc from xml to html if it's available, but there's
an already-formatted copy which is used if xmlto isn't found.

The check for gfortran must be noise -- there's nothing in there that would use
it if it were found.

Comment 5 Jef Spaleta 2006-01-07 16:29:54 UTC
Looking over the specfile some more in context to the Packaging Guidelines...
<spec quote>
BuildPrereq: dbus-devel >= 0.22, libselinux-devel, libxml2-devel
BuildPrereq: pam-devel, python-devel
BuildPrereq: cyrus-sasl-devel, krb5-devel, openldap-devel
Prereq: /sbin/chkconfig
Should the BuildPrereq tags be replaced with BuildRequires?

And should the Prereq for chkconfig in the scriptlets be cast as a pair of tags:
Requires(pre) Requires(post) since its called in both pre and post scriptlets?

And since you also use /sbin/service in the preun script don't you also need a
Requires(pre): /sbin/service ?

rpmlint on mock built packages returns with what looks like spurious errors:

rpmlint oddjob-0.21-2.i386.rpm
  E: oddjob executable-marked-as-config-file /etc/rc.d/init.d/oddjobd
  W: oddjob incoherent-init-script-name oddjobd
rpmlint oddjob-devel-0.21-2.i386.rpm
  W: oddjob-devel no-documentation
rpmlint oddjob-libs-0.21-2.i386.rpm
  returns clean


Comment 6 Nalin Dahyabhai 2006-01-09 16:15:50 UTC
Okay, I've updated to 0.21-3 with these changes, same location as before.  Thanks!

Comment 7 Rudolf Kastl 2006-01-10 04:51:05 UTC
so actually if xmlto is added the docs are newly generated? i am not sure whats
the best way to go there then. regenerate the docs to be sure they match and
work properly... or use the prebuilt ones. just a thought ;)

Comment 8 Nalin Dahyabhai 2006-01-10 13:40:56 UTC
The only difference that they should ever have is due to different stylesheets
-- the make rules should guarantee that.  But I supposed the package could pass
"--disable-xml-docs" to avoid even trying.  Opinions?

Comment 9 Jef Spaleta 2006-01-13 18:00:47 UTC
Sorry for the delay, I should be able to pick this backup this evening and get
further along on the mandatory review items.


Comment 10 Jef Spaleta 2006-01-13 18:02:42 UTC
uhm i dont actually see 0.21-3 at
Can you clarify where 0.21-3 is so I can grab it this evening?


Comment 11 Chris Chabot 2006-01-13 18:13:45 UTC
After venturing a guess i found it for you, it's in (without the extras) :-)

Comment 12 Jef Spaleta 2006-01-15 23:53:03 UTC
Formal Review Summary for 0.21-3:
No blockers according to the review guidelines.
But I haven't tested the intended functionality beyond checking that the service
script starts and stops correctly.  I'd like to test the provided sample, but
I'm sure I completely understand how to test it based on the text provided at

I'll start a 48 hour clock on this approval. If someone is intereested in taking
the provided sample configuration in the docs for a spin and wants to report
back in the meantime please go ahead. 

Full Review:
- GOOD: rpmlint must be run on every package. The output should be posted in the
all messages appear bogus
rpmlint oddjob-0.21-3.i386.rpm
E: oddjob executable-marked-as-config-file /etc/rc.d/init.d/oddjobd
W: oddjob incoherent-init-script-name oddjobd
rpmlint oddjob-devel-0.21-3.i386.rpm
W: oddjob-devel no-documentation
rpmlint oddjob-libs-0.21-3.i386.rpm
(no output)

- GOOD: The package is named according to the PackageNamingGuidelines.
- GOOD: The spec file name matches the base package %{name}, in the format
- GOOD: The package meets the PackagingGuidelines.
- GOOD: The package is licensed BSD 
- GOOD: The License field in the package spec file matches the actual license.
- GOOD: If (and only if) the source package includes the text of the license(s)
in its own file, then that file, containing the text of the license(s) for the
package must be included in %doc.
- GOOD: The spec file must be written in American English.
- GOOD: The spec file for the package MUST be legible. If the reviewer is unable
to read the spec file, it will be impossible to perform a review. Fedora Extras
is not the place for entries into the Obfuscated Code Contest ([WWW]
- GOOD: The sources used to build the package must match the upstream source
105265e2cdf9f2370373ee5432a5b4cd  oddjob-0.21-1.tar.gz
- GOOD: The package must successfully builds on fedora-core-development i386 in mock
- GOOD: A package does not contain any BuildRequires that are listed in the
exceptions section of PackagingGuidelines.
- GOOD: All other Build dependencies are listed in BuildRequires.
- GOOD: No locale files. 
- GOOD: libs subpackage has correct post/postun scriplets
- GOOD: not designed to be relocatable, 
- GOOD: All the directories created in all subpackages are owned.
- GOOD: A package must not contain any duplicate files in the %files listing.
- GOOD: Permissions on files must be set properly. Executables should be set
with executable permissions, for example. Every %files section must include a
%defattr(...) line.
- GOOD: Each package must have a %clean section, which contains rm -rf
%{buildroot} (or $RPM_BUILD_ROOT).
- GOOD: Each package must consistently use macros, as described in the macros
section of PackagingGuidelines.
- GOOD: The package must contain code, or permissable content. This is described
in detail in the code vs. content section of PackagingGuidelines.
- GOOD: no Large documentation files. 
- GOOD: If a package includes something as %doc, it must not affect the runtime
of the application. To summarize: If it is in %doc, the program must run
properly if it is not present.
- GOOD: Header files or static libraries must be in a -devel package.
- GOOD: Files used by pkgconfig (.pc files) must be in a -devel package.
- GOOD: If a package contains library files with a suffix (e.g.,
then library files that end in .so (without suffix) must go in a -devel package.
- GOOD: In the vast majority of cases, devel packages must require the base
package using a fully versioned dependency.
- GOOD: Packages must NOT contain any .la libtool archives, these should be
removed in the spec.
- GOOD: No GUI applications 
- GOOD: Packages must not own files or directories already owned by other packages.

Comment 13 Nalin Dahyabhai 2006-01-16 19:34:33 UTC
As you've noted, the sample configurations provided under /usr/share/doc are for
a not-particularly-useful sample service.

The sample script (usr/lib/oddjob/ is configured for oddjobd
(etc/oddjobd.conf.d/oddjobd-sample.conf) and the system-wide copy of D-BUS
(etc/dbus-1/system.d/oddjob-sample.conf).  (Uncovered a bug in the default
sample here, fixed it in 0.22).

After installation of these files, a restart of both the messagebus and oddjobd
services will be required to make both daemons reread their respective

That done, a client can invoke the service using either:
  oddjob_request -s com.redhat.oddjob.sample -o /com/redhat/oddjob/sample -i
com.redhat.oddjob.sample sample
or, using the more standard D-BUS client tool:
  dbus-send --system --print-reply --dest=com.redhat.oddjob.sample
/com/redhat/oddjob/sample com.redhat.oddjob.sample.sample

The script indicated in the configuration will be run with superuser privileges,
and the client will receive its exit status and whatever it output to stdout and

Comment 14 Jef Spaleta 2006-01-17 20:27:00 UTC
(In reply to comment #13)
> (Uncovered a bug in the default
> sample here, fixed it in 0.22).

Let me roll up binaries of 0.22 and make sure the sample works as you describe
and I will then approve 0.22 for cvs import.


Comment 15 Jef Spaleta 2006-01-27 21:58:03 UTC
Sorry real life caught up with me this week.  I'll be looking at finishing this
review up this weekend.


Comment 16 Nalin Dahyabhai 2006-01-27 23:15:21 UTC
No worries.  I've been tweaking the build setup and code so that they'll build
with the version of dbus in FC3 and RHEL4 if a certain piece of SELinux-specific
functionality which I really, really want gets backported.  I'll have 0.23 up in
the usual places soonish.

Comment 17 Jef Spaleta 2006-02-25 19:39:56 UTC
Okay sorry it took so long. Marking this as APPROVED for FE devel

I just built local binaries of 0.23 under mock against the development trees. No
important changes in the spec file since 0.22 that need review
and the md5sums in the 0.23 src.rpm match the upstream source md5sum
df4a8c74dc972ede3c829b42da388f1b  oddjob-0.23-1.tar.gz

Once i move the example configs over to the system locations   
the example command in comment #11 appears to work as i expect. 

As an aside, this looks like a very good tool for sysadmins, but I think there
will need to be a little more polish associated with the documentation and
perhaps another example or two to help people walk through getting more familiar
with scripting dbus actions through oddjob

Back to the provided example
as user:
oddjob_request -s com.redhat.oddjob.sample -o /com/redhat/oddjob/sample -i
com.redhat.oddjob.sample sample
com.redhat.oddjob.Error.ACL: ACL does not allow access

as root
oddjob_request -s com.redhat.oddjob.sample -o /com/redhat/oddjob/sample -i
com.redhat.oddjob.sample sample
Error org.freedesktop.DBus.Error.SELinuxSecurityContextUnknown: Could not
determine security context for ':1.3'.
uid=0(root) gid=0(root) groups=0(root)
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0    136   7588  34068 205392    0    0   160    67  169   401 10  3 84  3


Comment 18 Nalin Dahyabhai 2006-03-06 19:37:45 UTC
Okay, the build system seems to like 0.24 (0.23 didn't quite build against FC3,
and it's my intention to keep it building with releases of D-BUS which are that
old, all the way up to 1.0).  Once the packages show up on the public servers,
I'll go ahead and mark this as resolved with resolution NEXTTRELEASE.

Comment 19 Michael Schwendt 2007-02-14 10:26:39 UTC
The circular dependency between the main package and the -libs package
is odd. The main package has an implicit dependency on the library
SONAME in the -libs package. The -libs package has an explicit dependency
on the main package. The initial import (tagged oddjob-0_23-1) has an
indirect dependency from the -devel package to the main package and
from there to the -libs package via the automatic SONAME dep. Instead,
it should have been just -devel requires -libs, not -devel requires
main package and not -libs requires main package.

Note You need to log in before you can comment on or make changes to this bug.