User:Techtonik

From DreamHost
Jump to: navigation, search

Drafts

~/inst software maintenance

It is better to keep all custom software in ~/inst directory, because Unix packages usually contain several directories in root.

Maintaining Trac in ~/inst subdirectory

Installing latest Trac

Official Python version on DreamHost at the beginning of 2010 is 2.4.4 that should be enough for Trac 0.12.x

# Installing virtual Python environment (this script can be enhanced to do all the stuff automagically)
# see http://pypi.python.org/pypi/virtualenv
wget http://svn.colorstudy.com/virtualenv/trunk/virtualenv.py
# Clean old environment if any (optional)
rm ~/inst/bin/python
python virtualenv.py --clear ~/inst
rm virtualenv.py
rm virtualenv.pyc
# The virtualenv.py script installs setuptools automatically
# Installing required Genshi template engine
~/inst/bin/easy_install Genshi
# Installing Trac
~/inst/bin/easy_install Trac

This will download and install latest stable Trac version into ~/inst/ If you would rather use SVN version - use the following command sequence instead of the last ~/inst/bin/easy_install Trac call:

mkdir temptrac; cd temptrac
svn checkout http://svn.edgewall.org/repos/trac/trunk
cd trunk; python setup.py install
cd ../..
rm -rf temptrac
# package installed

That installs Trac, but by default it won't allow to browse SVN repository, because it needs subversion bindings for Python first.

Installing Subversion bindings for Python (Trac requirements)

Trac can operate without repository, but it loses a lot of charm without it. To access SVN repositories Trac uses Subversion bindings for Python. A pity, but newer Python 2.4.x preinstalled on Dreamhost (instead of default 2.3.x) doesn't include these. To get python bindings back in place I've recompiled Subversion, installed it with the libraries into ~/inst , then compiled bindings from the same source, installed them as well and then added a path pointing to bindings to Python site-packages directory. Translated into shell language with ~/inst path as prefix it looks like the following manuscript.

Bindings are made using SWIG tool. It's worth installing the latest version mentioned in SVN documentation ./subversion/bindings/swig/INSTALL (1.3.31 for Subversion 1.5.5)

mkdir SWIG; cd SWIG
wget http://downloads.sourceforge.net/swig/swig-1.3.31.tar.gz
tar xzvf swig-1.3.31.tar.gz; cd swig-1.3.31
./configure --prefix=$HOME/inst
make; make install
cd ../..; rm -rf SWIG

Installing latest Subversion. Specifying path to versions that are installed in $HOME/inst explicitly to avoid using those available from $PATH, because --prefix is not enough.

mkdir svntmp; cd svntmp
wget http://subversion.tigris.org/downloads/subversion-1.5.5.tar.bz2
wget http://subversion.tigris.org/downloads/subversion-deps-1.5.5.tar.bz2
tar xjf subversion-1.5.5.tar.bz2
tar xjf subversion-deps-1.5.5.tar.bz2
cd subversion-1.5.5
./configure --prefix=$HOME/inst --with-swig=$HOME/inst PYTHON=~/inst/bin/python
make
make install
make swig-py
make check-swig-py
make install-swig-py
less subversion/bindings/swig/INSTALL
# for python2.4
echo ~/inst/lib/svn-python > ~/inst/lib/python2.4/site-packages/subversion.pth
cd ../..; rm -rf svntmp

Setup CVS for multiple developers from one SSH account

You will need to substitute your username instead of rainforce below.

  1. export CVSROOT=/home/rainforce/repository
  2. vim .bash_profile
  3. Add the same export CVSROOT=/home/rainforce/repository to .bash_profile
  4. And umask=007 there for security reasons
  5. cvs init
  6. chmod -R 770 /home/rainforce/repository
  7. Generate your SSH key and paste public part of it into .ssh/authorized_keys2
  8. Prepend your key with forced command to test it works i.e. command="/bin/echo Sorry, buddy, but youve been terminated!" ssh-rsa AAAA...
  9. Try to login with your new key - you should be disconnected with note mentioned above
  10. Login normally and change command in your .ssh/authorized_keys2 to no-pty,command="/usr/bin/cvs --allow-root=/home/rainforce/repository server" ssh-rsa AAAA...

This would be fine if only "cvs server" understand "--allow-root" command. Although instructions on this page http://ioctl.org/unix/cvs/server contain the same technique I've made some experiments and was not able to restrict "cvs init" with only one cvsroot equal to --allow-root=/home/rainforce/repository. See http://savannah.nongnu.org/bugs/?func=detailitem&item_id=14900 and http://lists.nongnu.org/archive/html/bug-cvs/2005-11/msg00000.html (update: recent comments show that the issue has been fixed and fix will be available in version 1.12.14 of CVS, so the plan is to wait for 1.12.14 to appear in public and on lucas server)


Helpful links:

Setup Subversion access for multiple developers through one SSH account

These quick instruction covers several aspects of multiuser development with Subversion. Setup SVN+SSH on server side. Use one SSH for multiple users. Use of PuTTY client to securely connect to SVN.

Starting with key:

  1. Generate a key using puttygen.exe - save private key separately and copy "Public key for pasting into OpenSSH authorized_keys file" into .ssh/authorized_keys on your hosting account (/home/rainforce_www/.ssh/authorized_keys in my case). authorized_keys should look like
  2. ssh-rsa AAAAB3Nza.................................................. rsa-key-20061217
    
  3. Now your key need to be enhanced with command to be automatically launched when the key is used for authentication. This allows you to specify repository location and user name to be used to work with it. After modification your authorized_keys line should look like this (it is actually one line split in two for convenience)
  4. command="/usr/bin/svnserve -t --tunnel-user techtonik -r /home/rainforce_www/svn", no-port-
    forwarding, no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3Nza... rsa-key-20061217
    

    First parameter /usr/bin/svnserve - is obvious - the name of program to handle SVN requests on server side, -t key tells it that it is executed in tunnel mode (i.e. through SSH), --tunnel-user techtonik specifies name that should be used in svn logs when accessing the repository with this key and finally -r is used to point where repository is located.

    Note that the user name in this case can be just anything - SSH tells SVN this name and that the name was already authenticated so there is no need to annoy that person. SVN lazily believes that do not bothering itself with checks if the name is present in access lists or not (whatever they are). As for comma separated parameters - they turn off all "extra" OpenSSH abilities that are not needed for SVN access to reduce security risks.

    Now when you've setup SSH access from server-side, let's tune PuTTY and SVN cooperation on client machine.

  5. To link PuTTY and SVN on client machine, open your SVN config directory - something like C:\Documents and Settings\techtonik\Application Data\Subversion and inside config file uncomment and edit ssh string to look like
  6. ssh = C:\\Tools\\PuTTY\\plink.exe -load
    

    SVN is ready.

  7. Setup PuTTY session to connect to your repository. To know how to do this - replace "session" with "profile" in previous sentence and read this paragraph.
  8. Now if you were careful enough to remember your session name (mine is rainforce, you can issue:
  9. svn list svn+ssh://rainforce/svn/
    

    Enjoy. To add more users just add more strings to authorized_users file.


The list of software that helped a lot

http://www.farmanger.com/ Far. File and archive manger (not open source)
http://apserver.sourceforge.net/ NTLM Authorization Proxy Server (Python, GPL)
diff -u3prNw origsrc newsrc