Changeset - 6bad83d27fc1
[Not reviewed]
beta
0 1 0
Magnus Ericmats - 13 years ago 2013-04-26 20:54:25
magnus.ericmats@gmail.com
Grafted from: 4518c0d249ae
Documentation: How to setup LDAP Filter when using Organisational Units.
1 file changed with 7 insertions and 0 deletions:
0 comments (0 inline, 0 general)
docs/setup.rst
Show inline comments
 
@@ -7,384 +7,391 @@ 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/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
 

	
 
If your user groups are placed in a Organisation Unit (OU) structure the Search Settings configuration differs::
 

	
 
 Search settings
 
 Base DN              = DC=host,DC=example,DC=org
 
 LDAP Filter          = (&(memberOf=CN=your user group,OU=subunit,OU=unit,DC=host,DC=example,DC=org)(objectClass=user))
 
 LDAP Search Scope    = SUBTREE
 

	
 
.. _enable_ldap:
 

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

	
 
.. _ldap_host:
 

	
 
Host : required
 
    LDAP server hostname or IP address. Can be also a comma separated
 
    list of servers to support LDAP fail-over.
 

	
 
.. _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
 
        authenticated for the session to proceed.
 

	
 
    HARD
 
        The same as DEMAND.
 

	
 
.. _Base DN:
 

	
 
Base DN : required
 
    The Distinguished Name (DN) where searches for users will be performed.
 
    Searches can be controlled by `LDAP Filter`_ and `LDAP Search Scope`_.
 

	
 
.. _LDAP Filter:
 

	
 
LDAP Filter : optional
 
    A LDAP filter defined by RFC 2254.  This is more useful when `LDAP
 
    Search Scope`_ is set to SUBTREE.  The filter is useful for limiting
 
    which LDAP objects are identified as representing Users for
 
    authentication.  The filter is augmented by `Login Attribute`_ below.
 
    This can commonly be left blank.
 

	
 
.. _LDAP Search Scope:
 

	
 
LDAP Search Scope : required
 
    This limits how far LDAP will search for a matching object.
 

	
 
    BASE
 
        Only allows searching of `Base DN`_ and is usually not what you
 
        want.
 

	
 
    ONELEVEL
 
        Searches all entries under `Base DN`_, but not Base DN itself.
 

	
 
    SUBTREE
 
        Searches all entries below `Base DN`_, but not Base DN itself.
 
        When using SUBTREE `LDAP Filter`_ is useful to limit object
 
        location.
 

	
 
.. _Login Attribute:
 

	
 
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::
0 comments (0 inline, 0 general)