Joerg:
On 08/14/09 02:31, Joerg Barfurth wrote: > Brian Cameron schrieb: > I justed wanted to know (and have recorded in this case) some of the > architectural gotchas we have to deal with, at least for the transition. Much appreciated. >>> Does this mean that PAM is not even started before a user is selected, >>> if the face browser is enabled? >> >> Correct. >> >>> That makes face browser incompatible with PAM modules that preset a user >>> name known from elsewhere, without prompting interactively (such modules >>> are for example used by various Sun Ray features). >> >> Yes and no. This is an area where we need to do some additional work. >> > > [...] > >> Another approach would be to add back a feature that the old GDM >> supported. You could set AutomaticLogin to "!scriptname" and that >> would then run a script that would return the username to use. It is >> passed the DISPLAY and $USER environment variables so that the script >> can pick the username based on those settings. This feature was lost >> in the rewrite, but it would be trivial to add back if you think it >> would be better to use this interface. >> >> One advantage of using the "!scriptname" feature is that if the >> script returns an invalid username, then AutomaticLogin is not used >> for that login session. So, if you want to support the ability to >> use AutomaticLogin sometimes, but not others, then this script approach >> could facilitate that. You could just write a script that passes back >> the username when you want to AutomaticLogin, and an invalid username >> when you don't. >> > > We'll need to do extra work to make Kiosk Mode work under new GDM > anyway. From what I know now, it certainly seems that AutomaticLogin > with the "!scriptname" feature would be the best approach here. Okay, this is a fairly trivial feature to add back to the new GDM and generally useful for terminal server environments where you might want different users to log into different machines based on the display. I'll make sure this feature gets added back to the new GDM. >> That said, I think getting this to work with AutomaticLogin, if >> possible, would be the better approach. >> > > Yes. I'll try to work with you on that. Once I get the above feature working, I'll provide you with packages for testing. >>> How is (UI) language selected *before* the user has entered/selected a >>> user name. Is there any memory of the language to use? >> >> GDM uses the $HOME/.dmrc file to use the last selected session and >> language. We are talking about moving the $HOME/.dmrc file to >> /var/cache to avoid issues with kerberos and the issues you mention >> below. >> > > If you plan to change it, is "Uncommitted" the right stability for the > $HOME/.dmrc path? No. Volatile would be better. > OTOH that is a pre-existing gdm interface (and for example Kiosk Mode is > currently using it ...), so switching that will not be that easy. I think the best solution is to add a configuration option to GDM so that it can be configured to access the file either from the user's $HOME directory or from the cache. >> Correct. GDM starts up gnome-session, gnome-settings-daemon and >> metacity. Then after authentication they are torn down, and the user >> session is started. GDM does provide some configuration defaults for >> gnome-settings-daemon so that it only loads modules which are needed >> by GDM to help save resources. >> >>> (I'm concerned about performance/resource impact on (massively) >>> multi-seat systems) >> >> The new process will likely be a bit more resource intensive than the >> old GDM. Fortunately, people don't spend most of their time using the >> GDM program, so I wouldn't think it would affect the overall >> performance so greatly. > > On Sun Ray systems you often have large number of sessions sitting at > the greeter (on unused clients). That shouldn't be a performance issue. The processes that run with the greeter are not resources intensive. There might be a bit of a performance hit when they first start up, especially when a lot of them start up at once, which does happen in Sun Ray environments. But it is a one-time hit each time you restart the server, and shouldn't be a big impact after that. > But if use of AutomaticLogin avoids this in cases that don't need it at > all, that addresses an important part of my concerns. Great. I'm sure we can work together and get it working. Brian
