Handling correctly HOST value on the client side
Hello, I have a log management infrastructure with many servers sending logs to centralized servers. Currently, on the server side, I use the HOST field present in the log messages to store log messages in separate files (like <path>/<host>/messages). Of course, due to inconsistent content of the HOST value in the log messages, I have several log file locations for a single client. Bad point. My question : I want to fix the problem at the source and so, set a single unique value in the HOST field of every log message sent by each client. What is your preferred way to address this problem on the client side ? Do you use use_fqdn() global option ? If yes, how it works ? A reverse DNS call ? What is the value returned if a PTR value is not set in the DNS zone for the IP of the host ? Thank you for the reading and for your answer :) Christophe ***************************************************** "Le contenu de ce courriel et ses eventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire. Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans le présent courriel." ******************************************************
Le 27/08/2013 16:58, Christophe Brocas a écrit :
Hello,
I have a log management infrastructure with many servers sending logs to centralized servers.
Currently, on the server side, I use the HOST field present in the log messages to store log messages in separate files (like <path>/<host>/messages).
Of course, due to inconsistent content of the HOST value in the log messages, I have several log file locations for a single client. Bad point.
My question : I want to fix the problem at the source and so, set a single unique value in the HOST field of every log message sent by each client.
What is your preferred way to address this problem on the client side ? Do you use use_fqdn() global option ? If yes, how it works ? A reverse DNS call ? What is the value returned if a PTR value is not set in the DNS zone for the IP of the host ?
Thank you for the reading and for your answer :) Christophe Small HUP :)
Christophe ***************************************************** "Le contenu de ce courriel et ses eventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire. Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans le présent courriel." ******************************************************
On Tue, 2013-08-27 at 16:58 +0200, Christophe Brocas wrote:
Hello,
I have a log management infrastructure with many servers sending logs to centralized servers.
Currently, on the server side, I use the HOST field present in the log messages to store log messages in separate files (like <path>/<host>/messages).
Of course, due to inconsistent content of the HOST value in the log messages, I have several log file locations for a single client. Bad point.
My question : I want to fix the problem at the source and so, set a single unique value in the HOST field of every log message sent by each client.
What is your preferred way to address this problem on the client side ? Do you use use_fqdn() global option ? If yes, how it works ? A reverse DNS call ? What is the value returned if a PTR value is not set in the DNS zone for the IP of the host ?
Thank you for the reading and for your answer :) Christophe
well either the server trusts the client with the hostname it sent in the message (keep-hostname(yes) setting) or it doesn't. if the server doesn't trust the client, it will reverse the IP address based on DNS and /etc/hosts (we do have an option to only use /etc/hosts) if the server does trust the client, the client will have to use proper HOST value in the messages it sends. by default syslog-ng uses gethostname() to find out its own hostname, but if you are using a different client that might work differently. if you use syslog-ng on the client side HOST should be consistent for all messages. Hope this helps,
Le 29/08/2013 18:19, Balazs Scheidler a écrit :
On Tue, 2013-08-27 at 16:58 +0200, Christophe Brocas wrote:
Hello,
I have a log management infrastructure with many servers sending logs to centralized servers.
Currently, on the server side, I use the HOST field present in the log messages to store log messages in separate files (like <path>/<host>/messages).
Of course, due to inconsistent content of the HOST value in the log messages, I have several log file locations for a single client. Bad point.
My question : I want to fix the problem at the source and so, set a single unique value in the HOST field of every log message sent by each client.
What is your preferred way to address this problem on the client side ? Do you use use_fqdn() global option ? If yes, how it works ? A reverse DNS call ? What is the value returned if a PTR value is not set in the DNS zone for the IP of the host ?
Thank you for the reading and for your answer :) Christophe well either the server trusts the client with the hostname it sent in the message (keep-hostname(yes) setting) or it doesn't.
if the server doesn't trust the client, it will reverse the IP address based on DNS and /etc/hosts (we do have an option to only use /etc/hosts)
if the server does trust the client, the client will have to use proper HOST value in the messages it sends. by default syslog-ng uses gethostname() to find out its own hostname, but if you are using a different client that might work differently. Hello Balazs
I am in this case and currently, we have old syslogd on many systems. syslogd provides unfortunately unconsistent host value in log messages. The good point is that you confirm that syslog-ng (soon on our client systems) generates consistent host value (based on gethostname() result) for all messages it sent to the log server. Thank you for this reply. Christophe
if you use syslog-ng on the client side HOST should be consistent for all messages.
Hope this helps,
-- Christophe Brocas CNAMTS/DDSI/DS | 12, allées Haussmann 33300 Bordeaux (fixe)+33 557.855.355 | (mobile)+33 677.051.901 | 3072R/0x0661CBBA ***************************************************** "Le contenu de ce courriel et ses eventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire. Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans le présent courriel." ******************************************************
participants (2)
-
Balazs Scheidler
-
Christophe Brocas