When our cluster was upgraded, I somehow lost the ability to run ArcGIS Server. No problem, I said, I’ll just rebuild the machine. This is where I was again reminded that ArcGIS Server installation is very different from other Linux software.
The biggest issue is that ArcGIS installers will only run when logged in root. Yeah, not running a bash as root, or sudo’ing as root, or su’ing to root … you actually have to log in as root.
Herein lies the difficulty: the rest of the installer assumes a GUI (e.g., gnome or kde). You can’t login to gnome or kde as root.
If you’re doing best practice X tunneling with SSH, then you’re using private/public keys. So make sure that you create a .ssh profile with keys and copy over the authorized_keys directory from your normal user. I think this is where my immediate stumbling block was: when I first did this I wasn’t thinking as much about security, just seeing if it would work. I didn’t use keys. When I rebuilt the system, I did … and of course I disabled plaintext passwords. I didn’t even consider that I’d want to login as root through X/SSH, but I’d guarantee that’s how I did it the first time. This was also an issue with X, specifically, because X settings (e.g., $DISPLAY) would only be set for the logged in connection (my normal login) and not root, if not connected directly with root.
Finally, of course, everything ArcGIS runs through Wine on Linux (the Windows compatibility layer). It turned out there was a profile directory that was owned by another use
# chown -R root /root/arcgis/server/framework/runtime/.wine
Also two other things I found out during this process:
- set is a great command for debugging. I put set -x at the top of authorizeSoftware and this gave me all kinds of great diagnostic info, including THE LOCATION OF THE LOGS!!
- the software authorization log was located under: /root/arcgis/server/.Setup/softwareauthorization.log