GZIP all SAS datasets in a library.

[Kurt_Bremser]

If you have login access to the command line, there is no, _no_, NO!!!!! reason to prohibit xcmd. Stick that to your "administrators". x starts a shell that differs from a "normal" login shell only in its environment (working directory, some environment variables), but not in its privileges. Any havoc you can wreak on the system with the x command is even easier done from the CLI.

Instead of bringing forth strawman arguments, they should harden their system by proper granting of rights, having quotas, workload management and so on.

"My" users are reigned in by quota management in locations where they have write access (or I set up dedicated file systems that don't bother me if full), restricting the number of concurrent SAS sessions (so they don't cause excessive paging by running >30 SAS sessions at once, one of the idiots actually did that one time), and proper management of access rights to resources. I actually encourage them to use ssh and the x command to make their days easier, and I never had problems from that.

If your admins think that only some users should have xcmd (and CLI access) enabled, then they only need to define an additional workspace server that only the privileged users have access to.

[jakarman]

Kumarz, Kurt is a little bit rude but he is right. Kurt and I could do an Alliance :smileydevil:.  If I read his approach he is really engaged and helping his customers analists.

You have access to CLI (ssh) allowing all commands and not able to do the same with SAS. Silly/Crazy reasoning. Could by a Dilbert episode using humor as approach.

Why this blocking issue? There are a lot of policies at the OS level. I found an example at an professional organization.  http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf  Interesting is 2.3.1.4 as is telling users should not use the shell. That will work for routers or a DBMS with his own OS approach, but not when you want to use it for analytics in a way like Excel desktop approach. You need to convince and document analytics is different than a router approach. This should not be that difficult. The argument that this not common with SAS is a false one.  Why SAS did this default setting? I want to keep polite, ....

It looks for me as SAS failed to understand the higher level requirements as set by reglautors (hipaa iso27k ITSM Cobit) and instead did some technical things as result of vague insinuations/questions.

What is to find about the xcmd? see: The case for XCMD privileges in SAS Enterprise Guide - The SAS Dummy Normal SAS usage in PC environments is quite common to use xcmds, their own desktop/data why should you bother them. At 9.1.3 Eguide was limited in the same way with xcmd and getting bad acceptance for that. That one is set open by default again at 9.3.

SAS is very open to integrate tools. With most of them you will find the XCMD access level is needed. As examples:

-  using R with SAS/IML,

- Eminer user instructions,

- get through requirements of solutions you will also find many times the XCMD-requirement.

  SAS-VA is marketed as web-based but the data-admins are needing xcmd (6.4).    
For those third party components SAS is integrating they are promising to allow xcmd usage not needing that setting. That is bypassing their own check.

Why would you do all that trouble? Having a well designed OS layer security not allowing you to harm anybody else on the machine (sandboxed -  non-shared parts - workload isolation cgroup) and when something is going wrong you can correct that yourself or somebody like Kurt will get to you.

This is asking a more professional approach at the OS level with this vision. Can be challenging.   

[Kumarz]

Kurt and Jaap,

I really appreciate both of yours' detailed response in this case. Kurt sounds little rude; but honestly he is 100% right. It didn't make sense to me as well when I asked the same question and they gave me all those security reasons.

As of now, I'm doing little more research before petitioning my administrator to grant as allow XCMD and remove other restrictions.

Since, I'm slowly moving towards Admin role; Can I ask you guys some specific questions via emails? I'm not sure if conversations like this (or future) should be part of this thread or not. Please let me know.

And like Jaap mentioned about creating an alliance with Kurt to help users like me; it would be great that we get direct guidance from industry experts like you...!!!.

Thank you very much.

Kumar.

[Kurt_Bremser]

Kumar,

if you are already moving towards an "admin" role:

- read, read, read. Since there are literally tons (in terms of paper, if printed) of SAS documentation out there, that is an absolute prerogative. I have found that posting the contents of an error message or a log in google with "SAS" prepended often returns a usable link to information immediately.

- get a solid grip on the operating system which is used for the SAS server. With CLI access, you may find you can solve lots of problems quickly using generic OS tools. Server OS's are VERY powerful, and the "read, read, read" is also valid there. Knowledge of the server OS puts you on an equal footing with those who run/administrate it. Large operations tend to produce people who avoid work by feeding bullshit to those that they consider to have no clue. Proving them wrong can be exhilarating and rewarding . I often find myself (in the admin role) close to falling into this trap, so I force myself to rethink WHY I have placed certain restrictions on users.

- real security for data has to be done at the OS level. Only there can you be sure that nothing untowards happens (think of your case: restricting access via metadata is useless if you can still use the CL to copy a file to your sasuser directory).

- if then you have problems that seem impossible to solve, or if you suspect that there may be more efficient solutions, don't hesitate to open threads here or in other places (stackexchange.com, stackoverflow.com etc). That way you tap into the cumulative wisdom of the whole _planet_.

[jakarman]

This is one for everyone, excellent to be quoted:

"I often find myself (in the admin role) close to falling into this trap, so I force myself to rethink WHY I have placed certain restrictions on users."

[Kumarz]

Yes.

I would agree to both of you on all the comments and suggestions. Especially Read, read, read and Mastering the OS part. I have been reading these (and other) blogs/threads and SAS documentations as much as I can and MOSTLY whenever I face a problem (like everyone else.......).

Of course its never ending process. But my confusion is how much is enough? Because in today's fast paced world nothing is enough and everything you learn/deliver is late when you are a new to an Admin role (or any other role).

So is there any suggestion (or any discussion on other forums/threads) that you guys can share with us? I mean, " How to become an efficient SAS Administrator : For a newbie or for a SAS programmer or for anyone?" If nothing is out there; then lets build/start something from this question.

It would be a great help for an aspiring SAS Administrator like me and others.

Any help is appreciated.

Kumar.

[ChrisHemedinger]

For some great contributions about SAS Administration, see this blog series:

SAS Administrators - SAS Users

These blogs are written by SAS users as well as folks from SAS.  They offer practical advice around the admin practices in today's SAS environments.

Chris

[Kurt_Bremser]

How much is enough?

In a completely different context (officiating American Football) I once came across this quote:

"When you're through learning, you're through".

It never stops, and you will always find things that you don't know (yet), but need to know.

Take every problem as a "solution in blue denim", and work until it's solved and wears a tux to the prom (performs in front of the audience of your users). Put your brain to it, and try to rely on other's help as the absolutely last measure. The information is there, from shell scripting manuals to pdf's from the SUG events. I often spend time at work playing around with things that are not "necessary" at the moment, but when the time arises, I find how the knowledge gained helps me. That's why you find me here or in other forums.

Every time you do something, ask yourself "could I let the computer/system do that instead of doing it myself?" Then try to automate it. Learning by doing.

[jakarman]

Kumar,

I did recognize your issues as Kurt did, it is frustrating. Reading his answers/discussions you can recognize he understands SAS and the OS environment as a combination.

That is a needed combination that when lacking is giving that many problems. And make a guess how often this is wrong indeed.   

For the arguments and going deeper into details about a real secured environment, I have given some links already.

"It looks for me as SAS failed to understand the higher level requirements as set by regulators (hipaa iso27k ITSM Cobit) and instead did some technical things as result of vague insinuations/questions."

We can do it openly. A lot of more people are having this kind of problems. It could be very interesting for SAS people also. 

You are not the only one. I went to the OS details with SNLFAM1 in this one: Allowing Approved Permissions to Restricted Data

Building up the environment according the required security policies and that is not just following:  a contradictionary way or  humbug checklist statements as used by nitwits. 

If it are details about persons or a company you are not wanting to have in a discussion thread you can mail me.

I should be easily to find ...(just google).  

[jakarman]

Nice to see you Chris,  Indeed those blogs are nice and there are so many of them. I like this ones:

- SAS admins: providing maximum benefit to users - SAS Users Groups  (2012 Leroy Bessler)

- SAS administrator roles and responsibilities: a recap - SAS Users (2014 C. Harvey)

- Managing multiple users of a SAS Installer account - SAS Users (2014 R. Collum) The recognition of high priviledged accounts. It is a start for SIEM (Security Information & Event Management).

And of course: Best Practices in SAS Administration (SAS talks) The importance of a good cooperation between IT-staff the SAS-admins and SAS users.

The real work is learning by doing. (as Kurt said).

As Kumarz does possible problem with that cooperation with IT-staff. Send away by them with "not normal SAS functionality" there is gap to solve.
It could be done within a dedicated project for that, using "Harvey Balls" getting into more "common customer requirements" approach with a "artisan" deployment.
It would make more sense to do that with a more generic view as it is also being mentioned as weakness/threats of SAS in the Forrester Gartner reports. 

http://blogs.sas.com/content/sgf/2014/01/29/managing-multiple-users-of-a-sas-installer-account/

[LindaAdams]

This is how I do it, and I've never had a problem due to the number of datasets:

X cd /sas/adhoc/myfiles; 

X gzip *.sas7bdat;

[Kumarz]

Thanks All,

Especially for providing very helpful links. I am going through each of them; one by one; and can say that this is what exactly I was looking for.

Kumar.