nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

WebGISDR and Hosts File

NathanHeickLACSD

I'm trying to understand how the etc/hosts file works in conjunction with migrating to a new server using webgisdr. Is the only purpose to resolve URLs in the source backup to the target machine for the duration of the backup? Or is the information somehow used in the configuration of ArcGIS Enterprise when you install it? The documentation and various blogs indicate to set the etc/hosts file prior to installing ArcGIS Enterprise. I'm trying to understand if you can switch from machine names to using aliases in the migration process and how you would set up the etc/hosts file.

Najděte více příspěvků označených jako

Accepted answers

JonathanEpstein

In my experience, the hostnames prior to taking the WebGisDR backup must exactly match the hostnames used when importing that WebGisDr backup. One of these easiest ways to achieve that goal is via creative use of the etc/hosts file(s) on both the old hosts and the new ones.

Note for example that the IP addresses needn't match, only the host names.

I have had successful experience with this, on a 6-host Linux Enterprise system.

All comments

ZachBodenner

Hi @NathanHeickLACSD , did you wind up completing this migration successfully? I'm working on migrating my deployment from one machine to a new one with the eventual goal of distributing the deployment to multiple machines after the migration. Did you find it was actually necessary to do anything with the host names? My network admin thinks that our DNS should take of that without us having to touch them. Additionally, how did you manage getting the public URLs to remain the same using web adaptors? Did you install a temporary web adaptor on a different machine than your existing one that had the same name?

NathanHeickLACSD

I will perform a test server installation and restore today. I read more forum posts last night and came to the same conclusion as @JonathanEpstein. The main purpose of the etc/hosts file seems to be to accomplish the requirement that the source and target systems of the backup have the same public portal and server URLs. That seems more like a webgisdr requirement for it to work.

Reading that blog that @A_Wyn_Jones referred to, which was the impetus for my question, I was mainly concerned about the section where it said:

3. Before you install any software on the new machine, update its etc\hosts file to resolve the IP address of the new machine to newmachine.domain.local as well as enterprise.domain.com:

10.0.0.2 newmachine.domain.local enterprise.domain.com

Listing the local hostname into the etc\hosts file first ensures that the software will store that name in configuration files, rather than the DNS alias. Adding the DNS alias ensures the deployment can be configured with the DNS alias without impacting production.

I was worried about how setting up your etc/hosts file impacts the URLs stored in the Portal, Server, and Data Store configs. The blog covers two cases, namely using a backup that used machine names and one that used aliases. Our source backup uses machine names but I want to set up the new server with aliases. I succeeded in doing that on a new 10.9.1 installation but I want to move from a backup based on machine names to a server based on aliases.

It seems the installation software uses the left-most entry when it wants to store a domain name in the AGE configs. I learned how the etc/hosts file doesn't support C name records like a DNS server, so maybe everything to the right resolves to the same IP address but the first domain name is the one it uses when it wants to store a domain name over an IP address.

No matter what, though, I am seeing that the public URLs have to match the source to be able to run the backup, but I want to end with different public URLs when I am finished.. I think I can set up Portal, Server, and the DataStore with the aliases I want but use the etc/hosts file and the source public URLs to set up the web adaptors. Then, after the restore, I will attempt to uninstall and reinstall the web adaptors using the aliases I want to use. Hopefully, this will do the trick.

My main concern is just understanding the mechanics. I don't quite understand how the left most domain name in the etc/hosts file gets used. I understand how the public URLs have to match. I have some experience installing 10.9.1 using aliases. I just worry about what internal URLs I might end up with inside the ArcGIS Enterprise configs.

With regards to the content, I definitely will be doing some scripting to update item URLs and URLs in item data. That's partially why we want our new installation to use aliases. We want to get away from the machine names.

Thanks for your help,

Nathan

A_Wyn_Jones

There's a thorough description of Hosts file being used in this regard here:

https://www.esri.com/arcgis-blog/products/arcgis-enterprise/administration/migrate-to-a-new-machine-in-arcgis-enterprise-two/

This effectively creates an isolated environment where your friendly DNS alias will resolve to your new machine (and not the existing deployment) allowing you to build/import content and test in isolation. Recent versions of WebGISDr do support different hostnames for Enterprise machines - it's the content creation URL that's important to maintain.

As you create content in portal - the URL used to create that content is engrained into the Portal content. This is normally (and hopefully) a friendly alias.

JonathanEpstein

Note for example that the IP addresses needn't match, only the host names.

I have had successful experience with this, on a 6-host Linux Enterprise system.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.