Show More
@@ -1,251 +1,210 b'' | |||
|
1 | 1 | .. _installation: |
|
2 | 2 | |
|
3 | 3 | ========================== |
|
4 | 4 | Installation on Unix/Linux |
|
5 | 5 | ========================== |
|
6 | 6 | |
|
7 | **Kallithea** is written entirely in Python and requires Python version | |
|
7 | **Kallithea** is written entirely in Python_ and requires Python version | |
|
8 | 8 | 2.6 or higher. Python 3.x is currently not supported. |
|
9 | 9 | |
|
10 | 10 | There are several ways to install Kallithea: |
|
11 | 11 | |
|
12 | 12 | - :ref:`installation-source`: The Kallithea development repository is stable |
|
13 | 13 | and can be used in production. In fact, the Kallithea maintainers do |
|
14 | 14 | use it in production. The advantage of installation from source and regularly |
|
15 | 15 | updating it is that you take advantage of the most recent improvements, which |
|
16 | 16 | is particularly useful because Kallithea is evolving rapidly. |
|
17 | 17 | |
|
18 | 18 | - :ref:`installation-virtualenv`: If you prefer to only use released versions |
|
19 | 19 | of Kallithea, the recommended method is to install Kallithea in a virtual |
|
20 | 20 | Python environment using `virtualenv`. The advantages of this method over |
|
21 | 21 | direct installation is that Kallithea and its dependencies are completely |
|
22 | 22 | contained inside the virtualenv (which also means you can have multiple |
|
23 | 23 | installations side by side or remove it entirely by just removing the |
|
24 | 24 | virtualenv directory) and does not require root privileges. |
|
25 | 25 | |
|
26 | 26 | - :ref:`installation-without-virtualenv`: The alternative method of installing |
|
27 | 27 | a Kallithea release is using standard pip. The package will be installed in |
|
28 | 28 | the same location as all other Python packages you have ever installed. As a |
|
29 | 29 | result, removing it is not as straightforward as with a virtualenv, as you'd |
|
30 | 30 | have to remove its dependencies manually and make sure that they not are |
|
31 | 31 | needed by other packages. |
|
32 | 32 | |
|
33 | 33 | .. _installation-source: |
|
34 | 34 | |
|
35 | 35 | Installation from repository source |
|
36 | 36 | ----------------------------------- |
|
37 | 37 | |
|
38 | 38 | To install Kallithea from source in a virtualenv, follow the instructions |
|
39 | 39 | below:: |
|
40 | 40 | |
|
41 | 41 | hg clone https://kallithea-scm.org/repos/kallithea |
|
42 | 42 | cd kallithea |
|
43 | 43 | virtualenv ../kallithea-venv |
|
44 | 44 | source ../kallithea-venv/bin/activate |
|
45 | 45 | python setup.py develop |
|
46 | 46 | |
|
47 | 47 | You can now proceed to :ref:`setup`. |
|
48 | 48 | |
|
49 | 49 | To upgrade, simply update the repository with ``hg pull -u`` and restart the |
|
50 | 50 | server. |
|
51 | 51 | |
|
52 | 52 | .. _installation-virtualenv: |
|
53 | 53 | |
|
54 | 54 | Installing a released version in a virtualenv |
|
55 | 55 | --------------------------------------------- |
|
56 | 56 | |
|
57 | 57 | It is highly recommended to use a separate virtualenv_ for installing Kallithea. |
|
58 | 58 | This way, all libraries required by Kallithea will be installed separately from your |
|
59 | 59 | main Python installation and other applications and things will be less |
|
60 | 60 | problematic when upgrading the system or Kallithea. |
|
61 | 61 | An additional benefit of virtualenv_ is that it doesn't require root privileges. |
|
62 | 62 | |
|
63 | 63 | - Assuming you have installed virtualenv_, create a new virtual environment |
|
64 | 64 | in for example `/srv/kallithea/venv` using the virtualenv command:: |
|
65 | 65 | |
|
66 | 66 | virtualenv /srv/kallithea/venv |
|
67 | 67 | |
|
68 | 68 | .. note:: Older versions of virtualenv required ``--no-site-packages`` to work |
|
69 | 69 | correctly. It should no longer be necessary. |
|
70 | 70 | |
|
71 | 71 | - Activate the virtualenv_ in your current shell session by running:: |
|
72 | 72 | |
|
73 | 73 | source /srv/kallithea/venv/bin/activate |
|
74 | 74 | |
|
75 | 75 | .. note:: You can't use UNIX ``sudo`` to source the ``virtualenv`` script; it |
|
76 | 76 | will "activate" a shell that terminates immediately. It is also perfectly |
|
77 | 77 | acceptable (and desirable) to create a virtualenv as a normal user. |
|
78 | 78 | |
|
79 | 79 | - Make a folder for Kallithea data files, and configuration somewhere on the |
|
80 | 80 | filesystem. For example:: |
|
81 | 81 | |
|
82 | 82 | mkdir /srv/kallithea |
|
83 | 83 | |
|
84 | 84 | - Go into the created directory run this command to install kallithea:: |
|
85 | 85 | |
|
86 | 86 | pip install kallithea |
|
87 | 87 | |
|
88 | 88 | Alternatively, download a .tar.gz from http://pypi.python.org/pypi/Kallithea, |
|
89 | 89 | extract it and run:: |
|
90 | 90 | |
|
91 | 91 | python setup.py install |
|
92 | 92 | |
|
93 | 93 | - This will install Kallithea together with pylons and all other required |
|
94 | 94 | python libraries into the activated virtualenv. |
|
95 | 95 | |
|
96 | 96 | You can now proceed to :ref:`setup`. |
|
97 | 97 | |
|
98 | 98 | .. _installation-without-virtualenv: |
|
99 | 99 | |
|
100 | 100 | Installing a released version without virtualenv |
|
101 | 101 | ------------------------------------------------ |
|
102 | 102 | |
|
103 | 103 | For installation without virtualenv, 'just' use:: |
|
104 | 104 | |
|
105 | 105 | pip install kallithea |
|
106 | 106 | |
|
107 | 107 | Note that this method requires root privileges and will install packages |
|
108 | 108 | globally without using the system's package manager. |
|
109 | 109 | |
|
110 | 110 | To install as a regular user in ``~/.local``, you can use:: |
|
111 | 111 | |
|
112 | 112 | pip install --user kallithea |
|
113 | 113 | |
|
114 | 114 | You can now proceed to :ref:`setup`. |
|
115 | 115 | |
|
116 | Celery (optional) | |
|
117 | ----------------- | |
|
118 | ||
|
119 | In order to gain maximum performance | |
|
120 | there are some third-party you must install. When Kallithea is used | |
|
121 | together with celery you have to install some kind of message broker, | |
|
122 | recommended one is rabbitmq_ to make the async tasks work. | |
|
123 | ||
|
124 | Of course Kallithea works in sync mode also and then you do not have to install | |
|
125 | any third party applications. However, using Celery_ will give you a large | |
|
126 | speed improvement when using many big repositories. If you plan to use | |
|
127 | Kallithea for say 7 to 10 repositories, Kallithea will perform perfectly well | |
|
128 | without celery running. | |
|
129 | ||
|
130 | If you make the decision to run Kallithea with celery make sure you run | |
|
131 | celeryd using paster and message broker together with the application. | |
|
132 | ||
|
133 | .. note:: | |
|
134 | Installing message broker and using celery is optional, Kallithea will | |
|
135 | work perfectly fine without them. | |
|
136 | ||
|
137 | ||
|
138 | **Message Broker** | |
|
139 | ||
|
140 | - preferred is `RabbitMq <http://www.rabbitmq.com/>`_ | |
|
141 | - A possible alternative is `Redis <http://code.google.com/p/redis/>`_ | |
|
142 | ||
|
143 | For installation instructions you can visit: | |
|
144 | http://ask.github.com/celery/getting-started/index.html. | |
|
145 | This is a very nice tutorial on how to start using celery_ with rabbitmq_ | |
|
146 | ||
|
147 | ||
|
148 | Next | |
|
149 | ---- | |
|
150 | ||
|
151 | You can now proceed to :ref:`setup`. | |
|
152 | ||
|
153 | ||
|
154 | 116 | Upgrading Kallithea from Python Package Index (PyPI) |
|
155 | 117 | ----------------------------------------------------- |
|
156 | 118 | |
|
157 | 119 | .. note:: |
|
158 | 120 | Firstly, it is recommended that you **always** perform a database and |
|
159 | 121 | configuration backup before doing an upgrade. |
|
160 | 122 | |
|
161 | 123 | (These directions will use '{version}' to note that this is the version of |
|
162 | 124 | Kallithea that these files were used with. If backing up your Kallithea |
|
163 | 125 | instance from version 0.1 to 0.2, the ``my.ini`` file could be |
|
164 | 126 | backed up to ``my.ini.0-1``.) |
|
165 | 127 | |
|
166 | 128 | |
|
167 | 129 | If using a SQLite database, stop the Kallithea process/daemon/service, and |
|
168 | 130 | then make a copy of the database file:: |
|
169 | 131 | |
|
170 | 132 | service kallithea stop |
|
171 | 133 | cp kallithea.db kallithea.db.{version} |
|
172 | 134 | |
|
173 | 135 | |
|
174 | 136 | Back up your configuration file:: |
|
175 | 137 | |
|
176 | 138 | cp my.ini my.ini.{version} |
|
177 | 139 | |
|
178 | 140 | |
|
179 | 141 | Ensure that you are using the Python Virtual Environment that you'd originally |
|
180 | 142 | installed Kallithea in:: |
|
181 | 143 | |
|
182 | 144 | pip freeze |
|
183 | 145 | |
|
184 | 146 | will list all packages installed in the current environment. If Kallithea |
|
185 | 147 | isn't listed, change virtual environments to your venv location:: |
|
186 | 148 | |
|
187 | 149 | source /srv/kallithea/venv/bin/activate |
|
188 | 150 | |
|
189 | 151 | |
|
190 | 152 | Once you have verified the environment you can upgrade Kallithea with:: |
|
191 | 153 | |
|
192 | 154 | pip install --upgrade kallithea |
|
193 | 155 | |
|
194 | 156 | |
|
195 | 157 | Then run the following command from the installation directory:: |
|
196 | 158 | |
|
197 | 159 | paster make-config Kallithea my.ini |
|
198 | 160 | |
|
199 | 161 | This will display any changes made by the new version of Kallithea to your |
|
200 | 162 | current configuration. It will try to perform an automerge. It's recommended |
|
201 | 163 | that you re-check the content after the automerge. |
|
202 | 164 | |
|
203 | 165 | .. note:: |
|
204 | 166 | Please always make sure your .ini files are up to date. Often errors are |
|
205 | 167 | caused by missing params added in new versions. |
|
206 | 168 | |
|
207 | 169 | |
|
208 | 170 | It is also recommended that you rebuild the whoosh index after upgrading since |
|
209 | 171 | the new whoosh version could introduce some incompatible index changes. Please |
|
210 | 172 | read the changelog to see if there were any changes to whoosh. |
|
211 | 173 | |
|
212 | 174 | |
|
213 | 175 | The final step is to upgrade the database. To do this simply run:: |
|
214 | 176 | |
|
215 | 177 | paster upgrade-db my.ini |
|
216 | 178 | |
|
217 | 179 | This will upgrade the schema and update some of the defaults in the database, |
|
218 | 180 | and will always recheck the settings of the application, if there are no new |
|
219 | 181 | options that need to be set. |
|
220 | 182 | |
|
221 | 183 | |
|
222 | 184 | .. note:: |
|
223 | 185 | DB schema upgrade library has some limitations and can sometimes fail if you try to |
|
224 | 186 | upgrade from older major releases. In such case simply run upgrades sequentially, eg. |
|
225 | 187 | upgrading from 0.1.X to 0.3.X should be done like that: 0.1.X. > 0.2.X > 0.3.X |
|
226 | 188 | You can always specify what version of Kallithea you want to install for example in pip |
|
227 | 189 | `pip install Kallithea==0.2` |
|
228 | 190 | |
|
229 | 191 | You may find it helpful to clear out your log file so that new errors are |
|
230 | 192 | readily apparent:: |
|
231 | 193 | |
|
232 | 194 | echo > kallithea.log |
|
233 | 195 | |
|
234 | 196 | Once that is complete, you may now start your upgraded Kallithea Instance:: |
|
235 | 197 | |
|
236 | 198 | service kallithea start |
|
237 | 199 | |
|
238 | 200 | Or:: |
|
239 | 201 | |
|
240 | 202 | paster serve /srv/kallithea/my.ini |
|
241 | 203 | |
|
242 | 204 | .. note:: |
|
243 | 205 | If you're using Celery, make sure you restart all instances of it after |
|
244 | 206 | upgrade. |
|
245 | 207 | |
|
246 | 208 | |
|
247 | 209 | .. _virtualenv: http://pypi.python.org/pypi/virtualenv |
|
248 |
.. _ |
|
|
249 | .. _mercurial: http://mercurial.selenic.com/ | |
|
250 | .. _celery: http://celeryproject.org/ | |
|
251 | .. _rabbitmq: http://www.rabbitmq.com/ | |
|
210 | .. _Python: http://www.python.org/ |
@@ -1,764 +1,781 b'' | |||
|
1 | 1 | .. _setup: |
|
2 | 2 | |
|
3 | 3 | ===== |
|
4 | 4 | Setup |
|
5 | 5 | ===== |
|
6 | 6 | |
|
7 | 7 | |
|
8 | 8 | Setting up Kallithea |
|
9 | 9 | -------------------- |
|
10 | 10 | |
|
11 | 11 | First, you will need to create a Kallithea configuration file. Run the |
|
12 | 12 | following command to do this:: |
|
13 | 13 | |
|
14 | 14 | paster make-config Kallithea my.ini |
|
15 | 15 | |
|
16 | 16 | - This will create the file `my.ini` in the current directory. This |
|
17 | 17 | configuration file contains the various settings for Kallithea, e.g proxy |
|
18 |
port, email settings, usage of static files, cache, |
|
|
18 | port, email settings, usage of static files, cache, Celery settings and | |
|
19 | 19 | logging. |
|
20 | 20 | |
|
21 | 21 | |
|
22 | 22 | Next, you need to create the databases used by Kallithea. It is recommended to |
|
23 | 23 | use PostgreSQL or SQLite (default). If you choose a database other than the |
|
24 | 24 | default ensure you properly adjust the database URL in your my.ini |
|
25 | 25 | configuration file to use this other database. Kallithea currently supports |
|
26 | 26 | PostgreSQL, SQLite and MySQL databases. Create the database by running |
|
27 | 27 | the following command:: |
|
28 | 28 | |
|
29 | 29 | paster setup-db my.ini |
|
30 | 30 | |
|
31 | 31 | This will prompt you for a "root" path. This "root" path is the location where |
|
32 | 32 | Kallithea will store all of its repositories on the current machine. After |
|
33 | 33 | entering this "root" path ``setup-db`` will also prompt you for a username |
|
34 | 34 | and password for the initial admin account which ``setup-db`` sets |
|
35 | 35 | up for you. |
|
36 | 36 | |
|
37 | 37 | setup process can be fully automated, example for lazy:: |
|
38 | 38 | |
|
39 | 39 | paster setup-db my.ini --user=nn --password=secret --email=nn@your.kallithea.server --repos=/srv/repos |
|
40 | 40 | |
|
41 | 41 | |
|
42 | 42 | - The ``setup-db`` command will create all of the needed tables and an |
|
43 | 43 | admin account. When choosing a root path you can either use a new empty |
|
44 | 44 | location, or a location which already contains existing repositories. If you |
|
45 | 45 | choose a location which contains existing repositories Kallithea will |
|
46 | 46 | add all of the repositories at the chosen location to its database. |
|
47 | 47 | (Note: make sure you specify the correct path to the root). |
|
48 | 48 | - Note: the given path for Mercurial_ repositories **must** be write accessible |
|
49 | 49 | for the application. It's very important since the Kallithea web interface |
|
50 | 50 | will work without write access, but when trying to do a push it will |
|
51 | 51 | eventually fail with permission denied errors unless it has write access. |
|
52 | 52 | |
|
53 | 53 | You are now ready to use Kallithea, to run it simply execute:: |
|
54 | 54 | |
|
55 | 55 | paster serve my.ini |
|
56 | 56 | |
|
57 | 57 | - This command runs the Kallithea server. The web app should be available at the |
|
58 | 58 | 127.0.0.1:5000. This ip and port is configurable via the my.ini |
|
59 | 59 | file created in previous step |
|
60 | 60 | - Use the admin account you created above when running ``setup-db`` |
|
61 | 61 | to login to the web app. |
|
62 | 62 | - The default permissions on each repository is read, and the owner is admin. |
|
63 | 63 | Remember to update these if needed. |
|
64 | 64 | - In the admin panel you can toggle LDAP, anonymous, permissions settings. As |
|
65 | 65 | well as edit more advanced options on users and repositories |
|
66 | 66 | |
|
67 | 67 | Optionally users can create `rcextensions` package that extends Kallithea |
|
68 | 68 | functionality. To do this simply execute:: |
|
69 | 69 | |
|
70 | 70 | paster make-rcext my.ini |
|
71 | 71 | |
|
72 | 72 | This will create `rcextensions` package in the same place that your `ini` file |
|
73 | 73 | lives. With `rcextensions` it's possible to add additional mapping for whoosh, |
|
74 | 74 | stats and add additional code into the push/pull/create/delete repo hooks. |
|
75 | 75 | For example for sending signals to build-bots such as Jenkins. |
|
76 | 76 | Please see the `__init__.py` file inside `rcextensions` package |
|
77 | 77 | for more details. |
|
78 | 78 | |
|
79 | 79 | |
|
80 | 80 | Using Kallithea with SSH |
|
81 | 81 | ------------------------ |
|
82 | 82 | |
|
83 | 83 | Kallithea currently only hosts repositories using http and https. (The addition |
|
84 | 84 | of ssh hosting is a planned future feature.) However you can easily use ssh in |
|
85 | 85 | parallel with Kallithea. (Repository access via ssh is a standard "out of |
|
86 | 86 | the box" feature of Mercurial_ and you can use this to access any of the |
|
87 | 87 | repositories that Kallithea is hosting. See PublishingRepositories_) |
|
88 | 88 | |
|
89 | 89 | Kallithea repository structures are kept in directories with the same name |
|
90 | 90 | as the project. When using repository groups, each group is a subdirectory. |
|
91 | 91 | This allows you to easily use ssh for accessing repositories. |
|
92 | 92 | |
|
93 | 93 | In order to use ssh you need to make sure that your web-server and the users |
|
94 | 94 | login accounts have the correct permissions set on the appropriate directories. |
|
95 | 95 | (Note that these permissions are independent of any permissions you have set up |
|
96 | 96 | using the Kallithea web interface.) |
|
97 | 97 | |
|
98 | 98 | If your main directory (the same as set in Kallithea settings) is for example |
|
99 | 99 | set to **/srv/repos** and the repository you are using is named `kallithea`, then |
|
100 | 100 | to clone via ssh you should run:: |
|
101 | 101 | |
|
102 | 102 | hg clone ssh://user@server.com//srv/repos/kallithea |
|
103 | 103 | |
|
104 | 104 | Using other external tools such as mercurial-server_ or using ssh key based |
|
105 | 105 | authentication is fully supported. |
|
106 | 106 | |
|
107 | 107 | Note: In an advanced setup, in order for your ssh access to use the same |
|
108 | 108 | permissions as set up via the Kallithea web interface, you can create an |
|
109 | 109 | authentication hook to connect to the Kallithea db and runs check functions for |
|
110 | 110 | permissions against that. |
|
111 | 111 | |
|
112 | 112 | Setting up Whoosh full text search |
|
113 | 113 | ---------------------------------- |
|
114 | 114 | |
|
115 | 115 | The whoosh index can be build by using the paster |
|
116 | 116 | command ``make-index``. To use ``make-index`` you must specify the configuration |
|
117 | 117 | file that stores the location of the index. You may specify the location of the |
|
118 | 118 | repositories (`--repo-location`). If not specified, this value is retrieved |
|
119 | 119 | from the Kallithea database. |
|
120 | 120 | It is also possible to specify a comma separated list of |
|
121 | 121 | repositories (`--index-only`) to build index only on chooses repositories |
|
122 | 122 | skipping any other found in repos location |
|
123 | 123 | |
|
124 | 124 | You may optionally pass the option `-f` to enable a full index rebuild. Without |
|
125 | 125 | the `-f` option, indexing will run always in "incremental" mode. |
|
126 | 126 | |
|
127 | 127 | For an incremental index build use:: |
|
128 | 128 | |
|
129 | 129 | paster make-index my.ini |
|
130 | 130 | |
|
131 | 131 | For a full index rebuild use:: |
|
132 | 132 | |
|
133 | 133 | paster make-index my.ini -f |
|
134 | 134 | |
|
135 | 135 | |
|
136 | 136 | building index just for chosen repositories is possible with such command:: |
|
137 | 137 | |
|
138 | 138 | paster make-index my.ini --index-only=vcs,kallithea |
|
139 | 139 | |
|
140 | 140 | |
|
141 | 141 | In order to do periodical index builds and keep your index always up to date. |
|
142 | 142 | It's recommended to do a crontab entry for incremental indexing. |
|
143 | 143 | An example entry might look like this:: |
|
144 | 144 | |
|
145 | 145 | /path/to/python/bin/paster make-index /path/to/kallithea/my.ini |
|
146 | 146 | |
|
147 | 147 | When using incremental mode (the default) whoosh will check the last |
|
148 | 148 | modification date of each file and add it to be reindexed if a newer file is |
|
149 | 149 | available. The indexing daemon checks for any removed files and removes them |
|
150 | 150 | from index. |
|
151 | 151 | |
|
152 | 152 | If you want to rebuild index from scratch, you can use the `-f` flag as above, |
|
153 | 153 | or in the admin panel you can check `build from scratch` flag. |
|
154 | 154 | |
|
155 | 155 | |
|
156 | 156 | Setting up LDAP support |
|
157 | 157 | ----------------------- |
|
158 | 158 | |
|
159 | 159 | Kallithea supports LDAP authentication. In order |
|
160 | 160 | to use LDAP, you have to install the python-ldap_ package. This package is |
|
161 | 161 | available via pypi, so you can install it by running |
|
162 | 162 | |
|
163 | 163 | pip install python-ldap |
|
164 | 164 | |
|
165 | 165 | .. note:: |
|
166 | 166 | python-ldap requires some certain libs on your system, so before installing |
|
167 | 167 | it check that you have at least `openldap`, and `sasl` libraries. |
|
168 | 168 | |
|
169 | 169 | LDAP settings are located in Admin->LDAP section. |
|
170 | 170 | |
|
171 | 171 | Here's a typical LDAP setup:: |
|
172 | 172 | |
|
173 | 173 | Connection settings |
|
174 | 174 | Enable LDAP = checked |
|
175 | 175 | Host = host.example.org |
|
176 | 176 | Port = 389 |
|
177 | 177 | Account = <account> |
|
178 | 178 | Password = <password> |
|
179 | 179 | Connection Security = LDAPS connection |
|
180 | 180 | Certificate Checks = DEMAND |
|
181 | 181 | |
|
182 | 182 | Search settings |
|
183 | 183 | Base DN = CN=users,DC=host,DC=example,DC=org |
|
184 | 184 | LDAP Filter = (&(objectClass=user)(!(objectClass=computer))) |
|
185 | 185 | LDAP Search Scope = SUBTREE |
|
186 | 186 | |
|
187 | 187 | Attribute mappings |
|
188 | 188 | Login Attribute = uid |
|
189 | 189 | First Name Attribute = firstName |
|
190 | 190 | Last Name Attribute = lastName |
|
191 | 191 | E-mail Attribute = mail |
|
192 | 192 | |
|
193 | 193 | If your user groups are placed in a Organisation Unit (OU) structure the Search Settings configuration differs:: |
|
194 | 194 | |
|
195 | 195 | Search settings |
|
196 | 196 | Base DN = DC=host,DC=example,DC=org |
|
197 | 197 | LDAP Filter = (&(memberOf=CN=your user group,OU=subunit,OU=unit,DC=host,DC=example,DC=org)(objectClass=user)) |
|
198 | 198 | LDAP Search Scope = SUBTREE |
|
199 | 199 | |
|
200 | 200 | .. _enable_ldap: |
|
201 | 201 | |
|
202 | 202 | Enable LDAP : required |
|
203 | 203 | Whether to use LDAP for authenticating users. |
|
204 | 204 | |
|
205 | 205 | .. _ldap_host: |
|
206 | 206 | |
|
207 | 207 | Host : required |
|
208 | 208 | LDAP server hostname or IP address. Can be also a comma separated |
|
209 | 209 | list of servers to support LDAP fail-over. |
|
210 | 210 | |
|
211 | 211 | .. _Port: |
|
212 | 212 | |
|
213 | 213 | Port : required |
|
214 | 214 | 389 for un-encrypted LDAP, 636 for SSL-encrypted LDAP. |
|
215 | 215 | |
|
216 | 216 | .. _ldap_account: |
|
217 | 217 | |
|
218 | 218 | Account : optional |
|
219 | 219 | Only required if the LDAP server does not allow anonymous browsing of |
|
220 | 220 | records. This should be a special account for record browsing. This |
|
221 | 221 | will require `LDAP Password`_ below. |
|
222 | 222 | |
|
223 | 223 | .. _LDAP Password: |
|
224 | 224 | |
|
225 | 225 | Password : optional |
|
226 | 226 | Only required if the LDAP server does not allow anonymous browsing of |
|
227 | 227 | records. |
|
228 | 228 | |
|
229 | 229 | .. _Enable LDAPS: |
|
230 | 230 | |
|
231 | 231 | Connection Security : required |
|
232 | 232 | Defines the connection to LDAP server |
|
233 | 233 | |
|
234 | 234 | No encryption |
|
235 | 235 | Plain non encrypted connection |
|
236 | 236 | |
|
237 | 237 | LDAPS connection |
|
238 | 238 | Enable LDAPS connections. It will likely require `Port`_ to be set to |
|
239 | 239 | a different value (standard LDAPS port is 636). When LDAPS is enabled |
|
240 | 240 | then `Certificate Checks`_ is required. |
|
241 | 241 | |
|
242 | 242 | START_TLS on LDAP connection |
|
243 | 243 | START TLS connection |
|
244 | 244 | |
|
245 | 245 | .. _Certificate Checks: |
|
246 | 246 | |
|
247 | 247 | Certificate Checks : optional |
|
248 | 248 | How SSL certificates verification is handled - this is only useful when |
|
249 | 249 | `Enable LDAPS`_ is enabled. Only DEMAND or HARD offer full SSL security |
|
250 | 250 | while the other options are susceptible to man-in-the-middle attacks. SSL |
|
251 | 251 | certificates can be installed to /etc/openldap/cacerts so that the |
|
252 | 252 | DEMAND or HARD options can be used with self-signed certificates or |
|
253 | 253 | certificates that do not have traceable certificates of authority. |
|
254 | 254 | |
|
255 | 255 | NEVER |
|
256 | 256 | A serve certificate will never be requested or checked. |
|
257 | 257 | |
|
258 | 258 | ALLOW |
|
259 | 259 | A server certificate is requested. Failure to provide a |
|
260 | 260 | certificate or providing a bad certificate will not terminate the |
|
261 | 261 | session. |
|
262 | 262 | |
|
263 | 263 | TRY |
|
264 | 264 | A server certificate is requested. Failure to provide a |
|
265 | 265 | certificate does not halt the session; providing a bad certificate |
|
266 | 266 | halts the session. |
|
267 | 267 | |
|
268 | 268 | DEMAND |
|
269 | 269 | A server certificate is requested and must be provided and |
|
270 | 270 | authenticated for the session to proceed. |
|
271 | 271 | |
|
272 | 272 | HARD |
|
273 | 273 | The same as DEMAND. |
|
274 | 274 | |
|
275 | 275 | .. _Base DN: |
|
276 | 276 | |
|
277 | 277 | Base DN : required |
|
278 | 278 | The Distinguished Name (DN) where searches for users will be performed. |
|
279 | 279 | Searches can be controlled by `LDAP Filter`_ and `LDAP Search Scope`_. |
|
280 | 280 | |
|
281 | 281 | .. _LDAP Filter: |
|
282 | 282 | |
|
283 | 283 | LDAP Filter : optional |
|
284 | 284 | A LDAP filter defined by RFC 2254. This is more useful when `LDAP |
|
285 | 285 | Search Scope`_ is set to SUBTREE. The filter is useful for limiting |
|
286 | 286 | which LDAP objects are identified as representing Users for |
|
287 | 287 | authentication. The filter is augmented by `Login Attribute`_ below. |
|
288 | 288 | This can commonly be left blank. |
|
289 | 289 | |
|
290 | 290 | .. _LDAP Search Scope: |
|
291 | 291 | |
|
292 | 292 | LDAP Search Scope : required |
|
293 | 293 | This limits how far LDAP will search for a matching object. |
|
294 | 294 | |
|
295 | 295 | BASE |
|
296 | 296 | Only allows searching of `Base DN`_ and is usually not what you |
|
297 | 297 | want. |
|
298 | 298 | |
|
299 | 299 | ONELEVEL |
|
300 | 300 | Searches all entries under `Base DN`_, but not Base DN itself. |
|
301 | 301 | |
|
302 | 302 | SUBTREE |
|
303 | 303 | Searches all entries below `Base DN`_, but not Base DN itself. |
|
304 | 304 | When using SUBTREE `LDAP Filter`_ is useful to limit object |
|
305 | 305 | location. |
|
306 | 306 | |
|
307 | 307 | .. _Login Attribute: |
|
308 | 308 | |
|
309 | 309 | Login Attribute : required |
|
310 | 310 | The LDAP record attribute that will be matched as the USERNAME or |
|
311 | 311 | ACCOUNT used to connect to Kallithea. This will be added to `LDAP |
|
312 | 312 | Filter`_ for locating the User object. If `LDAP Filter`_ is specified as |
|
313 | 313 | "LDAPFILTER", `Login Attribute`_ is specified as "uid" and the user has |
|
314 | 314 | connected as "jsmith" then the `LDAP Filter`_ will be augmented as below |
|
315 | 315 | :: |
|
316 | 316 | |
|
317 | 317 | (&(LDAPFILTER)(uid=jsmith)) |
|
318 | 318 | |
|
319 | 319 | .. _ldap_attr_firstname: |
|
320 | 320 | |
|
321 | 321 | First Name Attribute : required |
|
322 | 322 | The LDAP record attribute which represents the user's first name. |
|
323 | 323 | |
|
324 | 324 | .. _ldap_attr_lastname: |
|
325 | 325 | |
|
326 | 326 | Last Name Attribute : required |
|
327 | 327 | The LDAP record attribute which represents the user's last name. |
|
328 | 328 | |
|
329 | 329 | .. _ldap_attr_email: |
|
330 | 330 | |
|
331 | 331 | Email Attribute : required |
|
332 | 332 | The LDAP record attribute which represents the user's email address. |
|
333 | 333 | |
|
334 | 334 | If all data are entered correctly, and python-ldap_ is properly installed |
|
335 | 335 | users should be granted access to Kallithea with LDAP accounts. At this |
|
336 | 336 | time user information is copied from LDAP into the Kallithea user database. |
|
337 | 337 | This means that updates of an LDAP user object may not be reflected as a |
|
338 | 338 | user update in Kallithea. |
|
339 | 339 | |
|
340 | 340 | If You have problems with LDAP access and believe You entered correct |
|
341 | 341 | information check out the Kallithea logs, any error messages sent from LDAP |
|
342 | 342 | will be saved there. |
|
343 | 343 | |
|
344 | 344 | Active Directory |
|
345 | 345 | '''''''''''''''' |
|
346 | 346 | |
|
347 | 347 | Kallithea can use Microsoft Active Directory for user authentication. This |
|
348 | 348 | is done through an LDAP or LDAPS connection to Active Directory. The |
|
349 | 349 | following LDAP configuration settings are typical for using Active |
|
350 | 350 | Directory :: |
|
351 | 351 | |
|
352 | 352 | Base DN = OU=SBSUsers,OU=Users,OU=MyBusiness,DC=v3sys,DC=local |
|
353 | 353 | Login Attribute = sAMAccountName |
|
354 | 354 | First Name Attribute = givenName |
|
355 | 355 | Last Name Attribute = sn |
|
356 | 356 | E-mail Attribute = mail |
|
357 | 357 | |
|
358 | 358 | All other LDAP settings will likely be site-specific and should be |
|
359 | 359 | appropriately configured. |
|
360 | 360 | |
|
361 | 361 | |
|
362 | 362 | Authentication by container or reverse-proxy |
|
363 | 363 | -------------------------------------------- |
|
364 | 364 | |
|
365 | 365 | Kallithea supports delegating the authentication |
|
366 | 366 | of users to its WSGI container, or to a reverse-proxy server through which all |
|
367 | 367 | clients access the application. |
|
368 | 368 | |
|
369 | 369 | When these authentication methods are enabled in Kallithea, it uses the |
|
370 | 370 | username that the container/proxy (Apache/Nginx/etc) authenticated and doesn't |
|
371 | 371 | perform the authentication itself. The authorization, however, is still done by |
|
372 | 372 | Kallithea according to its settings. |
|
373 | 373 | |
|
374 | 374 | When a user logs in for the first time using these authentication methods, |
|
375 | 375 | a matching user account is created in Kallithea with default permissions. An |
|
376 | 376 | administrator can then modify it using Kallithea's admin interface. |
|
377 | 377 | It's also possible for an administrator to create accounts and configure their |
|
378 | 378 | permissions before the user logs in for the first time. |
|
379 | 379 | |
|
380 | 380 | |
|
381 | 381 | Container-based authentication |
|
382 | 382 | '''''''''''''''''''''''''''''' |
|
383 | 383 | |
|
384 | 384 | In a container-based authentication setup, Kallithea reads the user name from |
|
385 | 385 | the ``REMOTE_USER`` server variable provided by the WSGI container. |
|
386 | 386 | |
|
387 | 387 | After setting up your container (see `Apache's WSGI config`_), you'd need |
|
388 | 388 | to configure it to require authentication on the location configured for |
|
389 | 389 | Kallithea. |
|
390 | 390 | |
|
391 | 391 | |
|
392 | 392 | Proxy pass-through authentication |
|
393 | 393 | ''''''''''''''''''''''''''''''''' |
|
394 | 394 | |
|
395 | 395 | In a proxy pass-through authentication setup, Kallithea reads the user name |
|
396 | 396 | from the ``X-Forwarded-User`` request header, which should be configured to be |
|
397 | 397 | sent by the reverse-proxy server. |
|
398 | 398 | |
|
399 | 399 | After setting up your proxy solution (see `Apache virtual host reverse proxy example`_, |
|
400 | 400 | `Apache as subdirectory`_ or `Nginx virtual host example`_), you'd need to |
|
401 | 401 | configure the authentication and add the username in a request header named |
|
402 | 402 | ``X-Forwarded-User``. |
|
403 | 403 | |
|
404 | 404 | For example, the following config section for Apache sets a subdirectory in a |
|
405 | 405 | reverse-proxy setup with basic auth:: |
|
406 | 406 | |
|
407 | 407 | <Location /<someprefix> > |
|
408 | 408 | ProxyPass http://127.0.0.1:5000/<someprefix> |
|
409 | 409 | ProxyPassReverse http://127.0.0.1:5000/<someprefix> |
|
410 | 410 | SetEnvIf X-Url-Scheme https HTTPS=1 |
|
411 | 411 | |
|
412 | 412 | AuthType Basic |
|
413 | 413 | AuthName "Kallithea authentication" |
|
414 | 414 | AuthUserFile /srv/kallithea/.htpasswd |
|
415 | 415 | require valid-user |
|
416 | 416 | |
|
417 | 417 | RequestHeader unset X-Forwarded-User |
|
418 | 418 | |
|
419 | 419 | RewriteEngine On |
|
420 | 420 | RewriteCond %{LA-U:REMOTE_USER} (.+) |
|
421 | 421 | RewriteRule .* - [E=RU:%1] |
|
422 | 422 | RequestHeader set X-Forwarded-User %{RU}e |
|
423 | 423 | </Location> |
|
424 | 424 | |
|
425 | 425 | |
|
426 | 426 | .. note:: |
|
427 | 427 | If you enable proxy pass-through authentication, make sure your server is |
|
428 | 428 | only accessible through the proxy. Otherwise, any client would be able to |
|
429 | 429 | forge the authentication header and could effectively become authenticated |
|
430 | 430 | using any account of their liking. |
|
431 | 431 | |
|
432 | 432 | Integration with Issue trackers |
|
433 | 433 | ------------------------------- |
|
434 | 434 | |
|
435 | 435 | Kallithea provides a simple integration with issue trackers. It's possible |
|
436 | 436 | to define a regular expression that will fetch issue id stored in commit |
|
437 | 437 | messages and replace that with an url to this issue. To enable this simply |
|
438 | 438 | uncomment following variables in the ini file:: |
|
439 | 439 | |
|
440 | 440 | issue_pat = (?:^#|\s#)(\w+) |
|
441 | 441 | issue_server_link = https://myissueserver.com/{repo}/issue/{id} |
|
442 | 442 | issue_prefix = # |
|
443 | 443 | |
|
444 | 444 | `issue_pat` is the regular expression describing which strings in |
|
445 | 445 | commit messages will be treated as issue references. A match group in |
|
446 | 446 | parentheses should be used to specify the actual issue id. |
|
447 | 447 | |
|
448 | 448 | The default expression matches issues in the format '#<number>', e.g. '#300'. |
|
449 | 449 | |
|
450 | 450 | Matched issues are replaced with the link specified as `issue_server_link` |
|
451 | 451 | {id} is replaced with issue id, and {repo} with repository name. |
|
452 | 452 | Since the # is stripped away, `issue_prefix` is prepended to the link text. |
|
453 | 453 | `issue_prefix` doesn't necessarily need to be #: if you set issue |
|
454 | 454 | prefix to ISSUE- this will generate a URL in format:: |
|
455 | 455 | |
|
456 | 456 | <a href="https://myissueserver.com/example_repo/issue/300">ISSUE-300</a> |
|
457 | 457 | |
|
458 | 458 | If needed, more than one pattern can be specified by appending a unique suffix to |
|
459 | 459 | the variables. For example:: |
|
460 | 460 | |
|
461 | 461 | issue_pat_wiki = (?:wiki-)(.+) |
|
462 | 462 | issue_server_link_wiki = https://mywiki.com/{id} |
|
463 | 463 | issue_prefix_wiki = WIKI- |
|
464 | 464 | |
|
465 | 465 | With these settings, wiki pages can be referenced as wiki-some-id, and every |
|
466 | 466 | such reference will be transformed into:: |
|
467 | 467 | |
|
468 | 468 | <a href="https://mywiki.com/some-id">WIKI-some-id</a> |
|
469 | 469 | |
|
470 | 470 | |
|
471 | 471 | Hook management |
|
472 | 472 | --------------- |
|
473 | 473 | |
|
474 | 474 | Hooks can be managed in similar way to this used in .hgrc files. |
|
475 | 475 | To access hooks setting click `advanced setup` on Hooks section of Mercurial |
|
476 | 476 | Settings in Admin. |
|
477 | 477 | |
|
478 | 478 | There are 4 built in hooks that cannot be changed (only enable/disable by |
|
479 | 479 | checkboxes on previos section). |
|
480 | 480 | To add another custom hook simply fill in first section with |
|
481 | 481 | <name>.<hook_type> and the second one with hook path. Example hooks |
|
482 | 482 | can be found at *kallithea.lib.hooks*. |
|
483 | 483 | |
|
484 | 484 | |
|
485 | 485 | Changing default encoding |
|
486 | 486 | ------------------------- |
|
487 | 487 | |
|
488 | 488 | By default, Kallithea uses UTF-8 encoding. |
|
489 | 489 | It is configurable as `default_encoding` in the .ini file. |
|
490 | 490 | This affects many parts in Kallithea including user names, filenames, and |
|
491 | 491 | encoding of commit messages. In addition Kallithea can detect if `chardet` |
|
492 | 492 | library is installed. If `chardet` is detected Kallithea will fallback to it |
|
493 | 493 | when there are encode/decode errors. |
|
494 | 494 | |
|
495 | 495 | |
|
496 | 496 | Celery configuration |
|
497 | 497 | -------------------- |
|
498 | 498 | |
|
499 | Celery is configured in the Kallithea ini configuration files. | |
|
500 | Simply set use_celery=true in the ini file then add / change the configuration | |
|
501 | variables inside the ini file. | |
|
499 | Kallithea can use the distributed task queue system Celery_ to run tasks like | |
|
500 | cloning repositories or sending mails. | |
|
501 | ||
|
502 | Kallithea will in most setups work perfectly fine out of the box (without | |
|
503 | Celery), executing all tasks in the web server process. Some tasks can however | |
|
504 | take some time to run and it can be better to run such tasks asynchronously in | |
|
505 | a separate process so the web server can focus on serving web requests. | |
|
506 | ||
|
507 | For installation and configuration of Celery, see the `Celery documentation`_. | |
|
508 | Note that Celery requires a message broker service like RabbitMQ_ (recommended) | |
|
509 | or Redis_. | |
|
502 | 510 | |
|
503 | Remember that the ini files use the format with '.' not with '_' like celery. | |
|
504 | So for example setting `BROKER_HOST` in celery means setting `broker.host` in | |
|
505 | the config file. | |
|
511 | The use of Celery is configured in the Kallithea ini configuration file. | |
|
512 | To enable it, simply set:: | |
|
513 | ||
|
514 | use_celery = true | |
|
506 | 515 | |
|
507 | In order to start using celery run:: | |
|
516 | and add or change the celery.* and broker.* configuration variables. | |
|
517 | ||
|
518 | Remember that the ini files use the format with '.' and not with '_' like | |
|
519 | Celery. So for example setting `BROKER_HOST` in Celery means setting | |
|
520 | `broker.host` in the configuration file. | |
|
521 | ||
|
522 | To start the Celery process, run:: | |
|
508 | 523 | |
|
509 | 524 | paster celeryd <configfile.ini> |
|
510 | 525 | |
|
511 | 526 | |
|
512 | 527 | .. note:: |
|
513 | 528 | Make sure you run this command from the same virtualenv, and with the same |
|
514 | 529 | user that Kallithea runs. |
|
515 | 530 | |
|
516 | 531 | HTTPS support |
|
517 | 532 | ------------- |
|
518 | 533 | |
|
519 | 534 | Kallithea will by default generate URLs based on the WSGI environment. |
|
520 | 535 | |
|
521 | 536 | Alternatively, you can use some special configuration settings to control |
|
522 | 537 | directly which scheme/protocol Kallithea will use when generating URLs: |
|
523 | 538 | |
|
524 | 539 | - With `https_fixup = true`, the scheme will be taken from the HTTP_X_URL_SCHEME, |
|
525 | 540 | HTTP_X_FORWARDED_SCHEME or HTTP_X_FORWARDED_PROTO HTTP header (default 'http'). |
|
526 | 541 | - With `force_https = true` the default will be 'https'. |
|
527 | 542 | - With `use_htsts = true`, it will set Strict-Transport-Security when using https. |
|
528 | 543 | |
|
529 | 544 | Nginx virtual host example |
|
530 | 545 | -------------------------- |
|
531 | 546 | |
|
532 | 547 | Sample config for nginx using proxy:: |
|
533 | 548 | |
|
534 | 549 | upstream kallithea { |
|
535 | 550 | server 127.0.0.1:5000; |
|
536 | 551 | # add more instances for load balancing |
|
537 | 552 | #server 127.0.0.1:5001; |
|
538 | 553 | #server 127.0.0.1:5002; |
|
539 | 554 | } |
|
540 | 555 | |
|
541 | 556 | ## gist alias |
|
542 | 557 | server { |
|
543 | 558 | listen 443; |
|
544 | 559 | server_name gist.myserver.com; |
|
545 | 560 | access_log /var/log/nginx/gist.access.log; |
|
546 | 561 | error_log /var/log/nginx/gist.error.log; |
|
547 | 562 | |
|
548 | 563 | ssl on; |
|
549 | 564 | ssl_certificate gist.your.kallithea.server.crt; |
|
550 | 565 | ssl_certificate_key gist.your.kallithea.server.key; |
|
551 | 566 | |
|
552 | 567 | ssl_session_timeout 5m; |
|
553 | 568 | |
|
554 | 569 | ssl_protocols SSLv3 TLSv1; |
|
555 | 570 | ssl_ciphers DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:EDH-RSA-DES-CBC3-SHA:AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5; |
|
556 | 571 | ssl_prefer_server_ciphers on; |
|
557 | 572 | |
|
558 | 573 | rewrite ^/(.+)$ https://your.kallithea.server/_admin/gists/$1; |
|
559 | 574 | rewrite (.*) https://your.kallithea.server/_admin/gists; |
|
560 | 575 | } |
|
561 | 576 | |
|
562 | 577 | server { |
|
563 | 578 | listen 443; |
|
564 | 579 | server_name your.kallithea.server; |
|
565 | 580 | access_log /var/log/nginx/kallithea.access.log; |
|
566 | 581 | error_log /var/log/nginx/kallithea.error.log; |
|
567 | 582 | |
|
568 | 583 | ssl on; |
|
569 | 584 | ssl_certificate your.kallithea.server.crt; |
|
570 | 585 | ssl_certificate_key your.kallithea.server.key; |
|
571 | 586 | |
|
572 | 587 | ssl_session_timeout 5m; |
|
573 | 588 | |
|
574 | 589 | ssl_protocols SSLv3 TLSv1; |
|
575 | 590 | ssl_ciphers DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:EDH-RSA-DES-CBC3-SHA:AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5; |
|
576 | 591 | ssl_prefer_server_ciphers on; |
|
577 | 592 | |
|
578 | 593 | ## uncomment root directive if you want to serve static files by nginx |
|
579 | 594 | ## requires static_files = false in .ini file |
|
580 | 595 | #root /path/to/installation/kallithea/public; |
|
581 | 596 | include /etc/nginx/proxy.conf; |
|
582 | 597 | location / { |
|
583 | 598 | try_files $uri @kallithea; |
|
584 | 599 | } |
|
585 | 600 | |
|
586 | 601 | location @kallithea { |
|
587 | 602 | proxy_pass http://kallithea; |
|
588 | 603 | } |
|
589 | 604 | |
|
590 | 605 | } |
|
591 | 606 | |
|
592 | 607 | Here's the proxy.conf. It's tuned so it will not timeout on long |
|
593 | 608 | pushes or large pushes:: |
|
594 | 609 | |
|
595 | 610 | proxy_redirect off; |
|
596 | 611 | proxy_set_header Host $host; |
|
597 | 612 | ## needed for container auth |
|
598 | 613 | #proxy_set_header REMOTE_USER $remote_user; |
|
599 | 614 | #proxy_set_header X-Forwarded-User $remote_user; |
|
600 | 615 | proxy_set_header X-Url-Scheme $scheme; |
|
601 | 616 | proxy_set_header X-Host $http_host; |
|
602 | 617 | proxy_set_header X-Real-IP $remote_addr; |
|
603 | 618 | proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; |
|
604 | 619 | proxy_set_header Proxy-host $proxy_host; |
|
605 | 620 | proxy_buffering off; |
|
606 | 621 | proxy_connect_timeout 7200; |
|
607 | 622 | proxy_send_timeout 7200; |
|
608 | 623 | proxy_read_timeout 7200; |
|
609 | 624 | proxy_buffers 8 32k; |
|
610 | 625 | client_max_body_size 1024m; |
|
611 | 626 | client_body_buffer_size 128k; |
|
612 | 627 | large_client_header_buffers 8 64k; |
|
613 | 628 | |
|
614 | 629 | |
|
615 | 630 | Apache virtual host reverse proxy example |
|
616 | 631 | ----------------------------------------- |
|
617 | 632 | |
|
618 | 633 | Here is a sample configuration file for apache using proxy:: |
|
619 | 634 | |
|
620 | 635 | <VirtualHost *:80> |
|
621 | 636 | ServerName hg.myserver.com |
|
622 | 637 | ServerAlias hg.myserver.com |
|
623 | 638 | |
|
624 | 639 | <Proxy *> |
|
625 | 640 | Order allow,deny |
|
626 | 641 | Allow from all |
|
627 | 642 | </Proxy> |
|
628 | 643 | |
|
629 | 644 | #important ! |
|
630 | 645 | #Directive to properly generate url (clone url) for pylons |
|
631 | 646 | ProxyPreserveHost On |
|
632 | 647 | |
|
633 | 648 | #kallithea instance |
|
634 | 649 | ProxyPass / http://127.0.0.1:5000/ |
|
635 | 650 | ProxyPassReverse / http://127.0.0.1:5000/ |
|
636 | 651 | |
|
637 | 652 | #to enable https use line below |
|
638 | 653 | #SetEnvIf X-Url-Scheme https HTTPS=1 |
|
639 | 654 | |
|
640 | 655 | </VirtualHost> |
|
641 | 656 | |
|
642 | 657 | |
|
643 | 658 | Additional tutorial |
|
644 | 659 | http://pylonsbook.com/en/1.1/deployment.html#using-apache-to-proxy-requests-to-pylons |
|
645 | 660 | |
|
646 | 661 | |
|
647 | 662 | Apache as subdirectory |
|
648 | 663 | ---------------------- |
|
649 | 664 | |
|
650 | 665 | Apache subdirectory part:: |
|
651 | 666 | |
|
652 | 667 | <Location /<someprefix> > |
|
653 | 668 | ProxyPass http://127.0.0.1:5000/<someprefix> |
|
654 | 669 | ProxyPassReverse http://127.0.0.1:5000/<someprefix> |
|
655 | 670 | SetEnvIf X-Url-Scheme https HTTPS=1 |
|
656 | 671 | </Location> |
|
657 | 672 | |
|
658 | 673 | Besides the regular apache setup you will need to add the following line |
|
659 | 674 | into [app:main] section of your .ini file:: |
|
660 | 675 | |
|
661 | 676 | filter-with = proxy-prefix |
|
662 | 677 | |
|
663 | 678 | Add the following at the end of the .ini file:: |
|
664 | 679 | |
|
665 | 680 | [filter:proxy-prefix] |
|
666 | 681 | use = egg:PasteDeploy#prefix |
|
667 | 682 | prefix = /<someprefix> |
|
668 | 683 | |
|
669 | 684 | |
|
670 | 685 | then change <someprefix> into your chosen prefix |
|
671 | 686 | |
|
672 | 687 | Apache's WSGI config |
|
673 | 688 | -------------------- |
|
674 | 689 | |
|
675 | 690 | Alternatively, Kallithea can be set up with Apache under mod_wsgi. For |
|
676 | 691 | that, you'll need to: |
|
677 | 692 | |
|
678 | 693 | - Install mod_wsgi. If using a Debian-based distro, you can install |
|
679 | 694 | the package libapache2-mod-wsgi:: |
|
680 | 695 | |
|
681 | 696 | aptitude install libapache2-mod-wsgi |
|
682 | 697 | |
|
683 | 698 | - Enable mod_wsgi:: |
|
684 | 699 | |
|
685 | 700 | a2enmod wsgi |
|
686 | 701 | |
|
687 | 702 | - Create a wsgi dispatch script, like the one below. Make sure you |
|
688 | 703 | check the paths correctly point to where you installed Kallithea |
|
689 | 704 | and its Python Virtual Environment. |
|
690 | 705 | - Enable the WSGIScriptAlias directive for the wsgi dispatch script, |
|
691 | 706 | as in the following example. Once again, check the paths are |
|
692 | 707 | correctly specified. |
|
693 | 708 | |
|
694 | 709 | Here is a sample excerpt from an Apache Virtual Host configuration file:: |
|
695 | 710 | |
|
696 | 711 | WSGIDaemonProcess kallithea \ |
|
697 | 712 | processes=1 threads=4 \ |
|
698 | 713 | python-path=/srv/kallithea/pyenv/lib/python2.7/site-packages |
|
699 | 714 | WSGIScriptAlias / /srv/kallithea/dispatch.wsgi |
|
700 | 715 | WSGIPassAuthorization On |
|
701 | 716 | |
|
702 | 717 | Or if using a dispatcher wsgi script with proper virtualenv activation:: |
|
703 | 718 | |
|
704 | 719 | WSGIDaemonProcess kallithea processes=1 threads=4 |
|
705 | 720 | WSGIScriptAlias / /srv/kallithea/dispatch.wsgi |
|
706 | 721 | WSGIPassAuthorization On |
|
707 | 722 | |
|
708 | 723 | |
|
709 | 724 | .. note:: |
|
710 | 725 | When running apache as root, please make sure it doesn't run Kallithea as |
|
711 | 726 | root, for examply by adding: `user=www-data group=www-data` to the configuration. |
|
712 | 727 | |
|
713 | 728 | .. note:: |
|
714 | 729 | If running Kallithea in multiprocess mode, |
|
715 | 730 | make sure you set `instance_id = \*` in the configuration so each process |
|
716 | 731 | gets it's own cache invalidationkey. |
|
717 | 732 | |
|
718 | 733 | |
|
719 | 734 | Example wsgi dispatch script:: |
|
720 | 735 | |
|
721 | 736 | import os |
|
722 | 737 | os.environ["HGENCODING"] = "UTF-8" |
|
723 | 738 | os.environ['PYTHON_EGG_CACHE'] = '/srv/kallithea/.egg-cache' |
|
724 | 739 | |
|
725 | 740 | # sometimes it's needed to set the curent dir |
|
726 | 741 | os.chdir('/srv/kallithea/') |
|
727 | 742 | |
|
728 | 743 | import site |
|
729 | 744 | site.addsitedir("/srv/kallithea/pyenv/lib/python2.7/site-packages") |
|
730 | 745 | |
|
731 | 746 | from paste.deploy import loadapp |
|
732 | 747 | from paste.script.util.logging_config import fileConfig |
|
733 | 748 | |
|
734 | 749 | fileConfig('/srv/kallithea/my.ini') |
|
735 | 750 | application = loadapp('config:/srv/kallithea/my.ini') |
|
736 | 751 | |
|
737 | 752 | Or using proper virtualenv activation:: |
|
738 | 753 | |
|
739 | 754 | activate_this = '/srv/kallithea/venv/bin/activate_this.py' |
|
740 | 755 | execfile(activate_this,dict(__file__=activate_this)) |
|
741 | 756 | |
|
742 | 757 | import os |
|
743 | 758 | os.environ['HOME'] = '/srv/kallithea' |
|
744 | 759 | |
|
745 | 760 | ini = '/srv/kallithea/kallithea.ini' |
|
746 | 761 | from paste.script.util.logging_config import fileConfig |
|
747 | 762 | fileConfig(ini) |
|
748 | 763 | from paste.deploy import loadapp |
|
749 | 764 | application = loadapp('config:' + ini) |
|
750 | 765 | |
|
751 | 766 | |
|
752 | 767 | Other configuration files |
|
753 | 768 | ------------------------- |
|
754 | 769 | |
|
755 | 770 | Some example init.d scripts can be found in init.d directory: https://kallithea-scm.org/repos/kallithea/files/tip/init.d/ |
|
756 | 771 | |
|
757 | 772 | .. _virtualenv: http://pypi.python.org/pypi/virtualenv |
|
758 | 773 | .. _python: http://www.python.org/ |
|
759 | 774 | .. _Mercurial: http://mercurial.selenic.com/ |
|
760 |
.. _ |
|
|
761 | .. _rabbitmq: http://www.rabbitmq.com/ | |
|
775 | .. _Celery: http://celeryproject.org/ | |
|
776 | .. _Celery documentation: http://docs.celeryproject.org/en/latest/getting-started/index.html | |
|
777 | .. _RabbitMQ: http://www.rabbitmq.com/ | |
|
778 | .. _Redis: http://redis.io/ | |
|
762 | 779 | .. _python-ldap: http://www.python-ldap.org/ |
|
763 | 780 | .. _mercurial-server: http://www.lshift.net/mercurial-server.html |
|
764 | 781 | .. _PublishingRepositories: http://mercurial.selenic.com/wiki/PublishingRepositories |
General Comments 0
You need to be logged in to leave comments.
Login now