Bug 428643

One important Q. here!

"Do we expect users to send messages between sysklogd and rsylog?"

If yes, than will need to patch rsyslog and it will change it's default 
message format. It means rsyslog(RHEL) != rsyslog(Fedora) || rsyslog(Upstream)

c #250628, there is workaround.
IMHO: we should keep the current rsyslog message format.

Ooops I see there is:
Provides: syslog
Provides: sysklogd = 1.4.3-1
Obsoletes: sysklogd < 1.4.3-1
Conflicts: syslog-ng
I think we should erase:
--Provides: sysklogd = 1.4.3-1
--Obsoletes: sysklogd < 1.4.3-1

Right, "Obsoletes: sysklogd < 1.4.3-1" would change user's daemon unexpectedly.

AFAICS there should be a "Conflicts: sysklogd", but I dont' know whether this
could cause problems with the installer (is there an "install all" option that
would be broken by the Conflicts?).  Has anyone checked there are no packages in
RHEL5 that directly "Requires: sysklogd"?

Upgrades and installs will definitely need to be thoroughly tested, both using
sysklogd and rsyslog.

Please fix:
* URL in Source0 doesn't work; use
  http://download.rsyslog.com/rsyslog/rsyslog-1.19.11.tar.gz instead
* rsyslog-mysql owns /usr/lib/rsyslog/ommysql.so, but nothing owns
  /usr/lib/rsyslog.  I think it should be owned by the main package.
* Instead of "Requires: logrotate" and "Conflicts: logrotate < 3.5.2",
  use "Requires: logrotate >= 3.5.2".
* The package documentation should not include INSTALL and doc/Makefile*
* Requires(preun) contains /sbin/chkconfig twice; one of them should be
  /sbin/service.

Some cleanups:
* "Requires: logrotate" is repeated twice
* Provides: sysklogd twice, once versioned, once unversioned!

* rpmlint output:
| rsyslog.i386: W: dangerous-command-in-%post mv
OK if the package conflicts with sysklogd
| rsyslog.i386: W: service-default-enabled /etc/rc.d/init.d/rsyslog
OK, this is a rather important service ;)

Regarding comment #1, maybe a note should be put in the BUGS section of the man
page? If its documented as a problem with a workaround, then people can help
themselves.

There are 2 more packages besides sysklogd that needs to be changed in order to
put conflict between sysklogd and rsyslog, namely:
vixie-cron
initscripts
according to:
repoquery --whatrequires --alldeps sysklogd
initscripts-0:8.45.14.EL-1.s390x
vixie-cron-4:4.1-70.el5.s390x
sysklogd-0:1.4.1-40.el5.s390x
initscripts-0:8.45.17.EL-1.s390x
vixie-cron-4:4.1-66.1.el5.s390x
sysklogd-0:1.4.1-39.2.s390x
vixie-cron-4:4.1-72.el5.s390x

sysklogd doesn't have to be changed - it will conflict anyway. And the
initscripts and vixie-cron contain requires syslog not sysklogd, so no problem
with them either.

repoquery --whatrequires sysklogd
is what interests us, not --alldeps.

With respect to comment #1, changing the message format *in a RHEL update* seems
to be a shockingly bad idea. We're intending to obsolete sysklogd, right?

No, sysklogd stays in the distribution.

OK, so:

Anyone who installs a package that just requires 'syslog' is going to get
rsyslog instead of sysklogd, which could be considered a behavior change.

Anyone who does a kickstart install with @Everything or '*' in %packages will
very likely have a failed install due to file conflicts (anaconda treats this as
a fatal transaction error.)

Do we really want either of these two behaviors?

Why are we doing this in a RHEL update anyway? Either it's good enough for
everyone and we keep it compatible, or we tell those who need more features to
wait for RHEL 6. We do not want to be making each RHEL update a new major release.

Reviewing rsyslog-2.0.0-1 (posted out-of-band):
* /Requires(preun)/s,/sbin/services,/sbin/service,


> Anyone who installs a package that just requires 'syslog' is going to get
> rsyslog instead of sysklogd, which could be considered a behavior change.
(Could this be "fixed" by renaming the rsyslog package to something longer than
sysklogd?)

> Anyone who does a kickstart install with @Everything or '*' in %packages will
> very likely have a failed install due to file conflicts (anaconda treats this as
> a fatal transaction error.)
I was afraid of that.

Could this work?
* Remove the Conflicts:
* Change init.d/rsyslog not to start the service by default
* Remove the configuration file migration from %post, or at least copy
  the configuration files instead of moving them
AFAICS rsyslog and sysklogd would be parallel-installable, and the user could
switch between them manually using chkconfig (and migrating the configuration)

(In reply to comment #11)
> (Could this be "fixed" by renaming the rsyslog package to something longer than
> sysklogd?)

It *could*, although then you'll have the whole namespace issues on upgrades to
RHEL 6 later, including problems with package counting for %post/%pre/%postun
script purposes (it's installed, but the normal scriptlet counting checks won't
work because it's a different name.) That being said, naming it
'arrrrrrrrsyslog' would be entertaining.

> > Anyone who does a kickstart install with @Everything or '*' in %packages will
> > very likely have a failed install due to file conflicts (anaconda treats this as
> > a fatal transaction error.)
> I was afraid of that.
> 
> Could this work?
> * Remove the Conflicts:
> * Change init.d/rsyslog not to start the service by default
> * Remove the configuration file migration from %post, or at least copy
>   the configuration files instead of moving them
> AFAICS rsyslog and sysklogd would be parallel-installable, and the user could
> switch between them manually using chkconfig (and migrating the configuration)

logs would be double-rotated if both were installed.

(In reply to comment #9)
> Anyone who does a kickstart install with @Everything or '*' in %packages will
> very likely have a failed install due to file conflicts (anaconda treats this as
> a fatal transaction error.)

This is a behavior that we've very much tried to avoid historically.  As much as
we don't *like* people doing everything installs, they do them.  And we're not
going to magically make that stop, especially not in RHEL5 where there's still
the kludge for @Everything compatibility.

(In reply to comment #12)
> > Could this work?
> > * Remove the Conflicts:
> > * Change init.d/rsyslog not to start the service by default
> > * Remove the configuration file migration from %post, or at least copy
> >   the configuration files instead of moving them
> > AFAICS rsyslog and sysklogd would be parallel-installable, and the user 
could
> > switch between them manually using chkconfig (and migrating the 
configuration)
> 
> logs would be double-rotated if both were installed.
> 

What if we use same logrotate file and pid filename as sysklogd. Same 
situation used to be in Fedora with syslog-ng.

Update!
Spec URL: 
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog.spec

SRPM URL: 
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog-2.0.0-2.fc7.src.rpm

2.0.0-2:
* The removal of (chkconfig --add) is incorrect - change the run levels
  in rsyslog.init instead:
> rsyslog.i386: E: postin-without-chkconfig /etc/rc.d/init.d/rsyslog
> rsyslog.i386: W: service-default-enabled /etc/rc.d/init.d/rsyslog


> What if we use same logrotate file and pid filename as sysklogd. Same 
situation used to be in Fedora with syslog-ng.

No objection from me - can I assume you have tested this, made sure that it
works, the two packages don't conflict and e.g. removing one package won't
remove the logrotate file even if the other package is left installed?

Please also test "yum upgrade" when rsyslog/sysklogd is installed and the other
package is not; ISTR some versions of rpm are treating Provides: as an implicit
Obsoletes:.

fixed, tested(not yum upgrade).

Spec URL: 
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog.spec

SRPM URL: 
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog-2.0.0-3.fc7.src.rpm

Oops, logrotate file wasn't renamed in -3.

Spec URL: 
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog.spec

SRPM URL: 
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog-2.0.0-4.fc7.src.rpm

-4 looks fine to me.

* Tested:
  (rpm -Uvh rsyslog*) when sysklogd is installed,
  (rpm -Uvh sysklogd*) when rsyslog is installed,
  (rpm -Uvh sysklogd* rsyslog*) when neither is installed,
  - Verification reports
    .......T c /etc/logrotate.d/syslog
* Tested corresponding package removals
  NOTE! Uninstalling sysklogd stops rsyslog.
* Tested the postrotate script in /etc/logrotate.d/syslog restarts rsyslogd
* Tested that yum doesn't "upgrade" from sysklogd to rsyslog nor vice versa

Just to be sure - neither sysklogd nor rsyslog are multilib, are they?

(In reply to comment #18)

> * Tested corresponding package removals
>   NOTE! Uninstalling sysklogd stops rsyslog.

This is bad, in case someone is evaluating one or the other with both installed.

Also (as stated before), anything that requires 'syslog' is now going to prefer
rsyslog; I don't think we want that.

Again - what specifically is this added for *right now*, and if it is completely
compatible, why can't it just obsolete it?

(In reply to comment #19)
> (In reply to comment #18)
> 
> > * Tested corresponding package removals
> >   NOTE! Uninstalling sysklogd stops rsyslog.
> 
> This is bad, in case someone is evaluating one or the other with both installed.

I agree that this is bad however I don't see how it could be avoided if we want
one logrotate script. service syslogd stop will always stop rsyslog and vice
versa. Perhaps a release note would be good enough for this?

> Also (as stated before), anything that requires 'syslog' is now going to prefer
> rsyslog; I don't think we want that.

Is it a real problem when the core group in comps contains sysklogd?
 
> Again - what specifically is this added for *right now*, and if it is
completely compatible, why can't it just obsolete it?

Unfortunately it is not 100% compatible. See the bug 178855 for reasons why want
to provide rsyslog in RHEL5.

OK guys, I really don't know how to solve this problem. If you have any ideas, 
you are welcomed.

Let me summarize the options we had:
1. rsyslog obsoletes sysklogd
 - not 100% compatible(forwarded messages)
 - qa against it
 - I don't trust rsyslog so much(needs testing, new bug (428775) was detected)
2. rsyslog conflicts with sysklogd
 - kickstart install with @Everything
 - anything that requires 'syslog' is going to prefer
rsyslog
3. rsyslog lives with sysklogd
 - uninstalling sysklogd stops rsyslog.
 - anything that requires 'syslog' is going to prefer
rsyslog

fixing: bz#428775

Spec URL: 
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog.spec

SRPM URL: 
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog-2.0.0-5.fc7.src.rpm

Given problem #1, I'm not sure what the rush for RHEL 5.2 is  - maybe EPEL with
the note that it will be in RHEL 6? Failing that, documenting that removing
sysklogd stops rsyslog (and presumably the reverse?) is probably best. It's
still supporting two stacks in RHEL, which is somewhat messy - it's not like we
can ever remove sysklogd in a later update release, from what you're saying.

(In reply to comment #23)
> documenting that removing
> sysklogd stops rsyslog (and presumably the reverse?)
No, removing rsyslog does not stop sysklogd (rsyslog's scriptlets stop "rsyslog",
sysklogd's scriptlets stop "syslog" and find rsyslog's PID file).

We could have the logrotate script check for both pidfiles and restart both.

Of course, that would require changing *both* packages to keep them in sync;
dunno if we can swing another update.

(In reply to comment #25)
> We could have the logrotate script check for both pidfiles and restart both.
> 
> Of course, that would require changing *both* packages to keep them in sync;
> dunno if we can swing another update.
And maybe changing %config(noreplace) to %config /etc/logrotate.d/syslog in
rsyslog's spec file?

(In reply to comment #25)
> We could have the logrotate script check for both pidfiles and restart both.
Sounds good to me.

I have created two packages:
http://people.redhat.com/pvrabec/rpms/rsyslog/sysklogd-1.4.1-43.fc7.src.rpm
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog-2.0.0-6.fc7.src.rpm

logrotate file looks like
...
postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || 
true
        /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 
2> /dev/null || true
    endscript
...

I'm not sure it's possible to update sysklogd in 5.2 now. Is it?

Probably would require an exception. Check with your manager?

Would rsyslog conflict with sysklogd < 1.4.1-43 and coexist with ones older than
that? We cannot make customers update the sysklogd on their system. Something
has to make that a requirement.

Without an explicit Conflicts: to force yum to grab a new one, the transaction
would probably die.

I used (Requires: sysklogd => 1.4.1-43) but (Conflicts sysklogd < 1.4.1-43) is 
better, thnx.

Created attachment 292383 [details]
Use "conflicts: sysklogd <" instead of "requires: sysklogd >="

Approved after changing the Requires: to Conflicts:, as shown in the patch.

* Tested:
  (rpm -Uvh rsyslog*) when sysklogd-1.4.1-40 is installed 
  - fails on conflict, OK
  (rpm -Uvh rsyslog*) when sysklogd-1.4.1-43 is installed
  (rpm -Uvh sysklogd*) when rsyslog is installed,
  (rpm -Uvh sysklogd* rsyslog*) when neither is installed,
  Usually, verification reports
    .......T c /etc/logrotate.d/syslog
  for one of the packages, OK
* Tested running logrotate in all the above situations
* Tested corresponding package removals
* Tested the postrotate script in /etc/logrotate.d/syslog restarts rsyslogd
  and sysklogd
* Tested that yum doesn't "upgrade" from sysklogd to rsyslog nor vice versa
* Tested upgrades from sysklogd-1.4.1-40 to -43 using a repo that contains both

  sysklogd and rsyslog work correctly

thnx. mitr for review, patch applied, final srpm:

Spec URL: 
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog.spec

SRPM URL: 
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog-2.0.0-7.fc7.src.rpm

Ot. This package was shipped. Did the review ever close?

Yes - conditionally in comment #32.

I think, that we may close this ticket.

Ping. Why this ticket still open?