Cloud hosted, unable to access admin after upgrade to v20

[Wills]

I'm running 3cx in a VPS. After upgrading to v20 I'm unable to access the admin button of the webapp. All i see is an "apps" link in the bottom left.

I have SSH access, and the system seems to be working fine after the upgrade. I am also very familiar with pgsql and ave access to the database (read only for now).

We had IP restrictions in place to limit access in v18, I'm reading in some posts that that was a mistake, so I tried accessing the portal via an SSH tunnel to see if that made any difference (it didnt):
I did this by setting the server.my3cx.ca to 127.0.0.1 in my laptop's /etc/hosts file, and then started a tunnel with

ssh -L 5001:localhost:5001 [email protected]

.
I'm able to access the web portal that way, but still no admin button in the bottom left.

I'm wondering if I'm not the admin user, how do I tell who is (remember i have read only DB access)?
How do I turn off IP restrictions in the database? I can see that there is a table called public.balcklist that appears to contain whitelisted IP's so I could try adding IP;s to that, but I cant see a way to turn off IP whitelisting.

Maybe of note, the webapp is still running on https://server.my3cx.ca:5001/#/people, rather than the indicated port 443, here's the output of ss -plunt:

Netid             State              Recv-Q             Send-Q                         Local Address:Port                            Peer Address:Port             Process
udp               UNCONN             0                  0                                    0.0.0.0:5060                                 0.0.0.0:*
udp               UNCONN             0                  0                                  127.0.0.1:5063                                 0.0.0.0:*
udp               UNCONN             0                  0                                  127.0.0.1:5080                                 0.0.0.0:*
udp               UNCONN             0                  0                                  127.0.0.1:5483                                 0.0.0.0:*
udp               UNCONN             0                  0                                    0.0.0.0:38525                                0.0.0.0:*
udp               UNCONN             0                  0                                       [::]:5060                                    [::]:*
udp               UNCONN             0                  0                                          *:5090                                       *:*
tcp               LISTEN             0                  128                                  0.0.0.0:22                                   0.0.0.0:*
tcp               LISTEN             0                  512                                127.0.0.1:5004                                 0.0.0.0:*
tcp               LISTEN             0                  512                                127.0.0.1:5008                                 0.0.0.0:*
tcp               LISTEN             0                  244                                127.0.0.1:5432                                 0.0.0.0:*
tcp               LISTEN             0                  20                                 127.0.0.1:25                                   0.0.0.0:*
tcp               LISTEN             0                  511                                  0.0.0.0:5000                                 0.0.0.0:*
tcp               LISTEN             0                  511                                  0.0.0.0:5001                                 0.0.0.0:*
tcp               LISTEN             0                  5                                  127.0.0.1:5485                                 0.0.0.0:*
tcp               LISTEN             0                  5                                  127.0.0.1:5484                                 0.0.0.0:*
tcp               LISTEN             0                  5                                  127.0.0.1:5482                                 0.0.0.0:*
tcp               LISTEN             0                  64                                   0.0.0.0:5060                                 0.0.0.0:*
tcp               LISTEN             0                  64                                   0.0.0.0:5061                                 0.0.0.0:*
tcp               LISTEN             0                  20                                     [::1]:25                                      [::]:*
tcp               LISTEN             0                  128                                     [::]:22                                      [::]:*
tcp               LISTEN             0                  244                                    [::1]:5432                                    [::]:*
tcp               LISTEN             0                  512                                    [::1]:5008                                    [::]:*
tcp               LISTEN             0                  511                                     [::]:5000                                    [::]:*
tcp               LISTEN             0                  511                                     [::]:5001                                    [::]:*
tcp               LISTEN             0                  200                                        *:5090                                       *:*
tcp               LISTEN             0                  64                                      [::]:5060                                    [::]:*
tcp               LISTEN             0                  64                                      [::]:5061                                    [::]:*

 

[SteveITS]

I actually think localhost isn't allowed by default, just RFC1918:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
fe80::/10

Can you use one of those IPs? Or, can you use an IP that is allowed?

However if you were able to log in and run the update then I would think any console restrictions would allow that same IP. Are you logging in as a system owner or other higher level extension?

 

[Wills]

Unfortunately it's a VPS with a single public IP address, so I can't use RFC1819 addresses.

Looking at the 'public.balcklist' table I see an entry for :
ipaddr 127.0.0.1
ipmask 255.0.0.0
description Console Restriction added from Management Console
expiresat 13884998400
blocktype 1
pv_addedby 4

I assume from context that blocktype==1 is an allow, so I tried that with the tunnel i think?

I believe I'm logging in as the (or at least _a_) system owner, but I do not know how to confirm this. In what table are permissions stored in the DB?

 

[SteveITS]

It could be an internal/hidden allow then.

Not sure about the table. If you have a backup it should be marked in the XML file though. Look for:
<Group> <Members> <Member DN="123" IsPrimary="false"> <role name="system_owners"/> </Member> ...

 

[Wills]

The XML file from the final backup before upgrade has a single IsPrimary DN, which is equal to my extension number, which is good news I guess?

So now we know we are using a system owner user, and that my IP address is in the public.blacklist table with blocktype 1 and expiresat 15732228840 What are we missing? What else needs to be set so I can get remote admin access?

 

[SteveITS]

Just to be clear it shows "<role name="system_owners"/>" for your extension? Then I'm not sure what to suggest, it should care about the role and the source IP. You're not using a VPN or IPv6 or something like that?

 

[Wills]

I got in.

Looking at the backup XML I cans see I am just a user (I'm 002). I am IsPrimary, but that's not sufficient for admin in v20.
001, who is my colleague, is not IsPrimary, but has role system_owner was the account I used. It seems that primary is not sufficient to get you admin rights in v20.



I grepped a database dump for known remote IP;s that worked (my old home IP) and found:


Running DB query:

gave me two results:


where IP_WHITELIST values were in either bare IP, or CIDR notation (i.e. CIDR but omit /32 for single IPs), e.g. ["10.10.10.10","192.168.0.0/24"]. I only had single IPv6 addresses, and they appeared as bare IP addresses with no mask.

I added my colleague's (002 extension) IP to the list, and for good measure disabled the whitelist by changing IP_WHITELIST_RESTRICTED from 1 to 0 as can be seen in the image above.

After a system restart (reboot) my colleague (002 extension) was then able to access the admin and add me to the system_owners role and I have access again.


NB: If you find this post and you are trying to work out how to edit the database, you can try asking google or your AI about setting 'local all all trust' in your pg_hba.conf and restarting postgres to provide temporarily password free access from localhost in order to create yourself a db superuser account.

As commentary, I have to say I'm not at all impressed that the upgrade script locked me out. I followed the guide as published and I imagine many users would have had to reinstall in this situation. I appreciate that this is an edge case, and that this is "free" software, but still - not a great look for the devs.