On Mon, 2004-11-15 at 19:03, Axel Grupe wrote:
> Hi,
>
> I got performance problems with saslauth daemon. I`m using debian with
> cyrus 2.1.16 and saslauthd 2.1.19 for authentication.
> I test the system with 50 perl-script in the background from another
Can you send me the perl-script off-lis
Hi
For us pam-krb5 (MIT) leaked on redhat 7.3 but was fine on debian 3.0!?
Cheers
Matt
Let's no mislead people. saslauthd does NOT leak memory. Some PAM
modules DO leak, which causes saslauthd to grow as a side effect.
saslauthd works fine with well-written password authenticators
(including s
Zitat von Ken Murchison <[EMAIL PROTECTED]>:
> Let's no mislead people. saslauthd does NOT leak memory. Some PAM
> modules DO leak, which causes saslauthd to grow as a side effect.
> saslauthd works fine with well-written password authenticators
> (including some PAM modules).
Nothing different
Axel Grupe wrote:
[EMAIL PROTECTED] wrote:
Zitat von Axel Grupe <[EMAIL PROTECTED]>:
I'm running Debian Sarge so it's:
saslauthd 2.1.19
Source: pam-mysqlVersion: 0.5.0-6
The System is just in testing mode, so it hasn't been up for a longer time.
But thanks for the tip, I will observe it.
[EMAIL PROTECTED] wrote:
Zitat von Axel Grupe <[EMAIL PROTECTED]>:
I'm running Debian Sarge so it's:
saslauthd 2.1.19
Source: pam-mysqlVersion: 0.5.0-6
The System is just in testing mode, so it hasn't been up for a longer time.
But thanks for the tip, I will observe it.
On Tue, 16 Nov 2004, Axel Grupe wrote:
Igor Brezac wrote:
On Mon, 15 Nov 2004, Axel Grupe wrote:
Hi,
I got performance problems with saslauth daemon. I`m using debian with
cyrus 2.1.16 and saslauthd 2.1.19 for authentication.
The saslauthd is configured to use pam, which itself uses mysql for
pas
Zitat von Axel Grupe <[EMAIL PROTECTED]>:
> I'm running Debian Sarge so it's:
> saslauthd 2.1.19
> Source: pam-mysqlVersion: 0.5.0-6
> The System is just in testing mode, so it hasn't been up for a longer time.
> But thanks for the tip, I will observe it.
Could you send me ([EMAIL PROTECTED])
[EMAIL PROTECTED] wrote:
Zitat von Axel Grupe <[EMAIL PROTECTED]>:
I performed a test for my saslauthd, it makes 1000 authentications
within ~ 6,65 seconds (not bad!), and it still uses pam-> mysql.
If I make the same test with saslauthd using ldap it goes "down" to ~
6,625. In de
Zitat von Axel Grupe <[EMAIL PROTECTED]>:
> I performed a test for my saslauthd, it makes 1000 authentications
> within ~ 6,65 seconds (not bad!), and it still uses pam-> mysql.
> If I make the same test with saslauthd using ldap it goes "down" to ~
> 6,625. In deed these where cached by saslauthd
Igor Brezac wrote:
On Mon, 15 Nov 2004, Axel Grupe wrote:
Hi,
I got performance problems with saslauth daemon. I`m using debian
with cyrus 2.1.16 and saslauthd 2.1.19 for authentication.
The saslauthd is configured to use pam, which itself uses mysql for
password-verification.
I test the system
On Mon, 15 Nov 2004, Axel Grupe wrote:
Hi,
I got performance problems with saslauth daemon. I`m using debian with cyrus
2.1.16 and saslauthd 2.1.19 for authentication.
The saslauthd is configured to use pam, which itself uses mysql for
password-verification.
I test the system with 50 perl-script
* Axel Grupe <[EMAIL PROTECTED]> [041115 12:32]:
> Hi,
>
> I got performance problems with saslauth daemon. I`m using debian with
> cyrus 2.1.16 and saslauthd 2.1.19 for authentication.
> The saslauthd is configured to use pam, which itself uses mysql for
> password-verification.
try auxprop:
On Fri, 10 Jan 2003, Paul M Fleming wrote:
> Personally I have issues with dumping the contents of a password cache
> to a file. Especially in this case, they WILL be stored in cleartext. I
> had planned on keeping somes stats (hits,misses,etc)
Fair enough. Even if you don't dump passwords, it mi
Good point.. I don't have to store the cleartext version in order to do
the compare.. if i save the hash and just hash what the user submits and
compare them that would be sufficient.. just have to keep the cleartext
password long enough to do an actual authentication if need be..
Jeremy Rumpf w
I always hashed the password as soon as they entered the cache. So the
checkpoint dump would contain binary MD5, SHA hashes etc. They're not clear
text per say, but I can see why some would not find even that ideal.
Cheers,
Jeremy
On Friday 10 January 2003 11:07 am, Paul M Fleming wrote:
> Pers
Personally I have issues with dumping the contents of a password cache
to a file. Especially in this case, they WILL be stored in cleartext. I
had planned on keeping somes stats (hits,misses,etc)
Jeremy Rumpf wrote:
>
> > This whole idea sounds great, especially as I'd expect a lot of the
> > au
> This whole idea sounds great, especially as I'd expect a lot of the
> authentication load to come from a small number of users with their
> clients set to check mail every few minutes.
>
> For debugging it would help if there was a way to force a flush of the
> entire cache, and one to dump its c
My current thinking is to use
http://www.ossp.org/pkg/lib/mm/ for the shared memory stuff and
&
http://256.com/sources/table/ for the hash table
I haven't had a chance to look at:
ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/krbdirp-1.2.0.tar.gz
yet
Igor Brezac wrote:
>
> On Thu, 9 Jan 20
On Thu, 9 Jan 2003, Jeremy Rumpf wrote:
>
> On Thursday 09 January 2003 03:55 pm, Paul M Fleming wrote:
> > Timing out the passwords is simple ( I think ) I would store the time
> > when the entry is added and force a reauth if the password has been
> > cached longer than a timeout (for example o
Paul M Fleming wrote:
> Timing out the passwords is simple ( I think ) I would store the time
> when the entry is added and force a reauth if the password has been
> cached longer than a timeout (for example one hour ). That forces a
> reauth at least every timeout period of time. If an entry isn'
On Thursday 09 January 2003 03:55 pm, Paul M Fleming wrote:
> Timing out the passwords is simple ( I think ) I would store the time
> when the entry is added and force a reauth if the password has been
> cached longer than a timeout (for example one hour ). That forces a
> reauth at least every ti
Paul M Fleming wrote:
Timing out the passwords is simple ( I think ) I would store the time
when the entry is added and force a reauth if the password has been
cached longer than a timeout (for example one hour ). That forces a
reauth at least every timeout period of time. If an entry isn't in th
Correct..
John Alton Tamplin wrote:
>
> Paul M Fleming wrote:
>
> >Timing out the passwords is simple ( I think ) I would store the time
> >when the entry is added and force a reauth if the password has been
> >cached longer than a timeout (for example one hour ). That forces a
> >reauth at lea
Timing out the passwords is simple ( I think ) I would store the time
when the entry is added and force a reauth if the password has been
cached longer than a timeout (for example one hour ). That forces a
reauth at least every timeout period of time. If an entry isn't in the
cache (or if it is dif
Related to this thread... I am considering writing a generic cache layer
into saslauthd to lessen the load on the backend auth mechanism. My idea
is to implement a hash table in shared memory and use that to cache the
userid,password etc with a timeout. This should lighten the load ..
Comments? Ide
On Thu, 9 Jan 2003, Rob Siemborski wrote:
> Done.
>
> Someone should sanity-check the documentation I put in LDAP_SASLAUTHD.
>
Looks good.
I do not see when '2. There is no cost to staying bound as a named user'
would be false. Maybe for backends other then ldbm|bdb. It will cause
extra disco
Done.
Someone should sanity-check the documentation I put in LDAP_SASLAUTHD.
-Rob
On Thu, 9 Jan 2003, Igor Brezac wrote:
>
> On Fri, 10 Jan 2003 [EMAIL PROTECTED] wrote:
>
> > On Wed, 1 Jan 2003, Igor Brezac wrote:
> >
> > > On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
> > > [...]
> > > > Can a
On Fri, 10 Jan 2003 [EMAIL PROTECTED] wrote:
> On Wed, 1 Jan 2003, Igor Brezac wrote:
>
> > On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
> > [...]
> > > Can anyone offer advice on tuning the saslauthd pool? Are there particular
> > > options, either on the command line or in saslauthd.conf, which
On Wed, 1 Jan 2003, Kervin L. Pierre wrote:
> Maybe you should seriously consider moving from back-shell to back-perl,
> which you can optimize much more and is probably quicker right of the
> bat, since it does not spawn a separate process for the interpreter.
>
> Better still, have you though
On Wed, 1 Jan 2003, Igor Brezac wrote:
> On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
> [...]
> > Can anyone offer advice on tuning the saslauthd pool? Are there particular
> > options, either on the command line or in saslauthd.conf, which I should
> > be looking at?
>
> Try using 'ldap_auth_met
--On Wednesday, January 01, 2003 9:21 PM -0500 Igor Brezac <[EMAIL PROTECTED]>
wrote:
[...]
If you are on Solaris, I highly recommend the doors IPC method over the
UNIX socket method, since we began to see very bizarre problems under
load.
You might run into problems if you use ldap api and door
On Wed, 1 Jan 2003, Rob Siemborski wrote:
> On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
>
> > Since it's hard to predict peak usage, I'm tempted to run the daemon with
> > the -n0 option so it can spawn as required. However, a colleague has
> > pointed out that if something blows up then spawn-on
[EMAIL PROTECTED] wrote:
directory it's binding to is quite slow (it's actually a slapd instance
running a shell backend which routes bind requests to different places
depending on the usercode - don't ask...). Because saslauthd makes
Maybe you should seriously consider moving from back-shell to
On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
> Since it's hard to predict peak usage, I'm tempted to run the daemon with
> the -n0 option so it can spawn as required. However, a colleague has
> pointed out that if something blows up then spawn-on-demand could kill the
> server - with a fixed-size p
On Wed, 1 Jan 2003 [EMAIL PROTECTED] wrote:
> I've just upgraded to imapd 2.1.11, and while it's going fine so far I'm a
> bit concerned about how it will cope under load when our students return.
>
> The problem is that I'm using the saslauthd native LDAP mechanism, and the
> directory it's bind
35 matches
Mail list logo
