[Rpm-maint] [PATCH] add syslog support to rpm (when installing/removing packages)

Panu Matilainen pmatilai at redhat.com
Mon Dec 10 13:01:53 UTC 2012


On 12/09/2012 07:52 PM, Thierry Vignaud wrote:
> On 22 November 2012 09:19, Panu Matilainen <pmatilai at redhat.com> wrote:
>>> The following patch adds syslog support to rpm
>>> (logging installing/removing packages).
>>>
>>> It was proposed a year ago and Panu asked a little cleaning:
>>> http://lists.rpm.org/pipermail/rpm-maint/2011-March/002995.html
>>>
>>> Here's the cleaned version.
>>> I've also added some historic notes.
>>> Commenting out %_transaction_syslog_ident disables it.
>>>
>>> Please apply to master as well as to rpm-4.11 branch
>>
>> Sorry for not commenting on the (privately sent) patch earlier, just been
>> busy with other stuff.
>>
>> For a long time I had no idea whether you were going to do anything about
>> the syslog patch so I went ahead and played around with it a bit on my own.
>> A major issue nobody noticed or at least commented on in the previous round
>> is that this ends up logging way too much:
>>
>> Test transactions are getting logged, this is not good: if I as a regular
>> user run 'rpm -e --test --nodeps --allmatches glibc', that really must NOT
>> be logged, but that's what happens currently:
>>
>> Nov 22 09:36:53 localhost lt-rpm: [RPM] erase glibc-2.14.90-24.fc16.9.i686
>> Nov 22 09:36:53 localhost lt-rpm: [RPM] erase glibc-2.14.90-24.fc16.9.x86_64
>
> We could test for RPMTRANS_FLAG_TEST

Sure, but RPMTRANS_FLAG_TEST is not the only thing you need to check and 
you'd have to have some extra "infrastructure" around the logging to 
handle it all without duplicating umphteen checks around each syslog() 
call. Doable of course but since nothing like that is there now...

>
>> Largely similar to 1), operations on chroots and non-system database get
>> logged identically to everything else. For example just executing the rpm
>> test-suite as a regular user emits tons of stuff in the syslog - not good.
>>
>> Whether chroot operations should be logged at all I dunno: there are
>> situations where you might want it (such as during initial system install)
>> and then there are those where you probably dont want it. At the very least
>> the chroot needs to be logged as well. Another quirk is the rpmdb path: if
>> you do a --justdb install/erase of packages on an alternative db path, that
>> shouldn't be logged.
>
> I don't agree for the justdb case (but we can skip logging if
> RPMTRANS_FLAG_JUSTDB
> flag is set)

Note that I was talking about RPMTRANS_FLAG_JUSTDB operations on 
alternate rpmdb path, for the system rpmdb you'd certainly want to have 
them logged. I was just pointing out yet another case that needs 
considering, point being that getting the logging right is not quite 
that simple.

>
>> But then... what if somebody does something like:
>> # cp -avp /var/lib/rpm /tmp/junkdb
>> # rpm -Uvh --dbpath /tmp/junkdb nastypackage.rpm
>> (or erase something)
>>
>> That would modify the actual system but leave the system rpmdb unaware of
>> those changes, and should be logged, along with the rpmdb path that was
>> used.
>
> Indeed
> So we agree that most stuff should actually be logged :-)

Perhaps most, but there's a lot of stuff that absolutely must NOT be 
logged for the sysadmin sanity. Like those 'rpm -e --test glibc' kind of 
things.

>> And while adding logs, there are a bunch of other things we arguably should
>> log as well. At least:
>>
>> - Transaction start and stop, along with the transaction id. That makes it
>> easyish to see things like "here's a transaction that started but didn't
>> finish, so rpm has crashed or gotten killed while installing".
>> - Package scriptlet failures
>> - Rebuilds of the system rpmdb
>> - Bunch of other information about the transactions:
>>    - select parts of active configuration (eg the rpmdb path)
>>    - select transaction flags, such as whether scriptlet execution was
>> disabled, disk-space calculations ignored, file replacement forced etc
>>    - other things that seem like flags but are not in the librpm API, such as
>> the effect of --nodeps and --noorder
>>
>> I've a work-in-progress patch to do some of the things here, but its nowhere
>> near complete.
>
> Can we see it?

It's not going to go in so I dont see much point in sharing that 
abandoned "study" into syslogging. You can expect to see a rough-cut 
initial version of a logging plugin in git master in a week or two 
however, now that the plugin interface has the necessary bits and pieces 
for that.

>> And with all the plugin-discussions going around, I've
>> started thinking of pushing the whole logging thing into a plugin. So there
>> would be a "reference rpm logging plugin" that does roughly the above
>> shipped with rpm, distros get to choose whether to use that or something
>> more specialized.
>
> I would like a decision to be taken for rpm-4.11.
> We carry this patch for nearly 12 years and several people are interested in it.
> Since there's no plugin for the moment, we could put it in rpm-4.11, then
> enhance it later (--test case, transactions, ...).

That would create a dead-end line of development that's specific to a 
single branch, which is not how these things work. New features for the 
next version are developed in git master and in select cases can be 
backported to older branches once stable and complete enough. The plan 
is to have syslog capability in 4.12 as a plugin, and the only way for 
4.11.x to get it would be backporting the plugin and the needed 
infrastructure once "ready" (which they're obviously not at this point - 
the plugin doesn't even exist and the plugin interface is very much a 
work-in-progress still)

	- Panu -


More information about the Rpm-maint mailing list