Server Manager Not Listing Namespaces

[tinsmanj]

I've been having an issue with the Server Manager not listing the namespaces underneath the server. This started happening after upgrading the Intersystems Server Manager past version 3.8.0. When I revert back to that version, the namespaces get listed (see below).

When using any version after that version 3.8.0 it just indicates the server is unavailable (see below).

My connection to the IRIS server is through a connection provided by an AWS session manager instance - I think I've identified that correctly. I use the "aws ssm start-session" command to map a local port to a port on the the AWS server on which the IRIS instance resides.

What other information can I collect to provide more details?

Regards,
Jim Tinsman

[gjsjohnmurray]

https://github.com/intersystems-community/intersystems-servermanager/releases gives you access to all the beta builds. So if you have already determined that the Marketplace 3.8.1 has a problem but 3.8.0 doesn't the please bisect your way through the beta builds between those points

[tinsmanj]

Version 3.8.1-beta-2 works but Version 3.8.1-beta-3 doesn't work. So some change between those two BETA versions changed such that when I connect through the AWS session manager it stops displaying namespaces.

[gjsjohnmurray]

Here's what changed:

v3.8.1-beta.2...v3.8.1-beta.3

The associated PR focused on handling cases where a user's objectscript.conn settings object includes a docker-compose sub-object. I'd be surprised if yours does, but please check in your user-level settings.json file.

I guess the change may have had side-effects. What does your xxx.code-workspace file look like? If posting its contents here please mask any non-public information.

[tinsmanj]

Neither the user or the workspace has a docker-compose reference. Below is my xxx.code-workspace file.

{ "folders": [ { "name": "mundus_dev:SITEONE", "uri": "isfs://mundus_dev:siteone/" }, { "name": "mundus_dev:EQSDEV", "uri": "isfs://mundus_dev:eqsdev" }, { "name": "mundus_dev:JTDEV", "uri": "isfs://mundus_dev:jtdev" }, { "name": "mundus_dev:VMDEV", "uri": "isfs://mundus_dev:vmdev" }, { "name": "mundus_dev:DEVCENTRAL", "uri": "isfs://mundus_dev:devcentral" } ] }

Here are the contents of my user settings file:
{ "intersystems.servers": { "mundus_dev": { "webServer": { "scheme": "http", "host": "localhost", "port": 57772 }, "description": "Mundus Development IRIS Instance", "username": "jimtins" }, "localhost": { "webServer": { "scheme": "http", "host": "localhost", "port": 57772 }, "username": "jimtins", "description": "Added by Deltanji extension for secure password storage." }, "local_iris": { "webServer": { "scheme": "http", "host": "localhost", "port": 52773 }, "description": "Local Docker IRIS Installation", "username": "jtinsman" } }, "objectscript.showProposedApiPrompt": false, "objectscript.compileFlags": "ck", "intersystems.language-server.suggestTheme": false, "deltanji.serverURL": "http://localhost:57772/deltanji/Deltanji.Portal.cls" }

I recall at one point investigating it and found something that indicated it was attempting to connect as "UnknownUser". However, I can' remember where I found that.

Jim

[gjsjohnmurray]

What version of the InterSystems ObjectScript extension are you running?

[tinsmanj]

3.0.5

[gjsjohnmurray]

I suggest you create a one-folder workspace, then use Web Gateway's tracing facility to look for evidence of something going wrong during the /api/atelier REST calls that Server Manager makes.

It might be worth opening a WRC case too, as that'll give you a private channel for sharing trace details on.

[tinsmanj]

I will open a WRC ticket. I didn't see anything in the trace. In the security audit log, I saw some LoginFailure events associated with the "UnknownUser" account, followed by successful login events when it connected to the namespace.