Hi Darko,
A overall ldap schema is always good, especially when defining a ldap
roadmap for james 3.1, 3.2...
At the moment we need more a validation of the ldap functions in trunk.
The last message I saw one [1] doesn't confirm everything is fine.
We also need some schema to download for the ldap, and also some doc
that explains how to setup james with openldap, with the help of Apache
DS studio for example.
I don't think we lack competence in current devs, but everyone is really
busy on the next 3.0 milestone (3.0-M3). for example, I implemented LDAP
access from JAVA in 2001, I have used Apache DS Studio 2 years ago, but
I can't help ldap for james atm.
So if you want to help now, the best if to fix everything in
https://svn.apache.org/repos/asf/james/server/trunk/ldap/ and document
it in
https://svn.apache.org/repos/asf/james/server/trunk/src/site/xdoc/config-users.xml.
Maybe not the most exciting, but a excellent start I find...
The process is to open a JIRA and attach there some patches.
Tks again,
- Eric
[1] http://markmail.org/message/zy55o5xpl6dj35lh
On 7/04/2011 17:38, Darko Hojnik wrote:
Hello Eric,
Do you will need a LDAP Schema? I don't know but the DBmail Schema is
under the GPL v2. My idea for administering Apache James with the Apache
DS backend is, we could use Eclipse with the Apache DS Studio Plugins.
And at last someone has to develop one ore some template plugins for
common administering tasks. Just based on the eclipse plugins for Apache
DS Studio. Maybe james-cli would be available for backward compatibility
only.
So we will need a schema with following entries
Quota
Username
Group
GID
UID
Administrator
Staffadministrator (postmaster@ of a domain)
mailaddress
additional_mail_address
forwarding_mail_address
Antispam
Sieve
active (yes, no)
change_passwd (yes, no)
number_of_addresses (how many adresses could use this user)
max_custumer_adresses
DNSBL (yes no)
DNSBL_URL (exemplary spamhaus.org)
greylist (yes no)
Some stuff from the inetorgperson schema
address, name, division, blah blah......
Optional the mozilla schema for a shared adressbook
And for James 4 could be HUPA be the Groupware :D
best regards
Darko Hojnik
Am 07.04.2011, 16:23 Uhr, schrieb Eric Charles <[email protected]>:
Rereading myself:
"...ease of central..." should be "...advantages of central...".
howto develop on james?
http://james.apache.org/server/3/dev-build.html
where's ldap at james:
https://svn.apache.org/repos/asf/james/server/trunk/ldap/
howto create ldap users (taken from 2.3, needs updates for 3.0)
http://james.apache.org/server/3/config-users.html
Tks,
- Eric
On 7/04/2011 16:16, Eric Charles wrote:
Hi Darko,
Many tks for these information.
I think many of us are also convinced of the ease of central identity
management.
James already embeds derby, jackrabbit, activemq,... so there will be no
problem to embed apache directory as well.
We must think to custom packaging (all-ldap, all-jpa,...) and also on
distributed james (a cluster of servers) where the embedded approach is
no more viable.
Would you be interested to further discuss on the practical way to
implement all this? As you already have experience on embedding apache
ldap, would you be ready to help us?
Tks,
- Eric
On 7/04/2011 15:51, Darko Hojnik wrote:
Hi there,
Well I've thing a night along about it. And I'm asking me now what
other
people will think about to use LDAP as default for managing the Apache
James Server. I think it will need not very much work to embed Apache
Directory. Optionally Administrators could chose another or an existing
directory server like Active Directory from Microsoft. I've needed one
day only to deploy Apache Directory Server as an WAR inside Apache
Tomcat. And in Java I'm still an beginner.
So at all in our modern time a mailserver is just a little part of a
collaboration process inside a Corporate. And LDAP is the standard for
user, permission and identity management about the solutions for
instant
massaging, email, groupware, wiki, documentation management, the
enterprise website, print and fileservices.
Example one:
There is a company exemplary called Weed Pharmacy Inc. There IT uses:
Apache James as an Mailserver
SOGo as part of Webmail and Groupware
Liferay as solution for Websites and even more collaboration in the
inter and intranet
On Liferay is integrated
Apache OfBiz for selling Weed B2B and B2C like ;)
Alfresco for Documentmanagement
These services runs on hundreds of servers in different datacenters
across the world. All users and groups for these services are stored
inside Apache Directory. Apache Directory also regulates with Kerberos
and LDAP the access of the servers themselves. Such access to the
PostgreSQL Servers from the applications and even more
Example two:
There is an ISP exemplary called LOL Cloud Inc.
LOL Cloud Inc. sells Webspace, with email accounts and groupware. The
Apache Vhosts are stored on OpenLDAP. Groupware is SOGo and they uses
Postfix and DBmail with OpenLDAP as an LDAP backend. For exemplary I
describe Postfix, DBmail and SOGo without Vhosts. Just the emailstuff
only
So the LDAP has the DN dc=directory,dc=lol-cloud,dc=com Every
datacenter
is an orgisation unit. A LDIF from one customer could shown like
dn:
[email protected],ou=resellersgroup,ou=customername,o=Accounts,o=mailserver,o=server-42,o=datacenter-2,dc=directory,dc=lol-cloud,dc=com
objectClass: dbmailUser
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Toni Montana
mail: [email protected]
mailAlternateAddress: [email protected]
mailAlternateAddress: [email protected]
mailAlternateAddress: [email protected]
mailAlternateAddress: [email protected]
mailAlternateAddress: [email protected]
mailAlternateAddress: [email protected]
mailAlternateAddress: [email protected]
mailAlternateAddress: [email protected]
mailAlternateAddress: [email protected]
uid: toni_montana
dbmailGID: 10000
dbmailUID: 15654
mailQuota: 1524288000
userPassword::topsecret_md5
I'm using the DBmail Schema for OpenLDAP. As an attachment there is the
OpenLDAP Schema and a LDIF with a Schema for Apache Directory
Server. So
at last LDAP ist the swiss army knife to connect difficulty parts of
services together. Tell me if some more information will be needed.
best regards
Darko Hojnik
Am 07.04.2011, 07:24 Uhr, schrieb Norman Maurer <[email protected]>:
+1
Open JIRA issues is the way to go :)
Bye,
Norman
2011/4/7 Eric Charles <[email protected]>
Sure, we still have some work on the LDAP front :)
Feel free to open some JIRAs, and if you like as information on
how to
contribute on domains,... in LDAP, and we will happily help you.
James' code is really modular and is architectured to easily support
such
features.
Tks again,
- Eric
On 6/04/2011 19:18, Darko Hojnik wrote:
Oh thats bad. First I want deploy Apache James on a little
Multidomain
Server -500 Users. But on larger installations it really will be
needed.
Sorry I don't want start a flamewar now or insult you or another
from
the development team. The work about Apache James is a really great
job!
But without proper support for LDAP I think it will be hard to
integrate
Apache James maybe by an big enterprise or an ISP.
Currently we are using since 2009 DBmail for IMAP and POP3. Because
it's
great to store Mails in Databases and replicate or cluster your
environment of your databaseservers. But in the last time it has
made to
much trouble. So I hope on Apache James. A another solution could be
Zarafa but I suspecting me about there license so I never have tried
it.
best regards
Darko Hojnik
Am 06.04.2011, 18:16 Uhr, schrieb Eric Charles <[email protected]>:
Hi Darko,
James can only store users in ldap (not the domains nor the virtual
users).
There was a recent thread talking about james3 with LDAP
(http://markmail.org/message/uasjeq2f6jgcjj2z).
Mails can of course be stored in PostgreSQL.
Tks,
- Eric
On 5/04/2011 20:10, Darko Hojnik wrote:
Hi there,
Is there an example anywhere how I could configure Apache James
with
LDAP. I want store all virtual domains, users, virtual users and
passwords inside LDAP. Mails should be stored on a PostgreSQL
database.
I want LDAP because I think it's the cleanest way to connect our
Groupware on the Mailserver.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
