I just realized, I missed something, so here the interdiff to the interdiff:
diff --git a/doc/design-node-security.rst b/doc/design-node-security.rst index 4d61290..1c2c8a3 100644 --- a/doc/design-node-security.rst +++ b/doc/design-node-security.rst @@ -105,7 +105,7 @@ distribution to master candidates only. (Re-)Adding nodes to a cluster ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -According to :doc:`design-node-add.rst`, Ganeti transfers the ssh keys to +According to :doc:`design-node-add`, Ganeti transfers the ssh keys to every node that gets added to the cluster. We propose to change this procedure to treat master candidates and normal @@ -385,7 +385,7 @@ in this design so far. Also, other daemons than the ones mentioned so far perform intra-cluster communication. Neither the keys nor the daemons will be affected by this design for several reasons: -- The hmac key used by ConfD (see ``design-2.1.rst``): the hmac key is still +- The hmac key used by ConfD (see :doc:`design-2.1`): the hmac key is still distributed to all nodes, because it was designed to be used for communicating with ConfD, which should be possible from all nodes. For example, the monitoring daemon which runs on all nodes uses it to @@ -398,7 +398,7 @@ be affected by this design for several reasons: RPC requests is maintained with this design. - The rapi SSL key certificate and rapi user/password file 'rapi_users' is - already only copied to the master candidates (see :doc:`design-2.1.rst`, + already only copied to the master candidates (see :doc:`design-2.1`, Section ``Redistribute Config``). - The spice certificates are still distributed to all nodes, since it should @@ -422,7 +422,7 @@ future reference. increase the security if they were signed by a common CA. There is already a design doc for a Ganeti CA which was suggested in a different context (related to import/export). This would also be a - benefit for the RPC calls. See design doc :doc:`design-impexp2.rst` for + benefit for the RPC calls. See design doc :doc:`design-impexp2` for more information. Implementing a CA is rather complex, because it would mean also to support renewing the CA certificate and providing and supporting infrastructure to revoke compromised certificates. On Fri, Feb 14, 2014 at 2:08 PM, Helga Velroyen <[email protected]> wrote: > Sure, I also fixed the other references. FYI, interdiff: > > diff --git a/doc/design-node-security.rst b/doc/design-node-security.rst > index 11911bb..4d61290 100644 > --- a/doc/design-node-security.rst > +++ b/doc/design-node-security.rst > @@ -105,8 +105,8 @@ distribution to master candidates only. > (Re-)Adding nodes to a cluster > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -According to ``design-node-add.rst``, Ganeti transfers the ssh keys to > every > -node that gets added to the cluster. > +According to :doc:`design-node-add.rst`, Ganeti transfers the ssh keys to > +every node that gets added to the cluster. > > We propose to change this procedure to treat master candidates and normal > nodes differently. For master candidates, the procedure would stay as is. > @@ -398,7 +398,7 @@ be affected by this design for several reasons: > RPC requests is maintained with this design. > > - The rapi SSL key certificate and rapi user/password file 'rapi_users' is > - already only copied to the master candidates (see ``design-2.1.rst``, > + already only copied to the master candidates (see :doc:`design-2.1.rst`, > Section ``Redistribute Config``). > > - The spice certificates are still distributed to all nodes, since it > should > @@ -422,7 +422,7 @@ future reference. > increase the security if they were signed by a common CA. There is > already a design doc for a Ganeti CA which was suggested in a > different context (related to import/export). This would also be a > - benefit for the RPC calls. See design doc ``design-impexp2.rst`` for > + benefit for the RPC calls. See design doc :doc:`design-impexp2.rst` for > more information. Implementing a CA is rather complex, because it > would mean also to support renewing the CA certificate and providing > and supporting infrastructure to revoke compromised certificates. > > > > On Fri, Feb 14, 2014 at 12:56 PM, Klaus Aehlig <[email protected]> wrote: > >> > + benefit for the RPC calls. See design doc ``design-impexp2.rst`` for >> >> Please use correct rst-syntax for inner-documentation cross-reference. >> >> >> Rest LGTM >> >> -- >> Klaus Aehlig >> Google Germany GmbH, Dienerstr. 12, 80331 Muenchen >> Registergericht und -nummer: Hamburg, HRB 86891 >> Sitz der Gesellschaft: Hamburg >> Geschaeftsfuehrer: Graham Law, Christine Elizabeth Flores >> > > > > -- > -- > Helga Velroyen | Software Engineer | [email protected] | > > Google Germany GmbH > Dienerstr. 12 > 80331 München > > > Registergericht und -nummer: Hamburg, HRB 86891 > Sitz der Gesellschaft: Hamburg > Geschäftsführer: Graham Law, Christine Elizabeth Flores > -- -- Helga Velroyen | Software Engineer | [email protected] | Google Germany GmbH Dienerstr. 12 80331 München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores
