summaryrefslogtreecommitdiff
path: root/src/leap/soledad/server/_config.py
AgeCommit message (Collapse)Author
2017-11-19[feature] allow setting couchdb url from environmentdrebs
2017-10-12[feature] make concurrent blob writes configurabledrebs
2017-09-14[pkg] standardize location of services tokens filedrebs
Introduction of local services authentication added a configuration file containing the auth tokens for each service. There were different names for that file, and this commit standardizes all of them to the same value: /etc/soledad/services.tokens
2017-09-14[pkg] use /var/lib/soledad/blobs to store blobsdrebs
Soledad Server was previously using something in /srv to store blobs in the server side. Debian/lintian doesn't like that at all, so we are changing to /var/lib/soledad/blobs. Closes: #8948
2017-09-05[doc] document environment variablesdrebs
2017-09-05[style] improve naming and fixes from code reviewVictor Shyba
-- Related: #8867
2017-09-05[feature] new config option for tokens auth fileVictor Shyba
-- Related: #8867
2017-08-31[feat] get config file name from environmentdrebs
For tests, we may want to configure the server with non-default options, and the easiest way to do this is by creating a configuration file in a temporary directory and passing the file name by means of an environment variable. This commit changes the server config file loading scheme to account for a variable called SOLEDAD_SERVER_CONFIG_FILE. If that variable is set, the configuration is read from the file pointed by it. Otherwise, /etc/soledad/soledad-server.conf is used.
2017-08-23[bug] revert setting of default config that enabled blobs prematurelyKali Kaneko
We do not want to enable blobs on any server that, by mistake, deploys from master or from a released version in the 0.10.x series. for testing it's more sensible to allow instantiating the server with a custom config file.
2017-08-23[test] use sensible server default config for testingdrebs
2017-06-24[pkg] unify client and server into a single python packagedrebs
We have been discussing about this merge for a while. Its main goal is to simplify things: code navigation, but also packaging. The rationale is that the code is more cohesive in this way, and there's only one source package to install. Dependencies that are only for the server or the client will not be installed by default, and they are expected to be provided by the environment. There are setuptools extras defined for the client and the server. Debianization is still expected to split the single source package into 3 binaries. Another avantage is that the documentation can now install a single package with a single step, and therefore include the docstrings into the generated docs. - Resolves: #8896