Registrating a client with non Ascii character title fails
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Landscape Client |
Fix Committed
|
High
|
Mitch Burton |
Bug Description
Hey,
I was playing a bit with landscape trying to register my systems.
The German word for "office" is "Büro" and e voila, when trying to use that I go this:
$ sudo landscape-config --computer-title "Dev Laptop Büro" ...
<selecting defaults in any of the questions as they do not matter>
'ascii' codec can't encode character '\xfc' in position 193: ordinal not in range(128)
Aborting Landscape configuration
Well, that should be better.
It is fine that you do not accept non ascii chars.
But a user should not need to run through all of the questions just to be denied and not even be told which field/setting it was.
Suggestion:
$ sudo landscape-config --computer-title "Dev Laptop Büro" ...
Error: sorry, only ascii characters are allows in the computer-title
Value: "Dev Laptop Büro"
Issue: ^
The full visualization is important as there can be less obvious ones, especially for people not so used to different language sets.
Here an example:
$ sudo landscape-config --computer-title "АAAAА"
It is slightly visible in chrome here, but absolutely identical in my console.
The first and the last A are actually Cyrillic A.
So an error like this would help a lot more than just telling "this is bad":
Error: sorry, only ascii characters are allows in the computer-title
Value: "АAAAА"
Issue: ^ ^
Changed in landscape-client: | |
assignee: | nobody → Mitch Burton (mitchburton) |
status: | Confirmed → In Progress |
Changed in landscape-client: | |
status: | In Progress → Fix Committed |
There's actually no good reason not to accept valid utf-8 as the computer-title. Our message schema declares the title as unicode, and it is stored on the server side as unicode.
This bug exists because when we write the provided config to /etc/landscape/ client. conf we assume the encoding of that file is ASCII. We shouldn't need to make this assumption, and should instead enforce ASCII-ness on a per-field basis (as we do for other types, such as fields that must be integers, etc).