ldminfod and broken UTF-8 sequences

[Kim B. Heino]

Commit d3ab0dc8674e5 added decode() calls to "locale -a" parsing. decode() without any parameters equals to decode('utf-8', 'strict'), which will generate UnicodeDecodeError for non-UTF-8 input.

RHEL7's "locale -a" outputs such non-UTF-8 line:

fran<E7>ais

(That's "français" in ISO 8859-1 encoding)

Until RHEL7 gets fixed (might take years) this can be fixed in ldminfod by changing 'strict' to 'ignore'. Patch:

https://git.launchpad.net/~bcgss/ltsp/+git/ldm-rhel7/commit/?id=4750159ebfaacc8d530a9447f116f9f9b2832e47

[Vagrant Cascadian (vagrantc)]

On 2018-01-06, Kim B. Heino wrote:
> Commit d3ab0dc8674e5 added decode() calls to "locale -a" parsing.
> decode() without any parameters equals to decode('utf-8', 'strict'),
> which will generate UnicodeDecodeError for non-UTF-8 input.
>
> RHEL7's "locale -a" outputs such non-UTF-8 line:
>
> fran<E7>ais

Wow, Debian's "locale -a" only outputs the locale codes, e.g.:

  $ locale -a
  C
  C.UTF-8
  POSIX
  en_US.utf8

So that's why I was unable to confirm the issue on Debian.

I suspect there are other cases where this type of fix is needed,
though.

> Until RHEL7 gets fixed (might take years) this can be fixed in ldminfod
> by changing 'strict' to 'ignore'. Patch:
>
> https://git.launchpad.net/~bcgss/ltsp/+git/ldm-
> rhel7/commit/?id=4750159ebfaacc8d530a9447f116f9f9b2832e47

Thanks for the patch!

live well,
  vagrant

[Alkis Georgopoulos (alkisg)]

Closing old LTSP bugs as they're no longer relevant after LTSP has been rewritten from scratch.