Hi fellow deployers,
I was wondering why a sasv9_usermods.cfg it is not readily present at the Lev level. So eg in <sasconfig>/Lev1. This is SAS 9.4M1.
In this specific case I would like to have a Lev specific location for SASUSER libraries. The intention is to provide users get a different SASUSER for Dev as compared to Prod. But that would just be an example of how to use such a config file so please do not focus your response on how to handle the sasuser location. I was pondering:
1) Am I missing the obvious? Like there is such a file and I didn't spot it, or it is actually a silly question. Wouldn't be the first time 😉
2) Could there be a good reason behind why the Lev directory is skipped in the usermod chain SASHome, appserver context (eg SASApp) and appserver config (eg SASWorkSpaceServer)
3) is it good/bad/horrible practice to add such a file myself?
And of course I'd like the same for the autoexec. There is a level_env_usermods.sh though.
Looking forward to your thoughts.ion configuration level
I think this setup is because we wish to see each logical server as it's own isolated (kinda) configuration.
You could add you own master cfg file, but then you would create dependencies between the separate logical server domains.
But how many logical servers so you have in each Lev? I rarely see more then two (SASApp and SASMeta - and in SASMeta have no user SASUSER librefs).
There is a sasv9_usermods.cfg under the appserver context - SASApp. It is under SASApp that all of the SAS servers related to SASApp are configured so I can understand why there is a config at this level.
At the <sasconfig>\Lev1 level I see only one other server with a sasv9_usermods.cfg and that is SchedulingServer which I believe is just used for scheduling.
So at this point I am not seeing what advantage you would have with a <sasconfig>\Lev1 sasv9_usermods.cfg as all "normal" SAS jobs run under SASApp, including all batch, workspace, and stored process jobs.
Jan, You are indeed missing some things. At the <sasconfig>/Lev1 you not only have App-servers (Business application scope) but also the Metdata server and may be more Tech-servers as app-servers. (Technical scope). To have those segregated it is better not to mix them up.
All kind of settings at that level are mixing them up.
Well an app-server should be context for an Application-Server almost named for the association for the business application. Why being that resistive in accepting it that way? Is it the amount of work for configuration, that you can:
- solve that by scripting
- use logical links (unix) for having pointers to a central location
It is the concept of structured modular programming.
Mixing up Dev/Test/Prod in a single meta-database is a bad idea. There can be not solvable requirement issues. One common of those is that developers are not allowed to access prod another is the admins of those should not be the same persons.
Go to an IDD (IDMS) approach and the same was done for those kind of reasons included release management and for the developers some in parallel for support on working on multiple versions. (version management checkin/out).
The best one is the segregate those by segregation in levels.
Everyone thanks for the input. From the feedback I conclude that I need to further clarify my question. Some wrong assumptions/conclusions were drawn that I would like to get out of the way.
- The number and kind of servers underneath a Lev server depends on the server topology and SAS license. We have a metadata server on it's own separate machine, so that one is out of the equation. For us one Lev can contain ObjectSpawner, ConnectSpawner, ShareServer, SPD Server, Dataflux Data Management Server and a an arbitrary amount of app server contexts (SASApp, SASWeb, SASETL; SASMeta is absent here). These server each have their own set of usermod config files.
- DTAP tiers are not combined in a single metadata repository, let alone server. We "segregate those by segregation in levels". For us a Lev is the home of a single tier in the DTAP setup. We strive for separation at the machine level but that is not always the most economical or practical approach, hence multiple Lev's on a single machine. I had hoped that would be clear from my explanation. But eg Lev1 is Dev and Lev2 is Test. Or whatever. Lev1 and Lev2 would never share the same metadata server. That's how SAS designed it. So how are we mixing up DTAP tiers at the metadata level? I agree with Jaap that would be a very bad idea. Exactly why we are not doing it.
So say Lev1 is Dev and I want Dev to have its own SASWORK location, different from Test aka Lev2 (or, as in my example in the original post, SASUSER). I would like to define that in a config at the Lev level and not multiple times underneath that for every server component that is housed there. Call me lazy.
The metadata servers are duplicated by a lev- indication with a full port segregation.
that could be Dev=Lev4 .,. TST=Lev3 .,. TST=Lev2 .,. TST=Lev1 Combined on same hardware so you save on operational licenses (SAS will be angry on that).
Put some Cgroup loadbalancing on it an have the service accounts also be different and you can go for a audit with the IT enviroment for the most regulations ( health / financial). The objectspawner (and some others) still are troublesome infrastructure scope.
There are a lot of settings you could vary by means of a environment variable setting. Put those in the levenv_usermods.sh (export saswork=sometext ; export stg_data=p export stg_app=p or 4,3,2,1 as you like ) .
Than use those settings as a default one top be scripted deployed at the SASapp_business ones with the !saswork !stg_app refered to those.
There will be one standard setting at one location. The advantages:
- when needed easily to be tailored
- all changed modification are centralized . Be carefull on becoming too lazy.
- using the present available tailoring options in the config-levels
- The bad separation by SAS in the Config level mixing up Infrastructure and business may be get mitigated
A disadvantage with every approach you will do.
- You have to verify it is working that way and not harming SAS conventions in config/maintenance.
- You will be disliked by SAS TS people not doing their simple click click approach
Just to add. You at the Foundation level (the real installation part) also usermods for the config.sas and the start-scripting
These are ideal ones for setting at the OS/machine level. Eg:
- 64k-bit segment settings instead of 4k (LDRCNTRL). This is could be a bad example a being overwritten not exetender the ones mgnt
- buffers memory and other ones as of performance tuning the machine
That is just one location on the machine no matter the number of levels. (very lazy)
For the SASuser you have another issue. There are common Unix standards that are problematic to SAS institute and not often recognized by local Unix admins.
Unix (Linux) is a multi-user system that is very well capable supporting a multi-user system. When you are asking to implement that you get bashed.
That is something: Linux Directory Hierarchy: Oriented to the Software Parts
Different people prefer to place user accounts in a variety of places. This section describes only a suggested placement for user home directories; nevertheless we recommend that all FHS-compliant distributions use this as the default location for home directories.
"On small systems, each user's directory is typically one of the many subdirectories of /home such as /home/smith, /home/torvalds, /home/operator, etc. On large systems (especially when the /home directories are shared amongst many hosts using NFS) it is useful to subdivide user home directories. Subdivision may be accomplished by using subdirectories such as /home/staff, /home/guests, /home/students, etc."
With that subdivision you can set dedicated mountpoints/filesystems so no space problem because of the sharing will exist. This makes the system and service accounts (the system behavior) more reliable. Now convince Unix admins to do this.
That should be followed with a user administration so the home setting of each user is set accordingly.
By this all normal functionality of Unix is followed and will kept functional. (~ usage). Setting the current dir to each home dir correctly will solve that functionality with SAS coding. (there is a note on that that the SAS config settings is failing).
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
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.