It seems that my issue is closely related to the issue discussed here: https://github.com/apache/cloudstack/issues/3200
I will investigate this further Andrei ----- Original Message ----- > From: "Andrei Mikhailovsky" <and...@arhont.com.INVALID> > To: "Harikrishna Patnala" <harikrishna.patn...@shapeblue.com> > Cc: "users" <users@cloudstack.apache.org> > Sent: Sunday, 31 July, 2022 22:56:31 > Subject: Re: Unable to login to GUI onto second management server > Hi Harikrishna, > > Tried the below, but still have the same issue. > > also, after trying what you've suggested, I've started the old management > server > and I was still able to login. not sure if the host setting does anything > login > related... > > Andrei > >> From: "Harikrishna Patnala" <harikrishna.patn...@shapeblue.com> >> To: "Andrei Mikhailovsky" <and...@arhont.com> >> Cc: "users" <users@cloudstack.apache.org> >> Sent: Thursday, 28 July, 2022 09:54:39 >> Subject: Re: Unable to login to GUI onto second management server > >> Hi Andrei, > >> Can you please also try the below steps? I'm just making sure all pointers >> are >> to the new management server only. > >> 1. Keep only the new management server IP in the host configuration. >> 2. Stop the old management server >> 3. Restart the new management server >> Thanks, >> Harikrishna > >> From: Andrei Mikhailovsky <and...@arhont.com> >> Sent: Wednesday, July 27, 2022 6:45 PM >> To: Harikrishna Patnala <harikrishna.patn...@shapeblue.com> >> Cc: users <users@cloudstack.apache.org> >> Subject: Re: Unable to login to GUI onto second management server >> Hi Harikrishna, > >> I have added the new management server IP address into the host configuration >> from the gui. It now shows: > >> host The ip address of management server. This can also accept comma >> separated >> addresses. Advanced >> 192.168.169.13,192.168.169.21 > >> After that I've started the new management server and unfortunately, I still >> have the same issue. > >> I have also noticed that after starting the new management server, the table >> mshost has been updated to reflect the server status as Up.: > >>| 4 | 115129173025114 | 1658099918669 | ais-cloudhost13.csprdc.arhont.com | >>| 98405826-0861-11ea-a1da-80000003fe80 | Up | 4.16.1.0 | 127.0.0.1 | 9090 | >> | 2022-07-27 13:10:05 | NULL | 0 | >>| 5 | 165004275141402 | 1658927302926 | ais-compute1.cloud.arhont.com | >>| 0d1522a5-5d08-46af-b59c-b577aa22e9bb | Up | 4.16.1.0 | 192.168.169.21 | >>9090 | >> | 2022-07-27 13:08:32 | NULL | 0 | > >> Anything else I should try? > >> Thanks > >> Andrei > >>> From: "Harikrishna Patnala" <harikrishna.patn...@shapeblue.com> >>> To: "Andrei Mikhailovsky" <and...@arhont.com>, "users" >>> <users@cloudstack.apache.org> >>> Sent: Wednesday, 27 July, 2022 07:21:24 >>> Subject: Re: Unable to login to GUI onto second management server > >>> Hi Andrei, > >>> If the purpose of the second management server is about migration please >>> ignore >>> the previous reply. > >>> You have the right pointer to the procedure and I hope you have followed it. > >>> Please try to provide the following information. > >>> 1. Is the old management server also in the 4.16.1 version? >>> 2. Which database.properties file you have changed to point to the new >>> database >>> ? >>> 3. Can you check the database table "configuration", what is the value >>> for the >>> configuration with the name "host", is it your new MS host address ? >>> 4. Also, check the "mshost" table in the database if it is pointing to >>> the new >>> management server. >>> Regards, >>> Harikrishna > >>> From: Andrei Mikhailovsky <and...@arhont.com> >>> Sent: Monday, July 25, 2022 7:46 PM >>> To: users <users@cloudstack.apache.org> >>> Cc: Harikrishna Patnala <harikrishna.patn...@shapeblue.com> >>> Subject: Re: Unable to login to GUI onto second management server > >>> Hi Harikrishna, > >>> Having read the links that you've sent I am not sure that my issues are >>> related. >>> Perhaps I should have explained my current set up / intensions a bit more. >>> My >>> main reasons for adding the multiple management servers is not to provide >>> the >>> HA / load balancing, but rather to migrate the current management server >>> from >>> old hardware to the new one. I was referring to the post sent by Andrija >>> Panic >>> ( [ https://www.mail-archive.com/users@cloudstack.apache.org/msg32889.html | >>> https://www.mail-archive.com/users@cloudstack.apache.org/msg32889.html ] ) >>> where Andrija has suggested that one should install the second management >>> server, connect it to the database, move the database to a new server and >>> change the database properties to point the new management server to the new >>> db. > >>> In my tests, I have installed the second management server without any >>> proxy/load balancing and I tried to connect and authenticate directly to >>> the IP >>> address of the second management server. I've tried it with the primary >>> management server switched on and off, but I still have the same issues. If >>> I >>> am connecting directly to the new management server IP, I don't see how >>> having >>> nginx proxy settings changes would fix my issue. Also, I have not seen >>> anything >>> in the documentation that explicitly requires having a proxy if you install >>> the >>> second management server. > >>> Why do you think my issue relates to CORS? > >>> Andrei > >>> ----- Original Message ----- >>> > From: "Harikrishna Patnala" <harikrishna.patn...@shapeblue.com> >>> > To: "users" <users@cloudstack.apache.org> >>> > Sent: Wednesday, 20 July, 2022 05:10:13 >>> > Subject: Re: Unable to login to GUI onto second management server > >>> > Hi Andrei, > >>> > This looks to me like a CORS issue. > >>> > Have you set up any load balancer for these management servers. There is a >>> > section >>>> [ >>>> http://docs.cloudstack.apache.org/en/4.16.1.0/adminguide/reliability.html#management-server-load-balancing >>> > | >>> http://docs.cloudstack.apache.org/en/4.16.1.0/adminguide/reliability.html#management-server-load-balancing >>> ] >>> > which you need to configure so that you will not face issues with HA and >>> > agents >>> > later on. > > >>> > You may need to consider setting cookies like below. > >>> > If you are using nginx, try with "proxy_cookie_path / "/; Secure; >>> > SameSite=None;";" and a similar thing should work haproxy too. > >>> > I got this reference from a previous discussion on a PR >>> > [ >>> > https://github.com/apache/cloudstack-primate/pull/898#issuecomment-760227366 >>> > | >>> https://github.com/apache/cloudstack-primate/pull/898#issuecomment-760227366 >>> ] , >>> > please refer to it if it helps solve your problem. > > >>> > Regards, >>> > Harikrishna >>> > ________________________________ >>> > From: Andrei Mikhailovsky <and...@arhont.com.INVALID> >>> > Sent: Tuesday, July 19, 2022 4:06 PM >>> > To: users <users@cloudstack.apache.org> >>> > Subject: Re: Unable to login to GUI onto second management server > >>> > Bump please > > > > > > >>> > ----- Original Message ----- >>> >> From: "Andrei Mikhailovsky" <and...@arhont.com.INVALID> >>> >> To: "users" <users@cloudstack.apache.org> >>> >> Sent: Monday, 18 July, 2022 11:45:05 >>> >> Subject: Unable to login to GUI onto second management server > >>> >> Hello, > >>> >> I've recently installed a second management server ACS 4.16.1 following >>> >> the >>> >> installation instructions in section Additional Management Servers from >>> >> the >>> >> official documentation ( [ >>>>> [ >>>>> http://docs.cloudstack.apache.org/en/4.16.1.0/installguide/management-server/index.html >>> >> | >>> http://docs.cloudstack.apache.org/en/4.16.1.0/installguide/management-server/index.html >>> ] > >>>>> [ >>>>> http://docs.cloudstack.apache.org/en/4.16.1.0/installguide/management-server/index.html >>> >> | >>> http://docs.cloudstack.apache.org/en/4.16.1.0/installguide/management-server/index.html >>> ] >>> >> ] ). I've installed the Ubuntu package on the second server of the same >>> >> version >>> >> as the primary management server. Configured the database with >>> >> cloudstack-setup-databases command followed by running >>> >> cloudstack-setup-management as per the documentation. There were no >>> >> errors in >>> >> the process and the cloudstack-management.service seems to have started >>> >> just >>> >> fine. The second ACS management service connected to the same database >>> >> as the >>> >> primary one and the login web GUI loaded just fine. The management >>> >> server logs >>> >> seems to show no apparent errors in the startup. The only exceptions I >>> >> was >>> >> getting in the logs were from the host agents showing status >>> >> Disconnected. > >>> >> So, I have tried to login (using domain and ROOT login accounts) to the >>> >> web gui >>> >> of the second management server and the page just hangs after I enter the >>> >> credentials and press the Login button. I've tried several different >>> >> browsers >>> >> at no avail. Supplying the incorrect login credentials produce the error >>> >> though. The management server logs do not show any errors during the >>> >> login >>> >> process. In fact, it seems that all commands produce " is allowed to >>> >> perform >>> >> API calls: 0.0.0.0/0,::/0 " message in the logs. There are no exceptions >>> >> that I >>> >> can see either: > >>> >> -------------- > > >>> >> 2022-07-18 01:17:33,743 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-285:ctx-0cf08734) >>> >> (logid:94b277ba) ===START=== 192.168.169.251 -- POST >>> >> 2022-07-18 01:17:33,750 DEBUG [c.c.u.AccountManagerImpl] >>> >> (qtp681094281-285:ctx-0cf08734) (logid:94b277ba) Attempting to log in >>> >> user: >>> >> andrei in domain 1 >>> >> 2022-07-18 01:17:33,752 DEBUG [o.a.c.s.a.PBKDF2UserAuthenticator] >>> >> (qtp681094281-285:ctx-0cf08734) (logid:94b277ba) Retrieving user: andrei >>> >> 2022-07-18 01:17:33,969 DEBUG [c.c.u.AccountManagerImpl] >>> >> (qtp681094281-285:ctx-0cf08734) (logid:94b277ba) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:33,969 DEBUG [c.c.u.AccountManagerImpl] >>> >> (qtp681094281-285:ctx-0cf08734) (logid:94b277ba) User: andrei in domain >>> >> 1 has >>> >> successfully logged in >>> >> 2022-07-18 01:17:34,011 INFO [c.c.a.ApiServer] >>> >> (qtp681094281-285:ctx-0cf08734) >>> >> (logid:94b277ba) Current user logged in under Etc/UTC timezone >>> >> 2022-07-18 01:17:34,011 INFO [c.c.a.ApiServer] >>> >> (qtp681094281-285:ctx-0cf08734) >>> >> (logid:94b277ba) Timezone offset from UTC is: 0.0 >>> >> 2022-07-18 01:17:34,015 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-285:ctx-0cf08734) >>> >> (logid:94b277ba) ===END=== 192.168.169.251 -- POST >>> >> 2022-07-18 01:17:34,123 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-280:ctx-fafe166c) >>> >> (logid:41d7b4d5) ===START=== 192.168.169.251 -- GET >>> >> listall=true&command=listZones&response=json >>> >> 2022-07-18 01:17:34,133 DEBUG [c.c.a.ApiServer] >>> >> (qtp681094281-280:ctx-fafe166c >>> >> ctx-2269cc31) (logid:41d7b4d5) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:34,133 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-28:ctx-0906d03f) >>> >> (logid:56b10f23) ===START=== 192.168.169.251 -- GET >>> >> command=listApis&response=json >>> >> 2022-07-18 01:17:34,137 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-280:ctx-fafe166c >>> >> ctx-2269cc31) (logid:41d7b4d5) ===END=== 192.168.169.251 -- GET >>> >> listall=true&command=listZones&response=json >>> >> 2022-07-18 01:17:34,144 DEBUG [c.c.a.ApiServer] >>> >> (qtp681094281-28:ctx-0906d03f >>> >> ctx-5a2a7dde) (logid:56b10f23) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:34,153 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-318:ctx-fc79b118) >>> >> (logid:8a349f6d) ===START=== 192.168.169.251 -- GET >>> >> command=cloudianIsEnabled&response=json >>> >> 2022-07-18 01:17:34,163 DEBUG [c.c.a.ApiServer] >>> >> (qtp681094281-318:ctx-fc79b118 >>> >> ctx-40fd8f3a) (logid:8a349f6d) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:34,168 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-318:ctx-fc79b118 >>> >> ctx-40fd8f3a) (logid:8a349f6d) ===END=== 192.168.169.251 -- GET >>> >> command=cloudianIsEnabled&response=json >>> >> 2022-07-18 01:17:34,176 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-34:ctx-20a51695) >>> >> (logid:2436a576) ===START=== 192.168.12022-07-18 01:17:34,123 DEBUG >>> >> [c.c.a.ApiServlet] (qtp681094281-280:ctx-fafe166c) (logid:41d7b4d5) >>> >> ===START=== >>> >> 192.168.169.251 -- GET listall=true&command=listZones&response=json >>> >> 2022-07-18 01:17:34,133 DEBUG [c.c.a.ApiServer] >>> >> (qtp681094281-280:ctx-fafe166c >>> >> ctx-2269cc31) (logid:41d7b4d5) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:34,133 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-28:ctx-0906d03f) >>> >> (logid:56b10f23) ===START=== 192.168.169.251 -- GET >>> >> command=listApis&response=json >>> >> 2022-07-18 01:17:34,137 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-280:ctx-fafe166c >>> >> ctx-2269cc31) (logid:41d7b4d5) ===END=== 192.168.169.251 -- GET >>> >> listall=true&command=listZones&response=json >>> >> 2022-07-18 01:17:34,144 DEBUG [c.c.a.ApiServer] >>> >> (qtp681094281-28:ctx-0906d03f >>> >> ctx-5a2a7dde) (logid:56b10f23) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:34,153 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-318:ctx-fc79b118) >>> >> (logid:8a349f6d) ===START=== 192.168.169.251 -- GET >>> >> command=cloudianIsEnabled&response=json >>> >> 2022-07-18 01:17:34,163 DEBUG [c.c.a.ApiServer] >>> >> (qtp681094281-318:ctx-fc79b118 >>> >> ctx-40fd8f3a) (logid:8a349f6d) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:34,168 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-318:ctx-fc79b118 >>> >> ctx-40fd8f3a) (logid:8a349f6d) ===END=== 192.168.169.251 -- GET >>> >> command=cloudianIsEnabled&response=json >>> >> 2022-07-18 01:17:34,176 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-34:ctx-20a51695) >>> >> (logid:2436a576) ===START=== 192.168.12022-07-18 01:17:34,123 DEBUG >>> >> [c.c.a.ApiServlet] (qtp681094281-280:ctx-fafe166c) (logid:41d7b4d5) >>> >> ===START=== >>> >> 192.168.169.251 -- GET listall=true&command=listZones&response=json >>> >> 2022-07-18 01:17:34,133 DEBUG [c.c.a.ApiServer] >>> >> (qtp681094281-280:ctx-fafe166c >>> >> ctx-2269cc31) (logid:41d7b4d5) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:34,133 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-28:ctx-0906d03f) >>> >> (logid:56b10f23) ===START=== 192.168.169.251 -- GET >>> >> command=listApis&response=json >>> >> 2022-07-18 01:17:34,137 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-280:ctx-fafe166c >>> >> ctx-2269cc31) (logid:41d7b4d5) ===END=== 192.168.169.251 -- GET >>> >> listall=true&command=listZones&response=json >>> >> 2022-07-18 01:17:34,144 DEBUG [c.c.a.ApiServer] >>> >> (qtp681094281-28:ctx-0906d03f >>> >> ctx-5a2a7dde) (logid:56b10f23) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:34,153 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-318:ctx-fc79b118) >>> >> (logid:8a349f6d) ===START=== 192.168.169.251 -- GET >>> >> command=cloudianIsEnabled&response=json >>> >> 2022-07-18 01:17:34,163 DEBUG [c.c.a.ApiServer] >>> >> (qtp681094281-318:ctx-fc79b118 >>> >> ctx-40fd8f3a) (logid:8a349f6d) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:34,168 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-318:ctx-fc79b118 >>> >> ctx-40fd8f3a) (logid:8a349f6d) ===END=== 192.168.169.251 -- GET >>> >> command=cloudianIsEnabled&response=json >>> >> 2022-07-18 01:17:34,176 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-34:ctx-20a51695) >>> >> (logid:2436a576) ===START=== 192.168.169.251 -- GET >>> >> command=listLdapConfigurations&response=json >>> >> 2022-07-18 01:17:34,185 DEBUG [c.c.a.ApiServer] >>> >> (qtp681094281-34:ctx-20a51695 >>> >> ctx-73e9ab8d) (logid:2436a576) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:34,188 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-34:ctx-20a51695 >>> >> ctx-73e9ab8d) (logid:2436a576) ===END=== 192.168.169.251 -- GET >>> >> command=listLdapConfigurations&response=json >>> >> 2022-07-18 01:17:34,196 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-343:ctx-43a80d6a) >>> >> (logid:8d0a86c5) ===START=== 192.168.169.251 -- GET >>> >> command=listCapabilities&response=json >>> >> 2022-07-18 01:17:34,208 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-343:ctx-43a80d6a >>> >> ctx-dc6fb55f) (logid:8d0a86c5) ===END=== 192.168.169.251 -- GET >>> >> command=listCapabilities&response=json >>> >> 2022-07-18 01:17:34,218 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-339:ctx-7d400edb) >>> >> (logid:a57fa769) ===START=== 192.168.169.251 -- GET >>> >> username=andrei&command=listUsers&response=json >>> >> 2022-07-18 01:17:34,227 DEBUG [c.c.a.ApiServer] >>> >> (qtp681094281-339:ctx-7d400edb >>> >> ctx-2b12ac89) (logid:a57fa769) CIDRs from which account >>> >> 'Acct[06eedc2c-65f2-11e3-9bd1-d8d38559b2d0-admin_group] -- Account >>> >> {"id": 2, >>> >> "name": "admin_group", "uuid": "06eedc2c-65f2-11e3-9bd1-d8d38559b2d0"}' >>> >> is >>> >> allowed to perform API calls: 0.0.0.0/0,::/0 >>> >> 2022-07-18 01:17:34,230 DEBUG [c.c.a.ApiServlet] >>> >> (qtp681094281-339:ctx-7d400edb >>> >> ctx-2b12ac89) (logid:a57fa769) ===END=== 192.168.169.251 -- GET >>> >> username=andrei&command=listUsers&response=json > > >>> >> -------------- > >>> >> I can successfully login to the primary management server. I've done some >>> >> further investigation from the client browser side to see what requests >>> >> are >>> >> being exchanged between the browser and the management server. It seems >>> >> that >>> >> the second management server gives me a bunch of 401 errors during the >>> >> login >>> >> session. There are some http 200 responses, but mainly 401For example: > >>> >> Client Request: >>> >> POST /client/api/ HTTP/1.1 > >>> >> Server Response: >>> >> HTTP/1.1 200 OK >>> >> {"loginresponse":{"username":"andrei","userid":"ee8bbe57-acce-47fa-8d9b-9e831dcf87a2","domainid":"334d7527-65f1-11e3-9bd1-d8d38559b2d0","timeout":1800,"account":"admin_group","firstname":"Andrei","lastname":"Mikhailovsky","type":"1","timezone":"Etc/UTC","timezoneoffset":"0.0","registered":"false","sessionkey":"XXXX"}} > >>> >> ----- > >>> >> Client Request: >>> >> GET /client/api/?listall=true&command=listZones&response=json HTTP/1.1 > >>> >> Server Response: >>> >> HTTP/1.1 401 Unauthorized >>> >> {"listzonesresponse":{"uuidList":[],"errorcode":401,"cserrorcode":9999,"errortext":"The >>> >> given command 'listZones' either does not exist, is not available for >>> >> user."}} > >>> >> ----- > >>> >> Client Request: >>> >> GET /client/api/?command=listApis&response=json HTTP/1.1 > >>> >> Server Response: >>> >> HTTP/1.1 200 OK >>> >> {"listapisresponse":{"count":96,"api":[{"name":"listResourceIcon","description":"Lists >>> >> the resource icon for the specified >>> >> resource(s)","since":"4.16.0.0","isasync":false,"related":"","params":[{"name":"resourcetype","description":"type >>> >> of the resource","type":"string","length":255,"required":true}, > >>> >> (Followed by about 200K other data in the above request) > >>> >> ----- > > >>> >> Client Requests: >>> >> GET /client/api/?username=andrei&command=listUsers&response=json HTTP/1.1 >>> >> GET /client/api/?command=listLdapConfigurations&response=json HTTP/1.1 >>> >> GET /client/api/?command=listCapabilities&response=json HTTP/1.1 > >>> >> Server Response (for the above 3 requests): >>> >> HTTP/1.1 401 Unauthorized >>> >> {"listusersresponse":{"uuidList":[],"errorcode":401,"cserrorcode":9999,"errortext":"The >>> >> given command 'listUsers' either does not exist, is not available for >>> >> user."}} > > >>> >> ---------------- > > >>> >> Does anyone know what could be causing the login issues on the second >>> >> management >>> >> server? How do I solve the issue? > > >> > > Many thanks
