Login Attribute : required

    The LDAP record attribute that will be matched as the USERNAME or

    ACCOUNT used to connect to RhodeCode.  This will be added to `LDAP

    Filter`_ for locating the User object.  If `LDAP Filter`_ is specified as

    "LDAPFILTER", `Login Attribute`_ is specified as "uid" and the user has

    connected as "jsmith" then the `LDAP Filter`_ will be augmented as below

    ::

        (&(LDAPFILTER)(uid=jsmith))

.. _ldap_attr_firstname:

First Name Attribute : required

    The LDAP record attribute which represents the user's first name.

.. _ldap_attr_lastname:

Last Name Attribute : required

    The LDAP record attribute which represents the user's last name.

.. _ldap_attr_email:

Email Attribute : required

    The LDAP record attribute which represents the user's email address.

If all data are entered correctly, and python-ldap_ is properly installed

users should be granted access to RhodeCode with ldap accounts.  At this

time user information is copied from LDAP into the RhodeCode user database.

This means that updates of an LDAP user object may not be reflected as a

user update in RhodeCode.

If You have problems with LDAP access and believe You entered correct

information check out the RhodeCode logs, any error messages sent from LDAP

will be saved there.

Active Directory

''''''''''''''''

RhodeCode can use Microsoft Active Directory for user authentication.  This

is done through an LDAP or LDAPS connection to Active Directory.  The

following LDAP configuration settings are typical for using Active

Directory ::

 Base DN              = OU=SBSUsers,OU=Users,OU=MyBusiness,DC=v3sys,DC=local

 Login Attribute      = sAMAccountName

 First Name Attribute = givenName

 Last Name Attribute  = sn

 E-mail Attribute     = mail

All other LDAP settings will likely be site-specific and should be

appropriately configured.

Authentication by container or reverse-proxy

--------------------------------------------

Starting with version 1.3, RhodeCode supports delegating the authentication

of users to its WSGI container, or to a reverse-proxy server through which all

clients access the application.

When these authentication methods are enabled in RhodeCode, it uses the

username that the container/proxy (Apache/Nginx/etc) authenticated and doesn't

perform the authentication itself. The authorization, however, is still done by

RhodeCode according to its settings.

When a user logs in for the first time using these authentication methods,

a matching user account is created in RhodeCode with default permissions. An

administrator can then modify it using RhodeCode's admin interface.

It's also possible for an administrator to create accounts and configure their

permissions before the user logs in for the first time.

Container-based authentication

''''''''''''''''''''''''''''''

In a container-based authentication setup, RhodeCode reads the user name from

the ``REMOTE_USER`` server variable provided by the WSGI container.

After setting up your container (see `Apache's WSGI config`_), you'd need

to configure it to require authentication on the location configured for

RhodeCode.

In order for RhodeCode to start using the provided username, you should set the

following in the [app:main] section of your .ini file::

    container_auth_enabled = true

Proxy pass-through authentication

'''''''''''''''''''''''''''''''''

In a proxy pass-through authentication setup, RhodeCode reads the user name

from the ``X-Forwarded-User`` request header, which should be configured to be

sent by the reverse-proxy server.

After setting up your proxy solution (see `Apache virtual host reverse proxy example`_,

`Apache as subdirectory`_ or `Nginx virtual host example`_), you'd need to

configure the authentication and add the username in a request header named

``X-Forwarded-User``.

For example, the following config section for Apache sets a subdirectory in a

reverse-proxy setup with basic auth::

    <Location /<someprefix> >

      ProxyPass http://127.0.0.1:5000/<someprefix>

      ProxyPassReverse http://127.0.0.1:5000/<someprefix>

      SetEnvIf X-Url-Scheme https HTTPS=1

      AuthType Basic

      AuthName "RhodeCode authentication"

      AuthUserFile /home/web/rhodecode/.htpasswd

      require valid-user

      RequestHeader unset X-Forwarded-User

      RewriteEngine On

      RewriteCond %{LA-U:REMOTE_USER} (.+)

      RewriteRule .* - [E=RU:%1]

      RequestHeader set X-Forwarded-User %{RU}e

    </Location>

In order for RhodeCode to start using the forwarded username, you should set

the following in the [app:main] section of your .ini file::

    proxypass_auth_enabled = true

.. note::

   If you enable proxy pass-through authentication, make sure your server is

   only accessible through the proxy. Otherwise, any client would be able to

   forge the authentication header and could effectively become authenticated

   using any account of their liking.

Integration with Issue trackers

-------------------------------

RhodeCode provides a simple integration with issue trackers. It's possible

to define a regular expression that will fetch issue id stored in commit

messages and replace that with an url to this issue. To enable this simply

uncomment following variables in the ini file::

    url_pat = (?:^#|\s#)(\w+)

    issue_server_link = https://myissueserver.com/{repo}/issue/{id}

    issue_prefix = #

`url_pat` is the regular expression that will fetch issues from commit messages.

Default regex will match issues in format of #<number> eg. #300.

Matched issues will be replace with the link specified as `issue_server_link`

{id} will be replaced with issue id, and {repo} with repository name.

Since the # is striped `issue_prefix` is added as a prefix to url.

`issue_prefix` can be something different than # if you pass

ISSUE- as issue prefix this will generate an url in format::

  <a href="https://myissueserver.com/example_repo/issue/300">ISSUE-300</a>

Hook management

---------------

Hooks can be managed in similar way to this used in .hgrc files.

To access hooks setting click `advanced setup` on Hooks section of Mercurial

Settings in Admin.

There are 4 built in hooks that cannot be changed (only enable/disable by

checkboxes on previos section).

To add another custom hook simply fill in first section with

<name>.<hook_type> and the second one with hook path. Example hooks

can be found at *rhodecode.lib.hooks*.

Changing default encoding

-------------------------

By default RhodeCode uses utf8 encoding, starting from 1.3 series this

can be changed, simply edit default_encoding in .ini file to desired one.

This affects many parts in rhodecode including commiters names, filenames,

encoding of commit messages. In addition RhodeCode can detect if `chardet`

library is installed. If `chardet` is detected RhodeCode will fallback to it

when there are encode/decode errors.

Setting Up Celery

-----------------

Since version 1.1 celery is configured by the rhodecode ini configuration files.

Simply set use_celery=true in the ini file then add / change the configuration

variables inside the ini file.

Remember that the ini files use the format with '.' not with '_' like celery.

So for example setting `BROKER_HOST` in celery means setting `broker.host` in

the config file.

In order to start using celery run::

 paster celeryd <configfile.ini>

.. note::

   Make sure you run this command from the same virtualenv, and with the same

   user that rhodecode runs.

HTTPS support

-------------

There are two ways to enable https:

- Set HTTP_X_URL_SCHEME in your http server headers, than rhodecode will

  recognize this headers and make proper https redirections

- Alternatively, change the `force_https = true` flag in the ini configuration

  to force using https, no headers are needed than to enable https

Nginx virtual host example

--------------------------

Sample config for nginx using proxy::

    upstream rc {

        server 127.0.0.1:5000;

        # add more instances for load balancing

        #server 127.0.0.1:5001;

        #server 127.0.0.1:5002;

    }

    server {

       listen          443;

       server_name     rhodecode.myserver.com;

       access_log      /var/log/nginx/rhodecode.access.log;

       error_log       /var/log/nginx/rhodecode.error.log;

       ssl on;

       ssl_certificate     rhodecode.myserver.com.crt;

       ssl_certificate_key rhodecode.myserver.com.key;

       ssl_session_timeout 5m;

       ssl_protocols SSLv3 TLSv1;

       ssl_ciphers DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:EDH-RSA-DES-CBC3-SHA:AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5;

       ssl_prefer_server_ciphers on;

       # uncomment if you have nginx with chunking module compiled

       # fixes the issues of having to put postBuffer data for large git

       # pushes

       #chunkin on;

       #error_page 411 = @my_411_error;

       #location @my_411_error {

       #    chunkin_resume;

       #}

       # uncomment if you want to serve static files by nginx

       #root /path/to/installation/rhodecode/public;

       location / {

            try_files $uri @rhode;

       }

       location @rhode {

            proxy_pass      http://rc;

            include         /etc/nginx/proxy.conf;

       }

    }

Here's the proxy.conf. It's tuned so it will not timeout on long

pushes or large pushes::

    proxy_redirect              off;

    proxy_set_header            Host $host;

    proxy_set_header            X-Url-Scheme $scheme;

    proxy_set_header            X-Host $http_host;

    proxy_set_header            X-Real-IP $remote_addr;

    proxy_set_header            X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_set_header            Proxy-host $proxy_host;

    client_max_body_size        400m;

    client_body_buffer_size     128k;

    proxy_buffering             off;

    proxy_connect_timeout       7200;

    proxy_send_timeout          7200;

    proxy_read_timeout          7200;

    proxy_buffers               8 32k;

Also, when using root path with nginx you might set the static files to false

in the production.ini file::

    [app:main]

      use = egg:rhodecode

      full_stack = true

      static_files = false

      lang=en

      cache_dir = %(here)s/data

In order to not have the statics served by the application. This improves speed.

Apache virtual host reverse proxy example

-----------------------------------------

Here is a sample configuration file for apache using proxy::

    <VirtualHost *:80>

            ServerName hg.myserver.com

            ServerAlias hg.myserver.com

            <Proxy *>

              Order allow,deny

              Allow from all

            </Proxy>

            #important !

            #Directive to properly generate url (clone url) for pylons

            ProxyPreserveHost On

            #rhodecode instance

            ProxyPass / http://127.0.0.1:5000/

            ProxyPassReverse / http://127.0.0.1:5000/

            #to enable https use line below

            #SetEnvIf X-Url-Scheme https HTTPS=1

    </VirtualHost>

Additional tutorial

http://wiki.pylonshq.com/display/pylonscookbook/Apache+as+a+reverse+proxy+for+Pylons

Apache as subdirectory

----------------------

Apache subdirectory part::

    <Location /<someprefix> >

      ProxyPass http://127.0.0.1:5000/<someprefix>

      ProxyPassReverse http://127.0.0.1:5000/<someprefix>

      SetEnvIf X-Url-Scheme https HTTPS=1

    </Location>

Besides the regular apache setup you will need to add the following line

into [app:main] section of your .ini file::

    filter-with = proxy-prefix

Add the following at the end of the .ini file::

    [filter:proxy-prefix]

    use = egg:PasteDeploy#prefix

    prefix = /<someprefix>

then change <someprefix> into your choosen prefix

Apache's WSGI config

--------------------

Alternatively, RhodeCode can be set up with Apache under mod_wsgi. For

that, you'll need to:

- Install mod_wsgi. If using a Debian-based distro, you can install

  the package libapache2-mod-wsgi::

    aptitude install libapache2-mod-wsgi

- Enable mod_wsgi::

    a2enmod wsgi

- Create a wsgi dispatch script, like the one below. Make sure you

  check the paths correctly point to where you installed RhodeCode

  and its Python Virtual Environment.

- Enable the WSGIScriptAlias directive for the wsgi dispatch script,

  as in the following example. Once again, check the paths are

  correctly specified.

Here is a sample excerpt from an Apache Virtual Host configuration file::

    WSGIDaemonProcess pylons \

        threads=4 \

        python-path=/home/web/rhodecode/pyenv/lib/python2.6/site-packages

    WSGIScriptAlias / /home/web/rhodecode/dispatch.wsgi

    WSGIPassAuthorization On

.. note::

   when running apache as root please add: `user=www-data group=www-data`

   into above configuration

.. note::

Example wsgi dispatch script::

    import os

    os.environ["HGENCODING"] = "UTF-8"

    os.environ['PYTHON_EGG_CACHE'] = '/home/web/rhodecode/.egg-cache'

    # sometimes it's needed to set the curent dir

    os.chdir('/home/web/rhodecode/')

    import site

    site.addsitedir("/home/web/rhodecode/pyenv/lib/python2.6/site-packages")

    from paste.deploy import loadapp

    from paste.script.util.logging_config import fileConfig

    fileConfig('/home/web/rhodecode/production.ini')

    application = loadapp('config:/home/web/rhodecode/production.ini')

Note: when using mod_wsgi you'll need to install the same version of

Mercurial that's inside RhodeCode's virtualenv also on the system's Python

environment.

Other configuration files

-------------------------

Some example init.d scripts can be found in init.d directory::

  https://secure.rhodecode.org/rhodecode/files/beta/init.d

.. _virtualenv: http://pypi.python.org/pypi/virtualenv

.. _python: http://www.python.org/

.. _mercurial: http://mercurial.selenic.com/

.. _celery: http://celeryproject.org/

.. _rabbitmq: http://www.rabbitmq.com/

.. _python-ldap: http://www.python-ldap.org/

.. _mercurial-server: http://www.lshift.net/mercurial-server.html

.. _PublishingRepositories: http://mercurial.selenic.com/wiki/PublishingRepositories

.. _Issues tracker: https://bitbucket.org/marcinkuzminski/rhodecode/issues

.. _google group rhodecode: http://groups.google.com/group/rhodecode

.. _upgrade:

=======

Upgrade

=======

Upgrading from PyPI (aka "Cheeseshop")

---------------------------------------

.. note::

   Firstly, it is recommended that you **always** perform a database and

   configuration backup before doing an upgrade.

   (These directions will use '{version}' to note that this is the version of

   Rhodecode that these files were used with.  If backing up your RhodeCode

   instance from version 1.3.6 to 1.4.0, the ``production.ini`` file would be

   backed up to ``production.ini.1-3-6``.)

If using a sqlite database, stop the Rhodecode process/daemon/service, and

then make a copy of the database file::

 service rhodecode stop

 cp rhodecode.db rhodecode.db.{version}

Back up your configuration file::

 cp production.ini production.ini.{version}

Ensure that you are using the Python Virtual Environment that you'd originally

installed Rhodecode in::

 pip freeze

will list all packages installed in the current environment.  If Rhodecode

isn't listed, change virtual environments to your venv location::

 source /opt/rhodecode-venv/bin/activate

Once you have verified the environment you can upgrade ``Rhodecode`` with::

 easy_install -U rhodecode

Or::

 pip install --upgrade rhodecode

Then run the following command from the installation directory::

 paster make-config RhodeCode production.ini

This will display any changes made by the new version of RhodeCode to your

current configuration. It will try to perform an automerge. It's recommended

that you re-check the content after the automerge.

.. note::

   Please always make sure your .ini files are up to date. Often errors are

   caused by missing params added in new versions.

It is also recommended that you rebuild the whoosh index after upgrading since

the new whoosh version could introduce some incompatible index changes. Please

Read the changelog to see if there were any changes to whoosh.

The final step is to upgrade the database. To do this simply run::

 paster upgrade-db production.ini

This will upgrade the schema and update some of the defaults in the database,

and will always recheck the settings of the application, if there are no new

options that need to be set.

You may find it helpful to clear out your log file so that new errors are

readily apparent::

 echo > rhodecode.log

Once that is complete, you may now start your upgraded Rhodecode Instance::

 service rhodecode start

Or::

 paster serve /var/www/rhodecode/production.ini

.. note::

   If you're using Celery, make sure you restart all instances of it after

   upgrade.

.. _virtualenv: http://pypi.python.org/pypi/virtualenv

.. _python: http://www.python.org/

.. _mercurial: http://mercurial.selenic.com/

.. _celery: http://celeryproject.org/

.. _rabbitmq: http://www.rabbitmq.com/

.. _general:

=======================

General RhodeCode usage

=======================

Repository deleting

-------------------

Currently when admin/owner deletes a repository, RhodeCode does not physically

delete a repository from filesystem, it renames it in a special way so it's

not possible to push,clone or access repository. It's worth a notice that,

even if someone will be given administrative access to RhodeCode and will

delete a repository You can easy restore such action by restoring `rm__<date>`

Follow current branch in file view

----------------------------------

In file view when this checkbox is checked the << and >> arrows will jump

to changesets within the same branch currently viewing. So for example

if someone is viewing files at 'beta' branch and marks `follow current branch`

checkbox the << and >> buttons will only show him revisions for 'beta' branch

Compare view from changelog

---------------------------

Checkboxes in compare view allow users to view combined compare view. You can

only show the range between the first and last checkbox (no cherry pick).

Clicking more than one checkbox will activate a link in top saying

`Show selected changes <from-rev> -> <to-rev>` clicking this will bring

Compare view is also available from the journal on pushes having more than

one changeset

Non changeable repository urls

------------------------------

Due to complicated nature of repository grouping, often urls of repositories

can change.

example::

  #before

  http://server.com/repo_name

  # after insertion to test_group group the url will be

  http://server.com/test_group/repo_name

This can be an issue for build systems and any other hardcoded scripts, moving

repository to a group leads to a need for changing external systems. To

overcome this RhodeCode introduces a non changable replacement url. It's

simply an repository ID prefixed with `_` above urls are also accessible as::

  http://server.com/_<ID>

Since ID are always the same moving the repository will not affect such url.

the _<ID> syntax can be used anywhere in the system so urls with repo_name

for changelogs, files and other can be exchanged with _<ID> syntax.

Mailing

-------

When administrator will fill up the mailing settings in .ini files

RhodeCode will send mails on user registration, or when RhodeCode errors occur

on errors the mails will have a detailed traceback of error.

Mails are also sent for code comments. If someone comments on a changeset

mail is sent to all participants, the person who commited the changeset

(if present in RhodeCode), and to all people mentioned with @mention system.

Trending source files

---------------------

Trending source files are calculated based on pre defined dict of known

types and extensions. If You miss some extension or Would like to scan some

custom files it's possible to add new types in `LANGUAGES_EXTENSIONS_MAP` dict

located in `/rhodecode/lib/celerylib/tasks.py`

Cloning remote repositories

---------------------------

RhodeCode has an ability to clone remote repos from given remote locations.

Currently it support following options:

- hg  -> hg clone

- svn -> hg clone

- git -> git clone

.. note::

    - *`svn -> hg` cloning requires `hgsubversion` library to be installed.*

If you need to clone repositories that are protected via basic auth, you

might pass the url with stored credentials inside eg.

`http://user:passw@remote.server/repo, RhodeCode will try to login and clone

using given credentials. Please take a note that they will be stored as

plaintext inside the database. RhodeCode will remove auth info when showing the

clone url in summary page.