!SxCwoMDDLFxMJcVaKl:matrix.org

syslog-ng

182 Members
3 Servers

Load older messages

SenderMessageTime
25 Nov 2023
@_discord_851301431155490826:t2bot.ioarta.eth joined the room.03:25:25
@_discord_271774181295652864:t2bot.ioquantumcat40 joined the room.13:47:17
27 Nov 2023
@_discord_105120866047631360:t2bot.iogingimli 21:01:29
29 Nov 2023
@_discord_1095768645520593056:t2bot.iogamba47 joined the room.13:59:58
30 Nov 2023
@_discord_1179735565751558208:t2bot.iowowbagger_40528 joined the room.10:49:13
@_discord_839876246518366218:t2bot.iohofione hi,
i cannot decide what is the normal behavior, so asking instead

i have 2 syslog() sources
one UDP and one TCP
source source_269135093939866322999281528312881493959_0 {
    syslog (
        ip(localhost)
        port(40000)
        transport("udp")
        flags(no-parse)
    );
};

source source_269135093939866322999281528312881493959_1 {
    syslog (
        ip(localhost)
        port(40001)
        transport("tcp")
        flags(no-parse)
    );
};

(please note the no-parse flags)

the UDP one eats the none RFC formatted input
the TCP one reports invalid frame header

test input was fed by
loggen  --dont-parse --read-file=./loggen_input_framed_transport_test.txt -n 2 --permanent localhost 40000 -D

loggen  --dont-parse --read-file=./loggen_input_framed_transport_test.txt -n 2 --permanent localhost 40001 -i -P


where the input file content was 
PROXY TCP4 1.1.1.1 2.2.2.2 3333 4444
<34>Oct 11 22:14:15 myhostname sshd[1234]: Accepted publickey for user from 192.168.1.1 port 1234 ssh2


which one is correct? UDP source or TCP source behavior?

(my bet, as both the source and the loggen got no-parse options, the UDP one is the correct) 		11:56:33
@_discord_839876246518366218:t2bot.iohofione * hi,
i cannot decide what is the normal behavior, so asking instead

i have 2 syslog() sources
one UDP and one TCP
source source_269135093939866322999281528312881493959_0 {
    syslog (
        ip(localhost)
        port(40000)
        transport("udp")
        flags(no-parse)
    );
};

source source_269135093939866322999281528312881493959_1 {
    syslog (
        ip(localhost)
        port(40001)
        transport("tcp")
        flags(no-parse)
    );
};

(please note the no-parse flags)

the UDP one eats the none RFC formatted input
the TCP one reports invalid frame header

test input was fed by
loggen  --dont-parse --read-file=./loggen_input_framed_transport_test.txt -n 2 --permanent localhost 40000 -D

loggen  --dont-parse --read-file=./loggen_input_framed_transport_test.txt -n 2 --permanent localhost 40001 -i -P 

(also tried -F for the 2nd one)


where the input file content was 
PROXY TCP4 1.1.1.1 2.2.2.2 3333 4444
<34>Oct 11 22:14:15 myhostname sshd[1234]: Accepted publickey for user from 192.168.1.1 port 1234 ssh2


which one is correct? UDP source or TCP source behavior?

(my bet, as both the source and the loggen got no-parse options, the UDP one is the correct) 		12:01:38
@_discord_1095768645520593056:t2bot.iogamba47 12:52:03
@_discord_1179847726381404241:t2bot.iogabor_88547 joined the room.18:14:19
@_discord_728067021966802994:t2bot.iocalmazans joined the room.20:13:08
1 Dec 2023
@_discord_1180073412702507088:t2bot.iohaxodon_82096 joined the room.09:12:35
4 Dec 2023
@_discord_1181124704585662514:t2bot.iopilosula_32045 joined the room.07:10:12
6 Dec 2023
@_discord_303337119349211136:t2bot.ioMark joined the room.01:09:09
@_discord_839876246518366218:t2bot.iohofione bazsi77 overorion could you please take a look at this?
https://github.com/syslog-ng/syslog-ng/pull/4544
the actual solution gives a generic tcp proxy that can be used for all the tcp based sources e.g. network(), syslog()

i've tested it with the network() source that seems to be fine for me

but

i couldn't find any RFC of transmitting syslog over a proxy
RFC 6587 is only about the TCP part

so i do not know if it's a valid case at all now

if it was valid then i would need some help as there are/might be multiple issues (e.g. in my interpretation the proxy header should not be octet counted that the framed proto is not prepared for in its actual state)

(actually, my tests are passed on syslog() as well for all the proxied variants, but only with well prepared inputs a.k.a octet counted proxy headers) 		11:59:15
@_discord_839876246518366218:t2bot.iohofione * bazsi77 overorion could you please take a look at this?
https://github.com/syslog-ng/syslog-ng/pull/4544
the actual solution gives a generic tcp proxy that can be used for all the tcp based sources e.g. network(), syslog()

i've tested it with the network() source that seems to be fine for me

but

i couldn't find any RFC of transmitting syslog over a proxy
RFC 6587 is only about the TCP part

so i do not know if it's a valid case at all now

if it was valid then i would need some help as there are/might be multiple issues

(actually, my tests are passed on syslog() as well for all the proxied variants, but only with well prepared inputs a.k.a octet counted proxy headers) 		12:35:11
@_discord_839876246518366218:t2bot.iohofione * bazsi77 overorion could you please take a look at this?
https://github.com/syslog-ng/syslog-ng/pull/4544
the actual solution gives a generic tcp proxy that can be used for all the tcp based sources e.g. network(), syslog()

i've tested it with the network() source that seems to be fine for me

but

i couldn't find any RFC of transmitting syslog over a proxy
RFC 6587 is only about the TCP part

so i do not know if it's a valid case at all now

(actually, my tests are passed on syslog() as well for all the proxied variants, but only with well prepared inputs) 		12:36:11
@_discord_888751691606937651:t2bot.iosteveizzle joined the room.16:56:19
@_discord_914929598179975239:t2bot.iobazsi77 Of course I'd look at it. Bit overwhelmed these days. 19:50:01
@_discord_914929598179975239:t2bot.iobazsi77 I am not sure I understand why LogTransportSocketProxy cannot be a LogTransport instance. That's the design that I had in mind originally. Maybe multitransport does make that impossible? I'll check this in more details 19:56:21
7 Dec 2023
@_discord_306521119928877056:t2bot.iooverorion changed their display name from UBWGUNNER to overorion.07:09:58
@_discord_306521119928877056:t2bot.iooverorion Not sure about this week (really occupied these days), but next week I will have a look, thanks! 07:09:58
@_discord_724134903389618177:t2bot.iomstopa joined the room.11:04:48
@_discord_839876246518366218:t2bot.iohofione as i can see, it cannot be LogTransport based (simply) because in that case, either
1.) it must extend (or become part of the) LogTransport, and all of the inherited classes (MultiTransport, LogTransportSocket, etc.) must be inherited from the new proxied transport class, or
2.) we must add all the LogTransport proxied variants as well (e.g. ProxiedMultiTransport, ProxiedLogTransportSocket, etc.) that we surely do not want

the solution i've added seemed to be better for me, than option 1.) above, yes it also has PROs and CONs, this is why I asked support earlier, to discuss what would be the best solution here 		11:12:30
@_discord_839876246518366218:t2bot.iohofione * as i can see, it cannot be LogTransport based (simply) because in that case, either
1.) it must extend (or become part of the) LogTransport, and all of the inherited classes (MultiTransport, LogTransportSocket, etc.) must be inherited from the new proxied transport class, or
2.) we must add all the LogTransport proxied variants as well (e.g. ProxiedMultiTransport, ProxiedLogTransportSocket, etc.) that we surely do not want

the solution i've added seemed to be better for me than option 1.) above, yes it also has PROs and CONs, this is why I asked support earlier, to discuss what would be the best solution here 		11:15:19
@_discord_914929598179975239:t2bot.iobazsi77 I am working on fixing clang support and get back to this. 11:15:33
@_discord_839876246518366218:t2bot.iohofione yepp CzP mentioned, I'm curious how it will end, I started once for a short time, with no luck (bunch of c++ issues) 11:16:44
@_discord_914929598179975239:t2bot.iobazsi77 It already works more or less. 11:16:59
@_discord_839876246518366218:t2bot.iohofione * yepp CzP mentioned it, I'm curious how it will end, I started once for a short time, with no luck (bunch of c++ issues) 11:17:03
@_discord_914929598179975239:t2bot.iobazsi77 I found a glib bug but it compiles for me on Linux with clang/clang++ 11:17:41
@_discord_839876246518366218:t2bot.iohofione can't wait for it to test it on macOS 😉 11:19:13

Show newer messages

Back to Room ListRoom Version: 10