Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a few Xen guests that are very similar: same arch, same OS (Debian), usually the differences are in RAM and disk space. I'd like to use specific VMs for specific tasks, i.e. one for VPN and SSH, another for webserver, etc.

Most guides out there show how NFS is neat to export /home, but what i'm interested in is in exporting the base system, like /usr/bin, /sbin, etc... (actually maybe not /etc because of specific software).

I considered shoving everything new (non-base/specific) to /user/local and export only that, but i'd have to keep a zero-conf-ish structure there and would break compatibility with the package manager, voiding any system upgrade.

I guess i'm looking for something like a variation of dumb terminals.

Is this feasible? Any big pros and cons?

share|improve this question

migrated from Mar 20 '13 at 3:08

This question came from our site for professional and enthusiast programmers.

1 Answer 1

up vote 2 down vote accepted

I don't have any experience in trying to share a whole set of system tools, so I am most probably just taking wild guesses. Nevertheless, I don't think it will be too easy to accomplish your plan.

You will most definitely have some trouble in managing the whole set of library dependencies your shared tools bring along.

As requested, here some of the pros and cons that come into mind:


  • less consumption of hard disk storage as you don't have to store everything separately for every of your machines.

  • less redundant maintenance work as you just have to keep one set of tools up to date

  • higher degree of consistency as the same set of tools will be available on all systems


  • you're trapped if any essential tools to bring the network up again are just stored on a network share.

  • single point of failure - if the NFS server is down without any backup none of your systems will be operational at all.

  • compatibility problems - especially if different hardware architectures are involved you'll have to resort to symlink, LD_PRELOAD and whatsoever to a degree that's hardly ever managable.

  • tools requiring setuid won't run if the folders are shared nosuid

  • maintaining either NIS or LDAP user database to ensure a consistent UID mapping is a must.

  • security overhead - maintaining a whole kerberos or ipsec infrastructure to just keep NFS secure alone seems like a massive overhead.

  • slow operation - network latency and encryption overhead will steal a good amount of computing power.

  • missing isolation of your systems - if one of the systems gets compromised they're all compromised.

  • inconsistent package management data - as all updates will be installed in one central mastercopy the package databases of your clients won't know anything about the program and library versions currently in use.

Probably not all of the cons listed will meet your specific setup as my experiences originate from an attempt to share a small set of tools in a very heterogenous environment involving a whole bunch of different architectures and operating systems that soon turned into a nightmare while you seem to intend to work with a very homogenous (uniform) environment.

Nevertheless, I'd better think twice before diving into such an adventure head over heals.

share|improve this answer
Lots of IFs to consider indeed, even with a homogeneous environment. Thanks. – vesperto Mar 21 '13 at 14:01

Your Answer


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.