Closed GijsTimmers closed 8 years ago
Some things to think about before coding:
kotnetcli
on startup? We store the credentials in the keyring, which is only unlocked after logging in! In theory, we could make kotnetcli
read the credentials from a file in the /etc
directory with root access only, as systemd
is run as root. But is this still worth the effort? kotnetcli
will ask to enter in the credentials, but this will probably not happen while starting upkotnetcli
binary may be installed on different locations across different distros. We can find out its location by running this piece of code:import distutils.spawn
distutils.spawn.find_executable("kotnetcli")
An alternative is hardcoding the desired location in setup.py
, so that kotnetcli
is in the same directory on every distro. I'd rather not go with this approach, though.
kotnetcli
from systemd
should be as small as possible. The problem is that sometimes, the login process is very slow. We already have a BROWSER_TIMEOUT_SEC
variable, in place, but this timeout is only used when checking whether we're on the Kotnet network. It's possible that this check performs quickly, yet the login process as a whole is slow. I propose to create two new variables:BROWSER_CONN_CHECK_TIMEOUT = 1.5
: limits the amount of time that kotnetcli
may use to check whether we're on the Kotnet network;
BROWSER_SEND_CRED_TIMEOUT = 5.0
: limits the amount of time that kotnetcli
may use to send the credentials.
As sending the credentials is usually the 'speed determining step', I propose to put a limit on this step, rather than creating a mechanism that times every part of the login process.
@jovanbulck : please share your thoughts.
Good points; some thoughts:
While accessing systemd from python seems to be fairly easy, I believe launching kotnetcli
this early is neither possible, nor desirable:
kotnetcli
depends on the desktop environment's keyring. As far as I can tell, it is not available this early in the booting phase. This makes sense, when considering that is should only be available after the user has successfully logged in (and maybe explicitly unlocked his keyring).kotnetcli
is too heavy-weighted and non-deterministic. As such, it might well introduce buggy behavior and unacceptable delays...Summarized, systemd
should in my opinion only be used for things that are (i) common for the entire system (i.e. not user-specific), and (ii) relatively lightweight. Currently, kotnetcli
is neither of those.
Of course, the user could add kotnetcli
to the auto-start applications for his or her specific desktop environments. (As far as I can tell, this would not require additional support from our side. Meaningful exit codes, as discussed in issue #55, will of course help shell-scripting users.)
Agreed.
When an Arch user boots his computer,
systemd
services are executed. It would be nice to create one for kotnetcli, for a seamless Kotnet login. An Arch user should run:to enable this startup script.
Ubuntu will be moving to systemd as well, so the core developers won't put effort in creating
upstart
scripts. That doesn't mean we don't allow these scripts; just open up a pull request if you've created one yourself and we'll gladly merge it.