[Linux-cluster] Problem with automating ricci & ccs

[Jakov Sosic]

On 01/18/2013 07:44 PM, Jakov Sosic wrote:
> On 01/16/2013 02:14 PM, Jan Pokorný wrote:
> 
>> The point here is that once the public certificate of ccs is recognized by
>> ricci as authorized by supplying the password within the initial session,
>> any other other session will be passwordless, based only on the "proved"
>> client's certificate.
>>
>> Your intention seems to be to skip the initial phase involving password,
>> is it the case?  This should be doable by forcing ccs to generate its
>> certificate by doing some NO-OP, then copying (scp?) the public part
>> to the predefined destination at the machine with ricci installed,
>> e.g.:
>>
>>   [root at client1]# ccs -h localhost -p IGNOREME --getconf &>/dev/null
>>   [root at client1]# PUBLIC_CERT=~/.ccs/cacert/pem
>>   [root at client1]# RICCI_CLIENTS=/var/lib/ricci/certs/clients
>>   [root at client1]# UNIQUE_SUFFIX=$(hostname | sha1sum | cut -b1-6)
>>   [root at client1]# RICCI_CERT=${RICCI_CLIENTS}/client_cert_${UNIQUE_SUFFIX}
>>   [root at client1]# scp $PUBLIC_CERT riccihost:$RICCI_CERT
> 
> Thank you for your explanation. I've figured that out later myself :)
> 
> So, instead of using the sha1sum to avoide collisions, I use nodename.
> So my client_cert names look like this:
> 
> client_cert_mynode1
> client_cert_mynode2
> ...
> 
> Is this ok? Or should I obfuscate name for some reason...
> 
> 
>> Surely, the first step can be substituted by either using pregenerated
>> certificate + key on the locations expected by ccs (~/.ccs) or
>> generating them explicitly (e.g., by "openssl req") as part
>> of the process.  The point is that css-local and ricci-tracked
>> certificate (one of presumably many) matches.
> 
> I've done this by pre-generating the certificates on my puppet master.
> 
> 
>>> I'm building puppet module which will autoconfigure whole cluster from bare
>>> metal to working state. So far my only problem is updating cluster.conf, for
>>> which I need fully working ricci CA and user certificates in /root/.ccs of
>>> every node...
>>
>> By any chance, are you willing to share the module or its skeleton
>> to the community?
> 
> Offcourse, as soon as I'm happy with the code and the level of
> functionality. We have around dozen clusters, I'm developing this module
> on a new one that's supposed to go into production soon. Other clusters
> use older module which really doesn't solve any of this, so as soon as
> my code is stable we'll push other clusters to new puppet module. After
> that, I will publish it. So expect it in another week or two.
> 
> 
>> Hope the above helps.
> 
> Yeah, it really did help. But, for some strange reason it seems that
> ccs_sync doesn't use certificates, but instead it asks for password...
> 
> My idea was to use ccs_sync to propagate new cluster.conf. So, puppet
> puts cluster.conf in /etc/cluster.conf, and after that runs ccs_sync -f
> /etc/cluster.conf
> 
> But unfortunately, ccs_sync doesn't seem to recognize the certificates
> as ccs does :( Any idea on this one?
> 
> pgsql01-xc # ccs -h pgsql01-xc --getversion
> 2
> 
> pgsql01-xc # ccs_sync -f /etc/cluster.conf
> You have not authenticated to the ricci daemon on pgsql01-xc
> Password:
> 
> 
> I'm digging into source code to try to get some sense of it :-/

It seems that ccs_sync run as root uses /var/lib/ricci/cacert.pem as
it's own client certificate...


Do you think if it's OK to use same client certificate for root user
(/root/.ccs/cacert.pem) and for ricci user (/var/lib/ricci/cacert.pem)
on the same machine?

That way I wouldn't need to generate additional certificates for root
user but just use existing ones. As it seems ccs_sync already uses them...