Migration from 0.32 to 1.3.0

  • Server Information:

    OS: Ubunu 16.04
    Apache2 - PHP 7.0
    Running Version 8355
    SVN Revision: 5805

    I followed the instructions for migration from 0.32 to 1.x.x from the wiki (https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_1.x.x#Migration_Upgrade) and for the most part it was successful. I did run into the following issues though.

    1. All Service Settings for all host were lost.
    2. Group Membership was 99% lost. I say 99% since some of the hosts still showed up under the group.

    The first two items, were not really a big deal for me. Inconvenient, but not too bad to recreate. Plus, it was a major upgrade so one should expect to have to recreate some settings. For me I just re-added the hosts to the appropriate groups and then used the group to set the service settings.

    Has any one else experienced these issues? Is it something that should be added to the wiki page on migration?

  • @Tom-Elliott I have to say, FOG has some of the speediest devs 🙂 Y’all do great work. The migration from 0.32 to 1.3.0 was pretty straight forward and worked quited well. To be honest, I had expected more issues since I made such a big jump in versions but they were minor and easy to fix. This is a testament to how dedicated the FOG team and community are to this project.

    For anyone still running 0.32 (if I was not the last hold out), the migration is straight forward. Follow the directions on the wiki and you will be up and running in no time.

    Thanks for the help everyone.

  • Senior Developer

    Thanks for the file.

    I have found and fixed both issues reported. 0.32->trunk (1.3 as well when it is released) will maintain proper group associations AND service settings for each host will be fixed as well.

  • Senior Developer

    Never mind, I edited the file you originally sent me so I could actually use it.

  • Senior Developer

    @jburleson Yes, please dump the irrelevant parts. The history, usertracking, and imaging logs aren’t really needed for me to try to replicate.

  • @Wayne-Workman Yeah, give me a minute to fire up the old vm and I will generate a new dump. I have finished the migration and have changed all the passwords so that is no longer an issue. Can I still drop the history and user tracking data? There is almost 9 years worth and it makes the file around 70MB?

  • @jburleson Could you get Tom a non-sanitized db? He is trustworthy. All of our @Senior-Developers are trustworthy.

  • Senior Developer

    @Sebastian-Roth I have the dump, but testing was near impossible. It was “sanitized” of the original information such as the user password and ip information. It wouldn’t allow me to communicate with the db any further.

  • Senior Developer

    @Tom-Elliott Interesting post. Did you find the time to try it out? Do you have the DB dump in question?

  • Senior Developer

    @jburleson It’s not a problem, at least not one that I’m aware of. There are quite significant changes, but we should be all right. I’ll test with your DB and see if I can replicate the problem.

  • As I mentioned in the original post, I already fixed my issues.

    My original question still remains, does something need to be mentioned on the migration wiki page about this or was it just a one off issue. If it is not an isolated issue, I think it is appropriate to let people know that they will need to setup their groups again as well as the host service settings.

  • Senior Developer

    @jburleson the nice part is that, unless every host had very pin pointed service settings that must be maintained, you can just join all the hosts into groups, yes again, and apply settings that way.

  • Moderator

    @jburleson In a way it is and it isn’t (off point). The upgrade is filled with potential issues. The question would be is it quicker to fix your current upgrade or to just create a new install and then manually (or import) the necessary information into the new build. Its akin to upgrading windows between releases vs a clean install (but the clean install makes you install all of the software again too). So the question is what would be better for YOUR company in the long run. I’m wondering if FOG Project should even support upgrading more than 2 revs back, just because the database has changed so much.

    With 500 hosts I might consider sticking with the upgrade and working through the issues.

  • @george1421 About 500 hosts. I am not sure what you are suggesting here is on topic since the post is about the Host Service Settings and Group Membership and not the images.

  • Moderator

    I guess the question to ask here is how many registered hosts are we talking about from the 0.32 install? Depending on the scope the answer may be different than below.

    Since there is such a big jump, it would be my opinion to just create a new install of the 1.2.0 trunk, copy the images over to the new server and then recreate the image entries by hand in the new server.

  • I do have the sql backup from the old server. Whom should I email it to?

  • Do you have a copy of your DB from fog 0.32? If you do, we can work out the issues. If not - it’s anyones guess what went wrong. Also - do not post your db backup here. Email it to a dev.

Log in to reply