How to change the port for SAS Logon manager webapp

[RupaJ]

Hello,

I would like to understand how to change the port for SAS logon manager webapp. Currently it is configured to run on 8081 , however there is already another process running which cannot be killed. How can we reconfigure the webapp to run on a different port. Could someone provide the steps?

Appreciate your time and response!

Thanks

[JuanS_OCS]

Hello @RupaJ,

your requirement is to change configuration of the SASServer1_1 service, hence you might need to make a full reconfiguration of your middle tier server, with SAS Deployment Manager and the Update configuration options. You will need to repeat all your post-configuration steps, such as SSL, SSO, etc, if any.

Before going to that option, I would analyze what's going on. I mean: when it was installed, I guess nothing was running on 8081. So, what is running now in this port? And why? Are you sure it is not an old SASServer1_1 process that can, actually, be safely killed?

[RupaJ]

Thanks for your response JuanS_OSC

Our security agent (McAfee) is running on the port 8081 and it cannot be killed :-(. I am not sure how the SASServer1_1 was deployed to use that port when it was not even available. Is reconfiguration the only option to modify the port? Are there are documents that I can refer to try this reconfiguration?

[JuanS_OCS]

Hello @RupaJ,

I can easily imagine that, or the McAffee was installed afterwards, or it was disabled during the initial installation (quite often).

Here is your business case: This is an agent the impact of a change is very low/local, while a change in SAS middle tier can cost you a lot of money and time.

I would like to recommend to talk to your security team and make an exception and change this agent's port to one unused in your environment.

[RupaJ]

I completely understand and agree to what you are saying. However unfortunately that security agent is running on a standardized port 8081 for years and our IT is adamant to change it :-(. This is the first time we are trying to get our web applications up and running and only when we were unable to start our logon manager , we realized the port issue.

I have one question. Why do we have to reconfigure the entire mid tier just to change the port? Shouldn't changing the port be as simple as modifying some config file and restarting the services? That's how it is for other applications. 

[Kurt_Bremser]

---

@RupaJ wrote:

I completely understand and agree to what you are saying. However unfortunately that security agent is running on a standardized port 8081 for years and our IT is adamant to change it :-(. This is the first time we are trying to get our web applications up and running and only when we were unable to start our logon manager , we realized the port issue.

I have one question. Why do we have to reconfigure the entire mid tier just to change the port? Shouldn't changing the port be as simple as modifying some config file and restarting the services? That's how it is for other applications. 

---

No. Because the access information to the webapps is kept in metadata (eg to facilitate different web app servers for different webapps), all the web infrastructure metadata needs to be kept in sync with your mid-tier server configuration. So you need to redo the mid-tier post-installation steps.

I ran into a similar problem once when I found out the hard way that jboss (used with SAS 9.2) uses 8083 internally (so it was never detected I had a port collision because jboss was not yet running when I configured it). Maybe one of the reasons why SAS moved back to the simpler tomcat.

[RupaJ]

Thanks  for clarifying Kurt! Appreciate the response. 

[Kurt_Bremser]

If you ran your SAS on a real operating system instead of an undesigned and catastrophically bad programmed toybox, you wouldn't need something like that McAfee stuff.

It's typical that virus protection software has to be disabled while an installation is in progress, because false positives can cause the installation to fail, and the constant scannning in the background will slow the installation process down to a crawl.

[boemskats]

If you ran your SAS on a real operating system instead of an undesigned and catastrophically bad programmed toybox, you wouldn't need something like that McAfee stuff.

A man after my own heart.

However aren't the internal connections in metadata in 9.4 configured to talk to the JVM via the reverse proxy? Shouldn't it just be a case of changing the JVM config and the sas.conf reverse proxy balancer definitions?

[Kurt_Bremser]

---

@boemskats wrote:

If you ran your SAS on a real operating system instead of an undesigned and catastrophically bad programmed toybox, you wouldn't need something like that McAfee stuff.

A man after my own heart.

However aren't the internal connections in metadata in 9.4 configured to talk to the JVM via the reverse proxy? Shouldn't it just be a case of changing the JVM config and the sas.conf reverse proxy balancer definitions?

---

No. Every web application has the host and port configured, see this example for Web Report Studio:

I guess this should facilitate different servers for different webapps, so the logon manager can redirect you to that.

[boemskats]

This is exactly what I meant. In your screenshot the internal connection for the apps points at the host and port where the SAS Web Server (Apache 2.2) reverse proxy is running. The Web Server reverse proxies those connections to the JVMs according to the rules defined in Levn/Web/WebServer/conf/sas.conf.

I haven't done it, but in theory you should be able to just change the port your JVM runs on and update the JVM port under the Proxy definitions at the bottom of sas.conf, without needing to change any ports in metadata.