3.3. Sources and source drivers

A source is where syslog-ng receives log messages. Sources consist of one or more drivers, each defining where and how messages are received.

To define a source, add a source statement to the syslog-ng configuration file using the following syntax:

source <identifier> { source-driver(params); source-driver(params); ... };

[Example] Example 3.2. A simple source statement

The following source statement receives messages on the TCP port 1999 of the interface having the 10.1.2.3 IP address.

source s_demo_tcp { tcp(ip(10.1.2.3) port(1999)); };
                
[Example] Example 3.3. A source statement using two source drivers

The following source statement receives messages on the 1999 TCP port and the 1999 UDP port of the interface having the 10.1.2.3 IP address.

source s_demo_two_drivers { 
           tcp(ip(10.1.2.3) port(1999)); 
           udp(ip(10.1.2.3) port(1999)); };
            

To collect log messages on a specific platform, it is important to know how the native syslogd communicates on that platform. The following table summarizes the operation methods of syslogd on some of the tested platforms:

Platform Method
Linux A SOCK_STREAM unix socket named /dev/log; some of the distributions switched over to using SOCK_DGRAM, though applications still work with either method.
BSD flavors A SOCK_DGRAM unix socket named /var/run/log.
Solaris (2.5 or below) An SVR4 style STREAMS device named /dev/log.
Solaris (2.6 or above) In addition to the STREAMS device used in earlier versions, 2.6 uses a new multithreaded IPC method called door. By default the door used by syslogd is /etc/.syslog_door.
HP-UX 11 or later HP-UX uses a named pipe called /dev/log that is padded to 2048 bytes, e.g., source s_hp-ux {pipe ("/dev/log" pad_size(2048)}.
AIX 5.2 and 5.3 A SOCK_STREAM or SOCK_DGRAM unix socket called /dev/log.

Table 3.2. Communication methods used between the applications and syslogd


Each possible communication mechanism has a corresponding source driver in syslog-ng. For example, to open a unix socket with SOCK_DGRAM style communication use the driver unix-dgram. The same socket using the SOCK_STREAM style — as used under Linux — is called unix-stream.

[Example] Example 3.4. Source statement on a Linux based operating system

The following source statement collects the following log messages:

  • internal(): Messages generated by syslog-ng.

  • udp(ip(0.0.0.0) port(514)): Messages arriving to the 514/UDP port of any interface of the host.

  • unix-stream("/dev/log");: Messages arriving to the /dev/log socket.

source s_demo { 
           internal(); 
           udp(ip(0.0.0.0) port(514)); 
           unix-stream("/dev/log"); };
				

The following table lists the source drivers available in syslog-ng.

Name Description
internal() Messages generated internally in syslog-ng.
unix-stream() Opens the specified unix socket in SOCK_STREAM mode and listens for incoming messages.
unix-dgram() Opens the specified unix socket in SOCK_DGRAM mode and listens for incoming messages.
file() Opens the specified file and reads messages.
pipe(), fifo Opens the specified named pipe and reads messages.
tcp() Listens on the specified TCP port for incoming messages.
udp() Listens on the specified UDP port for incoming messages.
tcp6() Listens on the specified TCP port for incoming messages over IPv6.
udp6() Listens on the specified UDP port for incoming messages over IPv6.
sun-stream(), sun-streams() Opens the specified STREAMS device on Solaris systems and reads incoming messages.

Table 3.3. Source drivers available in syslog-ng


For a complete description on the above drivers, see Section 9.1, “Source drivers”.

Define a source only once. The same source can be used in several log paths. Duplicating sources causes syslog-ng to open the source (TCP/IP port, file, etc.) more than once, which might cause problems. For example, include the /dev/log file source only in one source statement, and use this statement in more than one log path if needed.


© 2007 BalaBit IT Security
Please send your comments or documentation bugs to: documentation@balabit.com