Re: bodhi CLI and USERNAME
On 10/19/2017 04:09 PM, Randy Barlow wrote:
Greetings fellow Fedorans,
We're about to release Bodhi 3.0.0[0] upstream, which has a backwards
incompatible CLI change[1] that I am considering backporting to the
stable Fedoras, but I wanted feedback first before I do that.
The Bodhi 2 CLI will use the USERNAME environment variable when
authenticating you, if present, and the Bodhi 3 CLI[3] does not use any
environment variable (yet) for authentication. Here's the reasoning:
* The Bodhi 2 CLI previously didn't have the ability to remember your
username, but it did have the environment variable, which kind of
acted like a bandaid. I believe this variable was in place before I
got involved.
* The CLI got a lot of love earlier this year, and one of the big things
added was the ability for it to remember your username if you've ever
successfully authenticated before. This feature largely removed the
need for the environment variable, but keeping the variable seemed
harmless at the time.
* I recently learned that the variable is painful for some users,
because GDM sets this variable to your local system's login username,
which is not necessarily the same as your FAS username.
* When the username is present, Bodhi will not prompt the user for their
username, which leads to a very poor experience upon first login for
GDM users who have mismatching FAS account names (Bodhi prompts for
their password and then tells them it's wrong). Without the variable,
Bodhi will prompt users to enter their username upon first use.
* Users can currently override the USERNAME environment variable with a
--user flag as a workaround.
* Though it may seem that Kerberos addresses this problem, Bodhi does
not use Kerberos (it uses OpenID) and there are not plans to adjust
Bodhi to use Kerberos because we plan to convert it to use OpenID
Connect instead.
In order to address the above, and in the spirit of working quickly due
to the other pressures to complete 3.0.0, it was easy enough to just
drop support for this environment variable with 3.0.0, since 3.0.0
already needed other backwards incompatible changes. However, I have a
few questions for the list:
0) Do you have a use case for an environment variable to set your
username? If there is sufficient demand for this feature, we can add
it back with a different name in a future Bodhi 3 release (perhaps
BODHI_USER or FAS_USER would suffice).
1) I'd like to make a backwards incompatible patch for the stable
Fedoras so that GDM users get a better experience without having to
wait for Fedora 28, but I don't want to do this if it is too
disruptive. Normally I am quite against backwards incompatible
changes in Fedora, but this can also be viewed as a painful bug and
fixing the bug might alleviate more pain than the change would
cause. Would such a change be a disruption to us developers, or does
the good outweigh the bad?
A few options for F25-27:
0) Do nothing, and let Rawhide be the only place this change happens.
1) Drop USERNAME.
2) s/USERNAME/BODHI_USER/ or similar.
Thoughts?
I don't think this change will affect my workflow at all. That said,
I've had this in my .bashrc for a while:
# Used by /usr/bin/bodhi at least
export FAS_USERNAME="crobinso"
And checking f25 dist-git bodhi code gives:
$ git grep USERNAME
bodhi-0.9.12.2/bodhi/tools/client.py: return
os.getenv('FAS_USERNAME', getuser())
bodhi-0.9.12.2/docs/bodhi.1:.IP "\fB\-u --username\fP USERNAME"
So indeed seems like the historical env name here is FAS_USERNAME, and
the switch to USERNAME is only in f26+ bodhi era code. I think that
changes a lot of the above dynamics. Maybe just switch the stable
branches back to FAS_USERNAME which avoids the GDM issue
Thanks,
Cole