To start syslog automatically
[root@host1 root]# syslogd
syslogd: Already running.
[root@host1 root]#

The /etc/syslog.conf file is flexible in the entries it supports. 

For instance, you can specify multiple facilities, separated by commas, 
in one statement. In this example, the facilities kern, user, mail, and 
daemon have the same priority pattern: emergency.

kern,user,mail,daemon.emerg     /var/log/messages
kern.warn;user.warn             /var/log/warnings

You can also combine facility.priority pairs using semicolons.
An asterisk stands for all facilities or priorities. So *.emerg 
instructs the syslog daemon to log messages with the priority of 
"emergency" from all facilities. The entry kern.* instructs it to 
log all messages of any priority from the kernel.

*.emerg        /var/log/messages
kern.*

In this example, the first rule specifies that all the messages of 
alert priority and above are sent to /var/log/syslog.alert, except for
user messages. The second line specifies that all user alert messages 
must be sent to a different file.

*.alert;user.none      /var/log/syslog.alert
user.alert             /var/log/syslog.user.alert

Configure syslog to log to remote machine - to centralize logging for easy analysis:

Suppose that you want to log all system messages to a remote host called 
computer33. If your system crashes, you'll then be able to find out what 
went wrong by reading the messages stored on the remote host. To do this, 
you open the /etc/syslog.conf file in the vi editor and add this entry to it.

# Various entry
auth,authpriv.*    /var/log/auth.log
*.*                @computer33

This simple script, for example, uses grep to examine every file in 
/var/log/samba for the string "connect to service". If it finds this 
string, it indicates that someone has connected successfully to a 
samba resource.

#!/bin/bash
# Description: Script to check Samba logs for successful connections
echo
echo
echo "Checking for successful Samba connections to this server..."
echo "You should view the following log files..."
grep -F1 'connect to service' /var/log/samba/*

The script then returns the names of all the log files - in this case, 
hostnames - that contain the string. If it returns a log file called 
host1.log, for example, it indicates that the machine called host1 
completed a connection

Rotate and archiving logs in Linux:

The logrotate program enables automatic rotation, compression, removal, 
and mailing of log files. You can use it to rotate files daily, weekly, 
monthly, or whenever they grow too large. You use the logrotate command 
with this syntax.  

logrotate options configurationfile 

The configuration file you identify in a logrotate command specifies 
rotation options for the log files. Usually, this is the /etc/logrotate.conf file.

The /etc/logrotate.conf file includes two sections - the first section 
contains global options, and the second contains local options.

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own lastlog or wtmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
    rotate 1
}

automation and scheduling:

The at command enables the simplest form of job scheduling. 
It runs a command or a series of commands once only at a 
specified time, and mails any output to the user. The jobs 
it runs are processed in the background.  You use this 
syntax for the at command. In the syntax, you can specify 
the time in a number of different ways. For example, you can 

specify the time as 01:30 or as 1:30 am.
[root@host11 grosetti]# at -m 01:30

You now want to schedule a series of commands that you've 
saved in a file named "system_maintenance" to run at 12:00 pm.
To do this, you use the -f option to specify the file in an at command.

[root@host11 grosetti]# at -f system_maintenance 12:00

Suppose that it is the end of June and you want to schedule 
a job to run four weeks from today, without entering the 
exact date on which it must run.  Which command do you enter before s
pecifying the job that must run to do this?

at now + 4 weeks 

Ordinary users use the crontab command to create or edit their crontab files.
To use the crontab command, users must be listed in the file /etc/cron.allow. 
If that file doesn't exist, the users must not be listed in /etc/cron.deny. 
If neither file exists, all users can use the crontab command unless some 
other configuration prevents this.


[root@samwise root]# crontab -l
no crontab for root
[root@samwise root]# crontab -e to create

An entry of 00 in the minute field, 20 in the hour field, and 1-5 in the day 
of week field specifies that a command must run at 8:00 pm every day, from 
Monday to Friday.

 00 20 * * 1-5 sort/usr/sales

In order, the fields that make up the time pattern in a crontab file entry 
include minute, hour, day of month, month of year, and day of week.  Examples:


0 22 * * 1-5                   10:00 pm on weekdays 
15 14 1 * *                    2:15 pm on the first of every month
30 /2 * * *                    Half past the hour every two hours
30 19 * * 1                    7:30 pm every Monday

The /etc/at.allow and /etc/at.deny files enable you to control which 
users can run the at command. When a user tries to run an at job, 
the at command checks to see if the /etc/at.allow file exists. 
If it does and the user is listed in the file, at schedules the job. 

If the user is not listed in /etc/at.allow, they will not be able to 
schedule the job, irrespective of whether they are listed in the /etc/at.deny file.
If the /etc/at.allow file does not exist, at checks the /etc/at.deny file. 
If the user's name does not appear in this file, the job will be scheduled.
If the /etc/at.allow file doesn't exist and /etc/at.deny is empty, any user 
can run at jobs. Alternatively, if /etc/at.allow exists and is empty, or 
if neither file exists, no user except root can run at jobs.

In some Linux distributions, such as Red Hat 7, any user can run cron jobs 
if neither the /etc/cron.allow or /etc/cron.deny files exist. In other 
distributions, only root can run cron jobs if neither file exists.