Re: Spamd sync observations and differences and setup question.
hi! On Tue, Jun 26, 2007 at 07:04:29PM -0400, Daniel Ouellet wrote: I setup the spamd sync feature between two servers running 4.1 and I observe the following issues with the setup itself. Some setup based on the man page do not work for me anyway and some are not always reliable and some always work. See below. Example Interface facing the Internet: dc0. server1.test.com 1.1.1.2 server2.test.com 1.1.1.3 setup in rc.conf.local that always work. In server 1: spamd_flags=-y dc0 -Y 1.1.1.3 In server 2: spamd_flags=-y dc0 -Y 1.1.1.2 hmm, ok. i will look into this. = Setup that mostly work. Meaning if you reboot, it doesn't always start spamd and as far as I can tell, that's because the name resolutions do not work right away when the query is requested, or something like that. This configuration will not always work and be reliable on reboot of servers. However based on the man page, it should. if you do it on the command line it does. Just reboot doesn't always do it. In server 1: spamd_flags=-y dc0 -Y server2.test.com In server 2: spamd_flags=-y dc0 -Y server1.test.com == Setup that I never been able to get to work. I see the message that said the initial communications between the two servers, but never do I see any sync messages exchanged between the two on the multicast channel. Only the initial helo message, but never any updates. In server 1: spamd_flags=-y dc0 -Y dc0 In server 2: spamd_flags=-y dc0 -Y dc0 you have to enable ip multicast on the systems. by default, openbsd rejects any ip multicast traffic by adding a route route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject try to set multicast_host=dc0 in /etc/rc.conf or /etc/rc.conf.local Setup that I never got to work at all. Not even the initial help message at all. In server 1: spamd_flags=-y server1.test.com -Y server1.test.com -Y server2.test.com In server 2: spamd_flags=-y server2.test.com -Y server1.test.com -Y server2.test.com In theory the man page said that you should be able to do this. I get: spamd: sync init: Device not configured I am still puzzle as to why it also should send the updates to itself here. Meaning -Y server2.test.com when it's configure on server2? It's the one sending the updates, so it already know what it is sending. Anyway, that's what I got. Now in the final setup, I do see the sync messages in the first configuration above, but it's still not clear to me how I can see the results in the /var/db/spamd file, or may be in the pf table spamd-white. I try to add some address to see with spamdb -a 1.2.3.4 on one side and expected it to be added on the second server, but never see it in the spamdb. I don't see it in the pf table spamd-white either. Isn't it suppose to be there some how? Or may be I need to add something in the pf configuration to log it to the spamd-white table when the updates are coming in. That might be it, but the man page say nothing about that. Am I forgetting something here. All this is with brand new 4.1 install. did you upgrade it to 4.1-stable? there was a minor fix for spamd-sync after the release. Thanks Daniel
Re: Spamd sync observations and differences and setup question.
Reyk Floeter wrote: you have to enable ip multicast on the systems. Shouldn't it be included in the man page then? May be I miss it, but I read them many times over to try to figure it out. I sure will test tonight when the servers are a bit less use. by default, openbsd rejects any ip multicast traffic by adding a route route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject One question however. CARP also use multicast and didn't need this, only net.inet.carp.preempt=1 in that specific case. I guess I am not understanding something here, or just not clear to me. Should it be rejected in CARP case as well then? I know both are not related, but I am more referring at the logic of how each work and both use multicast and in one case, the man page said to enable net.inet.carp.preempt=1 and nothing about adding multicast as well. Or is that does the same thing here? try to set multicast_host=dc0 in /etc/rc.conf or /etc/rc.conf.local I sure will try. In any case, I sure can use unicast only as well. But I will try to know for sure. did you upgrade it to 4.1-stable? there was a minor fix for spamd-sync after the release. No yet. (; I install about 20 of them all default install for now. Massive roll out last weekend. All new fresh wipe clean. My mistakes here, sorry. Thanks for the updates, Daniel
Re: Spamd sync observations and differences and setup question.
On Wed, Jun 27, 2007 at 02:37:25PM -0400, Daniel Ouellet wrote: Reyk Floeter wrote: you have to enable ip multicast on the systems. Shouldn't it be included in the man page then? May be I miss it, but I read them many times over to try to figure it out. I sure will test tonight when the servers are a bit less use. by default, openbsd rejects any ip multicast traffic by adding a route route -qn add -net 224.0.0.0/4 -interface 127.0.0.1 -reject One question however. CARP also use multicast and didn't need this, only net.inet.carp.preempt=1 in that specific case. I guess I am not understanding something here, or just not clear to me. Should it be rejected in CARP case as well then? I know both are not related, but I am more referring at the logic of how each work and both use multicast and in one case, the man page said to enable net.inet.carp.preempt=1 and nothing about adding multicast as well. Or is that does the same thing here? The reject route only triggers for UDP traffic. So carp (which runs inside the kernel) and ospfd (uses a raw socket) are not affected. On the other hand ripd/routed and other tools using multicast over UDP hit that route and when sending all packets are discrded. try to set multicast_host=dc0 in /etc/rc.conf or /etc/rc.conf.local I sure will try. In any case, I sure can use unicast only as well. But I will try to know for sure. I prefer to add a specific host route to 127.0.0.1 to let specific multicast traffic through the box. ripd -- as it already plays around with the routing table -- add such a route on startup but I think that's overkill for spamd. -- :wq Claudio
Re: Spamd sync observations and differences and setup question.
Claudio Jeker wrote: The reject route only triggers for UDP traffic. So carp (which runs inside the kernel) and ospfd (uses a raw socket) are not affected. On the other hand ripd/routed and other tools using multicast over UDP hit that route and when sending all packets are discrded. Thanks for the clarification Claudio! May be a suggestion, a quick addition to man 8 spamd in regards to enable ip multicast on the systems might be welcome. I sure overlook that for sure and looking at the man page again. I see no reference to it. Obviously, I should have thought about it, but just didn't. I assume I wouldn't be the only one going forward either. I prefer to add a specific host route to 127.0.0.1 to let specific multicast traffic through the box. ripd -- as it already plays around with the routing table -- add such a route on startup but I think that's overkill for spamd. Good inside.
Re: Spamd sync observations and differences and setup question.
On Wed, Jun 27, 2007 at 04:05:06PM -0400, Daniel Ouellet wrote: Thanks for the clarification Claudio! May be a suggestion, a quick addition to man 8 spamd in regards to enable ip multicast on the systems might be welcome. I sure overlook that for sure and looking at the man page again. I see no reference to it. Obviously, I should have thought about it, but just didn't. I assume I wouldn't be the only one going forward either. The following example will accept incoming multicast and unicast synchronisation messages, and send outgoing multicast messages through the network interface em0: the reader should suppose that this will only work on machines which enable ip multicast on the systems. and then man -k multicast should get you going... jmc
Re: Spamd sync observations and differences and setup question.
Jason McIntyre wrote: On Wed, Jun 27, 2007 at 04:05:06PM -0400, Daniel Ouellet wrote: Thanks for the clarification Claudio! May be a suggestion, a quick addition to man 8 spamd in regards to enable ip multicast on the systems might be welcome. I sure overlook that for sure and looking at the man page again. I see no reference to it. Obviously, I should have thought about it, but just didn't. I assume I wouldn't be the only one going forward either. The following example will accept incoming multicast and unicast synchronisation messages, and send outgoing multicast messages through the network interface em0: the reader should suppose that this will only work on machines which enable ip multicast on the systems. and then man -k multicast should get you going... Thanks. I sure don't want to make a big deal of anything here. I did read that. Same as in CARP use multicast as well, but in CARP there was reference to enabling additional feature to make it work. Both use multicast. In one cast nothing else was needed to make it work, as Claudio clarify for me earlier, it's done in the kernel for CARP, oppose to here, witch (uses a raw socket). I accept my stupidity here for sure, but it just didn't occur to me as I didn't make the link between multicast use for CARP and multicast use here for spamd-sync that needed something else, specially that I saw in my tests the helo message when I start the spamd-sync, but just couldn't see the sync messages at all. I agree with you, now that I know I can get it going and realize my stupid mistake. I only pointed out that I may not be the only one. I even saw the same question not answered on google before and contacted the person with the same results as well or still not working. http://archives.neohapsis.com/archives/openbsd/2007-05/1102.html So, I did my homework, just a simple hint would have helped me. I simply didn't put 2 and 2 together here. Thanks all and many thanks for your time as well. Best, Daniel
Spamd sync observations and differences and setup question.
Hi, I setup the spamd sync feature between two servers running 4.1 and I observe the following issues with the setup itself. Some setup based on the man page do not work for me anyway and some are not always reliable and some always work. See below. Example Interface facing the Internet: dc0. server1.test.com 1.1.1.2 server2.test.com 1.1.1.3 setup in rc.conf.local that always work. In server 1: spamd_flags=-y dc0 -Y 1.1.1.3 In server 2: spamd_flags=-y dc0 -Y 1.1.1.2 = Setup that mostly work. Meaning if you reboot, it doesn't always start spamd and as far as I can tell, that's because the name resolutions do not work right away when the query is requested, or something like that. This configuration will not always work and be reliable on reboot of servers. However based on the man page, it should. if you do it on the command line it does. Just reboot doesn't always do it. In server 1: spamd_flags=-y dc0 -Y server2.test.com In server 2: spamd_flags=-y dc0 -Y server1.test.com == Setup that I never been able to get to work. I see the message that said the initial communications between the two servers, but never do I see any sync messages exchanged between the two on the multicast channel. Only the initial helo message, but never any updates. In server 1: spamd_flags=-y dc0 -Y dc0 In server 2: spamd_flags=-y dc0 -Y dc0 Setup that I never got to work at all. Not even the initial help message at all. In server 1: spamd_flags=-y server1.test.com -Y server1.test.com -Y server2.test.com In server 2: spamd_flags=-y server2.test.com -Y server1.test.com -Y server2.test.com In theory the man page said that you should be able to do this. I get: spamd: sync init: Device not configured I am still puzzle as to why it also should send the updates to itself here. Meaning -Y server2.test.com when it's configure on server2? It's the one sending the updates, so it already know what it is sending. Anyway, that's what I got. Now in the final setup, I do see the sync messages in the first configuration above, but it's still not clear to me how I can see the results in the /var/db/spamd file, or may be in the pf table spamd-white. I try to add some address to see with spamdb -a 1.2.3.4 on one side and expected it to be added on the second server, but never see it in the spamdb. I don't see it in the pf table spamd-white either. Isn't it suppose to be there some how? Or may be I need to add something in the pf configuration to log it to the spamd-white table when the updates are coming in. That might be it, but the man page say nothing about that. Am I forgetting something here. All this is with brand new 4.1 install. Thanks Daniel
