I have followed the instructions from https://www.shapeblue.com/dynamic-roles-in-cloudstack/ and can confirm that after running the migration python script I was able to login to the new management server.
Perhaps the installation manuals for the multiple management server setup should mention the above instructions for the ACS servers that were crated before 4.9.x. In my case, I've installed ACS back in 2012 and didn't update the permissions structure Thanks everyone for looking into this issue. Andrei ----- Original Message ----- > From: "Andrei Mikhailovsky" <and...@arhont.com.INVALID> > To: "users" <users@cloudstack.apache.org> > Cc: "Harikrishna Patnala" <harikrishna.patn...@shapeblue.com> > Sent: Tuesday, 2 August, 2022 15:49:55 > Subject: Re: Unable to login to GUI onto second management server > 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
