Red Hat Bugzilla – Bug 165803
cimserver should not be running by default
Last modified: 2007-11-30 17:07:19 EST
Description of problem:
We don't normally make deamons run by default unless they are really essential.
Why is cimserver running by default in U2?
This impacts the security profile of the distribution since the daemon listens
on *:5989 by default.
(In reply to comment #1)
> Why is this package installed into /opt, unlike all the rest of the
Because all upstream tog-pegasus releases install into /opt, and there
are hundreds of references to /opt throughout the code.
It would be a major change to install tog-pegasus elsewhere, which would
also require applications using tog-pegasus that include references to /opt
to change also.
> It looks like this package has not gone through basic review.
What do you mean by "basic review" ? It has passed QA testing.
> - daemon is running by default, it really should not be
Yes, it should. If users decide to install tog-pegasus, then they
expect the daemon to be running.
> - installs into /opt, very bad -- completely non-standard packaging
Where is the "standard" defined ?
What is "bad" or non-functional about it ?
> (so trivial things like e.g. "man cimserver" don't even work)
# . /etc/profile
# man cimserver
cimserver - start or stop the CIM Server; display the version number of
the CIM Server
> - basic init script output is funky
Define "funky" . If you mean bug 165805, it is now fixed.
> - no separate of development package into -devel
There is the tog-pegasus-sdk package.
> - %post is *logging* the installation of the package? eww
Please clarify .
I can find no code in the %post script that invokes /usr/bin/logger or
generates log messages - except for the initscript condrestart that
is done if upgrading from an existing package.
> - %pre looks like is doing some migration thing, weird since we've never shipped
> a previous version
The %pre script will migrate an existing repository, IF it exists.
The .spec file is not specific to the first installation of a package;
it must also deal with cases where the package is being upgraded.
> - %post is creating symlinks for libraries which should be packaged.
The library symlinks are required to allow programs to link to generic
*.so names, rather than *.so.X.X... names.
> I'm sure the list will go on.
If you have any other issues with tog-pegasus, please let me know.
I can find no issue in the above list which constitutes a problem with the
correct functioning or operation of the tog-pegasus package.
Hence this bug is being closed as NOTABUG.
Another point to do with the title of this bug:
"cimserver should not be running by default"
I think it should be running by default, since the expected use of this package
is to control large installations of many machines which will probably be
installed in an automated manner (eg. with kickstart), and it would be a major
pain for administrators to have to log in to each client to enable the cimserver.
I don't think that the tog-pegasus package should be INSTALLED by default;
only users with a specific requirement for OpenPegasus WBEM/CIM support should
install this package.
I'll contact the anaconda team to see about getting tog-pegasus installed
Most of the rest of our upstream packages will install into /usr/local/* by
default. One of the basic values of making a Linux distribution is that you
package everything *consistently* rather than by "just what upstream does".
Should we install all our daemons into /usr/local because that's "just what
upstream does"? No. Likewise /opt. /opt is for third-party stuff. Once we
package ship it in RHEL core it's not third-party any more and we must apply Red
Hat packaging standards.
Using "-sdk" rather than "-devel" for the development headers is again
inconsistent with the rest of the distribution.
"installed" does not imply "daemon running by default", especially for
network-facing daemons which run as root. Users should be required to
"chkconfig tog-pegasus on" if they want it running.
Split off scriptlet issues to bug 165880.
*** Bug 165880 has been marked as a duplicate of this bug. ***
I thought this comment was added on Wednesday - I must not have pressed
the 'Save Changes' button :-(
After re-examining these issues, and those listed in Bug 163880,
they are now all fixed with the new tog-pegasus-2.4.1-2.rhel4 release,
I have run the tog-pegasus-test-2.4.1-2.rhel4.rpm on all supported platforms -
all tests passed.
These changes were made:
1. The tog-pegasus service is no longer enabled by default.
The %post script no longer does '/usr/lib/lsb/install_initrd tog-pegasus'
(chkconfig add), unless the package is installed with
"rpm --define 'AUTOSTART 1'" . I added the AUTOSTART
new .spec file variable, which is 0 by default, to enable
automatic enabling of the service when installed via kickstart.
2. tog-pegasus no longer installs into /opt .
I re-worked the .spec file and changed the hard-coded references to /opt
in the code .
Now, tog-pegasus installs into these directories:
/etc/Pegasus - configuration directory
/usr/sbin - daemons
/usr/bin - user programs
/var/run/tog-pegasus/ - pid file and socket file directory
(no more socket/ subdirectory!)
/var/lib/Pegasus - cache and repository data
/usr/lib - libraries
/usr/lib/Pegasus/providers - class provider libraries
/usr/share/Pegasus - Managed Object Files (mof), html, SDK samples,
/var/log/Pegasus - log files
If people have separate / and /usr partitions, / is likely to be small
and to contain /opt. It is probably better going forward to not ship
the package in /opt.
3. "sdk" subpackage renamed "devel".
devel subpackage now Provides the '*.so' library links, rather than
the main package creating them in %post
4. %postun no longer does any 'rm -rf'
5. no scriplet does any logging
6. Requires(post) tag added
7. BuildConflicts(tog-pegasus) tag added
(Package cannot be built if tog-pegasus package is installed)
8. All executables now built with ExecShield enabled
I think it would be better to start with shipping tog-pegasus-2.4.1-2.rhel4
rather than tog-pegasus-2.4.1-1 and I suggest we try to get it into the
RHEL-4-U2 Beta release.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.