Community
Participate
Working Groups
Now hear me out on this one. I believe ECF has something out there, but I would like it to be more structured. It would be convenient if there was a XMPP server for all committers / projects. For example, you login the server and you get a Roster with all the projects like this: * Tools * EMF * Ed Merks * Dave Steinberg * ... * GEF * Randy Hudson * ... * Technology * ECF * Scot Lewis * Chris Aniszczyk * ... * ... * Foundation * Wayne Beaton * Denis Roy * TPTP * ... I think you get the point. It would be nice to have a service like this, then again, I'm known to come up with useless ideas. I just think it would be useful to have especially since ECF will be maturing and the ability to know what committers are "on" and be able to share 'workspaces' with committers would be great. It's just organized. Thoughts or am I crazy here?
Not sure if this is the Asterisk server we're planning on running, but we're, uh, planning on running Asterisk. Target is for 2006-Q3. D.
My gosh... can't believe it has been over a year since I opened this. Just to let you know guys, I plan to blog about this on the committer rep blog to see what committers think. After talking to a lot of committers lately, there is a large complaint of being able to find committers and talking to them. For example, one person inside the Modeling project complained that he had to use Skype, AIM, MSN, GTalk just to talk to members of his project. My thought process here is to see if committers agree it would be good to have a foundation wide xmpp server. Part of the process of a committer getting his/her account provisioned would be an XMPP account. I would recommend we use the ECF server currently, ecf.eclipse.org as it already is running ECF's server. Denis, how much of a burden would this be to you if implemented? Do you already have scripts to do account provisioning? I guess we could just use unix accounts or ldap accounts (whatever you use now for accounts)
As an added benefit, it would be nice if committers would use ECF (eat our own dog food) to help with the refinement of the UI and features of the client. Using ECF's client would be optional, there are fantastic XMPP clients out there.
(In reply to comment #2) > My gosh... can't believe it has been over a year since I opened this. > > Just to let you know guys, I plan to blog about this on the committer rep blog > to see what committers think. After talking to a lot of committers lately, > there is a large complaint of being able to find committers and talking to > them. For example, one person inside the Modeling project complained that he > had to use Skype, AIM, MSN, GTalk just to talk to members of his project. > > My thought process here is to see if committers agree it would be good to have > a foundation wide xmpp server. Part of the process of a committer getting > his/her account provisioned would be an XMPP account. > > I would recommend we use the ECF server currently, ecf.eclipse.org as it > already is running ECF's server. > > Denis, how much of a burden would this be to you if implemented? Do you already > have scripts to do account provisioning? I guess we could just use unix > accounts or ldap accounts (whatever you use now for accounts) > As I recall, the issue with this in 2006 was that Denis was hesitant to hookup ecf.eclipse.org to the trusted ldap service (because ecf.eclipse.org was not considered a part of the EF trusted set of servers and/or jive's wildfire not considered a trusted service). Also FYI: Jive has updated the openfire (formerly wildfire) server since then, and I think it's much more 'enterprise ready' (sorry about the buzzwords) although I haven't examined it's current state: http://www.igniterealtime.org/projects/openfire/index.jsp Also, it's my understanding that the new Asterisk server supports XMPP and Jingle, and we are running an asterisk server for ECF dev and testing at ecf2.osuosl.org, but I haven't yet used it enough to answer admin questions about it...Roland Fru (another ECF committer) would be a source of more info about the current state of Asterisk, however. I've added Roland to cc for this bug so he can comment. FWIW, a +2 on the basic idea, however. It seems to me about time. I suggested this at the Board level several times in 2006. I think IRC servers at eclipse.org should be considered in this mix also.
Hi, I fully agree with Chris. There is added value for the community in pooling/pulling ECF committers/contributors together on a simple collaboration platform. Yes, there is currently an asterisk server (latest version 1.4.4 that supports jingle amongst other protocols) running on ecf2.osuosl.org and I would personally be happy to contribute in configuring and making it available for the commnity as suggested by Scott and Chris. The issues from an administration standpoint mainly have to do with user provisioning. Are ECF commiters configured in an available LDAP? We could alternatively sync against an existing user database! Is the grouping (Project - Subproject - Role - UserName) available as well or do we have to model that ourselves? Maybe just start building the user database ourselves and ignoring potential redundancy?! We could either provide a (web) front-end for configuration or simply use the command shell. We talked about this within ECF a while ago and we will all love to "eat our own dog food" by providing suitable front-end for chat, VOIP, conferencing, whiteboarding and collaboration in general :-). Users will, of course, be free to use their favorite clients since we will be using standard protocols. As far as I am concerned, we can move on when we have answers to the admin issues I pointed out. Regards, Roland.(In reply to comment #4) > (In reply to comment #2) > > My gosh... can't believe it has been over a year since I opened this. > > > > Just to let you know guys, I plan to blog about this on the committer rep blog > > to see what committers think. After talking to a lot of committers lately, > > there is a large complaint of being able to find committers and talking to > > them. For example, one person inside the Modeling project complained that he > > had to use Skype, AIM, MSN, GTalk just to talk to members of his project. > > > > My thought process here is to see if committers agree it would be good to have > > a foundation wide xmpp server. Part of the process of a committer getting > > his/her account provisioned would be an XMPP account. > > > > I would recommend we use the ECF server currently, ecf.eclipse.org as it > > already is running ECF's server. > > > > Denis, how much of a burden would this be to you if implemented? Do you already > > have scripts to do account provisioning? I guess we could just use unix > > accounts or ldap accounts (whatever you use now for accounts) > > > > As I recall, the issue with this in 2006 was that Denis was hesitant to hookup > ecf.eclipse.org to the trusted ldap service (because ecf.eclipse.org was not > considered a part of the EF trusted set of servers and/or jive's wildfire not > considered a trusted service). > > Also FYI: > > Jive has updated the openfire (formerly wildfire) server since then, and I > think it's much more 'enterprise ready' (sorry about the buzzwords) although I > haven't examined it's current state: > http://www.igniterealtime.org/projects/openfire/index.jsp > > Also, it's my understanding that the new Asterisk server supports XMPP and > Jingle, and we are running an asterisk server for ECF dev and testing at > ecf2.osuosl.org, but I haven't yet used it enough to answer admin questions > about it...Roland Fru (another ECF committer) would be a source of more info > about the current state of Asterisk, however. I've added Roland to cc for this > bug so he can comment. > > FWIW, a +2 on the basic idea, however. It seems to me about time. I suggested > this at the Board level several times in 2006. > > I think IRC servers at eclipse.org should be considered in this mix also. > (In reply to comment #4) > (In reply to comment #2) > > My gosh... can't believe it has been over a year since I opened this. > > > > Just to let you know guys, I plan to blog about this on the committer rep blog > > to see what committers think. After talking to a lot of committers lately, > > there is a large complaint of being able to find committers and talking to > > them. For example, one person inside the Modeling project complained that he > > had to use Skype, AIM, MSN, GTalk just to talk to members of his project. > > > > My thought process here is to see if committers agree it would be good to have > > a foundation wide xmpp server. Part of the process of a committer getting > > his/her account provisioned would be an XMPP account. > > > > I would recommend we use the ECF server currently, ecf.eclipse.org as it > > already is running ECF's server. > > > > Denis, how much of a burden would this be to you if implemented? Do you already > > have scripts to do account provisioning? I guess we could just use unix > > accounts or ldap accounts (whatever you use now for accounts) > > > > As I recall, the issue with this in 2006 was that Denis was hesitant to hookup > ecf.eclipse.org to the trusted ldap service (because ecf.eclipse.org was not > considered a part of the EF trusted set of servers and/or jive's wildfire not > considered a trusted service). > > Also FYI: > > Jive has updated the openfire (formerly wildfire) server since then, and I > think it's much more 'enterprise ready' (sorry about the buzzwords) although I > haven't examined it's current state: > http://www.igniterealtime.org/projects/openfire/index.jsp > > Also, it's my understanding that the new Asterisk server supports XMPP and > Jingle, and we are running an asterisk server for ECF dev and testing at > ecf2.osuosl.org, but I haven't yet used it enough to answer admin questions > about it...Roland Fru (another ECF committer) would be a source of more info > about the current state of Asterisk, however. I've added Roland to cc for this > bug so he can comment. > > FWIW, a +2 on the basic idea, however. It seems to me about time. I suggested > this at the Board level several times in 2006. > > I think IRC servers at eclipse.org should be considered in this mix also. >
In reply to Scott, if the issue is that it can't be hosted on ecf.eclipse.org, that's fine, we can keep the server and use it. It could be hosted on something like talk.eclipse.org that Denis and co have fine control over. In reply to Roland, I want to go much farther than just the ECF project. If you look at my first comment, I basically want a Foundation run messaging service. I'm working on a blog entry which I'll link back soon.
(In reply to comment #2) > Denis, how much of a burden would this be to you if implemented? Do you already > have scripts to do account provisioning? I guess we could just use unix > accounts or ldap accounts (whatever you use now for accounts) Being totally unfamiliar with the technology, how it works and how to set it up, my wildest guess would be "I dunno." All of us here in the Webmaster office are willing to learn new, cool stuff, though -- but time isn't on our side. If someone can pony up resources to help us set this up, we can certainly look into it sometime in July (we're tapped until then).
Added the blog post: http://eclipse-committer-reps.blogspot.com/2007/04/culture-of-collaboration.html
+1. I've been pushing for this for a long time. Hi Scott. :-)
Jive Software seem to have something to tie Asterisk to their Jabber server but I can't find any details on their website or igniterealtime.com either. I suspect I could throw a rock at their office from ours here, so maybe if one of you knows them I might be able to get a demo of what they're doing or at least get more info on their wildfire/asterisk plugin. Anyway, I just spent about 15 minutes trying to find info on what you get from Jabber/Asterisk integration. Can one of you guys who is familiar with this give us a quick summary of what you think we could achieve with a good setup? I understand setting up a Jabber/XMPP server for the Eclipse community and I can see the advantage in that, but I'm not clear on how it integrates with Asterisk other than having a dial list in your IM client and being able to tell if someone is online or not. Sounds interesting so please give us more detail. :)
(In reply to comment #10) > Anyway, I just spent about 15 minutes trying to find info on what you get from > Jabber/Asterisk integration. Can one of you guys who is familiar with this > give us a quick summary of what you think we could achieve with a good setup? With traditional VOIP, you get a softphone that looks and behaves like, well, a telephone. Needless to say, while a telephone is a nice simple and minimal interface for talking with someone, it's not very user friendly either. Skype (I believe) was the first to recognize that building VOIP into an IM client would (a) add tremendous value to IM clients, and (b) finally put a nice user-friendly interface on a VOIP client. Integrating Jabber and Asterisk would give us similar functionality to Skype, but on a 100% open source platform. If anyone from Skype is reading this, I like your client. I use it literally every day. But I'd greatly prefer an open-source, hackable client I can easily integrate into plain old telephone service (POTS) networks how I like in ways you didn't imagine.
Ah so basically because the Jabber server doesn't support voice you use Asterisk to handle the voice via SIP and Jabber to handle the text chat/online status. So from what I can tell the only thing you really get from Jabber is the ability to easily see if someone is online or not without calling them first. SIP already supports text messaging and if we were to setup Asterisk extensions for interested committers like 'committername@eclipse.org' and put up a DNS SRV record for IAX and SIP pointing at our asterisk server, then we would get most of the benefits, no?
BTW I'm not committing to doing that, just using that example setup for discussion. :)
Denis (who will be interested in scalability) will probably be interested in: http://www.voip-info.org/wiki/view/OpenPBX.org%20FAQ
(In reply to comment #12) > Ah so basically because the Jabber server doesn't support voice you use > Asterisk to handle the voice via SIP and Jabber to handle the text chat/online > status. So from what I can tell the only thing you really get from Jabber is > the ability to easily see if someone is online or not without calling them > first. SIP already supports text messaging and if we were to setup Asterisk > extensions for interested committers like 'committername@eclipse.org' and put > up a DNS SRV record for IAX and SIP pointing at our asterisk server, then we > would get most of the benefits, no? Hmmm. Here's another question for Denis: SIP can be a bear to get through firewalls. IAX is downright trivial (only one incoming UDP port on the server side needs to be opened). On the client side, even with stun server support, SIP simply can't get through some firewalls. I've been able to get my clients to talk through the most draconian corporate firewall implementations with IAX with zero configuration on my part. If we stick with SIP, maybe we can do what you're talking about. I think part of the motivation of marrying SIP and Jabber is because that's how Jingle (Google Talk) works. But I'm guessing now. Anyway, Denis will have lots of fun with this. I'm jealous.
So a little catching up for me...sorry this wasn't sent sooner. Karl...we can easily get meeting/demo/support from Jive for wildfire server. The Asterisk extension for the Smack API is for presence/awareness of Asterisk call state. Smack 3.0.0 is adding/has added support for Jingle (Google Talk signaling protocol proposed as extension to XMPP: Jingle Info: http://en.wikipedia.org/wiki/Jingle_(protocol) The recent Jive Openfire server supports Jingle directly (i.e. you can use it for both IM and Jingle-based telephony): http://www.igniterealtime.org/projects/openfire/index.jsp There is an ECF google summer of code project to implement our telephony call API with Jingle protocol (we'll be using Jive Smack 3.0.0 API). http://wiki.eclipse.org/index.php/VoIP_via_the_ECF_Call_API_and_the_Jingle_Protocol We've also recently implemented the call API with Skype: http://wiki.eclipse.org/index.php/Skype_Provider Roland Fru (ECF committer) has been/is working on the ECF call API via IAX (Asterisk) and SIP. Now, it really gets messy :). Asterisk has been working on dev versions supporting Jingle and XMPP, and they have a working version but I don't know what shape it's in. It's running at ecf2.osuosl.org if we want to play with it. Ideally, I think we would like to run an Asterisk server at eclipse.org, and have it support all three of: SIP 2, Jingle/Google Talk, and IAX for maximum client choice (hw/softphones/etc). Further, with luck ECF will have support for all three of these signaling protocols (enough to initiate/receive calls if not all features) and can/would have some Eclipse/RCP integrated clients as well (like our Skype Provider). IMHO the optimal combination from an open source/open systems point of view is XMPP + Jingle with ECF-based and other clients. But alas Jingle is not as mature as SIP, and there are no 'Jingle phones' like there are for SIP. IAX is an excellent protocol as well and IAX + XMPP integrated with asterisk may also be a good combination. Finally, the Google folks have said they intend to create a Jingle<->SIP bridge, but I don't think this exists yet. So although I think it would be great if telephony and IM/messaging were all provided with one open server, I'm not sure if that's available right now. As Dave points out in #14, I've heard openpbx also is a good alternative (relative to Asterisk), but I've not worked with it directly myself.
(In reply to comment #14) > Denis (who will be interested in scalability) will probably be interested in: > > http://www.voip-info.org/wiki/view/OpenPBX.org%20FAQ > "Yes, indeed, Asterisk doesn't scale." "SIP can be a bear to get through firewalls." Great. Just what we need, a winning combination! ;-)
How about we just focus on getting an XMPP server up and not worry about the SIP/VOIP stuff. For me, just being able to chat with someone is important. Setting up an XMPP server for the Foundation should be trivial compared to the voice stuff (maybe something that happens in the future, I'd like to start simple). Are people in agreement? Scott, do you have more info on Wildfire and if it connects to LDAP?
(In reply to comment #18) > How about we just focus on getting an XMPP server up and not worry about the > SIP/VOIP stuff. For me, just being able to chat with someone is important. I agree. This is doable and useful, even if not 'optimal'. > > Setting up an XMPP server for the Foundation should be trivial compared to the > voice stuff (maybe something that happens in the future, I'd like to start > simple). > > Are people in agreement? Scott, do you have more info on Wildfire and if it > connects to LDAP? Wildfire/Openfire does support LDAP (now...I don't think it did in the version ECF is running now). Openfire docs: http://www.igniterealtime.org/projects/openfire/documentation.jsp LDAP guide: http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/ldap-guide.html and Karl if you want to get together and visit/talk with the Jive folks LMK.
(In reply to comment #18) > How about we just focus on getting an XMPP server up and not worry about the > SIP/VOIP stuff. For me, just being able to chat with someone is important. +1 I wouldn't see it any other way. We can add more functionality as we go along.
(In reply to comment #18) > How about we just focus on getting an XMPP server up and not worry about the > SIP/VOIP stuff. For me, just being able to chat with someone is important. +1
Adding Moritz Post (Google SOC student working on Jingle impl) to cc.
(In reply to comment #18) > How about we just focus on getting an XMPP server up and not worry about the > SIP/VOIP stuff. For me, just being able to chat with someone is important. > > Setting up an XMPP server for the Foundation should be trivial compared to the > voice stuff (maybe something that happens in the future, I'd like to start > simple). +1
One last thought regarding SIP vs. IAX. (This doesn't change my vote to defer VOIP until after we get XMPP in place) IAX is easier to administer. But for an organization like Eclipse, SIP will scale much better. Here's why: IAX always has to route through the PBX server. It's really designed for a business where most folks are in an office working off of the office LAN, and a few remote workers need to connect into this infrastructure with the least hassle possible. But for Eclipse, this means that the Asterisk (or OpenPBX) box would have to route all VOIP traffic. Not a good situation for an organization the size of Eclipse. SIP, on the other hand, prefers to use the central server as a directory service, and then set up the actual voice channel point-to-point between whoever is talking. So for two-way calls, this would eliminate 99% of the traffic from going through the Eclipse.org servers. For conferences, we would still need a central server. Another advantage of SIP is that Eclipse.org could peer with other SIP services like GizmoProject Ekiga.net, and FreeWorldDialup, which would greatly enhance the usefulness of the service due to Metcalfe's Law. Just some more thoughts to throw into the mix.
(In reply to comment #24) > IAX always has to route through the PBX server. It's really designed for a > business where most folks are in an office working off of the office LAN, and a > few remote workers need to connect into this infrastructure with the least > hassle possible. But for Eclipse, this means that the Asterisk (or OpenPBX) > box would have to route all VOIP traffic. Not a good situation for an > organization the size of Eclipse. I agree... I don't see it scaling well to 800+ committers and with conferencing on the same server as well. And yes SIP is hard to get working through firewalls or even basic NAT routers like we use in the Portland and Ottawa offices. But it supports peer-to-peer. > > SIP, on the other hand, prefers to use the central server as a directory > service, and then set up the actual voice channel point-to-point between > whoever is talking. So for two-way calls, this would eliminate 99% of the > traffic from going through the Eclipse.org servers. For conferences, we would > still need a central server. For the conference server we are building we intend to use IAX and SIP both. IAX is so much easier to handle that it will likely be the choice for most conferencers.
One problem we will encounter is that all of the high-quality low bitrate voice codecs are patent-encumbered... This has a bad effect in that invariably conferences wind up with audible (sometimes really bad) artifacts in the audio due to conversions between encoding formats. One colleage told me it sounded like talking to me with R2D2 whistling and hooting in the background. :-) It would be awfully cool if someone in the Eclipse community (maybe some of the C/embedded guys) who actually know about some of this stuff could design us a clean-room low-bitrate unencumbered voice codec... I bet we've got someone around who could do this sort of thing in his or her sleep if they wanted too. ;-)
Don't confuse Denis with voice crap, let's just keep it simple with an XMPP server :) OpenFire is located here: http://www.igniterealtime.org/downloads/index.jsp#openfire Is there an issue with using GPL software as infrastructure for Eclipse? If not, would those wonderful OpenFire guys be so kind to donate a commercial license for their enterprise edition (http://www.jivesoftware.com/products/openfire/) which looks like it has VOIP support. Scott, any ideas here?
(In reply to comment #27) > Don't confuse Denis with voice crap, let's just keep it simple with an XMPP > server :) .... > their enterprise edition > (http://www.jivesoftware.com/products/openfire/) which looks like it has VOIP > support. Man, I'm really confused now! Denis? :-P
lol Dave, I know, I'm a flip-flopper ;p I just noticed that the enterprise had that voice support ;)
(In reply to comment #27) > Don't confuse Denis with voice crap, let's just keep it simple with an XMPP > server :) > > OpenFire is located here: > http://www.igniterealtime.org/downloads/index.jsp#openfire > > Is there an issue with using GPL software as infrastructure for Eclipse? Openfire is under Apache 2 I believe. So I don't think this is an issue for this package at least. Were you asking in general or just WRT Openfire? >If > not, would those wonderful OpenFire guys be so kind to donate a commercial > license for their enterprise edition > (http://www.jivesoftware.com/products/openfire/) which looks like it has VOIP > support. > > Scott, any ideas here? Yesterday (5/10/2007) I and Karl met with Jive's Matt Tucker (CTO) and Dawn ?...developer relations). They are keen on the Eclipse Foundation using the Openfire server, and perhaps other of Jive's OS offerings/products if found to be helpful given Foundation's setup. We also asked them a number of questions about scaling characteristics of Openfire, talked about VOIP support, integration questions, etc. I'll let Karl and Denis report here on their perspective about technical suitability. The Openfire server has IM/chat capability built in, and there are add ons for Jingle support and perhaps SIP support in the near future. The VOIP stuff is new, however, and is just being deployed commercially, so they haven't done a lot of tuning/don't have a lot of experience with scaling it yet (although architecturally it scales well). They are also working with standards and vendors to get full interoperability with (e.g.) Google Talk (Google Talk doesn't support Jingle as specified in XEP yet). So I think that we should continue forward with getting another Openfire server going, integrated with committer user db (via LDAP), and see what happens WRT Openfire support of VOIP. The VOIP stuff doesn't have to be installed/used and we can maybe try it out on ECF's Openfire server (as we need to run it anyway to support/test a Google SOC project). The main issue (according to Karl/Denis) is one of Foundation IT resources and timing. Everyone is focused on preparing for/supporting Europa. Openfire is not difficult to install/administer (I do so poorly here http://ecf.eclipse.org:9090), but I understand that there is some IT work involved in the LDAP/user authentication integration.
Scott, thanks for setting that up. The Jive people were super nice and willing to help out. Sounds like a good product and with them a stone's throw from our offce in Portland getting any needed help should be easy enough. We'll need to talk amongst ourselves on the IT staff and decide if/when it's something we think we can do and support.
I appreciate the "let's focus on XMPP, and not on voice crap" focus, but you lost me when you brought up: - voice crap - voice crap - more voice crap - this voice crap is cool - I wonder if this voice crap is scalable Sorry to sound like a manager type here, but a) this bug requests XMPP support for committers, so let's use this bug to focus on that and that alone, and b) as for VOIP goes, I'd like to have a better picture of what the requirements are in a separate bug so that we have a chance of closing this one as FIXED. Please? :-)
done Denis, this bug should only focus on getting the XMPP support setup. Voice talk can be in bug 188379
Denis, after Europa and many beers and days of relaxtion, is it possible to try to get this going? I would be and I'm sure Scott would be willing to help out in anyway.
How's life after Europa, webmasters :)?
To set up easily such a server, you could use a Gmail hosted account. It's free, and there is nothing to configure. It sure means less fun though (and adding manually people).
So here's what I'm reading in this proposal: 1. Get commitments from volunteer sysops for this software (similar to the way Planet is run) 2. Get a copy of OpenFire from JiveSoftware http://www.jivesoftware.com/products/openfire/index.jsp 3. Install this on a Foundation machine, not a virtual server 4. Volunteer sysops and Foundation webmasters cooperate to write an authentication plug-in that uses the Foundation LDAP and committer databases to produce the correct data structures for OpenFire 5. Beta roll it out to certain projects to see how it's working 6. Etc. Again, the key points are: 1. Runs on Foundation servers - keeps the login and password secret 2. Is sysop'd by volunteers from the committer population - the webmasters can't scale to implement this yet (we have to work on reducing our overhead first, e.g., bug 198541).
yap, looks good Bjorn. I don't think there will be a problem with volunteers. I'm sure the ECF people will help out. #4 I think is tricky... how do we do the mapping and authentication to the Foundation LDAP? Scott also mentioned that the OpenFire guys were friendly, maybe he can chime in about that.
(In reply to comment #37) > So here's what I'm reading in this proposal: > 1. Get commitments from volunteer sysops for this software > (similar to the way Planet is run) Planet and XMPP have one large difference: Planet does not require user authentication, so delegating admin is virtually risk-free. In this case, I don't see how we can allow volunteers to sysop the service without allowing them to see every committer username and password we have. If only for writing an auth plugin, we can simply set up a staging area where, like the portal, the plugin authors can code against sample infrastructure to be deployed by webmasters. However, the portal is currently managed by webmasters for security reasons, as it deals with user authentication. > 3. Install this on a Foundation machine, not a virtual server This can live on a vserver if only the webmaster has access to it. Otherwise, it doesn't really matter. FWIW, if we need a physical server for this, then there's a blocker in that I don't have budget for a machine and additional rack space for the 2007 budget. > 1. Runs on Foundation servers - keeps the login and password secret > 2. Is sysop'd by volunteers from the committer population - the webmasters > can't scale to implement this yet (we have to work on reducing our > overhead first, e.g., bug 198541). Again, I don't see how these can be mutually exclusive.
(In reply to comment #39) > > 1. Runs on Foundation servers - keeps the login and password secret > > 2. Is sysop'd by volunteers from the committer population - the webmasters > > can't scale to implement this yet (we have to work on reducing our > > overhead first, e.g., bug 198541). > > Again, I don't see how these can be mutually exclusive. > Perhaps we could implement an LDAP middle-class like you have done for DB access? This would necessarily put us on the hook for administering the machine on which it is hosted, but we could perhaps then offload the maintenance/support of the application, which is probably 2/3 of the work?
(In reply to comment #40) > Perhaps we could implement an LDAP middle-class like you have done for DB > access? I'm not fully aware of what the typical XMPP sysop tasks are, but what scares me is the idea that a non-webmaster has write access to code that manipulates committer/user credentials in real-time. Although I trust our committers, unauthorized access never happens willfully, usually never happens by someone with good intentions and is almost always extremely destructive (or disruptive). The recent EPIC security breach can be used as an example of the risks behind shared/volunteer sysop'ing: http://dev.eclipse.org/mhonarc/lists/phoenix-epic-dev/msg00248.html EPIC has no ties to the Foundation LDAP committer accounts, so the inflicted damage was fairly limited (although it could have been worse). Committer accounts have local shell access and write access to CVS and downloads, and compromised committer accounts can always lead to root.
Denis has a point. Maybe there needs to be no outside intervention... it can be all automatic. Similar to the way portal.eclipse.org works... when I log into portal.eclipse.org... it knows what categories/projects I'm already in... eclipse.pde technology.ecf technology.phoenix tools.orbit etc... This could be applied to how the groups are organized or created when accounts are provisioned.
As per comment 40, I think the best approach would be to put in a little effort to setup LDAP-based authentication and as per comment 42 have committer account provisioning include a set of associated XMPP chat rooms and buddy lists based upon their associated categories/projects. I'm willing to participate in any necessary dev for LDAP-based authentication, but as per Denis' comments about shared sys-admin I don't think it makes sense for me or other committers to actually administer the XMPP server. I think, however, that the administrative load would generally be pretty light however, if the auth is done with existing LDAP, and buddy lists, chat rooms, are provisioned at committer provisioning time. At least this covers the administration I've been doing with ecf.eclipse.org (at obviously a much smaller scale, however). Would it be possible to make further progress on this?
Assumption 1: the point of an XMPP server is to have a way to collaborate. Assumption 2: it would be nice to know who everyone is and in what project(s) they live/work. Assumption 3: the need for VoIP is infrequent; the need for text-based chatting is much more frequent/useful Fact 1: IRC already allows for text-based public and private collaboration, and it's free. Fact 2: new tech brings new overhead, new issues, new headaches, new security concerns (registration/authentication) Fact 3: wiki.eclipse.org/IRC/WhosWho would be a no-cost way of posting who people are w.r.t. their IRC nicknames, and which projects they are associated with, which channels they hang out in, headshots, links to their blogs, etc. Fact 4: ad hoc VoIP can be done as adhoc peer-to-peer chats w/ Skype; larger conf calls can be done with Asterisk I guess my point is why do we need another solution to a problem which appears to already be solved? As an alternative to Fact 3 above, there's been talk about adding more committer metadata to the Foundation's database (bug 197728). If this was to include IRC/Skype/Yahoo/MSN/gtalk contact info, we could generate a webpage with a Who's Who of committers by project, name, or nick and use it as a sortable lookup table for when you're looking to contact someone via IM/IRC. I know there's a wow factor in having an XMPP server... but wouldn't it be even more wow! if all committers started idling in #eclipse-dev? ;-)
(In reply to comment #44) <stuff deleted> > > I guess my point is why do we need another solution to a problem which appears > to already be solved? I don't want this to turn into an IRC vs. XMPP battle...I think both are useful technologies and am a heavy user of both. There are reasons to use XMPP, however, as IRC doesn't support (e.g.) grouped buddy lists, 'real' authentication (i.e. via eclipse.org login), a route to integrated voip, more consumer popularity, more commercial/biz support, for example. OTOH, IRC does have other advantages...e.g. more public OS clients, some features that XMPP chat is not very good at, and there are of course existing dev communities at freenode, etc. At least from my point of view, there is utility to having the foundation provide either XMPP and/or IRC services/services to committers...for associated buddy lists, chat/collaboration groups, and for the integration-with-other-services (e.g. bugzilla, newsgroups, wiki, etc) that would then be available. So in any event, I would personally be in favor of adding an enhancement request to run a foundation IRC server also, but I suspect that the push back will be that there would not be sufficient admin to manage/monitor multiple chat/messaging services.
(In reply to comment #45) > At least from my point of view, there is utility to having the foundation > provide either XMPP and/or IRC services/services to committers...for associated > buddy lists, chat/collaboration groups, and for the > integration-with-other-services (e.g. bugzilla, newsgroups, wiki, etc) that > would then be available. I think this is nice in that we'd be able to contact anyone with ease although there's the disadvantage of lowered transparency since we are talking amongst ourselves instead of through public channels. > So in any event, I would personally be in favor of adding an enhancement > request to run a foundation IRC server also, but I suspect that the push back > will be that there would not be sufficient admin to manage/monitor multiple > chat/messaging services. Even if we had enough admin I would not support the motion of adding a "foundation IRC server". As aforementioned in comment #45, we have a strong community on IRC (although it could be better, see Nick's comment 44 *hint, hint*) and I would be against having the community all move to another server. The fact of the matter is that not everyone's going to move and then the common knowledge pool drops significantly because the same questions are getting asked on both channels and people have to answer them twice. Now if we're talking about an IRC server just for committers, that's even more pointless in my opinion and I think we should just do the XMPP thing instead if that was what was implied.
(In reply to comment #46) <stuff deleted> > > Now if we're talking about an IRC server just for committers, that's even more > pointless in my opinion and I think we should just do the XMPP thing instead if > that was what was implied. > Although I disagree about the value of a IRC server for committers/projects/members, it's immaterial to this bug IMHO...the point being that an XMPP/IM service for projects/committers/community members (this bug) is a useful *addition* to the service provided by IRC, no matter where it's hosted. Also BTW, there are member companies that (by policy) restrict access to IRC for security reasons. Not rational IMHO, but still a problem.
no IRC server, just an XMPP one. IRC is common place in open-source already on irc.freenode.net and Eclipse has a presence. This has been a common complaint from anyone outside of a large nameless company that wants to interact with people from various projects.
I now work inside a large nameless company (that shall remain nameless for the time being) and my only hope of having *any* chat with folks outside the firewall is through XMPP. IRC is most definitely a non-starter. IT here is *very* serious about staying in control and if you cross them or end-around them, they can (and will) make life severely miserable for you.
(In reply to comment #49) > I now work inside a large nameless company (that shall remain nameless for the > time being) and my only hope of having *any* chat with folks outside the > firewall is through XMPP. IRC is most definitely a non-starter. IT here is > *very* serious about staying in control and if you cross them or end-around > them, they can (and will) make life severely miserable for you. > I know Dave is not alone in this, unfortunately. I don't see why we shouldn't have IRC (at freenode or wherever IRCers are established/most comfortable) and XMPP...for committers as per this bug?
Checking in...is there something the community can do to help with this bug?
(In reply to comment #51) > Checking in...is there something the community can do to help with this bug? > Is there any change/word on this bug? FWIW, ECF now has some basic shared editing, remote osgi services and other collaboration capabilities that work peer-to-peer over XMPP. This can/could support processes (e.g.) like public or private code walkthroughs/reviews...as desired by individual project teams and communities.
Scott and I talked about this bug today and came up with the following action items: 1. Scott will talk to Jive about OpenFire 2. Scott will look at OpenFire to see whether the following authentication mechanism would work 3. Bjorn will continue to work with Gabe and Karl towards having a behind-the-firewall web-api for authenticating committers: pass it a login and password, it returns a pass/fail and a token. The login could be a committer account or a bugzilla email address. This is the same code that we will be using for the portal code. 4. Bjorn will work with webmaster to determine the feasibility of having a virtual server for xmpp.eclipse.org that will be sysadmin'd by a restricted set of volunteers. The volunteers will all have to sign some new legal papers covering the fact they understand the privacy implications of their work.
(In reply to comment #53) > Scott and I talked about this bug today and came up with the following action > items: > 1. Scott will talk to Jive about OpenFire > 2. Scott will look at OpenFire to see whether the following authentication > mechanism would work > 3. Bjorn will continue to work with Gabe and Karl towards having a > behind-the-firewall web-api for authenticating committers: pass it a login and > password, it returns a pass/fail and a token. The login could be a committer > account or a bugzilla email address. This is the same code that we will be > using for the portal code. > 4. Bjorn will work with webmaster to determine the feasibility of having a > virtual server for xmpp.eclipse.org that will be sysadmin'd by a restricted set > of volunteers. The volunteers will all have to sign some new legal papers > covering the fact they understand the privacy implications of their work. I would suggest the following modification to this: 3. Users who need authentication are redirected to a Foundation-hosted server where they give their credentials and are then given a login token (cookie). They are handed back off to the source site via a redirect, and the source site validates the cookie using a web-api call back to the same Foundation-hosted authentication server. This prevents the client systems from ever having the user's credentials.
(In reply to comment #54) > (In reply to comment #53) > > Scott and I talked about this bug today and came up with the following action > > items: > > 1. Scott will talk to Jive about OpenFire > > 2. Scott will look at OpenFire to see whether the following authentication > > mechanism would work > > 3. Bjorn will continue to work with Gabe and Karl towards having a > > behind-the-firewall web-api for authenticating committers: pass it a login and > > password, it returns a pass/fail and a token. The login could be a committer > > account or a bugzilla email address. This is the same code that we will be > > using for the portal code. > > 4. Bjorn will work with webmaster to determine the feasibility of having a > > virtual server for xmpp.eclipse.org that will be sysadmin'd by a restricted set > > of volunteers. The volunteers will all have to sign some new legal papers > > covering the fact they understand the privacy implications of their work. > > I would suggest the following modification to this: > > 3. Users who need authentication are redirected to a Foundation-hosted server > where they give their credentials and are then given a login token (cookie). > They are handed back off to the source site via a redirect, and the source site > validates the cookie using a web-api call back to the same Foundation-hosted > authentication server. This prevents the client systems from ever having the > user's credentials. > In re-reading my own reply I see that this last sentence switches terminology and might be confusing. So "client systems" == "source systems" == "XMPP server" == "Any other non-Foundation service" for purposes of this comment.
(In reply to comment #54) > 3. Users who need authentication are redirected to a Foundation-hosted server > where they give their credentials and are then given a login token (cookie). > They are handed back off to the source site via a redirect, and the source site > validates the cookie using a web-api call back to the same Foundation-hosted > authentication server. This prevents the client systems from ever having the > user's credentials. > This is a great idea, Karl, and that was the intention of the Friends of Eclipse site login. It authenticates against Bugzilla and resturns an *.eclipse.org global cookie. All that would be missing is API to validate the cookie. https://dev.eclipse.org/site_login/ The site login above also properly identifies committer status.
(In reply to comment #56) > This is a great idea, Karl, and that was the intention of the Friends of > Eclipse site login. It authenticates against Bugzilla and resturns an > *.eclipse.org global cookie. All that would be missing is API to validate the > cookie. > > https://dev.eclipse.org/site_login/ > > The site login above also properly identifies committer status. :) thanks! Well if we wanted to integrate Friends functionality it would be trivial to add to the web-api callback a field to validate whether or not the user is an FoE (haha). What about calling it like login.eclipse.org?
(In reply to comment #54) > 3. Users who need authentication are redirected to a Foundation-hosted server > where they give their credentials and are then given a login token (cookie). Except that people don't always use a website to login to an XMPP server :-| For example, Google Talk or ECF.
(In reply to comment #58) > (In reply to comment #54) > > 3. Users who need authentication are redirected to a Foundation-hosted server > > where they give their credentials and are then given a login token (cookie). > > Except that people don't always use a website to login to an XMPP server :-| > For example, Google Talk or ECF. > Right...there is the problem that people will be using/want to use non-web clients for accessing XMPP/XMPPS (e.g. ECF, GAIM, iChat, etc)...and for these clients there will be no way to add code to implement a purely web-based authentication scheme. So these clients will need to send username/password info to the OpenFire server (we can, should, and will disable non-ssl-based access to prevent sending cleartext). But as per Bjorn's comment #53, I'm verifying that the OpenFire server can/will/does allow pluggable authentication...and that will allow us to insert authentication that uses this mechanism.
Does ECF support XEP-0051 (XMPP redirects)?
(In reply to comment #60) > Does ECF support XEP-0051 (XMPP redirects)? > Hi Karl. Our current ECF provider is implemented by the Smack 2.2.1 library, and the honest answer is I don't know whether Smack 2.2.1 supports xep 51 redirects. A quick look through the source shows no reference to the obvious search targets (51, xep, etc), so at this point I kind of doubt it. I will ask the authors (Jive), however. Further, there is a more recent version of Smack that may also have it...I will ask the authors about that as well. As last resort, we could implement it ourselves, but that would be work at least I haven't budgeted for so far.
Thanks for looking into it, Scott.
(In reply to comment #62) > Thanks for looking into it, Scott. > I heard back from Matt Tucker at Jive...Smack does not yet support xep 51 (even in 3.0.4 it seems). So, if we must use it, we would have to add that support by adding a IQ and/or packet extension to the org.jivesoftware.smack bundle that we (ECF) build to support our provider.
After some examination, I think the openfire server can be configured to use the Foundation's committer login infrastructure, perhaps with some development (that I am willing to contribute to, if desired/necessary). Here are the openfire custom database integration guide: http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/db-integration-guide.html If the described org.jivesoftware.openfire.auth.JDBCAuthProvider and org.jivesoftware.openfire.user.JDBCUserProvider and org.jivesoftware.openfire.group.JDBCGroupProvider do not provide sufficient access to the new EF authentication mechanisms, then I'm quite certain these classes can/could be substituted with new classes of our own construction: http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/javadoc/ See (e.g.) o.j.o.auth, o.j.o.user, and o.j.o.group I don't know the new EF authentication mechanisms to say, however...will use of Jive's JDBC or LDAP providers work? Or will a custom provider be necessary?
Any comments from the EF team about authentication via OpenFire server as per comment #64? FWIW, with the 2.0.0 release ECF has shared editing capabilities...that can support use cases such as remote code walkthroughs and pair programming. With this bug addressed, these services would be automatically available to all committers. Also, as per bug #235884 ECF will be engaging in an effort to create an Equinox-based XMPP server...possibly by refactoring OpenFire code. Work on implementing EF authentication could be coordinated with this effort. Finally, an XMPP server on Equinox running at EF could be an excellent example for the new top-level runtime project.
Scott, I need more policy information about how we want to handle this but I think it's a no-go if you can't offload authentication. But I can't say that definitively so I need to find out.
(In reply to comment #66) > Scott, I need more policy information about how we want to handle this but I > think it's a no-go if you can't offload authentication. But I can't say that > definitively so I need to find out. > Not sure what you mean by 'offload authentication'. OpenFire plugins can implement EF custom authentication mechanisms...and then use EF authentication for access to OpenFire-based services. Is this what you mean by offload?
I think what he's asking if you could use something like LDAP as the authentication mechanism. I think the goal would be to hook in maybe your bugzilla id or portal id to this server.
(In reply to comment #68) > I think what he's asking if you could use something like LDAP as the > authentication mechanism. I think the goal would be to hook in maybe your > bugzilla id or portal id to this server. > As per the info in comment #64, OpenFire can use LDAP (already developed by Jive), or some custom developed authentication mechanism (would have to be developed by someone with knowledge of EF authentication). So this is technically doable, as long as OpenFire runs on some machine behind firewall (I'm assuming that such services are only open to machines behind firewall).
Sorry, I'm still referring to the problems raised in comment 39 and comment 40.
(In reply to comment #70) > Sorry, I'm still referring to the problems raised in comment 39 and comment 40. > Isn't there some way to get past this? By my count, this bug has ~30 votes...more than any of the top voted new bugs currently listed on bugs.eclipse.org. (I don't understand why it's not actually listed there, but that's a separate question). If admin for OpenFire server cannot be delegated/contributed securely (i.e. the thrust of comment #39), then why not have admin of an OpenFire server done by Eclipse Foundation admin? If additional/reallocated admin implies changes to Board-authorized resources then why can't/don't the EMO and/or committer Board reps take this as a specific resource resource request to the Board? Otherwise, it seems that this request (and the need expressed behind it...the need for better/more committer-to-committer communication through the use of IT technology)...simply won't be addressed.
(In reply to comment #71) > If admin for OpenFire server cannot be delegated/contributed securely (i.e. the > thrust of comment #39), then why not have admin of an OpenFire server done by > Eclipse Foundation admin? That is definitely the way we want to handle services that require authentication from our LDAP and/or Bugzilla databases. But having my team admin Yet Another Service brings on the next challenge, which you have brought up: > If additional/reallocated admin implies changes to Board-authorized resources > then why can't/don't the EMO and/or committer Board reps take this as a > specific resource resource request to the Board? At this point, my team has a total headcount of three, so every new service we add spreads us even thinner to the point where we need to neglect something (that Blogs site we set up is quite sad, to name just one). I think I'm also suffering from the Once Bitten Twice Shy effect. Karl spent a fortune in time in setting up an Asterisk server that was supposed to accomplish great things. It turned out being a very costly experiment. I'm not opposed to experimenting, and I think the ECF collaboration tools are really, really cool, but I don't have a dozen sysadmins.... At this point, I agree that escalating this to the Committer Board Reps is a good idea. I'll post a message to their newsgroup in a bit to ask for their input.
(In reply to comment #72) <stuff deleted> > > If additional/reallocated admin implies changes to Board-authorized resources > > then why can't/don't the EMO and/or committer Board reps take this as a > > specific resource resource request to the Board? > > At this point, my team has a total headcount of three, so every new service we > add spreads us even thinner to the point where we need to neglect something > (that Blogs site we set up is quite sad, to name just one). OK, so I guess my suggestion was prescient: get some more resources (this isn't directed to Karl or Denis so much as to EMO and Board representatives...particularly the committer Board representatives. I'm sympathetic about IT resources...I understand that you are continuously squeezed (as are others in other ways). But why is this the case? > > I think I'm also suffering from the Once Bitten Twice Shy effect. Karl spent a > fortune in time in setting up an Asterisk server that was supposed to > accomplish great things. It turned out being a very costly experiment. I'm not > opposed to experimenting, and I think the ECF collaboration tools are really, > really cool, but I don't have a dozen sysadmins.... I would like to get something straight here. This is *not* about promoting ECF. It's about responding to a committer need (for greater/better/more modern communication between committers). An XMPP server for committers can/would be used by lots of people who didn't use ECF (i.e. other clients...e.g. GAIM, etc). ECF has some added value that people can/could use, certainly, but I think the 30 votes (and what others have been saying about the need for greater cross-project...aka committer...collaboration) is clear enough indication of what the real need is here. http://eclipse-committer-reps.blogspot.com/2007/04/culture-of-collaboration.html > > At this point, I agree that escalating this to the Committer Board Reps is a > good idea. I'll post a message to their newsgroup in a bit to ask for their > input. > Yes, thanks. Hopefully they are already engaged via this bug.
I am +1 this and I know other committer reps have voice interest. You can use any client that supports XMPP to access this which is pretty much every modern client. The key thing here is having a way for committers to easily communicate and collaborate with each other. I would hope that administration would be fairly hands off once the part is figured out on how to do the authentication + xmpp group creation.
cc'ng the rest of the reps
I'm a chat window junkie so I'm all for making communication easier...
+1 from me, also for the chat benefits. I'm not interested in VOIP. Even Skype sucks from my office.
For what it's worth, I use VOIP (skype) from at home and the quality is almost always excellent.
(In reply to comment #72) > I think I'm also suffering from the Once Bitten Twice Shy effect. What's the definition of "a fortune"? :-) Four comments: 1. Asterisk was my idea and it turned out to be a failed idea: people (including the Foundation staff) just didn't use it. I can list other ideas of mine that have failed just as I can list other ideas that have succeeded. As a wise man once said: "being 100% is just as bad as 0% because it shows that you're not trying hard enough". 2. XMPP is about committer/community collaboration. It's not an ECF thing any more than CVS is a Platform thing. 3. How about if use bugzilla authentication instead of committer authentication? We can still map bugzilla accounts to committer accounts and projects, but we wouldn't be exposing committer accounts and passwords to the volunteer sysops? 4. The goal here is to find a low overhead way to increase the services to the community. "Have Denis do it" is not low overhead. So we're working through design options for something that is "low overhead"...
(In reply to comment #79) > 3. How about if use bugzilla authentication instead of committer > authentication? We can still map bugzilla accounts to committer accounts and > projects, but we wouldn't be exposing committer accounts and passwords to the > volunteer sysops? I'm guessing the "map" verb you use refers to connections to our internal database. Regardless, it would appear that only I (and possibly Matt and Karl) see a risk in this, even with lowly Bugzilla authentication, so the risk is either unfounded, or we know something ya'll don't. So sure, Bugzilla authentication it is. Worst case, if something explodes, we can just shut it down and restore the last known good copy from backup. I think it's safe to say that our collective IT hands are tied until Ganymede has shipped, but after that we can assist the volunteer sysadmins in doing the authentication routines. Just so everyone knows, asking a sysadmin to delegate authentication to a system they don't own/manage is a big deal. It's like asking a lawyer to give you a straight answer.
(In reply to comment #80) > (In reply to comment #79) > I'm guessing the "map" verb you use refers to connections to our internal > database. I was just hypothesizing something like a web-api that the XMPP server calls to authenticate a login and password. The web-api checks that the login is a bugzilla login and the password matches, and then it looks up the bugzilla login in the foundation email to find the matching committer record (if there is one), and then returns "yes, valid, and here are the projects that person belongs to". > I think it's safe to say that our collective IT hands are tied until Ganymede > has shipped, ... I agree.
Removed by droy 2008-07-01 22:13 - SPAM
Much as I would like to get more highly spiritual and self-sufficient, and hilarious as find mistranslations do I, do we have a policy for blocking spam posts on bugs.ecipse.org? I think that this is the first spam of this sort that I've seen, and I'm wondering if we should be sending mail to webmaster or have a bug for collecting them and blocking when necessary. One nice thing about having a bug is that it could have its own security group so that all CC'd could post to it (e.g. if an email that wasn't really spam were accidentally blocked).
(In reply to comment #83) > do we have a policy for blocking spam posts on bugs.ecipse.org? Sending an email to webmaster works for me.
The two issues that were causing me some concern were: - authentication and security thereof - overhead for IT I like Bjorn's idea of using Bugzilla authentication. I propose provisioning a vserver and give Scott root access for the initial setup. Once the server is ready to be connected to the auth source, we'll revoke root privileges, and allow the volunteers to perform the work in shared screens with a webmaster. Maintenance requiring root and/or access to the auth sources will be performed using the shared screen with a webmaster. Scott, if this works for you, please let me know what you suggest for the vserver's hostname (xmpp.eclipse.org?) and also what ports you need opened on our firewall.
(In reply to comment #85) > Scott, if this works for you, please let me know what you suggest for the > vserver's hostname (xmpp.eclipse.org?) and also what ports you need opened on > our firewall. I'm willing to help out on this one too with Scott to get this moving.
(In reply to comment #85) > The two issues that were causing me some concern were: > > - authentication and security thereof > - overhead for IT > > I like Bjorn's idea of using Bugzilla authentication. I propose provisioning a > vserver and give Scott root access for the initial setup. Once the server is > ready to be connected to the auth source, we'll revoke root privileges, and > allow the volunteers to perform the work in shared screens with a webmaster. > > Maintenance requiring root and/or access to the auth sources will be performed > using the shared screen with a webmaster. > > Scott, if this works for you, please let me know what you suggest for the > vserver's hostname (xmpp.eclipse.org?) and also what ports you need opened on > our firewall. > Hi Denis, +1 for xmpp.eclipse.org (not sure if others have other opinions, but this seems reasonable to me) RE: ports...the two standard xmpp ports are: xmpp: 5222 xmpps: 5223 OpenFire also has a http/web admin (authenticated access) at port 9090 (by default). There is a db...it can be a small, internal one setup by OpenFire, or it can be mysql. Usually running localhost behind firewall. I'm not sure how this will work with the foundation's external authentication method though. I am willing to do the root access for install/config, etc, but I'm taking some time off with family starting this friday (18) and am pretty bound up this week with other things, so I won't be able to work on it immediately. If others (the most excellent zx and/or others) do have some bandwidth for it over next several weeks then I'm happy to have them persue it, and I'll jump in after end of July.
(In reply to comment #87) > +1 for xmpp.eclipse.org (not sure if others have other opinions, but this seems > reasonable to me) Sounds good to me, too. > OpenFire also has a http/web admin (authenticated access) at port 9090 (by Should be fine. > default). There is a db...it can be a small, internal one setup by OpenFire, > or it can be mysql. Usually running localhost behind firewall. I'm not sure > how this will work with the foundation's external authentication method though. I suggest we put the DB on another server like pebbles to free up resources on the vserver? Denis, your call, of course.
The XMPP vserver has been setup and I've sent the details to Scott. -M.
(In reply to comment #89) > The XMPP vserver has been setup and I've sent the details to Scott. Thanks guys!
(In reply to comment #90) > (In reply to comment #89) > > The XMPP vserver has been setup and I've sent the details to Scott. > > Thanks guys! > I browsed through the thread, is there any particular reason that eclipse has to host this? XMPP servers are publically available already. Just look at http://www.jabber.org/im-services for a list of free servers? There is even one for allowing traffic to communicate of port 80. Most companies are starting to block access to IM servers anyways.
(In reply to comment #91) > (In reply to comment #90) > > (In reply to comment #89) > > > The XMPP vserver has been setup and I've sent the details to Scott. > > > > Thanks guys! > > > > I browsed through the thread, is there any particular reason that eclipse has > to host this? XMPP servers are publically available already. Just look at > http://www.jabber.org/im-services for a list of free servers? In my view, there are some important reasons for EF hosting: 1) make it possible to have committers/contributors use existing logins rather than yet another login. ECF has been running an XMPP server at ecf.eclipse.org for about 3+ years now, and can/do add accounts for committers/contributors upon request. Of course, few know about it, and even fewer actually go to the trouble of requesting a login (at ecf-dev at eclipse.org incidently)...at least partially because it's another login id/password combination to remember, etc. 2) Integration with other EF services. With a foundation xmpp server, project-specific buddy lists, chat rooms, and other things can be created as part of the project-creation process, eliminating the burden of creation and maintenance on PMC/project leads/project team members. Also, other services (e.g. IM notification of build events, etc) can be integrated. 3) Buddy lists/presence organized by EF project....which results in easier/quicker IM access to eclipse project team members, who are distributed across space, organizations, and companies. If there are n servers out there being used, with no guarantee that those servers can/will interoperate (many xmpp servers do, but many don't), then it will make it much harder for EF project teams to communicate/collaborate...with each other and their respective communities. >There is even > one for allowing traffic to communicate of port 80. Most companies are > starting to block access to IM servers anyways. Is this true? Seems completely wrong-headed to me...especially for software companies, but I suppose not any more wrong headed than I've seen before.
(In reply to comment #91) > I browsed through the thread, is there any particular reason that eclipse has > to host this? In addition to the reasons Scott outlined, there is also the Eclipse Terms of Use that allows projects to use the conversations on the XMPP channels directly in their projects' code without having to go through a CQ. Hosting the XMPP server elsewhere would not provide us (Eclipse) with the same confidence in IP cleanliness.
(In reply to comment #93) > (In reply to comment #91) > > I browsed through the thread, is there any particular reason that eclipse has > > to host this? > > In addition to the reasons Scott outlined, there is also the Eclipse Terms of > Use that allows projects to use the conversations on the XMPP channels directly > in their projects' code without having to go through a CQ. Hosting the XMPP > server elsewhere would not provide us (Eclipse) with the same confidence in IP > cleanliness. > While I think some of these are valid reasons, will the XMPP server broadcast to other XMPP servers in the network. One of the nice things about XMPP servers is that you can communicate across the networks and use any server in the network to talk. I would hope that the XMPP server provided by eclipse wouldn't limit this ability, after all communication should be in the open, otherwise we just have a private channel. How is IRC handled under the Eclipse IP, since people are using that to collaborate now? Is it because there are logs of the conversations that can be tracked to prove the IP in the public channels? It seems that using a public server that already exists would fall under the same banner as the Eclipse IRC channels. (In reply to comment #92) > > > (In reply to comment #89) > > 1) make it possible to have committers/contributors use existing logins rather > than yet another login. ECF has been running an XMPP server at ecf.eclipse.org > for about 3+ years now, and can/do add accounts for committers/contributors > upon request. Of course, few know about it, and even fewer actually go to the > trouble of requesting a login (at ecf-dev at eclipse.org incidently)...at least > partially because it's another login id/password combination to remember, etc. The only concern I have hear is that depending on which username and password is used, I may to keep changing it. If it's bugzilla that is fine, I could live with that. If the concern is having to remember multiple passwords, why not just use a sight that has OpenID so that you can have one signon regardless of where you go. http://www.jabber.org/node/344 A separate topic, might be to have eclipse support OpenID for single signon and authentication. > 2) Integration with other EF services. With a foundation xmpp servers, > project-specific buddy lists, chat rooms, and other things can be created as > part of the project-creation process, eliminating the burden of creation and > maintenance on PMC/project leads/project team members. Also, other services > (e.g. IM notification of build events, etc) can be integrated. If they are broadcasted to other XMPP servers, then it doesn't matter which server is used. Most of what you talk about can be handled by clients and doesn't necessarily require a server to host it. You can integrate build events independent of which XMPP server is used, all the build system needs is an XMPP id at one of the servers to send out the notification. Luntbuild has had this built in for years. > > 3) Buddy lists/presence organized by EF project....which results in > easier/quicker IM access to eclipse project team members, who are distributed > across space, organizations, and companies. If there are n servers out there > being used, with no guarantee that those servers can/will interoperate (many > xmpp servers do, but many don't), then it will make it much harder for EF > project teams to communicate/collaborate...with each other and their respective > communities. Again if the XMPP server is broadcasting across the network, you get this automatically, if it's locked and a private server then I don't see the benefit of it being put up as eclipse communication shouldn't be private for IP reasons I would assume. > > >There is even > > one for allowing traffic to communicate of port 80. Most companies are > > starting to block access to IM servers anyways. > > Is this true? Seems completely wrong-headed to me...especially for software > companies, but I suppose not any more wrong headed than I've seen before. > Yep this is becomming very common. I tried to get a bunch of people to go the IM route, and it was very difficult to find a network client that wasn't blocked. A lot of companies are blocking external communication because of IP concerns and trade secrete concerns. Yahoo, MSN, and Google Talk all have been blocked at some point. To get around this issue, the following Jabber is available: https://www.xmpp.net/tags/jabber jabber80.ath.cx Admin SvenBorkert Components Group Chat: Multi-User Chat as defined in JEP-0045 User Directory: A searchable directory of users AIM Transport: Users can register for gateway communications to AIM ICQ Transport: Users can register for gateway communications to ICQ MSN Transport: Users can register for gateway communications to MSN Features SSL Connections: Old-style SSL on a separate port for secure client connections Website Description Jabber Server accepting connections on standard ports and port 80 and 443 to be reachable through any http proxy.
Hi Dave, (In reply to comment #94) > (In reply to comment #93) > > (In reply to comment #91) > > > I browsed through the thread, is there any particular reason that eclipse has > > > to host this? > > > > In addition to the reasons Scott outlined, there is also the Eclipse Terms of > > Use that allows projects to use the conversations on the XMPP channels directly > > in their projects' code without having to go through a CQ. Hosting the XMPP > > server elsewhere would not provide us (Eclipse) with the same confidence in IP > > cleanliness. > > > > While I think some of these are valid reasons, will the XMPP server broadcast > to other XMPP servers in the network. One of the nice things about XMPP > servers is that you can communicate across the networks and use any server in > the network to talk. Not all xmpp servers are configured to support this server-to-server communication, but I'm quite certain that the Wildfire server can be configured to do this. Further, I don't think that all the services provided by an xmpp server (e.g. presence/buddy lists, chat, auth, chat groups, etc., etc) are actually broadcast among all appropriately configured xmpp servers. >I would hope that the XMPP server provided by eclipse > wouldn't limit this ability, after all communication should be in the open, > otherwise we just have a private channel. Agreed. > > How is IRC handled under the Eclipse IP, since people are using that to > collaborate now? Is it because there are logs of the conversations that can > be tracked to prove the IP in the public channels? I don't know...Bjorn will have to answer this. > > It seems that using a public server that already exists would fall under the > same banner as the Eclipse IRC channels. > > <stuff deleted> > > The only concern I have hear is that depending on which username and password > is used, I may to keep changing it. If it's bugzilla that is fine, I could > live with that. That's the plan currently, I believe (have people use bugzilla logins...not CVS logins). >If the concern is having to remember multiple passwords, why > not just use a sight that has OpenID so that you can have one signon regardless > of where you go. AFAIK the current bugzilla authentication is not using OpenID, so having one more (whether openid or not) is less desirable. > > http://www.jabber.org/node/344 > > A separate topic, might be to have eclipse support OpenID for single signon and > authentication. True, this is a separate topic (and possibly a bigger one). > > > > 2) Integration with other EF services. With a foundation xmpp servers, > > project-specific buddy lists, chat rooms, and other things can be created as > > part of the project-creation process, eliminating the burden of creation and > > maintenance on PMC/project leads/project team members. Also, other services > > (e.g. IM notification of build events, etc) can be integrated. > > If they are broadcasted to other XMPP servers, then it doesn't matter which > server is used. I don't think this is strictly true. With the xmpp server running on EF hw and open source server (e.g. Wildfire), we would be able to extend the wildfire server software as desired...providing some more capabilities for integration that are available via inter-server communication. >Most of what you talk about can be handled by clients and > doesn't necessarily require a server to host it. True for some things, but some integration with the server(s) themselves is still useful. >You can integrate build > events independent of which XMPP server is used, all the build system needs is > an XMPP id at one of the servers to send out the notification. Luntbuild has > had this built in for years. True, this can be client based, but there are limits to this...in any event, it's not particularly worthy of debate...I believe you are are right that some things can be done with clients and I'm right that some things are better (and more securely) done with server integration. > > > > > > 3) Buddy lists/presence organized by EF project....which results in > > easier/quicker IM access to eclipse project team members, who are distributed > > across space, organizations, and companies. If there are n servers out there > > being used, with no guarantee that those servers can/will interoperate (many > > xmpp servers do, but many don't), then it will make it much harder for EF > > project teams to communicate/collaborate...with each other and their respective > > communities. > > Again if the XMPP server is broadcasting across the network, you get this > automatically, >if it's locked and a private server then I don't see the benefit > of it being put up as eclipse communication shouldn't be private for IP reasons > I would assume. I don't see it as necessary to be a locked/private server. It may be that the provisioning of projects/buddy list groups/chat rooms, etc. would be limited to some/a few EF administrators...so we don't have a bunch of groups for non-existent EF projects. > > > > > > > >There is even > > > one for allowing traffic to communicate of port 80. Most companies are > > > starting to block access to IM servers anyways. > > > > Is this true? Seems completely wrong-headed to me...especially for software > > companies, but I suppose not any more wrong headed than I've seen before. > > > > Yep this is becomming very common. I tried to get a bunch of people to go the > IM route, and it was very difficult to find a network client that wasn't > blocked. A lot of companies are blocking external communication because of IP > concerns and trade secrete concerns. Yahoo, MSN, and Google Talk all have > been blocked at some point. That's unfortunate...but I would hope that EF member companies would at least consider finding a way for their committers to participate (e.g. xmpp proxy, outgoing/client access to xmpp ports, etc). If the companies that block outgoing/client access to public xmpp won't allow access to EF xmpp, then I pity their committers, but I don't see that problem as solvable by those of us not working for those companies. In any event, I don't think this should block the rest of us from communicating :).
(In reply to comment #94) > How is IRC handled under the Eclipse IP, since people are using that to > collaborate now? Is it because there are logs of the conversations that can > be tracked to prove the IP in the public channels? Any IP that comes from a non-committer must go through the IP process. Having the Terms of Use helps move the IP through the IP process.
(In reply to comment #96) > (In reply to comment #94) > > How is IRC handled under the Eclipse IP, since people are using that to > > collaborate now? Is it because there are logs of the conversations that can > > be tracked to prove the IP in the public channels? > > Any IP that comes from a non-committer must go through the IP process. Having > the Terms of Use helps move the IP through the IP process. > Agreed and understood, but that didn't answer the question, How is IRC handled since it is hosted on Freenode and not on any of the Eclipse Foundation servers? Is there a special agreement with Freenode?
(In reply to comment #97) > Agreed and understood, but that didn't answer the question, I did answer the question: any IP that comes into Eclipse projects must go through the IP process. Thus IP that comes in through IRC must go through the IP process. I'm not sure how much simpler I can make that statement.
(In reply to comment #98) > (In reply to comment #97) > > Agreed and understood, but that didn't answer the question, > > I did answer the question: any IP that comes into Eclipse projects must go > through the IP process. Thus IP that comes in through IRC must go through the > IP process. I'm not sure how much simpler I can make that statement. > Okay, so effectively than...the point about having an XMPP server at eclipse will help with IP, isn't that relevant, because anything that is discussed still has to go through IP. Terms of Use could be extended to any (In reply to comment #93) > (In reply to comment #91) > > I browsed through the thread, is there any particular reason that eclipse has > > to host this? > > In addition to the reasons Scott outlined, there is also the Eclipse Terms of > Use that allows projects to use the conversations on the XMPP channels directly > in their projects' code without having to go through a CQ. Hosting the XMPP > server elsewhere would not provide us (Eclipse) with the same confidence in IP > cleanliness. If items still need to go through IP review, then unless I'm totaly missing this point, the terms of use could be extended to any conversation that happens on any XMPP or IM service such as IRC. Since IRC is not hosted at eclipse, it would just require extending the terms of use to cover other IM networks with conversations between committers. Honestly, I'm not trying to be difficult here, just trying to understand the reasoning for the need to have it hosted at Eclipse. Scott has some good points in some of the benefits that a XMPP server at eclipse will provide. I did a search for IRC terms of use at eclipse, and the only terms of use I have found is for the Website.
(In reply to comment #99) > If items still need to go through IP review, then unless I'm totaly missing > this point, the terms of use could be extended to any conversation that happens > on any XMPP or IM service such as IRC. Since IRC is not hosted at eclipse, it > would just require extending the terms of use to cover other IM networks with > conversations between committers. Maybe I can help clarify: The terms of use he's talking about are the terms of use for the Eclipse hosting infrastructure: ie: http://www.eclipse.org/legal/termsofuse.php The part in question is under subheading "Licenses". Basically, it says that if you post anything on an Eclipse.org web site, it is automatically licensed under the EPL. This is done so that anything you post is then free for a Committer to incorporate into any part of Eclipse he or she chooses. This license, by definition, can't apply to a web site or server that Eclipse.org does not own. Just like Eclipse.org can't write a terms-of-use contract that is binding when you are browsing Microsoft.com, it also cannot write a license that is binding when you are using FreeNode. In that case, you are bound by whatever license FreeNode has that lets you use their server(s). IANAL, so YMMV; just have dealt with lawyers a lot, including sitting on the Eclipse Board's Legal Committee way back... If a lawyer is reading and I've got any part wrong, please correct, etc. > Honestly, I'm not trying to be difficult here, just trying to understand the > reasoning for the need to have it hosted at Eclipse. No problem. It was clear to me that you weren't trying to be difficult, :-) Thanks for asking.
Progress report: Openfire xmpp server is now installed, configured, and running at xmpp.eclipse.org. It currently has test accounts. Today (8/12/2008) slewis and zx conferenced with Denis, Matt, and Karl about XMPP authentication based upon EF foundation dbs. Notes a) Authentication will be against bugzilla account b) To *start*, only committers will be authenticated c) XMPP groups (for buddy lists) will use EF-projects as groups (~90 unique projects) d) Openfire has ability to use LDAP for authentication and user and group info. Here is the Openfire LDAP guide: http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/ldap-guide.html See "Manually Editing the Config File" for information about expected LDAP properties...i.e. user names, group names, admin name, etc. Next steps i) Create a script to query bugzilla and other EF dbs to get all the LDAP properties consumed by XMPP (see the openfire LDAP docs above). This script will then be used to initialize and update the xmppLDAP server (below). This script will be created/tested by the crack Foundation IT staff, since they know where the relevant EF data sources are, know how to access the EF db fields via scripts, and have access to run/test. They will request support if they need more info than is provided by Openfire docs about the expected LDAP properties, or if they need to consult about the appropriate mapping between EF projects and XMPP groups (or any other expected LDAP properties). ii) Setup and initialize(using data generated by i) a *new* xmppLDAP server running on xmpp.eclipse.org. iii) Configure Openfire server to use the xmppLDAP server for authentication iv) Test xmppLDAP-based authentication and buddy list initialization, Debug vi) Make announcement of availability on committer's mailing lists and elsewhere.
> ii) Setup and initialize(using data generated by i) a *new* xmppLDAP server > running on xmpp.eclipse.org. If you're not comfortable doing this, we can do it for you. Otherwise, please use OpenLDAP, and set the rdn to dc=eclipse,dc=org 'User' accounts will have the following dn: uid=droy,ou=people,dc=eclipse,dc=org Groups' will have the following dn: cn=technology.phoenix,ou=group,dc=eclipse,dc=org
From comment 101, i) and ii) are done. I have written a script that intersects committer accounts in LDAP with Bugzilla passwords and Foundation project information for groups into one nifty LDIF. This LDIF is transferred over and imported into xmpp.eclipse.org's local LDAP server every weekday at noon ET. The base DN is dc=eclipse,dc=org Both Matt and I were able to bind to the directory successfully using our bz email/password combo. Here is how the LDAP client on Jive should be configured, as per the document you referred to in comment 101: * ldap.host : localhost * ldap.port : leave the default 389. * ldap.baseDN : ou=People,dc=eclipse,dc=org * ldap.adminDN and ldap.adminPassword : Let's not set these. I am convinced that Jive does not need to bind to the directory as the Admin. * ldap.usernameField : leave the default value of uid. * ldap.nameField : leave the default value of cn. * ldap.emailField : leave the default value of mail * ldap.searchFields : We may want to set this as "BugsMail/uid". * ldap.searchFilter : nothing Group Settings * ldap.groupNameField : leave default value of cn. * ldap.groupMemberField : leave the default value of member. * ldap.groupDescriptionField : leave the default value of description * ldap.posixMode : leave false. Users are stored in groups using their DN. * ldap.groupSearchFilter : leave default If you need assistance configuring/debugging the LDAP client, please let me know. I have implemented a firewall rule that restricts incoming SSH connections from dev.eclipse.org only, as many SSH brute-force attacks were occurring and the default passwords for the user and root accounts are quite weak.
> 'User' accounts will have the following dn: > uid=droy,ou=people,dc=eclipse,dc=org Correction. Make that: uid=denis.roy@myrealdomain-youknow-eclipse.org,ou=people,dc=eclipse,dc=org > * ldap.baseDN : ou=People,dc=eclipse,dc=org Correction. Make that: * ldap.baseDN : dc=eclipse,dc=org
I just configured OpenFire to work with the ldap server. I think our user mapping is great, I don't think our group mapping is correct yet, but we can fix that. I did notice that I was curiously absent in the LDIFF so I'm not in the LDAP server. I made Karl, Denis and Scott admins.
(In reply to comment #105) > I did notice that I was curiously absent in the LDIFF > so I'm not in the LDAP server. Your committer records show your gmail account, whereas your bugzilla email is @code9. Those need to match. You can update your committer email address in the Portal. You likely can't log into IPZilla either because of the mismatch.
I was able to login to the XMPP server as a client using Pidgin. However, because of the @ symbol in the login, I had to set my username as: karl.matthias\40eclipse.org Otherwise Pidgin was confused and couldn't connect to the server. I think we need to either user committer IDs with Bugzilla credentials, or encode the @ symbol in some other way. It appears the admin console is completely unable to handle @ symbols, encoded or otherwise. I don't know if we've included people's real names in the LDIF we upload, but I think that if there is a way to get OpenFire to use them then we ought to because some people's email addresses will be very difficult to search on unless someone knows what it is ahead of time. I also was able to search for users and add Scott Lewis as a buddy in Pidgin. I was not able to find Chris/zx in the directory so I don't know if that is because he has mismatching addresses and thus no account, or if something else is wrong. Pidgin defaults to search.xmpp.eclipse.org as the search server name and that seems to work fine. If I can find someone online to chat with I'll try that out, too. :) Very coo so far. Nice work, guys!
(In reply to comment #107) > I was able to login to the XMPP server as a client using Pidgin. However, > because of the @ symbol in the login, I had to set my username as: > > karl.matthias\40eclipse.org > > Otherwise Pidgin was confused and couldn't connect to the server. I think we > need to either user committer IDs with Bugzilla credentials, or encode the @ > symbol in some other way. It appears the admin console is completely unable to > handle @ symbols, encoded or otherwise. I don't know if we've included > people's real names in the LDIF we upload, but I think that if there is a way > to get OpenFire to use them then we ought to because some people's email > addresses will be very difficult to search on unless someone knows what it is > ahead of time. Cool! I think we should be able to display real names hopefully if we teak the user mapping setup. I believe my primary email was wrong on the portal so that's why my account didn't appear. I fixed that so hopefully the next time we sync, we should be good.
Are you guys waiting on us for anything? Just making sure we're not in some way holding you up. Cheers.
(In reply to comment #109) > Are you guys waiting on us for anything? Just making sure we're not in some > way holding you up. Cheers. > I don't think you are holding anything up. But I suppose we have to make a final choice on the jabber id format that will be accepted...when using mozilla usernames. So I think the choices are: slewis\40composent.com@xmpp.eclipse.org or slewis.composent.com@xmpp.eclipse.org I think we should do the second one: i.e. slewis.composent.com@xmpp.eclipse.org. So if we are going to do this do we have to modify the ldif content, so that the xmpp server authenticates against slewis.composent.com?
You can either modify the incoming LDIF file that you receive, or perhaps just hack the LDIF-to-LDAP import script that I wrote to change the user id at import time. Let us know when you're ready to roll this out and I'll help you announce its availability to the committers.
I will be upgrading the the latest OpenFire (2.6.0a) today as it contains a ton of LDAP-related fixes. We may be in good shape without the fix.
can someone at the Foundation d/l the latest OpenFire? http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire-3.6.0a-1.i386.rpm wget is eating it for me on xmpp.eclipse.org... it just dies on the download after a few seconds.
(In reply to comment #113) > can someone at the Foundation d/l the latest OpenFire? What would we do without the Gool Ol' Foundation... I logged into your vserver and downloaded it just fine. It's in the root home dir. Chris, you owe me a beer for this :-)
Installed the latest OpenFire with Scott, me and Denis as admins. I'm able to log-in using the typical escaped zx\40code9.com@xmpp.eclipse.org
Scott, if you look at Jabber's ID: http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/javadoc/org/xmpp/packet/JID.html#escapeNode(java.lang.String) Should ECF be escaping things?
(In reply to comment #116) > Scott, if you look at Jabber's ID: > > http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/javadoc/org/xmpp/packet/JID.html#escapeNode(java.lang.String) > > Should ECF be escaping things? > From a quick look at JEP-0106 (JID escaping) http://www.xmpp.org/extensions/xep-0106.html It looks like JEP-0106 does require JID escaping. BUT, JEP-0106 says 'Draft', so I don't think it's required of all 'compliant' clients and servers (yet). I'm not sure how the xmpp org 'enforces' compliance with various JEPs. From your javadoc ref it *looks like* openfire does it/supposed to do it.
So I can confirm I can log-in using various clients as long as my id is escaped. Currently, our group mapping needs work. Currently there are groups are defined by cn which means 1 user = 1 group. I think we need a system where groups are predefined based on which projects committers are a part of.
(In reply to comment #118) <stuff deleted> > > Should ECF be escaping things? > > > I've created bug #247039 to support this draft standard with ECF 2.0.1 and beyond.
I'm logged in just fine. I see Gabe, so he must be logged in OK, too. Can someone add Matt and me as admins as well? Cheers guys.
(In reply to comment #120) > I'm logged in just fine. I see Gabe, so he must be logged in OK, too. > > Can someone add Matt and me as admins as well? Cheers guys. Done.
(In reply to comment #118) > Currently, our group mapping needs work. Currently there are groups are defined > by cn which means 1 user = 1 group. I think we need a system where groups are > predefined based on which projects committers are a part of. The LDIF that is exported to the server contains all the project/committer group mappings, and it is successfully loaded into OpenLDAP. Here's a sample of the technology.babel group: dn: cn=technology.babel,ou=group,dc=eclipse,dc=org gidNumber: 1045 cn: technology.babel objectClass: top objectClass: groupOfNames objectClass: posixGroup member: uid=cnguyen@xxx.com,ou=people,dc=eclipse,dc=org member: uid=dmcgowan@xxx.com,ou=people,dc=eclipse,dc=org member: uid=denis.roy@xxx.org,ou=people,dc=eclipse,dc=org member: uid=gabe.obrien@xxx.org,ou=people,dc=eclipse,dc=org member: uid=kitlo@xxx.com,ou=people,dc=eclipse,dc=org member: uid=paul@xxx.com,ou=people,dc=eclipse,dc=org member: uid=essiembre.pascal@xxx.ca,ou=people,dc=eclipse,dc=org member: uid=werner.keil@xxx.net,ou=people,dc=eclipse,dc=org You may need to configure OpenFire's search pattern to tell it how to recognize a group. For instance, objectClass: groupOfNames or objectClass: posixGroup are sure bets. From the command-line, try this: ldapsearch -x -LLL "(objectClass=posixGroup)"
I gave you the wrong info for the ldapGroupSearchFilter in comment 103. I re-read the docs, so please set the ldapGroupSearchFilter to: "(objectClass=posixGroup)"
(In reply to comment #123) > I gave you the wrong info for the ldapGroupSearchFilter in comment 103. I > re-read the docs, so please set the ldapGroupSearchFilter to: > > "(objectClass=posixGroup)" Perfect, groups are working now. My LDAP foo is weak, thanks Denis.
Hey, I was able to connect on port 5222 using my Bugzilla account. But I don't see neither any users, nor groups. Is this normal? May be no one's in at the moment...
I'm working on making groups visible to everyone now... just need to find the twiddly bit in OpenFire to make that happen ;)
Thanks, Chris! It seems you have found it. I see four groups available and three people online. I am currently connected on port 5222. Is there a more firewall-friendly protocol already available?
I've added several groups to be shared amongst everyone... I haven't figured out a way to do it automatically for all the groups yet. I sent a couple support questions to the OpenFire guys to see if they are willing to help. But for now, feel free to sign in and hack around if you wish. There are no guarantees yet until we have everything working though :)
ECF bug 247039 has been fixed, allowing ECF clients to do escaping as per JEP-0106. With this fix (will be in 2.0.1 maintenance and ECF 2.1 in Oct), users can enter slewis@composent.com@xmpp.eclipse.org Until this version is distributed, however, accounts on this server may be accessed via ECF client with slewis\40composent.com@xmpp.eclipse.org Also, in ECF 2.1 stream (HEAD) I've added an 'Eclipse IM' connect wizard, that asks for bugzilla username and password for easier access. Further, with some small amount of coordination this info could also be retrieved from mylyn and used to connect without user interaction.
Excellent guys! That will be good to have in ECF Scott. Chris: I see the technology.phoenix group now and it all looks good!
(In reply to comment #129) > With this fix (will be in 2.0.1 maintenance and ECF 2.1 in Oct), users can > enter > slewis@composent.com@xmpp.eclipse.org btw. if you're not so lucky to have ECF running all the time (like me :( ), Pidgin is another way to go. It has the same "@ issue" as was just fixed in ECF. So the setup is: Username: jacek.pospychala\40pl.ibm.com Domain: xmpp.eclipse.org Password: bugzilla password thank you all for making this happen!
(In reply to comment #131) > btw. if you're not so lucky to have ECF running all the time (like me :( ), Here at the Foundation we've tested on Pidgin, Gaim (old Pidgin), Adium for Mac, and ECF from both Europa and Ganymede releases. All work with the \40 escape of the @ symbol.
Created attachment 112438 [details] pidgin eclipse xmpp groups Confirmed, Pidgin 2.4.1 on ubuntu/debian works (with the \40 escape). Do you have to manually add the groups? For example, where are all the Modeling people?
(In reply to comment #133) > Created an attachment (id=112438) [details] > pidgin eclipse xmpp groups > > Confirmed, Pidgin 2.4.1 on ubuntu/debian works (with the \40 escape). > > Do you have to manually add the groups? For example, where are all the Modeling > people? I've added a few select groups for testing purposes. If you have requests, please let me know :) In the future, every group should be visible but we are working on a way to automate that.
By the way, anyone want to open a bug against Pidgin or libpurple... I believe that's what is used by most of the popular clients out there for messaging support. For XMPP, they should support this: http://www.xmpp.org/extensions/xep-0106.html
(In reply to comment #133) > Created an attachment (id=112438) [details] > pidgin eclipse xmpp groups > > Confirmed, Pidgin 2.4.1 on ubuntu/debian works (with the \40 escape). > > Do you have to manually add the groups? For example, where are all the Modeling > people? > Yep, verified, working with Ubuntu and the latest version of Pidgin 2.5.0 from the Ubuntu repositories.
So Pidgin seems to be automatically showing all of the groups, which is cluttering up the group list so much that my own defined groups are disappearing behind a list groups I don't need 99% of the time. I thought you would only automatically see groups of which you were a member. Is there more than one setting, or is it on/off for visibility on groups?
Miranda IM also requires the \40 workaround. However, when I'm online all groups suddenly appear in my contact list. That's rather disturbing.
(In reply to comment #138) > Miranda IM also requires the \40 workaround. However, when I'm online all > groups suddenly appear in my contact list. That's rather disturbing. So you would prefer groups to not appear by default and you add them yourself based on your interests? The only downside to that is that you have to know the magical incantation to add group names (ie., modeling.emft). That may be difficult for people. By default, you should see the groups you're in and the groups I have magically made appear in your list.
(In reply to comment #139) > (In reply to comment #138) > > Miranda IM also requires the \40 workaround. However, when I'm online all > > groups suddenly appear in my contact list. That's rather disturbing. > > So you would prefer groups to not appear by default and you add them yourself > based on your interests? The only downside to that is that you have to know the > magical incantation to add group names (ie., modeling.emft). That may be > difficult for people. By default, you should see the groups you're in and the > groups I have magically made appear in your list. I think committers are ok with having to enter 'modeling.emft' as we use that a lot of places. I think my client is showing me all groups, though, since I see modeling and platform groups that I'm definitely not a member of.
Hi, I just tried connecting with Adium and apparently that doesn't work. During the account creation, the program tries to connect to the server, and a popup showed: 405: Not allowed. Do you have any trace of a user named antoine\40lunar-ocean.com ? I tried to use the @ character instead and that was rejected by Adium as an invalid character (400: Malformed XMPP ID). I hope it helps. Well it's time for me to call it a week, so excuse me if I don't reply right away if you want to run a debug session with me. We can meet on IRC next Monday if that fits someone to try to fix the problem.
(In reply to comment #141) > Hi, I just tried connecting with Adium and apparently that doesn't work. > > During the account creation, the program tries to connect to the server, and a > popup showed: 405: Not allowed. Are you running from behind a firewall? My guess is the 405 is from your firewall or proxy. Or, It also may be that you need to set the port, too, I can't remember. > Do you have any trace of a user named antoine\40lunar-ocean.com ? That is a valid Bugzilla account. > I tried to use the @ character instead and that was rejected by Adium as an > invalid character (400: Malformed XMPP ID). Yes, you have to escape it with \40 in Adium like you did the first time. > I hope it helps. Well it's time for me to call it a week, so excuse me if I > don't reply right away if you want to run a debug session with me. We can meet > on IRC next Monday if that fits someone to try to fix the problem. It works for me from Adium, so I think it's either a network or config issue.
(In reply to comment #139) > So you would prefer groups to not appear by default and you add them yourself > based on your interests? Maybe my Miranda IM client handles things different. The notion of "groups" is basically just something that helps keeping your contacts list organized. For example, all my Eclipse related IM contacts are in an "Eclipse" group which I maintain myself. Miranda offers me a "Find/Add Contacts" dialog which allows to search for users registered on the server via JID or via a custom search service (which didn't work for me). It did find somebody "zx", "denis" and "karl" :) Can we get first name and last name populated from the LDAP server?
(In reply to comment #140) > > > Miranda IM also requires the \40 workaround. However, when I'm online all > > > groups suddenly appear in my contact list. That's rather disturbing. > > > > So you would prefer groups to not appear by default and you add them yourself > > based on your interests? The only downside to that is that you have to know the > > magical incantation to add group names (ie., modeling.emft). That may be > > difficult for people. By default, you should see the groups you're in and the > > groups I have magically made appear in your list. > > I think committers are ok with having to enter 'modeling.emft' as we use that a > lot of places. I think my client is showing me all groups, though, since I see > modeling and platform groups that I'm definitely not a member of. (In reply to comment #143) > (In reply to comment #139) > > So you would prefer groups to not appear by default and you add them yourself > > based on your interests? > > Maybe my Miranda IM client handles things different. The notion of "groups" is > basically just something that helps keeping your contacts list organized. For > example, all my Eclipse related IM contacts are in an "Eclipse" group which I > maintain myself. > > Miranda offers me a "Find/Add Contacts" dialog which allows to search for users > registered on the server via JID or via a custom search service (which didn't > work for me). It did find somebody "zx", "denis" and "karl" :) Can we get first > name and last name populated from the LDAP server? This isn't just a Miranda issue, i get the same issue with Pidgin as well. Ideally, I should only have the groups automatically added that I belong to. I don't necessarily want to see and get all the groups that are available. A work around for right now, is to just delete the groups that I'm not interested in receiving. Like Miranda, Pidgin allows me to search for additional contacts to add and create my own groups. The more groups that are added, the more it's going to be a pain to have to go through and delete them. Does OpenFire have a user interface, as well as an Admin interface? If so, users could go to the open fire user interface and maybe select which groups they want be default? Not sure if that is possible or not though.
(In reply to comment #144) > This isn't just a Miranda issue, i get the same issue with Pidgin as well. > Ideally, I should only have the groups automatically added that I belong to. Yeah, this is what I was saying above ^^^, too. Kinda makes a mess of the groups list in Pidgin and Adium.
(In reply to comment #139) > So you would prefer groups to not appear by default and you add them yourself > based on your interests? The only downside to that is that you have to know the > magical incantation to add group names (ie., modeling.emft). That may be > difficult for people. By default, you should see the groups you're in and the > groups I have magically made appear in your list. How about publishing the groups and members list on the server, eg., http://xmpp.eclipse.org/groups/. That way you can CTRL-F for the name you want and add the group, or just the user -- no magical incantation guesswork required! You could even provide some documentation on how to add yourself, other users, and groups, for a couple clients (ECF, Pidgin, Miranda, Adium, etc.). By default, I think it'd be less painful to NOT prepopulate the buddy list w/ groups for which you're not a member, but I would like to see groups for which I am a member.
(In reply to comment #144) <stuff deleted> > Does OpenFire have a user interface, as well as an Admin interface? If so, > users could go to the open fire user interface and maybe select which groups > they want be default? Not sure if that is possible or not though. Openfire only has an admin console. For the time being Chris and I are on the hook for administration, but eventually we'll need to figure out another way to share the love (e.g. project leads?) Another option in longer term is that folks contribute additions to Openfire (e.g. more limited administration)...perhaps through Openfire's plugin interface. Also, incidently...there is also a desire to create an Equinox-based XMPP server (probably based upon Openfire) so then the server this can/could leverage stuff done for other projects (e.g. rap, wtp, ecf, etc). See bug #235844.
(In reply to comment #146) > How about publishing the groups and members list on the server, eg., > http://xmpp.eclipse.org/groups/. That way you can CTRL-F for the name you want > and add the group, or just the user -- no magical incantation guesswork > required! You could even provide some documentation on how to add yourself, > other users, and groups, for a couple clients (ECF, Pidgin, Miranda, Adium, > etc.). This page already displays all of that info: http://www.eclipse.org/projects/lists.php?list=allbyproject > By default, I think it'd be less painful to NOT prepopulate the buddy list w/ > groups for which you're not a member, but I would like to see groups for which > I am a member. +1
(In reply to comment #148) > This page already displays all of that info: > http://www.eclipse.org/projects/lists.php?list=allbyproject Awesome. So then how about something more mnemonic, like http://xmpp.eclipse.org/groups/? Here's a patch for an index.php file to live in that directory: <?php header("Location: http://www.eclipse.org/projects/lists.php?list=allbyproject"); />
Thanks to everyone who is putting in all the work to make this happen! For everyone who has to live behind a proxy server, I was able to configure Pidgin to use an HTTP proxy to talk to xmpp.eclipse.org.
(In reply to comment #150) > Thanks to everyone who is putting in all the work to make this happen! For > everyone who has to live behind a proxy server, I was able to configure Pidgin > to use an HTTP proxy to talk to xmpp.eclipse.org. > Grrr. ECF doesn't have (yet) a provider that supports http tunneling for xmpp. We would obviously like it, however. If someone has/writes that code please contribute to bug #247199.
(In reply to comment #142) > (In reply to comment #141) > [snip] > > Are you running from behind a firewall? My guess is the 405 is from your > firewall or proxy. Or, It also may be that you need to set the port, too, I > can't remember. I am directly behind my router at home, so it's not likely there is something blocking from accessing the server. > > [snip] > > It works for me from Adium, so I think it's either a network or config issue. > I tried with the default port: 5222. Am I missing something ? Actually I might: Adium showed a popup with the message: "zero byte resource" According to this post[0], this might be due to a MTU too small. The post has a solution for it, I'll try and will let you know. [0]: http://www.emergentchaos.com/archives/2004/11/mac_trivia_zero.html
FYI, for those who are interested, here is the bug against Pidgin/libpurple: http://developer.pidgin.im/ticket/7058
Chris, Scott, can you sum up what's left to do here so we can close this FIXED?
(In reply to comment #87) > > +1 for xmpp.eclipse.org (not sure if others have other opinions, but this seems > reasonable to me) > RE: ports...the two standard xmpp ports are: > xmpp: 5222 > xmpps: 5223 What about also opening port 5269 for server2server communication? Markus
(In reply to comment #131) > Username: jacek.pospychala\40pl.ibm.com > Domain: xmpp.eclipse.org > Password: bugzilla password Hi Team, Pidgen seems to require a resource. Home is the default but it does not like it anthonyh\40ca.ibm.com@xmpp.eclipse.org/Home disabled What is the correct Resource?
(In reply to comment #156) > What is the correct Resource? Can you leave it empty? Also, a new version of OpenFire should be coming out next week. When that happens, I'll update the server and officially launch this service. Thanks to everyone for their patience.
(In reply to comment #156) > (In reply to comment #131) > > Username: jacek.pospychala\40pl.ibm.com > > Domain: xmpp.eclipse.org > > Password: bugzilla password > > Hi Team, Pidgen seems to require a resource. Home is the default but it does > not like it > > anthonyh\40ca.ibm.com@xmpp.eclipse.org/Home disabled > > What is the correct Resource? > Home works for me as the Resource with Pidgen.
(In reply to comment #158) > (In reply to comment #156) > > (In reply to comment #131) > > > Username: jacek.pospychala\40pl.ibm.com > > > Domain: xmpp.eclipse.org > > > Password: bugzilla password > > > > Hi Team, Pidgen seems to require a resource. Home is the default but it does > > not like it > > > > anthonyh\40ca.ibm.com@xmpp.eclipse.org/Home disabled > > > > What is the correct Resource? > > > > Home works for me as the Resource with Pidgen. > I tried again and it works now, thanks.
Guys, I already see tremendous value in this service. I talked to Chris and he said he was going to remove the groups. I like the groups as is. Can everyone log in and comment?
(In reply to comment #160) > Guys, I already see tremendous value in this service. > > I talked to Chris and he said he was going to remove the groups. I like the > groups as is. Can everyone log in and comment? > Problem with the groups are that they are auotmatically added, and I might not want all the groups. Just particular ones...if you go through and delete them from pidgen, they get re-added the next time you log in. Not very nice.
(In reply to comment #161) > Problem with the groups are that they are auotmatically added, and I might not > want all the groups. Just particular ones...if you go through and delete them > from pidgen, they get re-added the next time you log in. Not very nice. +1 Same thing happens on other clients as well. What would be really nice is if the directory lookup for users, worked though. That would make adding people you need to chat with pretty easy. I thought it worked but recent attempts to use it were not working.
FYI, going to take down the server today and update to 3.6.2 I'll create a blog entry and wiki entry describing how to use the new server. Thanks for beta testing!
We'll have to be patient a bit longer. I'm having issues configuring the new OpenFire with LDAP :) http://www.igniterealtime.org/community/thread/36169
I've managed to fight around the issues with OpenFire. We now have a OpenFire 3.6.2 running live with all the correct settings. There are no groups being pushed by default, so you will have to add groups or people yourself. I have tried to outline how to do this via a wiki entry: http://wiki.eclipse.org/Xmpp.eclipse.org Feel free to modify the wiki entry if you come across an easier way to do things. I'll be online so feel free to find me and chat with me :) It's been awhile, but thanks to everyone who helped make this happen. I hope this helps our Eclipse committers collaborate more.
Nice work!
Note: For those people who were using the infrastructure before, you will have to re-authorize people to see them. It may look like there's no one online but there is. This is because we chose not to push out the groups to people.
I'm having trouble authenticating, and changed my bugzilla pw. Would it be possible to get an ldap refresh for the xmpp server pw db? Related question: Does it do a refresh every night, or more/less frequently than that? Thanks.
(In reply to comment #168) > I'm having trouble authenticating, and changed my bugzilla pw. Would it be > possible to get an ldap refresh for the xmpp server pw db? > > Related question: Does it do a refresh every night, or more/less frequently > than that? > > Thanks. > I believe this happens nightly.
(In reply to comment #167) > Note: For those people who were using the infrastructure before, you will have > to re-authorize people to see them. It may look like there's no one online but > there is. This is because we chose not to push out the groups to people. I can't connect to the server. It worked before when I was codeslave\40ca.ibm.com, but now that my Bugzilla address is nickboldt+bugzilla\40gmail.com, I can't get in; instead I get "401: Not authorized." I've tried various combinations: nickboldt%2Bbugzilla\40gmail.com@xmpp.eclipse.org/Home nickboldt\2Bbugzilla\40gmail.com@xmpp.eclipse.org/Home nickboldt\40gmail.com@xmpp.eclipse.org/Home and nothing works. I'm using Pidgin 2.5.2-6.fc10. Any advice would be appreciated.
Hi, I guess xmpp.eclipse.org user search is not working properly. I'm implementing a user search API on ECF, and it is working fine using ecf.eclipse.org and others XMPP servers, but not for xmpp.eclipse.org. I tried to run a search on xmpp.eclipse.org using other XMPP clients, but it didn't working fine. Any idea?
(In reply to comment #171) > Hi, I guess xmpp.eclipse.org user search is not working properly. I'm > implementing a user search API on ECF, and it is working fine using > ecf.eclipse.org and others XMPP servers, but not for xmpp.eclipse.org. I tried > to run a search on xmpp.eclipse.org using other XMPP clients, but it didn't > working fine. > > Any idea? Not sure, I logged into the admin console to see if the search service was enabled, it was. The service name is 'search.xmpp.eclipse.org' and the searchable fields are 'BugsMail' I don't know if anything is special if we're using LDAP. We can always try posting to the support forums: http://www.igniterealtime.org/community/
I'm not sure why this was resolved...it was dependent upon 198541...which was resolved...but I don't think anything has changed WRT this bug. Reopening and removing dependency.
Probably because we think we did everything we thought we wanted to do. Where am I wrong?
(In reply to comment # > Probably because we think we did everything we thought we wanted to do. I would think that if the 'we' you are referring to are tnhe committers, that such a decision would involve the committers on this bug (at least). If we you are referring to isn't the committers on this bug, then who is it?
Chris is the one who closed the bug... Long ago I thought we were done here. http://wiki.eclipse.org/Xmpp.eclipse.org What's left to do?
I tried it this morning with my bugzilla's credentials and I always get an error (405 or 401) about unauthorized access. I tried with '@' or '\40'. No luck.
same here, using empathy with ubuntu.
(In reply to comment #177) > I tried it this morning with my bugzilla's credentials and I always get an > error (405 or 401) about unauthorized access. > I tried with '@' or '\40'. No luck. (In reply to comment #178) > same here, using empathy with ubuntu. In December 2010, I stopped the export mechanism because, as per my notes, "can't scp the file for months now". I'm not sure what the problem is since it's been almost a year now... But at this point I am assuming (perhaps incorrectly) that the service was no longer being used. Does anyone have any usage statistics for xmpp.eclipse.org? Do we have any way of quantifying how useful the service was, how many committers were using it, and so on?
(In reply to comment #179) > In December 2010, I stopped the export mechanism because, as per my notes, I should specify -- webmasters don't admin xmpp.eclipse.org; Scott and Chris do. We simply set up a mechanism to export the Bugzilla committer accounts and groups to an LDAP-compatible LDIF file.
(In reply to comment #180) > (In reply to comment #179) > > In December 2010, I stopped the export mechanism because, as per my notes, > > I should specify -- webmasters don't admin xmpp.eclipse.org; Scott and Chris > do. We simply set up a mechanism to export the Bugzilla committer accounts and > groups to an LDAP-compatible LDIF file. I/Scott has never administered xmpp.eclipse.org. Years ago, I assisted Chris on some of the OpenFire setup/LDAP integration...but I haven't ever administered xmpp.eclipse.org. >Does anyone have any >usage statistics for xmpp.eclipse.org? Do we have any way of quantifying how >useful the service was, how many committers were using it, and so on? Not that I know of. Any usage statistics would be completely spurious, however, because xmpp.eclipse.org never really been available for actual usage by committers...I personally haven't been able to reach it via my eclipse.org bugzilla account since shortly after it became available (mid 2008). I suspect that this is due bug 291797. I would guess that 291797 is probably the source of comment 177 as well.
(In reply to comment #181) > however, because xmpp.eclipse.org never really been available for actual usage > by committers... So perhaps LDAP integration with existing Bugzilla accounts should be dropped, in favour of a local sign-up solution.
(In reply to comment #182) > (In reply to comment #181) > > however, because xmpp.eclipse.org never really been available for actual usage > > by committers... > > > So perhaps LDAP integration with existing Bugzilla accounts should be dropped, > in favour of a local sign-up solution. Fine by me...but of course the reason Bugzilla integration was attempted was because there wasn't any resource(s) for user administration.
I added a note to http://wiki.eclipse.org/Xmpp.eclipse.org declaring that the service is dead.
This is not something that webmaster will provide. We simply do not have the resources and feel it's best to focus on code and builds.
