BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
woo
Lapis Lazuli | Level 10 woo
Lapis Lazuli | Level 10

Hello All, if someone can please help, 

 

wanted to know what is the best way to stop/start individual sas (9.4 M3) applications, lets say SAS EG (as desktop) and SAS EM (as web) application in cluster grid environment on Linux? Thank you - 

1 ACCEPTED SOLUTION

Accepted Solutions
JuanS_OCS
Amethyst | Level 16

Hello @woo,

 

yours is a very good and interesting question.

 

For the interest of my explanations, I am going to understand that, when you say "stop" you can also mean "disable", which is in the end is the same result for you and your end-users.

 

First of all, I think it would be a good idea to get some basic knowledge on how SAS servers do work:

The point of it is that:

  • SAS Servers are basically services that listen on specific ports and managed by some config files and the metadata.
  • The desktop based applications that connect directly to a Workspace Server (such as Addon for Office or EG), and OLAP they depend directly on the Workspace Server (and, in last instance, in their own Object Spawner). And they can be more tricky, I will explain.
  • The web based applications (even if they do have a desktop app), such as SAS Studio, Miner, Web Stored Process, Portal, etc, just stopping the specific web application, or the web application server (SASServerM_N). I will explain as well.

So, ways to stop them:

 

Web based applications (SAS Studio, Miner, Forecast, Portal, Web Stored Process, VA Report viewer, VA Administrator, VA Hub, etc)

 

  1. A simple way to "stop" them is to just stop the SASServerM_N service. This will stop all the web applications living on that SASServerM_N. Beware, if you stop SASServer1_1, no web application will be able to work, because basic applications do live there (as SASLogon and the Content Server, to put it on simple words). Simple, but might affect other apps.
  2. Another way is, if you have got metadata roles well defined, you can always modify the roles within SAS Management Console. Most of the Web Applications require a metadata role to be able to access the web applications and their functionalities. More complex and elaborated.
  3. And another way, is to stop the individual web applications, with the SAS Environment Manager ( please read this great post provided by @PaulHomes  ). This operation is quite simple, and it gives you more flexibility. Beware with some apps from SASServer1_1, if you stop any web app part of the WIP (Web Infrastructure Platform), all the others won't work anymore. The same goes with SAS Visual Analytics, if you stop the Transport Service, as good example.

My preferred way, generally speaking, is the 3rd option.

 

Fully Desktop based applications (Enterprise Guide, Addon for Office)

 

  1. One option, is as @Kurt_Bremser suggested. Just stop the Object Spawner, however the counter-side of it is that no application (desktop or web based) will work afterwards.
  2. Another option, intermediate, is to split up the SASApp and Object Spawners. As, SASAppDesktop and SASAppWeb, then you can stop Object Spawners depending on what you want to stop. You can split them as much as you want to, however this will add some additional administration (permissions) since you will need to manage the access to each, and perhaps even to do some reconfigurations in your SAS platform.
  3. If your Desktop applications are virtualized (Citrix, AppV, ThinApp,..) you can always ask your IT teams to unpublish temporary the virtual apps you would like the users not to use.
  4. Or you can tell your IT admins, please deny read permissions on the key files (SEGuide.exe, or the Addon dlls) thorugh the network to the desired PCs. This normally won't be happening but, still, an option.
  5. Same as above, you can manage also the access through SAS metadata roles, in SAS Management Console. This method, however, it is not perfect, but worth to see how it behaves.
  6. Yet another option, is to block access to SAS applications servers through ACTs. You can always create an ACT, including the user groups you do not want to access it temporary, denying the Read Metadata permission, assign the ACT to the desired SAS Application server, and then the users won;t be able to see that SAS App and what is behind. Still, this affects to all client applications (web and desktop) depending on that SASApp, but instead of a full stop, you can maintain the access for certain groups (such as Administrators and Managers, really useful).

Generally speaking, I usually select options 3 (when available) and or 6. Option 1 just in a few cases, and, as responsible of installations, sometimes executing variances of option 2, but this requires approval  and agreement from the business users and other possible stakeholders.

 

Hope it helps.

 

Kind regards,

Juan

View solution in original post

6 REPLIES 6
SASKiwi
PROC Star

Your question is lacking detail. Do you mean as a SAS administrator how do you stop the SAS server workspace sessions that EG and EM users start? Or do you mean something else?

woo
Lapis Lazuli | Level 10 woo
Lapis Lazuli | Level 10

I am sorry if it has confused folks. 

I meant what is best way for sas admin to completely shutdown only few SAS applications (SAS EG as Desktop application and SAS EM as web application) while continue running other SAS applications like SAS MS Add-in or SAS Studio. is it possible or we must have to bring down everything with ./sasserver.sh script? Thank you - 

Kurt_Bremser
Super User

Since SAS Studio and the Office Add-In use the same backend(s) that EG uses, you can't do that. Once you stop the spawner (no more workspace servers) and the OLAP server, everything's dead.

 

What is the reason for your question?

JuanS_OCS
Amethyst | Level 16

Hello @woo,

 

yours is a very good and interesting question.

 

For the interest of my explanations, I am going to understand that, when you say "stop" you can also mean "disable", which is in the end is the same result for you and your end-users.

 

First of all, I think it would be a good idea to get some basic knowledge on how SAS servers do work:

The point of it is that:

  • SAS Servers are basically services that listen on specific ports and managed by some config files and the metadata.
  • The desktop based applications that connect directly to a Workspace Server (such as Addon for Office or EG), and OLAP they depend directly on the Workspace Server (and, in last instance, in their own Object Spawner). And they can be more tricky, I will explain.
  • The web based applications (even if they do have a desktop app), such as SAS Studio, Miner, Web Stored Process, Portal, etc, just stopping the specific web application, or the web application server (SASServerM_N). I will explain as well.

So, ways to stop them:

 

Web based applications (SAS Studio, Miner, Forecast, Portal, Web Stored Process, VA Report viewer, VA Administrator, VA Hub, etc)

 

  1. A simple way to "stop" them is to just stop the SASServerM_N service. This will stop all the web applications living on that SASServerM_N. Beware, if you stop SASServer1_1, no web application will be able to work, because basic applications do live there (as SASLogon and the Content Server, to put it on simple words). Simple, but might affect other apps.
  2. Another way is, if you have got metadata roles well defined, you can always modify the roles within SAS Management Console. Most of the Web Applications require a metadata role to be able to access the web applications and their functionalities. More complex and elaborated.
  3. And another way, is to stop the individual web applications, with the SAS Environment Manager ( please read this great post provided by @PaulHomes  ). This operation is quite simple, and it gives you more flexibility. Beware with some apps from SASServer1_1, if you stop any web app part of the WIP (Web Infrastructure Platform), all the others won't work anymore. The same goes with SAS Visual Analytics, if you stop the Transport Service, as good example.

My preferred way, generally speaking, is the 3rd option.

 

Fully Desktop based applications (Enterprise Guide, Addon for Office)

 

  1. One option, is as @Kurt_Bremser suggested. Just stop the Object Spawner, however the counter-side of it is that no application (desktop or web based) will work afterwards.
  2. Another option, intermediate, is to split up the SASApp and Object Spawners. As, SASAppDesktop and SASAppWeb, then you can stop Object Spawners depending on what you want to stop. You can split them as much as you want to, however this will add some additional administration (permissions) since you will need to manage the access to each, and perhaps even to do some reconfigurations in your SAS platform.
  3. If your Desktop applications are virtualized (Citrix, AppV, ThinApp,..) you can always ask your IT teams to unpublish temporary the virtual apps you would like the users not to use.
  4. Or you can tell your IT admins, please deny read permissions on the key files (SEGuide.exe, or the Addon dlls) thorugh the network to the desired PCs. This normally won't be happening but, still, an option.
  5. Same as above, you can manage also the access through SAS metadata roles, in SAS Management Console. This method, however, it is not perfect, but worth to see how it behaves.
  6. Yet another option, is to block access to SAS applications servers through ACTs. You can always create an ACT, including the user groups you do not want to access it temporary, denying the Read Metadata permission, assign the ACT to the desired SAS Application server, and then the users won;t be able to see that SAS App and what is behind. Still, this affects to all client applications (web and desktop) depending on that SASApp, but instead of a full stop, you can maintain the access for certain groups (such as Administrators and Managers, really useful).

Generally speaking, I usually select options 3 (when available) and or 6. Option 1 just in a few cases, and, as responsible of installations, sometimes executing variances of option 2, but this requires approval  and agreement from the business users and other possible stakeholders.

 

Hope it helps.

 

Kind regards,

Juan

woo
Lapis Lazuli | Level 10 woo
Lapis Lazuli | Level 10

Thank you so much Juan for your time to explain it in details, I would hardly find all these treasure in any article or book.

I think "create ACT and deny RM for SAS Applications" option would fit for me, I will definitely go through those 2 articles as well...

 

Thanks Again...

 

JuanS_OCS
Amethyst | Level 16

Very glad to know this is helping you, @woo.

 

The information is surely there. perhaps not everything in a single paper or SAS document, but it is there. I can be creative sometimes but I don't invent the rules 😉

 

Just an example, for the one you mentioned:

http://support.sas.com/kb/40/920.html

http://support.sas.com/kb/36/029.html

http://support.sas.com/kb/34/157.html

https://communities.sas.com/t5/Administration-and-Deployment/Can-I-control-access-to-workspace-serve...

http://documentation.sas.com/?docsetId=biig&docsetTarget=n08003intelplatform00install.htm&docsetVers...

https://communities.sas.com/t5/SAS-Communities-Library/SAS-Security-Model-Design-Golden-Rules-Valida...

https://communities.sas.com/t5/tkb/articleprintpage/tkb-id/library/article-id/2224

 

 

Conclusion: many places! The information is there, but you ought to know how to interpret/translate it and put it together, which indeed can be a bit hard sometimes. I can also tell you, the documentation is becoming better and better through the years.

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
  • 6 replies
  • 1772 views
  • 9 likes
  • 4 in conversation