1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
****** GUI Installation ******
These steps assume that you have already installed and configured the other CA
tools.
rpki-manage is a shell script wrapper around the django-admin command which
sets $PYTHONPATH and $DJANGO_SETTINGS_MODULE.
***** Prerequisites *****
* Django 1.4 (Django 1.5 is not currently supported)
* Django South 0.7.6 or later
* Apache 2
* mod_wsgi 3
***** Upgrading from a Previous Release *****
If you had previously installed the web portal before the database migration
support was added, you will need to take some additional steps.
**** Sync databases ****
$ rpki-manage syncdb
Note that at the end of the syncdb output you will see the following message:
Not synced (use migrations):
- rpki.gui.app
(use ./manage.py migrate to migrate these)
You should ignore the message about running ./manage.py since that script does
not exist in our setup.
**** Database Migration ****
If you have not previously run the new database migration step, you will need
to run this command. Note that you only need to run this command the first time
you upgrade.
$ rpki-manage migrate app 0001 --fake
If you are unsure whether or not you have previously run this command, you can
verify with the following command:
$ rpki-manage migrate --list
app
(*) 0001_initial
(*) 0002_auto__add_field_resourcecert_conf
(*) 0003_set_conf_from_parent
(*) 0004_auto__chg_field_resourcecert_conf
(*) 0005_auto__chg_field_resourcecert_parent
( ) 0006_add_conf_acl
( ) 0007_default_acls
The migrations are an ordered list. The presence of the asterisk (*) indicates
that the migration has already been performed. ( ) indicates that the specific
migration has not yet been applied. In the example above, migrations 0001
through 0005 have been applied, but 0006 and 0007 have not.
Now bring your database up to date with the current release:
$ rpki-manage migrate app
From this point on you will just need to run the latter command every time you
upgrade.
Restart apache
$ apachectl restart
***** New Installation *****
**** Create the initial tables ****
$ rpki-manage syncdb
Answer "yes" when asked if you want to create superuser Enter username for
superuser Enter password
Note that at the end of the syncdb output you will see the following message:
Not synced (use migrations):
- rpki.gui.app
(use ./manage.py migrate to migrate these)
You should ignore the message about running ./manage.py since that script does
not exist in our setup.
If you need to create superuser at a later time, you can run
$ rpki-manage createsuperuser
If you need to change superuser's password
$ rpki-manage changepassword <username>
**** Perform Database Migration ****
If there were any changes to the database schema, this command will bring your
existing database up to date with the current software.
$ rpki-manage migrate app
***** Configure Apache *****
Now configure apache, using /usr/local/etc/rpki/apache.conf, e.g.
$ cp apache.conf /usr/local/etc/apache22/Includes/rpki.conf
On Ubuntu this will be
$ cp apache.conf /etc/apache2/conf.d/rpki.conf
You can put it in a virtual host if you wish.
Restart apache
$ apachectl restart
Go to the URL for your web server and enter the superuser and password in login
form.
If you've only done the above bootstrap, there will only be a single handle to
manage, so the GUI will automatically bring you to the dashboard for that
handle.
**** Running the web portal as a different user ****
By default, the web portal is run in embedded mode in mod_wsgi, which means it
runs inside the apache process. However, you can make the web portal run in
daemon mode as a different user using mod_wsgi.
$ ./configure --enable-wsgi-daemon-mode[=user[:group]]
Where user is the optional user to run the web portal as, and group is the
optional group to run the web portal as. If user is not specified, it will run
in a separate process but the same user as apache is configured to run.
Note that when run in daemon mode, a unix domain socket will be created in the
same directory as the apache log files. If the user you have specified to run
the web portal as does not have permission to read a file in that directory,
the web interface will return a 500 Internal Server Error and you will see a
permission denied error in your apache logs. The solution to this is to use the
WSGISocketPrefix apache configuration directive to specify an alternative
location, such as:
WSGISocketPrefix /var/run/wsgi
Note that this directive must not be placed inside of the VirtualHost section.
It must be located at the global scope.
see http://code.google.com/p/modwsgi/wiki/
ConfigurationDirectives#WSGISocketPrefix for more information.
****** Installation of Route Views Support for the GUI ******
If you want ROA creation to tell the user what routes are in the global routing
table for what they are about to create,
Be sure you have curl installed. On FreeBSD it is in /usr/ports/ftp/curl
Install a script such as the following as /usr/locl/bin/do-routeviews
#!/bin/sh
# Fetch the full bgp dump from routeviews.org and update the web
# portal's database
i=oix-full-snapshot-latest.dat.bz2
o=/tmp/$i
curl -s -S -o $o http://archive.routeviews.org/oix-route-views/$i
if [ $? -eq 0 ]; then
/usr/local/sbin/rpkigui-import-routes -l error $o
fi
and create an entry in root's crontab such as
30 */2 * * * root /usr/local/sbin/do-routeviews
If you want the GUI's "routes" page to see ROAs when you click those buttons,
you will need to run rcynic. see the instructions for setting up rcynic.
If you are running rootd, you may want to run with only your local trust
anchor. In this case, to have the GUI be fairly responsive to changes, you may
want to run the rcynic often. In this case, you may want to look at the value
of jitter in rcynic.conf.
In addition, your rcynic script should also have
/usr/local/sbin/rpkigui-rcynic -l error
after the rcynic run.
****** Expiration Checking ******
The web portal can notify users when it detects that RPKI certificates will
expire in the near future. Run the following script as a cron job, perhaps once
a night:
/usr/local/sbin/rpkigui-check-expired
By default it will warn of expiration 14 days in advance, but this may be
changed by using the -t command line option and specifying how many days in
advance to check.
****** Using the GUI ******
****** GUI Examples ******
***** Logging in to the GUI *****
01-login.jpg
***** The Dashboard - Let's Make a ROA *****
02-dashboard.jpg
***** ROA List Currently Empty, So Let's Create One *****
03-roas.jpg
***** Choose an AS and Prefix - Let MaxLen? Default *****
04-create-roa.jpg
***** What Will the Consequences Be? - Confirm OK *****
05-are-you-sure.jpg
***** Now We Can See ROAs - Let's Look at Routes *****
06-roa-list.jpg
***** Real Effect on Routing Table *****
07-route view.jpg
***** Ghostbusters etc. are Similar *****
****** User Management ******
The web portal uses a model where users are distinct from resource holders. A
user is authorized to log into the web portal, and may be granted permission to
manage zero or more resource holders. The same name may be used as both a user
and resource holder for simple cases where there is a one-to-one mapping.
|
