Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

Articles portant le tag ‘syslog’

Consolidation des logs avec rsyslog, MySQL et LogAnalyser

Debian Lenny et Wheezy, Ubuntu Server 10.04

Dès qu’on a plus d’un serveur à gérer il est intéressant de pouvoir centraliser les logs des différentes machines pour en simplifier l’administration. C’est relativement facile avec rsyslog. Ce mini tuto va nous permettre de monter un serveur de logs sous Debian, les logs étant stockées dans une base MySQL.
Lire la suite »

logwatch ne trouve pas freshclam.log

Debian 5.07 Lenny – logwatch 7.3.6.cvs20080 –  clamav-freshclam 0.96.5+dfsg-1~volatile1

Les rapports logwatch contiennent le message suivant pour clam-update :

--------------------- clam-update Begin ------------------------ 
 
  No updates detected in the log for the freshclam daemon (the
 ClamAV update process).  If the freshclam daemon is not running,
 you may need to restart it.  Other options:
 
 A. If you no longer wish to run freshclam, deleting the log file
    (default is freshclam.log) will suppress this error message.
 
 B. If you use a different log file, update the appropriate
    configuration file.  For example:
       echo "LogFile = log_file" >> /etc/logwatch/conf/logfiles/clam-update.conf
    where log_file is the filename of the freshclam log file.
 
 C. If you are logging using syslog, you need to indicate that your
    log file uses the syslog format.  For example:
       echo "*OnlyService = freshclam" >> /etc/logwatch/conf/logfiles/clam-update.conf
       echo "*RemoveHeaders" >> /etc/logwatch/conf/logfiles/clam-update.conf

Lire la suite »

Limiter les logs snmpd dans syslog

Testé sur Debian 5.0 Lenny et Ubuntu Server 8.04 LTS Hardy

Le démon snmpd est un grand bavard dans sa configuration par défaut sous Debian et Ubuntu, et on se retrouve rapidement avec un syslog envahi de messages à chaque connexion d’un client snmp :

Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:42720
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:55670
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:56655
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:55557
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:46846
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:34805
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:49261
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:35418
Feb 25 10:40:06 monhost snmpd[2404]: Connection from UDP: [x.x.x.x]:35673

Pour clouer le bec à l’insolent, il faut aller modifier les options de démarrage SNMPDOPTS du démon dans /etc/default/snmpd :

SNMPDOPTS='-LS4d -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid '

L’option qui nous intéresse est -LS4d qui permet de n’écrire dans syslog qu’à partir du niveau warning. Un petit redémarrage du démon et le tour est joué.

A noter que la syntaxe semble différer selon les distributions, pour la vôtre ça sera peut-être -LS 4 d avec des espaces entre les arguments pour obtenir le résultat (erreur de syntaxe sous Debian).

Un extrait de la man page de snmpcmd sur les options de journalisation

(pour les niveaux d’alerte, pas pour la syntaxe des options, c’est différent de SNMPDOPTS)

The  mechanism  and destination to use for logging of warning and error messages can be controlled by passing  various  parameters  to  the  -L flag.
 
-Le    Log messages to the standard error stream.
 
-Lf FILE
Log messages to the specified file.
 
-Lo    Log messages to the standard output stream.
 
-Ls FACILITY
Log  messages  via syslog, using the specified facility ('d' for LOG_DAEMON, 'u' for LOG_USER, or '0'-'7' for LOG_LOCAL0  through LOG_LOCAL7).
 
There  are  also  "upper case" versions of each of these options, which allow the corresponding logging mechanism to be restricted  to  certain priorities of message.  Using standard error logging as an example:
 
-LE pri
will log messages of priority 'pri' and above to standard error.
 
-LE p1-p2
will log messages with priority between 'p1'  and  'p2'  (inclusive) to standard error.
 
For  -LF  and  -LS  the priority specification comes before the file or facility token.  The priorities recognised are:
 
0 or !  for LOG_EMERG,
1 or a for LOG_ALERT,
2 or c for LOG_CRIT,
3 or e for LOG_ERR,
4 or w for LOG_WARNING,
5 or n for LOG_NOTICE,
6 or i for LOG_INFO, and
7 or d for LOG_DEBUG.
 
Normal output is (or will be!) logged at a priority level of LOG_NOTICE