Functionality originally in 60fe75a5, but reverted by 4a7eee30 and 9113a190 amidst a raft of other changes. --- cobbler/action_sync.py | 7 ++++--- installer_templates/defaults | 1 + installer_templates/settings.template | 3 +++ 3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/cobbler/action_sync.py b/cobbler/action_sync.py index 43f5e6d..4edcc28 100644 --- a/cobbler/action_sync.py +++ b/cobbler/action_sync.py @@ -136,9 +136,10 @@ class BootSync: self.dns.regen_hosts() self.dns.write_dns_files()
- if self.verbose: - self.logger.info("rendering Rsync files") - self.rsync_gen() + if self.settings.manage_rsync: + if self.verbose: + self.logger.info("rendering Rsync files") + self.rsync_gen()
if self.verbose: self.logger.info("generating PXE menu structure") diff --git a/installer_templates/defaults b/installer_templates/defaults index 3da4476..efa7a6b 100644 --- a/installer_templates/defaults +++ b/installer_templates/defaults @@ -4,6 +4,7 @@ dns_module: 'manage_bind' dhcp_module: 'manage_isc' enable_dhcp: 0 enable_dns: 0 +enable_rsync: 1 next_server: '127.0.0.1' pxe_once: 0 redhat_management_type: "off" diff --git a/installer_templates/settings.template b/installer_templates/settings.template index 2777b73..1ba1a0b 100644 --- a/installer_templates/settings.template +++ b/installer_templates/settings.template @@ -168,6 +168,9 @@ mgmt_classes: [] mgmt_parameters: from_cobbler: 1
+# set to 1 to enable Cobbler's RSYNC management features. +manage_rsync: $enable_rsync + # set to 1 to enable Cobbler's DHCP management features. # the choice of DHCP management engine is in /etc/cobbler/modules.conf manage_dhcp: $enable_dhcp
If the site actually uses replication, than they should know to turn this on, having a cobbler upgrade start randomly squashing your /etc/rsyncd.conf is less than desirable.
This also seems to be more inline with how dhcp and dns manangement also default to off. --- installer_templates/defaults | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/installer_templates/defaults b/installer_templates/defaults index efa7a6b..1ecf443 100644 --- a/installer_templates/defaults +++ b/installer_templates/defaults @@ -4,7 +4,7 @@ dns_module: 'manage_bind' dhcp_module: 'manage_isc' enable_dhcp: 0 enable_dns: 0 -enable_rsync: 1 +enable_rsync: 0 next_server: '127.0.0.1' pxe_once: 0 redhat_management_type: "off"
On 10/07/2009 08:06 AM, Joshua T Corbin wrote:
Functionality originally in 60fe75a5, but reverted by 4a7eee30 and 9113a190 amidst a raft of other changes.
I somewhat disagree with this patch. I want to have a minimum of settings to configure out of the box. I suppose part of the problem is that you are worried about cloberring a previous rsync config? Can you elaborate?
--Michael
cobbler/action_sync.py | 7 ++++--- installer_templates/defaults | 1 + installer_templates/settings.template | 3 +++ 3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/cobbler/action_sync.py b/cobbler/action_sync.py index 43f5e6d..4edcc28 100644 --- a/cobbler/action_sync.py +++ b/cobbler/action_sync.py @@ -136,9 +136,10 @@ class BootSync: self.dns.regen_hosts() self.dns.write_dns_files()
if self.verbose:
self.logger.info("rendering Rsync files")
self.rsync_gen()
if self.settings.manage_rsync:
if self.verbose:
self.logger.info("rendering Rsync files")
self.rsync_gen() if self.verbose: self.logger.info("generating PXE menu structure")
diff --git a/installer_templates/defaults b/installer_templates/defaults index 3da4476..efa7a6b 100644 --- a/installer_templates/defaults +++ b/installer_templates/defaults @@ -4,6 +4,7 @@ dns_module: 'manage_bind' dhcp_module: 'manage_isc' enable_dhcp: 0 enable_dns: 0 +enable_rsync: 1 next_server: '127.0.0.1' pxe_once: 0 redhat_management_type: "off" diff --git a/installer_templates/settings.template b/installer_templates/settings.template index 2777b73..1ba1a0b 100644 --- a/installer_templates/settings.template +++ b/installer_templates/settings.template @@ -168,6 +168,9 @@ mgmt_classes: [] mgmt_parameters: from_cobbler: 1
+# set to 1 to enable Cobbler's RSYNC management features. +manage_rsync: $enable_rsync
- # set to 1 to enable Cobbler's DHCP management features. # the choice of DHCP management engine is in /etc/cobbler/modules.conf manage_dhcp: $enable_dhcp
Date: Wed, 07 Oct 2009 08:57:18 -0400 From: Michael DeHaan mdehaan@redhat.com To: cobbler development list cobbler-devel@lists.fedorahosted.org Subject: Re: [PATCH 1/2] Restore the ability to disable rsync management User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2
On 10/07/2009 08:06 AM, Joshua T Corbin wrote:
Functionality originally in 60fe75a5, but reverted by 4a7eee30 and 9113a190 amidst a raft of other changes.
I somewhat disagree with this patch. I want to have a minimum of settings to configure out of the box.
You shouldn't be wanting a high-availability configuration "out of the box" since that's not at all a simple setup, and one in which the admin needs to care a whole lot to set it up. This feature is only used by the replication sub-system of cobbler as far as I'm aware.
Even so, my first patch simply allows for it to be disabled, but keeps the default to enabled.
My second patch changes the default to be disabled which is consistent with how the DHCP and DNS management features work.
At any rate, the original commit had this feature, it was removed inadvertantly (I would hope) by a pair of huge catch-all "fixes" commits.
I suppose part of the problem is that you are worried about cloberring a previous rsync config? Can you elaborate?
Yes indeed, these patches are a direct result of on-the-ground pain; for now it can be worked around by obliterating the rsyncd.conf template, but having cobbler regenerating the file constantrly is less than desirable.
- Josh
On 10/07/2009 09:31 AM, Joshua T Corbin wrote:
Date: Wed, 07 Oct 2009 08:57:18 -0400 From: Michael DeHaanmdehaan@redhat.com To: cobbler development listcobbler-devel@lists.fedorahosted.org Subject: Re: [PATCH 1/2] Restore the ability to disable rsync management User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2
On 10/07/2009 08:06 AM, Joshua T Corbin wrote:
Functionality originally in 60fe75a5, but reverted by 4a7eee30 and 9113a190 amidst a raft of other changes.
I somewhat disagree with this patch. I want to have a minimum of settings to configure out of the box.
You shouldn't be wanting a high-availability configuration "out of the box" since that's not at all a simple setup, and one in which the admin needs to care a whole lot to set it up. This feature is only used by the replication sub-system of cobbler as far as I'm aware.
Replicate isn't just for HA.
It's also for backup, or seperate geographies, or an easy way to share data between a stage and production server.
And it is pretty easy to set up.
I suppose part of the problem is that you are worried about cloberring a previous rsync config? Can you elaborate?
Yes indeed, these patches are a direct result of on-the-ground pain; for now it can be worked around by obliterating the rsyncd.conf template, but having cobbler regenerating the file constantrly is less than desirable.
Hmm, I'll think about this.
Let's make sure there is an item filed in Trac for this one.
It would be nice if rsyncd.conf took conf.d directories like Apache. (As a sidenote, I wish about everything did this).
- Josh
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
On Wed, Oct 7, 2009 at 7:14 AM, Michael DeHaan mdehaan@redhat.com wrote:
On 10/07/2009 09:31 AM, Joshua T Corbin wrote:
Date: Wed, 07 Oct 2009 08:57:18 -0400 From: Michael DeHaan mdehaan@redhat.com To: cobbler development list cobbler-devel@lists.fedorahosted.org Subject: Re: [PATCH 1/2] Restore the ability to disable rsync management User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2
On 10/07/2009 08:06 AM, Joshua T Corbin wrote:
Functionality originally in 60fe75a5, but reverted by 4a7eee30 and 9113a190 amidst a raft of other changes.
I somewhat disagree with this patch. I want to have a minimum of settings to configure out of the box.
As a major cobbler replicate and rsyncd user I've got a few comments.
You shouldn't be wanting a high-availability configuration "out of the box" since that's not at all a simple setup, and one in which the admin needs to care a whole lot to set it up. This feature is only used by the replication sub-system of cobbler as far as I'm aware.
Replicate isn't just for HA.
It's also for backup, or seperate geographies, or an easy way to share data between a stage and production server.
Michael really hits home here. You don't want to pxe hosts in China over the wan to the united states or something really far away like that. Just getting the rpms takes ages if thats the case. There are some really big linux shops using cobbler out there so replicate is good stuff.
And it is pretty easy to set up.
I suppose part of the problem is that you are worried about cloberring a previous rsync config? Can you elaborate?
Yes indeed, these patches are a direct result of on-the-ground pain; for now it can be worked around by obliterating the rsyncd.conf template, but having cobbler regenerating the file constantrly is less than desirable.
Hmm, I'll think about this.
Would it be possible to have cobbler check look in the rsyncd.conf and see if the right modules are defined? That way it would be really straightforward for an admin to setup and wouldn't clobber the rsyncd.conf. A lot of people will scream if cobbler messes up the rsyncd.conf here and having a bunch of seperate templates for the rsyncd.conf in different geographic locations is undesirable. Ideally I'm seeing 2 settings for rsync replication... One would be for enabling rsync vs ssh replication and the other would enable rsyncd.conf management. What do you think?
On 10/07/2009 10:19 AM, Jeff Schroeder wrote:
On Wed, Oct 7, 2009 at 7:14 AM, Michael DeHaanmdehaan@redhat.com wrote:
On 10/07/2009 09:31 AM, Joshua T Corbin wrote:
Date: Wed, 07 Oct 2009 08:57:18 -0400 From: Michael DeHaanmdehaan@redhat.com To: cobbler development listcobbler-devel@lists.fedorahosted.org Subject: Re: [PATCH 1/2] Restore the ability to disable rsync management User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2
On 10/07/2009 08:06 AM, Joshua T Corbin wrote:
Functionality originally in 60fe75a5, but reverted by 4a7eee30 and 9113a190 amidst a raft of other changes.
I somewhat disagree with this patch. I want to have a minimum of settings to configure out of the box.
As a major cobbler replicate and rsyncd user I've got a few comments.
You shouldn't be wanting a high-availability configuration "out of the box" since that's not at all a simple setup, and one in which the admin needs to care a whole lot to set it up. This feature is only used by the replication sub-system of cobbler as far as I'm aware.
Replicate isn't just for HA.
It's also for backup, or seperate geographies, or an easy way to share data between a stage and production server.
Michael really hits home here. You don't want to pxe hosts in China over the wan to the united states or something really far away like that. Just getting the rpms takes ages if thats the case. There are some really big linux shops using cobbler out there so replicate is good stuff.
And it is pretty easy to set up.
I suppose part of the problem is that you are worried about cloberring a previous rsync config? Can you elaborate?
Yes indeed, these patches are a direct result of on-the-ground pain; for now it can be worked around by obliterating the rsyncd.conf template, but having cobbler regenerating the file constantrly is less than desirable.
Hmm, I'll think about this.
Would it be possible to have cobbler check look in the rsyncd.conf and see if the right modules are defined? That way it would be really straightforward for an admin to setup and wouldn't clobber the rsyncd.conf. A lot of people will scream if cobbler messes up the rsyncd.conf here and having a bunch of seperate templates for the rsyncd.conf in different geographic locations is undesirable. Ideally I'm seeing 2 settings for rsync replication... One would be for enabling rsync vs ssh replication and the other would enable rsyncd.conf management. What do you think?
Yeah, I was just thinking about that. What if we have a statement in our generated version that says "generated by cobbler" or something in the template (as a comment), and if that is /not found/ we don't overwrite the file *if existing*, and then in that case have cobbler check spit out a warning rather than overwrite it?
That could be pretty simple.
--Michael
On Wed, Oct 7, 2009 at 7:40 AM, Michael DeHaan mdehaan@redhat.com wrote: ...
Would it be possible to have cobbler check look in the rsyncd.conf and see if the right modules are defined? That way it would be really straightforward for an admin to setup and wouldn't clobber the rsyncd.conf. A lot of people will scream if cobbler messes up the rsyncd.conf here and having a bunch of seperate templates for the rsyncd.conf in different geographic locations is undesirable. Ideally I'm seeing 2 settings for rsync replication... One would be for enabling rsync vs ssh replication and the other would enable rsyncd.conf management. What do you think?
Yeah, I was just thinking about that. What if we have a statement in our generated version that says "generated by cobbler" or something in the template (as a comment), and if that is /not found/ we don't overwrite the file *if existing*, and then in that case have cobbler check spit out a warning rather than overwrite it?
That could be pretty simple.
It sounds like ponies falling from the sky. Everyone would be happy.
One would be for
enabling rsync vs ssh replication and the other would enable rsyncd.conf management. What do you think?
Do we even need to allow rsync-over-SSH? It seems like it would be rather slow and the only use case I can think of is either (A) someone not having a VPN, and (B) being rather concerned about internal data security.
I am not sure having the replicator go over SSH really makes the installs any more secure than they already were.
--Michael
On Wed, Oct 7, 2009 at 7:42 AM, Michael DeHaan mdehaan@redhat.com wrote:
One would be for
enabling rsync vs ssh replication and the other would enable rsyncd.conf management. What do you think?
Do we even need to allow rsync-over-SSH? It seems like it would be rather slow and the only use case I can think of is either (A) someone not having a VPN, and (B) being rather concerned about internal data security.
I am not sure having the replicator go over SSH really makes the installs any more secure than they already were.
How does it do it in cobbler 1.6.x? It certainly requires ssh for something. You don't scp the stuff because it only copies the changes. The ability to rsync over ssh is preferable in some use cases. Just don't make it the default.
On 10/07/2009 10:40 AM, Jeff Schroeder wrote:
On Wed, Oct 7, 2009 at 7:42 AM, Michael DeHaanmdehaan@redhat.com wrote:
One would be for
enabling rsync vs ssh replication and the other would enable rsyncd.conf management. What do you think?
Do we even need to allow rsync-over-SSH? It seems like it would be rather slow and the only use case I can think of is either (A) someone not having a VPN, and (B) being rather concerned about internal data security.
I am not sure having the replicator go over SSH really makes the installs any more secure than they already were.
How does it do it in cobbler 1.6.x? It certainly requires ssh for something. You don't scp the stuff because it only copies the changes. The ability to rsync over ssh is preferable in some use cases. Just don't make it the default.
Cobbler uses rsync over SSH for 1.6. For 2.0, Scott Henson cleaned it all up, so it surfaces distros and such over rsync protocol (not rsync over SSH) automatically, so that when you run replicate you don't need to deal with SSH auth. I find this much less annoying, and it also enables hitting the replicate button in the webapp or using it over the XMLRPC API more easily.
--Michael
On Wed, Oct 7, 2009 at 7:48 AM, Michael DeHaan mdehaan@redhat.com wrote:
On 10/07/2009 10:40 AM, Jeff Schroeder wrote:
On Wed, Oct 7, 2009 at 7:42 AM, Michael DeHaan mdehaan@redhat.com wrote:
One would be for
enabling rsync vs ssh replication and the other would enable rsyncd.conf management. What do you think?
Do we even need to allow rsync-over-SSH? It seems like it would be rather slow and the only use case I can think of is either (A) someone not having a VPN, and (B) being rather concerned about internal data security.
I am not sure having the replicator go over SSH really makes the installs any more secure than they already were.
How does it do it in cobbler 1.6.x? It certainly requires ssh for something. You don't scp the stuff because it only copies the changes. The ability to rsync over ssh is preferable in some use cases. Just don't make it the default.
Cobbler uses rsync over SSH for 1.6. For 2.0, Scott Henson cleaned it all up, so it surfaces distros and such over rsync protocol (not rsync over SSH) automatically, so that when you run replicate you don't need to deal with SSH auth. I find this much less annoying, and it also enables hitting the replicate button in the webapp or using it over the XMLRPC API more easily.
Sounds like a reasonable tradeoff. Any admin who didn't like that could just wrap rsync in stunnel if required anyways.
cobbler-devel@lists.fedorahosted.org