On Mon, 28 Mar 2011 23:52:24 -0700, petermity <6t12-n6js(a)dea.spamcon.org&gt; wrote: That might work, but you will likely run into problems. The correct way to do it is to use 'cobbler replicate --master'. Generally you would want to setup the cobbler settings file, start up cobblerd and then do that. This is the way I do it, and it allows you to do all kinds of fun things with selecting what you want brought down. -- Scott Henson Red Hat CIS Operator WVU Alum BSAE/BSME

I just recently migrated to a new server using replication. I used a similar command to what you listed below: cobbler replicate --master=$MASTER_SERVER_IP --distros=* --profiles=* --repos=* --systems=* I think replicate syncs all data by default unless you use the --omit-data option. The only real issues I had was with custom triggers that couldn't run on the slave system due to config issues, which breaks the replication unless you disable them on the master first then re-enable them after the replication. I also had an issue where the profile names associated with systems were using the wrong case compared to the profiles themselves. This was resolved by changing the profiles on these systems to match the correct case. After all of this the new cobbler server worked fine, even puppet external node classifiers. HTH, byron -----Original Message----- From: cobbler-bounces(a)lists.fedorahosted.org [mailto:cobbler-bounces@lists.fedorahosted.org] On Behalf Of petermity Sent: Friday, April 01, 2011 3:37 AM To: cobbler(a)lists.fedorahosted.org Subject: Re: Setting up new Cobbler server from existing one Scott Henson <shenson(a)redhat.com&gt; wrote: Thanks, I wasn't aware of replicate (it's not mentioned in Cobbler's top-level help). The documentation at: https://fedorahosted.org/cobbler/wiki/ReplicateMaster is sparse, not enough examples of exactly how to use it. Apparently there used to be a parameter "--full-data-sync" - that's what I want to do. Would this be the equivalent (since I have no systems or images)?: cobbler replicate --master=$MASTER_SERVER_IP --distros=* --profiles=* --repos=* When looking into it, I ran across: https://fedorahosted.org/cobbler/wiki/MovingYourInstallToAnotherBox which has an unhelpful statement, "use the right flags". Again, examples would help. I also ran across this bug, over a year old - it would seem to imply that it won't be worth replicating because I won't have access to distros - is this bug bogus, or there's a workaround, or what?: https://fedorahosted.org/cobbler/ticket/566 _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler

Scott Henson <shenson(a)redhat.com&gt; wrote: I was finally able to try replicating; it's not working quite right. From old server to new server, both running Cobbler V2.0.11, I did on the new server, as root: cobbler replicate --master=IP --sync-all The first problem was that I got a lot of failures like: rsync: send_files failed to open "/cache/zsh-4.2.6-5.el5.i386.rpm-{GUID string}" (in distro-CentOS5.6-i386): Permission denied (13) and at the end of a set of such failures: rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1508) [generator=3.0.7] That happened for most but not all distros. I finally tracked that down to the permissions in the "cache" directories under most of the distros under /var/www/cobbler/ks_mirror on the old server - they were only readable by the owner and nobody else; fixed via "chmod +r *" in each cache directory. Now there are no errors shown during the replicate. I think that Cobbler creates those cache directories, is there a bug (or was there a bug) in setting permissions correctly on them? I'd never fooled manually with permissions there. Secondly, it still isn't replicating correctly. After replicating with no errors, using "cobbler distro list", distros on the old server: CentOS4.4-i386 CentOS5.5-i386 CentOS5.5-x86_64 CentOS5.6-i386 CentOS5.6-x86_64 Fedora14-i386 Fedora14-x86_64 But on the new server: CentOS5.6-x86_64 Fedora14-x86_64 However, I noticed that for some reason the names under /var/www/cobbler/ks_mirror are different between the two servers, and the only distros showing up are those with the same name: Old server: dr-xr-xr-x 8 root root 4096 Feb 22 17:10 CentOS4.4 drwxr-xr-x 8 root root 4096 Feb 18 19:08 CentOS5.5 drwxr-xr-x 8 root root 4096 Feb 22 13:00 CentOS5.5-x64 drwxrwxr-x 7 root root 4096 Apr 12 20:10 CentOS5.6 drwxr-xr-x 7 root root 4096 Apr 12 20:31 CentOS5.6-x86_64 drwxr-xr-x. 2 root root 4096 Apr 26 12:07 config drwxr-sr-x 8 root root 4096 Feb 22 14:42 Fedora14 drwxr-sr-x 8 root root 4096 Feb 23 13:20 Fedora14-x86_64 New server: dr-xr-xr-x 8 root root 4096 Feb 22 17:10 CentOS4.4-i386 drwxr-xr-x 8 root root 4096 Feb 18 19:08 CentOS5.5-i386 drwxr-xr-x 8 root root 4096 Feb 22 13:00 CentOS5.5-x86_64 drwxrwxr-x 7 root root 4096 Apr 12 20:10 CentOS5.6-i386 drwxr-xr-x 7 root root 4096 Apr 12 20:31 CentOS5.6-x86_64 drwxr-xr-x 2 root root 4096 Apr 26 12:07 config drwxr-sr-x 8 root root 4096 Feb 22 14:42 Fedora14-i386 drwxr-sr-x 8 root root 4096 Feb 23 13:20 Fedora14-x86_64 What's the solution to get the new server to actually fully sync to the old one so all distros are available?

Scott Henson <shenson(a)redhat.com&gt; wrote: Is this likely to be part of 2.1?

Scott Henson wrote: Sounds good; we would like to be able to have replication and duplication to support deployment of our RHEL machines? Do you have an estimated timescale for 2.0.12? A few days, a few weeks or a few months? -- : David Lee : ECMWF (Data Handling System) : Shinfield Park : Reading RG2 9AX : Berkshire : : tel: +44-118-9499 362 : email: david.lee(a)ecmwf.int