Hello!
I would like to try it again. Two month ago, when 0.40 was released i
also tried to find someone who is interested in resolving bugs from the
qpsmtpd-prefork - but nobody cares. So i hope this time somebody cares
about it. Cause qpsmtpd-prefork is not usable at all on high load / many
On 2007-08-30 10:08:36 +0200, Peter J. Holzer wrote:
Here are some (measured) resolutions of gettimeofday on various systems:
Linux/i386: 1 ms
Linux/SPARC: 2 ms
HP-UX/PA-RISC: 2 ms
Linux/Alpha: 976 ms (1024 Hz)
Ok, so the Alpha is obsolete, and Sun and HP hardware seems to
On Thu, 2007-08-30 at 10:08 +0200, Peter J. Holzer wrote:
On 2007-08-29 18:36:12 -0400, Guy Hulbert wrote:
[snip]
Just assume that time() can have the granularity of the CPU instruction
counter[1].
It could (if your perl implementation uses 128 bit long doubles), but it
Or you could have
On Thu, 2007-08-30 at 10:45 +0200, Tony L. Svanstrom wrote:
Would this be a bad time to mention that people might get the idea that
they want to run two different setups of qpsmtpd on the same server?
No that's fine. PID is still in there taking care of that.
True, but the code
On 30-Aug-07, at 4:45 AM, Tony L. Svanstrom wrote:
True, but the code makes both the security guy and the programmer
in me
twitch...
Well, don't think of it for security then :-)
The part of the unique ID meant to identify the server is now
focusing on the
OS/computer instead of the
On Thu, 2007-08-30 at 09:14 -0400, Matt Sergeant wrote:
The part of the unique ID meant to identify the server is now
Is this unique ID the transaction ID we've been discussing.
Has someone already implemented it in svn - I thought it was a new
proposal (I'm just a bit confused here) ?
On 30-Aug-07, at 9:34 AM, Guy Hulbert wrote:
On Thu, 2007-08-30 at 09:14 -0400, Matt Sergeant wrote:
The part of the unique ID meant to identify the server is now
Is this unique ID the transaction ID we've been discussing.
Yes.
Has someone already implemented it in svn - I thought it
On Thu, 30 Aug 2007 the voices made Guy Hulbert write:
GH wtf does this mean - the *purpose* of the discussion is to *fix* a
GH *unique* transaction ID when the discussion is over it is *fixed* and
GH the discussion *documents* the implementation.
I meant undocumented as in it in Transaction.pm
On Thu, 2007-08-30 at 10:01 -0400, Matt Sergeant wrote:
That is not true. Random numbers do not give unique results.
True enough. But I'm going out on a limb to assume that it's good
enough for logging. It's not a security feature.
But this (by design[*]) doesn't meet the requirement.
On Thu, 2007-08-30 at 16:07 +0200, Tony L. Svanstrom wrote:
To qpsmtpd the hostname isn't as unique as the IPs + port used by it
is.
But for qpsmptd the hostname is configurable ( config('me') ). As
long as a hash is not used (see my follow-up to Matt) and the function
used is documented,
On 30-Aug-07, at 10:07 AM, Tony L. Svanstrom wrote:
On Thu, 30 Aug 2007 the voices made Guy Hulbert write:
GH wtf does this mean - the *purpose* of the discussion is to *fix* a
GH *unique* transaction ID when the discussion is over it is
*fixed* and
GH the discussion *documents* the
On Thu, 2007-08-30 at 10:30 -0400, Matt Sergeant wrote:
On 30-Aug-07, at 10:07 AM, Tony L. Svanstrom wrote:
On Thu, 30 Aug 2007 the voices made Guy Hulbert write:
[snip]
GH the discussion *documents* the implementation.
I meant undocumented as in it in Transaction.pm currently says
On Aug 26, 2007, at 10:02, Matt Sergeant wrote:
On 25-Aug-07, at 8:37 PM, Guy Hulbert wrote:
The mod_uniqueid module in apache has quite a reasonable
implementation.
There is a perl implementation on CPAN (in my directory).
I'm assuming Ask is referring to
Woah - bikeshedding galore!
I just got my email downloaded to my mac (I'm traveling) and Mail.app
says there are 61 mails in this thread (plus those I deleted
earlier!?!).
Enough already.
If anyone has a serious realistic concern with what Matt did, please
provide a perl implementation
Guy Hulbert wrote:
me = linux1
- linux1__
me = linux2.example.com
- linux2.e
If you run two instances you can call them 'thing1' and 'thing2'.
I'd rather not.
--
JT Moree
On Fri, 2007-08-31 at 00:59 +0800, Ask Bjørn Hansen wrote:
Woah - bikeshedding galore!
I just got my email downloaded to my mac (I'm traveling) and Mail.app
says there are 61 mails in this thread (plus those I deleted
earlier!?!).
Enough already.
There might have been a little less
Ask asked us to stop ... but what the heck ;-).
Perhaps we should drop the list after this one though.
On Thu, 2007-08-30 at 14:19 -0400, Matt Sergeant wrote:
On 30-Aug-07, at 10:57 AM, Guy Hulbert wrote:
Nope. I reject this. The design ASSUMES that the clock has
sufficient
On 30-Aug-07, at 2:52 PM, Guy Hulbert wrote:
Actually, I think the right answer is just a sequence generator (mod
1). That guarantees different consecutive results.
I think so too. In my testing perl only switches to floating point at
or around 2**50 on 32 bit platforms, which should
On 2007-08-29 17:50:28 -0400, Charlie Brady wrote:
A four-tuple identifying the TCP connection also identifies the server.
Right. And the tuple must not be reused for some time (2*MSL or 4 minutes
according to RFC 793), so you don't even need a high resolution timer.
However, what if there is
On 2007-08-30 07:07:51 -0400, Guy Hulbert wrote:
On Thu, 2007-08-30 at 10:08 +0200, Peter J. Holzer wrote:
On 2007-08-29 18:36:12 -0400, Guy Hulbert wrote:
Here are some (measured) resolutions of gettimeofday on various systems:
Linux/i386: 1 ms
Linux/SPARC: 2 ms
Peter J. Holzer wrote on 28.08.2007 23:59:
So, if you have to reconnect anyway, why not explicitely connect in
connect_hook? It won't be slower and it will work with other databases.
Ok, convinced!
So I put check_user in the crypt ;-)
http://dienstleistung-kultur.de/qpsmtpd/
I'm working on a
Raiders is now Twix ;-)
To avoid name collision I renamed my plugin announced in
http://www.nntp.perl.org/group/perl.qpsmtpd/2007/08/msg7128.html
from *check_content_type* to *check_attachment*
See http://dienstleistung-kultur.de/qpsmtpd/
*check_attachment* parses a MIME message into its
On Thu, 30 Aug 2007, Peter J. Holzer wrote:
On 2007-08-29 17:50:28 -0400, Charlie Brady wrote:
A four-tuple identifying the TCP connection also identifies the server.
Right. And the tuple must not be reused for some time (2*MSL or 4 minutes
according to RFC 793), so you don't even need a
Hi,
trying to inherit from a plugin I ran into a problem:
Plugin: /usr/share/qpsmtpd/plugins/extended_rcpt_to
sub init
{
my $self = shift;
print STDERR __PACKAGE__, ::init...\n;
$self-isa_plugin ( rcpt_to );
}
Configure: /etc/qpsmtpd/plugins
...
extended_rcpt_to
Hi Ernesto,
On Fri, Aug 31, 2007 at 04:10:30AM +0200, Ernesto wrote:
trying to inherit from a plugin I ran into a problem:
Plugin: /usr/share/qpsmtpd/plugins/extended_rcpt_to
sub init
{
my $self = shift;
print STDERR __PACKAGE__, ::init...\n;
$self-isa_plugin (
Gavin Carr wrote on 31.08.2007 04:29:
Hi Ernesto,
On Fri, Aug 31, 2007 at 04:10:30AM +0200, Ernesto wrote:
trying to inherit from a plugin I ran into a problem:
Plugin: /usr/share/qpsmtpd/plugins/extended_rcpt_to
sub init
{
my $self = shift;
print STDERR __PACKAGE__,
On Fri, 31 Aug 2007 12:29:00 +1000
Gavin Carr [EMAIL PROTECTED] wrote:
[...]
I think I've seen something similar, which turned out to be a bug
in the 0.40 isa_plugin code not handling multiple plugin_dirs
properly. Patch attached. Not sure if it's your problem but it
smells similar.
Thanks,
Author: hjp
Date: Thu Aug 30 13:18:42 2007
New Revision: 779
Modified:
trunk/lib/Qpsmtpd/Transaction.pm
Log:
fixed assignment (= instead of =).
Modified: trunk/lib/Qpsmtpd/Transaction.pm
==
---
Author: hjp
Date: Thu Aug 30 13:19:30 2007
New Revision: 780
Modified:
trunk/lib/Qpsmtpd/Connection.pm
trunk/qpsmtpd-forkserver
Log:
Connection id similar to the transaction id by Matt.
Modified: trunk/lib/Qpsmtpd/Connection.pm
Author: vetinari
Date: Thu Aug 30 22:26:04 2007
New Revision: 783
Modified:
trunk/lib/Qpsmtpd/Plugin.pm
Log:
Fix Qpsmtpd::Plugins::isa_plugin() with multiple plugin dirs (Gavin Carr)
Modified: trunk/lib/Qpsmtpd/Plugin.pm
30 matches
Mail list logo
