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@client1]# ccs -h localhost -p IGNOREME --getconf &>/dev/null
>> [root@client1]# PUBLIC_CERT=~/.ccs/cacert/pem
>> [root@client1]# RICCI_CLIENTS=/var/lib/ricci/certs/clients
>> [root@client1]# UNIQUE_SUFFIX=$(hostname | sha1sum | cut -b1-6)
>> [root@client1]# RICCI_CERT=${RICCI_CLIENTS}/client_cert_${UNIQUE_SUFFIX}
>> [root@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...
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
