Installing and running multiple instances of the same software

Karl Auer kauer at biplane.com.au
Sun Mar 13 09:54:08 UTC 2016


On Sun, 2016-03-13 at 09:58 +0100, Ralf Mardorf wrote:
> One user can run a second instance of firefox as another user,
> even if firefox wouldn't allow to use different profiles.

If you start it as another user, won't you will be using a different
profile?

To the OP: The discussion starts getting a bit esoteric here. I think
Ralf and I are agreed that you need some form of container to run your
two Vyatta's. If the following discussion all makes sense, then you
probably don't need our help - the pointers to the various technologies
will be all you need.

But if the following discussion is not clear to you, your fastest (and
probably most reliable) way forward is to use heavyweight containers -
virtual machines or even two physical machines.

Why do you not want to use virtual machines? Why do you want two
Vyattas on one physical machine?

Now read on:

> IIRC there is a smarter solution than to use xhost and sudo by using 
> ssh. I guess quite recently this was a topic on this list.

Not sure what solution you are referring to here.

> IOW this could be done for every app a user could run, even if the 
> app shouldn't allow to run several instances.
> 
> [rocketmouse at archlinux ~]$ grep -v "#" /usr/local/bin/chuser 

Can't seem to find that on Ubuntu 15.10:

kauer at kt:~$ less /usr/local/bin/chuser
/usr/local/bin/chuser: No such file or directory
kauer at kt:~$ find /usr -iname "*chuser*" -print
kauer at kt:~$ find /bin -iname "*chuser*" -print
kauer at kt:~$ find /sbin -iname "*chuser*" -print
kauer at kt:~$ which chuser
kauer at kt:~$ man chuser
No manual entry for chuser
kauer at kt:~$ grep chuser /etc/passwd
kauer at kt:~$ apt-cache search chuser
kauer at kt:~$

Maybe it's an archlinux thing? If not, where do I find it?

Thanks for the info on systemd-nspawn, that was new to me. It looks
very interesting. For this particular query though, do contained OSes
get their own IP addresses and so forth? How does sharing of network
interfaces (and devices more generally) work?

> Perhaps a chroot or systemd-nspawn could do the job.

chroot would not solve the shared access to devices (I think). I don't
know whether nspawn would either. The doco for the --capability option
suggests it might, but on the other hand (from the LXC guide):

"By default LXC creates a private network namespace for each container,
which includes a layer 2 networking stack.  Containers usually connect
to the outside world by either having a physical NIC or a veth tunnel
endpoint passed into the container.  LXC creates a NATed bridge,
lxcbr0, at host startup. Containers created using the default
configuration will have one veth NIC with the remote end plugged into
the lxcbr0 bridge.  A NIC can only exist in one namespace at a time, so
a physical NIC passed into the container is not usable on the host.  

"It is possible to create a container without a private network
namespace. In this case, the container will have access to the host
networking like any other application.  Note that this is particularly
dangerous if the container is running a distribution with upstart, like
Ubuntu, since programs which talk to init, like shutdown, will talk
over the abstract Unix domain socket to the host's upstart, and shut
down the host."

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4







More information about the ubuntu-users mailing list