source: main/waeup.aaua/trunk/INSTALL.txt @ 11381

Last change on this file since 11381 was 11381, checked in by uli, 11 years ago

Update docs.

File size: 11.4 KB
Line 
1Installation of Kofa
2####################
3
4These are generic installation instructions for the WAeUP_ ``Kofa``
5student information portal and customized versions thereof.
6
7For specific aspects of this package please refer to the local README
8file.
9
10Please note, that **only Linux-based installs** are described and actively
11supported. We recommend use of Debian_ / Ubuntu_.
12
13.. note:: This means we do not actively support Windows(tm)!
14
15
16Prerequisites
17*************
18
19The Kofa packages are based on `Grok`_, which is a Python_
20framework for agile webapplication development. Grok_ itself is based
21on `Zope`_.
22
23Both, Grok_ and Zope_, are written in the `Python`_ programming
24language (with parts written in C). You therefore have to have
25`Python`_ installed (including `Python`_ headers).
26
27
28Preparing the System
29====================
30
31For a `Kofa` install we need of course `Python`_ installed as well as
32some standard developer tools like C compilers, C libraries, etc.
33
34What you need (Debian/Ubuntu package names in brackets):
35
36* Python 2.7 (``python2.7``)
37
38* Python 2.7 development files (``python2.7-dev``)
39
40* A C-Compiler with basic C developer libraries (``build-essential``)
41
42* A subversion client (``svn``)
43
44* enscript (``enscript``) [optional]
45
46  This is only needed if you want test coverage reports.
47
48All these packages can be installed on Debian systems like this::
49
50  $ sudo apt-get install python2.7 python2.7-dev svn \
51                         build-essential enscript
52
53Afterwards you should be able to enter::
54
55  $ python2.7
56
57at the commandline and get a Python_ prompt. Quit the interpreter
58pressing <CTRL-D>.
59
60
61Installing `virtualenv`
62=======================
63
64We recommend use of `virtualenv`_ to create Python_ sandboxes where you
65can run your code without touching any other installations.
66
67If you don't already have ``easy_install`` available, you can find the
68script to set it up on the `PEAK EasyInstall page`_.
69
70.. _`PEAK EasyInstall page`: http://peak.telecommunity.com/DevCenter/EasyInstall#installing-easy-install
71
72You need to download `ez_setup.py`_. Then, you run it like this to
73install ``easy_install`` into your system Python::
74
75  $ sudo python2.7 ez_setup.py
76
77.. _`ez_setup.py`: http://peak.telecommunity.com/dist/ez_setup.py
78
79This will make ``easy_install`` available to you.
80
81.. note:: Sometimes you have ``easy_install`` installed but you need a
82          newer version of the underlying setuptools infrastructure to
83          make Grok work. You can upgrade setuptools with::
84
85            $ sudo easy_install -U setuptools
86
87Now you can install `virtualenv` by doing (as root)::
88
89  # easy_install-2.7 virtualenv
90
91This step will fetch all needed sources from the internet and install
92`virtualenv` locally in your Python2.7 installation.
93
94
95Creating a sandbox
96==================
97
98This step is only necessary (and recommended) if you installed
99`virtualenv` before.
100
101As a normal user you now can create a sandbox for your upcoming work
102by::
103
104  $ virtualenv --no-site-packages mysandbox
105
106where ``mysandbox`` is a directory in the filesystem where your
107sandbox will be created. `virtualenv` will also create this directory
108for you.
109
110By passing the ``no-site-packages`` switch we tell `virtualenv` to
111provide us a clean environment without any extra-packages installed
112systemwide.
113
114You now can activate the sandbox by doing::
115
116  $ source mysandbox/bin/activate
117
118You will notice that the input prompt changes.
119
120To deactivate the sandbox at any time, enter::
121
122  (sandbox27)$ deactivate
123
124and the prompt will be the same as before the activation.
125
126For the following steps make sure the sandbox is active.
127
128
129Creating a working place
130========================
131
132In the sandbox we now create our real working
133environment. To do this, we change to the sandbox and checkout the
134sources of Kofa from the subversion server::
135
136  (sandbox27)$ cd mysandbox/
137  (sandbox27)$ svn co https://svn.waeup.org/repos/main/waeup.kofa/trunk kofa-trunk
138
139where ``kofa-trunk`` is only a name we've chosen here to make clear
140where the sources come from. In this case we are installing the Kofa base
141package.
142
143The command should fetch the Kofa base package sources for you and
144put it in the directory ``kofa-trunk/``.
145
146Now enter the new directory::
147
148  (sandbox27)$ cd kofa-trunk
149
150
151You can run ``Kofa`` with a single client (useful for evaluation,
152development, etc.) or with multiple clients running in parallel. The
153latter setup is useful in productive environments with many thousands
154users. We will cover both setup types one after another.
155
156
157Part 1: Single Client Setup
158***************************
159
160Preparing the build
161===================
162
163In the sources directory (``kofa-trunk/``) you have to prepare the
164project to fetch needed components (eggs), compile C-code parts,
165etc. This steip will not touch any external projects::
166
167  (sandbox27)$ python bootstrap.py
168
169This will generate some directories and the ``buildout`` script in
170``bin/`` for us. This step must be executed only once for each
171instance.
172
173You can now deactivate the sandbox::
174
175  (sandbox27)$ deactivate
176
177Now we can do the real build by triggering::
178
179  $ bin/buildout
180
181If this is your first install of some Grok-related project, this step
182will need some time as lots of sources have to be fetched, many
183components must be compiled, etc.
184
185This step must be redone whenever you change something in
186``buildout.cfg`` or ``setup.py``.
187
188Note that if you have more than one sandbox for a Zope-based web
189application, it will probably make sense to share the eggs between the
190different sandboxes.  You can tell ``zc.buildout`` to use a central
191eggs directory by creating ``~/.buildout/default.cfg`` with the
192following contents::
193
194    [buildout]
195    eggs-directory = /home/bruno/buildout-eggs
196
197
198Start the instance
199==================
200
201You should be able now to start the created instance by doing::
202
203   $ bin/zopectl fg
204
205Alternatively you can do:
206
207    $ bin/paster serve parts/etc/deploy.ini
208
209The port numbers where Kofa is running on your server are defined in
210buildout.cfg under [kofa_params].
211
212If you now point a browser to the right port on your server, for example ::
213
214   localhost:8080
215
216you should get a login pop-up, where you can login as superuser with
217``grok`` and ``grok`` as username/password (Kofa base package only!).
218
219You can stop the instance by pressing <CTRL-C>.
220
221If you are connected and logged in,
222you should be able to add the grok-based applications
223(such as ``University``) from the menu.
224
225Add an instance of ``University`` and click on the link next to the
226then visible entry in the list of installed applications.
227
228Running the tests
229=================
230
231The tests are easily run by executing the test runner that's
232installed in the ``bin`` directory::
233
234    $ bin/test
235
236
237Part 2: Deploying Kofa as ZEO install
238*************************************
239
240Each ZEO install consists of at least one ZEO server and normally two
241or more ZEO clients. While the ZEO server is meant to manage the ZODB
242database for clients, the clients connect to the outside world, listen
243for request and do the real dataprocessing.
244
245We prepared a `buildout` configuration that sets up one server
246configuration and two client configs. This configuration is in
247``buildout-zeo.cfg``.
248
249Generating the ZEO setup
250========================
251
252To install Kofa ZEO-based you can run `buildout` with the given
253(or your own) configuration file like this::
254
255  $ ./bin/buildout -c buildout-zeo.cfg
256
257This should generate all scripts necessary to run servers, clients,
258etc.
259
260Starting ZEO servers and clients
261================================
262
263First start the server::
264
265  $ ./bin/zeo_server start
266
267Clients can be started by doing::
268
269  $ ./bin/zeo_client1 start
270  $ ./bin/zeo_client2 start
271
272This will start both clients in daemon mode.
273
274Instead of ``start`` you can, as usually, start an instance in
275foreground (``fg``), etc. You know the drill.
276
277
278Manually starting ZEO clients
279=============================
280
281This is normally not neccessary.
282
283``zeo_clientN`` scripts are basically wrappers around calls to
284``bin/paster``. You can bypass this wrapper and start a client
285'manually' like this::
286
287  $ ./bin/paster serve --pid-file var/zeo1.pid --daemon \
288        pars/etc/zeo1.ini
289
290It is important to give a pid-file as paster otherwise can not start
291different clients (they would all refer to the same pid file
292`paster.pid` and refuse to start after the first client was started).
293
294
295Setup (paramters, ports, etc.)
296==============================
297
298By default the server will listen on port 8100 for requests from
299localhost (not: from the outside world).
300
301You can change ZEO server settings in the ``[zeo_server]`` section
302of ``buildout-zeo.conf``. Run `buildout` afterwards.
303
304The clients will listen on port 8081 and 8082. You can change settings
305in ``etc/zeo1.ini.in`` and ``etc/zeo2.ini.in`` respectively. Run
306buildout after any change.
307
308If you want to change the paster wrapper for any zeo client, you can
309edit ``etc/zeo1.conf`` and/or ``etc/zeo2.conf``. Run buildout
310afterwards.
311
312
313Creating new clients
314====================
315
316You want more clients to be created by buildout? Easy. Three steps are
317neccessary.
318
3191. Create config files in etc/
320------------------------------
321
322Each client needs two configuration files:
323
324  - ``etc/zeoN.conf``
325       configuring the paster wrapper
326
327  - ``etc/zeoN.ini``
328       configuring the runtime config, ports, etc.
329
330Just copy over these files from the already existing zeo1/zeo2 files
331and replace ``zeo1`` or ``zeo2`` with your new name.
332
3332. Update buildout-zeo.cfg
334--------------------------
335
336Here, inside ``buildourt-zeo.cfg`` also three steps are needed.
337
338* 2.1. Create new .ini and .conf entries
339
340  The .conf and .ini files in etc/ are only templates that have to be
341  generated in their really used final location. In buildout-zeo.cfg
342  you can care for this by creating a new ``[zeoN_ini]`` and
343  ``[zeoN_conf]`` option (replacing ``N`` with a number, of course).
344
345  Just copy over existing entries and replace the mentions of ``zeo1``
346  or ``zeo2`` by your ``zeoN``.
347
348* 2.2. Create a new ``zeo_clientN`` entry
349
350  Then you have to create an entry that will generate the
351  ``zeo_clientN`` script. Again, just copy over an existing
352  ``[zeo_client1]`` entry and replace ``1`` withg your client number.
353
354* 2.3. Register the new sections in ``[buildout]`` section
355
356  When done with the above: add the new section in ``[buildout]``::
357
358    [buildout]
359      ...
360      <old entries...>
361      ...
362      zope_conf_zeo_5
363      zeo5_ini
364      zeo_client5
365
366  depending on how you named your new sections.
367
3683. Rerun ``buildout``
369---------------------
370
371When adding or removing client/server instances, make sure to stop all
372running servers/clients before rerunning buildout.
373
374To activate the new setup, rerun buildout::
375
376  $ bin/buildout -c buildout-zeo.cfg
377
378This should generate any new clients and remove older ones or just
379update configuration files.
380
381
382Considerations
383==============
384
385There are some things in the current buildout-zeo.cfg we might do not
386want. It extends the regular ``buildout.cfg`` so that we do not have
387to repeat most sections but the ``parts`` in ``[buildout]`` have to be
388listed.
389
390We need, however, not everything with a ZEO-deploy that is listed in a
391default buildout. We might do not need docs, no profiling, etc. Also a
392regular non-ZEO kofactl might not make to much sense. Therefore all
393this might be subject to changes.
394
395.. _Debian: http://www.debian.org/
396.. _Grok: http://grok.zope.org/
397.. _Python: http://www.python.org/
398.. _Ubuntu: http://www.ubuntu.com/
399.. _virtualenv: http://www.virtualenv.org/en/latest/
400.. _WAeUP: https://www.waeup.org/
401.. _Zope: http://www.zope.org/
402.. _zc.buildout: http://cheeseshop.python.org/pypi/zc.buildout
Note: See TracBrowser for help on using the repository browser.