When doing something with rpm that should really be done as root could it please say for example "error: can't create transaction lock, do you need to be root", or maybe a permission problem message instead of :
$ rpm -e kernel-2.6.5-1.358 kernel-2.6.8-1.541 error: can't create transaction lock
How would I formally request a more useful error message?
For the first half second I think, "huh, what's wrong", half a second after that I throw a 'sudo' in front of it.
-n.
On Tue, 07 Sep 2004 12:02:52 +0900, Naoki naoki@valuecommerce.com wrote:
When doing something with rpm that should really be done as root could it please say for example "error: can't create transaction lock, do you need to be root", or maybe a permission problem message instead of :
$ rpm -e kernel-2.6.5-1.358 kernel-2.6.8-1.541 error: can't create transaction lock
Doesn't this assume that ALL transaction lock problems are permissions related? Can you assume that? Does rpm have the capability to inherently know that its a permission problem? Can you assume that every rpm installation in use requires root?
-jef"goes off to play with his self-compiled rpm installation he uses with a normal user account on a system where he doesn't have full adminstration access, but where he has to manage a subset of specialized software for a small group of users inside the 1000+ userbase of the large system"spaleta
On Mon, 2004-09-06 at 23:14 -0400, Jeff Spaleta wrote:
On Tue, 07 Sep 2004 12:02:52 +0900, Naoki naoki@valuecommerce.com wrote:
When doing something with rpm that should really be done as root could it please say for example "error: can't create transaction lock, do you need to be root", or maybe a permission problem message instead of :
$ rpm -e kernel-2.6.5-1.358 kernel-2.6.8-1.541 error: can't create transaction lock
Doesn't this assume that ALL transaction lock problems are permissions related? Can you assume that? Does rpm have the capability to inherently know that its a permission problem? Can you assume that every rpm installation in use requires root?
Yeah, I thought about this as well and decided that a 'normal' user just wouldn't ever work out what a transaction lock was. I don't care what the error is message or even if there is one because I know how to use 'strace'. Also considering the error is pretty obvious in it's cause :
open("/var/lock/rpm/transaction", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = -1 EACCES (Permission denied)
It might make sense and help the average joe if we can tell them it's a permission problem.
-n.
Le mar 07/09/2004 à 08:02, Naoki a écrit :
It might make sense and help the average joe if we can tell them it's a permission problem.
I don't think the average joe use rpm. They use system-config-packages or yum.
[average_joe@here average_joe] yum install tata ... You need to be root to perform these commands
$ rpm -e kernel-2.6.5-1.358 kernel-2.6.8-1.541 error: can't create transaction lock
Doesn't this assume that ALL transaction lock problems are permissions related?
No. There are a variety of reasons why this might fail. There's more than one value for errno returned.
Does rpm have the capability to inherently know that its a permission problem?
errno is set, its just a matter of using it in the error message.
Can you assume that every rpm installation in use requires root?
This is actually a good point. rpm should check the uid to see if its root. If not print a warning that there may be permission problems and re-run as root to avoid this warning. This patch has been on my todo list for a while.
-Steve Grubb
_______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
On Tue, Sep 07, 2004 at 05:01:37AM -0700, Steve G wrote:
$ rpm -e kernel-2.6.5-1.358 kernel-2.6.8-1.541 error: can't create transaction lock
Doesn't this assume that ALL transaction lock problems are permissions related?
No. There are a variety of reasons why this might fail. There's more than one value for errno returned.
Indeed there might be another write rpm operation happening!
Does rpm have the capability to inherently know that its a permission problem?
errno is set, its just a matter of using it in the error message.
This is fair enough
Can you assume that every rpm installation in use requires root?
This is actually a good point. rpm should check the uid to see if its root. If not print a warning that there may be permission problems and re-run as root to avoid this warning. This patch has been on my todo list for a while.
I'm not sure that's ideal behaviour - it is possible to use things such as --dbpath and --root (ignoring not being able to move the transaction lock for the moment). I wouldn't expect a failed (EPERM) rm command to suggest rerunning as root, likewise for rpm.
Also theoretically we could have a "package_installer_r" with selinux to enable certain rpm install operations.
As always bugzilla or rpm-list the best places for RFEs or this sort of discussion.
Paul
I'm not sure that's ideal behaviour - it is possible to use things such as --dbpath and --root (ignoring not being able to move the transaction lock for the moment). I wouldn't expect a failed (EPERM) rm command to suggest rerunning as root, likewise for rpm.
I think that using --dbpath and --root is rare. The 80/20 rule is that people use rpm to simply upgrade/query a system. Nothing fancy. The only time I *ever* use those options is in my chroot build system when I'm setting up the build partition. Even in that case I need to run as root to make sure all file permissions are set correctly so that the build system will error when it tries to overwrite something important.
I suppose another approach is to hold off the warning until EPERM is seen. But that complicates the code. For my source tree, I'm going to patch in a warning message since that is the simplest solution.
Also theoretically we could have a "package_installer_r" with selinux to enable certain rpm install operations.
This would have to be thought out carefully if I understand your suggestion. It could become and attack vector if done wrong.
-Steve Grubb
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
On Tue, 7 Sep 2004 05:47:12 -0700 (PDT), Steve G linux_4ever@yahoo.com wrote:
I'm not sure that's ideal behaviour - it is possible to use things such as --dbpath and --root (ignoring not being able to move the transaction lock for the moment). I wouldn't expect a failed (EPERM) rm command to suggest rerunning as root, likewise for rpm.
I think that using --dbpath and --root is rare. The 80/20 rule is that people use rpm to simply upgrade/query a system. Nothing fancy.
The 80/20 rule applies to error messages? We should be happy when an error message misinforms 20% of the time? That strikes me as a bit odd. Sure 80/20 for defaults and for ui features and for crap like that. Error messages, I have a hard time with that.
-jef
On Tuesday 07 September 2004 14:16, Paul Nasrat wrote:
I'm not sure that's ideal behaviour - it is possible to use things such as --dbpath and --root (ignoring not being able to move the transaction lock for the moment). I wouldn't expect a failed (EPERM) rm command to suggest rerunning as root, likewise for rpm.
Also theoretically we could have a "package_installer_r" with selinux to enable certain rpm install operations.
This would still require root permission. SELinux doesn't give additional rights.
-
Féliciano Matias -
Jef Spaleta -
Naoki -
Paul Nasrat -
Ronny Buchmann -
Steve G