Migrating to new Fog Server - Issue
-
Hi Everyone,
I am having an issue with migrating to a new Fog Server. We had a really old Fog Server that I am trying to replace and to be quite honest, I set up the new fog server months ago and did not document everything that I had done (I know). The web interface is up and working and it looks like I had imported all of our hosts and imported our Fog settings from the old server. I updated the new server’s Fog settings to point to the new Fog Server’s IP address, and I was able to register a new machine. I then tried to upload an image to the new server and it finished the imaging process showing the task was completed on the machine, but then it got to the updating the database and then gave me this error: “Error Returned: Type: 2, File: /var/www/fog/lib/fog/fog.tftp.class.php, Line 470, Message: ftp_login(): Login incorrect., Host: 10.40.22.69 Username: fogproject”
I would assume that it has something to do with importing the old settings and it not matching what I set for the password setting the new server up, but am not sure. If I go to the TFTP section in the web interface, there is a password set there, but it is a long string of random characters. Is there a way to change the TFTP FTP password on the server and the web interface to fix this issue?
Any help would be appreciated!
-
@jaoyer hello. Everything is well documented on https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG give it a read.
-
@AUTH-IT-Center - Thanks for pointing me in the right direction! I knew it was something simple. I had been looking at some of the wiki stuff and forum posts, but they both were a few years out of date, so I wanted to double check before I broke something else! Thanks again for your help!
-
Please be advised that the FOG server migration, as described in the link, does not work well for existing Hosts. While the process migrates the hosts’ info that’s stored in the database, it doesn’t take into account that the new FOG server will have a new CA named exactly the same as the old server’s CA. When you follow this migration guideline, your existing hosts will not connect to the new server at a new IP address, that has a new CA unless you remove the old FOG CA from every client. This is possible thru GPOs etc, (as described by @jj=fullmer) but it’s tricky and can’t be done with FOG (since there is no way to run a snaping from the new server until the CA is already removed from the client). If your FOG system is used on more than on AD domain, then the problem becomes compounded.
I opted to harvest the certs and CA from my old server and put them on the new server. This means I had to use the old server’s IP address on the new server. This to make the old cert & CA usable by the old clients). The Reset Encryption button in the WebUI doesn’t reset the CA.
I’m working on a post to document what I did. I have several sites, each with a FOG Storage Node - something else that is omitted in the migration guide link.
I can’t say that my process will work for anyone else. I had v1.5.10 on all servers before and after I migrated. My migration took place on a network that didn’t change. My goal was to retire CEntOS 7 and move to ALMALINUX, which I did. I migrated all my images and snapins and the configuration of every host. With this approach, the Reest Encryption button was necessary, but since the CA was the same on the servers and the hosts, everything worked as it did before.
I’ll get the completed instructions posted as soon as I can.
Jim Graczyk
-
@Jim-Graczyk obviously your setup is more complex than others and will happily wait for the steps you took to migrate.
In our case we migrated from CentOS 7 to Ubuntu 22 following the migration guide (for images, ssl certs, didn’t create new CA https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG#If_old_server_was_FOG_1.3.0.2B ) with new server name, ip (same cname) and by only resetting encryption data on all hosts the fog clients worked smoothly.
-
The wiki on migration covers migrating a single FOG server using the only workable process, so I’ll leave that alone.
I think my issue with the entire “Server Migration” process is that it requires you take FOG down at the onset of the process - before you attempt to install FOG on the new server. This obviously stops all the PC IT maintenance processes FOG provides IT support, but also FOG’s benefits to the end users of the hosts, until the new server/system is back up and working.
I’ve used FOG on a fairly large scale - some instances have 10+ remote sites, each with its own FOG Storage Node. To say that shutting it down before starting migration is inconvenient to the business is an understatement. Storage node migration didn’t require that the storage node had use the same IP as the old storage node - so that helped.
I hope that my initial post to you comes up when other FOG users search “FOG Migration”, so they don’t waste the time I did trying to build a completely new FOG system, including storage nodes, to cut over to, only to find that you can image PCs and create new hosts, but the exiting host would not talk to the new server system - so all the existing host configuration is lost (a large chunk of work). Ironically, there are numerous FOG wikis that address most issues that I ran into - creating new certs, the ever-present Reset Encryption on the FOG Client, etc., but none mentioned that the CA of the old system HAD to be used in place of the new.
I’m glad there was some way forward without having to reconfigure everything manually, but like many things in FOG wikis, everything in them is true, but context and limitations are not defined at the beginning. Even the migration process link didn’t spell out requirements, nor include remote sites and storage nodes. It needs to spell out that harvesting the CA and certs and using the old server’s IP address are as important as the database, snapins, and images - and this is the ONLY way to migrate.
So - a suggestion to the great minds working on FOG:
Create a way to change the FOG Client CA in one step - delete old and replace new - from within the FOG Client. This could be something issued from the old FOG server, for security reasons. CA deletion should also be built into the FOG Client Installation MSI/EXE. I use FOG to build portable Windows images that are company and FOG server independent. The FOG client is installed at the initial boot and replaced in the image as FOG evolves.
If that capability could be added, migration would be possible such that the new system w database, snapins, images, host configs, could be build out with multi-storage nodes and multi-locations, side-by-side with the old FOG system, gated only by DHCP boot settings at each site (IP broadcast space).
Jim Graczyk
