Brian Cameron schrieb: > As you probably know, the Desktop team has worked hard over the years > to make sure that GDM works well on Sun Ray. Our plan is to ensure > that the new GDM rewrite also works well on Sun Ray. That said, there > will probably be a few pains in making the transition. However, in the > long run, I think this is a good thing. Since Sun Ray supports various > Linux distros, it is important to work with the upstream GDM community > and resolve issues in a way that will work across all distributions > that SRSS supports. >
Yes, I know and agree. 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. >>> By default GDM now displays all users on the system in a face browser >>> so the user can select the username from a list and then enter the >>> password. The most frequent users are displayed first and the list >>> of frequent users is obtained using the ConsoleKit /usr/bin/ck-history >>> interface. >> >> Displaying all users should not be enabled by default, especially if a >> name service other than files is active, which may generate a far too >> long list of 'faces' to be useful. > > As has already been discussed, GDM does things to limit the number of > users shown in the Face Browser so that only users defined on the local > system with a valid shell defined in /etc/passwd are shown. If a > user actually logs in with a non-system account (e.g. via NIS), then > that user will be shown in the face browser on subsequent logins. > Ah yes. I recall Jon describing this. It just wasn't clear from your description. Not listing non-local users unless they are in ck-history is a good compromise between the needs of the standalone PC/laptop case and those of a server. >> 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. > 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. >> 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? 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. > 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). But if use of AutomaticLogin avoids this in cases that don't need it at all, that addresses an important part of my concerns. Thanks for responding. - J?rg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth at sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
