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 more
