It does seem like something strange is going on with your settings.  Note in gdm2/slave.c that there is a function gdm_parse_enriched_login which does support some mangling of your username if it is turned on - which you may have done accidently.  

Could you turn on debug in GDM (set Enable=true in the debug section or use gdmsetup), and re-run gdm by running gdm-restart.  Recreate the problem and see if the log has any useful messages.  Note gdm_parse_enriched_login sends debug output, so if it is being called we could tell from the log.  It might help me debug your problem if you could attach a log.

Also, note that normally gdm_verify_user is passed in NULL for the username, which means that your PAM module is expected to remember what username was passed in.  This could also be a PAM problem if it is misconfigured.

Nothing special to the log:
localhost gdm[9105]: gdm_slave_wait_for_login: In loop
...
6 seconds after that:
localhost gdm[9105]: Impossible d'identifier l'utilisateur
("Couldn't authenticate user")
localhost gdm[9105]: gdm_slave_wait_for_login: end verify for ''
localhost gdm[9105]: gdm_slave_wait_for_login: No login/Bad login
gdm[9105]: gdm_slave_wait_for_login: In loop

etc

The unknown "Linux" user problem come from an incorrect french translation
http://bugzilla.gnome.org/show_bug.cgi?id=334644
It's fixed in gdm 2.14.2

Thanks, marking this as Fixed.

the issue is not the user name but the "authentification failed", reopening

I use timed login too, 8 seconds. When I open a nested gdm, there is timed login and I have
8 7 6 5 4 3 2
and hop, it returns to 8
8 7 6 ..
indefinitly.
If I remember well, gdm 2.8.x didn't have timed login for a second instance of GDM...

still having that issue with gdm 2.16.1
* open gdmsetup
* activate timed login for an user
* open gdmflexiserver --xnest
the screen displays a message saying that the user <blank> (there is no user name written) will connect, login fails and the counter starts again, login fails and the counter etc

the issue is specific to gdmflexiserver, the normal gdm screen uses the correct user

How does it work when the timedlogin user is set to a hardcoded username.

Does it really make sense for TimedLogin to be enabled when run in Xnest mode?  It seems to me that this only really makes sense for the console.  Perhaps we should disable timedlogin completely if GDM_TIMED_LOGIN_OK isn't set?

I think part of the problem here is that the feature to allow the timedlogin to be a script that returns potentially different usernames was probably added without considering how it would impact xnest.  With the current code, the daemon slave evaluates the TIMED_LOGIN value so that the GUI can use it.  However, when launching via gdmflexiserver, the slave isn't in the picture so the evaluation is not done.

I guess another way to fix it would be to make gdmflexiserver evaluate the TimedLogin value and set the environment variable in case the GUI wants to use it?
Though again, I'm not sure this feature really has value to xnest sessions.

I think it makes sense to do no timed login with xnest

I ran into this trying to configure a machine to drive two displays,
but one at a time.  The displays have no keyboards, so I'm using
autologin and timed login.  I configured two X servers to start on
separate VTs.  The first one autologin's just fine, the second one
exhibits the bug described above - "authentication failed" and an
endless loop of failed timed logins.

The idea behind the config, btw, is to use chvt to quickly switch
between the displays, which require different X configs.  It all
works nicely except for the failed auto(timed)login.

I also get this Bug with a machine having 4 displays,
4 mice and 4 keyboards.
I made a workaround in 
gdm-2.14.10/daemon/verify-shadow.c line 98-101
so that for the displays :1 :2 :3 an username will be returned
without checking the pasword.

It seems that I found the solution:
In daemon/gdm.c comment out line 260

old
------------------------
if (gdm_first_login)
    d->timed_login_ok = TRUE;
-----------------------

new
-----------------------
//if (gdm_first_login)
    d->timed_login_ok = TRUE;
-----------------------

As far as I understand the issue, Bernt has one PC with 4 displays, mices and keyboards connected. 

This would be a typical configuration for an internet cafe because only one pc has to be bought which runs 4 X-Sessions (each display displays one). So, he runs into a problem because of the if clause.


On the other hand, the if clause is there, because 

a) It would create problems if one user is logged in several times (at least gdm says so when trying this manually)
b) User Peter may want to log in with another account and does not want the timed login to be there

But this creates an issue for Bernt.

So I would suggest to do the following:

a) Add a configuration option "Use auto login / timed login on all displays"
b) Add a configuration option "Autologin with the username X + the display number" (Maybe I should add a feature request about this)

All guesses without warranty ;-)

Ah, good catch.  I'd say that the code in comment #13 is the right way to hack the behavior you want.

The right way, if you want this integrated in GDM, would be to add a new configuration option in gdm.conf.in that allows the user to specify whether TimedLogin only works on first login or all logins, with the default being first login.  

I'm happy to help you modify the code to make this change in a way the code can go upstream if you want.  I'd read the comments in daemon/gdm.h that explain how to make this change.  Note that the steps that say "if the option should cause the greeter program to be updated" and "Add the key to gdm_read_config and gdm_reread_config" would not apply to this change since this
configuration option would only be used by the daemon.

If someone want to have timed loginand has more than one display,
he usaly use a script for building the username.

TimedLogin=/usr/bin/myloginscript|

I think this possibility exist for a longer time than the line 
with gdm_first_login, because with ubuntu breezy I had not this bug!
But to verify this I should search for the old source ;-)

So, I dont think, that we need this if clause.
- If a user tries to login twice manually he gets a warning.
- If there is more than one display the right configuration entry
  is something with a script or %d %h for display and host.

It's a waste of time to search for old source ;-)

I lived a long time with a hack in daemon/verify-shadow.c
that produces the username as the script would do.

The best would be to have a configuration option in gdm.conf.in
_and_ some hints how to use a script or %d and %h to make
different usernames for timed login.

Also gdmsetup should be enhenced whith this hints and the new config option.

Bernt, you can get the Breezy source at http://archive.ubuntu.com/ubuntu/pool/main/g/gdm/gdm_2.8.0.5.orig.tar.gz

> The best would be to have a configuration option in gdm.conf.in _and_ some hints > how to use a script or %d and %h to make different usernames for timed login.

Definitly, I think that it may be useful for schools using GNOME which do not want to create a user account for each student, also.

:::

I will have a look at Gdm this evening, but do not except too much since I do not have lots of hacking skills.

I am somewhat confused.. I commented out "if (gdm_first_login)", recompiled gdm, told gdm to autologin after 5 seconds and restarted gdm.

But in the second X session, gdm still does not count down.

Ideas?

Okay, I shot my GDM now somehow. At an other computer, it works nicely.

Okay, I now added a configuration option called FORCE_TIMED_LOGIN which can be true or false and GDM recompiles fine so far.

My problem is that I want to extend

if (gdm_first_login)

in daemon/gdm.c with || VAR so that it goes ahead with the timed login if the configuration option is enabled.

But I do not know how to query the configuration value.

Could you give me any hints, please?

Excellent.  Glad to hear that you are working on this.  The steps in the comments in gdm.h are helpful.  I'd prefer the key to be named something more clear.  Let's call it TimedLoginFirstDisplay with the default value being true.  If users set it to false, then it will work for all displays.  I think this config value best belongs in the "daemon" section since it only affects the daemon and this is where the other TimedLogin values are.

Step 1)  Add a #define to daemon/gdm.h.  Probably something like this:

#define GDM_KEY_TIMED_LOGIN_FIRST_DISPLAY "daemon/TimedLoginFirstDisplay=true"

Step 2)  Add some code to daemon/gdmconfig.c to make the config value available

This includes adding a new static gboolean to the end of the list that starts at line 161 and adding a gdm_config_add_hash call to the list of calls that starts at line 356.

Since this key only affects the daemon, you don't have to muck around with the update functions.  These are needed to let the GUI know the value changed so it can be restarted.  But since this key only affects the daemon, no need for this.

Step 3) Now access in daemon/gdm.c

You should be able to access like this:

    if (gdm_get_value_bool (GDM_KEY_TIMED_LOGIN_FIRST_DISPLAY) {
       do what you want if the value is "true"
    } else {
       do what you want if the value is "false"
    }

And that is all.

In other words.  Just add a #define to the header, 2 lines of code to daemon/gdmconfig.c, and the above sort of if-test in daemon/gdm.c.  Then it should work.

Aside from this you need to modify config/gdm.conf.in to add the new key with the default value and a comment to explain what it does.  Also modify docs/C/gdm.xml to mention the new key in the "Configuration" section where the other keys are documented.  This is in SGML format so it should be easy to see how to add docs in the same style as the rest of the docs.  If you have trouble with this, I can help.

Note you will need to restart the daemon to notice a change to the config value.  Do this by running gdm-restart.  Note this will log you out of any running sessions so don't do this when you have unsaved data in the desktop.  If you don't want to restart, you can make the daemon re-read the configuration value by running:

  gdmconfig --command="UPDATE_CONFIG key"

where key is "daemon/TimedLoginFirstDisplay'

Then if you run 

  gdmconfig --command="GET_CONFIG key"

it should tell you the new value in the config file.

Then future GDM GUI's should work in the TimedLogin way you expect.

Note this is a UI change so it can't go into GDM 2.17 but I will put the modification into 2.19 after 2.18 is released.  Unless you think there is a real need for it before then, we can discuss getting approval for this.

Brian, I am glad that you help me so much.

Many thanks for doing so, I will try to do the change this evening.

First patch against gdm 2.16.1 (:-(() attached.

::

Sadly, I am not able to test this myself. I used to make the changes, create .debs , install them and restart Gdm. This worked one time. Now, when I install the changed .debs and restart Gdm, nothing changes (already tried full system reboots).

Also, when I install the Gdm .debs from my distributor and restart, nothing changes (timedlogin on all sessions)..

And I do not know why :-(

Nevertheless, the patch should theretically work. It would be nice if you could try it and make suggestions what can be better.

Thanks, Martin

Created attachment 81215 [details] [review]
patch #1

Can you please test this a bit more.  I'd prefer to not put your patch upstream
if we aren't sure it works.  Could you try to verify that this patch actually works right?  Can you run the following commands:

gdmflexiserver --command="GET_CONFIG daemon/TimedLoginFirstDisplay"

this should say "false" if you think it is being set to false.  If it is false, then it there is probably a bug if this isn't working.  If the above command is returning a "key not supported" error, then you probably have an issue where the GDM that is being started isn't the same GDM with the patch.  If so, your system might have more than one GDM installed on the system?

If the above value says true, when you think it should be false, then double check the config files.  Run these two commands:

gdmflexiserver --command="GET_CONFIG_FILE"
gdmflexiserver --command="GET_CUSTOM_CONFIG_FILE"

These two commands should tell you what configuration files you are using.  Note the "custom config file" takes preferences over the default config file.  So make sure that something weird isn't happening (like you set it to false in the default config file, but it gets set to true again in the custom config file).

Some comments:

+ Note that the docs for how a "piped script" works is in the AutomaticLogin
  configuration key.  Probably the new TimedLoginFirstDisplay should tell 
  the reader to read the docs for this key to understand how to write a
  "piped script".  Might be nice to slightly reorganize the docs so piped
  scripts are described in a separate section (instead of the AutomaticLogin
  key) and have all keys (e.g. TimedLogin/TimedLoginFirstDisplay/AutomaticLogin)
  that support piped scripts refer to the separate section?  Might also be nice
  if the docs explained why a user might want to use a script for Automatic or
  Timed login in the first place.

+ In gdm.conf.in you should set to "true" instead of "True" for consistency.
  "True" should also work, but all other configuration values use lower case
  so lets follow the standard.  The comments in gdm.conf.in should probably
  also mention the piped script feature for AutomaticLogin/TimedLogin/
  TimedLoginFirstDisplay, don't you think?

Brian, I now know why my tests did not work.

In gdm 2.17, the following has been introduced:

    if (!ve_string_empty(str->str) && gdm_is_user_valid(str->str))
	    return g_string_free (str, FALSE);
    else
    {
        /* "If an empty or otherwise invalid username is returned [by the script]
         *  automatic login [and timed login] is not performed." -- GDM manual 
	 */
	/* fixme: also turn off automatic login */
	gdm_set_value_bool(GDM_KEY_TIMED_LOGIN_ENABLE, FALSE);
	d->timed_login_ok = FALSE;
	do_timed_login = FALSE;
	g_string_free(str, TRUE);
	return NULL;
    }
}


Since I only checked if the countdown appeard with an user and not with a piped script, the code blocked my experiments :-)

Except a working patch shortly :-)

Great.  Looking forward to putting this upstream.  I think this is a nice feature.

Could you also test how AutomaticLogin works?  Does it make sense for it to also work in this way?  If so, should we add a configuration value for it as well
(or use the same one)?

Brian, many thanks for helping me so much. I think that I learned a lot.

But sadly, I can not get it working. 

In gdm 2.16, I can uncomment if (gdm_first_login) and this results in the right behavior.

In gdm 2.17, I can uncomment it but without any result because there probably are some new checks added which I do not find.

Additional, in gdm 2.16, my if clause (see patch) does not work.

gdmflexiserver --command="GET_CONFIG daemon/TimedLoginFirstDisplay"

returns the correct configuration item and I find it logical that it should work.


Thanks for being so patient and helpful, but I fear that it resulted in nothing :-(

I now have a limited amount of time (classtests) and I do not really know what's wrong (it would be really appreciated if you could have a look at the patch). 

I am happy if someone else wants to take this bug, otherwise, I can still try of course.

I'm sorry to hear that you weren't able to get this patch finalized.  I'm not sure when I'll have time to look into this, but if some other user is interested in seeing this feature in GDM, then I'd be happy to commit this upstream if someone gets it working.

Jeff Stockett reported on gdm-list@gnome.org that you can hack GDM to work with multiple autologin by commenting out hte below line in daemon/gdm.c

>     } else if (d->type == TYPE_STATIC &&
> /*             gdm_first_login && */
>                ! ve_string_empty (ParsedAutomaticLogin) &&
>                strcmp (ParsedAutomaticLogin, gdm_root_user ()) != 0) {
>             gdm_first_login = FALSE;
> 

I have made a patch that makes auto/timed logins work for multiple displays.  The timed login (now that I look at it more closely) seems to be the same as the other patch found here.  It is a bit flaky during startup, but seems to work okay after that.

Created attachment 91476 [details] [review]
patch to allow auto/timed login from multiple displays

May need to add the new configuration options to the GUI, timed login seems flaky on startup.

Eldon.  Thanks for the patch.  Some thoughts about the patch...

1) This patch is against 2.18 and not 2.19.  The patch would require a bit
   more work to compile against the latest SVN 2.19 code.  

2) I'm not sure that users would ever want to use both automatic and timed
   login at the same time.  Your patch adds two new configuration options - 
   one for timed and one for automatic login.  Would it make sense to just offer
   one configuration option that works for both?   Or do we want to think about
   making GDM more sophisticated and support the ability to do things like
   support timed login on some displays and automatic login on other displays?

   I'd appreciate some discussion about this.  What level of functionality do
   people think would be useful?  Also, what do people think the best way to
   support this in the configuration file?

3) You say that timed login is "flaky".  Could you explain in detail what
   problems you are seeing?  If you have found a bug, please let me know about
   it so we can look into fixing it.  Also, please explain what you mean by
   "May need to add the new configuration options to the GUI."  Why do you 
   think this would help to fix the problem of it being flaky?

I know I have used both automatic and timed login at the same time, but I don't see a case where someone would want automatic login on only the first display and timed login on all of them (or any combination of these).  It would make more sense to have a single configuration item.  I can't think of a reasonable name for it, though... 'AutoOrTimedLoginFirstDisplayOnly' seems a bit long ;).  Are there other features that are enabled for the first display only?

The timed login seems to be working.  I'm not sure what was going on the other night.  My mouse is really sensitive, and I was probably leaning on the desk, or maybe it doesn't work right if you switch between VTs before it logs in.  I'll have to look at it some more.

The new configuration item for the GUI was not to help with the flakiness, I am just not sure whether this falls in the 'advanced usage, does not belong in the graphical configuration tool' category.  Sorry for the lack of clarity, it was late ;).

I'll try to take a look at CVS later this week, maybe after deciding on a name for the new configuration item.

Okay, thinking about this a little more.

One suggestion is that I just modified GDM 2.19 so it the [servers] section is
like this:

[servers]
0=Standard device=/dev/foo

This allows you to specify the device to pass along to utmp accounting for the
display :0.

Perhaps we could enhance this as follows:

0=Standard device=/dev/foo type=authreq|auto-timed

With authreq (user authentication required) being the default value if type 
is not specified.  If the value is auto-timed, then it will use timed login 
in TimedLoginEnable is true or automatic login if AutoLoginEnble is turned on.
Does this approach make sense?  

You could look at how I implemented the device=/dev/foo code in daemon/gdm-daemon-config.c if you wanted to implement this.  I think this is
a better approach than having a "AutoOrTimedLoginFirstDisplayOnly" feature and
also allows users to turn on automatic/timed login on a per-display basis. 
which is nice.

What about something like:

0=Standard device=/dev/foo auto=username timed=username[:timeout?]

and get rid of the 'AutomaticLogin' and 'TimedLogin' options to avoid confusion?

It seems like the most common script you see just maps a display to a username, and this could eliminate much of the need for such scripts (but they could still be allowed).

I often use both automatic and timed login together to avoid waiting for the timeout on boot.

Yes, I like your suggestion.  GDM should still support the older configuration options if they are present in the configuration file, but we could use the
new configuration options going forward.

To make this work properly, though, gdmsetup would also need to be modified to use the new configuration mechanism.

>To make this work properly, though, gdmsetup would also need to be modified to
>use the new configuration mechanism.

I think most of the gui stuff is already in place. The xserver configuration dialog (Servers to start treeview) already contains column Options that the information can be appended to (it might require a vertical scrollbar as the info will be too long to display). What needs to be added:
1. Add Modify dialog needs autologin and timed login widget entries (hopefully moved from security tab) - device= switch could go into options (or is additional entry needed for that?)
2. All the logic that deals with updating auto/timed login (w.r.t included users and minimalUID) would have to be adjusted accordingly

Sounds good.  Is someone willing to take the provided patch and modify it so it works as suggested?  It sounds like Lukasz is willing to update gdmsetup if someone else is willing to do the rest of the work.

I would be willing to do so, but I'm not sure where to put variables for the new-style configuration.  Does it belong in the same structure as the 'device' parameter, or is there a better place to put it?

Note the function load_xservers_group in gdm-deamon-config.c.  Note it has logic like this:

                if (value_list[1] != NULL &&
                    strncmp (value_list[1], "device=", strlen ("device=")) == 0)
                        device_name = value_list[1] + strlen ("device=");

Currently it is hardcoded to only check item 1 for the "device" key.  Probably this needs to be made into a loop and look for different keys, not just device.
Then note that we pass the xserver->device value into gdm_display_alloc so it gets added to the display structure for future reference.  You probably need to do something similar.

Refer to similar bug #475477

Hello, we have a project called multilinux to support digital inclusion in Brazil and developing countries, which in practice and mount multiterminais using only a cpu + 4 keyboards and mice + 4 monitors, the project can be viewed at the following link. But like a help, because in a laboratory with several terminals it is important that all terminals have automatic log in each CPU have 4 terminals with 5 users registered, 1 in 4 users root, but I want to 4 users had automatic login when connecting the CPU.

OS - Ubuntu 7.04

link project : http://www.ronaldcosta.pro.br/sistemas/wiki/index.php/Multiterminais_Ubuntu_7.04

Since you already.

	
Hello after reading all topics, it seems that this patch solves my problem cited in the previous topic. Then I want a detailed explanation of how to apply this patch.

Thanks.

Marcio,

That patch was a work in progress, and I'm not sure it was ever finished.  Nobody found the time to test it to make sure it works properly.  It also may not apply to the latest GDM code.  If not, it would require some work to get it to apply again.

Sorry, but patches like this that have not made it upstream are not supported.  If you want to work to try to get this working, then there will likely be work involved.

Note that GDM 2.21 is a complete rewrite.  I am aware that Jon McCann is currently working to add autologin features into the new codebase.  So hopefully this issue will be resolved going forwards in a different way.

syntax of gdmdynamic autologin suggestions?

For example, I could do something like:

gdmdynamic -a "AutomaticLogin:user TimedLogin:user TimedLoginDelay:NN 1=/my/fave/X -some -x -options"

and then I could parse parse this up to the first occurence of [0-9]\+=

I think it would be easy enough to splice this into gdm.c near

if (type == DYNAMIC_ADD) {
...
disp = gdm_display_alloc (disp_num, val, NULL);
[load up the values parsed above into disp]
gdm_daemon_config_display_list_insert (disp);

Does this make sense?  This would provide a framework for gdmdynamic using almost any option that is available to gdm static.

I don't think the right fix is to add arguments to gdmdynamic.  If we fix GDM so that you can specify that automatic timed login should work for a particular display number, then it should work regardless of whether the display was started via gdmdynamic or not.

Can someone please tell me what the difference between autologin and timed login is supposed to be, and why they can't be merged?

I'm working on laptops for schools with a locked-down student account, I want this to log in automatically after a time delay whenever no user is logged in, but an admin can override this and log in instead.

At the moment it appears that I have to install a patched gdm on all the laptops to achieve this. Comment #13 seems not to apply to gdm 2.30.5. Please can we do something better than completely disable automatic/timed login after the first login?

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdm/issues/2.