Let’s pimp ‘newvserver’

newvserver is a truly convenient script to create a new vserver and have it largely preconfigured. Too sad it lacks the necessary flexibility … you think? Think twice. Bash gives newvserver the flexibility that you need!

Alright, so you figured out that /etc/vservers/newvserver-vars gets sourced by newvserver, but how can that help? Well, since we know that functions can override commands or builtins, we will have to find a strategically nice point in the newvserver script where we can override some command. After some searching I found the vserver call quite fitting. This is being done (without giving an explicit path to the vserver script) after the vserver build command, which is called using the absolute (full) path. So how about creating a function that will mimick the behavior of the vserver script under normal circumstances, but will do what we expect it to do under certain circumstances? 😉

Guess what, that’s exactly what I did. Here’s in a nutshell what my function vserver does:

• Checks whether its second parameter was start and if so, does some magic such as moving the original script that was created by newvserver and writing its own version where (again) two functions are being overriden (tasksel and dpkg-reconfigure in my case). Make sure to escape any references to function parameters in these “second-level” functions properly! Inside dpkg-reconfigure, if the first parameter is passwd, the function will run the following two (external) commands to enable shadow passwords and lock the password for root (vserver <name> enter works regardless!)!

  command shadowconfig on
  command passwd -l root

  The old (moved) script that had been created by newvserver is then appended to the newly written script part, except for the first line with the hashbang:

  # Append the original newvserver-created script ;)
  tail -n +2 $VROOTDIR/$VHOST/vserver-config.old.sh >> \\
    "$VROOTDIR/$VHOST/vserver-config.sh"

  After all that, the parameters are passed to the actual vserver command (see below).

• If the second parameter was exec, the function looks for a marker file which I create before the call to newvserver under certain circumstances. After all that, the parameters are passed to the actual vserver command (see below).
• If no matching condition was found, the function just passes the parameters on to the external vserver command by calling:

  # Now execute the actual vserver script
  command vserver $*

  This is the same approach that is used in the above two cases where I also pass on the parameters to the original vserver script.

Hope this helps someone else 😉

// Oliver