docs: added SAML documentation.
- Remove few obsolete replaces - update authentication docs - cleanups and fixes
This commit is contained in:
parent
909181f429
commit
cbff54d3ed
72 changed files with 657 additions and 298 deletions
|
|
@ -3,19 +3,19 @@
|
|||
Anonymous Users
|
||||
---------------
|
||||
|
||||
By default, |RCM| provides |repo| access for registered users only. It can be
|
||||
By default, |RCE| provides |repo| access for registered users only. It can be
|
||||
configured to be **world-open** in terms of read and write permissions. This
|
||||
configuration is called "Anonymous Access" and allows |RCM| to be used as a
|
||||
configuration is called "Anonymous Access" and allows |RCE| to be used as a
|
||||
public hub where unregistered users have access to your |repos|.
|
||||
|
||||
Anonymous access is useful for open source projects, universities,
|
||||
or if running inside a restricted internal corporate network to serve
|
||||
documents to all employees. Anonymous users get the default user permission
|
||||
settings that are applied across the whole |RCM| system.
|
||||
settings that are applied across the whole |RCE| system.
|
||||
|
||||
To enable anonymous access to your |repos|, use the following steps:
|
||||
|
||||
1. From the |RCM| interface, select :menuselection:`Admin --> Permissions`.
|
||||
1. From the |RCE| interface, select :menuselection:`Admin --> Permissions`.
|
||||
2. On the Application tab, check the :guilabel:`Allow anonymous access` box.
|
||||
3. Select :guilabel:`Save`.
|
||||
4. To set the anonymous user access permissions, which are based on the
|
||||
|
|
|
|||
|
|
@ -166,7 +166,7 @@ To add custom hooks to your instance, use the following steps:
|
|||
``pretxnchangegroup.example`` with value ``python:/path/to/custom_hook.py:my_func_name``
|
||||
3. Select :guilabel:`Save`
|
||||
|
||||
Also, see the |RC| Extensions section of the :ref:`rc-tools` guide. |RC|
|
||||
Also, see the RhodeCode Extensions section of the :ref:`rc-tools` guide. RhodeCode
|
||||
Extensions can be used to add additional hooks to your instance and comes
|
||||
with a number of pre-built plugins if you chose to install them.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Apache WSGI Configuration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|RCM| can also be set up with Apache under ``mod_wsgi``. To configure this
|
||||
|RCE| can also be set up with Apache under ``mod_wsgi``. To configure this
|
||||
use the following steps.
|
||||
|
||||
1. Install ``mod_wsgi`` using the following command:
|
||||
|
|
@ -50,6 +50,6 @@ The following is an example ``wsgi`` dispatch script.
|
|||
.. note::
|
||||
|
||||
When using `mod_wsgi` the same version of |hg| must be running in your
|
||||
system's |PY| environment and on |RCM|. To check the |RCM| version,
|
||||
system's |PY| environment and on |RCE|. To check the |RCE| version,
|
||||
on the interface go to
|
||||
:menuselection:`Admin --> Settings --> System Info`
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ sections.
|
|||
Default location: :file:`/home/{user}/.rccontrol/cache/MANIFEST`
|
||||
|
||||
|RCC| uses this file to source the latest available builds from the
|
||||
secure |RC| download channels. The only reason to mess with this file
|
||||
secure RhodeCode download channels. The only reason to mess with this file
|
||||
is if you need to do an offline installation,
|
||||
see the :ref:`Offline Installation<control:offline-installer-ref>`
|
||||
instructions, otherwise |RCC| will completely manage this file.
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Glossary
|
|||
Adding more machines or workers into your pool of resources.
|
||||
|
||||
Instance
|
||||
A single installed version of one of the |RC| products. It could
|
||||
A single installed version of one of the RhodeCode products. It could
|
||||
refer to |RCE| or the VCS server depending on the context.
|
||||
|
||||
Plugin
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Full-text Search
|
||||
----------------
|
||||
|
||||
By default |RC| is configured to use `Whoosh`_ to index |repos| and
|
||||
By default RhodeCode is configured to use `Whoosh`_ to index |repos| and
|
||||
provide full-text search.
|
||||
|
||||
|RCE| also provides support for `Elasticsearch`_ as a backend for scalable
|
||||
|
|
@ -46,7 +46,7 @@ Configure the ``.rhoderc`` File
|
|||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|RCT| uses the :file:`/home/{user}/.rhoderc` file for connection details
|
||||
to |RCM| instances. If this file is not automatically created,
|
||||
to |RCE| instances. If this file is not automatically created,
|
||||
you can configure it using the following example. You need to configure the
|
||||
details for each instance you want to index.
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ details for each instance you want to index.
|
|||
- VERSION: 1.5.0
|
||||
- URL: http://127.0.0.1:10000
|
||||
|
||||
To get your API Token, on the |RCM| interface go to
|
||||
To get your API Token, on the |RCE| interface go to
|
||||
:menuselection:`username --> My Account --> Auth tokens`
|
||||
|
||||
.. code-block:: ini
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Public Access
|
||||
-------------
|
||||
|
||||
By default |RCM| allows users to read all **public** |repos|. User
|
||||
By default |RCE| allows users to read all **public** |repos|. User
|
||||
permissions and |repo| access can be configured explicitly,
|
||||
and those permissions will override any default settings. The default
|
||||
settings can be found under the following section:
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Setting Default Permissions
|
||||
---------------------------
|
||||
|
||||
Default permissions allow you to configure |RCM| so that when a new |repo|, user group,
|
||||
Default permissions allow you to configure |RCE| so that when a new |repo|, user group,
|
||||
or user is created their permissions are already defined. To set default permissions you need administrator
|
||||
privileges. See the following sections for setting up your permissions system:
|
||||
|
||||
|
|
@ -19,7 +19,7 @@ Setting User defaults
|
|||
|
||||
To set default user permissions, use the following steps.
|
||||
|
||||
1. From the |RCM| interface, select :menuselection:`Admin --> Permissions`
|
||||
1. From the |RCE| interface, select :menuselection:`Admin --> Permissions`
|
||||
2. Select the :guilabel:`Global` tab from the left-hand menu. The permissions
|
||||
set on this screen apply to users and user-groups across the whole instance.
|
||||
3. Save your changes
|
||||
|
|
@ -31,7 +31,7 @@ Setting User Group defaults
|
|||
|
||||
To set default user group permissions, use the following steps.
|
||||
|
||||
1. From the |RCM| interface, select :menuselection:`Admin --> User groups`
|
||||
1. From the |RCE| interface, select :menuselection:`Admin --> User groups`
|
||||
2. Select :guilabel:`Permissions`, and configure the default user
|
||||
permissions. All users will get these permissions unless
|
||||
individually set.
|
||||
|
|
@ -48,7 +48,7 @@ Setting Repository defaults
|
|||
|
||||
To set default |repo| permissions, use the following steps.
|
||||
|
||||
1. From the |RCM| interface, select :menuselection:`Admin --> Permissions`
|
||||
1. From the |RCE| interface, select :menuselection:`Admin --> Permissions`
|
||||
2. Select the :guilabel:`Object` tab from the left-hand menu and set the
|
||||
|perm| permissions
|
||||
3. Save your changes
|
||||
|
|
@ -60,7 +60,7 @@ Setting Repository Group defaults
|
|||
|
||||
To set default Repository Group permissions, use the following steps.
|
||||
|
||||
1. From the |RCM| interface, select :menuselection:`Admin --> Repository Groups`
|
||||
1. From the |RCE| interface, select :menuselection:`Admin --> Repository Groups`
|
||||
2. Select :guilabel:`Edit` beside the |repo| group you wish to configure
|
||||
3. On the left-hand pane select :guilabel:`Permissions`
|
||||
4. Set the default permissions for all |repos| created in this group
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@
|
|||
Repository Administration
|
||||
=========================
|
||||
|
||||
Repository permissions in |RCM| can be managed in a number of different ways.
|
||||
Repository permissions in |RCE| can be managed in a number of different ways.
|
||||
This overview should give you an insight into how you could adopt particular
|
||||
settings for your needs:
|
||||
|
||||
* Global |repo| permissions: This allows you to set the default permissions
|
||||
for each new |repo| created within |RCM|, see :ref:`repo-default-ref`. All
|
||||
for each new |repo| created within |RCE|, see :ref:`repo-default-ref`. All
|
||||
|repos| created will inherit these permissions unless explicitly configured.
|
||||
* Individual |repo| permissions: To set individual |repo| permissions,
|
||||
see :ref:`set-repo-perms`.
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ Supported Browsers
|
|||
System Requirements
|
||||
-------------------
|
||||
|
||||
|RCM| performs best on machines with ultra-fast hard disks. Generally disk
|
||||
|RCE| performs best on machines with ultra-fast hard disks. Generally disk
|
||||
performance is more important than CPU performance. In a corporate production
|
||||
environment handling 1000s of users and |repos| you should deploy on a 12+
|
||||
core 64GB RAM server. In short, the more RAM the better.
|
||||
|
|
@ -68,7 +68,7 @@ core 64GB RAM server. In short, the more RAM the better.
|
|||
For example:
|
||||
|
||||
- for team of 1 - 5 active users you can run on 1GB RAM machine with 1CPU
|
||||
- above 250 active users, |RCM| needs at least 8GB of memory.
|
||||
- above 250 active users, |RCE| needs at least 8GB of memory.
|
||||
Number of CPUs is less important, but recommended to have at least 2-3 CPUs
|
||||
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ Connection Methods
|
|||
|
||||
* HTTPS
|
||||
* SSH
|
||||
* |RCM| API
|
||||
* |RCE| API
|
||||
|
||||
Internationalization Support
|
||||
----------------------------
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
User Administration
|
||||
===================
|
||||
|
||||
|RCM| enables you to define permissions for the following entities within the
|
||||
|RCE| enables you to define permissions for the following entities within the
|
||||
system; **users**, **user groups**, **repositories**, **repository groups**.
|
||||
|
||||
Within each one of these entities you can set default settings,
|
||||
|
|
|
|||
|
|
@ -3,13 +3,13 @@
|
|||
VCS Server Management
|
||||
---------------------
|
||||
|
||||
The VCS Server handles |RCM| backend functionality. You need to configure
|
||||
a VCS Server to run with a |RCM| instance. If you do not, you will be missing
|
||||
the connection between |RCM| and its |repos|. This will cause error messages
|
||||
The VCS Server handles |RCE| backend functionality. You need to configure
|
||||
a VCS Server to run with a |RCE| instance. If you do not, you will be missing
|
||||
the connection between |RCE| and its |repos|. This will cause error messages
|
||||
on the web interface. You can run your setup in the following configurations,
|
||||
currently the best performance is one of following:
|
||||
|
||||
* One VCS Server per |RCM| instance.
|
||||
* One VCS Server per |RCE| instance.
|
||||
* One VCS Server handling multiple instances.
|
||||
|
||||
.. important::
|
||||
|
|
@ -49,7 +49,7 @@ To configure a |RCE| instance to use a VCS server, see
|
|||
|RCE| VCS Server Options
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The following list shows the available options on the |RCM| side of the
|
||||
The following list shows the available options on the |RCE| side of the
|
||||
connection to the VCS Server. The settings are configured per
|
||||
instance in the
|
||||
:file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file.
|
||||
|
|
@ -75,7 +75,7 @@ instance in the
|
|||
|
||||
\vcs.server <host:port>
|
||||
Set the host, either hostname or IP Address, and port of the VCS server
|
||||
you wish to run with your |RCM| instance.
|
||||
you wish to run with your |RCE| instance.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
|
|
|
|||
|
|
@ -22,12 +22,12 @@ API access can also be turned on for each web view in |RCE| that is
|
|||
decorated with a `@LoginRequired` decorator. To enable API access, change
|
||||
the standard login decorator to `@LoginRequired(api_access=True)`.
|
||||
|
||||
From |RCM| version 1.7.0 you can configure a white list
|
||||
From |RCE| version 1.7.0 you can configure a white list
|
||||
of views that have API access enabled by default. To enable these,
|
||||
edit the |RCM| configuration ``.ini`` file. The default location is:
|
||||
edit the |RCE| configuration ``.ini`` file. The default location is:
|
||||
|
||||
* |RCM| Pre-2.2.7 :file:`root/rhodecode/data/production.ini`
|
||||
* |RCM| 3.0 :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
|
||||
* |RCE| Pre-2.2.7 :file:`root/rhodecode/data/production.ini`
|
||||
* |RCE| 3.0 :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
|
||||
|
||||
To configure the white list, edit this section of the file. In this
|
||||
configuration example, API access is granted to the patch/diff raw file and
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ Crowd
|
|||
|
||||
To enable Crowd authentication, use the following steps:
|
||||
|
||||
1. From the |RCM| interface, go to :menuselection:`Admin --> Authentication`
|
||||
2. Enable the ``rhodecode.lib.auth_modules.auth_crowd`` library and select
|
||||
1. From the |RCE| interface, go to :menuselection:`Admin --> Authentication`
|
||||
2. Activate the ``rhodecode.lib.auth_modules.auth_crowd`` library and select
|
||||
:guilabel:`Save`
|
||||
3. On the Crowd plugin settings section, do the following:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,25 +3,24 @@
|
|||
LDAP/AD With User Groups Sync
|
||||
-----------------------------
|
||||
|
||||
|RCM| supports LDAP (Lightweight Directory Access Protocol) or
|
||||
AD (active Directory) authentication.
|
||||
All LDAP versions are supported, with the following |RCM| plugins managing each:
|
||||
**This plugin is available only in EE Edition.**
|
||||
|
||||
* For LDAP/AD with user group sync use ``LDAP + User Groups (egg:rhodecode-enterprise-ee#ldap_group)``
|
||||
|RCE| supports LDAP (Lightweight Directory Access Protocol) or
|
||||
AD (active Directory) authentication.
|
||||
All LDAP versions are currently supported.
|
||||
|
||||
RhodeCode reads all data defined from plugin and creates corresponding
|
||||
accounts on local database after receiving data from LDAP. This is done on
|
||||
every user log-in including operations like pushing/pulling/checkout.
|
||||
In addition group membership is read from LDAP and following operations are done:
|
||||
|
||||
- automatic addition of user to |RCM| user group
|
||||
- automatic removal of user from any other |RCM| user groups not specified in LDAP.
|
||||
- automatic addition of user to |RCE| user group
|
||||
- automatic removal of user from any other |RCE| user groups not specified in LDAP.
|
||||
The removal is done *only* on groups that are marked to be synced from ldap.
|
||||
This setting can be changed in advanced settings on user groups
|
||||
- automatic creation of user groups if they aren't yet existing in |RCM|
|
||||
- automatic creation of user groups if they aren't yet existing in |RCE|
|
||||
- marking user as super-admins if he is a member of any admin group defined in plugin settings
|
||||
|
||||
This plugin is available only in EE Edition.
|
||||
|
||||
.. important::
|
||||
|
||||
|
|
@ -39,11 +38,12 @@ LDAP Configuration Steps
|
|||
|
||||
To configure |LDAP|, use the following steps:
|
||||
|
||||
1. From the |RCM| interface, select
|
||||
1. From the |RCE| interface, select
|
||||
:menuselection:`Admin --> Authentication`
|
||||
2. Enable the ldap+ groups plugin and select :guilabel:`Save`
|
||||
3. Select the :guilabel:`Enabled` check box in the plugin configuration section
|
||||
4. Add the required LDAP information and :guilabel:`Save`, for more details,
|
||||
2. Activate the `LDAP + User Groups` plugin and select :guilabel:`Save`
|
||||
3. Go to newly available menu option called `LDAP + User Groups` on the left side.
|
||||
4. Check the `enabled` check box in the plugin configuration section,
|
||||
and fill in the required LDAP information and :guilabel:`Save`, for more details,
|
||||
see :ref:`config-ldap-groups-examples`
|
||||
|
||||
For a more detailed description of LDAP objects, see :ref:`ldap-gloss-ref`:
|
||||
|
|
@ -52,59 +52,107 @@ For a more detailed description of LDAP objects, see :ref:`ldap-gloss-ref`:
|
|||
|
||||
Example LDAP configuration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
.. code-block:: bash
|
||||
|
||||
# Auth Cache TTL, Defines the caching for authentication to offload LDAP server.
|
||||
# This means that cache result will be saved for 3600 before contacting LDAP server to verify the user access
|
||||
3600
|
||||
# Host, comma seperated format is optionally possible to specify more than 1 server
|
||||
https://ldap1.server.com/ldap-admin/,https://ldap2.server.com/ldap-admin/
|
||||
# Default LDAP Port, use 689 for LDAPS
|
||||
389
|
||||
# Account, used for SimpleBind if LDAP server requires an authentication
|
||||
e.g admin@server.com
|
||||
# Password used for simple bind
|
||||
ldap-user-password
|
||||
# LDAP connection security
|
||||
LDAPS
|
||||
# Certificate checks level
|
||||
DEMAND
|
||||
# Base DN
|
||||
cn=Rufus Magillacuddy,ou=users,dc=rhodecode,dc=com
|
||||
# User Search Base
|
||||
ou=groups,ou=users
|
||||
# LDAP search filter to narrow the results
|
||||
(objectClass=person)
|
||||
# LDAP search scope
|
||||
SUBTREE
|
||||
# Login attribute
|
||||
sAMAccountName
|
||||
# First Name Attribute to read
|
||||
givenName
|
||||
# Last Name Attribute to read
|
||||
sn
|
||||
# Email Attribute to read email address from
|
||||
mail
|
||||
# group extraction method
|
||||
rfc2307bis
|
||||
# Group search base
|
||||
ou=RC-Groups
|
||||
# Group Name Attribute, field to read the group name from
|
||||
sAMAAccountName
|
||||
# User Member of Attribute, field in which groups are stored
|
||||
memberOf
|
||||
# LDAP Group Search Filter, allows narrowing the results
|
||||
Below is example setup that can be used with Active Directory and LDAP server with groups sync::
|
||||
|
||||
# Admin Groups. Comma separated list of groups. If user is member of
|
||||
# any of those he will be marked as super-admin in RhodeCode
|
||||
admins, management
|
||||
*option*: `enabled` => `True`
|
||||
# Enable or disable this authentication plugin.
|
||||
|
||||
*option*: `cache_ttl` => `360`
|
||||
# Amount of seconds to cache the authentication and permissions check response call for this plugin.
|
||||
# Useful for expensive calls like LDAP to improve the performance of the system (0 means disabled).
|
||||
|
||||
Below is example setup that can be used with Active Directory and ldap groups.
|
||||
*option*: `host` => `192.168.245.143,192.168.1.240`
|
||||
# Host[s] of the LDAP Server
|
||||
# (e.g., 192.168.2.154, or ldap-server.domain.com.
|
||||
# Multiple servers can be specified using commas
|
||||
|
||||
*option*: `port` => `389`
|
||||
# Custom port that the LDAP server is listening on. Default value is: 389, use 689 for LDAPS(SSL)
|
||||
|
||||
*option*: `timeout` => `300`
|
||||
# Timeout for LDAP connection
|
||||
|
||||
*option*: `dn_user` => `Administrator@rhodecode.com`
|
||||
# Optional user DN/account to connect to LDAP if authentication is required.
|
||||
# e.g., cn=admin,dc=mydomain,dc=com, or uid=root,cn=users,dc=mydomain,dc=com, or admin@mydomain.com
|
||||
|
||||
*option*: `dn_pass` => `SomeSecret`
|
||||
# Password to authenticate for given user DN.
|
||||
|
||||
*option*: `tls_kind` => `PLAIN`
|
||||
# TLS Type
|
||||
|
||||
*option*: `tls_reqcert` => `NEVER`
|
||||
# Require Cert over TLS?. Self-signed and custom certificates can be used when
|
||||
# `RhodeCode Certificate` found in admin > settings > system info page is extended.
|
||||
|
||||
*option*: `tls_cert_file` => ``
|
||||
# This specifies the PEM-format file path containing certificates for use in TLS connection.
|
||||
# If not specified `TLS Cert dir` will be used
|
||||
|
||||
*option*: `tls_cert_dir` => `/etc/openldap/cacerts`
|
||||
# This specifies the path of a directory that contains individual CA certificates in separate files.
|
||||
|
||||
*option*: `base_dn` => `dc=rhodecode,dc=com`
|
||||
# Base DN to search. Dynamic bind is supported. Add `$login` marker in it to be replaced with current user credentials
|
||||
# (e.g., dc=mydomain,dc=com, or ou=Users,dc=mydomain,dc=com)
|
||||
|
||||
*option*: `user_search_base` => `ou=RC-Users`
|
||||
# User search base will extend the Base DN
|
||||
# (e.g., ou=Users will result in ou=Users,dc=mydomain,dc=com root DN)
|
||||
|
||||
*option*: `user_search_filter` => ``
|
||||
# Filter to narrow results
|
||||
# (e.g., (&(objectCategory=Person)(objectClass=user)), or
|
||||
# (memberof=cn=rc-login,ou=groups,ou=company,dc=mydomain,dc=com)))
|
||||
|
||||
*option*: `search_scope` => `SUBTREE`
|
||||
# How deep to search LDAP. If unsure set to SUBTREE
|
||||
|
||||
*option*: `attr_login` => `sAMAccountName`
|
||||
# LDAP Attribute to map to user name (e.g., uid, or sAMAccountName)
|
||||
|
||||
*option*: `attr_email` => `mail`
|
||||
# LDAP Attribute to map to email address (e.g., mail).
|
||||
# Emails are a crucial part of RhodeCode.
|
||||
# If possible add a valid email attribute to ldap users.
|
||||
|
||||
*option*: `attr_firstname` => `givenName`
|
||||
# LDAP Attribute to map to first name (e.g., givenName)
|
||||
|
||||
*option*: `attr_lastname` => `sn`
|
||||
# LDAP Attribute to map to last name (e.g., sn)
|
||||
|
||||
*option*: `group_extraction_type` => `rfc2307bis`
|
||||
# With rfc2307, group members are listed by name in the memberUid attribute
|
||||
# With rfc2307bis (Microsoft AD compatible) group members are listed by DN and stored in the member attribute
|
||||
|
||||
*option*: `group_search_base` => `ou=RC-Groups`
|
||||
# Group search base will extend the Base DN (e.g. ou=Groups will result in ou=Groups,dc=mydomain,dc=com)
|
||||
|
||||
*option*: `group_name_attr` => `sAMAccountName`
|
||||
# LDAP Attribute to map to group name (e.g., cn, or sAMAccountName)
|
||||
|
||||
*option*: `user_member_of` => `memberOf`
|
||||
# Users Attribute used to fetch the group membership.
|
||||
# Use if users have stored group membership inside their attributes
|
||||
# (e.g., memberOf, or userMemberOf)
|
||||
|
||||
*option*: `group_search_filter` => ``
|
||||
# Filter to narrow results (e.g., (&(objectCategory=Group)(objectClass=group)), etc)
|
||||
|
||||
*option*: `group_member_of` => `memberOf`
|
||||
# LDAP Attribute used to resolve the parent group (e.g., memberOf)
|
||||
|
||||
*option*: `admin_groups` => `Admins,Management`
|
||||
# A comma separated list of group names that identify users as RhodeCode Administrators (e.g., admins)
|
||||
|
||||
*option*: `admin_groups_sync` => `full`
|
||||
# Way to sync Admin groups.
|
||||
# Full means admin flag is set to on or off according to membership in administrator group defined above.
|
||||
# On-only means the flag is only set to on, and not turned off once user is no longer a member
|
||||
|
||||
.. image:: ../images/ldap-groups-example.png
|
||||
:alt: LDAP/AD setup example
|
||||
:scale: 50 %
|
||||
|
||||
.. toctree::
|
||||
|
||||
|
|
|
|||
|
|
@ -3,11 +3,9 @@
|
|||
LDAP/AD
|
||||
-------
|
||||
|
||||
|RCM| supports LDAP (Lightweight Directory Access Protocol) or
|
||||
|RCE| supports LDAP (Lightweight Directory Access Protocol) or
|
||||
AD (active Directory) authentication.
|
||||
All LDAP versions are supported, with the following |RCM| plugins managing each:
|
||||
|
||||
* For LDAP or Active Directory use ``LDAP (egg:rhodecode-enterprise-ce#ldap)``
|
||||
All LDAP versions are currently supported.
|
||||
|
||||
RhodeCode reads all data defined from plugin and creates corresponding
|
||||
accounts on local database after receiving data from LDAP. This is done on
|
||||
|
|
@ -30,11 +28,12 @@ LDAP Configuration Steps
|
|||
|
||||
To configure |LDAP|, use the following steps:
|
||||
|
||||
1. From the |RCM| interface, select
|
||||
1. From the |RCE| interface, select
|
||||
:menuselection:`Admin --> Authentication`
|
||||
2. Enable the ldap plugin and select :guilabel:`Save`
|
||||
3. Select the :guilabel:`Enabled` check box in the plugin configuration section
|
||||
4. Add the required LDAP information and :guilabel:`Save`, for more details,
|
||||
2. Activate the `LDAP` plugin and select :guilabel:`Save`
|
||||
3. Go to newly available menu option called `LDAP` on the left side.
|
||||
4. Check the `enabled` check box in the plugin configuration section,
|
||||
and fill in the required LDAP information and :guilabel:`Save`, for more details,
|
||||
see :ref:`config-ldap-examples`
|
||||
|
||||
For a more detailed description of LDAP objects, see :ref:`ldap-gloss-ref`:
|
||||
|
|
@ -43,44 +42,73 @@ For a more detailed description of LDAP objects, see :ref:`ldap-gloss-ref`:
|
|||
|
||||
Example LDAP configuration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
.. code-block:: bash
|
||||
|
||||
# Auth Cache TTL, Defines the caching for authentication to offload LDAP server.
|
||||
# This means that cache result will be saved for 3600 before contacting LDAP server to verify the user access
|
||||
3600
|
||||
# Host, comma seperated format is optionally possible to specify more than 1 server
|
||||
https://ldap1.server.com/ldap-admin/,https://ldap2.server.com/ldap-admin/
|
||||
# Default LDAP Port, use 689 for LDAPS
|
||||
389
|
||||
# Account, used for SimpleBind if LDAP server requires an authentication
|
||||
e.g admin@server.com
|
||||
# Password used for simple bind
|
||||
ldap-user-password
|
||||
# LDAP connection security
|
||||
LDAPS
|
||||
# Certificate checks level
|
||||
DEMAND
|
||||
# Base DN
|
||||
cn=Rufus Magillacuddy,ou=users,dc=rhodecode,dc=com
|
||||
# LDAP search filter to narrow the results
|
||||
(objectClass=person)
|
||||
# LDAP search scope
|
||||
SUBTREE
|
||||
# Login attribute
|
||||
sAMAccountName
|
||||
# First Name Attribute to read
|
||||
givenName
|
||||
# Last Name Attribute to read
|
||||
sn
|
||||
# Email Attribute to read email address from
|
||||
mail
|
||||
Below is example setup that can be used with Active Directory/LDAP server::
|
||||
|
||||
*option*: `enabled` => `True`
|
||||
# Enable or disable this authentication plugin.
|
||||
|
||||
Below is example setup that can be used with Active Directory/LDAP server.
|
||||
*option*: `cache_ttl` => `360`
|
||||
# Amount of seconds to cache the authentication and permissions check response call for this plugin.
|
||||
# Useful for expensive calls like LDAP to improve the performance of the system (0 means disabled).
|
||||
|
||||
.. image:: ../images/ldap-example.png
|
||||
:alt: LDAP/AD setup example
|
||||
:scale: 50 %
|
||||
*option*: `host` => `192.168.245.143,192.168.1.240`
|
||||
# Host[s] of the LDAP Server
|
||||
# (e.g., 192.168.2.154, or ldap-server.domain.com.
|
||||
# Multiple servers can be specified using commas
|
||||
|
||||
*option*: `port` => `389`
|
||||
# Custom port that the LDAP server is listening on. Default value is: 389, use 689 for LDAPS(SSL)
|
||||
|
||||
*option*: `timeout` => `300`
|
||||
# Timeout for LDAP connection
|
||||
|
||||
*option*: `dn_user` => `Administrator@rhodecode.com`
|
||||
# Optional user DN/account to connect to LDAP if authentication is required.
|
||||
# e.g., cn=admin,dc=mydomain,dc=com, or uid=root,cn=users,dc=mydomain,dc=com, or admin@mydomain.com
|
||||
|
||||
*option*: `dn_pass` => `SomeSecret`
|
||||
# Password to authenticate for given user DN.
|
||||
|
||||
*option*: `tls_kind` => `PLAIN`
|
||||
# TLS Type
|
||||
|
||||
*option*: `tls_reqcert` => `NEVER`
|
||||
# Require Cert over TLS?. Self-signed and custom certificates can be used when
|
||||
# `RhodeCode Certificate` found in admin > settings > system info page is extended.
|
||||
|
||||
*option*: `tls_cert_file` => ``
|
||||
# This specifies the PEM-format file path containing certificates for use in TLS connection.
|
||||
# If not specified `TLS Cert dir` will be used
|
||||
|
||||
*option*: `tls_cert_dir` => `/etc/openldap/cacerts`
|
||||
# This specifies the path of a directory that contains individual CA certificates in separate files.
|
||||
|
||||
*option*: `base_dn` => `cn=Rufus Magillacuddy,ou=users,dc=rhodecode,dc=com`
|
||||
# Base DN to search. Dynamic bind is supported. Add `$login` marker in it to be replaced with current user credentials
|
||||
# (e.g., dc=mydomain,dc=com, or ou=Users,dc=mydomain,dc=com)
|
||||
|
||||
*option*: `filter` => `(objectClass=person)`
|
||||
# Filter to narrow results
|
||||
# (e.g., (&(objectCategory=Person)(objectClass=user)), or
|
||||
# (memberof=cn=rc-login,ou=groups,ou=company,dc=mydomain,dc=com)))
|
||||
|
||||
*option*: `search_scope` => `SUBTREE`
|
||||
# How deep to search LDAP. If unsure set to SUBTREE
|
||||
|
||||
*option*: `attr_login` => `sAMAccountName`
|
||||
# LDAP Attribute to map to user name (e.g., uid, or sAMAccountName)
|
||||
|
||||
*option*: `attr_email` => `mail`
|
||||
# LDAP Attribute to map to email address (e.g., mail).
|
||||
# Emails are a crucial part of RhodeCode.
|
||||
# If possible add a valid email attribute to ldap users.
|
||||
|
||||
*option*: `attr_firstname` => `givenName`
|
||||
# LDAP Attribute to map to first name (e.g., givenName)
|
||||
|
||||
*option*: `attr_lastname` => `sn`
|
||||
# LDAP Attribute to map to last name (e.g., sn)
|
||||
|
||||
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ PAM
|
|||
|
||||
To enable PAM authentication, use the following steps:
|
||||
|
||||
1. From the |RCM| interface, go to :menuselection:`Admin --> Authentication`
|
||||
2. Enable the ``rhodecode.lib.auth_modules.auth_pam`` library and select save
|
||||
1. From the |RCE| interface, go to :menuselection:`Admin --> Authentication`
|
||||
2. Activate the ``rhodecode.lib.auth_modules.auth_pam`` library and select save
|
||||
3. On the PAM plugin settings section, do the following:
|
||||
|
||||
* Check the :guilabel:`Enable` checkbox
|
||||
|
|
|
|||
105
docs/auth/auth-saml-duosecurity.rst
Normal file
105
docs/auth/auth-saml-duosecurity.rst
Normal file
|
|
@ -0,0 +1,105 @@
|
|||
.. _config-saml-duosecurity-ref:
|
||||
|
||||
|
||||
SAML 2.0 with Duo Security
|
||||
--------------------------
|
||||
|
||||
**This plugin is available only in EE Edition.**
|
||||
|
||||
|RCE| supports SAML 2.0 Authentication with Duo Security provider. This allows
|
||||
users to log-in to RhodeCode via SSO mechanism of external identity provider
|
||||
such as Duo. The login can be triggered either by the external IDP, or internally
|
||||
by clicking specific authentication button on the log-in page.
|
||||
|
||||
|
||||
Configuration steps
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To configure Duo Security SAML authentication, use the following steps:
|
||||
|
||||
1. From the |RCE| interface, select
|
||||
:menuselection:`Admin --> Authentication`
|
||||
2. Activate the `Duo Security` plugin and select :guilabel:`Save`
|
||||
3. Go to newly available menu option called `Duo Security` on the left side.
|
||||
4. Check the `enabled` check box in the plugin configuration section,
|
||||
and fill in the required SAML information and :guilabel:`Save`, for more details,
|
||||
see :ref:`config-saml-duosecurity`
|
||||
|
||||
|
||||
.. _config-saml-duosecurity:
|
||||
|
||||
|
||||
Example SAML Duo Security configuration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Example configuration for SAML 2.0 with Duo Security provider::
|
||||
|
||||
*option*: `enabled` => `True`
|
||||
# Enable or disable this authentication plugin.
|
||||
|
||||
*option*: `cache_ttl` => `0`
|
||||
# Amount of seconds to cache the authentication and permissions check response call for this plugin.
|
||||
# Useful for expensive calls like LDAP to improve the performance of the system (0 means disabled).
|
||||
|
||||
*option*: `debug` => `True`
|
||||
# Enable or disable debug mode that shows SAML errors in the RhodeCode logs.
|
||||
|
||||
*option*: `entity_id` => `http://rc-app.com/dag/saml2/idp/metadata.php`
|
||||
# Identity Provider entity/metadata URI.
|
||||
# E.g. https://duo-gateway.com/dag/saml2/idp/metadata.php
|
||||
|
||||
*option*: `sso_service_url` => `http://rc-app.com/dag/saml2/idp/SSOService.php?spentityid=http://rc.local.pl/_admin/auth/duosecurity/saml-metadata`
|
||||
# SSO (SingleSignOn) endpoint URL of the IdP. This can be used to initialize login
|
||||
# E.g. https://duo-gateway.com/dag/saml2/idp/SSOService.php?spentityid=<metadata_entity_id>
|
||||
|
||||
*option*: `slo_service_url` => `http://rc-app.com/dag/saml2/idp/SingleLogoutService.php?ReturnTo=http://rc-app.com/dag/module.php/duosecurity/logout.php`
|
||||
# SLO (SingleLogout) endpoint URL of the IdP.
|
||||
# E.g. https://duo-gateway.com/dag/saml2/idp/SingleLogoutService.php?ReturnTo=http://duo-gateway.com/_admin/saml/sign-out-endpoint
|
||||
|
||||
*option*: `x509cert` => `<CERTIFICATE_STRING>`
|
||||
# Identity provider public x509 certificate. It will be converted to single-line format without headers
|
||||
|
||||
*option*: `name_id_format` => `sha-1`
|
||||
# The format that specifies how the NameID is sent to the service provider.
|
||||
|
||||
*option*: `signature_algo` => `sha-256`
|
||||
# Type of Algorithm to use for verification of SAML signature on Identity provider side
|
||||
|
||||
*option*: `digest_algo` => `sha-256`
|
||||
# Type of Algorithm to use for verification of SAML digest on Identity provider side
|
||||
|
||||
*option*: `cert_dir` => `/etc/saml/`
|
||||
# Optional directory to store service provider certificate and private keys.
|
||||
# Expected certs for the SP should be stored in this folder as:
|
||||
# * sp.key Private Key
|
||||
# * sp.crt Public cert
|
||||
# * sp_new.crt Future Public cert
|
||||
#
|
||||
# Also you can use other cert to sign the metadata of the SP using the:
|
||||
# * metadata.key
|
||||
# * metadata.crt
|
||||
|
||||
*option*: `user_id_attribute` => `PersonImmutableID`
|
||||
# User ID Attribute name. This defines which attribute in SAML response will be used to link accounts via unique id.
|
||||
# Ensure this is returned from DuoSecurity for example via duo_username
|
||||
|
||||
*option*: `username_attribute` => `User.username`
|
||||
# Username Attribute name. This defines which attribute in SAML response will map to an username.
|
||||
|
||||
*option*: `email_attribute` => `User.email`
|
||||
# Email Attribute name. This defines which attribute in SAML response will map to an email address.
|
||||
|
||||
|
||||
Below is example setup from DUO Administration page that can be used with above config.
|
||||
|
||||
.. image:: ../images/saml-duosecurity-service-provider-example.png
|
||||
:alt: DUO Security SAML setup example
|
||||
:scale: 50 %
|
||||
|
||||
|
||||
Below is an example attribute mapping set for IDP provider required by the above config.
|
||||
|
||||
|
||||
.. image:: ../images/saml-duosecurity-attributes-example.png
|
||||
:alt: DUO Security SAML setup example
|
||||
:scale: 50 %
|
||||
18
docs/auth/auth-saml-generic.rst
Normal file
18
docs/auth/auth-saml-generic.rst
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
.. _config-saml-generic-ref:
|
||||
|
||||
|
||||
SAML 2.0 Authentication
|
||||
-----------------------
|
||||
|
||||
|
||||
**This plugin is available only in EE Edition.**
|
||||
|
||||
RhodeCode Supports standard SAML 2.0 SSO for the web-application part.
|
||||
|
||||
Please check for reference two example providers:
|
||||
|
||||
.. toctree::
|
||||
|
||||
auth-saml-duosecurity
|
||||
auth-saml-onelogin
|
||||
|
||||
106
docs/auth/auth-saml-onelogin.rst
Normal file
106
docs/auth/auth-saml-onelogin.rst
Normal file
|
|
@ -0,0 +1,106 @@
|
|||
.. _config-saml-onelogin-ref:
|
||||
|
||||
|
||||
SAML 2.0 with One Login
|
||||
-----------------------
|
||||
|
||||
**This plugin is available only in EE Edition.**
|
||||
|
||||
|RCE| supports SAML 2.0 Authentication with OneLogin provider. This allows
|
||||
users to log-in to RhodeCode via SSO mechanism of external identity provider
|
||||
such as OneLogin. The login can be triggered either by the external IDP, or internally
|
||||
by clicking specific authentication button on the log-in page.
|
||||
|
||||
|
||||
Configuration steps
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To configure OneLogin SAML authentication, use the following steps:
|
||||
|
||||
1. From the |RCE| interface, select
|
||||
:menuselection:`Admin --> Authentication`
|
||||
2. Activate the `OneLogin` plugin and select :guilabel:`Save`
|
||||
3. Go to newly available menu option called `OneLogin` on the left side.
|
||||
4. Check the `enabled` check box in the plugin configuration section,
|
||||
and fill in the required SAML information and :guilabel:`Save`, for more details,
|
||||
see :ref:`config-saml-onelogin`
|
||||
|
||||
|
||||
.. _config-saml-onelogin:
|
||||
|
||||
|
||||
Example SAML OneLogin configuration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Example configuration for SAML 2.0 with OneLogin provider::
|
||||
|
||||
*option*: `enabled` => `True`
|
||||
# Enable or disable this authentication plugin.
|
||||
|
||||
*option*: `cache_ttl` => `0`
|
||||
# Amount of seconds to cache the authentication and permissions check response call for this plugin.
|
||||
# Useful for expensive calls like LDAP to improve the performance of the system (0 means disabled).
|
||||
|
||||
*option*: `debug` => `True`
|
||||
# Enable or disable debug mode that shows SAML errors in the RhodeCode logs.
|
||||
|
||||
*option*: `entity_id` => `https://app.onelogin.com/saml/metadata/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`
|
||||
# Identity Provider entity/metadata URI.
|
||||
# E.g. https://app.onelogin.com/saml/metadata/<onelogin_connector_id>
|
||||
|
||||
*option*: `sso_service_url` => `https://customer-domain.onelogin.com/trust/saml2/http-post/sso/xxxxxx`
|
||||
# SSO (SingleSignOn) endpoint URL of the IdP. This can be used to initialize login
|
||||
# E.g. https://app.onelogin.com/trust/saml2/http-post/sso/<onelogin_connector_id>
|
||||
|
||||
*option*: `slo_service_url` => `https://customer-domain.onelogin.com/trust/saml2/http-redirect/slo/xxxxxx`
|
||||
# SLO (SingleLogout) endpoint URL of the IdP.
|
||||
# E.g. https://app.onelogin.com/trust/saml2/http-redirect/slo/<onelogin_connector_id>
|
||||
|
||||
*option*: `x509cert` => `<CERTIFICATE_STRING>`
|
||||
# Identity provider public x509 certificate. It will be converted to single-line format without headers
|
||||
|
||||
*option*: `name_id_format` => `sha-1`
|
||||
# The format that specifies how the NameID is sent to the service provider.
|
||||
|
||||
*option*: `signature_algo` => `sha-256`
|
||||
# Type of Algorithm to use for verification of SAML signature on Identity provider side
|
||||
|
||||
*option*: `digest_algo` => `sha-256`
|
||||
# Type of Algorithm to use for verification of SAML digest on Identity provider side
|
||||
|
||||
*option*: `cert_dir` => `/etc/saml/`
|
||||
# Optional directory to store service provider certificate and private keys.
|
||||
# Expected certs for the SP should be stored in this folder as:
|
||||
# * sp.key Private Key
|
||||
# * sp.crt Public cert
|
||||
# * sp_new.crt Future Public cert
|
||||
#
|
||||
# Also you can use other cert to sign the metadata of the SP using the:
|
||||
# * metadata.key
|
||||
# * metadata.crt
|
||||
|
||||
*option*: `user_id_attribute` => `PersonImmutableID`
|
||||
# User ID Attribute name. This defines which attribute in SAML response will be used to link accounts via unique id.
|
||||
# Ensure this is returned from OneLogin for example via Internal ID
|
||||
|
||||
*option*: `username_attribute` => `User.username`
|
||||
# Username Attribute name. This defines which attribute in SAML response will map to an username.
|
||||
|
||||
*option*: `email_attribute` => `User.email`
|
||||
# Email Attribute name. This defines which attribute in SAML response will map to an email address.
|
||||
|
||||
|
||||
|
||||
Below is example setup that can be used with OneLogin SAML authentication that can be used with above config..
|
||||
|
||||
.. image:: ../images/saml-onelogin-config-example.png
|
||||
:alt: OneLogin SAML setup example
|
||||
:scale: 50 %
|
||||
|
||||
|
||||
Below is an example attribute mapping set for IDP provider required by the above config.
|
||||
|
||||
|
||||
.. image:: ../images/saml-onelogin-attributes-example.png
|
||||
:alt: OneLogin SAML setup example
|
||||
:scale: 50 %
|
||||
|
|
@ -3,7 +3,10 @@
|
|||
Authentication Tokens
|
||||
---------------------
|
||||
|
||||
|RCE| has 4 different kinds of authentication tokens.
|
||||
|RCE| has 4 different kinds of authentication tokens. `API token`, `Feed tokens` work
|
||||
without a need to enable any additional authentication. `VCS tokens` require dedicated
|
||||
authentication plugin to be activated. `Web Interface tokens` are controlled by the
|
||||
white_list configuration.
|
||||
|
||||
* *API tokens*: API tokens can only be used to execute |RCE| API operations.
|
||||
You can store your API token and assign it to each instance in
|
||||
|
|
@ -11,15 +14,7 @@ Authentication Tokens
|
|||
example in :ref:`indexing-ref` section for more details.
|
||||
|
||||
* *Feed tokens*: The feed token can only be used to access the RSS feed.
|
||||
Usually those are safe to store inside your RSS feed reader.
|
||||
|
||||
* *VCS tokens*: You can use these to authenticate with |git|, |hg| and |svn|
|
||||
operations instead of a password. They are designed to be used with
|
||||
CI Servers or other third party tools that require |repo| access.
|
||||
They are also a good replacement for SSH based access.
|
||||
To use these tokens you need be enabled special authentication method on
|
||||
|RCE|, as they are disabled by default.
|
||||
See :ref:`enable-vcs-tokens`.
|
||||
Usually those are safe to store inside your RSS feed reader.
|
||||
|
||||
* *Web Interface tokens*: These token allows users to access the web
|
||||
interface of |RCE| without logging in.
|
||||
|
|
@ -41,7 +36,16 @@ Authentication Tokens
|
|||
https://rhodecode.com/repo/archive/tip.zip?auth_token=<web-api-token>
|
||||
|
||||
# To show commit diff without logging into Web UI
|
||||
https://rhodecode.com/repo/changeset-diff/<sha>?auth_token=<web-api-token>
|
||||
https://rhodecode.com/repo/raw-diff/<sha>?auth_token=<web-api-token>
|
||||
|
||||
* *VCS tokens*: You can use these to authenticate with |git|, |hg| and |svn|
|
||||
operations instead of a password. They are designed to be used with
|
||||
CI Servers or other third party tools that require |repo| access.
|
||||
They are also a good replacement for SSH based access.
|
||||
To use these tokens you need be enabled special authentication method on
|
||||
|RCE|, as they are disabled by default.
|
||||
See :ref:`enable-vcs-tokens`.
|
||||
|
||||
|
||||
.. _enable-vcs-tokens:
|
||||
|
||||
|
|
@ -51,7 +55,7 @@ Enabling VCS Tokens
|
|||
To enable VCS Tokens, use the following steps:
|
||||
|
||||
1. Go to :menuselection:`Admin --> Authentication`.
|
||||
2. Enable the ``rhodecode.lib.auth_modules.auth_token`` plugin.
|
||||
2. Activate the ``rhodecode.lib.auth_modules.auth_token`` plugin.
|
||||
3. Click :guilabel:`Save`.
|
||||
|
||||
Authentication Token Tips
|
||||
|
|
@ -67,7 +71,7 @@ Creating Tokens
|
|||
|
||||
To create authentication tokens for an user, use the following steps:
|
||||
|
||||
1. From the |RCM| interface go to
|
||||
1. From the |RCE| interface go to
|
||||
:menuselection:`Username --> My Account --> Auth tokens`.
|
||||
|
||||
2. Label and Add the tokens you wish to use with |RCE|.
|
||||
|
|
|
|||
|
|
@ -4,29 +4,31 @@ Authentication Options
|
|||
======================
|
||||
|
||||
|RCE| provides a built in authentication against its own database. This is
|
||||
implemented using ``rhodecode.lib.auth_rhodecode`` plugin. This plugin is
|
||||
enabled by default.
|
||||
implemented using ``RhodeCode Internal`` plugin. This plugin is enabled by default.
|
||||
Additionally, |RCE| provides a Pluggable Authentication System. This gives the
|
||||
administrator greater control over how users authenticate with the system.
|
||||
|
||||
.. important::
|
||||
|
||||
You can disable the built in |RCM| authentication plugin
|
||||
``rhodecode.lib.auth_rhodecode`` and force all authentication to go
|
||||
You can disable the built in |RCE| authentication plugin
|
||||
``RhodeCode Internal`` and force all authentication to go
|
||||
through your authentication plugin of choice e.g LDAP only.
|
||||
However, if you do this, and your external authentication tools fails,
|
||||
you will be unable to access |RCM|.
|
||||
accessing |RCE| will be blocked unless a fallback plugin is
|
||||
enabled via :file: rhodecode.ini
|
||||
|
||||
|RCM| comes with the following user authentication management plugins:
|
||||
|
||||
|RCE| comes with the following user authentication management plugins:
|
||||
|
||||
|
||||
.. toctree::
|
||||
|
||||
auth-token
|
||||
auth-ldap
|
||||
auth-ldap-groups
|
||||
auth-saml-generic
|
||||
auth-saml-onelogin
|
||||
auth-saml-duosecurity
|
||||
auth-crowd
|
||||
auth-pam
|
||||
auth-token
|
||||
ssh-connection
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -3,27 +3,73 @@
|
|||
Active Directory
|
||||
----------------
|
||||
|
||||
|RCM| can use Microsoft Active Directory for user authentication. This is
|
||||
|RCE| can use Microsoft Active Directory for user authentication. This is
|
||||
done through an LDAP or LDAPS connection to Active Directory. Use the
|
||||
following example LDAP configuration setting to set your Active Directory
|
||||
authentication.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
# Set the Base DN
|
||||
Base DN = OU=SBSUsers,OU=Users,OU=MyBusiness,DC=v3sys,DC=local
|
||||
# Set the Active Directory SAM-Account-Name
|
||||
Login Attribute = sAMAccountName
|
||||
# Set the Active Directory user name
|
||||
First Name Attribute = usernameame
|
||||
# Set the Active Directory user surname
|
||||
Last Name Attribute = user_surname
|
||||
# Set the Active Directory user email
|
||||
E-mail Attribute = userEmail
|
||||
authentication::
|
||||
|
||||
|
||||
Below is example setup that can be used with Active Directory and ldap groups.
|
||||
*option*: `enabled` => `True`
|
||||
# Enable or disable this authentication plugin.
|
||||
|
||||
.. image:: ../images/ldap-groups-example.png
|
||||
:alt: LDAP/AD setup example
|
||||
:scale: 50 %
|
||||
*option*: `cache_ttl` => `360`
|
||||
# Amount of seconds to cache the authentication and permissions check response call for this plugin.
|
||||
# Useful for expensive calls like LDAP to improve the performance of the system (0 means disabled).
|
||||
|
||||
*option*: `host` => `192.168.245.143,192.168.1.240`
|
||||
# Host[s] of the LDAP Server
|
||||
# (e.g., 192.168.2.154, or ldap-server.domain.com.
|
||||
# Multiple servers can be specified using commas
|
||||
|
||||
*option*: `port` => `389`
|
||||
# Custom port that the LDAP server is listening on. Default value is: 389, use 689 for LDAPS(SSL)
|
||||
|
||||
*option*: `timeout` => `300`
|
||||
# Timeout for LDAP connection
|
||||
|
||||
*option*: `dn_user` => `Administrator@rhodecode.com`
|
||||
# Optional user DN/account to connect to LDAP if authentication is required.
|
||||
# e.g., cn=admin,dc=mydomain,dc=com, or uid=root,cn=users,dc=mydomain,dc=com, or admin@mydomain.com
|
||||
|
||||
*option*: `dn_pass` => `SomeSecret`
|
||||
# Password to authenticate for given user DN.
|
||||
|
||||
*option*: `tls_kind` => `PLAIN`
|
||||
# TLS Type
|
||||
|
||||
*option*: `tls_reqcert` => `NEVER`
|
||||
# Require Cert over TLS?. Self-signed and custom certificates can be used when
|
||||
# `RhodeCode Certificate` found in admin > settings > system info page is extended.
|
||||
|
||||
*option*: `tls_cert_file` => ``
|
||||
# This specifies the PEM-format file path containing certificates for use in TLS connection.
|
||||
# If not specified `TLS Cert dir` will be used
|
||||
|
||||
*option*: `tls_cert_dir` => `/etc/openldap/cacerts`
|
||||
# This specifies the path of a directory that contains individual CA certificates in separate files.
|
||||
|
||||
*option*: `base_dn` => `OU=SBSUsers,OU=Users,OU=MyBusiness,DC=v3sys,DC=local`
|
||||
# Base DN to search. Dynamic bind is supported. Add `$login` marker in it to be replaced with current user credentials
|
||||
# (e.g., dc=mydomain,dc=com, or ou=Users,dc=mydomain,dc=com)
|
||||
|
||||
*option*: `filter` => `(objectClass=person)`
|
||||
# Filter to narrow results
|
||||
# (e.g., (&(objectCategory=Person)(objectClass=user)), or
|
||||
# (memberof=cn=rc-login,ou=groups,ou=company,dc=mydomain,dc=com)))
|
||||
|
||||
*option*: `search_scope` => `SUBTREE`
|
||||
# How deep to search LDAP. If unsure set to SUBTREE
|
||||
|
||||
*option*: `attr_login` => `sAMAccountName`
|
||||
# LDAP Attribute to map to user name (e.g., uid, or sAMAccountName)
|
||||
|
||||
*option*: `attr_email` => `userEmail`
|
||||
# LDAP Attribute to map to email address (e.g., mail).
|
||||
# Emails are a crucial part of RhodeCode.
|
||||
# If possible add a valid email attribute to ldap users.
|
||||
|
||||
*option*: `attr_firstname` => `user_firstname`
|
||||
# LDAP Attribute to map to first name (e.g., givenName)
|
||||
|
||||
*option*: `attr_lastname` => `user_surname`
|
||||
# LDAP Attribute to map to last name (e.g., sn)
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ The following LDAP attributes are required when enabling |LDAP| on |RCE|.
|
|||
* The LDAP username or account used to connect to |RCE|. This will be added
|
||||
to the LDAP filter for locating the user object.
|
||||
* For example, if an LDAP filter is specified as `LDAPFILTER`,
|
||||
the login attribute is specified as `uid`, and the user connects as
|
||||
the login/username attribute is specified as `uid`, and the user connects as
|
||||
`jsmith`, then the LDAP Filter will be like the following example.
|
||||
|
||||
.. code-block:: vim
|
||||
|
|
@ -68,7 +68,7 @@ The following LDAP attributes are required when enabling |LDAP| on |RCE|.
|
|||
Optional settings
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
The following are optional when enabling LDAP on |RCM|
|
||||
The following are optional when enabling LDAP on |RCE|
|
||||
|
||||
* An LDAP account is only required if the LDAP server does not allow
|
||||
anonymous browsing of records.
|
||||
|
|
@ -104,10 +104,4 @@ The following are optional when enabling LDAP on |RCM|
|
|||
following directory: `/etc/openldap/cacerts`
|
||||
|
||||
|
||||
Below is example setup that can be used with Active Directory and ldap groups.
|
||||
|
||||
.. image:: ../images/ldap-groups-example.png
|
||||
:alt: LDAP/AD setup example
|
||||
:scale: 50 %
|
||||
|
||||
.. _RFC 2254: http://www.rfc-base.org/rfc-2254.html
|
||||
|
|
@ -3,7 +3,7 @@
|
|||
Code Review
|
||||
===========
|
||||
|
||||
|RCM| provides two ways in which you can review code. You can review |prs| or
|
||||
|RCE| provides two ways in which you can review code. You can review |prs| or
|
||||
commits. To better understand |prs|, see the :ref:`pull-requests-ref`
|
||||
and :ref:`collaborate-ref` sections. For more information about why
|
||||
code review matters, see these posts on the topic:
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ review purposes.
|
|||
Reviewing Changes
|
||||
-----------------
|
||||
|
||||
|RCM| displays all code changes made with each commit. Removed content is
|
||||
|RCE| displays all code changes made with each commit. Removed content is
|
||||
marked in red and new content in green.
|
||||
|
||||
.. image:: ../images/plain-diff.png
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ To approve a |pr|, use the following steps:
|
|||
4. Set the review status to :guilabel:`Approved`
|
||||
5. Select :guilabel:`Comment`
|
||||
|
||||
If you approve the |pr|, you will be able to merge automatically if |RCM|
|
||||
If you approve the |pr|, you will be able to merge automatically if |RCE|
|
||||
detects that it can do so safely. You will see this message:
|
||||
|
||||
:guilabel:`This pull request can be automatically merged.`
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Collaboration
|
|||
|
||||
Forking and branching does not work with |svn| |repos|.
|
||||
|
||||
Collaboration in |RCM| is accomplished through a combination of the following
|
||||
Collaboration in |RCE| is accomplished through a combination of the following
|
||||
functions:
|
||||
|
||||
.. only:: latex
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ on the web interface. To branch a |git| |repo| use the following example:
|
|||
$ git commit -a -m "ghost script: initial file"
|
||||
$ git push
|
||||
|
||||
Once it is pushed to the |RCM| server, you can switch to the newly created
|
||||
Once it is pushed to the |RCE| server, you can switch to the newly created
|
||||
branch using the following steps:
|
||||
|
||||
1. Select :menuselection:`Admin --> Repositories`.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Using Notifications
|
|||
-------------------
|
||||
|
||||
To notify users of items that require their attention you can use the mention
|
||||
function. The mention function allows you to use ``@username`` within |RCM|.
|
||||
function. The mention function allows you to use ``@username`` within |RCE|.
|
||||
The notification function can be used within the following
|
||||
items to highlight their need for attention:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Merge a |pr|
|
||||
------------
|
||||
|
||||
|RCM| can detect if it can automatically merge the changes in a |pr|. If it
|
||||
|RCE| can detect if it can automatically merge the changes in a |pr|. If it
|
||||
can, you will see the following message:
|
||||
:guilabel:`This pull request can be automatically merged.` To merge,
|
||||
click the big blue button! To enable this feature, see :ref:`server-side-merge`.
|
||||
|
|
@ -21,7 +21,7 @@ messages:
|
|||
Manual Merge a |PR|
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If |RCM| cannot safely merge the changes in a |pr|,
|
||||
If |RCE| cannot safely merge the changes in a |pr|,
|
||||
usually due to conflicts, you need to manually merge the changes on the
|
||||
command line. You can see more information for each |repo| type at the
|
||||
following links:
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Notifications Overview
|
||||
----------------------
|
||||
|
||||
|RCM| has an integrated notification system which alerts users to requests
|
||||
|RCE| has an integrated notification system which alerts users to requests
|
||||
that they have received. Notifications can occur for the following reasons:
|
||||
|
||||
* Pull request reviews
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Pull request management
|
|||
|
||||
.. only:: html
|
||||
|
||||
There are two ways of tracking |prs| within |RCM|.
|
||||
There are two ways of tracking |prs| within |RCE|.
|
||||
|
||||
1. :ref:`prs-your-review`
|
||||
2. :ref:`prs-per-repo`
|
||||
|
|
@ -15,7 +15,7 @@ Pull requests for your review
|
|||
|
||||
To view pull requests for your review, use the following steps:
|
||||
|
||||
1. From the |RCM| interface, Select
|
||||
1. From the |RCE| interface, Select
|
||||
:menuselection:`username --> Notifications`
|
||||
2. Select :guilabel:`Pull Requests`
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ To review a pull request, use the following steps:
|
|||
4. Select Comment
|
||||
|
||||
When the |pr| is approved by all reviewers you will be able to merge
|
||||
automatically if |RCM| detects that it can do so safely. You will see this
|
||||
automatically if |RCE| detects that it can do so safely. You will see this
|
||||
message: `This pull request can be automatically merged.`
|
||||
|
||||
If rejected, you can fix the issues raised during review and then update the
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Supported Workflows
|
||||
-------------------
|
||||
|
||||
|RCM| can be used to develop using a variety of different workflows.
|
||||
|RCE| can be used to develop using a variety of different workflows.
|
||||
|
||||
* Centralized, using |svn|, |git|, or |hg| |repos|
|
||||
* Feature-Branch, using |git| or |hg| |repos|
|
||||
|
|
|
|||
|
|
@ -20,10 +20,7 @@ rst_epilog = '''
|
|||
.. |psf| replace:: Python Software Foundation
|
||||
.. |repo| replace:: repository
|
||||
.. |repos| replace:: repositories
|
||||
.. |RCI| replace:: RhodeCode Control
|
||||
.. |RCC| replace:: RhodeCode Control
|
||||
.. |RCV| replace:: RhodeCode Enterprise
|
||||
.. |RCM| replace:: RhodeCode Enterprise
|
||||
.. |RCE| replace:: RhodeCode Enterprise
|
||||
.. |RCCE| replace:: RhodeCode Community
|
||||
.. |RCEE| replace:: RhodeCode Enterprise
|
||||
|
|
@ -31,6 +28,5 @@ rst_epilog = '''
|
|||
.. |RCT| replace:: RhodeCode Tools
|
||||
.. |RCEBOLD| replace:: **RhodeCode Enterprise**
|
||||
.. |RCEITALICS| replace:: `RhodeCode Enterprise`
|
||||
.. |RC| replace:: RhodeCode
|
||||
.. |RNS| replace:: Release Notes
|
||||
'''
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ so to clarify what is meant each time, read the following definitions:
|
|||
Hooks
|
||||
-----
|
||||
|
||||
Within |RCM| there are two types of supported hooks.
|
||||
Within |RCE| there are two types of supported hooks.
|
||||
|
||||
* **Internal built-in hooks**: The internal |hg|, |git| or |svn| hooks are
|
||||
triggered by different VCS operations, like push, pull,
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 210 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1,003 KiB |
BIN
docs/images/saml-duosecurity-attributes-example.png
Normal file
BIN
docs/images/saml-duosecurity-attributes-example.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
BIN
docs/images/saml-duosecurity-service-provider-example.png
Normal file
BIN
docs/images/saml-duosecurity-service-provider-example.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
BIN
docs/images/saml-onelogin-attributes-example.png
Normal file
BIN
docs/images/saml-onelogin-attributes-example.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
BIN
docs/images/saml-onelogin-config-example.png
Normal file
BIN
docs/images/saml-onelogin-config-example.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
|
|
@ -1,13 +1,13 @@
|
|||
|RCM|
|
||||
|RCE|
|
||||
=====
|
||||
|
||||
|RCM| is a high-performance source code management and collaboration system.
|
||||
|RCE| is a high-performance source code management and collaboration system.
|
||||
It enables you to develop projects securely behind the firewall while
|
||||
providing collaboration tools that work with |git|, |hg|,
|
||||
and |svn| |repos|. The user interface allows you to create, edit,
|
||||
and commit files and |repos| while managing their security permissions.
|
||||
|
||||
|RCM| provides the following features:
|
||||
|RCE| provides the following features:
|
||||
|
||||
* Source code management.
|
||||
* Extended permissions management.
|
||||
|
|
@ -18,7 +18,7 @@ and commit files and |repos| while managing their security permissions.
|
|||
* Web-based hook management.
|
||||
* Native |svn| support.
|
||||
* Migration from existing databases.
|
||||
* |RCM| SDK.
|
||||
* |RCE| SDK.
|
||||
* Built-in analytics
|
||||
* Built in integrations including: Slack, Webhooks (used for Jenkins/TeamCity and other CIs), Jira, Redmine, Hipchat
|
||||
* Pluggable authentication system.
|
||||
|
|
|
|||
|
|
@ -5,8 +5,24 @@ Supported Databases
|
|||
|
||||
.. important::
|
||||
|
||||
We do not recommend using SQLite in a production environment. It is
|
||||
supported by |RCE| for evaluation purposes.
|
||||
We do not recommend using SQLite in a production environment of more than 5 people.
|
||||
It is not suited for higher usage and mayb cause problems.
|
||||
|
||||
|
||||
|RCE| supports the following databases. The recommended encoding is UTF-8.
|
||||
|
||||
.. only:: latex
|
||||
|
||||
* :ref:`install-sqlite-database`
|
||||
* :ref:`install-mysql-database`
|
||||
* :ref:`install-postgresql-database`
|
||||
|
||||
.. toctree::
|
||||
|
||||
using-mysql
|
||||
using-postgresql
|
||||
using-sqllite
|
||||
|
||||
|
||||
Database Overview
|
||||
-----------------
|
||||
|
|
@ -48,21 +64,3 @@ following example to configure the correct one.
|
|||
# for the RCE instance you are installing
|
||||
Database name: example-db-name-for-2xx # The 2xx version database
|
||||
Database name: example-db-name-for-3xx # The 3xx version database
|
||||
|
||||
Supported Databases
|
||||
-------------------
|
||||
|
||||
|RCM| supports the following databases. The recommended encoding is Unicode
|
||||
UTF-8.
|
||||
|
||||
.. only:: latex
|
||||
|
||||
* :ref:`install-sqlite-database`
|
||||
* :ref:`install-mysql-database`
|
||||
* :ref:`install-postgresql-database`
|
||||
|
||||
.. toctree::
|
||||
|
||||
using-mysql
|
||||
using-postgresql
|
||||
using-sqllite
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Post Installation Tasks
|
|||
=======================
|
||||
|
||||
The following tasks are the most common post installation requirements. Use
|
||||
the information in these sections to configure your instance of |RCM|.
|
||||
the information in these sections to configure your instance of |RCE|.
|
||||
|
||||
.. toctree::
|
||||
|
||||
|
|
|
|||
|
|
@ -3,21 +3,21 @@
|
|||
Migrating |repos|
|
||||
-----------------
|
||||
|
||||
If you have installed |RCM| and have |repos| that you wish to migrate into
|
||||
If you have installed |RCE| and have |repos| that you wish to migrate into
|
||||
the system, use the following instructions.
|
||||
|
||||
1. On the |RCM| interface, check your |repo| storage location under
|
||||
1. On the |RCE| interface, check your |repo| storage location under
|
||||
:menuselection:`Admin --> Settings --> System Info`. For example,
|
||||
Storage location: /home/{username}/repos.
|
||||
|
||||
2. Copy the |repos| that you want |RCM| to manage to this location.
|
||||
2. Copy the |repos| that you want |RCE| to manage to this location.
|
||||
3. Remap and rescan the |repos|, see :ref:`remap-rescan`
|
||||
|
||||
.. important::
|
||||
|
||||
Directories create |repo| groups inside |RCM|.
|
||||
Directories create |repo| groups inside |RCE|.
|
||||
|
||||
Importing adds |RCM| git hooks to your |repos|.
|
||||
Importing adds |RCE| git hooks to your |repos|.
|
||||
|
||||
You should verify if custom ``.hg`` or ``.hgrc`` files inside
|
||||
repositories should be adjusted since |RCM| reads the content of them.
|
||||
repositories should be adjusted since |RCE| reads the content of them.
|
||||
|
|
|
|||
|
|
@ -27,9 +27,12 @@ To get |RCE| up and running, run through the below steps:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ chmod 755 RhodeCode-installer-linux-*
|
||||
$ chmod +x RhodeCode-installer-linux-*
|
||||
$ ./RhodeCode-installer-linux-*
|
||||
|
||||
Do you accept the RhodeCode Control license?
|
||||
Press [Y] to accept license and [V] to view license text: y
|
||||
|
||||
3. Install a VCS Server, and configure it to start at boot.
|
||||
|
||||
.. code-block:: bash
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@
|
|||
Set up Email
|
||||
------------
|
||||
|
||||
To setup email with your |RCM| instance, open the default
|
||||
To setup email with your |RCE| instance, open the default
|
||||
:file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
|
||||
file and uncomment and configure the email section. If it is not there,
|
||||
use the below example to insert it.
|
||||
|
||||
Once configured you can check the settings for your |RCM| instance on the
|
||||
Once configured you can check the settings for your |RCE| instance on the
|
||||
:menuselection:`Admin --> Settings --> Email` page.
|
||||
|
||||
.. code-block:: ini
|
||||
|
|
|
|||
|
|
@ -4,15 +4,15 @@ MySQL or MariaDB
|
|||
----------------
|
||||
|
||||
To use a MySQL or MariaDB database you should install and configure the
|
||||
database before installing |RCM|. This is because during |RCM| installation
|
||||
database before installing |RCE|. This is because during |RCE| installation
|
||||
you will setup a connection to your MySQL or MariaDB database. To work with
|
||||
either, use the following steps:
|
||||
|
||||
1. Depending on your |os|, install a MySQL or MariaDB database following the
|
||||
appropriate instructions from the `MySQL website`_ or `MariaDB website`_.
|
||||
2. Configure the database with a username and password which you will use
|
||||
with |RCM|.
|
||||
3. Install |RCM|, and during installation select MySQL as your database.
|
||||
with |RCE|.
|
||||
3. Install |RCE|, and during installation select MySQL as your database.
|
||||
4. Enter the following information during the database setup:
|
||||
|
||||
* Your network IP Address
|
||||
|
|
|
|||
|
|
@ -4,15 +4,15 @@ PostgreSQL
|
|||
----------
|
||||
|
||||
To use a PostgreSQL database, you should install and configure the database
|
||||
before installing |RCV|. This is because during |RCV| installation you will
|
||||
before installing |RCE|. This is because during |RCE| installation you will
|
||||
setup the connection to your PostgreSQL database. To work with PostgreSQL,
|
||||
use the following steps:
|
||||
|
||||
1. Depending on your |os|, install a PostgreSQL database following the
|
||||
appropriate instructions from the `PostgreSQL website`_.
|
||||
2. Configure the database with a username and password, which you will use
|
||||
with |RCV|.
|
||||
3. Install |RCV|, and during installation select PostgreSQL as your database.
|
||||
with |RCE|.
|
||||
3. Install |RCE|, and during installation select PostgreSQL as your database.
|
||||
4. Enter the following information during the database setup:
|
||||
|
||||
* Your network IP Address
|
||||
|
|
|
|||
|
|
@ -9,15 +9,15 @@ SQLite
|
|||
as it has an internal locking mechanism which can become a performance
|
||||
bottleneck when there are more than 5 concurrent users.
|
||||
|
||||
|RCM| installs SQLite as the default database if you do not specify another
|
||||
|RCE| installs SQLite as the default database if you do not specify another
|
||||
during installation. SQLite is suitable for small teams,
|
||||
projects with a low load, and evaluation purposes since it is built into
|
||||
|RCM| and does not require any additional database server.
|
||||
|RCE| and does not require any additional database server.
|
||||
|
||||
Using MySQL or PostgreSQL in an large setup gives you much greater
|
||||
performance, and while migration tools exist to move from one database type
|
||||
to another, it is better to get it right first time and to immediately use
|
||||
MySQL or PostgreSQL when you deploy |RCM| in a production environment.
|
||||
MySQL or PostgreSQL when you deploy |RCE| in a production environment.
|
||||
|
||||
Migrating From SQLite to PostgreSQL
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
|
|
|||
|
|
@ -11,20 +11,20 @@ different Slack channels, for example.
|
|||
Supported integrations
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
================================ ============ ========================================
|
||||
Type/Name |RC| Edition Description
|
||||
================================ ============ ========================================
|
||||
:ref:`integrations-webhook` |RCCEshort| Trigger events as `json` to a custom url
|
||||
:ref:`integrations-slack` |RCCEshort| Integrate with https://slack.com/
|
||||
:ref:`integrations-hipchat` |RCCEshort| Integrate with https://www.hipchat.com/
|
||||
:ref:`integrations-email` |RCCEshort| Send repo push commits by email
|
||||
:ref:`integrations-ci` |RCCEshort| Trigger Builds for Common CI Systems
|
||||
:ref:`integrations-rcextensions` |RCCEshort| Advanced low-level integration framework
|
||||
================================ ================== ========================================
|
||||
Type/Name RhodeCode Edition Description
|
||||
================================ ================== ========================================
|
||||
:ref:`integrations-webhook` |RCCEshort| Trigger events as `json` to a custom url
|
||||
:ref:`integrations-slack` |RCCEshort| Integrate with https://slack.com/
|
||||
:ref:`integrations-hipchat` |RCCEshort| Integrate with https://www.hipchat.com/
|
||||
:ref:`integrations-email` |RCCEshort| Send repo push commits by email
|
||||
:ref:`integrations-ci` |RCCEshort| Trigger Builds for Common CI Systems
|
||||
:ref:`integrations-rcextensions` |RCCEshort| Advanced low-level integration framework
|
||||
|
||||
:ref:`integrations-jenkins` |RCEEshort| Trigger Builds for Jenkins CI System
|
||||
:ref:`integrations-redmine` |RCEEshort| Close/Resolve/Reference Redmine issues
|
||||
:ref:`integrations-jira` |RCEEshort| Close/Resolve/Reference JIRA issues
|
||||
================================ ============ ========================================
|
||||
:ref:`integrations-jenkins` |RCEEshort| Trigger Builds for Jenkins CI System
|
||||
:ref:`integrations-redmine` |RCEEshort| Close/Resolve/Reference Redmine issues
|
||||
:ref:`integrations-jira` |RCEEshort| Close/Resolve/Reference JIRA issues
|
||||
================================ ================== ========================================
|
||||
|
||||
.. _creating-integrations:
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ You can set an issue tracker connection in two ways with |RCE|.
|
|||
* At the |repo| level, you can configure an integration with a different issue
|
||||
tracker.
|
||||
|
||||
To integrate |RCM| with an issue tracker, you need to define a regular
|
||||
To integrate |RCE| with an issue tracker, you need to define a regular
|
||||
expression that will fetch the issue ID stored in commit messages, and replace
|
||||
it with a URL. This enables |RCE| to generate a link matching each issue to the
|
||||
target |repo|.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Error Message
|
|||
Error creating repository repo-name
|
||||
|
||||
Cause
|
||||
As of |RCM| 3.0, a VCS Server is required to run backend operations.
|
||||
As of |RCE| 3.0, a VCS Server is required to run backend operations.
|
||||
|
||||
Solution
|
||||
Install a VCS Server. See the `Install a VCS Server`_ section of |RCC|
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Nix Packaging
|
||||
=============
|
||||
|
||||
|RCM| is installed using |Nix Package Manager|. The Nix environment provides
|
||||
|RCE| is installed using |Nix Package Manager|. The Nix environment provides
|
||||
the following features for maintenance and deployment:
|
||||
|
||||
* Atomic upgrades and rollbacks
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|RCE| 3.0.0 |RNS|
|
||||
-----------------
|
||||
|
||||
As |RCM| 3.0 is a big release, the release notes have been split into the following sections:
|
||||
As |RCE| 3.0 is a big release, the release notes have been split into the following sections:
|
||||
|
||||
* :ref:`general-rn-ref`
|
||||
* :ref:`security-rn-ref`
|
||||
|
|
|
|||
|
|
@ -44,10 +44,10 @@ following example:
|
|||
Installing |RCT|
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
|RCT| enable you to automate many of the most common |RCM| functions through
|
||||
|RCT| enable you to automate many of the most common |RCE| functions through
|
||||
the API. Installing them on a local machine lets you carry out maintenance on
|
||||
the server remotely. Once installed you can use them to index your |repos|
|
||||
to setup full-text search, strip commits, or install |RC| Extensions for
|
||||
to setup full-text search, strip commits, or install RhodeCode Extensions for
|
||||
additional functionality.
|
||||
|
||||
For more detailed instructions about using |RCT| for indexing and full-text
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|RCT|
|
||||
=====
|
||||
|
||||
|RCT| enable you to automate many of the most common |RCM| functions through
|
||||
|RCT| enable you to automate many of the most common |RCE| functions through
|
||||
the API.
|
||||
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ rhodecode-tools
|
|||
---------------
|
||||
|
||||
Use |RCT| to setup automation, run the indexer, and install extensions for
|
||||
your |RCM| instances. Options:
|
||||
your |RCE| instances. Options:
|
||||
|
||||
.. rst-class:: dl-horizontal
|
||||
|
||||
|
|
@ -49,7 +49,7 @@ Example usage:
|
|||
rhodecode-api
|
||||
-------------
|
||||
|
||||
The |RC| API lets you connect to |RCE| and carry out management tasks from a
|
||||
The RhodeCode API lets you connect to |RCE| and carry out management tasks from a
|
||||
remote machine, for more information about the API, see the :ref:`api`. To
|
||||
pass arguments on the command-line use the ``method:option`` syntax.
|
||||
|
||||
|
|
@ -117,7 +117,7 @@ Options:
|
|||
rhodecode-cleanup-gists
|
||||
-----------------------
|
||||
|
||||
Use this to delete gists within |RCM|. Options:
|
||||
Use this to delete gists within |RCE|. Options:
|
||||
|
||||
.. rst-class:: dl-horizontal
|
||||
|
||||
|
|
@ -166,7 +166,7 @@ Example usage:
|
|||
rhodecode-cleanup-repos
|
||||
-----------------------
|
||||
|
||||
Use this to manage |repos| and |repo| groups within |RCM|. Options:
|
||||
Use this to manage |repos| and |repo| groups within |RCE|. Options:
|
||||
|
||||
.. rst-class:: dl-horizontal
|
||||
|
||||
|
|
@ -280,7 +280,7 @@ the using :ref:`integrations-rcextensions` section.
|
|||
rhodecode-gist
|
||||
--------------
|
||||
|
||||
Use this to create, list, show, or delete gists within |RCM|. Options:
|
||||
Use this to create, list, show, or delete gists within |RCE|. Options:
|
||||
|
||||
.. rst-class:: dl-horizontal
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ To install |RCT| correctly, see the installation steps covered in
|
|||
:ref:`install-tools`, and :ref:`config-rhoderc`.
|
||||
|
||||
Once |RCT| is installed, and the :file:`/home/{user}/.rhoderc` file is
|
||||
configured you can then use |RCT| on each |RCM| instance to carry out admin
|
||||
configured you can then use |RCT| on each |RCE| instance to carry out admin
|
||||
tasks. Use the following example to configure that file,
|
||||
and once configured see the :ref:`tools-cli` for more details.
|
||||
|
||||
|
|
|
|||
|
|
@ -95,10 +95,10 @@ but below is the example shortcut.
|
|||
|
||||
# Check that the script is uploaded to your home directory
|
||||
$ ls -1
|
||||
RhodeCode-installer-linux-391_b1a804c4d69b_d6c087d520e3
|
||||
RhodeCode-installer-linux-buildYYYYXXXX_ZZZZ
|
||||
|
||||
# Change the script permissions
|
||||
$ chmod 755 RhodeCode-installer-linux*
|
||||
$ chmod +x RhodeCode-installer-linux*
|
||||
|
||||
# Run the installer and accept the prompts
|
||||
$ ./RhodeCode-installer-linux-*
|
||||
|
|
|
|||
|
|
@ -7,13 +7,13 @@
|
|||
Git Large File Storage (or LFS) is a new, open-source extension to Git that
|
||||
aims to improve handling of large files. It does this by replacing large files
|
||||
in your repository—such as graphics and videos—with simple text pointers.
|
||||
|RC| Server includes an embedded LFS object store server, allowing storage of
|
||||
RhodeCode Server includes an embedded LFS object store server, allowing storage of
|
||||
large files without the need for an external object store.
|
||||
Git LFS is disabled by default, globally, and for each individual repository.
|
||||
|
||||
.. note::
|
||||
|
||||
|RC| implements V2 API of Git LFS. Please make sure your git client is
|
||||
RhodeCode implements V2 API of Git LFS. Please make sure your git client is
|
||||
using the latest version (2.0.X recommended) to leverage full feature set
|
||||
of the V2 API.
|
||||
|
||||
|
|
@ -22,7 +22,7 @@ Git LFS is disabled by default, globally, and for each individual repository.
|
|||
Enabling Git LFS
|
||||
++++++++++++++++
|
||||
|
||||
Git LFS is disabled by default within |RC| Server.
|
||||
Git LFS is disabled by default within RhodeCode Server.
|
||||
|
||||
To enable Git LFS Globally:
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ size in bytes. For example::
|
|||
|
||||
|
||||
The object itself will be uploaded to a separate location via the Git LFS Batch API.
|
||||
The transfer is validated and authorized by |RC| server itself.
|
||||
The transfer is validated and authorized by RhodeCode server itself.
|
||||
|
||||
If give repository has Git LFS disabled, a proper message will be sent back to
|
||||
the client and upload of LFS objects will be forbidden.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ of the current revision. This saves both disk space and bandwidth.
|
|||
Enabling HG Largefiles
|
||||
++++++++++++++++++++++
|
||||
|
||||
Mercurial Largefiles extension is disabled by default within |RC| Server.
|
||||
Mercurial Largefiles extension is disabled by default within RhodeCode Server.
|
||||
|
||||
To enable Mercurial Largefiles Globally:
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Pre-requisites
|
|||
* For MySQL, do not use `localhost` in the database connection string of the
|
||||
:file:`rhodecode.ini` file.
|
||||
* InnoDB must be the database tables engine.
|
||||
* Contact |RC| for a new licence Key/Token pair. If you don't, a trial licence
|
||||
* Contact RhodeCode for a new licence Key/Token pair. If you don't, a trial licence
|
||||
will be applied so you are not locked out of the upgraded instance.
|
||||
|
||||
You can find the specific instructions to carry out these pre-requisite steps
|
||||
|
|
|
|||
|
|
@ -3,19 +3,19 @@
|
|||
Getting Started with VCS
|
||||
------------------------
|
||||
|
||||
When using |RCM|, you will be working with |git|, |svn| or |hg| |repos| from the
|
||||
When using |RCE|, you will be working with |git|, |svn| or |hg| |repos| from the
|
||||
command line or using a GUI client such as Tortoise, Tower or SourceTree.
|
||||
|
||||
|RCM| uses a standard |git|, |svn| and |hg| protocols. So all tools that
|
||||
|RCE| uses a standard |git|, |svn| and |hg| protocols. So all tools that
|
||||
can interact with there protocols are supported, including Eclipse or PyCharm
|
||||
plugins.
|
||||
|
||||
|
||||
If you have never used either before, the following information should
|
||||
help you set up your local machine so that you can sync changes with the
|
||||
|RCM| server.
|
||||
|RCE| server.
|
||||
|
||||
All of the following instructions assume you have a |RCM| account,
|
||||
All of the following instructions assume you have a |RCE| account,
|
||||
and you can access your |repos| from the web interface.
|
||||
|
||||
.. note::
|
||||
|
|
|
|||
|
|
@ -3,14 +3,14 @@ File Editing
|
|||
|
||||
To edit files using the online editor, use the following steps.
|
||||
|
||||
1. From the |RCM| interface, select :menuselection:`Admin --> Repositories`
|
||||
1. From the |RCE| interface, select :menuselection:`Admin --> Repositories`
|
||||
2. Select the |repo| in which you want to edit a file.
|
||||
3. Select the :guilabel:`file` view of the |repo|, and double-click on the file.
|
||||
4. To open the editor, select the :guilabel:`edit on branch:default` button.
|
||||
|
||||
* If the filename has an extension |RCM| recognises,
|
||||
* If the filename has an extension |RCE| recognises,
|
||||
the syntax highlighting will appear automatically.
|
||||
* If the filename does not have an extension |RCM| recognises,
|
||||
* If the filename does not have an extension |RCE| recognises,
|
||||
you can set the language syntax highlighter by
|
||||
choosing from the file type drop down menu.
|
||||
5. To save your changes, select :guilabel:`Commit changes`
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Gist Editing
|
|||
^^^^^^^^^^^^
|
||||
|
||||
Gists are standalone files that only the creator can edit. To work with
|
||||
gists, click on the :guilabel:`Gists` tab on the |RCM| header. The gist
|
||||
gists, click on the :guilabel:`Gists` tab on the |RCE| header. The gist
|
||||
editor also has syntax highlighting.
|
||||
|
||||
You can set the following properties for each gist:
|
||||
|
|
@ -13,7 +13,7 @@ You can set the following properties for each gist:
|
|||
and will show up in searches.
|
||||
* :guilabel:`Gist Lifetime`: You can set a gist to expire after a set
|
||||
period by using the :guilabel:`Gist Lifetime` dropdown menu.
|
||||
This means that when the gist expires it will be deleted from the |RCM|
|
||||
This means that when the gist expires it will be deleted from the |RCE|
|
||||
gist database.
|
||||
* :guilabel:`Private`: This means that the gist will not show up in searches.
|
||||
* :guilabel:`Gist access level`: If you create a private gist you can have
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Online Editing
|
||||
--------------
|
||||
|
||||
|RCM| has an integrated online editor, allowing you to edit files in the
|
||||
|RCE| has an integrated online editor, allowing you to edit files in the
|
||||
browser. The online editor has syntax highlighting and the ability to fork,
|
||||
merge, and commit changes to files.
|
||||
|
||||
|
|
|
|||
|
|
@ -249,7 +249,7 @@ class LdapSettingsSchema(AuthnPluginSettingsSchemaBase):
|
|||
colander.Int(),
|
||||
default=389,
|
||||
description=_('Custom port that the LDAP server is listening on. '
|
||||
'Default value is: 389'),
|
||||
'Default value is: 389, use 689 for LDAPS(SSL)'),
|
||||
preparer=strip_whitespace,
|
||||
title=_('Port'),
|
||||
validator=colander.Range(min=0, max=65536),
|
||||
|
|
|
|||
|
|
@ -534,7 +534,7 @@ address {
|
|||
color: @grey4;
|
||||
font-family: @text-light;
|
||||
&.pre-formatting {
|
||||
white-space: pre;
|
||||
white-space: pre-wrap;
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -97,6 +97,18 @@
|
|||
${h.end_form()}
|
||||
</div>
|
||||
</div>
|
||||
|
||||
% if request.GET.get('schema'):
|
||||
## this is for development and creation of example configurations for documentation
|
||||
<pre>
|
||||
% for node in plugin.get_settings_schema():
|
||||
*option*: `${node.name}` => `${defaults.get(node.name)}`${'\n # '.join(['']+node.description.splitlines())}
|
||||
|
||||
% endfor
|
||||
</pre>
|
||||
|
||||
% endif
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -104,8 +116,7 @@
|
|||
</div>
|
||||
</div>
|
||||
|
||||
## TODO: Ugly hack to get ldap select elements to work.
|
||||
## Find a solution to integrate this nicely.
|
||||
|
||||
<script>
|
||||
$(document).ready(function() {
|
||||
var select2Options = {
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue