Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I tend to copy some useful programs to every server I login to. I have loads of configuration files, a statically compiled zsh (in case I need a new version), vim, python, version control binary, etc. I have a script that just checks them out, links all binaries to ~/bin if they're newer than the system-wide versions, and does all the needed setup - I've got the setup I need on any kind of host/distro.

This has worked just fine, while I had the same login on all hosts. Unfortunately now I can't use my standard login at some hosts. How can I modify my environment to work in the same way without recompiling? For example with a normal deployment, I would need to recompile python to make /home/yyy/priv_env/python/lib the main library path, but on all other hosts I need /home/xxx/.... This case can be solved with PYTHONPATH of course, but there are other binaries taking the default path from the compilation stage - like zsh modules. Is there any way to solve this without taking care of many shell variables?

Ideally, I would use a private chroot in the environment which maps to all the needed directories to the places I need. But chroot is not available for non-root users of course.

I also thought about setting up a link in /tmp/${random_preselected_string} to ${HOME}/priv_env and setting all the paths to point at the /tmp/... link. This will work as long as noone creates a file with the same name there. Also with long login sessions, it might be affected by tmp autocleaners.

Have you got any better ideas?

share|improve this question
up vote 1 down vote accepted

I'd look at ways to specify $HOME as part of the path for the software to evaluate at run time. There's a good chance that'd require patching the code though...

share|improve this answer
Yeah... I really do not want to solve it this way :/ – viraptor Dec 8 '09 at 3:00
Yeah, I understand that, but sometimes a patch is really the only way to solve it. Seems like it wouldn't be a large patch on each package, but multiply by the number of packages that need it, and it may add up. – retracile Dec 8 '09 at 14:29
There's probably no other "good" way - I'll start patching... – viraptor Dec 9 '09 at 1:28

This won't be much help, but as a general rule the idea behind source builds is they're targetted at the library configuration of your host machine. Portable binaries you've generated via statically linking on another machine are not guaranteed to work, and are not the canonical way of doing things. Generally you should compile your custom binaries on each and every machine you target.

As a fallback I'd set the prefix to /usr/local, but again, I see your dilemma, not having root-access and all.

share|improve this answer
Well - I do have a root access on those machines, but I don't want to mess with them at the /usr/local level. I simply want to have my own and reproducible environment on any host for my user account. I want the same readline support and same zsh modules and same vim+python+scripts etc. etc. on a host with one command. Of course I could compile everything, but making a set of 2 environments (32+64b) and just hg up-ing them on login is so much easier :) – viraptor Dec 8 '09 at 9:01
hey hg'ing it is a pretty nice idea. i gave up on this track a while ago, and use HOME for my own machines, and /usr/local on servers where i'll be back again, and need stuff across accounts. – Matt Joiner Dec 8 '09 at 13:27

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.