Q:

Backing up for syslog/dmesg/message to different folder

I have an assignment where I am required to back up the /var/log/dmesg, /var/log/syslog and /var/log/message to text files in a different folder such as the Desktop. It will also create a file called Execution.txt to record the date and time whenever the bash script is run. I do have this code that I've written yet every time I run it, it gives me:
./bash.sh: line 7: /var/log/dmesg: Permission denied
./bash.sh: line 8: /var/log/syslog: Permission denied
./bash.sh: line 9: /var/log/message: Permission denied

However, it does create these files on the desktop, but the message and dmesg files are empty. I was wondering if this is normal or have I done something wrong? Below is the code that I have written so far. Any help would be appreciated. Thanks!
#!/bin/bash

cat /var/log/dmesg l nl >> /home/administrator/Desktop/dmesg
cat /var/log/syslog l nl >> /home/administrator/Desktop/syslog
cat /var/log/message l nl >> /home/administrator/Desktop/message

echo ' ' > /var/log/dmesg
echo ' ' > /var/log/syslog
echo ' ' > /var/log/message

date >> /home/administrator/Desktop/execution.txt

A:

I suspect you just don't have access to them from the user that is running this script. Look at the file ownerships:
$ ls -l /var/log/{dmesg,syslog,message}
ls: cannot access /var/log/message: No such file or directory
-rw-r----- 1 root   adm 86384 Mar  9 11:12 /var/log/dmesg
-rw-r----- 1 syslog adm 18553 Mar 25 13:25 /var/log/syslog

You could read from these files if you had a user in the adm group but you'd not be able to write. The first user on a system is typically a member of the adm group but if your ~/Desktop copies are empty, I'd suggest your user isn't (check with the groups command). You do have a few options.

You could either look at adding ACL permissions for your user. These are separate from the standard permissions and adding explicit read/write access to your user doesn't really affect anything else. Which is nice.
sudo apt-get install acl
sudo setfacl -m u:$USER:rw /var/log/{dmesg,syslog,message}

This might need a reboot to take. You might even need to change your fstab. I haven't but ACLs seem to work okay here so I'm assuming that's not required any more.
You could change the unix permissions on the file. The safest way of doing this would be to add your user to the adm group and then to enable group write on those files:
sudo usermod -a -G adm $USER
sudo chmod g+w /var/log/{dmesg,syslog,message}

You'll need to log out and in again to see the effect.
Or you could let anybody read and write these files. This could be a security risk so I'm not giving you code... But honestly, while possible, you probably don't want this.
The other option is simply running the script as root with sudo ./scriptname. The downside of this is that anything this script does will be done as root. That includes creating new files (which >> can if the file doesn't exist already) and that can be a pain for the user.

And if this isn't academic curiosity and you're actually trying to get some work done in the best possible way, there are tools that do these things for you but better. You really want to look at logrotate. This Digital Ocean tutorial is the cleanest one I can find quickly.

A:

You most probably don't have read permissions for /var/log/{dmesg,syslog,message}. So even though you have the files created on your destkop, they will be empty, since nothing was read but an attempt to write was made to a file(the one created on your desktop).
So you have two options:

Get read permissions for /var/log/{dmesg,syslog,message} as follows:
sudo usermod -a -G adm $USER #adm is the group name which owns /var/log/syslog

Use sudo for reading (easier for one-time read):
sudo cat /var/log/dmesg >> /home/administrator/Desktop/dmesg

A:

Your problem is the following lines of your script :
echo ' ' > /var/log/dmesg
echo ' ' > /var/log/syslog
echo ' ' > /var/log/message

Unsurprisingly, since those are precisely lines 7,8 and 9 which are the ones that bash is complaining about.
These commands are attempting to delete the contents of those 3 log files in /var/log but since they are owned by root and you have no write access to them, you are getting an error. Good! I am assuming you do not want to clear out your system logs like that.
Remember that > overwrites the contents of a file, you need >> to append to it. In any case, you should never modify those files, they are used by the system and there is absolutely no reason why you would want to overwrite them. Even if you do, there are far simpler ways do do so, like rm file or even simply > file.
A cleaner way to do all this would be to use logrotate instead.

