topic Re: Cleanwork Deployment on UNIX SAS in Administration and Deployment

Cleanwork Deployment on UNIX SAS

rsc24_in — Wed, 04 May 2016 23:03:37 GMT

Hi All,

I am looking for the best/effective way to deploy Cleanwork in a UNIX SAS environment.

Here are some of the things that i am looking for:

1. Log deletion activity

2. Dont let the log grow indefinitely

3. Email support teams with status of Cleanwork

I am working to create a small wrapper around cleanwork to have it email the daily cleanup status,

Re: Cleanwork Deployment on UNIX SAS

Reeza — Wed, 04 May 2016 23:32:42 GMT

So what's your question? Sorry, it's not clear what exactly you need help with.

Re: Cleanwork Deployment on UNIX SAS

rsc24_in — Thu, 05 May 2016 00:24:02 GMT

I am looking for some best practices while deploying cleanwork. Like say log management or other considerations when deploying cleanwork.

Re: Cleanwork Deployment on UNIX SAS

SASKiwi — Thu, 05 May 2016 00:57:27 GMT

The CLEANWORK utility is not about log management. It is used to remove leftover SAS WORK directories:

http://support.sas.com/documentation/cdl/en/hostunx/67929/HTML/default/viewer.htm#n13ozwpq7az8v6n1s77r8c2zp9d1.htm

Best practice is to run this as a daily scheduled task at a time when there unlikely to be any SAS jobs running - say midnight for example. If it fails for some reason then some WORK space may taken by the old WORK directories. This is not usually a big deal for a day or two, but if left could cause you to run out of WORK space. Hence the daily scheduled task should be monitored to ensure it runs successfully on most days.

Re: Cleanwork Deployment on UNIX SAS

bheinsius — Wed, 29 Jun 2016 11:38:53 GMT

Do you have suggestions as to what user i should run the cleanwork script with?

Running it as root is not allowed by our IT department since the cleanwork script is owned by the sas installation user.

Running it as the sas installation user (sasinst) does not work since that account does not have sufficient permissions on the work directories to delete them.

Setting workperms to 2775 and saswork directory group to sasinst does not work because if the user is not a member of the sasinst group, the files and subdirectories beneath the created SAS_worknnnn directory are created with 775 (instead of 2775) and that prevents sasinst group members from deleting the files in it.

Running it under the users' account is possible but then i need a crontab entry for every single user, which is quite cumbersome.

Please let me know your thoughts.

Bart

Re: Cleanwork Deployment on UNIX SAS

JuanS_OCS — Wed, 29 Jun 2016 11:49:52 GMT

Hi Bart,

what about to give sasinst user some sudo permissions for W on the SASWork folder? Or any other system account other than root.

That should do the trick.

Best regards,

Juan

Re: Cleanwork Deployment on UNIX SAS

bheinsius — Wed, 29 Jun 2016 11:54:55 GMT

Hi Juan,

Can you explain what you mean by: "give sasinst user some sudo permissions for W on the SASWork folder" ?

regards,

Bart

Re: Cleanwork Deployment on UNIX SAS

JuanS_OCS — Wed, 29 Jun 2016 11:58:07 GMT

I mean that the system administrators can give part permissions to execute some commands and access some locations as a root.

This functionality is named " sudo" : https://en.wikipedia.org/wiki/Sudo

The trick is to specify carefully what you need as a root, then the security team will evaluate and accept your request, or reject it.

Re: Cleanwork Deployment on UNIX SAS

bheinsius — Wed, 29 Jun 2016 14:20:54 GMT

yes but then the script runs as root which is what IT does not want. unless the script cannot be modified by sasinst by changing owner to root.

so that is an option.

any other ideas?

Re: Cleanwork Deployment on UNIX SAS

JuanS_OCS — Wed, 29 Jun 2016 14:27:33 GMT

Hi Bart,

I understand your reasoning process, but I think you are wrong. Sudo can be configured on many ways... and it should not be configured on a way that sasinst will "run as" root. The script will run as sasinst. But sasinst will have a subset of root privileges.

The link to the wikipedia I sent you earlier explains it very well and shortly:

Design[edit]

Unlike the command su, users supply their personal password to sudo if necessary. After authentication, and if the configuration file permits the user access, the system invokes the requested command. By default the user's password can be retained through a grace period (15 minutes per pseudo terminal), allowing the user to execute several successive commands as the requested user without having to provide a password again.

sudo may be configured to log each command run. When a user attempts to invoke sudo without being listed in the configuration file, an exception indication is presented to the user indicating that the attempt has been recorded. The root user will be alerted via mail and an entry is recorded in the system log.^[12]

Configuration[edit]

The file /etc/sudoers may contain a list of users to execute a subset of commands while having the privileges of the root user or other specified user. The program may be configured to require a password or none at all.^[13]

Impact[edit]

In some system distributions, sudo has largely supplanted the default use of a distinct superuser login for administrative tasks, most notably in some Linux distributions as well as Apple's Mac OS X.^[14]^[15]

Re: Cleanwork Deployment on UNIX SAS

rsc24_in — Wed, 29 Jun 2016 15:26:08 GMT

Brat,

I believe we had the exact same situation at our site.

The solution was:

1. Create a new directory owned and managed by root. (the entire path must be root owned/managed)

2. Copy the cleanwork utility from SAS Utilities location to this new directory and change permissions to have root own this file.

3. Create a wrapper for cleanwork (if needed) and enable logging, as required. Change permissions to have root own this file.

4. Schedule the script as root to run weekly/daily.

This setup isolates cleanwork from the installer account and only root will have access to modify/update the script or the cron entry.

Now, if the IT department is not familiar with cleanwork, they would question what the utility does and if it can adversely impact the system. You might have some convincing to do here.

Here is a sample of the wrapper that we created.

#!/bin/bash

dt=$(date +%Y%m%d-%H_%M_%S)

/opt/local/sas-admin/cleanwork /opt/local/saswork >> /opt/local/sas/shared/cleanwrk/cleanwrk.log 2>&1

echo "$dt">>/opt/local/sas/shared/cleanwrk/cleanwrk.log

/bin/mailx -r "PROD-Compute<admindl@yourorg.com>" -s "SAS - PROD - Cleanwork Utility Daily Status - `hostname`" admindl@yourorg.com <<EOF
 This is an automated email from SAS Servers.

 Cleanwork Utility has been executed on `hostname`, `date`.

 Cleanwork log is available at /opt/local/sas/shared/cleanwrk/cleanwrk.log.

 Please contact your SAS Admin if there are any questions.
EOF

Re: Cleanwork Deployment on UNIX SAS

bheinsius — Wed, 29 Jun 2016 20:39:03 GMT

that sounds like a good option too.

i currently have sasinst running sudo cleanwork where root is owner of the cleanwork program, which is effectively the same i think.

i didn't think of creating a separate root-owned copy of cleanwork, i like it i will do that.

Re: Cleanwork Deployment on UNIX SAS

mikev — Thu, 30 Jun 2016 20:13:08 GMT

Although the script is a good workaround (maybe add a md5 checksum check to satisfy your administrator), I would suggest that option if I needed to run cleanwork for 50 or more users but..

If you configure the SAS WorkSpace servers to use SAS token authentication you only need to run the cleanwork for the users you configure (on the Options tab of the server definition). This leaves you with a limited set of users (like sassrv and sasinst) you have to setup cleanwork for.

For these users you can setup a crontab entry and if you also set a MAILTO= variable in your crontab the output will be send automatically. SASWork files owned by another user cannot be accessed by the current user, see the evidence below:

[sassrv@localhost ~]$ /opt/SASHome/SASFoundation/9.4/utilities/bin/cleanwork -n /tmp
Running as user sassrv on hostname localhost.localdomain
/tmp/SAS_util00010000099A_localhost.localdomain [2458]
cleanwork: /tmp/SAS_util00010000099F_localhost.localdomain is IN USE: [2463]
cleanwork: /tmp/SAS_util00010000099F_localhost.localdomain - User sassrv not owner of pid [2463]

This could be crontab entry:

####

MAILTO=me@mydomain.com

# run cleanwork every hour

5 * * * * /opt/SASHome/SASFoundation/9.4/utilities/bin/cleanwork /tmp 2>&1

hope this helps.

grtz

-- Mike

Re: Cleanwork Deployment on UNIX SAS

boemskats — Mon, 17 Apr 2017 14:42:27 GMT

Old discussion, but just to add that arguably the 'proper' UNIX way of doing this would be using the setuid bit (already used by SAS for sasauth, sasperm and elssrv). That means that if you:

sudo chown root cleanwork
sudo chmod u+s cleanwork

then any subsequent execution of cleanwork will run with root privileges, regardless of the user that executed it. You can then limit who can actually trigger cleanwork using standard UNIX execute permissions.

Running shell scripts as root generally isn't a great idea, which is why the setuid bit functionality is limited to binary executables.

Nik