November 25, 2009


Originally uploaded by skvidal

celebrate all good things – and happy thanksgiving.

– seen in the grocery store

In f12 the default policy for polkit for package kit is to allow users at the
desktop to install signed pkgs from repositories enabled on the system.

Some folks are unhappy about this so I investigated a bit. Ray Strode looked
through the polkit code to figure out the answers.

The short answer is to run (as root)

pklalockdown –lockdown org.freedesktop.packagekit.package-install

to remove this lockdown run (as root):

pklalockdown –remove-lockdown org.freedesktop.packagekit.package-install


Update: According davidz in the comments below the above command is going away. So if you want to keep users from installing pkgs you need to follow the longer instructions below.

the long answer explains a bit about polkit.

To get a list of all actions that policykit knows about you run:


to get information about the system defaults for any action you run:

pkaction –action-id actionname –verbose

this only tells you what the system defaults are. It doesn’t tell you what
the current runtime policy is going to do.

pkaction –action-id org.freedesktop.packagekit.package-install –verbose

description:       Install signed package
message:           Authentication is required to install a signed package
vendor:            The PackageKit Project
vendor_url:        http://www.packagekit.org/
icon:              package-x-generic
implicit any:      no
implicit inactive: no
implicit active:   yes

Now, if I want to change the value of this to something more specific you need
to edit a file:

in this file you would put:

[Only Let Admins Install Packages]

save it and that’s it.

The line Identity let’s you specify users or groups that the policy impacts.
The items are ; separated and each one must start with unix-user or unix-group
and have a user, group or wildcard following it.

Now, if you want to test to make sure this works you can, of course, run the
program in question. OR you can use pkcheck.

you use pkcheck like this:
pkcheck –action-id org.freedesktop.packagekit.package-install \
–process $process_id_of_the_process_making_the_request \
-u $the_username_you_are_testing

the process id I used was of a shell of the user or was the gnome-session process.

it should pop up an auth dialog if you did everything correctly.

For more complete docs look at:
man pklocalauthority


man polkit

hope this helps.

Yes,  I know it’s not supported, but neither is anything else. I took the time on friday to try out the yum update and it worked swimmingly. Here are the steps I took:

0. I ran pybackpack and duplicity and backed up all my stuff to remote

1. download fedora-release and fedora-release notes from the f12 mirrors

2. yum localinstall them

3. yum clean all

4. screen

5. yum update yum\* rpm\*

6. yum update python\*

7. yum update glibc\*

8. yum update kernel

9. yum update

10. yum groupinstall “GNOME Desktop Environment” base core

11. yum remove specspo mlocate sendmail

12. logout and reboot

It took a while to get everything and I had to break a few pieces up in order to make all the pkgs fit when I downloaded them but everything else just worked.

Proceed at your own risk.

This morning I was annoyed by a perl module which took the output from yumdownloader –resolve –urls, screenscraped it, downloaded the pkgs then passed them to rpm -Uvh. Let’s ignore all the things which could break there – just the ugliness of it.

So I hashed this together:


I’m not sure I like it yet, but it is a start.

You can pass multiple items on the command line doing multiple things like:

yumpipes –install=foo –install=baz –update=quux –remove=sendmail

and you can pass –dry-run which runs the transaction in test mode

and you can pass –report-only  which only spits out what the transaction would do.

and the output from the transaction and from the –list option is pipe-delimited so people using awk or cut can easily parse it.

finally. the error codes, while not great, are somewhat consistent.

flames welcome.


what needs to be restarted

November 3, 2009

A common problem I’ve encountered for years is how to know what daemons need to be restarted in order to take advantage of some update or to be sure that they are running the secure version of the libs you just updated. I was thinking about this yesterday and realized I had all the tools necessary to find this out.

I came up with this simple script: needs_to_be_restarted.py

Now, it might be a bit overly simple and that is why I’m asking here. All it does is go through each of the processes in /proc/###### open the smaps file and look for files. For any of the files in there, it checks if a pkg owns them. If it does it checks what the installtime is on that package. If the installtime of the package is newer than when the process was started then it reports that pid (and the cmdline).

Now, this won’t work in every case, and I may have it report if the files have been removed but it seems to work pretty well.

If there are more foolproof ways to know or additional checks I should add, let me know.

If this looks good I’ll probably add some options and add it to yum-utils.

rail system

November 3, 2009

A semi-heartening comment today from this cnnfn article:

“Our country’s future prosperity depends on its having an efficient and well-maintained rail system,” Buffett said in a statement.

yum nag plugin

November 2, 2009

James and I were talking on irc about things we see in bugs that make us cringe. That people  are doing on their systems with yum or rpm or vaguely related. It reminded me of this list of  sysadmin aphorisms that I worked on about 3 or 4 yrs ago now.

So I was thinking what we need is a  yum nag plugin that when you run it as root it would emit some warnings about things you probably don’t want to be doing. Examples:

1. Warning: You have 10+ plugins installed and enabled, this is probably going to have odd effects

2. Warning: You have more than 5000 pkgs installed. Do you really need all that stuff?

3. Warning: Your system has been up for 528 days. Massive uptimes aren’t  as cool as you think

4. Warning: We’ve search ~/.bash_history and found evidence of –force and/or –nodeps – these are not wise.

5. Warning: You’ve disabled gpg checking. Bad, Bad.

6. Warning: You have 10 repositories enabled and 30 available. Seriously?

7. Warning: You have 4 versions of perl|python|ruby installed – this is just going to end in tears

8. Warning: Rawhide is enabled. I hope you know what you’re doing.

9. Warning: You have kernel modules installed. Good luck with those distro upgrades.


What else should be added here?