[Spacewalk-list] Migrating to a physical

Tue Nov 29 19:36:48 UTC 2016

Daryl
I hope you ran the full upgrade script and not just the database upgrade
script.

On Tue, Nov 29, 2016 at 12:23 PM, Daryl Rose <darylrose at outlook.com> wrote:

> Once again I posted and then figured out how to resolve the issue.
>
>
> I was able to successfully to upgrade the schema and that resolved both of
> my issues.  At this moment, it looks like my migration was successfully.
>
>
> Thank you to everyone who helped me get this completed successfully.
>
>
> Daryl
>
> ------------------------------
> *From:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces@
> redhat.com> on behalf of Daryl Rose <darylrose at outlook.com>
> *Sent:* Tuesday, November 29, 2016 9:53 AM
>
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] Migrating to a physical
>
>
> Hello again,
>
>
> After I posted this message, I realized what might be the cause of at
> least one of my errors.
>
>
> I didn't realize that v2.6 was just released and installed that version on
> the physical server, while the original server is still v2.5.  I'm sure
> that will resolve the schema error, but will it also resolve the repository
> issue?
>
>
> Can I upgrade the old server and migrate the database over as Paul posted
> previously?  Does the server name have to be the correct name?  To do the
> migration, I renamed the original server to "<server name>-old", and
> renamed the physical server to the actual name of the server, had DNS
> change to reflect the name changes, then installed Spacewalk on the
> physical server.
>
>
> I can rename everything again and preform the upgrade on the original
> server, but if I can upgrade it without the name change that would be
> preferred.  Or, I can rename the server without updating DNS.  Does the
> upgrade query DNS to verify that it can fully resolve the name?  I could
> try and force it to read the /etc/host file?
>
>
> Thoughts?
>
>
> Thank you.
>
>
> Daryl
>
> ------------------------------
> *From:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces@
> redhat.com> on behalf of Daryl Rose <darylrose at outlook.com>
> *Sent:* Tuesday, November 29, 2016 9:28 AM
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] Migrating to a physical
>
>
> 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:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces@
> redhat.com> on behalf of Paul Robert Marino <prmarino1 at gmail.com>
> *Sent:* Tuesday, November 15, 2016 3:29 PM
> *To:* spacewalk-list at redhat.com
> *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 <test-yle at quanticdream.com>
> 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 :* spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces
>> @redhat.com] *De la part de* Ree, Jan-Albert van
>> *Envoyé :* mardi 15 novembre 2016 15:32
>> *À :* spacewalk-list at redhat.com
>> *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 | J.A.v.Ree at marin.nl | www.marin.nl
>>
>> [image: LinkedIn] <https://www.linkedin.com/company/marin> [image:
>> YouTube] <http://www.youtube.com/marinmultimedia> [image: Twitter]
>> <https://twitter.com/MARIN_nieuws> [image: 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:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces at redhat
>> .com> on behalf of Daryl Rose <darylrose at outlook.com>
>> *Sent:* Tuesday, November 15, 2016 14:07
>> *To:* spacewalk-list at redhat.com
>> *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:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces at redhat
>> .com> on behalf of Ree, Jan-Albert van <J.A.v.Ree at marin.nl>
>> *Sent:* Tuesday, November 15, 2016 1:50 AM
>> *To:* spacewalk-list at redhat.com
>> *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 | J.A.v.Ree at marin.nl | www.marin.nl
>>
>> [image: LinkedIn] <https://www.linkedin.com/company/marin> [image:
>> YouTube] <http://www.youtube.com/marinmultimedia> [image: Twitter]
>> <https://twitter.com/MARIN_nieuws> [image: 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:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces at redhat
>> .com> on behalf of Daryl Rose <darylrose at outlook.com>
>> *Sent:* Monday, November 14, 2016 20:29
>> *To:* spacewalk-list at redhat.com
>> *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
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20161129/21c690a6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 293 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20161129/21c690a6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 253 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20161129/21c690a6/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 333 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20161129/21c690a6/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 331 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20161129/21c690a6/attachment-0003.png>