Unix account setup

From DreamHost
Revision as of 08:08, 19 June 2010 by Baby (Talk | contribs)

Jump to: navigation, search
The instructions provided in this article or section require shell access unless otherwise stated.

You can use the PuTTY client on Windows, or SSH on UNIX and UNIX-like systems such as Linux or Mac OS X.
Your account must be configured for shell access in the Control Panel.
More information may be available on the article's talk page.

The instructions provided in this article or section are considered advanced.

You are expected to be knowledgeable in the UNIX shell.
Support for these instructions is not available from DreamHost tech support.
Server changes may cause this to break. Be prepared to troubleshoot this yourself if this happens.
We seriously aren't kidding about this.

Note: some general instructions and information about some environment settings are given in Environment Setup

Sharing installed software

In some contexts (e.g. when you have to administer several domains), it might make sense to use only one unix account and install all the software you need, either from the command line or from the web sites.

In order to do this, you should create a special (non-personal) unix account to hold all the software you install PLUS all the websites that you administer. This keeps things sorted.

Give a generic name to this unix account and try to keep it as short as possible. Maybe "inst" for "install" or "soft" or whatever else you like. These instructions will use "inst" , but this name will quickly be assign to an environment variable so that you can copy most of these instructions and paste them into your terminal window (you should actually choose a different username of your liking since, if these instructions happen to have some popularity, the chances that the inst username be already used in your (shared) host will become higher).

Furthermore, as stated above, all the sites that you administer go to this same user so you don't need one unix account per site. If you have different administrators for different sites, you may want to create one unix account for administrator (not one per site). If you want, you can also create a mailbox for this user to receive generic mail for the domains hosted (e.g. webmaster@<your-domain>, postmaster@<your-domain>, info@<your-domain>, etc).

Creating the unix account

So, go now and login to your DreamHost panel and select:

  • Users
    • Manage Users
      • Add A New User
        • In Type of User Account: choose Shell: allows FTP plus ssh/telnet shell access..
        • In Shell Type: choose /bin/bash.
        • In Username: put the username you chose (e.g inst).
        • In Full Name: put Software Administrator (or whatever you prefer).

Fill in your password twice (or let the panel choose one for you) and press the Add user button. In a few minutes you'll be able to access your account via SSH (which is what you'll be using for the rest of this how-to).

Keeping it tidy

In order to avoid having dozens (or hundreds) of files and directories in your ${HOME}, you'll kinda mimmick the File Hierarchy Standard (FHS) within your own ${HOME}, in a subdirectory named run (though' you may name it as you please). You'll also use a www subdirectory to hold all the sites for this user (instead of having one subdirectory for each domain/subdomain under ${HOME}.

So, login (using SSH), and let's start creating the following subidrectories:

  • soft to download (and compile if necessary) software before installing it. Once the software is installed you can delete it from here. But, if you modified it somehow, maybe you should keep it here, noting what you modified.
  • run to install the software. It is a kind of private FHS space for our own. You use this to avoid having bin, etc, lib and the like directly in your $HOME directory (which is what many people do). Let's say your /home/inst/run is the moral equivalent to /usr/local and is what you'll use for the --prefix option that most software's ./configure script use to prepare software in order to be installed in a non-standard place (like ours). You'll probably use ./configure --prefix /home/inst/run with most software you compile for use in your account.
  • www to hold the web sites that you administer. The subdirectories here will be the ones that are usually in the $HOME directory to hold web sites. Note: You have to manually tell the dreamhost panel that your site goes in www/< domain-name > instead of the default < domain-name >
  • logs is already created by DreamHost and has a subdirectory for each virtual host to hold the Apache HTTP Server logs. However, you don't have write access to this directory, so you create the following:
  • log somehow equivalent to the standard /var/log where your software will put its log data.
  • log/setup will hold the logs generated during software installations.
  • log/vhosts will be a symbolic link (symlink) to logs.

Creating the directories

Now you simply create the directories we need:

cd ${HOME}
# create the first level directories (and log/setup)
mkdir -pv soft run www log log/setup backup data
# create the second level directories within run (our own FHS)
for subdir in bin etc include lib man share
do
  mkdir -pv run/${subdir}
done
# symlink so that man pages stay all in the same place
ln -sv ../man run/share/man
# symlink so that the apache logs are also found within log
ln -sv ../logs log/vhosts

Now, if the account is new, ls should only show these files:

Maildir/  backup/  data/  log/  logs/  run/  soft/  www/

Configuring the Environment

Now you want that the software you install in your own FHS be found when you invoke it in the command line. What's more, in case you're installing something by the same name of something already installed by DreamHost (in /usr/bin or in /usr/local/bin), maybe a newer version of a package, you want your FHS to be found before the standard one.

You'll add some commands to the end of .bashrc in order to do this (if you're using csh, ksh or any other non-bash shell, you should probably know how to do this for your shell).

You'll add a pathmunge() function which allows you to prepend (or postpend) the $PATH environment variable with the name of a directory. The gain of this function (against the good ole' export PATH=<new-directory>:$PATH) is that this function does a couple of sanity checks:

  1. If the directory doesn't exist, it is not added to the $PATH
  2. If the directory already is in the $PATH, it is not re-added

So, do the following:

cat >>${HOME}/.bashrc <<eof
function pathmunge () {
if [ -d \$1 ] && ! echo $PATH | /bin/egrep -q "(^|:)\$1(\$|:)"
then
        if [ "\$2" = "after" ]
        then
                PATH=$PATH:\$1
        else
                PATH=\$1:\$PATH
        fi
fi
}

export RUN="\${HOME}/run"

pathmunge \${RUN}/bin

export LD_LIBRARY_PATH=\${RUN}/lib:\${LD_LIBRARY_PATH}
export LD_RUN_PATH=\${RUN}/lib:\${LD_RUN_PATH}

# perl library search path
PERL5LIB=\${RUN}/share/perl/5.8:\${RUN}/share/perl/5.8.4:\${PERL5LIB}
export PERL5LIB=\${RUN}/lib/perl/5.8:\${RUN}/lib/perl/5.8.4:\${PERL5LIB}

eof

Now, the next time you log in (via SSH) you'll have a new $RUN environment variable (pointing to /home/inst/run and /home/inst/run/bin will be the first directory in your $PATH.

If you want to activate this right now, do the following:

. ${HOME}/.bashrc

(note the dot at the beginning of the command line and type it).

You may also need to add this line of code to your .bash_profile file: source ~/.bashrc

Other instructions in this wiki by the same may will that $RUN and $PATH are set up like this, so you may choose any name for the run subdirectory and it will still work.


Configuring other account's environments

As explained above, this setup allows you to share installed software, in order for your other accounts to use the software installed for user inst (or however you called it) in your other shell accounts, you have to do this in each account:

  • login to each account via ssh.
  • type in each account the following (replace 'inst' with the name of the account you use to install the software):
# replace 'inst' in the line below with the real username of the account where you installed your software:
export INST_ACCOUNT="inst"


cat >>${HOME}/.bashrc <<eof
function pathmunge () {
if [ -d \$1 ] && ! echo $PATH | /bin/egrep -q "(^|:)\$1(\$|:)"
then
        if [ "\$2" = "after" ]
        then
                PATH=$PATH:\$1
        else
                PATH=\$1:\$PATH
        fi
fi
}

export RUN="/home/${INST_ACCOUNT}/run"

pathmunge \${RUN}/bin

export LD_LIBRARY_PATH=\${RUN}/lib:\${LD_LIBRARY_PATH}
export LD_RUN_PATH=\${RUN}/lib:\${LD_RUN_PATH}

# perl library search path
PERL5LIB=\${RUN}/share/perl/5.8:\${RUN}/share/perl/5.8.4:\${PERL5LIB}
export PERL5LIB=\${RUN}/lib/perl/5.8:\${RUN}/lib/perl/5.8.4:\${PERL5LIB}

eof

Note that you must log in to the 'inst' account to install software, but the software you install there can be used from any of the other accounts.

Preparing your environment to support local installation of modules or packages

Your environment must be configured and the environment variable $RUN configured. That is, if you type:

echo $RUN

you must see the directory you configured as your local installation directory.

Configuring CPAN to support local installation of Perl modules

Type the following commands in order to create a configuration so that CPAN installs Perl modules within this hierarchy.

mkdir -pv ${HOME}/.cpan/CPAN
cat > ${HOME}/.cpan/CPAN/MyConfig.pm <<eof

\$CPAN::Config = {
  'auto_commit' => q[0],
  'build_cache' => q[10],
  'build_dir' => q[\$ENV{HOME}/.cpan/build],
  'cache_metadata' => q[1],
  'commandnumber_in_prompt' => q[1],
  'cpan_home' => q[\$ENV{HOME}/.cpan],
  'dontload_hash' => {  },
  'ftp' => q[/usr/bin/ftp],
  'ftp_passive' => q[1],
  'ftp_proxy' => q[],
  'getcwd' => q[cwd],
  'gpg' => q[/usr/bin/gpg],
  'gzip' => q[/bin/gzip],
  'histfile' => q[\$ENV{HOME}/.cpan/histfile],
  'histsize' => q[100],
  'http_proxy' => q[],
  'inactivity_timeout' => q[0],
  'index_expire' => q[1],
  'inhibit_startup_message' => q[0],
  'keep_source_where' => q[\$ENV{HOME}/.cpan/sources],
  'lynx' => q[/usr/bin/lynx],
  'make' => q[/usr/bin/make],
  'make_arg' => q[],
  'make_install_arg' => q[],
  'make_install_make_command' => q[/usr/bin/make],
  'makepl_arg' => q[PREFIX=\$ENV{RUN}],
  'mbuild_arg' => q[],
  'mbuild_install_arg' => q[],
  'mbuild_install_build_command' => q[./Build],
  'mbuildpl_arg' => q[],
  'ncftpget' => q[/usr/bin/ncftpget],
  'no_proxy' => q[],
  'pager' => q[less],
  'prerequisites_policy' => q[follow],
  'scan_cache' => q[atstart],
  'shell' => q[/bin/bash],
  'tar' => q[/bin/tar],
  'term_is_latin' => q[0],
  'term_ornaments' => q[1],
  'unzip' => q[/usr/bin/unzip],
  'urllist' => [q[ftp://cpan.cse.msu.edu/], q[ftp://cpan-du.viaverio.com/pub/CPAN/], q[ftp://cpan.mirrors.redwire.net/pub/CPAN/], q[ftp://cpan.hostrack.net/pub/CPAN]],
  'use_sqlite' => q[0],
  'wget' => q[/usr/bin/wget],
};
1;
__END__
eof

Configuring virtualenv to support local installation of Python packages

We'll create a virtual python environment so that we can install Python packages. We'll use [virtualenv] for that purpose:

VIRTENVVERSION=1.4.9

mkdir -pv ${HOME}/soft
cd ${HOME}/soft

wget http://pypi.python.org/packages/source/v/virtualenv/virtualenv-${VIRTENVVERSION}.tar.gz

tar xvzf virtualenv-${VIRTENVVERSION}.tar.gz

python virtualenv-${VIRTENVVERSION}/virtualenv.py ${RUN}


See Also

External Links