*** Following are the key features of syslog-ng: Centralized system logging TCP based communication is inherently more reliable than UDP (can be TLSed) Flexible filtering options for message content, category and origin Diverse choices of sources and destinations including TCP, UDP, files, pipes, FIFO, datagram and stream unix sockets Wide platform support (all major Unix and Linux) Agent for windows to transfer logs to central server (only available in commercial edition) Disk based message buffering, local storage of messages, if central server is unavailable (only available in commercial edition) Flow control, where sylog-ng stops reading messages from sources, if destination cannot process the previously sent messages Manipulate and re-structure log messages, such as adding hostnames and date to the beginning of every log message with templates. Can also be used for constructing SQL statements Timezone support including interpreting timezone in message, associating source and destination with a particular time zone Support large size messages with log_msg_size option Private and configurable DNS cache allows storing IP to hostname mapping
*** Centralized logging is essential for large heterogeneous environments to serve the purpose of security, auditing and system health monitoring.
*** Limitations with default syslog include limited filtering based only on priority and facility, absence of content based filtering, lack of TCP support, lack of timezone information in log messages, max message size of 1024 bytes
*** syslog-ng can receive messages from applications, files, remote hosts and other sources. syslog-ng clients that send messages to syslog-ng server also run syslog-ng. Log-path defines what syslog-ng does with a message, connecting sources with destinations. Log-path in syslog-ng configuration is called log statement and can include filters. syslog-ng relay cannot write messages from the network sources to local files. As per syslog RFC, syslog message consists of PRI, HEADER and MSG. Total size of syslog message should be less than 1024 bytes. To replace the default syslogd, it is important to know how the native syslogd communicates on the particular platform. e.g /var/run/syslog SOCK_DGRAM on Mac OS X. Unix sockets can be of stream or datagram type. Source or destination driver is a communication method used for receiving or delivering log messages. A source should be defined only once, although it can be used in several log paths. Log paths are processed in their sequence of appearance. All log paths/statements are processed, so multiple actions can be taken for every message. flag options within log statement can override this behavior. 'final', 'fallback', 'catchall' and 'flow-control' are available flags. Filters consist of functions (which supports regular expressions) and boolean operators such as and, or, not. Templates can be used to create message formats or filenames and can include macros.
*** Configuration of syslog-ng begins with global object definition. Object can be source, destination, log, filter or template. Parameters within object definition can be compulsory or optional. Comments are pre-fixed with '#' character. Sample source statement is, source {source-driver(params); source-driver(params); ...}; A sample destination statement is, destination {destination-driver (params); destination-driver {params); ...}; A sample log statement is, log { source(name); source(name); ... filter(name); filter(name); ... destination(name); destination(name); ... flags(flag1); }; A sample filter statement is, filter {expression; }; A sample template statement is, template { template ("$ISODATE $HOST $MSG\n"); template_escape{no)); }; A sample option statement is option { option1(params); option2(params); };
*** It is advised to not separate messages based on facility. Use ts_format(iso) option to modify timestamps in messages to include timezone information. DNS resolution can be disabled by using use_dns global option.
Purchase criteria for console servers and KVM over IP siwtches
Rights & Authentication: 1) Authentication protocols such as RADIUS, TACACS+, Active Directory, RSASecurID and LDAP supported for identifying users? 2) What rights management or authorization features are available? Such as restriction per port per user/group, time of day etc? Are these ACLs defined locally or via AD, LDAP, TACACS+ and RADIUS?
Management features: 1) Single view for all monitored devices without requiring to scroll or click to quickly spot problems 2) Consolidates console, KVM over IP and power management solutions 3) Scheduling of tasks such as power-on, export console server etc? 4) Analog and digital connectivity in one device
Access methods: 1) IPSec VPN support? 2) Telnet, SSH, web access? 3) Dial-in, dial-back, wireless and other out-of-band connectivity support?
Facilities management: 1) Power and rack space considerations? 2) Serial surge protection support? 3) Power strip control
Availability & Redundancy: 1) Automatic fail-over and syncing of data and transactions and/or clustering options 2) Solution architecture, distributed or hub and spoke (one server connecting to multiple console and KVM over IP switches)
Security 1) Encryption of data in transit using SSL, AES, DES, 3DES 2) Exit macros to send keystrokes to log out each user when a session is terminated for any reason 3) Level of auditing of user access and format of audit logs?
Manageability 1) Flash upgradeable 2) Customized view per user 3) SNMP and email integration for monitoring and alerting? 4) Backup and restoration of device itself?
Reporting 1) Which event logging format (syslog etc) are supported? 2) Statistics of user access/reporting and its format. Integration with existing reporting investments?
Misc: 1) Solaris reboot feature with a 'break' combination? 2) Shared access to same port for monitoring, knowledge transfer? 3) Intelligent cabling to facilitate device naming and detection 4) Multi-device and platform support including power consoles, environmental monitors, UPS, power generators, PBX etc 5) Scalability with growth in users, servers and network devices 6) Programmability to take automatic actions 7) Virtual media for remote file transfer 8) Windows scaling with window size change? 9) ROI by calculating cost per managed port? 10) NEBS certification and level of certification 11) IPMI (Intelligent Platform Management Interface) support. It is an open standard that runs on dedicated chip known as BMC (Baseboard Management Controller). BMC runs independent of server OS. Server management can be done either via an agent running locally on OS or via a hardware feature such as IPMI. IPMI helps to monitor hardware and sensors, control system components and retrieve logs of important system events. Hardware health conditions such as temperature, fan, voltage, hardware errors (memory, network etc) and chassis intrusion.
