GNOME Bugzilla – Bug 356174
ability to run headless for system-wide use
Last modified: 2007-07-25 17:05:11 UTC
Inspired by the recent upstart threads on the dbus list http://lists.freedesktop.org/archives/dbus/2006-September/005768.html I thought it might be good to do this soon. We need a few things First, is the ability for g-p-m to take a commandline option --headless. If this is passed g-p-m shall be able to work without an X server and a session message bus. It will still use gconf however. Also, it's possible to detect there is no X server, see use of gtk_init_check() in main() in http://cvs.gnome.org/viewcvs/gnome-mount/src/gnome-mount.c?view=markup and if this is the case run as if --headless was passed. In the future we might want to change this, e.g. it's not unreasonable in some star trek future that g-p-m might dock into the display manager (g-d-m for instance). Second, we need some entity to spawn "g-p-m --headless" when no one is logged in and kill it when someone logs in. Potentially several copies of "g-p-m --headless" will be spawned (one for each console) but that requires multi-seat support, it's doable but bluesky for now. Ideally upstart will do this for us one day, but until that I suggest a more simple approach. Distros use an initscript to start "g-p-m --headless". When "g-p-m --headless" is started it claims the name org.gnome.Systemwide.PowerManager on the _system bus_. It exports one object with one interface that has one method: PauseService(). If someone calls this method then it stops enforcing policy, e.g. basically goes to sleep. It tracks, via NameOwnerChanged, when the caller disappears and resumes service once all callers of PauseService() disappears. Much like Lock() and others is implemented in HAL / g-p-m / g-s. When a user logs in g-p-m is started, without --headless. It calls StopService() on the org.gnome.Systemwide.PowerManager service. Pretty low-tech solution and this will only work for GNOME. Distros also shipping KDE will have to patch g-p-m like programs to do the same. Hopefully either upstart can save the day (so we don't need to run two processes) or we standardize org.gnome.Systemwide.PowerManager to org.freedesktop.Systemwide.PowerManager When we have this we can (and should) start doing the "set these settings as system-wide" feature. Will file a separate bug for this. It will require PolicyKit but I'll be working on that over the next few weeks. Same design pattern applies to nm-applet and g-v-m. Will file separate bugs if this works out great for g-p-m. Either way, let's do this fast and try to target GNOME 2.18. Thanks for considering.
So, why does it need to be headless? Seems to me that the usecase is very specific: handle system (and possibly screen) power management when a display manager is active. I'm not sure you need to handle the headless case at all - I can't imagine a scenario where you'd want gpm and an X display wouldn't be open. Whether or not we can add an XEmbed dock to GDM is another matter. One I'll try to look into. Long term, as I think we talked about at GUADEC briefly, we may wish to consider reconceptualizing the display manager "greeter" as a session run by user "gdm".
In response to comment 1: > So, why does it need to be headless? Seems to me that the usecase is > very specific: handle system (and possibly screen) power management when a > display manager is active. I'm not sure you need to handle the headless > case at all - I can't imagine a scenario where you'd want gpm and an X > display wouldn't be open. So, one example would be people not using X - with cpu frequency scaling support mo ving into g-p-m this is useful on servers too. And it's even nice for sysadmins, they can use the g-p-m UI to configure power management policy in that case too. Here's an updated implementation idea. Provide a small baby sitter, ideally hosted on fd.o, let's call it xdg-policy-daemon that takes two parameters, the type of policy daemon, and the path of what binary implements this. For runlevel 3, e.g. no X, the distro would use this to spawn g-p-m or what ever power management daemon they want. The initscript on Fedora could e.g. look in /etc/sysconfig/desktop to determine whether KDE or GNOME is the default desktop. So in run level 3, it will look like this xdg-policy-daemon --type PowerManager --exec "/usr/bin/gnome-power-manager --no-user-logged-in" The baby sitter would be a daemon process that simply claims the name org.freedesktop.XdgPolicyDaemon.<type> (where <type> is PowerManager, VolumeManager, NetworkManager or whatever). If it cannot claim the name, it just waits until it becomes available, listening to NameOwnerChanged. If the manages to claim the name it spawns that process. If someone calls PauseService() it kills the process / starts it again when the callers exit the bus. Just like in the original proposal. For runleve 5, there is no such init script. We, however, patch gdm to read desktop files that spawns xdg-policy-daemon. So g-d-m would just provide a desktop file for this. Thus, "xdg-policy-daemon --type PowerManager --exec blah" would be spawned by gdm and DISPLAY=, DBUS_SESSION_ADDRESS etc. would be available too, all provided by g-d-m. It would make sense for gnome-screensaver to provide a desktop file too such that we finally can get the screen saver working on the login screen. Also, the screen saver and power manager would interoperate just fine just as if it was a desktop session. Ideally (and before we start using the name org.freedesktop) we'd get KDE to buy into this too. It should interoperate just fine. > Whether or not we can add an XEmbed dock to GDM is another matter. One > I'll try to look into. Sounds good. If you, and Richard, likes this proposal perhaps we have the work cut out: Richard: fix up g-p-m to accept the --no-user-logged-in. Note that you may be launched both with and without either an X server or D-Bus session bus available. Should be able to handle both these cases. Jon: Add XEmbed dock to GDM; read .desktop files and launch them David (or someone else): Write xdg-policy-daemon - also talk to KDE / other desktops about using this. > Long term, as I think we talked about at GUADEC briefly, we may wish > to consider reconceptualizing the display manager "greeter" as a session > run by user "gdm". Right. That would be awesome. It's kinda what I'm suggesting here too. What do you think?
>Long term, as I think we talked about at GUADEC briefly, we may wish to >consider reconceptualizing the display manager "greeter" as a session run by >user "gdm". I think this is a very good idea. >Note that you may be launched both with and without either an X server or >D-Bus session bus available. Should be able to handle both these cases. Without a dbus-session bus, how are we going to talk to the other gdm stuff? For instance, g-p-m couldn't tell g-s to Lock() without a session bus. I can understand the x-not-running case. Richard.
> Without a dbus-session bus, how are we going to talk to the other gdm stuff? > For instance, g-p-m couldn't tell g-s to Lock() without a session bus. Well, for the g-d-m case (referring to comment 2) you'll probably have a screen saver as the idea is to let g-d-m spawn a session bus as well as g-p-m, g-s and possibly crazy talk like g-v-m and other things. For the "run level 3" case, I'm not sure it makes sense to lock the screen - users are normally not logged in and if they do log in, the get a shell on the console. (note that for run level 3 we'll still DTRT if the user logs in to the console and does a 'startx' - his GNOME session (or whatever) will spawn g-p-m etc. and the system-wide things will be shut down by their baby sitter). Hope this clarifies.
WRT to the 'nobody' user going to sleep... How do we deal with mandatory settings? For the NM case, we probably need both the 'nobody' daemon and the user daemon going at the same time, for this reason: the 'nobody' daemon needs to know when changes are made to the system-wide settings, and to alert NM to those changes. If the user authenticates, and then hits the "Make System Default" button (or whatever it is), or some system config files changes, or an LDAP update is made and pushed to the machine, only the 'nobody' daemon is going to know that something changed. If it's not pushing these policy changes back to NM, then NM won't be getting the policy updates either. We can't rely on the user daemon enforcing policy for us because it's untrusted.
Re comment 5: The proposal is that the 'nobody' daemon is going to be exactly the same piece of code running as when the user is logged in (perhaps with the only difference that it don't display any UI). I don't think you want a trust model where you need to have NM trusting nm-applet. I think, it is like: To make an usable system, NM needs to exports privileged operations to unprivileged users. Right now we have a very coarse interface; allow all such operations when the user is at the console, none if the user is not at the console (ditto for Debian, only group membership). (Using PolicyKit would help here (want to allow only some users to connect to some wireless networks etc.), but in principle the "at_console" thing is good enough at least for the purpose of this discussion.) As such, if a users session (at the console) is compromised, they can screw up networking and that's the trade off we are making. And I think that's fine; there is nothing you can do about this if the design you have is to allow settings / policy to come from the desktop session. So I see no reason to have the 'nobody' piece of code running when the user is logged in, e.g. we would run one, and only one, instance of nm-applet at any given time. If there is no user logged in, then we'll have g-d-m (or whatever) spawn nm-applet. If a user is logged in then it's nm-applet in the desktop session taking control. If we have several users logged in... ok, let's wait with that use-case :-) If you disagree please come up with examples, I'm not sure I fully understand what you are saying... ps: it sounds like you are trying to use gconf lockdown as a substitute for PolicyKit and I think that is a pretty bad idea (you are mixing settings with enforcing policy for one thing). I can expand on this if you want, but it's really off-topic wrt this bug
Right. I'm starting to play with this some more. How does g-p-m get preferences when run in --headless mode? There's no gconf, so should I just hardcode it as a sane value? Or is gconf running with the user nobody? Thanks, Richard.
Dude, Jon and myself got g-p-m running in gdm at GUADEC, without any UI. I'll close this bug, as it seems to work well.