Systems Administration

This is probably obvious to the system administrators out there, but it's interesting to note the impact when you don't pipe the output (both stdout and stderr) of a cron job to /dev/null.

Every time the task runs, it emails its output to the account owner. If this happens every 5 minutes, that's 288 times a day or about a hundred thousand after a year.

If you intend that server -- and the cronjob running on it -- to be running for a long time without intervention, do yourself a favor and send the output to the null device. Or else you'll wind up with gigabytes in /var/mail.

This article on spamhaus details how spammers are using cracked FTP accounts to spread malware in spam. FTP cracking is hardly new, but the article gives some excellent reasons to switch away from plain FTP.

It also illustrates an interesting -- and slightly scary -- convergence of technology to further spammers' aims.

There's an added overhead in moving large numbers of files from one computer to another. If the source and destination are similar enough in configuration and you have time to spare, you might simply use rsync or a raw file copy.

There are other -- faster -- ways, particularly if you're trying to archive those files or are in a hurry.

Systems administrators typically use the date command in combination with cp -R to provide backup functionality. In a cronjob, the command


cp -R /path/to/backup /backup/destination/backup-`date +%u`


So what will this do? It will create seven distinct directories, one for each day of the week (1 through 7). When overwriting your old backups, you can either delete them first, or set cp to overwrite them. Neither is really optional.