Tag Info

Hot answers tagged

7

Restrict the commands that can be invoked by the key If an SSH key is going to be used by any kind of automated or unattended task, you should restrict what commands it is able to execute on a remote machine, no matter what decision you make about how and where to store the key. Use something like this in ~/.ssh/authhrized_keys: ...


6

Change the following line in /etc/hosts 127.0.0.1 localhost to 127.0.0.1 localhost orion Your MTA was unable to resolve the domain name of your machine.


5

Jodka Lemon's answer is correct: cron executes its job, and sends a result mail to "root@orion" (via "mail" or similar) the MTA cannot resolve host orion, since the hostname is not listed in /etc/hosts and not resolvable via dns. so the mailer writes the dead letter information You will find the destination address of crons mail output in the crontab ...


5

I'm not sure why you would want to do that. If you're concerned about security, if someone discovers your password on 1 July, they'll know it on 31 July or 15 September... To answer your question, if you want to ensure that the password update is done either at a scheduled time or when the system restarts, you want to install anacron. It can do periodic ...


4

It's because cron forcibly sets PATH to /usr/bin:/bin. You need to invoke iptables as /sbin/iptables or add PATH=/usr/sbin:/sbin:/usr/bin:/bin in your script or crontab. See crontab(5) for details.


4

This is handled by anacron, which runs the default cron.daily etc. jobs on Fedora. If this is a root job, you can either add it to the /etc/cron.daily or to /etc/anacrontab.


4

Don't use password authentication. Use ssh keypairs. Karthik@A $: ssh-keygen #keep the passphrase empty Karthik@A $: ssh-copy-id B #enter your B password #^ this will copy your public key to Karthik@B:.ssh/authorized_keys From then on, you should be able to ssh from A to B (and by extension, scp from A to B) without a password.


2

xrandr needs the $DISPLAY variable set to tell it which X session it's manipulating, and that isn't being set in the cron environment. xrandr could be working on your default local X session, or a second one that you started by running startx from a TTY, or a session to a remote display being forwarded over SSH, or a nested X session running inside another ...


2

You need to use full paths to the output files and probably to the executables as well. When run in cron, there is no pre-existing environment for it to know things like a working directory or a path.


2

I don't think it's a bad idea to harden your system by protecting accounts as good as possible as you can. In many situations it will introduce extra hurdles during authentication, but if you're willing to cope with that it's all fine. An important thing to take into account, though, is the risk of actually introducing more flaws by increasing the complexity ...


2

Those environment variables such as ${ORACLE_HOME} are perhaps in your bash profile. This does not get read via cron automatically. Insert the line below after the #!/bin/bash. source /home/user/.bash_profile


1

0 9 1-7 * * runs the job once per day (at 9:00), but only on the first 7 days of the month. That's one way to run a job on the first Monday of the month: run it on the first 7 days, but don't do anything unless that day is a Monday. 0 9 1-7 * * if [ "$(date +%u)" = 1 ]; then do_stuff; fi 0 9 * 1 * runs the job every Monday. That's another way to run a ...


1

The shebang is working and cron has nothing to do with that. When a file is executed, if that file's content begins with #!, the kernel executes the file specified on the #! line and passes it the original file as an argument. Your problem is that you seem to believe that SHELL in a shell script reflects the shell that is executing the script. This is not ...


1

Bash Reference Manual says: SHELL - The full pathname to the shell is kept in this environment variable. If it is not set when the shell starts, Bash assigns to it the full pathname of the current user’s login shell. man 5 crontab says: Several environment variables are set up automatically by the cron(8) daemon. SHELL is set to /bin/sh, and ...


1

Could the query just be returning nothing? You could add some extra checks: sqlplus -s << $query > ${query_log} # check if the sqlplus command actually worked if [[ $? -ne 0 ]] ; then echo "error: Query failed!" >&2 # or mailx -s ... (cron will email stdout/err anyway) exit 1 fi # check the query is not empty if [[ -s ${query_log} ...


1

You can simulate the cron user environment as explained in "Running a cron job manually and immediately". This will allow you to test the job works when it would be run as the cron user.


1

You can also put your commands into a shell file and then execute the shell file with cron. jobs.sh echo hello >> ~/cron-logs/hourly/test`date "+%d"`.log cron 0 * * * * sh jobs.sh


1

Here is a solution which will both unlockpt() a new pty descriptor and write its ptsname() to stdout for you. <<\C cc -xc - -o pts #include <stdio.h> int main(int argc, char *argv[]) { if(unlockpt(0)) return 2; char *ptsname(int fd); printf("%s\n",ptsname(0)); return argc - 1; } C Which just compiles a tiny ...


1

I'm assuming by parent folder you just mean the folder with filename.txt. You can get find to print this folder name with -printf '%h\n' instead of the -exec. You can pipe this into a shell loop or xargs for example: find /path/ -name "filename.txt" -type f -mtime -2 -printf '%h\n' | xargs -i rsync ... {} /destination \; I think you need to add -R to ...


1

use nohup scriptForB.sh inside scriptForA.sh... in that way, the child process will not be terminated when the parent process exits.. On termination, parent process will send SIGTERM signal to all child process. If you use nohup, the child process will ignore the SIGTERM signals.



Only top voted, non community-wiki answers of a minimum length are eligible