I have a bash script that has a function written in Perl script called in the bash script. But when I try to run the script in cron the cron is not able to fetch the script as it says it requires root user access. When I execute the script I switch to the data manager role to execute. What can I do so that cron can also execute the script?
Few suggested converting the bash script into csh script also for reference asked me to add
source /central/confg/global.cshrc
this is in the script but I am not good at shell scripting so I am having trouble converting bash script into csh script.
If anyone has any ideas what can be done here please share.
add the below line into file: /etc/sudoers
$(USERNAME) ALL=(ALL:ALL) NOPASSWD: $(PATH TO SCRIPT)
The default user is root if no user is specified as a parameter when creating a cronjob. Give the script the executable permissions to run successfully and to set any environment variables the root user needs to run the script.
Note: The root user should not be used for security reasons unless necessary.
Related
I have a shell script on /usr/bin/myapp and another 12 set of scripts on a diff folder (say /opt/myapp). I want a solution that only scripts from /opt/myapp can use or execute script in /usr/bin/myapp. This is to secure the script on /usr/bin/myapp and noone else except /opt/myapp should use it.
Any other solution is also accepted. Thanks in advance
The standard way is to grant "execute" permissions on the folder (or "read" and "execute" permissions on the scripts) only for a special group.
(Note that restricting "execute" permissions for the script alone is not enough, since read permissions are enough to execute a script with e.g. sh /path/to/script.)
Then you can grant the group permissions to the other scripts for instance via sudo (using some shell wrappers) or by writing your own binary wrappers.
I need to run a Make script that invokes a shell script.
I can run the shell script directly as root but when running make on the makefile (still as root) make is denied permission to run the same shell script?
The offending line in the Makefile is that one:
PLATFORM=$(shell $(ROOT)/systype.sh)
I could go in and hardcode the value of every PLATFORM variable of every Makefile scrip on the system but that would be pointless fix, I'd like to understand why there is that Permission Denied error:
make[1]: execvp: ../systype.sh: Permission denied
PS: The content of the shell script is not the issue even if the shell script only contain ls or echo linux the Permission is Denied to the Make utility to run the shell script.
PS: I am not a make expert by an mean so if the explanation is related to Make please be as specific as you can.
In your comments above you say when you "run it manually" you use . scriptname.sh, is that correct? You use . followed by scriptname.sh?
That does not run the script, that sources the script. Your statement that scriptname.sh will execute with and without the x permission since it is a shell script is wrong. You can source the script if you have read permissions. But you cannot execute the script unless you have execute permissions.
"Sourcing" means that a new shell is not started: instead your current shell (where you type that command) reads the contents of the script and runs them just as if you'd typed them in by hand, in the current shell. At the end all the side-effects (directory changes, variable assignments, etc.) that were performed in that script are still available in your current script.
"Executing" means that the script is treated like a program, but the program is a new shell that's started, which then reads the contents of the script and executes it. Once the script ends the shell exits and all side-effects are lost.
The $(shell ...) function in make will not source your script (unless you also use . there, which you did not). It will try to run your script. The error you show implies that either systype.sh did not have the execution bit set, or else that it had an invalid #! line. There's no other explanation I can think of.
If sourcing the file really does what you want then why not just use the same method in $(shell ...) that you use in your own personal use:
PLATFORM=$(shell . $(ROOT)/systype.sh)
If changing the user permission didn't work, are you sure that whatever user owns the script is the same user you're using to invoke make? You say you're "running as root"; is the script owned by root? Or is it owned by you and you're running sudo make or similar?
I don't know why you don't just use:
chmod +x systype.sh
and call it a day.
Adding execution permission to the file Group rather that the file User fixed the issue.
PS: I wonder why? It seems the Make utility run shell scripts not with the same user that started Make...
I am running a shell script by which we are scheduling a task using at command. But it schedules the at task but its not running the same beacuse its using shell /sbin/nologin when we are calling it from php code. It works fine if we run it from terminal.
You should check the "$PATH" env variable. When you are logged in from terminal the shell has initialized it's search path via .bashrc etc. "cron" or "at" jobs don't do that.
So try to log the environment variables to a file in your 'at' jobs and check if it is set up right.
I have a perl script and I scheduled it to run daily through crontab. The script is working fine if executed. But while executing through crontab, it's posting error mail to my mailbox.
Is there any thing that I should modify to successfully execute the script through crontab?
It could be a $PATH problem. Ensure that your Perl script either is on a place mentioned by $PATH, or has an absolute path in the crontab. This is also valid for any script or program that you run in the Perl script. The $PATH variable usually has to be set inside the crontab file.
It could be a file used in the Perl script having relative path, which could work when executed manually, but fail when run by cron (different working directories).
Does the Perl script have execute permissions (the x mode bit set)? This is not necessary when it's run with perl /path/to/script.pl, but would fail when it's run with /path/to/script.pl.
EDITED:
Suggestions for how to fix:
Add to $PATH in the crontab (for the sample script /path/to/script.pl):
PATH=/bin:/usr/bin:/path/to
Remember to include other needed paths as well (e.g. /bin and /usr/ucb).
Chances are there already is a PATH definition in the file. In that case, just append your path to it.
Alternatively, you can specify full path in the cron job line, e.g.:
17 * * * * root /path/to/script.pl
To fix permissions:
chmod a+r+x /path/to/script.pl
I'm trying to interactively test code before I put it into a script and was wondering if there are any things that behave differently in a script?
When you execute a script it has its own environment variables which are inherited from the parent process (the shell from which you executed the command). Only exported variables will be visible to the child script.
More information:
http://en.wikipedia.org/wiki/Environment_variable
http://www.kingcomputerservices.com/unix_101/understanding_unix_shells_and_environment_variables.htm
By the way, if you want your script to run in the same environment as the shell it is executed in, you can do it with the point command:
. script.sh
This will avoid creating a new process for you shell script.
A script runs in exactly the same way as if you typed the content in at a shell prompt. Even loops and if statements can be typed in at the shell prompt. The shell will keep asking for more until it has a complete statement to execute.
As David rightly pointed out, watch out for environment variables.
Depending on how you intend to launch your script, variables set in .profile and .bashrc may not be available. This is subject to whether the script is launched in interactive mode and whether it was a login shell. See Quick Startup File Reference.
A common problem I see is scripts that work when run from the shell but fail when run from another application (cron, nagios, buildbot, etc.) because $PATH was not set.
To test if a command/script would work in a clean session, you can login using:
ssh -t localhost "/bin/bash --noprofile --norc"
This ensures that we don't inherit any exported variables from the parent shell, and nothing from .profile or .rc.
If it works in a clean session and none of you're commands expect to be in interactive mode, then you're good to go!