BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
rsc24_in
Fluorite | Level 6

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,

1 ACCEPTED SOLUTION

Accepted Solutions
rsc24_in
Fluorite | Level 6

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

 

View solution in original post

13 REPLIES 13
Reeza
Super User

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

rsc24_in
Fluorite | Level 6
I am looking for some best practices while deploying cleanwork. Like say log management or other considerations when deploying cleanwork.
SASKiwi
PROC Star

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#n13ozwpq7az8v6n1s7...

 

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. 

bheinsius
Lapis Lazuli | Level 10

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

JuanS_OCS
Amethyst | Level 16

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

 

 

bheinsius
Lapis Lazuli | Level 10

Hi Juan,

 

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

 

regards,

Bart

JuanS_OCS
Amethyst | Level 16

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.

bheinsius
Lapis Lazuli | Level 10

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?

JuanS_OCS
Amethyst | Level 16

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:

 

Spoiler

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]  

 

rsc24_in
Fluorite | Level 6

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

 

bheinsius
Lapis Lazuli | Level 10

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.

mikev
Calcite | Level 5

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

boemskats
Lapis Lazuli | Level 10

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

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 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 13 replies
  • 8524 views
  • 11 likes
  • 7 in conversation