distributed teams through public Internet?
Are most people using Jazz for distributed development opening up port 9443 in their firewall and letting remote users connect via the open Internet, or is all activity taking place inside the firewall?
Clearly the first alternative is easier and more flexible but if I have to make a case to management for it, there will be some push back and I'd better have all the facts at my fingertips. Can anyone provide anecdotes or pointers to documents making the case either way? Thanks, MK |
4 answers
kesterto wrote: There is a third way - have a VPN into your network. I use this from It may be a minor semantic distinction but I was counting VPNs in the inside-the-firewall column. In fact VPNs are what led to my question in the first place. <snip> Fair enough... I suppose one example you are looking at right now is jazz.net. We are coming in as contributors rather than developers, but if you browse one of the projects - you are accessing the same space as the developers inside the network (At least that is my understanding). I would go with your first instinct, SSL and opening the port. anthony |
Our RTC server is publicly hosted which makes it accessible to all members of our globally distributed team. We are also behind a very restrictive firewall so our server is configured to use the standard SSL port (443). The RTC server is using the LDAP authentication.
We also have a second type of group who uses the RTC as their ticketing system so they only use the web front end. I think the only justification we used is that it makes sense and minimal overhead. ciao! |
|
kesterto wrote:
There is a third way - have a VPN into your network. I use this from It may be a minor semantic distinction but I was counting VPNs in the inside-the-firewall column. In fact VPNs are what led to my question in the first place. Let me elaborate: Most financial, military, etc businesses have a restrictive VPN design such that your PC is _either_ part of your home network or part of the corporate network, with no bridging. This means that once a remote worker starts the VPN s/he can no longer see the local printer, attach to shares from other local PC's, etc. I've spent a lot of time working this way and it's awful - you have to disconnect to print something or look up a password, then reconnect to try the password, then disconnect to see what to try next, etc., potentially losing your state each time. IBM people don't experience this pain ... I've had the privilege of working for IBM and I know their VPN is more user friendly than that. Unfortunately I'm in the position of working for a place with the obnoxious setup. Its effect on RTC is that remote workers - whether geographically dispersed development teams or just people working from home for the day - can see the Jazz server only when the VPN is active, which means they lose many RTC benefits because they can't see work items or accept/deliver without cranking up the VPN. Ironically, this is making RTC seem like a regression from ClearCase. The old model used ClearCase+MultiSite, which means that remote teams worked against a local replica of the database and the VPN thing was no problem. That's why I'm hoping to make a case for using the "front door" by opening port 9443 on the firewall. It seems to me that if a financial institution trusts SSL with our banking data then it should trust its own private data to it as well. So the question remains - are there RTC customers who let their users work over the Internet relying on SSL, and if so are there justifications in existence? Alternatively, are there documented reasons not to trust it? MK |
Are most people using Jazz for distributed development opening up port 9443 in their firewall and letting remote users connect via the open Internet, or is all activity taking place inside the firewall? There is a third way - have a VPN into your network. I use this from home regularly, as do many other people at IBM. anthony |