Last week it was hacking week for the openSUSE-GNOME team, so I continued working on a little project I started a few weeks ago, which is, in the good old Richard Hughes tradition, a thing called AdminKit, which is a PolicyKit-based framework for allowing user applications to run administration tasks.
Most of the time hacking on this has been dedicated to the PolicyKit stuff, but now everything should be in place, and, apart from the 2 methods I added (RunAsRoot to replace gnomesu/gksu/kdesu, and AddUser as an example of how to use YaST’s command line interface for the operations), more methods (users management, firewall, samba shares, etc) can be easily added. With this and the GUI from gnome-system-tools, I think we can start providing a distro-independent (and acceptable to all of them) set of administration tools for GNOME (and KDE, if they adopt AdminKit), or just add the needed admin functionality to already existing applications. From now on, here are my ideas:
- Move PolicyKit mechanisms already existing in some GNOME modules (gnome-panel’s SetTime and SetTimezone, for instance) to AdminKit, provided people agree on adopting it
- See system-tools-backends and reuse as much knowledge/code as possible
- See at changing gnome-system-tools’ GUI to use AdminKit (once the functionality needed is moved to AdminKit)
- Add more admin operations, as needed. For openSUSE, we have quite a lot of functionality via yast’s command line interface, and other distros have similar stuff, so anything we need can be added AFAIK.
Get the code with:
git clone http://www.gnome.org/~rodrigo/git/osc-plugins.git
(cd AdminKit, the other top-level dirs contain unrelated projects)
And, soon, packages at my home build service repository.
Is this going to do stuff like the following?
ethan@home:~$ tail -27 .bashrc
# system command aliases
alias list=’ls’
alias delete=’rm’
alias DELETE=’sudo rm’
alias frigging=’sudo’
alias install=’sudo apt-get install’
alias uninstall=’sudo apt-get remove’
alias check-update=’sudo apt-get update’
alias update=’sudo apt-get upgrade’
alias murder=’sudo killall’
alias get=’wget’
alias GET=’sudo wget’
alias enter=’cd’
alias up=’cd ..’
alias home=’cd ~/’
alias unmount=’umount’
#functions
function remove () { mv “$@” ~/.local/share/Trash/files; }
function REMOVE () { sudo mv “$@” ~/.local/share/Trash/files; }
# enable programmable completion features (you don’t need to enable
# this, if it’s already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
Hello! Nice work you got there! I wanted to let you know that I am writing a PolicyKit-based version of gksu; take a look here:
http://live.gnome.org/gksu
git://kov.eti.br/srv/git/gksu-polkit.git/
It’s almost feature complete, provides X authentication “forwarding” like the earlier gksu, and also provides a way to let the developers and administrators specify what environment variables should be “forwarded” too.
My code contains a library to provide an easy interface for applications. The library even handles the client-side PolicyKit work, and I/O (stdin/stdout/stderr). Take a look, perhaps we can merge some of your work for RunAsRoot into gksu-polkit and keep going from there?
What we really need is to be able to connect to a server and administer it, much like the printer tools in GNOME these days. Well at least the ones in Ubuntu and I image Fedore and SUSE.
This would seriously kick….
I hope you don’t plan to use Perl as in system-tools-backends! It would be good to get rid of system-tools-backends and the Perl dependency once and for all.
Nice! will this make it into openSUSE 11.1?
No offense, but what is the point? Can you write a followup blog on why AdminKit exists and the specific niche it is attempting to fill?
What can AdminKit that PolicyKit can’t do already? It seems like you should patch PolicyKit instead of a subset of it.
Jeff, OlicyKit just offers the framework for running stuff as root, but it doesn’t contain the actual implementation of those specific tasks (RunAsRoot, AddUser, etc), so AdminKit, based on PolicyKit, offers that.
Michael: no, will not be in 11.1, but in 11.2 probably
Oh cool, but why not get that functionality merged back into policykit?
“… which is, in the good old Richard Hughes tradition, a thing called AdminKit…”
Rather, in good old Apple/NeXT tradition…