Hello All,
I finally had the opportunity to migrate from my virtual environment to the physical environment. Thank you to Paul Robert Marino for providing these steps to migrating over the database. For the most part, things went well, however, I see one error that I'm not sure about, and I can't see any of my repositories. The error that I see is on the login screen: A schema upgrade is required. Please upgrade your schema at your earliest convenience to receive latest bug fixes and avoid potential problems. How do do I upgrade the schema? Is this a database message? I also get this error whenever I click on a repository: Internal Server Error The server experienced a problem which prevented your request from being filled out. It may not be possible to execute this action at this time. Please help us correct this problem by contacting us with details of how you received this message. Any thoughts on these issues? Thank you. Daryl ________________________________ From: [email protected] <[email protected]> on behalf of Paul Robert Marino <[email protected]> Sent: Tuesday, November 15, 2016 3:29 PM To: [email protected] Subject: Re: [Spacewalk-list] Migrating to a physical this is an interesting thread. some notes the initial plan looks good. however I usually use C names instead of A records in the DNS. this means you can easily change which host the the record is pointing to. next I would consider moving the database to a separate box or cluster, this will give a nice performance boost over running every thing on the same box. As to your followup question about the archiving I think you may have already figured this out but the archive command in the PostgreSQL's config is for the database journal. Also on a side note there is a quicker way to migrate a PostgreSQL database. step 1 while the box is running do a recursive scp from the original box to the new one of the PostgreSQL's data directory, by default its in /var/lib/pgsql on Red Hat based distributions. step 2 shut down PostgreSQL on the source server. step 3 use rsync -a --delete -c -I of the source server to the destination server. Note the -c and -I flags are very important in this case. step 4 start PostgreSQL on the destination server, and optionally the source server too. By the way this is the method pgpool uses to restore a failed slave if you have 3 or more servers in a cluster using a second running slave as the source. the one difference is it uses rsync for both step 1 and 3, but I always use SCP because it is faster for the initial copy. On Tue, Nov 15, 2016 at 10:45 AM, test-yle <[email protected]<mailto:[email protected]>> wrote: Hello, I use a crontab with a scrip to clean a archive. I list a task with spacecmd schedule_list | grep “” And spacecmd schedule_cancel number “id” I kill a archive . The Script: #!/bin/sh fich="/srv/scripts/Clean-Tache-Spwalk/liste.txt" spacecmd schedule_list | grep "Show differences between profiled config files and deployed config files" > $fich spacecmd schedule_list | grep "Deploy config files to system" >> $fich spacecmd schedule_list | grep "Run an arbitrary script" >> $fich ligne=`wc -l $fich | awk -F " " '{print $1}'` x=0 echo "The number of line is $ligne" echo "x=$x" while [ "$x" -le "$ligne" ]; do # echo "1------- $x" id=`cat $fich | awk 'NR=='$x' {print $1}'` echo "ID $id Delete" spacecmd schedule_cancel $id x=$(($x + 1)) echo "-------------$x" done De : [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] De la part de Ree, Jan-Albert van Envoyé : mardi 15 novembre 2016 15:32 À : [email protected]<mailto:[email protected]> Objet : Re: [Spacewalk-list] Migrating to a physical Ah yes, that can be an issue indeed, we only have a small installation with around 80 clients Cleaning up archived actions can be done from the GUI : Schedule > Archived Actions > Select All > Delete Actions I had roughly 50K archived actions there, in your case it might be a lot more. -- Jan-Albert Jan-Albert van Ree | Linux System Administrator | MARIN Support Group MARIN | T +31 317 49 35 48<tel:%2B31%20317%2049%2035%2048> | [email protected]<mailto:[email protected]> | www.marin.nl<http://www.marin.nl> [LinkedIn]<https://www.linkedin.com/company/marin> [YouTube] <http://www.youtube.com/marinmultimedia> [Twitter] <https://twitter.com/MARIN_nieuws> [Facebook] <https://www.facebook.com/marin.wageningen> MARIN news: Operational performance of wind assisted ships<http://www.marin.nl/web/News/News-items/Operational-performance-of-wind-assisted-ships-1.htm> ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Daryl Rose <[email protected]<mailto:[email protected]>> Sent: Tuesday, November 15, 2016 14:07 To: [email protected]<mailto:[email protected]> Subject: Re: [Spacewalk-list] Migrating to a physical Jan-Albert, Thank you for the feedback. I considered going the direction that you went, but that really won't work for me. The steps that I outlined are high level. I left out things like shutting down SW, and changing DNS entry. (The IP address has to change going from VM world to physical world). I also have a proxy server in the mix, so that means that firewall rules have to be changed. Not looking forward to that either. Networking isn't to receptive about changing firewall rules. :-( <snip> And you might want to clean up archived actions to make database backup / restore a bit quicker </snip> I'm not really sure how to do this. I did a little research and I found this example: * archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r' I don't really think that this is what I need, or is it? Thank you, and thank you for the feedback. Daryl ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Ree, Jan-Albert van <[email protected]<mailto:[email protected]>> Sent: Tuesday, November 15, 2016 1:50 AM To: [email protected]<mailto:[email protected]> Subject: Re: [Spacewalk-list] Migrating to a physical We did something similar earlier this year. However to prevent issues and allow for testing we did things a bit different : - We installed a new server on which we created all the content we needed (we used a new FQDN so we didn't have to do anything to allow for 2 servers in the same network) - Then I wrote a migration script which installed the new certificate package and re-registered the machine to the new SW server This allowed for more control as we did migration per server group and we would never be left with unmanaged machines in the event the migration went wrong. Your plan to me looks solid otherwise, although before step 1 I'd shut down the spacewalk services to make sure nothing in the database gets changed. And you might want to clean up archived actions to make database backup / restore a bit quicker Good luck -- Jan-Albert Jan-Albert van Ree | Linux System Administrator | MARIN Support Group MARIN | T +31 317 49 35 48<tel:%2B31%20317%2049%2035%2048> | [email protected]<mailto:[email protected]> | www.marin.nl<http://www.marin.nl> [LinkedIn]<https://www.linkedin.com/company/marin> [YouTube] <http://www.youtube.com/marinmultimedia> [Twitter] <https://twitter.com/MARIN_nieuws> [Facebook] <https://www.facebook.com/marin.wageningen> MARIN news: Winaars Speurspel open dag<http://www.marin.nl/web/News/News-items/Winaars-Speurspel-open-dag.htm> ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of Daryl Rose <[email protected]<mailto:[email protected]>> Sent: Monday, November 14, 2016 20:29 To: [email protected]<mailto:[email protected]> Subject: [Spacewalk-list] Migrating to a physical I'm migrating my SW environment from a VM to a physical. I have the physical built, but before I move forward, I need to make sure that I'll have my steps down. Please review my steps, and let me know if I missed anything. 1. Rename current SW to temporary name. 2. Rename physical from temporary name to actual FQDN. 3. Install latest version of SW (current installation was recently upgraded to 2.5). 4. rsync following directories: * /etc/jabberd * /etc/rhn * /etc/sysconfig/rhn * /root/ssl * /var/www/html/pub * /var/satellite 1. Backup Postgres DB from VM 2. Restore Postgres DB to physical One additional comment, I am using signed cert, so I need to make sure that names and certificates are all correct, so I don't end up having issues with my current connections. If I'm missing something, or I have something wrong, please let me know. Thank you. Daryl _______________________________________________ Spacewalk-list mailing list [email protected]<mailto:[email protected]> https://www.redhat.com/mailman/listinfo/spacewalk-list
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
