RE: Another performance question
Thank you, this is really helpful information, exactly what I was looking for. The code to my limit "patch" will be posted in that thread. Best regards, Pontus > -Original Message- > From: Miguel Figueiredo [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 18, 2005 1:18 PM > To: 'Slide Users Mailing List' > Subject: RE: Another performance question > > > > Hello, > > We have been using openldap as an authentication server > without any issues > so far (windows distribution). As far as I learned it's a > relatively active > open-source unix project, and you probably should already > know about those > unix-geeks: they are perfectionists: P. > I haven't made any performance tests on the openldap server, > but I feel > confident it should handle quite well, at least comparable > with commercial > implementations. Anyway, it's better than parsing XML > documents (like it is > done by slide) and if the openldap performance isn't good > enough, you can > still migrate to a commercial implementation (good thing about using > standards!). Last remark... OpenLdap is GPL. > > Now, the instructions of slide configuration to take advantage of an > LDAP/Active directory server are already on the slide > documentation, witch > also makes some references to the tomcat documentation pages. > It's all about > org.apache.catalina.realm.JNDIRealm realm on the web container side > (server.xml) and > org.apache.slide.store.txjndi.JNDIPrincipalStore on the > slide webapp (domain.xml). > > Although it has been quite discussed in this mailing list, > I'm attaching my > domain.xml and server.xml as examples. Also, when adding user > info to the > LDAP server, I found quite useful the JExplorer tool. > Finally, this are only > tips from where you can start learning. > > Best Regards, > Miguel Figueiredo > > PS: Is it possible to post your code patches for the 'limit' > feature? Many > Thanks! > > > > > -Original Message- > From: Pontus Strand [mailto:[EMAIL PROTECTED] > Sent: terça-feira, 18 de Janeiro de 2005 11:34 > To: 'Slide Users Mailing List' > Subject: RE: Another performance question > > Hello Miguel, > > Thank you for you response. The problem with LDAP is that > none of us in the > project has worked with LDAP. We will look into it, of course, so any > pointers you may have would be useful to us. For instance, is > OpenLDAP any > good or should we look at a commercial LDAP-server? How > should we setup > Slide to use LDAP? > > Regards, > Pontus > > > -Original Message- > > From: Miguel Figueiredo [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 18, 2005 11:04 AM > > To: 'Slide Users Mailing List' > > Subject: RE: Another performance question > > > > > > > > Hello Pontus, > > > > First of all, many thanks for your performance enquiries > to the slide > > mailing list: I've been consuming them avidly. > > For user aggregation on groups, and group2user or user2group > > traversal for > > authentication/authorization purposes, I would suggest to > publish that > > information in a LDAP or Active Directory servers. These > > kinds of servers > > are optimized for just doing that work and the biggest > > performance cost > > associated with requesting a service to these authentication > > servers, would > > be the establishment of a tcp connection. Hope this helps. > > > > Best regards, > > Miguel Figueiredo > > > > -Original Message- > > From: Pontus Strand [mailto:[EMAIL PROTECTED] > > Sent: terça-feira, 18 de Janeiro de 2005 9:21 > > To: Slide Users Mailing List (E-mail) > > Subject: Another performance question > > > > Hello again, > > > > This time I want to ask about users. Are there any known > > problems with large > > numbers of users and/or groups? And are there any nice > > parameters that we > > should know about that improves user management? We haven't > > tested this yet, > > mostly because the somewhat complex user management in Slide. > > My fear is > > that adding large numbers of users to a group could lead to > > slow user access > > verifications, is that a correct assumption? > > > > Regards, > > Pontus > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another performance question
Hello,
We have been using openldap as an authentication server without any issues
so far (windows distribution). As far as I learned it's a relatively active
open-source unix project, and you probably should already know about those
unix-geeks: they are perfectionists: P.
I haven't made any performance tests on the openldap server, but I feel
confident it should handle quite well, at least comparable with commercial
implementations. Anyway, it's better than parsing XML documents (like it is
done by slide) and if the openldap performance isn't good enough, you can
still migrate to a commercial implementation (good thing about using
standards!). Last remark... OpenLdap is GPL.
Now, the instructions of slide configuration to take advantage of an
LDAP/Active directory server are already on the slide documentation, witch
also makes some references to the tomcat documentation pages. It's all about
org.apache.catalina.realm.JNDIRealm realm on the web container side
(server.xml) and org.apache.slide.store.txjndi.JNDIPrincipalStore on the
slide webapp (domain.xml).
Although it has been quite discussed in this mailing list, I'm attaching my
domain.xml and server.xml as examples. Also, when adding user info to the
LDAP server, I found quite useful the JExplorer tool. Finally, this are only
tips from where you can start learning.
Best Regards,
Miguel Figueiredo
PS: Is it possible to post your code patches for the 'limit' feature? Many
Thanks!
-Original Message-
From: Pontus Strand [mailto:[EMAIL PROTECTED]
Sent: terça-feira, 18 de Janeiro de 2005 11:34
To: 'Slide Users Mailing List'
Subject: RE: Another performance question
Hello Miguel,
Thank you for you response. The problem with LDAP is that none of us in the
project has worked with LDAP. We will look into it, of course, so any
pointers you may have would be useful to us. For instance, is OpenLDAP any
good or should we look at a commercial LDAP-server? How should we setup
Slide to use LDAP?
Regards,
Pontus
> -Original Message-
> From: Miguel Figueiredo [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 18, 2005 11:04 AM
> To: 'Slide Users Mailing List'
> Subject: RE: Another performance question
>
>
>
> Hello Pontus,
>
> First of all, many thanks for your performance enquiries to the slide
> mailing list: I've been consuming them avidly.
> For user aggregation on groups, and group2user or user2group
> traversal for
> authentication/authorization purposes, I would suggest to publish that
> information in a LDAP or Active Directory servers. These
> kinds of servers
> are optimized for just doing that work and the biggest
> performance cost
> associated with requesting a service to these authentication
> servers, would
> be the establishment of a tcp connection. Hope this helps.
>
> Best regards,
> Miguel Figueiredo
>
> -Original Message-
> From: Pontus Strand [mailto:[EMAIL PROTECTED]
> Sent: terça-feira, 18 de Janeiro de 2005 9:21
> To: Slide Users Mailing List (E-mail)
> Subject: Another performance question
>
> Hello again,
>
> This time I want to ask about users. Are there any known
> problems with large
> numbers of users and/or groups? And are there any nice
> parameters that we
> should know about that improves user management? We haven't
> tested this yet,
> mostly because the somewhat complex user management in Slide.
> My fear is
> that adding large numbers of users to a group could lead to
> slow user access
> verifications, is that a correct assumption?
>
> Regards,
> Pontus
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
factory
org.apache.catalina.users.MemoryUserDatabaseFactory
pathname
conf/tomcat-users.xml
ldap://localhost:389";
userPattern="uid={0},ou=people,dc=dominio,dc=pt"
roleBase="ou=groups,dc=dominio,dc=pt"
roleName="cn"
roleSearch="(uniqueMember={0})"
digest="SHA"
roleSubtree="true"
/>
RE: Another performance question
Hello Miguel, Thank you for you response. The problem with LDAP is that none of us in the project has worked with LDAP. We will look into it, of course, so any pointers you may have would be useful to us. For instance, is OpenLDAP any good or should we look at a commercial LDAP-server? How should we setup Slide to use LDAP? Regards, Pontus > -Original Message- > From: Miguel Figueiredo [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 18, 2005 11:04 AM > To: 'Slide Users Mailing List' > Subject: RE: Another performance question > > > > Hello Pontus, > > First of all, many thanks for your performance enquiries to the slide > mailing list: I've been consuming them avidly. > For user aggregation on groups, and group2user or user2group > traversal for > authentication/authorization purposes, I would suggest to publish that > information in a LDAP or Active Directory servers. These > kinds of servers > are optimized for just doing that work and the biggest > performance cost > associated with requesting a service to these authentication > servers, would > be the establishment of a tcp connection. Hope this helps. > > Best regards, > Miguel Figueiredo > > -Original Message- > From: Pontus Strand [mailto:[EMAIL PROTECTED] > Sent: terça-feira, 18 de Janeiro de 2005 9:21 > To: Slide Users Mailing List (E-mail) > Subject: Another performance question > > Hello again, > > This time I want to ask about users. Are there any known > problems with large > numbers of users and/or groups? And are there any nice > parameters that we > should know about that improves user management? We haven't > tested this yet, > mostly because the somewhat complex user management in Slide. > My fear is > that adding large numbers of users to a group could lead to > slow user access > verifications, is that a correct assumption? > > Regards, > Pontus > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another performance question
Hello Pontus, First of all, many thanks for your performance enquiries to the slide mailing list: I've been consuming them avidly. For user aggregation on groups, and group2user or user2group traversal for authentication/authorization purposes, I would suggest to publish that information in a LDAP or Active Directory servers. These kinds of servers are optimized for just doing that work and the biggest performance cost associated with requesting a service to these authentication servers, would be the establishment of a tcp connection. Hope this helps. Best regards, Miguel Figueiredo -Original Message- From: Pontus Strand [mailto:[EMAIL PROTECTED] Sent: terça-feira, 18 de Janeiro de 2005 9:21 To: Slide Users Mailing List (E-mail) Subject: Another performance question Hello again, This time I want to ask about users. Are there any known problems with large numbers of users and/or groups? And are there any nice parameters that we should know about that improves user management? We haven't tested this yet, mostly because the somewhat complex user management in Slide. My fear is that adding large numbers of users to a group could lead to slow user access verifications, is that a correct assumption? Regards, Pontus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
