Re: [Rpm-maint] Script hooks patch
On 11/23/2012 07:32 AM, Reshetova, Elena wrote: Hi, Please ignore the previous path: I should have just went to sleep yesterday Heh, I know the feeling :) Somehow it got locked in my head that case when execv might fail is a special case (which of course it is, but not for this) and we need to call the hook there also to indicate this. Complete nonsense when you look at it with fresh head. The corrected patch attached! I see a couple of further problems with this: - runLuaScript() will leak memory and a file descriptor if rpmpluginsCallScriptPre() fails. - For external scripts the hooks run on different sides of the fork(): pre-hook runs in the forked child, post-hook in the parent, so parent will be unaware of anything occurring in the pre-hook. I'd prefer the hooks called from rpmScriptRun() already so there would be exactly one place where to deal with them, but whether that would actually work is a different question entirely... External scripts have a lengthy setup sequence in the child between the fork() and exec(), including a call to rpmExpand() on %_install_script_path. Which should not, but technically could, have a shell-invocation in it, which would cause a fork() + exec() of its own which would cause (at least in case of SELinux) the exec context setup to go to wrong address. It should be possible to move the rpmExpand() into parent and just pass the path as an argument to doScriptExec() though but just goes to show how the kind of minefield this is. Internal scripts present different problems: as it is now, there's not much difference between calling hooks from runLuaScript() and rpmScriptRun(), but if we assume they'll get forked in the future, any security context switch would have to happen after the fork. Which inevitably causes the same asymmetry with pre- and post-hooks as there is now with external scripts. One way to address it would be having an "unpaired" post-fork (or pre-exec if you like) hook that explicitly runs in the child process, which basically is what we have now in the script setup hook. Which then begs the question: what exactly are the new script pre- and post-hooks supposed to be used for? Ok, I can imagine eg logging plugin wanting to do something in both of those, but... - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Script hooks patch
Hi, Please ignore the previous path: I should have just went to sleep yesterday L Somehow it got locked in my head that case when execv might fail is a special case (which of course it is, but not for this) and we need to call the hook there also to indicate this. Complete nonsense when you look at it with fresh head. The corrected patch attached! Best Regards, Elena. From: Reshetova, Elena Sent: Thursday, November 22, 2012 9:42 PM To: rpm-maint@lists.rpm.org; Panu Matilainen Subject: Script hooks patch Hi, In the attachment promised patch for the script hooks: changing to have two hooks instead of one and calling them for lua case, too. Let me know what needs to be fixed J Panu, I will reply to your other email tomorrow morning: I am falling asleep already with this darkness around L Best Regards, Elena. 0001-Improving-script-related-rpm-plugin-hooks.patch Description: Binary data smime.p7s Description: S/MIME cryptographic signature ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Script hooks patch
Hi, In the attachment promised patch for the script hooks: changing to have two hooks instead of one and calling them for lua case, too. Let me know what needs to be fixed J Panu, I will reply to your other email tomorrow morning: I am falling asleep already with this darkness around L Best Regards, Elena. 0001-Improving-script-related-rpm-plugin-hooks.patch Description: Binary data smime.p7s Description: S/MIME cryptographic signature ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Plugin ponderings
Hi, Like said in some earlier email, there's not much hope getting the details 100% right the first time. The best way of finding out what works and what doesn't is to try it out, so... I started looking into creating a syslog plugin for rpm. One could argue that logging is fundamental enough to be in rpm core, but then having it in a plugin allows nicely for alternatives (such as *gasp* native systemd journal support) and is a nice and harmless way to test the plugin system. Lets just say I ran into issues real fast. No fingerpointing implied - I didn't catch these on review either and some of the issues are direct consequences from my own suggestions, doh :) For logging installs and erasures, one of the primary interests is PLUGINHOOK_PSM_POST. As it is now, the hook doesn't get called if the package failed to install, which is a case you'll certainly want to log: /* Run post transaction element hook for all plugins */ if (!rc) rc = rpmpluginsCallPsmPost(ts->plugins, te); The other problem here is that the PSM_POST hook doesn't get passed the result code of the install (otoh it doesn't get called on failure to begin with so...). One could get the status from rpmteFailed(), but that element failure is set only after rpmpsmRun() returns so its not available here. Similar issues are present in the TSM hooks: TSM_POST doesn't get called on some error situations (file conflicts etc) where TSM_PRE is called, and the transaction result code is not passed to plugins. Me thinks we seriously need to define a consistent convention for all plugin hooks and then scrutinize the existing and future hook paths for correctness in all possible situations. I'd think part of the convention needs to be that whenever PRE-hooks get called, the pairing POST hooks are guaranteed to get called too. Even if some of the PRE-hooks returned errors: some plugin(s) might return an error from its PRE-hook, but there could be other plugins which succeeded in their own business and might have allocated resources they need to free up in POST. Then there's the issue of return codes: maybe all the POST hooks should take an added 'rc' argument for the return code of the actual operation. That seems simple enough in principle, but there be dragons in the details: For example rpmpsmRun() returns RPMRC_FAIL only if the package didn't get installed (or removed) at all. %pre and %preun scriptlets can prevent install/erase from taking place, %post and %postun cannot (as the operations cannot be rolled back) so RPMRC_OK is returned from rpmpsmRun() even if they fail: basically the operation succeeded with warnings. This semantic needs to be taken into account with plugin hook results too, so rpmpluginsCallPsmPost() can't really cause RPMRC_FAIL to be returned from rpmpsmRun(). Or we need to revamp the whole damn return code system (which might well be the sanest option really, especially since its just an internal API) Similar quirks are present in rpmtsRun() return codes, but that's a more difficult case as its part of the public API (which everybody loves to hate because of the nutty and useless return codes :) Another question is whether rpmRC codes are sufficient for the task. It's used for a lot of things in rpm, but many of those uses are ugly abuses in reality. Thoughts/comments/ideas? P.S. I certainly dont mean you need to do all this, I'll help combing the call- and error paths for correctness once we figure out what "correct" actually is. - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] add syslog support to rpm (when installing/removing packages)
On 11/22/2012 05:42 AM, Thierry Vignaud wrote: Hi Hi, You had a typo in the mailing list address: 'pm-m...@lists.rpm.org' but apparently some catchall-alias sent it to me afterall. Since rpm-maint was obviously the intent, replying to the list. 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 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. 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. 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. 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. -- - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
