checkbox won't run because of authentication issues when X unavailable

[Rod Smith]

I tried running checkbox on a system via an SSH login without X access. The result was a failure to authenticate with the message "Error executing command as another user: Not authorized". (See attached text output, which verifies X is not running and the fact that the account does have sudo access.)

[Zygmunt Krynicki (zyga)]

c-c-s has no debugging features (which should be a separate task to get all the small tools to behave correctly) but for the moment, please reproduce that with:

 plainbox --trace plainbox.ctrl run -w /path/to/whitelist

And attach ~/.cache/plainbox/logs/debug.log

Also add the output of `id`

Thanks

I suspect the solution will include a way for the execution controllers to say "I failed, try the next one in the list".

[Rod Smith (rodsmith)]

Typing "plainbox" results in a "command not found" error. After installing the "plainbox" package the command became available, but I got the following:

$ plainbox --trace plainbox.ctrl run -w /usr/share/checkbox/data/whitelists/hwsubmit.whitelist
===============================[ Analyzing Jobs ]===============================
Do you want to resume the previous session? [y, n] n
Estimated duration is 17.35 for automated jobs.
Estimated duration cannot be determined for manual jobs.
===============================[ Authentication ]===============================
Error executing command as another user: Not authorized

If I should be passing a specific whitelist file, please clarify.

The ~/.cache/plainbox/logs directory was empty. (I cleaned out ~/.cache/plainbox prior to making this attempt, so if you meant to get the log from my earlier run, it's gone.)

I did find that the following appeared in /var/log/auth.log when the authentication error occurred:

Feb 7 10:31:02 u1404d pkexec[6804]: rodsmith: Error executing command as another user: Not authorized [USER=root] [TTY=/dev/pts/20] [CWD=/home/rodsmith] [COMMAND=/usr/bin/plainbox-trusted-launcher-1 --warmup]

[Rod Smith (rodsmith)]

I've now tested with both the desktop and server versions of trusty and I get the same behavior with both. In other words, my initial description ("when X unavailable") is inaccurate; this seems to relate to remote (SSH) logins vs. local logins. Doing an "ssh localhost" from a console is sufficient to reproduce the problem, assuming the SSH server is installed.