Comment by mystraline

18 hours ago

Uh, that is demonstrably not true. ArcGIS Enterprise (Portal, hosting servers, datastore, geoevent) all also run on Linux.

Now where ArcGIS enterprise succeeds is being in an actual enterprise (thousands of users), having groups collaborate, data control, and more. None of the enterprise-y bits exist.

And QGis is more akin to ArcGIS Pro, not Enterprise.

Now, yes, it is definitely resource hungry. And also, if you administer it, HA isn't really HA. Theres tons of footguns in how they implement HA that makes it a SPOF.

Also, for relevancy, I was the one who worked with one of their engineers and showed that WebAdapters (iis reverse proxy for AGE) could be installed multiply on the same machine, using SNI. 11.2 was the first to include my contribution to that.

Edit: gotta love the -1s. What do you all want? Screenshots of my account on my.esri.com? Pictures of Portal and the Linux console they're running on? The fact its 80% Apache Tomcat and Java, with the rest Python3? Or how about the 300 ish npm modules, 80 of which on the last security scan I did showed compromise?

Everything I said was completely true. This is what I'm paid to run. Can't say who, cause we can't edit posts after 1 or so hours.

I would LOVE to push FLOSS everywhere. QGIS would mostly replace ArcGIS Pro, with exception of things like Experience Builder and other weird vertical tools. But yeah. I know this industry. Even met Jack a few times.

8 comments

mystraline

Reply
rthnbgrredf  7 hours ago

> demonstrably not true ... all also run on Linux

I'm not saying that it can't run in Linux, I'm saying there is no native binary for Linux.

They have bash scripts that starts the windows executables in wine.

You can see that when you read the scripts or in htop.

AuthorizedCust  2 hours ago

> ArcGIS Enterprise (Portal, hosting servers, datastore, geoevent) all also run on Linux

This isn’t about what platform an enterprise hosts its cloud offerings on. That barely affects the customer experience, outside of lock-in situations.

The concern was on OS support for customer-run software.

jiggawatts  16 hours ago

Speaking of ArcGIS and reverse proxies, they were circulating a single-file .ashx script for about a decade that ended up being the single worst security breach at several large government customers of mine… ever. By a mile.

For the uninitiated: this proxy was a hack to work around the poor internal architecture of ArcGIS enterprise, and to make things “work” it took the target server URL as a query parameter.

So yes, you guessed right: any server. Any HTTP to HTTPS endpoint anywhere on the network. In fact you could hack TCP services too if you knew a bit about protocol smuggling. Anonymously. From the Internet. Fun!

I’m still finding this horror embedded ten folders deep in random ASP.NET apps running in production.

  • mystraline  16 hours ago

    I'm acutely aware of that.

    The folks who hired me didn't realize I was also a hacker. I did my due diligence as well, and this was more 10.3 . And yes, it was terrible.

    I know that FEMA and EPA both are running their public portals as 10.8 , which is really bad. There's usually between 8-12 critical (cvss 3.0 9 or greater) per version bump. Fuck if I know how federal acquisitions even allow this, but yeahhh.

    Also, on Hosting Server install, theres configs with commented out internal ticket numbers. You search this on google, and you'll find out 25% of the IPs that hit it are Chinese. Obviously, for software thats used predominantly in the US government, a whole bunch of folks in opposition to us are writing it. And damn, the writing quality is TERRIBLE.

    basically, if you have to run ArcGIS enterprise, keep it internal only if at all possible. Secure Portal operation is NOT to be trusted. And if you do need a public API, keep the single machine in DMZ, or better yet, isolated on a cloud. Copy the data as a bastion, like a S3 bucket or rsync, or something. Dont connect it to your enterprise.

    Oh and even with 11.5 , there are a multitude of hidden options you can set with the config for WebAdapter, including full debug. Some even save local creds like for portaladmin.

    Oh yeah, and if you access the Portal postgres DB, and query the users table, you'll find 20 or so Esri accounts that are intentionally hidden from the Users list in portal on :7443 . The accounts do appear disabled... But, why are they even there to begin with?