docs: fixed config files path for editing settings...

docs/admin/lab-settings.rst

@@ -1,31 +1,31 b''
 .. _lab-settings:
 
 Lab Settings
 ============
 
 |RCE| Lab Settings is for delivering features which may require an additional
 level of support to optimize for production scenarios. To enable lab settings,
 use the following instructions:
 
 1. Open the |RCE| configuration file,
-   :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+   :file:`config/_shared/rhodecode.ini`
 
 2. Add the following configuration option in the ``[app:main]`` section.
 
 .. code-block:: bash
 
    [app:main]
 
    ## Display extended labs settings
    labs_settings_active = true
 
 3. Restart your |RCE| instance
 
 .. code-block:: bash
 
    $ rccontrol restart enterprise-1
 
 4. You will see the labs setting on the
    :menuselection:`Admin --> Settings --> labs` page.
 
 .. image:: ../images/lab-setting.png

docs/admin/sec-x-frame.rst

@@ -1,57 +1,57 b''
 .. _x-frame:
 
 Securing HTTPS Connections
 --------------------------
 
 * To secure your |RCE| instance against `Cross Frame Scripting`_ exploits, you
   should configure your webserver ``x-frame-options`` setting.
 
 * To configure your instance for `HTTP Strict Transport Security`_, you need to
   configure the ``Strict-Transport-Security`` setting.
 
 Nginx
 ^^^^^
 
 In your nginx configuration, add the following lines in the correct files. For
 more detailed information see the :ref:`nginx-ws-ref` section.
 
 .. code-block:: nginx
 
     # Add this line to the nginx.conf file
     add_header X-Frame-Options SAMEORIGIN;
 
     # This line needs to be added inside your virtual hosts block/file
     add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
 
 Apache
 ^^^^^^
 
 In your :file:`apache2.conf` file, add the following line. For more detailed
 information see the :ref:`apache-ws-ref` section.
 
 .. code-block:: apache
 
     # Add this to your virtual hosts file
     Header always append X-Frame-Options SAMEORIGIN
 
     # Add this line in your virtual hosts file
     Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
 
 |RCE| Configuration
 ^^^^^^^^^^^^^^^^^^^
 
 |RCE| can also be configured to force strict *https* connections and Strict
 Transport Security. To set this, configure the following options to ``true``
-in the :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file.
+in the :file:`config/_shared/rhodecode.ini` file.
 
 .. code-block:: ini
 
     ## force https in RhodeCode, fixes https redirects, assumes it's always https
     force_https = false
 
     ## use Strict-Transport-Security headers
     use_htsts = false
 
 
 .. _Cross Frame Scripting: https://www.owasp.org/index.php/Cross_Frame_Scripting
 .. _HTTP Strict Transport Security: https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
  No newline at end of file

docs/admin/sec-your-server.rst

@@ -1,179 +1,179 b''
 .. _sec-your-server:
 
 Securing Your Server
 --------------------
 
 |RCE| runs on your hardware, and while it is developed with security in mind
 it is also important that you ensure your servers are well secured. In this
 section we will cover some basic security practices that are best to
 configure when setting up your |RCE| instances.
 
 SSH Keys
 ^^^^^^^^
 
 Using SSH keys to access your server provides more security than using the
 standard username and password combination. To set up your SSH Keys, use the
 following steps:
 
 1. On your local machine create the public/private key combination. The
    private key you will keep, and the matching public key is copied to the
    server. Setting a passphrase here is optional, if you set one you will
    always be prompted for it when logging in.
 
 .. code-block:: bash
 
     # Generate SSH Keys
     user@ubuntu:~$ ssh-keygen -t rsa
 
 .. code-block:: bash
 
     Generating public/private rsa key pair.
     Enter file in which to save the key (/home/user/.ssh/id_rsa):
     Created directory '/home/user/.ssh'.
     Enter passphrase (empty for no passphrase):
     Enter same passphrase again:
     Your identification has been saved in /home/user/.ssh/id_rsa.
     Your public key has been saved in /home/user/.ssh/id_rsa.pub.
     The key fingerprint is:
     02:82:38:95:e5:30:d2:ad:17:60:15:7f:94:17:9f:30 user@ubuntu
     The key\'s randomart image is:
     +--[ RSA 2048]----+
 
 2. SFTP to your server, and copy the public key to the ``~/.ssh`` folder.
 
 .. code-block:: bash
 
     # SFTP to your server
     $ sftp user@hostname
 
     # copy your public key
     sftp> mput /home/user/.ssh/id_rsa.pub /home/user/.ssh
     Uploading /home/user/.ssh/id_rsa.pub to /home/user/.ssh/id_rsa.pub
     /home/user/.ssh/id_rsa.pub      100%  394     0.4KB/s   00:00
 
 3. On your server, add the public key to the :file:`~/.ssh/authorized_keys`
    file.
 
 .. code-block:: bash
 
     $ cat /home/user/.ssh/id_rsa.pub > /home/user/.ssh/authorized_keys
 
 You should now be able to log into your server using your SSH
 Keys. If you've added a passphrase you'll be asked for it. For more
 information about using SSH keys with |RCE| |repos|, see the
 :ref:`ssh-connection` section.
 
 VPN Whitelist
 ^^^^^^^^^^^^^
 
 Most company networks will have a VPN. If you need to set one up, there are
 many tutorials online for how to do that. Getting it right requires good
 knowledge and attention to detail. Once set up, you can configure your
 |RCE| instances to only allow user access from the VPN, to do this see the
 :ref:`settip-ip-white` section.
 
 Public Key Infrastructure and SSL/TLS Encryption
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Public key infrastructure (PKI) is a system that creates, manages, and
 validates certificates for identifying nodes on a network and encrypting
 communication between them. SSL or TLS certificates can be used to
 authenticate different entities with one another. To read more about PKIs,
 see the `OpenSSL PKI tutorial`_ site, or this `Cloudflare PKI post`_.
 
 If the network you are running is SSL/TLS encrypted, you can configure |RCE|
 to always use secure connections using the ``force_https`` and ``use_htsts``
-options in the :file:`/home/user/.rccontrol/instance-id/rhodecode.ini` file.
+options in the :file:`config/_shared/rhodecode.ini` file.
 For more details, see the :ref:`x-frame` section.
 
 FireWalls and Ports
 ^^^^^^^^^^^^^^^^^^^
 
 Setting up a network firewall for your internal traffic is a good way
 of keeping it secure by blocking off any ports that should not be used.
 Additionally, you can set non-default ports for certain functions which adds
 an extra layer of security to your setup.
 
 A well configured firewall will restrict access to everything except the
 services you need to remain open. By exposing fewer services you reduce the
 number of potential vulnerabilities.
 
 There are a number of different firewall solutions, but for most Linux systems
 using the built in `IpTables`_ firewall should suffice. On BSD systems you
 can use `IPFILTER`_ or `IPFW`_. Use the following examples, and the IpTables
 documentation to configure your IP Tables on Ubuntu.
 
 Changing the default SSH port.
 
 .. code-block:: bash
 
     # Open SSH config file and change to port 10022
     vi /etc/ssh/sshd_config
 
     # What ports, IPs and protocols we listen for
     Port 10022
 
 Setting IP Table rules for SSH traffic. It is important to note that the
 default policy of your IpTables can differ and it is worth checking how each
 is configured. The options are *ACCEPT*, *REJECT*, *DROP*, or *LOG*. The
 usual practice is to block access on all ports and then enable access only on
 the ports you with to expose.
 
 .. code-block:: bash
 
     # Check iptables policy
     $ sudo iptables -L
 
     Chain INPUT (policy ACCEPT)
     target     prot opt source               destination
 
     Chain FORWARD (policy ACCEPT)
     target     prot opt source               destination
 
     Chain OUTPUT (policy ACCEPT)
     target     prot opt source               destination
 
     # Close all ports by default
     $ sudo iptables -P INPUT DROP
 
     $ sudo iptables -L
     Chain INPUT (policy DROP)
     target     prot opt source               destination
     DROP       all  --  anywhere             anywhere
 
     Chain FORWARD (policy ACCEPT)
     target     prot opt source               destination
 
     Chain OUTPUT (policy ACCEPT)
     target     prot opt source               destination
 
 .. code-block:: bash
 
     # Deny outbound SSH traffic
     sudo iptables -A OUTPUT -p tcp --dport 10022 -j DROP
 
     # Allow incoming SSH traffic on port 10022
     sudo iptables -A INPUT -p tcp --dport 10022 -j ACCEPT
 
     # Allow incoming HTML traffic on port 80 and 443
     iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
     iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
 
 Saving your IP Table rules, and restoring them from file.
 
 .. code-block:: bash
 
     # Save you IP Table Rules
     iptables-save
 
     # Save your IP Table Rules to a file
     sudo sh -c "iptables-save > /etc/iptables.rules"
 
     # Restore your IP Table rules from file
     iptables-restore < /etc/iptables.rules
 
 .. _OpenSSL PKI tutorial: https://pki-tutorial.readthedocs.org/en/latest/#
 .. _Cloudflare PKI post: https://blog.cloudflare.com/how-to-build-your-own-public-key-infrastructure/
 .. _IpTables: https://help.ubuntu.com/community/IptablesHowTo
 .. _IPFW: https://www.freebsd.org/doc/handbook/firewalls-ipfw.html
 .. _IPFILTER: https://www.freebsd.org/doc/handbook/firewalls-ipf.html

docs/admin/system-overview.rst

@@ -1,172 +1,172 b''
 .. _system-overview-ref:
 
 System Overview
 ===============
 
 Latest Version
 --------------
 
 * |release| on Unix and Windows systems.
 
 System Architecture
 -------------------
 
 The following diagram shows a typical production architecture.
 
 .. image:: ../images/architecture-diagram.png
   :align: center
 
 Supported Operating Systems
 ---------------------------
 
 Linux
 ^^^^^
 
 * Ubuntu 14.04+
 * CentOS 6.2, 7 and 8
 * RHEL 6.2, 7 and 8
 * Debian 7.8
 * RedHat Fedora
 * Arch Linux
 * SUSE Linux
 
 Windows
 ^^^^^^^
 
 * Windows Vista Ultimate 64bit
 * Windows 7 Ultimate 64bit
 * Windows 8 Professional 64bit
 * Windows 8.1 Enterprise 64bit
 * Windows Server 2008 64bit
 * Windows Server 2008-R2 64bit
 * Windows Server 2012 64bit
 
 Supported Databases
 -------------------
 
 * SQLite
 * MySQL
 * MariaDB
 * PostgreSQL
 
 Supported Browsers
 ------------------
 
 * Chrome
 * Safari
 * Firefox
 * Internet Explorer 10 & 11
 
 System Requirements
 -------------------
 
 |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.
 
 
 For example:
 
  - for team of 1 - 5 active users you can run on 1GB RAM machine with 1CPU
  - 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
 
 
 .. _config-rce-files:
 
 Configuration Files
 -------------------
 
-* :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+* :file:`config/_shared/rhodecode.ini`
 * :file:`/home/{user}/.rccontrol/{instance-id}/search_mapping.ini`
 * :file:`/home/{user}/.rccontrol/{vcsserver-id}/vcsserver.ini`
 * :file:`/home/{user}/.rccontrol/supervisor/supervisord.ini`
 * :file:`/home/{user}/.rccontrol.ini`
 * :file:`/home/{user}/.rhoderc`
 * :file:`/home/{user}/.rccontrol/cache/MANIFEST`
 
 For more information, see the :ref:`config-files` section.
 
 Log Files
 ---------
 
 * :file:`/home/{user}/.rccontrol/{instance-id}/enterprise.log`
 * :file:`/home/{user}/.rccontrol/{vcsserver-id}/vcsserver.log`
 * :file:`/home/{user}/.rccontrol/supervisor/supervisord.log`
 * :file:`/tmp/rccontrol.log`
 * :file:`/tmp/rhodecode_tools.log`
 
 Storage Files
 -------------
 
 * :file:`/home/{user}/.rccontrol/{instance-id}/data/index/{index-file.toc}`
 * :file:`/home/{user}/repos/.rc_gist_store`
 * :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.db`
 * :file:`/opt/rhodecode/store/{unique-hash}`
 
 Default Repositories Location
 -----------------------------
 
 * :file:`/home/{user}/repos`
 
 Connection Methods
 ------------------
 
 * HTTPS
 * SSH
 * |RCE| API
 
 Internationalization Support
 ----------------------------
 
 Currently available in the following languages, see `Transifex`_ for the
 latest details. If you want a new language added, please contact us. To
 configure your language settings, see the :ref:`set-lang` section.
 
 .. hlist::
 
   * Belorussian
   * Chinese
   * French
   * German
   * Italian
   * Japanese
   * Portuguese
   * Polish
   * Russian
   * Spanish
 
 Licencing Information
 ---------------------
 
 * See licencing information `here`_
 
 Peer-to-peer Failover Support
 -----------------------------
 
 * Yes
 
 Additional Binaries
 -------------------
 
 * Yes, see :ref:`rhodecode-nix-ref` for full details.
 
 Remote Connectivity
 -------------------
 
 * Available
 
 Executable Files
 ----------------
 
 Windows: :file:`RhodeCode-installer-{version}.exe`
 
 Deprecated Support
 ------------------
 
 - Internet Explorer 8 support deprecated since version 3.7.0.
 - Internet Explorer 9 support deprecated since version 3.8.0.
 
 .. _here: https://rhodecode.com/licenses/
 .. _Transifex: https://explore.transifex.com/rhodecode/RhodeCode/

docs/admin/system_admin/admin-tricks.rst

@@ -1,300 +1,300 b''
 .. _admin-tricks:
 
 One-time Admin Tasks
 --------------------
 
 * :ref:`web-analytics`
 * :ref:`admin-tricks-license`
 * :ref:`announcements`
 * :ref:`md-rst`
 * :ref:`repo-stats`
 * :ref:`server-side-merge`
 * :ref:`remap-rescan`
 * :ref:`custom-hooks`
 * :ref:`clear-repo-cache`
 * :ref:`set-repo-pub`
 * :ref:`ping`
 
 .. _web-analytics:
 
 Adding Web Analytics
 ^^^^^^^^^^^^^^^^^^^^
 
 If you wish to add a Google Analytics, or any other kind of tracker to your
 |RCE| instance you can add the necessary codes to the header or footer
 section of each instance using the following steps:
 
 1. From the |RCE| interface, select
    :menuselection:`Admin --> Settings --> Global`
 2. To add a tracking code to you instance, enter it in the header or footer
    section and select **Save**
 
 Use the example templates in the drop-down menu to set up your configuration.
 
 .. _admin-tricks-license:
 
 Licence Key Management
 ^^^^^^^^^^^^^^^^^^^^^^
 
 To manage your license key, go to
 :menuselection:`Admin --> Settings --> License`.
 On this page you can see the license key details. If you need a new license,
 or have questions about your current one, contact [e-mail]
 
 .. _announcements:
 
 Server-wide Announcements
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 If you need to make a server-wide announcement to all users,
 you can add a message to be displayed using the following steps:
 
 1. From the |RCE| interface, select
    :menuselection:`Admin --> Settings --> Global`
 2. To add a message that will be displayed to all users,
    select :guilabel:`Server Announcement` from the drop-down menu and
    change the ``var message = "TYPE YOUR MESSAGE HERE";`` example line.
 3. Select :guilabel:`Save`, and you will see the message once your page
    refreshes.
 
 .. image:: ../../images/server-wide-announcement.png
    :alt: Server Wide Announcement
 
 .. _md-rst:
 
 
 Suppress license warnings or errors
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 In case you're running on maximum allowed users, RhodeCode will display a
 warning message on pages that you're close to the license limits.
 It's often not desired to show that all the time. Here's how you can suppress
 the license messages.
 
 1. From the |RCE| interface, select
    :menuselection:`Admin --> Settings --> Global`
 2. Select :guilabel:`Flash message filtering` from the drop-down menu.
 3. Select :guilabel:`Save`, and you will no longer see the license message
    once your page refreshes.
 
 .. _admin-tricks-suppress-license-messages:
 
 
 Markdown or RST Rendering
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 |RCE| can use `Markdown`_ or `reStructured Text`_ in commit message,
 code review messages, and inline comments. To set the default to either,
 select your preference from the drop-down menu on the
 :menuselection:`Admin --> Settings --> Visual` page and select
 :guilabel:`Save settings`.
 
 .. _repo-stats:
 
 Enabling Repository Statistics
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To enable |repo| statistics, use the following steps:
 
 1. From the |RCE| interface, open
    :menuselection:`Admin --> Repositories` and select
    :guilabel:`Edit` beside the |repo| for which you wish to enable statistics.
 2. Check the :guilabel:`Enable statistics` box, and select :guilabel:`Save`
 
 .. _server-side-merge:
 
 Enabling Server-side Merging
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To enable server-side merging, use the following steps:
 
 1. From the |RCE| interface, open :menuselection:`Admin --> Settings --> VCS`
 2. Check the :guilabel:`Server-side merge` box, and select
    :guilabel:`Save Settings`
 
 If you encounter slow performance with server-side merging enabled, check the
 speed at which your server is performing actions. When server-side merging is
 enabled, the following actions occurs on the server.
 
 * A |pr| is created in the database.
 * A shadow |repo| is created as a working environment for the |pr|.
 * On display, |RCE| checks if the |pr| can be merged.
 
 To check how fast the shadow |repo| creation is occurring on your server, use
 the following steps:
 
 1. Log into your server and create a directory in your |repos| folder.
 2. Clone a |repo| that is showing slow performance and time the action.
 
 .. code-block:: bash
 
    # One option is to use the time command
    $ time hg clone SOURCE_REPO TARGET
 
 .. _remap-rescan:
 
 Remap and Rescan Repositories
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 You may want to Remap and rescan the |repos| that |RCE| is managing to ensure
 the system is always up-to-date. This is useful after importing, deleting,
 or carrying out general cleaning up operations. To do this use the
 following steps:
 
 1. From the |RCE|, open
    :menuselection:`Admin --> Settings --> Remap and rescan`
 2. Click :guilabel:`Rescan Repositories`
 
 Check the additional options if needed:
 
 * :guilabel:`Destroy old data`: Useful for purging deleted repository
   information from the database.
 * :guilabel:`Invalidate cache for all repositories`: Use this to completely
   remap all |repos|. Useful when importing or migrating |repos| to ensure all
   new information is picked up.
 
 .. _custom-hooks:
 
 Adding Custom Hooks
 ^^^^^^^^^^^^^^^^^^^
 
 To add custom hooks to your instance, use the following steps:
 
 1. Open :menuselection:`Admin --> Settings --> Hooks`
 2. Add your custom hook details, you can use a file path to specify custom
    hook scripts, for example:
    ``pretxnchangegroup.example`` with value ``python:/path/to/custom_hook.py:my_func_name``
 3. Select :guilabel:`Save`
 
 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.
 
 .. _clear-repo-cache:
 
 Clearing |repo| cache
 ^^^^^^^^^^^^^^^^^^^^^
 
 If you need to clear the cache for a particular |repo|, use the following steps:
 
 1. Open :menuselection:`Admin --> Repositories` and select :guilabel:`Edit`
    beside the |repo| whose cache you wish to clear.
 2. On the |repo| settings page, go to the :guilabel:`Caches` tab and select
    :guilabel:`Invalidate repository cache`.
 
 .. _set-lang:
 
 Changing Default Language
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To change the default language of a |RCE| instance, change the language code
-in the :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file. To
+in the :file:`config/_shared/rhodecode.ini` file. To
 do this, use the following steps.
 
 1. Open the :file:`rhodecode.ini` file and set the required language code.
 
 .. code-block:: ini
 
    ## Optional Languages
    ## en(default), de, fr, it, ja, pl, pt, ru, zh
    lang = de
 
 2. Restart the |RCE| instance and check that the language has been updated.
 
 .. code-block:: bash
 
    $ rccontrol restart enterprise-2
    Instance "enterprise-2" successfully stopped.
    Instance "enterprise-2" successfully started.
 
 .. image:: ../../images/language.png
 
 .. _set-repo-pub:
 
 Setting Repositories to Publish
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To automatically promote your local |repos| to public after pushing to |RCE|,
 enable the :guilabel:`Set repositories as publishing` option on the
 :menuselection:`Admin --> Settings --> VCS` page.
 
 .. note::
 
    This option is enabled by default on most |RCE| versions, but if upgrading
    from a 1.7.x version it could be disabled on upgrade due to inheriting
    older default settings.
 
 .. _ping:
 
 Pinging the |RCE| Server
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 You can check the IP Address of your |RCE| instance using the
 following URL: ``{instance-URL}/_admin/ping``.
 
 .. code-block:: bash
 
    $ curl https://your.rhodecode.url/_admin/ping
    pong[rce-7880] => 203.0.113.23
 
 .. _Markdown: http://daringfireball.net/projects/markdown/
 .. _reStructured Text: http://docutils.sourceforge.io/docs/index.html
 
 
 Unarchiving a repository
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Archive operation for the repository is similar as delete. Archive keeps the data for future references
 but makes the repository read-only. After archiving the repository it shouldn't be modified in any way.
 This is why repository settings are disabled for an archived repository.
 
 If there's a need for unarchiving a repository for some reasons, the interactive
 ishell interface should be used.
 
 .. code-block:: bash
 
   # Open iShell from the terminal
   $ rccontrol ishell enterprise-1/community-1
 
 .. code-block:: python
 
   # Set repository as un-archived
   In [1]: repo = Repository.get_by_repo_name('SOME_REPO_NAME')
   In [2]: repo.archived = False
   In [3]: Session().add(repo);Session().commit()
 
 
 
 
 Bulk change repository owner
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Here's how one can change an owner of repository for an user who has been de activated.
 Settings a new owner can be done via ishell for all repositories that past owner had.
 
 do run this script the interactive ishell interface should be used.
 
 .. code-block:: bash
 
   # Open iShell from the terminal
   $ rccontrol ishell enterprise-1/community-1
 
 
 .. code-block:: python
 
     from rhodecode.model.db import User, Repository, Session
     from rhodecode.model.permission import PermissionModel
 
     # replace old-owner and new-owner with your exact users
     old_owner = User.get_by_username('old-owner')
     new_owner = User.get_by_username('new-owner')
 
     # list of users we need to "flush" permissions
     affected_user_ids = [new_owner.user_id, old_owner.user_id]
 
     for repo in Repository.get_all_repos(user_id=old_owner.user_id):
         repo.user = new_owner
         Session().add(repo)
         Session().commit()
 
     PermissionModel().trigger_permission_flush(affected_user_ids)

docs/admin/system_admin/config-files-overview.rst

@@ -1,74 +1,74 b''
 .. _config-files:
 
 Configuration Files Overview
 ============================
 
 |RCE| and |RCC| have a number of different configuration files. The following
 is a brief explanation of each, and links to their associated configuration
 sections.
 
 .. rst-class:: dl-horizontal
 
     \- **rhodecode.ini**
         Default location:
-        :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+        :file:`config/_shared/rhodecode.ini`
 
         This is the main |RCE| configuration file and controls much of its
         default behaviour. It is also used to configure certain customer
         settings. Here are some of the most common reasons to make changes to
         this file.
 
         * :ref:`config-database`
         * :ref:`set-up-mail`
         * :ref:`increase-gunicorn`
         * :ref:`x-frame`
 
     \- **search_mapping.ini**
         Default location:
         :file:`/home/{user}/.rccontrol/{instance-id}/search_mapping.ini`
 
         This file is used to control the |RCE| indexer. It comes configured
         to index your instance. To change the default configuration, see
         :ref:`advanced-indexing`.
 
     \- **vcsserver.ini**
         Default location:
         :file:`/home/{user}/.rccontrol/{vcsserver-id}/vcsserver.ini`
 
         The VCS Server handles the connection between your |repos| and |RCE|.
         See the :ref:`vcs-server` section for configuration options and more
         detailed information.
 
     \- **supervisord.ini**
         Default location:
         :file:`/home/{user}/.rccontrol/supervisor/supervisord.ini`
 
         |RCC| uses Supervisor to monitor and manage installed instances of
         |RCE| and the VCS Server. |RCC| will manage this file completely,
         unless you install |RCE| in self-managed mode. For more information,
         see the :ref:`Supervisor Setup<control:supervisor-setup>` section.
 
     \- **.rccontrol.ini**
         Default location: :file:`/home/{user}/.rccontrol.ini`
 
         This file contains the instances that |RCC| starts at boot, which is all
         by default, but for more information, see
         the :ref:`Manually Start At Boot <control:set-start-boot>` section.
 
     \- **.rhoderc**
         Default location: :file:`/home/{user}/.rhoderc`
 
         This file is used by the |RCE| API when accessing an instance from a
         remote machine. The API checks this file for connection and
         authentication details. For more details, see the :ref:`config-rhoderc`
         section.
 
     \- **MANIFEST**
         Default location: :file:`/home/{user}/.rccontrol/cache/MANIFEST`
 
         |RCC| uses this file to source the latest available builds from the
         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.
 

docs/admin/system_admin/enable-debug.rst

@@ -1,148 +1,148 b''
 .. _debug-mode:
 
 Enabling Debug Mode
 -------------------
 
 Debug Mode will enable debug logging, and request tracking middleware. Debug Mode
 enabled DEBUG log-level which allows tracking various information about authentication
 failures, LDAP connection, email etc.
 
 The request tracking will add a special
 unique ID: `| req_id:00000000-0000-0000-0000-000000000000` at the end of each log line.
 The req_id is the same for each individual requests, it means that if you want to
 track particular user logs only, and exclude other concurrent ones
 simply grep by `req_id` uuid which you'll have to find for the individual request.
 
 To enable debug mode on a |RCE| instance you need to set the debug property
-in the :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file. To
+in the :file:`config/_shared/rhodecode.ini` file. To
 do this, use the following steps
 
 1. Open the file and set the ``debug`` line to ``true``
 2. Restart you instance using the ``rccontrol restart`` command,
    see the following example:
 
 .. code-block:: ini
 
     [DEFAULT]
     debug = true
 
 .. code-block:: bash
 
     # Restart your instance
     $ rccontrol restart enterprise-1
     Instance "enterprise-1" successfully stopped.
     Instance "enterprise-1" successfully started.
 
 
 Debug and Logging Configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Further debugging and logging settings can also be set in the
-:file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file.
+:file:`config/_shared/rhodecode.ini` file.
 
 In the logging section, the various packages that run with |RCE| can have
 different debug levels set. If you want to increase the logging level change
 ``level = DEBUG`` line to one of the valid options.
 
 You also need to change the log level for handlers. See the example
 ``##handler`` section below. The ``handler`` level takes the same options as
 the ``debug`` level.
 
 .. code-block:: ini
 
     ################################
     ### LOGGING CONFIGURATION   ####
     ################################
     [loggers]
     keys = root, sqlalchemy, beaker, celery, rhodecode, ssh_wrapper
 
     [handlers]
     keys = console, console_sql, file, file_rotating
 
     [formatters]
     keys = generic, color_formatter, color_formatter_sql
 
     #############
     ## LOGGERS ##
     #############
     [logger_root]
     level = NOTSET
     handlers = console
 
     [logger_sqlalchemy]
     level = INFO
     handlers = console_sql
     qualname = sqlalchemy.engine
     propagate = 0
 
     [logger_beaker]
     level = DEBUG
     handlers =
     qualname = beaker.container
     propagate = 1
 
     [logger_rhodecode]
     level = DEBUG
     handlers =
     qualname = rhodecode
     propagate = 1
 
     [logger_ssh_wrapper]
     level = DEBUG
     handlers =
     qualname = ssh_wrapper
     propagate = 1
 
     [logger_celery]
     level = DEBUG
     handlers =
     qualname = celery
 
     ##############
     ## HANDLERS ##
     ##############
 
     [handler_console]
     class = StreamHandler
     args = (sys.stderr, )
     level = DEBUG
     formatter = generic
 
     [handler_console_sql]
     class = StreamHandler
     args = (sys.stderr, )
     level = INFO
     formatter = generic
 
     [handler_file]
     class = FileHandler
     args = ('rhodecode_debug.log', 'a',)
     level = INFO
     formatter = generic
 
     [handler_file_rotating]
     class = logging.handlers.TimedRotatingFileHandler
     # 'D', 5 - rotate every 5days
     # you can set 'h', 'midnight'
     args = ('rhodecode_debug_rotated.log', 'D', 5, 10,)
     level = INFO
     formatter = generic
 
     ################
     ## FORMATTERS ##
     ################
 
     [formatter_generic]
     class = rhodecode.lib.logging_formatter.ExceptionAwareFormatter
     format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
     datefmt = %Y-%m-%d %H:%M:%S
 
     [formatter_color_formatter]
     class = rhodecode.lib.logging_formatter.ColorFormatter
     format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
     datefmt = %Y-%m-%d %H:%M:%S
 
     [formatter_color_formatter_sql]
     class = rhodecode.lib.logging_formatter.ColorFormatterSql
     format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
     datefmt = %Y-%m-%d %H:%M:%S
  No newline at end of file

docs/admin/system_admin/svn-http.rst

@@ -1,208 +1,208 b''
 .. _svn-http:
 
 |svn| With Write Over HTTP
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To use |svn| with read/write support over the |svn| HTTP protocol, you have to
 configure the HTTP |svn| backend.
 
 Prerequisites
 =============
 
 - Enable HTTP support inside the admin VCS settings on your |RCE| instance
 - You need to install the following tools on the machine that is running an
   instance of |RCE|:
   ``Apache HTTP Server`` and ``mod_dav_svn``.
 
 
 .. tip::
 
    We recommend using Wandisco repositories which provide latest SVN versions
    for most platforms. If you skip this version you'll have to ensure the Client version
    is compatible with installed SVN version which might differ depending on the operating system.
    Here is an example how to add the Wandisco repositories for Ubuntu.
 
     .. code-block:: bash
 
         $ sudo sh -c 'echo "deb http://opensource.wandisco.com/ubuntu `lsb_release -cs` svn110" >> /etc/apt/sources.list.d/subversion110.list'
         $ sudo wget -q http://opensource.wandisco.com/wandisco-debian-new.gpg -O- | sudo apt-key add -
         $ sudo apt-get update
 
     Here is an example how to add the Wandisco repositories for Centos/Redhat. Using
     a yum config
 
     .. code-block:: bash
 
         [wandisco-Git]
         name=CentOS-6 - Wandisco Git
         baseurl=http://opensource.wandisco.com/centos/6/git/$basearch/
         enabled=1
         gpgcheck=1
         gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco
 
 
 
 Example installation of required components for Ubuntu platform:
 
 .. code-block:: bash
 
     $ sudo apt-get install apache2
     $ sudo apt-get install libapache2-svn
 
 Once installed you need to enable ``dav_svn`` on Ubuntu:
 
 .. code-block:: bash
 
     $ sudo a2enmod dav_svn
     $ sudo a2enmod headers
     $ sudo a2enmod authn_anon
 
 
 Example installation of required components for RedHat/CentOS platform:
 
 .. code-block:: bash
 
     $ sudo yum install httpd
     $ sudo yum install subversion mod_dav_svn
 
 
 Once installed you need to enable ``dav_svn`` on RedHat/CentOS:
 
 .. code-block:: bash
 
     sudo vi /etc/httpd/conf.modules.d/10-subversion.conf
     ## The file should read:
 
     LoadModule dav_svn_module     modules/mod_dav_svn.so
     LoadModule headers_module     modules/mod_headers.so
     LoadModule authn_anon_module  modules/mod_authn_anon.so
 
 .. tip::
 
    To check the installed mod_dav_svn module version, you can use such command.
 
    `strings /usr/lib/apache2/modules/mod_dav_svn.so | grep 'Powered by'`
 
 
 Configuring Apache Setup
 ========================
 
 .. tip::
 
    It is recommended to run Apache on a port other than 80, due to possible
    conflicts with other HTTP servers like nginx. To do this, set the
    ``Listen`` parameter in the ``/etc/apache2/ports.conf`` file, for example
    ``Listen 8090``.
 
 
 .. warning::
 
    Make sure your Apache instance which runs the mod_dav_svn module is
    only accessible by |RCE|. Otherwise everyone is able to browse
    the repositories or run subversion operations (checkout/commit/etc.).
 
 It is also recommended to run apache as the same user as |RCE|, otherwise
 permission issues could occur. To do this edit the ``/etc/apache2/envvars``
 
    .. code-block:: apache
 
       export APACHE_RUN_USER=rhodecode
       export APACHE_RUN_GROUP=rhodecode
 
 1. To configure Apache, create and edit a virtual hosts file, for example
    :file:`/etc/apache2/sites-enabled/default.conf`. Below is an example
    how to use one with auto-generated config ```mod_dav_svn.conf```
    from configured |RCE| instance.
 
 .. code-block:: apache
 
     <VirtualHost *:8090>
         ServerAdmin rhodecode-admin@localhost
         DocumentRoot /var/www/html
         ErrorLog ${'${APACHE_LOG_DIR}'}/error.log
         CustomLog ${'${APACHE_LOG_DIR}'}/access.log combined
         LogLevel info
         # allows custom host names, prevents 400 errors on checkout
         HttpProtocolOptions Unsafe
         # Most likely this will be: /home/user/.rccontrol/enterprise-1/mod_dav_svn.conf
         Include /home/user/.rccontrol/enterprise-1/mod_dav_svn.conf
     </VirtualHost>
 
 
 2. Go to the :menuselection:`Admin --> Settings --> VCS` page, and
    enable :guilabel:`Proxy Subversion HTTP requests`, and specify the
    :guilabel:`Subversion HTTP Server URL`.
 
 3. Open the |RCE| configuration file,
-   :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+   :file:`config/_shared/rhodecode.ini`
 
 4. Add the following configuration option in the ``[app:main]``
    section if you don't have it yet.
 
    This enables mapping of the created |RCE| repo groups into special
    |svn| paths. Each time a new repository group is created, the system will
    update the template file and create new mapping. Apache web server needs to
    be reloaded to pick up the changes on this file.
    To do this, simply configure `svn.proxy.reload_cmd` inside the .ini file.
    Example configuration:
 
 
 .. code-block:: ini
 
     ############################################################
     ### Subversion proxy support (mod_dav_svn)               ###
     ### Maps RhodeCode repo groups into SVN paths for Apache ###
     ############################################################
     ## Enable or disable the config file generation.
     svn.proxy.generate_config = true
     ## Generate config file with `SVNListParentPath` set to `On`.
     svn.proxy.list_parent_path = true
     ## Set location and file name of generated config file.
     svn.proxy.config_file_path = %(here)s/mod_dav_svn.conf
     ## Used as a prefix to the <Location> block in the generated config file.
     ## In most cases it should be set to `/`.
     svn.proxy.location_root = /
     ## Command to reload the mod dav svn configuration on change.
     ## Example: `/etc/init.d/apache2 reload`
     svn.proxy.reload_cmd = /etc/init.d/apache2 reload
     ## If the timeout expires before the reload command finishes, the command will
     ## be killed. Setting it to zero means no timeout. Defaults to 10 seconds.
     #svn.proxy.reload_timeout = 10
 
 
 This would create a special template file called ```mod_dav_svn.conf```. We
 used that file path in the apache config above inside the Include statement.
 It's also possible to manually generate the config from the
 :menuselection:`Admin --> Settings --> VCS` page by clicking a
 `Generate Apache Config` button.
 
 5. Now only things left is to enable svn support, and generate the initial
    configuration.
 
    - Select `Proxy subversion HTTP requests` checkbox
    - Enter http://localhost:8090 into `Subversion HTTP Server URL`
    - Click the `Generate Apache Config` button.
 
 This config will be automatically re-generated once an user-groups is added
 to properly map the additional paths generated.
 
 
 
 Using |svn|
 ===========
 
 Once |svn| has been enabled on your instance, you can use it with the
 following examples. For more |svn| information, see the `Subversion Red Book`_
 
 .. code-block:: bash
 
     # To clone a repository
     svn checkout http://my-svn-server.example.com/my-svn-repo
 
     # svn commit
     svn commit
 
 
 .. _Subversion Red Book: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svn
 
 .. _Ask Ubuntu: http://askubuntu.com/questions/162391/how-do-i-fix-my-locale-issue
  No newline at end of file

docs/admin/system_admin/tuning/tuning-change-encoding.rst

@@ -1,22 +1,22 b''
 .. _change-encoding:
 
 Change Default Encoding
 -----------------------
 
 |RCE| uses ``utf8`` encoding by default. You can change the default encoding
-in the :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file. To
+in the :file:`config/_shared/rhodecode.ini` file. To
 change the default encoding used by |RCE|, set a new value for the
 ``default_encoding``.
 
 .. code-block:: ini
 
         # default encoding used to convert from and to unicode
         # can be also a comma separated list of encoding in case of mixed
         # encodings
         default_encoding = utf8
 
 .. note::
 
        Changing the default encoding will affect many parts of your |RCE|
        installation, including committers names,
        file names, and the encoding of commit messages.

docs/admin/system_admin/tuning/tuning-hg-auth-loop.rst

@@ -1,17 +1,17 b''
 .. _hg-auth-loop:
 
 |hg| Authentication Tuning
 --------------------------
 
 When using external authentication tools such as LDAP with |hg|, a
 password retry loop in |hg| can result in users being locked out due to too
 many failed password attempts. To prevent this from happening, add the
 following setting to your
-:file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file, in the
+:file:`config/_shared/rhodecode.ini` file, in the
 ``[app:main]`` section.
 
 
 .. code-block:: ini
 
    [app:main]
    auth_ret_code_detection = true

docs/admin/system_admin/tuning/tuning-scale-horizontally-cluster.rst

@@ -1,396 +1,396 b''
 .. _scale-horizontal-cluster:
 
 
 Scale Horizontally / RhodeCode Cluster
 --------------------------------------
 
 |RCE| is built in a way it support horizontal scaling across multiple machines.
 There are three main pre-requisites for that:
 
 - Shared storage that each machine can access. Using NFS or other shared storage system.
 - Shared DB connection across machines. Using `MySQL`/`PostgreSQL` that each node can access.
 - |RCE| user sessions and caches need to use a shared storage (e.g `Redis`_/`Memcached`)
 
 
 Horizontal scaling means adding more machines or workers into your pool of
 resources. Horizontally scaling |RCE| gives a huge performance increase,
 especially under large traffic scenarios with a high number of requests.
 This is very beneficial when |RCE| is serving many users simultaneously,
 or if continuous integration servers are automatically pulling and pushing code.
 It also adds High-Availability to your running system.
 
 
 Cluster Overview
 ^^^^^^^^^^^^^^^^
 
 Below we'll present a configuration example that will use two separate nodes to serve
 |RCE| in a load-balanced environment. The 3rd node will act as a shared storage/cache
 and handle load-balancing. In addition 3rd node will be used as shared database instance.
 
 This setup can be used both in Docker based configuration or with individual
 physical/virtual machines. Using the 3rd node for Storage/Redis/PostgreSQL/Nginx is
 optional. All those components can be installed on one of the two nodes used for |RCE|.
 We'll use following naming for our nodes:
 
  - `rc-node-1` (NFS, DB, Cache node)
  - `rc-node-2` (Worker node1)
  - `rc-node-3` (Worker node2)
 
 Our shares NFS storage in the example is located on `/home/rcdev/storage` and
 it's RW accessible on **each** node.
 
 In this example we used certain recommended components, however many
 of those can be replaced by other, in case your organization already uses them, for example:
 
 - `MySQL`/`PostgreSQL`: Aren't replaceable and are the two only supported databases.
 - `Nginx`_ on `rc-node-1` can be replaced by: `Hardware Load Balancer (F5)`, `Apache`_, `HA-Proxy` etc.
 - `Nginx`_ on rc-node-2/3 acts as a reverse proxy and can be replaced by other HTTP server
   acting as reverse proxy such as `Apache`_.
 - `Redis`_ on `rc-node-1` can be replaced by: `Memcached`
 
 
 Here's an overview what components should be installed/setup on each server in our example:
 
 - **rc-node-1**:
 
  - main storage acting as NFS host.
  - `nginx` acting as a load-balancer.
  - `postgresql-server` used for database and sessions.
  - `redis-server` used for storing shared caches.
  - optionally `rabbitmq-server` or `redis` for `Celery` if used.
  - optionally if `Celery` is used Enterprise/Community instance + VCSServer.
  - optionally mailserver that can be shared by other instances.
  - optionally channelstream server to handle live communication for all instances.
 
 
 - **rc-node-2/3**:
 
  - `nginx` acting as a reverse proxy to handle requests to |RCE|.
  - 1x RhodeCode Enterprise/Community instance.
  - 1x VCSServer instance.
  - optionally for testing connection: postgresql-client, redis-client (redis-tools).
 
 
 Before we start here are few assumptions that should be fulfilled:
 
 - make sure each node can access each other.
 - make sure `Redis`_/`MySQL`/`PostgreSQL`/`RabbitMQ`_ are running on `rc-node-1`
 - make sure both `rc-node-2`/`3` can access NFS storage with RW access
 - make sure rc-node-2/3 can access `Redis`_/`PostgreSQL`, `MySQL` database on `rc-node-1`.
 - make sure `Redis`_/Database/`RabbitMQ`_ are password protected and accessible only from rc-node-2/3.
 
 
 
 Setup rc-node-2/3
 ^^^^^^^^^^^^^^^^^
 
 Initially before `rc-node-1` we'll configure both nodes 2 and 3 to operate as standalone
 nodes with their own hostnames. Use a default installation settings, and use
 the default local addresses (127.0.0.1) to configure VCSServer and Community/Enterprise instances.
 All external connectivity will be handled by the reverse proxy (`Nginx`_ in our example).
 
 This way we can ensure each individual host works,
 accepts connections, or do some operations explicitly on chosen node.
 
 In addition this would allow use to explicitly direct certain traffic to a node, e.g
 CI server will only call directly `rc-node-3`. This should be done similar to normal
 installation so check out `Nginx`_/`Apache`_ configuration example to configure each host.
 Each one should already connect to shared database during installation.
 
 
 1) Assuming our final url will be http://rc-node-1, Configure `instances_id`, `app.base_url`
 
-a) On **rc-node-2** find the following settings and edit :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+a) On **rc-node-2** find the following settings and edit :file:`config/_shared/rhodecode.ini`
 
 .. code-block:: ini
 
     ## required format is: *NAME-
     instance_id = *rc-node-2-
     app.base_url = http://rc-node-1
 
 
-b) On **rc-node-3** find the following settings and edit :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+b) On **rc-node-3** find the following settings and edit :file:`config/_shared/rhodecode.ini`
 
 .. code-block:: ini
 
     ## required format is: *NAME-
     instance_id = *rc-node-3-
     app.base_url = http://rc-node-1
 
 
 
 2) Configure `User Session` to use a shared database. Example config that should be
    changed on both **rc-node-2** and **rc-node-3** .
-   Edit :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+   Edit :file:`config/_shared/rhodecode.ini`
 
 .. code-block:: ini
 
     ####################################
     ###       BEAKER SESSION        ####
     ####################################
 
     ## Disable the default `file` sessions
     #beaker.session.type = file
     #beaker.session.data_dir = %(here)s/data/sessions
 
     ## use shared db based session, fast, and allows easy management over logged in users
     beaker.session.type = ext:database
     beaker.session.table_name = db_session
     # use our rc-node-1 here
     beaker.session.sa.url = postgresql://postgres:qweqwe@rc-node-1/rhodecode
     beaker.session.sa.pool_recycle = 3600
     beaker.session.sa.echo = false
 
 In addition make sure both instances use the same `session.secret` so users have
 persistent sessions across nodes. Please generate other one then in this example.
 
 .. code-block:: ini
 
     # use a unique generated long string
     beaker.session.secret = 70e116cae2274656ba7265fd860aebbd
 
 3) Configure stored cached/archive cache to our shared NFS `rc-node-1`
 
 .. code-block:: ini
 
     # note the `_` prefix that allows using a directory without
     # remap and rescan checking for vcs inside it.
     cache_dir = /home/rcdev/storage/_cache_dir/data
     # note archive cache dir is disabled by default, however if you enable
     # it also needs to be shared
     #archive_cache_dir = /home/rcdev/storage/_tarball_cache_dir
 
 
 4) Use shared exception store. Example config that should be
    changed on both **rc-node-2** and **rc-node-3**, and also for VCSServer.
-   Edit :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` and
+   Edit :file:`config/_shared/rhodecode.ini` and
    :file:`/home/{user}/.rccontrol/{vcsserver-instance-id}/vcsserver.ini`
    and add/change following setting.
 
 .. code-block:: ini
 
     exception_tracker.store_path = /home/rcdev/storage/_exception_store_data
 
 
 5) Change cache backends to use `Redis`_ based caches. Below full example config
    that replaces default file-based cache to shared `Redis`_ with Distributed Lock.
 
 
 .. code-block:: ini
 
     #####################################
     ###         DOGPILE CACHE        ####
     #####################################
 
     ## `cache_perms` cache settings for permission tree, auth TTL.
     #rc_cache.cache_perms.backend = dogpile.cache.rc.file_namespace
     #rc_cache.cache_perms.expiration_time = 300
 
     ## alternative `cache_perms` redis backend with distributed lock
     rc_cache.cache_perms.backend = dogpile.cache.rc.redis
     rc_cache.cache_perms.expiration_time = 300
     ## redis_expiration_time needs to be greater then expiration_time
     rc_cache.cache_perms.arguments.redis_expiration_time = 7200
     rc_cache.cache_perms.arguments.socket_timeout = 30
     rc_cache.cache_perms.arguments.host = rc-node-1
     rc_cache.cache_perms.arguments.password = qweqwe
     rc_cache.cache_perms.arguments.port = 6379
     rc_cache.cache_perms.arguments.db = 0
     rc_cache.cache_perms.arguments.distributed_lock = true
 
     ## `cache_repo` cache settings for FileTree, Readme, RSS FEEDS
     #rc_cache.cache_repo.backend = dogpile.cache.rc.file_namespace
     #rc_cache.cache_repo.expiration_time = 2592000
 
     ## alternative `cache_repo` redis backend with distributed lock
     rc_cache.cache_repo.backend = dogpile.cache.rc.redis
     rc_cache.cache_repo.expiration_time = 2592000
     ## redis_expiration_time needs to be greater then expiration_time
     rc_cache.cache_repo.arguments.redis_expiration_time = 2678400
     rc_cache.cache_repo.arguments.socket_timeout = 30
     rc_cache.cache_repo.arguments.host = rc-node-1
     rc_cache.cache_repo.arguments.password = qweqwe
     rc_cache.cache_repo.arguments.port = 6379
     rc_cache.cache_repo.arguments.db = 1
     rc_cache.cache_repo.arguments.distributed_lock = true
 
     ## cache settings for SQL queries, this needs to use memory type backend
     rc_cache.sql_cache_short.backend = dogpile.cache.rc.memory_lru
     rc_cache.sql_cache_short.expiration_time = 30
 
     ## `cache_repo_longterm` cache for repo object instances, this needs to use memory
     ## type backend as the objects kept are not pickle serializable
     rc_cache.cache_repo_longterm.backend = dogpile.cache.rc.memory_lru
     ## by default we use 96H, this is using invalidation on push anyway
     rc_cache.cache_repo_longterm.expiration_time = 345600
     ## max items in LRU cache, reduce this number to save memory, and expire last used
     ## cached objects
     rc_cache.cache_repo_longterm.max_size = 10000
 
 
 6) Configure `Nginx`_ as reverse proxy on `rc-node-2/3`:
    Minimal `Nginx`_ config used:
 
 
 .. code-block:: nginx
 
     ## rate limiter for certain pages to prevent brute force attacks
     limit_req_zone  $binary_remote_addr  zone=req_limit:10m   rate=1r/s;
 
     ## custom log format
     log_format log_custom '$remote_addr - $remote_user [$time_local] '
                           '"$request" $status $body_bytes_sent '
                           '"$http_referer" "$http_user_agent" '
                           '$request_time $upstream_response_time $pipe';
 
     server {
         listen          80;
         server_name     rc-node-2;
         #server_name     rc-node-3;
 
         access_log   /var/log/nginx/rhodecode.access.log log_custom;
         error_log    /var/log/nginx/rhodecode.error.log;
 
         # example of proxy.conf can be found in our docs.
         include     /etc/nginx/proxy.conf;
 
         ## serve static files by Nginx, recommended for performance
         location /_static/rhodecode {
             gzip on;
             gzip_min_length  500;
             gzip_proxied     any;
             gzip_comp_level 4;
             gzip_types  text/css text/javascript text/xml text/plain text/x-component application/javascript application/json application/xml application/rss+xml font/truetype font/opentype application/vnd.ms-fontobject image/svg+xml;
             gzip_vary on;
             gzip_disable     "msie6";
             expires 60d;
             #alias /home/rcdev/.rccontrol/community-1/static;
             alias /home/rcdev/.rccontrol/enterprise-1/static;
         }
 
 
         location /_admin/login {
             limit_req  zone=req_limit  burst=10  nodelay;
             try_files $uri @rhode;
         }
 
         location / {
             try_files $uri @rhode;
         }
 
         location @rhode {
             # Url to running RhodeCode instance.
             # This is shown as `- URL: <host>` in output from rccontrol status.
             proxy_pass      http://127.0.0.1:10020;
         }
 
         ## custom 502 error page. Will be displayed while RhodeCode server
         ## is turned off
         error_page 502 /502.html;
         location = /502.html {
            #root  /home/rcdev/.rccontrol/community-1/static;
            root  /home/rcdev/.rccontrol/enterprise-1/static;
         }
     }
 
 
 7) Optional: Full text search, in case you use `Whoosh` full text search we also need a
    shared storage for the index. In our example our NFS is mounted at `/home/rcdev/storage`
    which represents out storage so we can use the following:
 
 .. code-block:: ini
 
     # note the `_` prefix that allows using a directory without
     # remap and rescan checking for vcs inside it.
     search.location = /home/rcdev/storage/_index_data/index
 
 
 .. note::
 
     If you use ElasticSearch it's by default shared, and simply running ES node is
     by default cluster compatible.
 
 
 8) Optional: If you intend to use mailing all instances need to use either a shared
    mailing node, or each will use individual local mail agent. Simply put node-1/2/3
    needs to use same mailing configuration.
 
 
 
 Setup rc-node-1
 ^^^^^^^^^^^^^^^
 
 
 Configure `Nginx`_ as Load Balancer to rc-node-2/3.
 Minimal `Nginx`_ example below:
 
 .. code-block:: nginx
 
     ## define rc-cluster which contains a pool of our instances to connect to
     upstream rc-cluster {
         # rc-node-2/3 are stored in /etc/hosts with correct IP addresses
         server rc-node-2:80;
         server rc-node-3:80;
     }
 
     server {
         listen          80;
         server_name     rc-node-1;
 
         location / {
             proxy_pass http://rc-cluster;
         }
     }
 
 
 .. note::
 
    You should configure your load balancing accordingly. We recommend writing
    load balancing rules that will separate regular user traffic from
    automated process traffic like continuous servers or build bots. Sticky sessions
    are not required.
 
 
 Show which instance handles a request
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 You can easily check if load-balancing is working as expected. Visit our main node
 `rc-node-1` URL which at that point should already handle incoming requests and balance
 it across node-2/3.
 
 Add a special GET param `?showrcid=1` to show current instance handling your request.
 
 For example: visiting url `http://rc-node-1/?showrcid=1` will show, in the bottom
 of the screen` cluster instance info.
 e.g: `RhodeCode instance id: rc-node-3-rc-node-3-3246`
 which is generated from::
 
     <NODE_HOSTNAME>-<INSTANCE_ID>-<WORKER_PID>
 
 
 Using Celery with cluster
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 
 If `Celery` is used we recommend setting also an instance of Enterprise/Community+VCSserver
 on the node that is running `RabbitMQ`_ or `Redis`_. Those instances will be used to
 executed async tasks on the `rc-node-1`. This is the most efficient setup.
 `Celery` usually handles tasks such as sending emails, forking repositories, importing
 repositories from external location etc. Using workers on instance that has
 the direct access to disks used by NFS as well as email server gives noticeable
 performance boost. Running local workers to the NFS storage results in faster
 execution of forking large repositories or sending lots of emails.
 
 Those instances need to be configured in the same way as for other nodes.
 The instance in rc-node-1 can be added to the cluster, but we don't recommend doing it.
 For best results let it be isolated to only executing `Celery` tasks in the cluster setup.
 
 
 .. _Gunicorn: http://gunicorn.org/
 .. _Whoosh: https://pypi.python.org/pypi/Whoosh/
 .. _Elasticsearch: https://www.elastic.co/..
 .. _RabbitMQ: http://www.rabbitmq.com/
 .. _Nginx: http://nginx.io
 .. _Apache: http://nginx.io
 .. _Redis: http://redis.io
 

docs/admin/system_admin/tuning/tuning-user-sessions-performance.rst

@@ -1,67 +1,67 b''
 .. _user-session-ref:
 
 User Session Performance
 ------------------------
 
 The default file-based sessions are only suitable for smaller setups, or
 instances that doesn't have a lot of users or traffic.
 They are set as default option because it's setup-free solution.
 
 The most common issue of file based sessions are file limit errors which occur
 if there are lots of session files.
 
 Therefore, in a large scale deployment, to give better performance,
 scalability, and maintainability we recommend switching from file-based
 sessions to database-based user sessions or Redis based sessions.
 
 To switch to database-based user sessions uncomment the following section in
-your :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file.
+your :file:`config/_shared/rhodecode.ini` file.
 
 
 .. code-block:: ini
 
       ## db based session, fast, and allows easy management over logged in users
       beaker.session.type = ext:database
       beaker.session.table_name = db_session
 
       # use just one of the following according to the type of database
       beaker.session.sa.url = postgresql://postgres:secret@localhost/rhodecode
       # or
       beaker.session.sa.url = mysql://root:secret@127.0.0.1/rhodecode
 
       beaker.session.sa.pool_recycle = 3600
       beaker.session.sa.echo = false
 
 
 and make sure you comment out the file based sessions.
 
 .. code-block:: ini
 
       ## types are file, ext:memcached, ext:database, and memory (default).
       #beaker.session.type = file
       #beaker.session.data_dir = %(here)s/data/sessions/data
 
 
 The `table_name` will be automatically created on specified database if it isn't yet existing.
 Database specified in the `beaker.session.sa.url` can be the same that RhodeCode
 uses, or if required it can be a different one. We recommend to use the same database.
 
 
 
 To switch to redis-based user sessions uncomment the following section in
-your :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file.
+your :file:`config/_shared/rhodecode.ini` file.
 
 .. code-block:: ini
 
       ## redis sessions
       beaker.session.type = ext:redis
       beaker.session.url = localhost:6379
 
 
 and make sure you comment out the file based sessions.
 
 .. code-block:: ini
 
       ## types are file, ext:memcached, ext:database, and memory (default).
       #beaker.session.type = file
       #beaker.session.data_dir = %(here)s/data/sessions/data
  No newline at end of file

docs/admin/system_admin/vcs-server.rst

@@ -1,379 +1,379 b''
 .. _vcs-server:
 
 VCS Server Management
 ---------------------
 
 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 |RCE| instance.
 * One VCS Server handling multiple instances.
 
 .. important::
 
    If your server locale settings are not correctly configured,
    |RCE| and the VCS Server can run into issues. See this `Ask Ubuntu`_ post
    which explains the problem and gives a solution.
 
 For more information, see the following sections:
 
 * :ref:`install-vcs`
 * :ref:`config-vcs`
 * :ref:`vcs-server-options`
 * :ref:`vcs-server-versions`
 * :ref:`vcs-server-maintain`
 * :ref:`vcs-server-config-file`
 * :ref:`svn-http`
 
 .. _install-vcs:
 
 VCS Server Installation
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 To install a VCS Server, see
 :ref:`Installing a VCS server <control:install-vcsserver>`.
 
 .. _config-vcs:
 
 Hooking |RCE| to its VCS Server
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To configure a |RCE| instance to use a VCS server, see
 :ref:`Configuring the VCS Server connection <control:manually-vcsserver-ini>`.
 
 .. _vcs-server-options:
 
 |RCE| VCS Server Options
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 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.
+:file:`config/_shared/rhodecode.ini` file.
 
 .. rst-class:: dl-horizontal
 
     \vcs.backends <available-vcs-systems>
         Set a comma-separated list of the |repo| options available from the
         web interface. The default is ``hg, git, svn``,
         which is all |repo| types available. The order of backends is also the
         order backend will try to detect requests type.
 
     \vcs.connection_timeout <seconds>
         Set the length of time in seconds that the VCS Server waits for
         requests to process. After the timeout expires,
         the request is closed. The default is ``3600``. Set to a higher
         number if you experience network latency, or timeout issues with very
         large push/pull requests.
 
     \vcs.server.enable <boolean>
         Enable or disable the VCS Server. The available options are ``true`` or
         ``false``. The default is ``true``.
 
     \vcs.server <host:port>
         Set the host, either hostname or IP Address, and port of the VCS server
         you wish to run with your |RCE| instance.
 
 .. code-block:: ini
 
     ##################
     ### VCS CONFIG ###
     ##################
     # set this line to match your VCS Server
     vcs.server = 127.0.0.1:10004
     # Set to False to disable the VCS Server
     vcs.server.enable = True
     vcs.backends = hg, git, svn
     vcs.connection_timeout = 3600
 
 
 .. _vcs-server-versions:
 
 VCS Server Versions
 ^^^^^^^^^^^^^^^^^^^
 
 An updated version of the VCS Server is released with each |RCE| version. Use
 the VCS Server number that matches with the |RCE| version to pair the
 appropriate ones together. For |RCE| versions pre 3.3.0,
 VCS Server 1.X.Y works with |RCE| 3.X.Y, for example:
 
 * VCS Server 1.0.0 works with |RCE| 3.0.0
 * VCS Server 1.2.2 works with |RCE| 3.2.2
 
 For |RCE| versions post 3.3.0, the VCS Server and |RCE| version numbers
 match, for example:
 
 * VCS Server |release| works with |RCE| |release|
 
 .. _vcs-server-maintain:
 
 VCS Server Cache Optimization
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 To optimize the VCS server to manage the cache and memory usage efficiently, it's recommended to
 configure the Redis backend for VCSServer caches.
 Once configured, restart the VCS Server.
 
 Make sure Redis is installed and running.
 Open :file:`/home/{user}/.rccontrol/{vcsserver-id}/vcsserver.ini`
 file and ensure the below settings for `repo_object` type cache are set:
 
 .. code-block:: ini
 
     ; ensure the default file based cache is *commented out*
     ##rc_cache.repo_object.backend = dogpile.cache.rc.file_namespace
     ##rc_cache.repo_object.expiration_time = 2592000
 
     ; `repo_object` cache settings for vcs methods for repositories
     rc_cache.repo_object.backend = dogpile.cache.rc.redis_msgpack
 
     ; cache auto-expires after N seconds
     ; Examples: 86400 (1Day), 604800 (7Days), 1209600 (14Days), 2592000 (30days), 7776000 (90Days)
     rc_cache.repo_object.expiration_time = 2592000
 
     ; redis_expiration_time needs to be greater then expiration_time
     rc_cache.repo_object.arguments.redis_expiration_time = 3592000
 
     rc_cache.repo_object.arguments.host = localhost
     rc_cache.repo_object.arguments.port = 6379
     rc_cache.repo_object.arguments.db = 5
     rc_cache.repo_object.arguments.socket_timeout = 30
     ; more Redis options: https://dogpilecache.sqlalchemy.org/en/latest/api.html#redis-backends
     rc_cache.repo_object.arguments.distributed_lock = true
 
 
 To clear the cache completely, you can restart the VCS Server.
 
 .. important::
 
    While the VCS Server handles a restart gracefully on the web interface,
    it will drop connections during push/pull requests. So it is recommended
    you only perform this when there is very little traffic on the instance.
 
 Use the following example to restart your VCS Server,
 for full details see the :ref:`RhodeCode Control CLI <control:rcc-cli>`.
 
 .. code-block:: bash
 
     $ rccontrol status
 
 .. code-block:: vim
 
     - NAME: vcsserver-1
     - STATUS: RUNNING
       logs:/home/ubuntu/.rccontrol/vcsserver-1/vcsserver.log
     - VERSION: 4.7.2 VCSServer
     - URL: http://127.0.0.1:10008
     - CONFIG: /home/ubuntu/.rccontrol/vcsserver-1/vcsserver.ini
 
     $ rccontrol restart vcsserver-1
     Instance "vcsserver-1" successfully stopped.
     Instance "vcsserver-1" successfully started.
 
 .. _vcs-server-config-file:
 
 VCS Server Configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 You can configure settings for multiple VCS Servers on your
 system using their individual configuration files. Use the following
 properties inside the configuration file to set up your system. The default
 location is :file:`home/{user}/.rccontrol/{vcsserver-id}/vcsserver.ini`.
 For a more detailed explanation of the logger levers, see :ref:`debug-mode`.
 
 .. rst-class:: dl-horizontal
 
     \host <ip-address>
         Set the host on which the VCS Server will run. VCSServer is not
         protected by any authentication, so we *highly* recommend running it
         under localhost ip that is `127.0.0.1`
 
     \port <int>
         Set the port number on which the VCS Server will be available.
 
 
 .. note::
 
    After making changes, you need to restart your VCS Server to pick them up.
 
 .. code-block:: ini
 
     ; #################################
     ; RHODECODE VCSSERVER CONFIGURATION
     ; #################################
 
     [server:main]
     ; COMMON HOST/IP CONFIG
     host = 127.0.0.1
     port = 10002
 
     ; ###########################
     ; GUNICORN APPLICATION SERVER
     ; ###########################
 
     ; run with gunicorn --log-config rhodecode.ini --paste rhodecode.ini
 
     ; Module to use, this setting shouldn't be changed
     use = egg:gunicorn#main
 
     ; Sets the number of process workers. More workers means more concurrent connections
     ; RhodeCode can handle at the same time. Each additional worker also it increases
     ; memory usage as each has it's own set of caches.
     ; Recommended value is (2 * NUMBER_OF_CPUS + 1), eg 2CPU = 5 workers, but no more
     ; than 8-10 unless for really big deployments .e.g 700-1000 users.
     ; `instance_id = *` must be set in the [app:main] section below (which is the default)
     ; when using more than 1 worker.
     workers = 6
 
     ; Gunicorn access log level
     loglevel = info
 
     ; Process name visible in process list
     proc_name = rhodecode_vcsserver
 
     ; Type of worker class, one of sync, gevent
     ; currently `sync` is the only option allowed.
     worker_class = sync
 
     ; The maximum number of simultaneous clients. Valid only for gevent
     worker_connections = 10
 
     ; Max number of requests that worker will handle before being gracefully restarted.
     ; Prevents memory leaks, jitter adds variability so not all workers are restarted at once.
     max_requests = 1000
     max_requests_jitter = 30
 
     ; Amount of time a worker can spend with handling a request before it
     ; gets killed and restarted. By default set to 21600 (6hrs)
     ; Examples: 1800 (30min), 3600 (1hr), 7200 (2hr), 43200 (12h)
     timeout = 21600
 
     ; The maximum size of HTTP request line in bytes.
     ; 0 for unlimited
     limit_request_line = 0
 
     ; Limit the number of HTTP headers fields in a request.
     ; By default this value is 100 and can't be larger than 32768.
     limit_request_fields = 32768
 
     ; Limit the allowed size of an HTTP request header field.
     ; Value is a positive number or 0.
     ; Setting it to 0 will allow unlimited header field sizes.
     limit_request_field_size = 0
 
     ; Timeout for graceful workers restart.
     ; After receiving a restart signal, workers have this much time to finish
     ; serving requests. Workers still alive after the timeout (starting from the
     ; receipt of the restart signal) are force killed.
     ; Examples: 1800 (30min), 3600 (1hr), 7200 (2hr), 43200 (12h)
     graceful_timeout = 3600
 
     # The number of seconds to wait for requests on a Keep-Alive connection.
     # Generally set in the 1-5 seconds range.
     keepalive = 2
 
     ; Maximum memory usage that each worker can use before it will receive a
     ; graceful restart signal 0 = memory monitoring is disabled
     ; Examples: 268435456 (256MB), 536870912 (512MB)
     ; 1073741824 (1GB), 2147483648 (2GB), 4294967296 (4GB)
     memory_max_usage = 1073741824
 
     ; How often in seconds to check for memory usage for each gunicorn worker
     memory_usage_check_interval = 60
 
     ; Threshold value for which we don't recycle worker if GarbageCollection
     ; frees up enough resources. Before each restart we try to run GC on worker
     ; in case we get enough free memory after that, restart will not happen.
     memory_usage_recovery_threshold = 0.8
 
 
     [app:main]
     use = egg:rhodecode-vcsserver
 
     pyramid.default_locale_name = en
     pyramid.includes =
 
     ; default locale used by VCS systems
     locale = en_US.UTF-8
 
     ; #############
     ; DOGPILE CACHE
     ; #############
 
     ; Default cache dir for caches. Putting this into a ramdisk can boost performance.
     ; eg. /tmpfs/data_ramdisk, however this directory might require large amount of space
     cache_dir = %(here)s/data
 
     ; **********************************************************
     ; `repo_object` cache with redis backend
     ; recommended for larger instance, or for better performance
     ; **********************************************************
 
     ; `repo_object` cache settings for vcs methods for repositories
     rc_cache.repo_object.backend = dogpile.cache.rc.redis_msgpack
 
     ; cache auto-expires after N seconds
     ; Examples: 86400 (1Day), 604800 (7Days), 1209600 (14Days), 2592000 (30days), 7776000 (90Days)
     rc_cache.repo_object.expiration_time = 2592000
 
     ; redis_expiration_time needs to be greater then expiration_time
     rc_cache.repo_object.arguments.redis_expiration_time = 3592000
 
     rc_cache.repo_object.arguments.host = localhost
     rc_cache.repo_object.arguments.port = 6379
     rc_cache.repo_object.arguments.db = 5
     rc_cache.repo_object.arguments.socket_timeout = 30
     ; more Redis options: https://dogpilecache.sqlalchemy.org/en/latest/api.html#redis-backends
     rc_cache.repo_object.arguments.distributed_lock = true
 
     ; #####################
     ; LOGGING CONFIGURATION
     ; #####################
     [loggers]
     keys = root, vcsserver
 
     [handlers]
     keys = console
 
     [formatters]
     keys = generic
 
     ; #######
     ; LOGGERS
     ; #######
     [logger_root]
     level = NOTSET
     handlers = console
 
     [logger_vcsserver]
     level = DEBUG
     handlers =
     qualname = vcsserver
     propagate = 1
 
 
     ; ########
     ; HANDLERS
     ; ########
 
     [handler_console]
     class = StreamHandler
     args = (sys.stderr, )
     level = INFO
     formatter = generic
 
     ; ##########
     ; FORMATTERS
     ; ##########
 
     [formatter_generic]
     format = %(asctime)s.%(msecs)03d [%(process)d] %(levelname)-5.5s [%(name)s] %(message)s
     datefmt = %Y-%m-%d %H:%M:%S
 
 
 .. _Subversion Red Book: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svn
 
 .. _Ask Ubuntu: http://askubuntu.com/questions/162391/how-do-i-fix-my-locale-issue

docs/api/api.rst

@@ -1,209 +1,209 b''
 .. _api:
 
 API Documentation
 =================
 
 The |RCE| API uses a single scheme for calling all API methods. The API is
 implemented with JSON protocol in both directions. To send API requests to
 your instance of |RCE|, use the following URL format
 ``<your_server>/_admin``
 
 .. note::
 
    To use the API, you should configure the :file:`~/.rhoderc` file with
    access details per instance. For more information, see
    :ref:`config-rhoderc`.
 
 
 API ACCESS FOR WEB VIEWS
 ------------------------
 
 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 |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 |RCE| configuration ``.ini`` file. The default location is:
 
 * |RCE| Pre-2.2.7 :file:`root/rhodecode/data/production.ini`
-* |RCE| 3.0 :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+* |RCE| 3.0 :file:`config/_shared/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
 archive.
 
 .. code-block:: ini
 
     ## List of controllers (using glob syntax) that AUTH TOKENS could be used for access.
     ## Adding ?auth_token = <token> to the url authenticates this request as if it
     ## came from the the logged in user who own this authentication token.
     ##
     ## Syntax is <ControllerClass>:<function_pattern>.
     ## The list should be "," separated and on a single line.
     ##
     api_access_controllers_whitelist = RepoCommitsView:repo_commit_raw,RepoCommitsView:repo_commit_patch,RepoCommitsView:repo_commit_download
 
 After this change, a |RCE| view can be accessed without login by adding a
 GET parameter ``?auth_token=<auth_token>`` to a url. For example to
 access the raw diff.
 
 .. code-block:: html
 
    http://<server>/<repo>/changeset-diff/<sha>?auth_token=<auth_token>
 
 By default this is only enabled on RSS/ATOM feed views. Exposing raw diffs is a
 good way to integrate with 3rd party services like code review, or build farms
 that could download archives.
 
 API ACCESS
 ----------
 
 All clients are required to send JSON-RPC spec JSON data.
 
 .. code-block:: bash
 
     {
         "id:"<id>",
         "auth_token":"<auth_token>",
         "method":"<method_name>",
         "args":{"<arg_key>":"<arg_val>"}
     }
 
 Example call for auto pulling from remote repositories using curl:
 
 .. code-block:: bash
 
     curl https://server.com/_admin/api -X POST -H 'content-type:text/plain' --data-binary '{"id":1,
     "auth_token":"xe7cdb2v278e4evbdf5vs04v832v0efvcbcve4a3","method":"pull", "args":{"repoid":"CPython"}}'
 
 Provide those parameters:
  - **id** A value of any type, which is used to match the response with the
    request that it is replying to.
  - **auth_token** for access and permission validation.
  - **method** is name of method to call
  - **args** is an ``key:value`` list of arguments to pass to method
 
 .. note::
 
     To get your |authtoken|, from the |RCE| interface,
     go to:
     :menuselection:`username --> My account --> Auth tokens`
 
     For security reasons you should always create a dedicated |authtoken| for
     API use only.
 
 
 The |RCE| API will always return a JSON-RPC response:
 
 .. code-block:: bash
 
     {
         "id": <id>, # matching id sent by request
         "result": "<result>"|null, # JSON formatted result, null if any errors
         "error": "null"|<error_message> # JSON formatted error (if any)
     }
 
 All responses from API will be with `HTTP/1.0 200 OK` status code.
 If there is an error when calling the API, the *error* key will contain a
 failure description and the *result* will be `null`.
 
 API CLIENT
 ----------
 
 To install the |RCE| API, see :ref:`install-tools`. To configure the API per
 instance, see the :ref:`rc-tools` section as you need to configure a
 :file:`~/.rhoderc` file with your |authtokens|.
 
 Once you have set up your instance API access, use the following examples to
 get started.
 
 .. code-block:: bash
 
     # Getting the 'rhodecode' repository
     # from a RhodeCode Enterprise instance
     rhodecode-api --instance-name=enterprise-1 get_repo repoid:rhodecode
 
     Calling method get_repo => http://127.0.0.1:5000
     Server response
     {
         <json data>
     }
 
     # Creating a new mercurial repository called 'brand-new'
     # with a description 'Repo-description'
     rhodecode-api --instance-name=enterprise-1 create_repo repo_name:brand-new repo_type:hg description:Repo-description
     {
       "error": null,
       "id": 1110,
       "result": {
         "msg": "Created new repository `brand-new`",
         "success": true,
         "task": null
       }
     }
 
 A broken example, what not to do.
 
 .. code-block:: bash
 
     # A call missing the required arguments
     # and not specifying the instance
     rhodecode-api get_repo
 
     Calling method get_repo => http://127.0.0.1:5000
     Server response
     "Missing non optional `repoid` arg in JSON DATA"
 
 You can specify pure JSON using the ``--format`` parameter.
 
 .. code-block:: bash
 
     rhodecode-api --format=json get_repo repoid:rhodecode
 
 In such case only output that this function shows is pure JSON, we can use that
 and pipe output to some json formatter.
 
 If output is in pure JSON format, you can pipe output to a JSON formatter.
 
 .. code-block:: bash
 
     rhodecode-api --instance-name=enterprise-1 --format=json get_repo repoid:rhodecode | python -m json.tool
 
 API METHODS
 -----------
 
 Each method by default required following arguments.
 
 .. code-block:: bash
 
     id :      "<id_for_response>"
     auth_token : "<auth_token>"
     method :  "<method name>"
     args :    {}
 
 Use each **param** from docs and put it in args, Optional parameters
 are not required in args.
 
 .. code-block:: bash
 
     args: {"repoid": "rhodecode"}
 
 .. Note: From this point on things are generated by the script in
    `scripts/fabfile.py`. To change things below, update the docstrings in the
    ApiController.
 
 .. --- API DEFS MARKER ---
 .. toctree::
 
    methods/repo-methods
    methods/store-methods
    methods/license-methods
    methods/deprecated-methods
    methods/gist-methods
    methods/pull-request-methods
    methods/repo-group-methods
    methods/search-methods
    methods/server-methods
    methods/user-methods
    methods/user-group-methods

docs/auth/ssh-connection.rst

@@ -1,144 +1,144 b''
 .. _ssh-connection:
 
 SSH Connection
 --------------
 
 If you wish to connect to your |repos| using SSH protocol, use the
 following instructions.
 
 1. Include |RCE| generated `authorized_keys` file into your sshd_config.
 
    By default a file `authorized_keys_rhodecode` is created containing
    configuration and all allowed user connection keys are stored inside.
    On each change of stored keys inside |RCE| this file is updated with
    proper data.
 
    .. code-block:: bash
 
        # Edit sshd_config file most likely at /etc/ssh/sshd_config
        # add or edit the AuthorizedKeysFile, and set to use custom files
 
        AuthorizedKeysFile %h/.ssh/authorized_keys %h/.ssh/authorized_keys_rhodecode
 
    This way we use a separate file for SSH access and separate one for
    SSH access to |RCE| repositories.
 
 
 2. Enable the SSH module on instance.
 
    On the server where |RCE| is running executing:
 
    .. code-block:: bash
 
        rccontrol enable-module ssh {instance-id}
 
    This will add the following configuration into :file:`rhodecode.ini`.
    This also can be done manually:
 
    .. code-block:: ini
 
         ############################################################
         ### SSH Support Settings                                 ###
         ############################################################
 
         ## Defines if a custom authorized_keys file should be created and written on
         ## any change user ssh keys. Setting this to false also disables posibility
         ## of adding SSH keys by users from web interface. Super admins can still
         ## manage SSH Keys.
         ssh.generate_authorized_keyfile = true
 
         ## Options for ssh, default is `no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding`
         # ssh.authorized_keys_ssh_opts =
 
         ## Path to the authrozied_keys file where the generate entries are placed.
         ## It is possible to have multiple key files specified in `sshd_config` e.g.
         ## AuthorizedKeysFile %h/.ssh/authorized_keys %h/.ssh/authorized_keys_rhodecode
         ssh.authorized_keys_file_path = ~/.ssh/authorized_keys_rhodecode
 
         ## Command to execute the SSH wrapper. The binary is available in the
         ## rhodecode installation directory.
         ## e.g ~/.rccontrol/community-1/profile/bin/rc-ssh-wrapper
         ssh.wrapper_cmd = ~/.rccontrol/community-1/rc-ssh-wrapper
 
         ## Allow shell when executing the ssh-wrapper command
         ssh.wrapper_cmd_allow_shell = false
 
         ## Enables logging, and detailed output send back to the client during SSH
         ## operations. Useful for debugging, shouldn't be used in production.
         ssh.enable_debug_logging = false
 
         ## Paths to binary executable, by default they are the names, but we can
         ## override them if we want to use a custom one
         ssh.executable.hg = ~/.rccontrol/vcsserver-1/profile/bin/hg
         ssh.executable.git = ~/.rccontrol/vcsserver-1/profile/bin/git
         ssh.executable.svn = ~/.rccontrol/vcsserver-1/profile/bin/svnserve
 
         ## Enables SSH key generator web interface. Disabling this still allows users
         ## to add their own keys.
         ssh.enable_ui_key_generator = true
 
 
 3. Set base_url for instance to enable proper event handling (Optional):
 
    If you wish to have integrations working correctly via SSH please configure
    The Application base_url.
 
    Use the ``rccontrol status`` command to view instance details.
    Hostname is required for the integration to properly set the instance URL.
 
    When your hostname is known (e.g https://code.rhodecode.com) please set it
-   inside :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+   inside :file:`config/_shared/rhodecode.ini`
 
    add into `[app:main]` section the following configuration:
 
    .. code-block:: ini
 
        app.base_url = https://code.rhodecode.com
 
 
 4. Add the public key to your user account for testing.
    First generate a new key, or use your existing one and have your public key
    at hand.
 
    Go to
    :menuselection:`My Account --> SSH Keys` and add the public key with proper description.
 
    This will generate a new entry inside our configured `authorized_keys_rhodecode` file.
 
    Test the connection from your local machine using the following example:
 
    .. note::
 
        In case of connection problems please set
        `ssh.enable_debug_logging = true` inside the SSH configuration of
-       :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+       :file:`config/_shared/rhodecode.ini`
        Then add, remove your SSH key and try connecting again.
        Debug logging will be printed to help find the problems on the server side.
 
    Test connection using the ssh command from the local machine. Make sure
    to use the use who is running the |RCE| server, and not your username from
    the web interface.
 
 
    For SVN:
 
    .. code-block:: bash
 
        SVN_SSH="ssh -i ~/.ssh/id_rsa_test_ssh_private.key" svn checkout svn+ssh://rhodecode@rc-server/repo_name
 
    For GIT:
 
    .. code-block:: bash
 
        GIT_SSH_COMMAND='ssh -i ~/.ssh/id_rsa_test_ssh_private.key' git clone ssh://rhodecode@rc-server/repo_name
 
    For Mercurial:
 
    .. code-block:: bash
 
        Add to hgrc:
 
        [ui]
        ssh = ssh -C -i ~/.ssh/id_rsa_test_ssh_private.key
 
        hg clone ssh://rhodecode@rc-server/repo_name

docs/install/setup-email.rst

@@ -1,45 +1,45 b''
 .. _set-up-mail:
 
 Set up Email
 ------------
 
 To setup email with your |RCE| instance, open the default
-:file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini`
+:file:`config/_shared/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 |RCE| instance on the
 :menuselection:`Admin --> Settings --> Email` page.
 
 Please be aware that both section should be changed the `[DEFAULT]` for main applications
 email config, and `[server:main]` for exception tracking email
 
 .. code-block:: ini
 
     [DEFAULT]
     ; ########################################################################
     ; EMAIL CONFIGURATION
     ; These settings will be used by the RhodeCode mailing system
     ; ########################################################################
 
     ; prefix all emails subjects with given prefix, helps filtering out emails
     #email_prefix = [RhodeCode]
 
     ; email FROM address all mails will be sent
     #app_email_from = rhodecode-noreply@localhost
 
     #smtp_server = mail.server.com
     #smtp_username =
     #smtp_password =
     #smtp_port =
     #smtp_use_tls = false
     #smtp_use_ssl = true
 
     [server:main]
     ; Send email with exception details when it happens
     #exception_tracker.send_email = true
 
     ; Comma separated list of recipients for exception emails,
     ; e.g [e-mail],[e-mail]
     ; Can be left empty, then emails will be sent to ALL super-admins
     #exception_tracker.send_email_recipients =

docs/tutorials/multi-instance-setup.rst

@@ -1,91 +1,91 b''
 .. _multi-instance-setup:
 
 Scaling |RCE| Using Multiple Instances
 ======================================
 
 Running multiple instances of |RCE| from a single database can be used to
 scale the application for the following deployment setups:
 
 * Using dedicated Continuous Integrations instances.
 * Locating instances closer to geographically dispersed development teams.
 * Running production and testing instances, or failover instances on a
   different server.
 * Running proxy read-only instances for pull operations.
 
 If you wish to run multiple instances of |RCE| using a single database for
 settings, use the following instructions to set this up. Before you get onto
 multiple instances though, you should install |RCE|, and set
 up your first instance as you see fit. You can see the full instructions here
 :ref:`Installing RhodeCode Enterprise <control:rcc>`
 
 Once you have configured your first instance, you can run additional instances
 from the same database using the following steps:
 
 1. Install a new instance of |RCE|, choosing SQLite as the database. It is
    important to choose SQLite, because this will not overwrite any other
    database settings you may have.
 
    Once the new instance is installed you need to update the licence token and
    database connection string in the
-   :file:`/home/{user}/.rccontrol/{instance-id}/rhodecode.ini` file.
+   :file:`config/_shared/rhodecode.ini` file.
 
 .. code-block:: bash
 
    $ rccontrol install Enterprise
 
     Agree to the licence agreement? [y/N]: y
     Username [admin]: username
     Password (min 6 chars):
     Repeat for confirmation:
     Email: [e-mail]
     Respositories location [/home/brian/repos]:
     IP to start the Enterprise server on [127.0.0.1]:
     Port for the Enterprise server to use [10000]:
     Database type - [s]qlite, [m]ysql, [p]ostresql: s
 
 2. The licence token used on each new instance needs to be the token from your
    initial instance. This allows multiple instances to run the same licence key.
 
    To get the licence token, go to the |RCE| interface of your primary
    instance and select :menuselection:`admin --> setting --> license`. Then
    update the licence token setting in each new instance's
    :file:`rhodecode.ini` file.
 
 .. code-block:: ini
 
     ## generated license token, goto license page in RhodeCode settings to get
     ## new token
     license_token = add-token-here
 
 3. Update the database connection string in the
    :file:`rhodecode.ini` file to point to your database. For
    more information, see :ref:`config-database`.
 
 .. code-block:: ini
 
     #########################################################
     ### DB CONFIGS - EACH DB WILL HAVE IT'S OWN CONFIG    ###
     #########################################################
 
     # Default SQLite config
     sqlalchemy.db1.url = sqlite:////home/user/.rccontrol/enterprise-1/rhodecode.db
 
     # Use this example for a PostgreSQL
     sqlalchemy.db1.url = postgresql://username:password@localhost/rhodecode
 
 4. Restart your updated instance. Once restarted the new instance will read
    the licence key in the database and will function identically as the
    original instance.
 
 .. code-block:: bash
 
    $ rccontrol restart enterprise-2
 
 If you wish to add additional performance to your setup, see the
 :ref:`rhodecode-tuning-ref` section.
 
 Scaling Deployment Diagram
 --------------------------
 
 .. image:: ../images/scaling-diagrm.png
    :align: center