On Mon, Mar 27, 2017 at 7:33 PM, Graham Leggett <[email protected]>
wrote:
> [...]
>
> Gdb runs fine, but the source code is missing (on Redhat the source is
> part of the debuginfo packages, don't have as much ubuntu experience,
> can you confirm what package the source can be found?)
>
You can use "pull-lp-source" from the package ubuntu-dev-tools to get the
source.
[...]
So, the failure is triggered by the following:
>
> 51 c = setlocale(LC_ALL, "");
> (gdb)
> 52 if (c == NULL) {
> (gdb)
> 53 return EIO;
>
Ack, thanks for tracking that down with me.
> Which is in turn fixed by https://pagure.io/SSSD/sssd/issue/2785 (or
> something similar to that).
>
Now that we understand better what is going on I can agree.
Out of that issue the "fix" is this commit:
https://pagure.io/SSSD/sssd/c/43e06ff39584570817949dc5de118d
2b7ca854c1?branch=master
The rest is adding testcases, debug messages and so on.
The actual fix is just to report a message and ignore the error if the
set_locale failed.
So not rocket science, but I agree that we have to wonder why it happens on
your box suddenly.
> According to the man page of setlocale(), NULL is returned when the
> locale cannot be found.
>
[...]
The env check was good, is just calling "locale" output the same on good &
bad systems as well?
We could try to regen-the locale by calling:
$ sudo locale-gen en_US.UTF-8
Might that fix it for you?
Also since you auto-deployed the content should be the same, so we might
just as well check all of /usr/share/locale if the files match.
$ find /usr/share/locale/ | sort | md5sum
Is that the same on both systems, if not what is different?
If the former is the same still some of the files might differ, you could
(lengthy) compare:
$ md5sum $(find /usr/share/locale/ | sort)
> It is possible that the broken locale is a red herring, and the cause of
> the problem is something else. The /var/log/auth.log shows this on the
> broken machine:
>
> Mar 27 17:24:43 yyy-bastion01 sshd[1624]: pam_sss(sshd:account): Access
> denied for user minfrin: 6 (Permission denied)
> Mar 27 17:24:43 yyy-bastion01 sshd[1624]: fatal: Access denied for user
> minfrin by PAM account configuration [preauth]
>
It could of course be a red-herring, yet one that we can try to understand.
It could just as well be that due to that similar issue with the locale on
the auth it takes an exit path with a bad rc which is reported as
permission denied.
So the herring doesn't have to be red.
On your check with LANG set, you could try if the following works instead
and report back?
$ LC_ALL="en_US.UTF-8" /usr/bin/sss_ssh_authorizedkeys minfrin
Finally - after all the tests above to destroy our testcase as late as
possible - you can try this ppa.
It contains an sssd with the related fix that ignores the set_locale fail
and just goes on.
That should at least help to find if fixing the locale issue was indeed a
red herring or not.
=> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2655
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1675118
Title:
Setting locale breaks sss_ssh_authorizedkeys: set_locale() failed (5):
Input/output error
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1675118/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
