Wait, I'm missing something.
In meta/python/lsst/qserv/meta/client.py, we have:
def _connectToQMS(self, host, port, user, pwd, xmlPath):
url = "http://%s:%d/%s" % (host, port, xmlPath)
qms = xmlrpclib.Server(url)
So... there's no authentication to the qms, right? Which is good: I
don't see any reason for any user/pass to the qms, at least until we
have qserv users. At most, we might have a shared secret code among the
qms, master, worker, and admin scripts. Anyway, I want to make sure that
there is no user-configurable user/pass between the master-meta or
worker-meta. Something we can do is autogenerate a shared-secret code
file and just make sure that the meta, master, and worker all have a copy.
I didn't see any code for handling HTTP user/pass in server.py, either.
Which is good.
The qms can care about authentication to its mysqld, so it can have
user/pass to its mysqld. I hope we agree that nobody outside of the qms
daemon (and its config) should know the mysql user/pass of the mysqld,
or even that the qms uses mysql. qms may need to execute GRANT, but the
client should have no knowledge.
-Daniel
On 05/20/2013 06:01 PM, Becla, Jacek wrote:
> Daniel
>
> Yes, qms is paying attention to authentication.
> See meta/examples/permissions.sql. qms needs a
> grant similar to that to properly function.
> The user/password used in that grant should
> be passed to the QmsClient, it is done in
> app.py, see MetadataCacheIface class,
> newSession function. If you want to bypass it,
> just do the grant without password...
>
> Jacek
>
>
>
> On 05/20/2013 05:52 PM, Wang, Daniel Liwei wrote:
>> Hi Jacek,
>>
>> In the config for the master, I see:
>>
>> [metaServer]
>> passwd = qmsPass
>> host = localhost
>> port = 7082
>> user = qms
>>
>> Do you have password protection on the qms? I thought we left the qms
>> open (no authentication) for now. If those are mysqld user/pass, then
>> I'm a little confused--why does the master care?
>>
>> -Daniel
>>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1
