1

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?

viraptor
  • 1,264
  • 6
  • 21
  • 40

2 Answers2

1

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...

retracile
  • 1,260
  • 7
  • 10
  • Yeah... I really do not want to solve it this way :/ – viraptor Dec 08 '09 at 03: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 08 '09 at 14:29
  • There's probably no other "good" way - I'll start patching... – viraptor Dec 09 '09 at 01:28
0

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.

Matt Joiner
  • 191
  • 1
  • 8
  • 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 08 '09 at 09: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 08 '09 at 13:27