Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

As part of a pilot project, I am attempting to set-up a thin client environment for a team of developers using NoMachine. Each developer will login to the same Linux box and do development via an X session. Currently, each developer runs their own HTTP daemon on their local workstation that listens on 127.0.0.1:5000. However, if I move everyone onto the same machine this obviously creates a problem with port conflicts.

Ideally, I'd like to keep their workflow the same. If I have to assign everyone a unique port, it's just going to create a lot of grief and confusion. Is there a way to do this? Can different processes bind to the same port on a per-user basis? I discovered a way to use iptables to do port redirection on a per-user basis, but this only solves part the problem:

iptables -t nat -I OUTPUT --src 0/0 --dst 127.0.0.1 -p tcp --dport 5000 -m owner --uid-owner userA -j REDIRECT --to-ports 5001

This solution still doesn't allow different processes to bind to the same port. And I'm not even sure that I'm on the right track here by looking for an iptables solution. Any suggestions? Is there maybe a hack that be applied in userland? Thanks!

share|improve this question

4 Answers 4

up vote 2 down vote accepted

They can't bind to the same port.

Bind each process to its own port, and then dispatch INPUT port 5000 to 5001, 5002, 5003 depending on your conditions.

share|improve this answer
    
Thanks for the answer. The main problem with that idea is that they're starting (and restarting) their own Python-based HTTP daemon while working. And port 5000 is specified in an .ini file that's shared across all developers via a version control system. That .ini file contains dozens of other app settings so it's important that the file remain synchronized between devs. Am I making any sense? –  jamieb Oct 9 '11 at 3:47
    
Oh sorry, i inversed your problem. Why not simply git-ignore that .ini-file on a per-developer base? I'd recommend having some sort of default.ini which has to be copied to production.ini or something like that. that way you can have your defaults in your VCS and also have local developer changes which don't get commited. Also good if people update from your project, then their config won't get overwritten. –  Franz Bettag Oct 9 '11 at 3:53
    
Why do you even need to use a fixed port for each server, and not dynamic port? –  curiousguy Oct 9 '11 at 4:03

TCP server addresses

The address of a listening TCP server consists of (IP, port) (for IP in IPv4 or IPv6), where IP can be the wild-card IP "*", that is the address 0.

A TCP client will connect to a specific (server_IP, server_port) pair (no wild-card here). There must be exactly one listening socket with either:

  • this exact (server_IP, server_port) address
  • or the wild-card IP, and the same port; ie the listening socket will have the address (0, server_port)

The TCP stack does not want to have to make arbitrary choices between sockets, so it will not allow the creation of two different listening TCP sockets at the same time which could accept the same connexion attempt from a TCP client.

Usable address space

The good new is that the space for IPv4 local-host addresses is quite large: exactly 2**24 - 2 = 16777214 different IPv4 addresses are reserved for this job, from 127.0.0.1 to 127.255.255.254.

share|improve this answer

You can use a different IP for each user. Most of the programs allow to bind on different IPs on the same port. You will need to add those IPs to a network interface.

share|improve this answer
    
Both IP address and TCP port have to be the same for each developer. This info is pulled from a centralized .ini file when they launch their own HTTP process. This system wasn't designed with a thin-client environment in mind. I'm hoping to find a way to jam a square peg into a round hole here. –  jamieb Oct 9 '11 at 3:51

How many people developers do you have? If it is not that many, how about setting up KVM (or Xen/VMware) on the server and have them use their own virtual machine (each with it's own IP, of course).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.