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.

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*. 

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: