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
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
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
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
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:
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
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_method:
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 thought of
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 I should
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
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
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 one hour
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 least every
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
--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
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
[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
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 binding
18 matches
Mail list logo
