Conan Server

Important

This server is mainly used for testing (though it might work fine for small teams). We recommend using the free Artifactory Community Edition for C/C++ for private development or Artifactory Pro as Enterprise solution.

Configuration

By default your server configuration is saved under ~/.conan_server/server.conf, however you can modify this behaviour by either setting the CONAN_SERVER_HOME environment variable or launching the server with -d or --server_dir command line argument followed by desired path. In case you use one of the options your configuration file will be stored under server_directory/server.conf Please note that command line argument will override the environment variable. You can change configuration values in server.conf, prior to launching the server. Note that the server does not support hot-reload, and thus in order to see configuration changes you will have to manually relaunch the server.

The server configuration file is by default:

  1. [server]
  2. jwt_secret: IJKhyoioUINMXCRTytrR
  3. jwt_expire_minutes: 120
  5. ssl_enabled: False
  6. port: 9300
  8. public_port:
  9. host_name: localhost
  11. authorize_timeout: 1800
  13. disk_storage_path: ./data
  14. disk_authorize_timeout: 1800
  15. updown_secret: HJhjujkjkjkJKLUYyuuyHJ
  17. [write_permissions]
  18. # "opencv/2.3.4@lasote/testing": default_user,default_user2
  20. [read_permissions]
  21. */*@*/*: *
  23. [users]
  24. demo: demo

Server Parameters

Note

The Conan server supports relative URLs, allowing you to avoid setting host_name, public_port and ssl_enabled. The URLs used to upload/download packages will be automatically generated in the client following the URL of the remote. This allows accessing the Conan server from different networks.

  • port: Port where conan_server will run.

  • The client server authorization is done with JWT. jwt_secret is a random string used to generate authentication tokens. You can change it safely anytime (in fact it is a good practice). The change will just force users to log in again. jwt_expire_minutes is the amount of time that users remain logged-in within the client without having to introduce their credentials again.

  • host_name: If you set host_name, you must use the machine’s IP where you are running your server (or domain name), something like host_name: 192.168.1.100. This IP (or domain name) has to be visible (and resolved) by the Conan client, so take it into account if your server has multiple network interfaces.

  • public_port: Might be needed when running virtualized, Docker or any other kind of port redirection. File uploads/downloads are served with their own URLs, generated by the system, so the file storage backend is independent. Those URLs need the public port they have to communicate from the outside. If you leave it blank, the port value is used.

    Example: Use conan_server in a Docker container that internally runs in the 9300 port but exposes the 9999 port (where the clients will connect to):

    1. docker run ... -p9999:9300 ... # Check Docker docs for that

    server.conf

    1. [server]
    3. ssl_enabled: False
    4. port: 9300
    5. public_port: 9999
    6. host_name: localhost

  • ssl_enabled Conan doesn’t handle the SSL traffic by itself, but you can use a proxy like Nginx to redirect the SSL traffic to your Conan server. If your Conan clients are connecting with “https”, set ssl_enabled to True. This way the conan_server will generate the upload/download urls with “https” instead of “http”.

Note

Important: The Conan client, by default, will validate the server SSL certificates and won’t connect if it’s invalid. If you have self signed certificates you have two options:

  1. Use the conan remote command to disable the SSL certificate checks. E.g., conan remote add/update myremote https://somedir False

  2. If using the core.net.http:cacert_path configuration in the Conan client, append the server .crt file contents to the cacert.pem location.

The folder in which the uploaded packages are stored (i.e., the folder you would want to backup) is defined in the disk_storage_path. The storage backend might use a different channel, and uploads/downloads are authorized up to a maximum of authorize_timeout seconds. The value should sufficient so that large downloads/uploads are not rejected, but not too big to prevent hanging up the file transfers. The value disk_authorize_timeout is not currently used. File transfers are authorized with their own tokens, generated with the secret updown_secret. This value should be different from the above jwt_secret.

Permissions Parameters

By default, the server configuration when set to Read can be done anonymous, but uploading requires you to be registered users. Users can easily be registered in the [users] section, by defining a pair of login: password for each one. Plain text passwords are used at the moment, but as the server is on-premises (behind firewall), you just need to trust your sysadmin :)

If you want to restrict read/write access to specific packages, configure the [read_permissions] and [write_permissions] sections. These sections specify the sequence of patterns and authorized users, in the form:

  1. # use a comma-separated, no-spaces list of users
  2. package/version@user/channel: allowed_user1,allowed_user2

E.g.:

  1. */*@*/*: * # allow all users to all packages
  2. PackageA/*@*/*: john,peter # allow john and peter access to any PackageA
  3. */*@project/*: john # Allow john to access any package from the "project" user

The rules are evaluated in order. If the left side of the pattern matches, the rule is applied and it will not continue searching for matches.

Authentication

By default, Conan provides a simple user: password users list in the server.conf file.

There is also a plugin mechanism for setting other authentication methods. The process to install any of them is a simple two-step process:

  1. Copy the authenticator source file into the .conan_server/plugins/authenticator folder.

  2. Add custom_authenticator: authenticator_name to the server.conf [server] section.

This is a list of available authenticators, visit their URLs to retrieve them, but also to report issues and collaborate:

Create Your Own Custom Authenticator

If you want to create your own Authenticator, create a Python module in ~/.conan_server/plugins/authenticator/my_authenticator.py

Example:

  1. def get_class():
  2.     return MyAuthenticator()
  5. class MyAuthenticator(object):
  6.     def valid_user(self, username, plain_password):
  7.         return username == "foo" and plain_password == "bar"

The module has to implement:

  • A factory function get_class() that returns a class with a valid_user() method instance.

  • The class containing the valid_user() that has to return True if the user and password are valid or False otherwise.

Authorizations

By default, Conan uses the contents of the [read_permissions] and [write_permissions] sections to authorize or reject a request.

A plugin system is also available to customize the authorization mechanism. The installation of such a plugin is a simple two-step process:

  1. Copy the authorizer’s source file into the .conan_server/plugins/authorizer folder.

  2. Add custom_authorizer: authorizer_name to the server.conf [server] section.

Create Your Own Custom Authorizer

If you want to create your own Authorizer, create a Python module in ~/.conan_server/plugins/authorizer/my_authorizer.py

Example:

  1. from conan.internal.errors import AuthenticationException, ForbiddenException
  3. def get_class():
  4.     return MyAuthorizer()
  6. class MyAuthorizer(object):
  7.     def _check_conan(self, username, ref):
  8.         if ref.user == username:
  9.             return
  11.         if username:
  12.             raise ForbiddenException("Permission denied")
  13.         else:
  14.             raise AuthenticationException()
  16.     def _check_package(self, username, pref):
  17.        self._check(username, pref.ref)
  19.     check_read_conan = _check_conan check_write_conan = _check_conan
  20.     check_delete_conan = _check_conan check_read_package = _check_package
  21.     check_write_package = _check_package check_delete_package = _check_package

The module has to implement:

  • A factory function get_class() that returns an instance of a class conforming to the Authorizer’s interface.

  • A class that implements all the methods defined in the Authorizer interface:

    • check_read_conan() is used to decide whether to allow read access to a recipe.

    • check_write_conan() is used to decide whether to allow write access to a recipe.

    • check_delete_conan() is used to decide whether to allow a recipe’s deletion.

    • check_read_package() is used to decide whether to allow read access to a package.

    • check_write_package() is used to decide whether to allow write access to a package.

    • check_delete_package() is used to decide whether to allow a package’s deletion.

The check_*_conan() methods are called with a username and conans.model.ref.ConanFileReference instance as their arguments. Meanwhile the check_*_package() methods are passed a username and conans.model.ref.PackageReference instance as their arguments. These methods should raise an exception, unless the user is allowed to perform the requested action.

Running the Conan Server with SSL using Nginx

server.conf

  1. [server] port: 9300

nginx conf file

  1. server {
  2.     listen 443; server_name myservername.mydomain.com;
  4.     location / {
  5.       proxy_pass http://0.0.0.0:9300;
  6.     } ssl on; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key
  7.     /etc/nginx/ssl/server.key;
  8. }

remote configuration in Conan client

  1. $ conan remote add myremote https://myservername.mydomain.com

Running the Conan Server with SSL using Nginx in a Subdirectory

server.conf

  1. [server] port: 9300

nginx conf file

  1. server {
  3.        listen 443; ssl on; ssl_certificate /usr/local/etc/nginx/ssl/server.crt;
  4.        ssl_certificate_key /usr/local/etc/nginx/ssl/server.key; server_name
  5.        myservername.mydomain.com;
  7.        location /subdir/ {
  8.           proxy_pass http://0.0.0.0:9300/;
  9.        }
  10.   }

remote configuration in Conan client

  1. $ conan remote add myremote https://myservername.mydomain.com/subdir/

Running Conan Server using Apache

You need to install mod_wsgi. If you want to use Conan installed from pip, the conf file should be similar to the following example:

Apache conf file (e.g., /etc/apache2/sites-available/0_conan.conf)

  1. <VirtualHost *:80>
  2.     WSGIScriptAlias /
  3.     /usr/local/lib/python3.6/dist-packages/conans/server/server_launcher.py
  4.     WSGICallableObject app WSGIPassAuthorization On
  6.     <Directory /usr/local/lib/python3.6/dist-packages/conans>
  7.         Require all granted
  8.     </Directory>
  9. </VirtualHost>

If you want to use Conan checked out from source in, for example in /srv/conan, the conf file should be as follows:

Apache conf file (e.g., /etc/apache2/sites-available/0_conan.conf)

  1. <VirtualHost *:80>
  2.     WSGIScriptAlias / /srv/conan/conans/server/server_launcher.py
  3.     WSGICallableObject app WSGIPassAuthorization On
  5.     <Directory /srv/conan/conans>
  6.         Require all granted
  7.     </Directory>
  8. </VirtualHost>

The directive WSGIPassAuthorization On is needed to pass the HTTP basic authentication to Conan.

Also take into account that the server config files are located in the home of the configured Apache user, e.g., var/www/.conan_server, so remember to use that directory to configure your Conan server.

See also