User:Techtonik

Drafts

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

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

wget http://svn.colorstudy.com/virtualenv/trunk/virtualenv.py rm ~/inst/bin/python python virtualenv.py --clear ~/inst rm virtualenv.py rm virtualenv.pyc ~/inst/bin/easy_install Genshi ~/inst/bin/easy_install Trac
 * 1) Installing virtual Python environment (this script can be enhanced to do all the stuff automagically)
 * 2) see http://pypi.python.org/pypi/virtualenv
 * 1) Clean old environment if any (optional)
 * 1) The virtualenv.py script installs setuptools automatically
 * 2) Installing required Genshi template engine
 * 1) Installing 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
 * 1) 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 echo ~/inst/lib/svn-python > ~/inst/lib/python2.4/site-packages/subversion.pth cd ../..; rm -rf svntmp
 * 1) for python2.4

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:
 * SSH forced commands and more by O'Reilly
 * Top 10 CVS Tips

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:   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  ssh-rsa AAAAB3Nza.................................................. rsa-key-20061217

 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)  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.  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  ssh = C:\\Tools\\PuTTY\\plink.exe -load

SVN is ready.

 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. 

 Now if you were careful enough to remember your session name (mine is rainforce, you can issue: 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