Messages

1

General Board / Re: Floating licenses on Pro Cloud

« on: December 22, 2022, 06:19:56 pm »

I have PCS v5.1 running. I also was unable to connect the license client to the license server (both running on the same VM). By disabling IPv6 and whitelisting the server in the admin client whitelist of PCM, it seems to work. I now use both floating license client and server on the same virtual machine.

2

PCS General Board / Re: EA client on internet cannot obtain license from floating licence server (Azure)

« on: December 15, 2022, 07:47:07 am »

Hello Modesto, thanks for your reply. My SSL certificate currently does not include both the internal and external FQN. Good tip! I will give it a try. It will probably take a few days before I have feedback as I rely on other persons to make some of the required changes.

3

PCS General Board / EA client on internet cannot obtain license from floating licence server (Azure)

« on: December 14, 2022, 01:28:48 am »

Hello,

I have a pro cloud server (PCS) v5.1 running in Azure. I have WebEA running on the PCS as well as floating license server (FLS). My EA client can obtain a shared license from FLS when my PC has a VPN connection into Azure. With the VPN connection, I can ping the fully qualified name (FQN) of the server; this FQN is used to tell the EA client where the FLS is. I have a server.pem certificate with the FQN on the server. The domain name of the server (and thus its FQN) is our AD domain and this is not available on the internet. So far so good, everything works as it should.
Not all the EA users in my organisation are entitled to a VPN connection into Azure. They need to connect to the FLS through https over the internet. They have to enter an URL as the FLS adres in the EA licence management\shared keystore selection window. This URL (https://....:443) is based on our public domain name (which is different from our AD domain name). Public DNS directs this URL to our Azure Application Gateway, which should redirect to the internal FLS adres based on the server FQN; internally the port used is 1805 (as 443 is already in use by WebEA which runs on the same PCS. I cannot get this to work from the internet, meaning the EA client does not manage to get a license from PCS (most likely because I made a configuration error).

Has anyone managed to get this setup working? I couldn't find any documentation from Sparx on this topic.

Thanks, Christof

4

General Board / Re: How to prevent regular users from adding new root nodes to a shared repository?

« on: August 22, 2022, 11:08:21 pm »

OK, thanks for the feedback. I hoped for a different answer but it is what it is.

5

General Board / How to prevent regular users from adding new root nodes to a shared repository?

« on: August 16, 2022, 05:38:56 pm »

I use a shared repository (MS SQL) and have enabled security. I use group locks on the root node, views and packages to restrict edit access to specific users. This all works fine. I have one remaining issue with users still being able to add new root nodes to the shared repository which I don't want. Only the built-in admin account is member of the security group with specific rights on the root node. All other users can only access is which seem to work as the options under package control are all grayed out for regular users. How can I disable the option 'add root node' in the context menu for regular users?