Migrate Hosts from 1.2 to dev-trunk

[Sebastian Roth]

@jayphizzle Have you tried upgrading your trunk server and importing the mysql-generated CSV yet? I tested a lot but I am still wondering if this is really working for other users as well! Please let us know.

[Tom Elliott]

@Sebastian-Roth I only just finally added your suggestions. Literally like 32 seconds ago. Sorry I saw it and just missed it.

[jayphizzle]

@Sebastian-Roth said:

@jayphizzle Have you tried upgrading your trunk server and importing the mysql-generated CSV yet? I tested a lot but I am still wondering if this is really working for other users as well! Please let us know.

@Sebastian-Roth Sorry i did not give feedback to your suggestion. I tried it but the product key field in the webgui does not show any entry.

@Tom-Elliott said:

@Sebastian-Roth I only just finally added your suggestions. Literally like 32 seconds ago. Sorry I saw it and just missed it.

Damn. I entered the product keys for most of our clients manually yesterday.
I have to be more patient next time

I tested the new trunk version just a minute ago.

As mentioned i imported the base64 coded productkey from my 1.2 installation into the db of the dev-version.
I checked the productkey of a host i did not updated manually - field is still empty.
I clicked on “update” in the host view - field is still empty and also the db field is now empty.
I copied the base64 coded product key from the db an entered it in the field in the host view - there is a encoding of the entered key, but it is not correct. (Q1RRW-XXXXX-XXXXX-XXXXX-XXXXX instead of CTQY2-XXXXX-XXXXX-XXXXX-XXXXX )

[Sebastian Roth]

@jayphizzle said:

Damn. I entered the product keys for most of our clients manually yesterday.
I have to be more patient next time

Is a response time of 24 hours for a complete solution not fast enough?!? Just kidding!

The proposed fix is only able to jump in and recognize/modify the values being imported on the fly. I don’t think we want to have some foo magic that tries to make assumptions on the product key filed every time it’s loaded/saved from/to the database. So your tests (import base64 via db dump and update the value via web gui) just won’t work - as you already saw!

If I’d be you, I’d go for this: Do a complete mysql-CSV-dump from your 1.2.0 DB as described earlier. Make a copy of that full CSV file and delete most lines to only keep a few (maybe 3-5) for testing. Choose whichever you like (maybe hosts that you haven’t modified the product key value by hand yet so you won’t ruin those precious entries you spend hours on I suppose). Then delete exactly those 3-5 hosts from your FOG trunk DB using the web gui and import the CSV. Check if everything is fine - especially AD passwords as I don’t think we have that correctly yet - and let us know!

[jayphizzle]

@Sebastian-Roth said:

The proposed fix is only able to jump in and recognize/modify the values being imported on the fly.

Ah ok only during the import.
Why i did not tried this

I tried it with a few hosts as you recommended - the productkey was successfull decoded from base64 and saved in AES.
(i did not test ad passwords cause the last hosts where standalone devices)

Thanks to @Sebastian-Roth and @Tom-Elliott for the quick (bug)fix!

[Sebastian Roth]

Anyone interested to test this who has settings like AD passwords and such?

[Sebastian Roth]

@Testers Anyone still running FOG 1.2.0 anywhere? Would be great if you could run through the export/import process described below to see if it all works… I guess we still have problems with the AD passwords.

[Tom Elliott]

@Sebastian-Roth Should we adjust the export method you described to place the ADPasswordLegacy into the proper location on the CSV?

[Sebastian Roth]

Chatted with Tom about this. I didn’t have in mind that ADPass in FOG 1.2.0 was encrypted using FOGcrypt (different encryption than we use in FOG trunk now!) and that value stored in the DB. This value needs to go to the field ADPassLegacy in FOG trunk without any conversation while ADPass in trunk needs to stay empty as we cannot decrypt the old value ( @Tom-Elliott sure we can’t do this?).

I changed my earlier posting to reflect this. Still would be great if anyone could test and let us know!

[Wayne Workman]

For future readers: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG