importSite different OS

danbecker

Used portalAdmin exportSite on a Linux portal machine.

Now I'm using portalAdmin importSite on a windows machine and it errors out.

In c:\arcgisportal\log\db log I'm getting an error:

"Line 7 of pg_hba.cong, local connections are not supported by this build".

postgreSQL docs state that "local" specifies unix domain sockets. So the .conf file on win needs to be changed to "host". I'm guessing that the Linux pg_hba.conf is restored, causing this issue.

https://www.postgresql.org/docs/11/auth-pg-hba-conf.html

I'm using export/importSite because webgisdr method is unable to backup a site that uses a mix of Linux/Win VMs, which is the case for us.

Any advice?

danbecker

Our Enterprise deployment of Portal (Linux), Datastore (Linux), Postgres (Linux) and Server/webadaptor (Win) is NOT recommended for anyone reading this. There's not an out of the box method of migrating Enterprise site/data with mixed OS.

webgisdr - not an option since the backup operation must access the same file share across all VMs. Lin/Win UNC paths are different.

REST export/importSite - not an option since importSite also restores all site settings on the target VMs, so they have to be the same OS the backup was taken from.

Azure Enterprise VMs are all windows. Enterprise components installed on separate VMs (new local domain names as well). Using hosts file edits on the VMs, Azure Server machine was federated with the same production.domain.com alias as used on-prem.

In order to use ArcGIS API for Python to copy data between sites, both sites had to be accessible, so Azure webadaptors were configured with newsite.domain.com DNS alias. Public DNS A-record for newsite.domain.com was created, pointing to Azure Web App Gateway. I noticed that attempting to login to Azure server manager via internal.domain.com:6443, you're redirected to federated URL (production.domain.com) to login, again a hosts file manipulation so that Azure site handles the request.

ArcGIS API for Python is the only method of migrating content, I'm using these examples: https://developers.arcgis.com/python/samples/clone-portal-users-groups-and-content-rn/

Users and groups were easy. Web maps were also copied, but I'm noticing the feature service layers (none are hosted, all are referenced) in web maps point to newsite.domain.com?id=guidFromProductionItem

So, when I used the above python GIS.content.add() method to move the feature services, I specified item_id=guidFromProductionItem. Now the feature services in Azure have the same itemID, but the referenced REST service (production.domain.com/server) is obliviously not created. Using Pro, I attempted to overwrite the Portal feature service that I had copied using Python, but that doesn't work, error: unable to retrieve server details. That makes sense because the services doesn't actually exist in Azure.

So, I published a new feat. service from Pro using the same folder/serviceName, but this creates a duplicate feature service item in the Portal. Any pointers here? Can you publish services from Pro, and not create a Portal Item in the federated portal? That workflow is accomplished via Python GIS.content.add() since we need to maintain the itemID.

The good news is that the web maps that were copied using Python work without issue after the service is published to Azure. Webmaps contain the old layer references (id=guidFromProductionItem), which were moved to Azure, which point to the newly published Feat Service, so all is well. But, I have that duplicate portal feature service item? If I delete it in Portal, then the server service is also deleted. It's like I need to delete the Pro-created feat service Portal Item, then link the service to the feat service Portal Item that I copied with python. Is this possible?