headers
James Turnbull | 1 Oct 2006 03:31
Gravatar

Pollserver & Branches

Hi

Just wondering what the plans were for the pollserver - will the
unstable branch be merged into the 0.3x branch (or vice versa)?

Regards

James Turnbull

--

-- 
James Turnbull <james <at> lovedthanlost.net>
---
Author of Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)

Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
---
PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)
Permalink | Reply | 9 comments |
headers
Ask Bjørn Hansen | 1 Oct 2006 03:50
Gravatar

Re: Pollserver & Branches


On Sep 30, 2006, at 6:31 PM, James Turnbull wrote:

> Just wondering what the plans were for the pollserver - will the
> unstable branch be merged into the 0.3x branch (or vice versa)?

Last we talked about it we were leaning towards moving the pollserver  
back to a branch and put 0.3x back as the trunk.

There are some anecdotal reliability problems with the pollserver and  
not enough people testing it.   Also, it's not entirely clear that  
the added complexity to the plugins are worth it (at least for my  
part it's putting working on it a bit lower on the list).

   - ask

--
http://askask.com/  - http://develooper.com/
Permalink | Reply | 8 comments |
headers
Matt Sergeant | 1 Oct 2006 05:16
Favicon

Re: Pollserver & Branches

On 30-Sep-06, at 9:50 PM, Ask Bjørn Hansen wrote:

> On Sep 30, 2006, at 6:31 PM, James Turnbull wrote:
>
>> Just wondering what the plans were for the pollserver - will the
>> unstable branch be merged into the 0.3x branch (or vice versa)?
>
> Last we talked about it we were leaning towards moving the  
> pollserver back to a branch and put 0.3x back as the trunk.
>
> There are some anecdotal reliability problems with the pollserver  
> and not enough people testing it.   Also, it's not entirely clear  
> that the added complexity to the plugins are worth it (at least for  
> my part it's putting working on it a bit lower on the list).

Does anyone have the tuits to just make this happen? I've grown a  
little tired of hearing that it's the "plan" :-)

I think the stability problems are/were related to perl 5.8.0 on  
linux 2.4, as my other installations are stable as a horse in a barn.

But lets move the trunk back to a branch so we can stop confusing  
people.
Permalink | Reply | 7 comments |
headers
Robert Spier | 1 Oct 2006 22:24
Picon
Favicon
Gravatar

Re: Pollserver & Branches

> 
> I think the stability problems are/were related to perl 5.8.0 on
> linux 2.4, as my other installations are stable as a horse in a barn.
> 
> But lets move the trunk back to a branch so we can stop confusing
> people.

Wait.

Now we're saying that trunk is stable enough on modern platforms?

I know that I was expressing some of the complexity concerns...but if
they can be abstracted out, they're likely worth it from the
scalability department.

-R
Permalink | Reply | 6 comments |
headers
Matt Sergeant | 2 Oct 2006 03:30
Favicon

Re: Pollserver & Branches

On 1-Oct-06, at 4:24 PM, Robert Spier wrote:

>>
>> I think the stability problems are/were related to perl 5.8.0 on
>> linux 2.4, as my other installations are stable as a horse in a barn.
>>
>> But lets move the trunk back to a branch so we can stop confusing
>> people.
>
> Wait.
>
> Now we're saying that trunk is stable enough on modern platforms?

Well I'm guessing. A few of us (3 or more people) have completely  
stable versions of trunk running, so it's either the perl/OS  
combination, or something to do with the plugins I was running. The  
issues I was getting were so weird that I can't imagine them being  
caused by any kind of perl code we have.

But there's always the possibility I did something wrong. I just  
never had the tuits to dig deeply into it.

> I know that I was expressing some of the complexity concerns...but if
> they can be abstracted out, they're likely worth it from the
> scalability department.

The idea was/is that the pollserver was completely abstracted out.  
There's a slight issue in that to be non-blocking plugins need to be  
re-written, but I'm now thinking the best way to do that might be to  
maintain a directory of non-blocking plugins, rather than try and
(Continue reading)

Permalink | Reply | 5 comments |
headers
Leonardo Helman | 2 Oct 2006 22:21
Picon

Apache

Hi, 

I tried the forkserver (had performance issues there), the preforking
plugin (once in a while, I'm loosing packets (still don't find where),
one in a while, the preforking server doesn't answer to the connections
and when it timeouts, it prints 3 o 4 lines with 220's)
and now, I gave a try to the apache module.

I'm wondering how (if) are you setting something like Max connections
from a single IP with the apache modules?.

I have found a module that read this from Scoreboard, but it seems
to be something for apache 1. ?

Are you setting this limits with iptables/similar?

Thanks

Saludos
--  
Leonardo Helman
Pert Consultores
Argentina
Permalink | Reply | 2 comments |
headers
Sydney Bogaert | 2 Oct 2006 23:17
Picon

RE: Apache

> I'm wondering how (if) are you setting something like Max connections
> from a single IP with the apache modules?.
> 
> I have found a module that read this from Scoreboard, but it seems
> to be something for apache 1. ?
> 

It could maybe work with mod_cband ???
http://cband.linux.pl/

Sydney.
Permalink | Reply | 0 comments |
headers
Matt Sergeant | 3 Oct 2006 00:14
Favicon

Re: Apache

On 2-Oct-06, at 4:21 PM, Leonardo Helman wrote:

> I'm wondering how (if) are you setting something like Max connections
> from a single IP with the apache modules?.

http://dominia.org/djao/limitipconn.html

Seems to be the canonical way of doing things.

Matt.
Permalink | Reply | 1 comment |
headers
Brian Szymanski | 3 Oct 2006 03:51
Favicon

restricting auth plugins to SSL *or* TLS

Howdy again qpsmtpd folks...

I want to restrict my auth handlers for plain and login to secure  
(SSL or TLS) connections, so that CRAM-MD5 is the only one that can  
be used with plaintext. However, I'm not sure what the best way to do  
this is. Before I had the tls plugin enabled, I was able to get by  
with this:
sub register {
     my ( $self, $qp ) =  <at> _;
     $self->register_hook("auth-cram-md5", "authuserdb");
     #only make insecure mechanisms available if over SSL or localhost
     if(($ENV{TCPLOCALPORT} == 465) || ($ENV{TCPREMOTEIP} eq  
'127.0.0.1')) {
         $self->register_hook("auth-plain", "authuserdb");
         $self->register_hook("auth-login", "authuserdb");
     }
}

But of course this winds up only offering the "secure" auth plugins  
after starttls, which in my base (with versamail 3.X from a treo 650)  
breaks things, since versamail only does auth plain and auth plain  
only. I tried (naively) to add $self->connection->notes 
('tls_enabled') in to that clause, but of course we don't know  when  
register() is called whether TLS will be enabled later or not.

Now, I could just register plain and login on port 25, but then  
return DENY if tls_enabled isn't in the connection notes, but that  
sucks for a number of reasons:
- A valid client can error out (AFTER shipping its credentials in  
plaintext)
(Continue reading)

Permalink | Reply | 8 comments |
headers
John Peacock | 3 Oct 2006 04:18
Favicon

Re: restricting auth plugins to SSL *or* TLS

Brian Szymanski wrote:
> I want to restrict my auth handlers for plain and login to secure (SSL
> or TLS) connections, so that CRAM-MD5 is the only one that can be used
> with plaintext. 

The recommended way to deal with that is to run branches/0.3x and use the file
config/tls_before_auth config, which (if 0), only displays AUTH *after* tls has
been enabled.  Then you can support whatever AUTH mechanisms you like, in
perfect safety.  The majority of modern MUA's support TLS, so this shouldn't be
a stretch.

The entire AUTH framework, along with the TLS code, is due for a rewrite, but
this really depends strongly on the wind blowing in exactly the correct
direction for sufficient time to allow me time to do it... ;-)

John
Permalink | Reply | 7 comments |

Gmane