unsubscribe
On 4/14/22 23:39, Victor FROLOV (VMcS via rsyslog wrote:
> Hello,
>
> Thank you for your advice, particularly for logging with the debug template.
> I tested the different combinations and I agree the "fromhost-ip" is more
> reliable then "fromhost" (for the message received from socket or via udp
> but from local interfce the message keep the server name in "fromhost", but
> for remote sender this variable contain the IP address).
> However I think to use the "hostname" field - it have the name exact of
> remote server, whatever the interface or IP address was used by remote
> server to send the syslog message.
>
> Yes, you are right, I use the same condition twice, it's just the rest of
> more complex config, that I simplified to give the example for my first
> message.
>
> WBR,
> Victor
>
> -----Message d'origine-----
> De : rsyslog [mailto:rsyslog-bounces@lists.adiscon.com] De la part de
> Mariusz Kruk via rsyslog
> Envoyé : jeudi 14 avril 2022 17:00
> À : rsyslog-users
> Cc : Mariusz Kruk
> Objet : Re: [rsyslog] Two servers logs synchronization by rsyslog
>
> I'd not rely on fromhost. I use fromhost-ip whenever I need to differentiate
> between host.
> Also, if you're not sure what's going on with your logs, try logging with te
> debug template. This way you're getting the log entry along with all
> metadata and rsyslog variables at the moment of the log action. It's very
> very helpful.
> BTW, if you're calling the ruleset only for the local4.* messages, there's
> no point for the prifilt condition.
> And it could be a bit clearer (but boils down to the same action) if you
> just wrote to the file and then had a conditional forwarding. But that's up
> to your personal taste.
>
>
> On 14 April 2022 16:25:40 CEST, "Victor FROLOV (VMcS via rsyslog"
> <rsyslog@lists.adiscon.com> wrote:
>> Hello,
>>
>>
>>
>> I need your adwise.
>>
>>
>>
>> Environment:
>>
>> I have 2 freeradius servers united in one cluster. The radius databases are
>> synchronized and a client can send the request to any of the servers
>> following the client config. By default, radius write the logs locally and
>> during the troubleshooting I must look the logs on the both servers to
> found
>> the traces of client.
>>
>> I would like to synchronize the logs on the servers, i.e. each server must
>> write the local radius messages and the messages received from adjacent
>> server in the local log, also send the local only message to the adjacent
>> server (not received by udp message - to avoid the loop).
>>
>> For the radius messages I use the local4 facility.
>>
>> Freeradius send the messages to the local rsyslog through the file socket
>> /dev/syslog, then rsyslog write the messages to the log file and also send
>> these messages to the adjacent server by udp/514.
>>
>>
>>
>> By other words, I need the next behavior :
>>
>> On each server
>>
>> - The messages local4.* received via udp from the adjacent
>> server must be writed in the local log
>>
>> - The messages local4.* received via file socket OR via udp
> >from from the localhost must be writed in the local log AND must be sent to
>> the adjacent server
>>
>>
>>
>> Problem :
>>
>> The problem is the looping the messages between the servers.
>>
>> My configuration:
>>
>> (SERVER1 and SERVER2 are the FQDN well resolved to IP adresses)
>>
>>
>>
>> SERVER1 :
>>
>> #==============================================================
>>
>> module(load="imuxsock")
>>
>> module(load="imudp")
>>
>> input(type="imudp" port="514")
>>
>>
>>
>> template(name="TMPL_Radius_Local_Log" type="string"
>>
>> string="/var/log/radiusd/radiusd-%$YEAR%-%$MONTH%-%$DAY%.log"
>>
>> )
>>
>>
>>
>> ruleset(name="RLS_Radius"){
>>
>> if $fromhost == "SERVER2" and prifilt("local4.*") then {
>>
>> action (type="omfile" dynafile="TMPL_Radius_Local_Log")
>>
>> stop
>>
>> } else {
>>
>> action (type="omfile" dynafile="TMPL_Radius_Local_Log")
>>
>> action (type="omfwd" target=" SERVER2" port="514"
> protocol="udp")
>> stop
>>
>> }
>>
>> }
>>
>>
>>
>> local4.* {
>>
>> call RLS_Radius
>>
>> }
>>
>>
>>
>> auth,authpriv.* /var/log/auth.log
>>
>> *.*;auth,authpriv.none -/var/log/syslog
>>
>> kern.* -/var/log/kern.log
>>
>> mail.* -/var/log/mail.log
>>
>> mail.err /var/log/mail.err
>>
>> *.emerg :omusrmsg:*
>>
>>
>>
>> SERVER2 :
>>
>> #==============================================================
>>
>> module(load="imuxsock")
>>
>> module(load="imudp")
>>
>> input(type="imudp" port="514")
>>
>>
>>
>> template(name="TMPL_Radius_Local_Log" type="string"
>>
>> string="/var/log/radiusd/radiusd-%$YEAR%-%$MONTH%-%$DAY%.log"
>>
>> )
>>
>>
>>
>> ruleset(name="RLS_Radius"){
>>
>> if $fromhost == "SERVER1" and prifilt("local4.*") then {
>>
>> action (type="omfile" dynafile="TMPL_Radius_Local_Log")
>>
>> stop
>>
>> } else {
>>
>> action (type="omfile" dynafile="TMPL_Radius_Local_Log")
>>
>> action (type="omfwd" target=" SERVER1" port="514"
> protocol="udp")
>> stop
>>
>> }
>>
>> }
>>
>>
>>
>> local4.* {
>>
>> call RLS_Radius
>>
>> }
>>
>>
>>
>> auth,authpriv.* /var/log/auth.log
>>
>> *.*;auth,authpriv.none -/var/log/syslog
>>
>> kern.* -/var/log/kern.log
>>
>> mail.* -/var/log/mail.log
>>
>> mail.err /var/log/mail.err
>>
>> *.emerg :omusrmsg:*
>>
>>
>>
>> Why I have the looping between the servers? How to realize the mentioned
>> behavior?
>>
>>
>>
>> WBR,
>>
>> Victor
>>
>> _______________________________________________
>> rsyslog mailing list
>> https://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
>> What's up with rsyslog? Follow https://twitter.com/rgerhards
>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
> sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T
> LIKE THAT.
>
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
On 4/14/22 23:39, Victor FROLOV (VMcS via rsyslog wrote:
> Hello,
>
> Thank you for your advice, particularly for logging with the debug template.
> I tested the different combinations and I agree the "fromhost-ip" is more
> reliable then "fromhost" (for the message received from socket or via udp
> but from local interfce the message keep the server name in "fromhost", but
> for remote sender this variable contain the IP address).
> However I think to use the "hostname" field - it have the name exact of
> remote server, whatever the interface or IP address was used by remote
> server to send the syslog message.
>
> Yes, you are right, I use the same condition twice, it's just the rest of
> more complex config, that I simplified to give the example for my first
> message.
>
> WBR,
> Victor
>
> -----Message d'origine-----
> De : rsyslog [mailto:rsyslog-bounces@lists.adiscon.com] De la part de
> Mariusz Kruk via rsyslog
> Envoyé : jeudi 14 avril 2022 17:00
> À : rsyslog-users
> Cc : Mariusz Kruk
> Objet : Re: [rsyslog] Two servers logs synchronization by rsyslog
>
> I'd not rely on fromhost. I use fromhost-ip whenever I need to differentiate
> between host.
> Also, if you're not sure what's going on with your logs, try logging with te
> debug template. This way you're getting the log entry along with all
> metadata and rsyslog variables at the moment of the log action. It's very
> very helpful.
> BTW, if you're calling the ruleset only for the local4.* messages, there's
> no point for the prifilt condition.
> And it could be a bit clearer (but boils down to the same action) if you
> just wrote to the file and then had a conditional forwarding. But that's up
> to your personal taste.
>
>
> On 14 April 2022 16:25:40 CEST, "Victor FROLOV (VMcS via rsyslog"
> <rsyslog@lists.adiscon.com> wrote:
>> Hello,
>>
>>
>>
>> I need your adwise.
>>
>>
>>
>> Environment:
>>
>> I have 2 freeradius servers united in one cluster. The radius databases are
>> synchronized and a client can send the request to any of the servers
>> following the client config. By default, radius write the logs locally and
>> during the troubleshooting I must look the logs on the both servers to
> found
>> the traces of client.
>>
>> I would like to synchronize the logs on the servers, i.e. each server must
>> write the local radius messages and the messages received from adjacent
>> server in the local log, also send the local only message to the adjacent
>> server (not received by udp message - to avoid the loop).
>>
>> For the radius messages I use the local4 facility.
>>
>> Freeradius send the messages to the local rsyslog through the file socket
>> /dev/syslog, then rsyslog write the messages to the log file and also send
>> these messages to the adjacent server by udp/514.
>>
>>
>>
>> By other words, I need the next behavior :
>>
>> On each server
>>
>> - The messages local4.* received via udp from the adjacent
>> server must be writed in the local log
>>
>> - The messages local4.* received via file socket OR via udp
> >from from the localhost must be writed in the local log AND must be sent to
>> the adjacent server
>>
>>
>>
>> Problem :
>>
>> The problem is the looping the messages between the servers.
>>
>> My configuration:
>>
>> (SERVER1 and SERVER2 are the FQDN well resolved to IP adresses)
>>
>>
>>
>> SERVER1 :
>>
>> #==============================================================
>>
>> module(load="imuxsock")
>>
>> module(load="imudp")
>>
>> input(type="imudp" port="514")
>>
>>
>>
>> template(name="TMPL_Radius_Local_Log" type="string"
>>
>> string="/var/log/radiusd/radiusd-%$YEAR%-%$MONTH%-%$DAY%.log"
>>
>> )
>>
>>
>>
>> ruleset(name="RLS_Radius"){
>>
>> if $fromhost == "SERVER2" and prifilt("local4.*") then {
>>
>> action (type="omfile" dynafile="TMPL_Radius_Local_Log")
>>
>> stop
>>
>> } else {
>>
>> action (type="omfile" dynafile="TMPL_Radius_Local_Log")
>>
>> action (type="omfwd" target=" SERVER2" port="514"
> protocol="udp")
>> stop
>>
>> }
>>
>> }
>>
>>
>>
>> local4.* {
>>
>> call RLS_Radius
>>
>> }
>>
>>
>>
>> auth,authpriv.* /var/log/auth.log
>>
>> *.*;auth,authpriv.none -/var/log/syslog
>>
>> kern.* -/var/log/kern.log
>>
>> mail.* -/var/log/mail.log
>>
>> mail.err /var/log/mail.err
>>
>> *.emerg :omusrmsg:*
>>
>>
>>
>> SERVER2 :
>>
>> #==============================================================
>>
>> module(load="imuxsock")
>>
>> module(load="imudp")
>>
>> input(type="imudp" port="514")
>>
>>
>>
>> template(name="TMPL_Radius_Local_Log" type="string"
>>
>> string="/var/log/radiusd/radiusd-%$YEAR%-%$MONTH%-%$DAY%.log"
>>
>> )
>>
>>
>>
>> ruleset(name="RLS_Radius"){
>>
>> if $fromhost == "SERVER1" and prifilt("local4.*") then {
>>
>> action (type="omfile" dynafile="TMPL_Radius_Local_Log")
>>
>> stop
>>
>> } else {
>>
>> action (type="omfile" dynafile="TMPL_Radius_Local_Log")
>>
>> action (type="omfwd" target=" SERVER1" port="514"
> protocol="udp")
>> stop
>>
>> }
>>
>> }
>>
>>
>>
>> local4.* {
>>
>> call RLS_Radius
>>
>> }
>>
>>
>>
>> auth,authpriv.* /var/log/auth.log
>>
>> *.*;auth,authpriv.none -/var/log/syslog
>>
>> kern.* -/var/log/kern.log
>>
>> mail.* -/var/log/mail.log
>>
>> mail.err /var/log/mail.err
>>
>> *.emerg :omusrmsg:*
>>
>>
>>
>> Why I have the looping between the servers? How to realize the mentioned
>> behavior?
>>
>>
>>
>> WBR,
>>
>> Victor
>>
>> _______________________________________________
>> rsyslog mailing list
>> https://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
>> What's up with rsyslog? Follow https://twitter.com/rgerhards
>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
> sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T
> LIKE THAT.
>
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.