Syntax for sudoers file for mv command

Hi,

On one of Solaris 10 server, apache service is running. Due to audit requirement, its error_log grows bigger and we are required to keep that. Sometimes it grows more than 200GB and fills up file-system.
Purpose is, if error_log touches 10GB, apache service should stop, error_log should move to error_log_xxxxxx and spache service start.
Application team wants to use a script, which looks straightforward. Below is part of that script

       logger -p user.alert "ChkProxyStatus.sh :: proxy_health_warning :: Apache error log was exceeding 10G. Restarting apache on $Server."
       mv $LatestErrorFile ${LatestErrorFile}_`date +%Y%m%d`
       /usr/local/bin/sudo /usr/sbin/svcadm restart svc:/site/network/http:apache2
       sleep  10
       Status=`/usr/bin/svcs |grep http | grep -c 'online'`

error_log is owned by root, so application user (which will run that script via his cron) will not be able to mv that file. If I can give 'sudo mv' to his id with absolute path, this should serve the purpose, I think.
But I am not able to figure out, what should be syntax in /etc/sudoers for mv command mentioned in above script.
Help please.

Thanks

You can also run your script from the root users crontab and the problem is solved, and you can get rid of the sudo .

sudo is really overused, especially in situations where it is not necessary.

I have many similar scripts running that are executed by a crontab owned by root. It makes little sense to me to take these kinds of scripts and run them as a non-privileged user only to then sudo to get them to work. This just added extra complexity to the management of the system, in my view, for these kinds of log rotation scripts.

1 Like

Sure, that would be one good option.

Cheers.

Managing servers for over 40 years, I try to keep things simple. To me, simplicity is elegance.

In addition, I normally never have enough time to do all the things I need to do with IT systems, so I like things simple, self-documenting, and easy to understand so when I go back and have to revisit things months later, it's easy to understand and make changes. In coding and sys admin, I like self-documenting and descriptive, not cryptic or pedantic.

Naturally, you will need to make sure any scripts that are run from the root user cron are only writeable, executable and perhaps only readable by root. The requirement would be similar if you set it up for sudo , but it's similar to just run it from the root crontab.

sudo mostly give you logging when "people" sudo to execute a privileged command, but since you know that root needs to execute this process in cron , you really don't need sudo for this.

Don't let sudo become a "religion" for your system admin work (as some on the net would want to to "believe")

You can delegate SMF permissions for specified service to a user.
A user can be set to stop / start / restart svc:/site/network/http:apache2 specifically.

Check out the resources online so i don't paste the obvious search engine output.

Hope that helps.
Regards
Peasant

If you have a suitable Operating System, which would be very useful to know, have you considered using logrotate for this? You can write a stanza that tells the process what to do and it can be based on size or various other things.

You could schedule this against your own configuration file more frequently than the default 'once overnight' that probably already runs to manage things in /var/log

Would that be a way forward? You can probably re-use a stanza from /etc/logrotate.conf to get you started.

I hope that this helps,
Robin

Delegating SMF permissions and using logroate is also good options. I will check, what would be most suitable for their needs. Thanks for suggestions.

We also use logrotate , and this runs as a privileged user (for example root) , as it does on most Linux systems I am currently using.

In other words, we do not use sudo to run logrotate because root kick off this process when it runs (I assume, but have not really looked deeply into it), and so it had permissions to chmod, chown , etc. on the archived log files.