Changeset - c008f1b0cf62
[Not reviewed]
beta
0 1 0
Marcin Kuzminski - 13 years ago 2012-10-09 00:14:14
marcin@python-works.com
docs update
1 file changed with 2 insertions and 2 deletions:
0 comments (0 inline, 0 general)
docs/setup.rst
Show inline comments
 
.. _setup:
 

	
 
=====
 
Setup
 
=====
 

	
 

	
 
Setting up RhodeCode
 
--------------------
 

	
 
First, you will need to create a RhodeCode configuration file. Run the 
 
following command to do this::
 
 
 
    paster make-config RhodeCode production.ini
 

	
 
- This will create the file `production.ini` in the current directory. This
 
  configuration file contains the various settings for RhodeCode, e.g proxy 
 
  port, email settings, usage of static files, cache, celery settings and 
 
  logging.
 

	
 

	
 
Next, you need to create the databases used by RhodeCode. I recommend that you
 
use postgresql or sqlite (default). If you choose a database other than the
 
default ensure you properly adjust the db url in your production.ini
 
configuration file to use this other database. RhodeCode currently supports
 
postgresql, sqlite and mysql databases. Create the database by running
 
the following command::
 

	
 
    paster setup-rhodecode production.ini
 

	
 
This will prompt you for a "root" path. This "root" path is the location where
 
RhodeCode will store all of its repositories on the current machine. After
 
entering this "root" path ``setup-rhodecode`` will also prompt you for a username 
 
and password for the initial admin account which ``setup-rhodecode`` sets 
 
up for you.
 

	
 
setup process can be fully automated, example for lazy::
 

	
 
    paster setup-rhodecode production.ini --user=marcink --password=secret --email=marcin@rhodecode.org --repos=/home/marcink/my_repos
 
    
 

	
 
- The ``setup-rhodecode`` command will create all of the needed tables and an 
 
  admin account. When choosing a root path you can either use a new empty 
 
  location, or a location which already contains existing repositories. If you
 
  choose a location which contains existing repositories RhodeCode will simply 
 
  add all of the repositories at the chosen location to it's database. 
 
  (Note: make sure you specify the correct path to the root).
 
- Note: the given path for mercurial_ repositories **must** be write accessible
 
  for the application. It's very important since the RhodeCode web interface 
 
  will work without write access, but when trying to do a push it will 
 
  eventually fail with permission denied errors unless it has write access.
 

	
 
You are now ready to use RhodeCode, to run it simply execute::
 
 
 
    paster serve production.ini
 
 
 
- This command runs the RhodeCode server. The web app should be available at the 
 
  127.0.0.1:5000. This ip and port is configurable via the production.ini 
 
  file created in previous step
 
- Use the admin account you created above when running ``setup-rhodecode`` 
 
  to login to the web app.
 
- The default permissions on each repository is read, and the owner is admin. 
 
  Remember to update these if needed.
 
- In the admin panel you can toggle ldap, anonymous, permissions settings. As
 
  well as edit more advanced options on users and repositories
 

	
 
Optionally users can create `rcextensions` package that extends RhodeCode
 
functionality. To do this simply execute::
 

	
 
    paster make-rcext production.ini
 

	
 
This will create `rcextensions` package in the same place that your `ini` file
 
lives. With `rcextensions` it's possible to add additional mapping for whoosh, 
 
stats and add additional code into the push/pull/create repo hooks. For example
 
for sending signals to build-bots such as jenkins.
 
stats and add additional code into the push/pull/create/delete repo hooks.
 
For example for sending signals to build-bots such as jenkins.
 
Please see the `__init__.py` file inside `rcextensions` package 
 
for more details.
 

	
 

	
 
Using RhodeCode with SSH
 
------------------------
 

	
 
RhodeCode currently only hosts repositories using http and https. (The addition
 
of ssh hosting is a planned future feature.) However you can easily use ssh in
 
parallel with RhodeCode. (Repository access via ssh is a standard "out of
 
the box" feature of mercurial_ and you can use this to access any of the
 
repositories that RhodeCode is hosting. See PublishingRepositories_)
 

	
 
RhodeCode repository structures are kept in directories with the same name 
 
as the project. When using repository groups, each group is a subdirectory.
 
This allows you to easily use ssh for accessing repositories.
 

	
 
In order to use ssh you need to make sure that your web-server and the users 
 
login accounts have the correct permissions set on the appropriate directories.
 
(Note that these permissions are independent of any permissions you have set up
 
using the RhodeCode web interface.)
 

	
 
If your main directory (the same as set in RhodeCode settings) is for example
 
set to **/home/hg** and the repository you are using is named `rhodecode`, then
 
to clone via ssh you should run::
 

	
 
    hg clone ssh://user@server.com/home/hg/rhodecode
 

	
 
Using other external tools such as mercurial-server_ or using ssh key based
 
authentication is fully supported.
 

	
 
Note: In an advanced setup, in order for your ssh access to use the same
 
permissions as set up via the RhodeCode web interface, you can create an
 
authentication hook to connect to the rhodecode db and runs check functions for
 
permissions against that.
 
    
 
Setting up Whoosh full text search
 
----------------------------------
 

	
 
Starting from version 1.1 the whoosh index can be build by using the paster
 
command ``make-index``. To use ``make-index`` you must specify the configuration
 
file that stores the location of the index. You may specify the location of the 
 
repositories (`--repo-location`).  If not specified, this value is retrieved 
 
from the RhodeCode database.  This was required prior to 1.2.  Starting from 
 
version 1.2 it is also possible to specify a comma separated list of 
 
repositories (`--index-only`) to build index only on chooses repositories 
 
skipping any other found in repos location
 

	
 
You may optionally pass the option `-f` to enable a full index rebuild. Without
 
the `-f` option, indexing will run always in "incremental" mode.
 

	
 
For an incremental index build use::
 

	
 
	paster make-index production.ini 
 

	
 
For a full index rebuild use::
 

	
 
	paster make-index production.ini -f 
 

	
 

	
 
building index just for chosen repositories is possible with such command::
 
 
 
 paster make-index production.ini --index-only=vcs,rhodecode
 

	
 

	
 
In order to do periodical index builds and keep your index always up to date.
 
It's recommended to do a crontab entry for incremental indexing. 
 
An example entry might look like this::
 
 
 
    /path/to/python/bin/paster make-index /path/to/rhodecode/production.ini 
 
  
 
When using incremental mode (the default) whoosh will check the last
 
modification date of each file and add it to be reindexed if a newer file is
 
available. The indexing daemon checks for any removed files and removes them
 
from index.
 

	
 
If you want to rebuild index from scratch, you can use the `-f` flag as above,
 
or in the admin panel you can check `build from scratch` flag.
 

	
 

	
 
Setting up LDAP support
 
-----------------------
 

	
 
RhodeCode starting from version 1.1 supports ldap authentication. In order
 
to use LDAP, you have to install the python-ldap_ package. This package is 
 
available via pypi, so you can install it by running
 

	
 
using easy_install::
 

	
 
    easy_install python-ldap
 
 
 
using pip::
 

	
 
    pip install python-ldap
 

	
 
.. note::
 
   python-ldap requires some certain libs on your system, so before installing 
 
   it check that you have at least `openldap`, and `sasl` libraries.
 

	
 
LDAP settings are located in admin->ldap section,
 

	
 
Here's a typical ldap setup::
 

	
 
 Connection settings
 
 Enable LDAP          = checked
 
 Host                 = host.example.org
 
 Port                 = 389
 
 Account              = <account>
 
 Password             = <password>
 
 Connection Security  = LDAPS connection
 
 Certificate Checks   = DEMAND
 

	
 
 Search settings
 
 Base DN              = CN=users,DC=host,DC=example,DC=org
 
 LDAP Filter          = (&(objectClass=user)(!(objectClass=computer)))
 
 LDAP Search Scope    = SUBTREE
 

	
 
 Attribute mappings
 
 Login Attribute      = uid
 
 First Name Attribute = firstName
 
 Last Name Attribute  = lastName
 
 E-mail Attribute     = mail
 

	
 
.. _enable_ldap:
 

	
 
Enable LDAP : required
 
    Whether to use LDAP for authenticating users.
 

	
 
.. _ldap_host:
 

	
 
Host : required
 
    LDAP server hostname or IP address.
 

	
 
.. _Port:
 

	
 
Port : required
 
    389 for un-encrypted LDAP, 636 for SSL-encrypted LDAP.
 

	
 
.. _ldap_account:
 

	
 
Account : optional
 
    Only required if the LDAP server does not allow anonymous browsing of
 
    records.  This should be a special account for record browsing.  This
 
    will require `LDAP Password`_ below.
 

	
 
.. _LDAP Password:
 

	
 
Password : optional
 
    Only required if the LDAP server does not allow anonymous browsing of
 
    records.
 

	
 
.. _Enable LDAPS:
 

	
 
Connection Security : required
 
    Defines the connection to LDAP server
 

	
 
    No encryption
 
        Plain non encrypted connection
 
        
 
    LDAPS connection
 
        Enable ldaps connection. It will likely require `Port`_ to be set to 
 
        a different value (standard LDAPS port is 636). When LDAPS is enabled 
 
        then `Certificate Checks`_ is required.
 
        
 
    START_TLS on LDAP connection
 
        START TLS connection
 

	
 
.. _Certificate Checks:
 

	
 
Certificate Checks : optional
 
    How SSL certificates verification is handled - this is only useful when
 
    `Enable LDAPS`_ is enabled.  Only DEMAND or HARD offer full SSL security 
 
    while the other options are susceptible to man-in-the-middle attacks.  SSL
 
    certificates can be installed to /etc/openldap/cacerts so that the
 
    DEMAND or HARD options can be used with self-signed certificates or
 
    certificates that do not have traceable certificates of authority.
 

	
 
    NEVER
 
        A serve certificate will never be requested or checked.
 

	
 
    ALLOW
 
        A server certificate is requested.  Failure to provide a
 
        certificate or providing a bad certificate will not terminate the
 
        session.
 

	
 
    TRY
 
        A server certificate is requested.  Failure to provide a
 
        certificate does not halt the session; providing a bad certificate
 
        halts the session.
 

	
 
    DEMAND
 
        A server certificate is requested and must be provided and
0 comments (0 inline, 0 general)