BookmarkSubscribeRSS Feed
RupaJ
Lapis Lazuli | Level 10

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

10 REPLIES 10
JuanS_OCS
Amethyst | Level 16

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
Lapis Lazuli | Level 10

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
Amethyst | Level 16

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
Lapis Lazuli | Level 10

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
Super User

@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
Lapis Lazuli | Level 10

Thanks  for clarifying Kurt! Appreciate the response. 

Kurt_Bremser
Super User

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
Lapis Lazuli | Level 10

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
Super User

@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:wrs_port.jpg

 

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

 

boemskats
Lapis Lazuli | Level 10

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.

 

 

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 10 replies
  • 2094 views
  • 5 likes
  • 4 in conversation