Description of problem:
If the authentication settings in /etc/beaker/labcontroller.conf are wrong (for example mistyped password or wrong user acocunt) the lab controller daemons start successfully but don't work properly.

The root of the problem is that kobo does not raise an exception if it fails to authenticate to the hub.

Version-Release number of selected component (if applicable):
0.15.4

How reproducible:
always

Steps to Reproduce:
1. Edit /etc/beaker/labcontroller.conf to have wrong settings in AUTH_METHOD, USERNAME, and/or PASSWORD
2. Restart the daemon (bug applies to beaker-proxy, beaker-provision, beaker-watchdog, beaker-transfer)

Actual results:
The daemon starts up, logs a message about failing to authenticate, and then keeps running but fails to do anything useful. For example, beaker-watchdog will loop failing to fetch watchdogs:

kobo.client.HubProxy INFO Creating new session...
kobo.client.HubProxy DEBUG Failed to create new session: <Fault 1: <class 'bkr.server.authentication.LoginException'>:Invalid username or password>
bkr.labcontroller.watchdog ERROR Traceback (most recent call last):
   File "/usr/lib/python2.6/site-packages/bkr/labcontroller/watchdog.py", line 42, in main_loop
     expired_watchdogs = watchdog.hub.recipes.tasks.watchdogs ('expired')
   File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
     return self.__send(self.__name, args)
   File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
     verbose=self.__verbose
   File "/usr/lib/python2.6/site-packages/bkr/labcontroller/proxy.py", line 55, in request
     result = transport_class.request(self, *args, **kwargs)
   File "/usr/lib/python2.6/site-packages/kobo/xmlrpc.py", line 432, in _request
     return self._parse_response(h.getfile(), sock)
   File "/usr/lib64/python2.6/xmlrpclib.py", line 1392, in _parse_response
     return u.close()
   File "/usr/lib64/python2.6/xmlrpclib.py", line 838, in close
     raise Fault(**self._stack[0])
 Fault: <Fault 1: <class 'bkr.common.bexceptions.BX'>:No lab controller passed in and not currently logged in>

Whereas beaker-proxy will start but then fail every request it receives.

Expected results:
Daemon should refuse to start with a suitable descriptive error message indicating what the problem is, so the admin knows that the configuration is wrong.

Additional info:
This problem has existed in Beaker for a very long time. I first tried to fix it back in 2011:

http://gerrit.beaker-project.org/824

but the fix was blocked by the Kobo issue noted above (filed as bug 753006, as yet unfixed). However now that we are no longer using Kobo we are in a position to fix this.