On 18/01/13 20:44 +0100, Jakov Sosic wrote:
> On 01/18/2013 07:44 PM, Jakov Sosic wrote:
>>
>> 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...
Indeed, you can go with whatever naming convention you like, only location
is important. Honestly, I wasn't sure so sticked with the internal naming
convention of ricci, which does not hurt either (note that during
the cluster lifetime, you can, e.g., re-add a node under different name so
this descriptive naming can get out of sync, but not a big deal).
>>> 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.
Cool, thanks.
>>> 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...
See below.
>> 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...
(/var/lib/ricci/certs/cacert.pem)
Yes, but it is a little bit more complicated. When ricci is run for
the first time (prerequisite [1] to run either "cman_tool version ..."
or ccs_sync directly [*]), it generates its OpenSSL certificate
(/var/lib/ricci/certs/cacert.pem) + key, which are then 1:1 cloned
to PKCS#12 format and put into NSS certificate DB (in the same dir)
and this is what ccs_sync uses to obtain its 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?
As long as you do not need per-client granularity (e.g., to forcibly
revoke/remove particular certificate from /var/lib/ricci/certs/clients;
btw. custom named cert files here would actually prove useful as
otherwise one would have to do a tedious certificate-content-matching
task to identify a correct victim)...
> 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...
See above, really depends on the level of permissions management you
want to achieve (in extreme, there can be a single certificate for
everything, but I wouldn't recommend this).
Other possibility, although suffering from the similar global
permission issue, is to use local certificate authority whose
certificates (every and each) will be automatically considered
as trusted. It looks like that to you utilize this, you would
need to append the certificate of this CA to
/var/lib/ricci/certs/auth_CAs.pem. As this path is not commonly
used, this is for the braver ones :)
[*] in fact, this prerequisite can be avoided (a/ by specifying "-c"
option to ccs_sync AND b/ explicitly listing other nodes as
arguments, but again, these nodes have to be running ricci),
however this a degenerate case and best if forgotten
[1] http://www.redhat.com/archives/linux-cluster/2010-November/msg00163.html
--
Jan
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
