Hi,
I plan to use a cron script to back up a number of relatively small but very important files over the web to a server.
Are there any recommendations (in terms of security for my own machine) which user should run such a script? I imagine root is not the ideal user to run such a script.
The script will use the WebDAV client cadaver.
Any advice appreciated.
Peter
Your schema is not very clear to me. What do you use as a backup softeware (rsync, others), etc. But in general what you do not need to run as root, do not as root. And when you hesitate to let this do by one of the “normal” users (that is those that use the system regularly using the GUI, for browsing, mailing, banking, whatever an end users do). just create an extra user for it. That user does not even need to use the GUI (but there would not be much against it).
It is like having mysql for administering MySQL, etc. I have several of them. One is owner of the wepages I generate with information about all the systems I manage. This is very different from the normal work my own username does or the username my wife uses. I never use it for loging in in a GUI. Whenever I need to use it I start Konsole and do a
su - <username>
enter it’s password and then have the CLI where I can e.g. do
crontab -e
manage scripts, etc.
Unix/Linux has the concept of multi users (that can login all at the same time), use it to separate the different roles you have (even if they end up in the same physical person, you).
From your signature I read that you never performed any updates on 11.2, is that correct? If security is a concern to you, one of the first things I’d suggest is to keep your machine up to date, i.e. update from the update repos.
For the rest, not much to add to what hcvv wrote
IMO, it depends on what you need to backup/restore, the permissions, owner and groupid. If it is only user files then the user owner is good enough.
Often user is good enough for most files but some files and folders can only be read by userid owner or the root id, as hHcvv suggests files owned by mysql. Group members of a group may or may not be able to restore files.
That also could mean switching userids during the backup/restore process, and what userid/owner and groupid are stored on the WebDav server.
I guess I’m saying only you will know which userid/owners you will need for the backup.
Ok, i’ve decided to let it run by the user whose files it is backing up. The sript works fine from the konsole, but not as cron job.
Now I’m not quite sure where the crontab file should live, what format it should have and what the correct permissions are.
The user that should run the cron job is “maja”.
so I have the following file in /var/spool/cron/tabs :
obsidian:/var/spool/cron/tabs # ls -lh maja ; cat maja
-rw-r--r-- 1 maja users 69 15. Jul 09:05 maja
# cron jobs for user maja
*/2 * * * * /home/maja/bin/kmailadrbkup.sh
At the moment I have it set to run every two minutes, this is for test purpose only, but it doesn’t work.
The user maja should be allowed to run cron jobs:
# cat /etc/cron.deny
guest
gast
My questions are:
It works, and I can answer the questions myself (for the record):
My questions are:
- is the file in the right place? or should it be in /var/spool/cron??
- are the permissions/owner right?
- should I add the user “maja” as 6th column in the file??
What was missing was a path definition so the it would find the “cadaver” command which is in /usr/local/bin :
obsidian:/var/spool/cron/tabs # cat maja
# cron jobs for user maja
PATH=/usr/bin:/bin:/usr/local/bin
* */1 * * * /home/maja/bin/kmailadrbkup.sh >& /dev/null
the job should now run every hour.
thanks for the advice, I’m glad it’s working now.
Peter
First, you should use the crontab edit command which takes care of placement and the crontab file permissions.
man crontab
# list crontab for user
crontab -l
# edit crontab for user
crontab -e
# edit another users crontab
crontab -u user -e
# edit superuser crontab
sudo crontab -e
su -c "crontab -e
I’m not always successful without the shell command so I use sh:
cat maja
-rw-r--r-- 1 maja users 69 15. Jul 09:05 maja
# cron jobs for user maja
*/2 * * * * **sh** /home/maja/bin/kmailadrbkup.sh
Also, I’ve had trouble running a test every minutes though I think it should work:
cat maja
-rw-r--r-- 1 maja users 69 15. Jul 09:05 maja
# cron jobs for user maja
*/**5** * * * * sh /home/maja/bin/kmailadrbkup.sh
The first part of tararpharazon’s post is correct. Yoy should never edit any crontab file directly (and thus one does not need to know where they are). Manage the crontab file with the crontab tool.
As you can read in
man crontab
running there does not use the same environment as it is setup for a shell login. Thus it is better to use absolute pathes to your file/directories in your script (you can e.g. be sure that your working directory is different when running fron cron commpared when you run from wherever you happen to be testing the script).
Using the sh command to run a script is a bit strange. Especialy as most people here use bash scripts. Thus first sh is loaded, then sh reads the script to find out that it is a bash script, thus sh calls bash and bash reads and executes the script.
Assuming that we talk about a bash script, the first line of that script should be
#!/bin/bash
Then the script is of course stored as a file with a name e.g. in the bin directory inside your home directory (which is specialy created for that reason and for the same reaon is in your default PATH, but you can take any direcitory you have access to or can create). There is no need at al to give it a name that ends in the three characters .sh. That is only for those who often forget what is what and thus ask themeselves everfy other time: what the hell is that silly file. >:(
I would e.g. have stored that file as * /home/henk/bin/backup*.
Then, as this is to be something to be executed, the apropriate x-access bit(s) must be set:
chmod u+x /home/henk/bin/backup
The result is that user henk, when loged in in a terminal (emulator), can execute this script by calling
backup
because /hom/henk/bin is in his PATH variable.
In a crontab he complete path must be used:
/home/henk/bin/backup
Hi,
I wouldn’t have thought it matters whether bash or sh is specified as, in
openSUSE, /bin/sh is merely a link to bash anyway.
Maybe I’m wrong here, if anyone can confirm either way I’d be grateful.
However, I would agree with using the shebang line, and adding x
permissions, rather than having to specify what language the code is in,
simply to save having to check whether each file was written in bash,
Perl, c, etc.
Regards,
Barry.
When two programss are physicaly the same (using te same place on disk), but having different name to be called with (using links) that does not imply that you get the same results. When a program is called, the kernel makes the arguments of the call available to the program. Argument #0 is the name it is called with. Thus iinside he program you can see if you have to behave like sh or like bash. And look at these:
henk@boven:~> l /bin/ex
lrwxrwxrwx 1 root root 3 jan 2 2010 /bin/ex -> vim*
henk@boven:~> l /bin/vi
lrwxrwxrwx 1 root root 3 jan 2 2010 /bin/vi -> vim*
henk@boven:~>
Different editors, but the same file on disk.
Back to bash and sh.
bash is the name the Borne Again Shell is called with.
sh is the name the POSIX shell is called with.
(and there are more shells: ksh, zsh, csh, …).
While these do have a lot in common, there are differences and it is a nice task to compare both man pages ;).
Also in a next level of openSUSE, or in a different distro, or on another Unix system, bash and sh might be different files. Let not the fact that you know that at this moment in time on the system you use they are links, lure you into thinking this is a law for ever and ever.
I know of at least one thread here where someone thought that putting the shebang* #!/bin/sh* in the first line of his bash script would do no harm. It did, because he had one of those (very deep hidden) differences used in his script.
It is simple. You make a script according to the documentation of that shell and you let it start with the correct shebang (else it is not a script, but juist a bunch of statements).
It is simple. When you want an executable program (being it a shell script, a Python program, a compiled/linked C/Fortran/Cobol program) to be made available for execution, you have to set the appropriate x-bits. Look at konqueror:
henk@boven:~> l /usr/bin/konqueror
-rwxr-xr-x 1 root root 5656 feb 4 22:15 /usr/bin/konqueror*
henk@boven:~>
The x-bits are set thus that the owner root the groupmembers of group root and everybody else can execute it. A script is not different at all.
Thank you