root / README.admin @ 404ccab2
History | View | Annotate | Download (3 kB)
1 |
README.admin - Administration notes |
---|---|
2 |
|
3 |
This file contains notes related to administration of a working Synnefo |
4 |
deployment. This document should be read *after* README.deploy, which contains |
5 |
step-by-step Synnefo deployment instructions. |
6 |
|
7 |
|
8 |
Database |
9 |
======== |
10 |
|
11 |
MySQL: manage.py dbshell seems to ignore the setting of 'init_command' |
12 |
in settings.DATABASES |
13 |
|
14 |
|
15 |
Reconciliation mechanism |
16 |
======================== |
17 |
|
18 |
On certain occasions, such as a Ganeti or RabbitMQ failure, the VM state in the |
19 |
system's database may differ from that in the Ganeti installation. The |
20 |
reconciliation process is designed to bring the system's database in sync with |
21 |
what Ganeti knows about each VM, and is able to detect the following three |
22 |
conditions: |
23 |
|
24 |
* Stale DB servers without corresponding Ganeti instances |
25 |
* Orphan Ganeti instances, without corresponding DB entries |
26 |
* Out-of-sync operstate for DB entries wrt to Ganeti instances |
27 |
|
28 |
The reconciliation mechanism runs as a management command, e.g., as follows: |
29 |
[PYTHONPATH needs to contain the parent of the synnefo Django project |
30 |
directory]: |
31 |
|
32 |
/srv/synnefo$ export PYTHONPATH=/srv:$PYTHONPATH |
33 |
vkoukis@dev67:~/synnefo [reconc]$ ./manage.py reconcile --detect-all -v 2 |
34 |
|
35 |
Please see ./manage.py reconcile --help for all the details. |
36 |
|
37 |
The administrator can also trigger reconciliation of operating state manually, |
38 |
by issuing a Ganeti OP_INSTANCE_QUERY_DATA command on a Synnefo VM, using |
39 |
gnt-instance info. |
40 |
|
41 |
|
42 |
Logging |
43 |
======= |
44 |
|
45 |
Logging in Synnefo is using Python's logging module. The module is configured |
46 |
using a configuration file, whose format is described here: |
47 |
|
48 |
http://docs.python.org/library/logging.config.html |
49 |
|
50 |
By default, the log initialization code will look for the logging.conf file |
51 |
in the following locations in order: |
52 |
|
53 |
1. /etc/synnefo/logging.conf |
54 |
2. os.getcwd()/logging.conf |
55 |
3. synnefo.logic.__path__[0]/logging.conf (<-- this is the default) |
56 |
|
57 |
The default configuration is using Linux conventions: it logs to /dev/log for |
58 |
all loggers. The default configuration can be changed by copying the default |
59 |
file to any of the above mentioned locations and changing it appropriately. |
60 |
|
61 |
* Logging and demonization: If the logging is configured to print to the console |
62 |
(using the consoleHandler handler) then daemon processes (notably, the |
63 |
dispatcher) will not work as it should. This only happens after the daemon |
64 |
has lost its controlling terminal (e.g. because the terminal was closed); |
65 |
in this case the dispatcher does not know where to log to and depending on |
66 |
the system it either crashes or stalls. This can be avoided if the logging |
67 |
module is not configured to output to the console. |
68 |
|
69 |
|
70 |
Admin Tools |
71 |
=========== |
72 |
|
73 |
snf-admin is a tool used to perform various administrative tasks. It needs to |
74 |
be able to access the django database, so the following should be able to import |
75 |
the Django settings. |
76 |
|
77 |
Additionally, administrative tasks can be performed via the admin web interface |
78 |
located in /admin. Only users of type ADMIN can access the admin pages. To change |
79 |
the type of a user to ADMIN, snf-admin can be used: |
80 |
|
81 |
snf-admin user modify 42 --type ADMIN |