|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
M.Kiesel - 07/31/07 04:42 AM
What OpenFire components/source files probably need to get updated in order to implement this? Any caveats?
maybe this could as well add support for 'vhosts'. e.g. 'anonymous.example.org' and 'registered.example.org', so that you can nicely restrict resources for anonymous use etc.
cmer I'm planning on doing a partial implementation of this for the Openfire server we use on http://mugshot.org
 (the same server instance is going to be the backend for the GNOME online desktop work - http://online-desktop.org). I'm not at all confident that the work will be even useful as a starting point for a real implementation ... there are huge amounts of features and subsystems of Openfire that we don't use at all and that I'd have no way of testing even if I had the motivation to try and update them, but I'll post here a patch for what I come up with
As I see it, there are two fairly different things that could be covered by this bug report: A) "server aliases" - the server acts as multiple different domains, but the set of users is the same on all domains I'm only really interested in A) at the moment. My basic plan of attack is to keep the idea that a server has a central master domain, configured as the property, but to add a separate property xmpp.domainAliases which is a list of additional domains that the server thinks it is. There are many places that could conceivably be affected by the change (searching for references to XMPPServerInfo.getName()) but I think you can get a usable amount of functionality going ignoring most of these. Some of the places I do expect to have to change:
Feedback appreciated if the above sounds horribly wrong or misguided. I'm not sure how "server aliases" are supposed to work. What user data exactly is supposed to be shared between aliases? The roster, too? This is likely to cause problems I think: Say someone logs in as user@alias1, adds person@external, then logs out and in again as user@alias2. Then person@external will be in the roster (with presence subscribe=both) but person@external still has user@alias1in the roster - thus, presence will be broken for both users. Of course the server can do alias rewriting but I wouldn't know what the point of aliases is then
 as local (aliased) users only show up under one alias externally then. As I said "I'm not at all confident that the work will be even useful as a starting point for a real implementation"... rosters and, in fact, presence don't really matter for our use case so it's not something I've thought about a lot. But my assumption would be that in general each user would only log in to one alias or the other, and not switch between the aliases. If the user does switch, yes, the roster state will be mildly inconsistent.
You probably could fix things up by say, remembering the JID the user had when they added a roster entry and using that as the 'from' for subsequent <presence/> sent as a result of the roster entry, but whether that is of any use really depends on the use cases people have. It may be that people want and need full virtualization of the user database instead. That isn't conceptually hard, but is certainly not something I'm planning to touch. I'd like to see one instance of the server software able to view users from multiple domains and allow user searrching across those domains.
So user@sistercompany1.com can login to the same server as user@sistercompany2.com even though each company has it's own LDAP server. The two users should be able to do searches and find each other. Ideally this would scale to around 7-10 domains supported. Much of this discussion has been about using the same users on different domains. What I really, really
desperately need is the ability to have virtual hosts where one instance of openfire can server up multiple domains where the users are NOT shared. Otherwise, right now, I have to use some kind of IP proliferation scheme where I map XMPP ports based on the domain name to different internal IPs and different instances of openfire. That is, essentially, unworkable. As much as I like openfire, I'm going to have to switch to something that supports multiple domains via virtual hosts--if such a server exists. Alex, I believe ejabberd has that support for some time now. That was the other choice for me, but at the time, multi-domain support isn't critical to me (yet very desirable!) so I went for OpenFire back then.
Well, I'm stuck. The alternatives are a good solution for me and so I'm going to have to figure out how to run openfire.
...if I had the time I'd write the code! I will join the choir and say that this missing functionality is a blocker.
OpenFire has a very sexy feature set and it is by far the easiest to setup/install/manage (love the admin gui) from all the Jabber Servers i tested but without multi-domain support we can't use it. Jorge, which other server software will you use? We need multi-domain support, even if the other software is more of a pain to configure.
I really need this feature too...
I need to configure subsets of a real world domain of Active Directory like below: domain.local Is there a way to configure it actually? I need it working tomorrow.. hehe This is BY FAR the most votes for feature, yet it is still only marked for "future versions", and not for 3.5 ...
Bart:
To implement this will require very significant changes to the core Openfire code, and is not going to be an easy task. Having the most votes helps Jive determine what the public is interested in, but other factors play into what features actually get implemented. Paying customers tend to have better say, of course. If some community members are willing to start work on the process, Im sure several others will join in, perhaps even with some support from Jive. But this is not a project to be undertaken by a single person. Then make us pay for it. Develop the multi-domain support and add it only to the 'enterprise' version. With so many people wanting it, this would be the ideal way to drive sales of the enterprise Openfire product.
I think the "make us pay for it" argument doesn't really fly here. I'd be willing to bet that the vast majority of administrators who want this feature are "just" users of the free version. I am one of those users. I'd guess that most companies buying Enterprise Edition only really need one domain supported and would much rather their money go to their own pet issues.
I found a way to work around this by using MS ADAM. If you're using Active Directory then check out this link:
http://www.igniterealtime.org/community/docs/DOC-1534 Very cool! Although that's not the same multi-domains that this issue is talking about. This issue is referring to the ability to have a single Openfire server handle something like:
mydomain.org mycompany.com igniterealtime.org ninjas.net etc in other words, more than one XMPP domain at the same time. =) |
|||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Add multi-domain support (Virtual Domains)
