aboutsummaryrefslogtreecommitdiff
path: root/scripts/testdb.sql
blob: 7b3f80b3704645230b4a9ee8e39afc74b05f785c (plain) (blame)
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
-- $Id$
--
-- Run this manually under the MySQL CLI to set up databases for testdb.py.
-- testdb.py doesn't do this automatically because it requires privileges
-- that testdb.py doesn't (or at least shouldn't) have.

CREATE DATABASE irdb0;
CREATE DATABASE irdb1;
CREATE DATABASE irdb2;
CREATE DATABASE irdb3;
CREATE DATABASE irdb4;
CREATE DATABASE irdb5;
CREATE DATABASE irdb6;
CREATE DATABASE irdb7;
CREATE DATABASE irdb8;
CREATE DATABASE irdb9;
CREATE DATABASE irdb10;
CREATE DATABASE irdb11;

CREATE DATABASE rpki0;
CREATE DATABASE rpki1;
CREATE DATABASE rpki2;
CREATE DATABASE rpki3;
CREATE DATABASE rpki4;
CREATE DATABASE rpki5;
CREATE DATABASE rpki6;
CREATE DATABASE rpki7;
CREATE DATABASE rpki8;
CREATE DATABASE rpki9;
CREATE DATABASE rpki10;
CREATE DATABASE rpki11;

GRANT ALL ON irdb0.* TO irdb@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON irdb1.* TO irdb@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON irdb2.* TO irdb@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON irdb3.* TO irdb@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON irdb4.* TO irdb@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON irdb5.* TO irdb@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON irdb6.* TO irdb@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON irdb7.* TO irdb@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON irdb8.* TO irdb@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON irdb9.* TO irdb@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON irdb10.* TO irdb@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON irdb11.* TO irdb@localhost IDENTIFIED BY 'fnord';

GRANT ALL ON rpki0.* TO rpki@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON rpki1.* TO rpki@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON rpki2.* TO rpki@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON rpki3.* TO rpki@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON rpki4.* TO rpki@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON rpki5.* TO rpki@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON rpki6.* TO rpki@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON rpki7.* TO rpki@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON rpki8.* TO rpki@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON rpki9.* TO rpki@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON rpki10.* TO rpki@localhost IDENTIFIED BY 'fnord';
GRANT ALL ON rpki11.* TO rpki@localhost IDENTIFIED BY 'fnord';
.xml you supplied as input. This registers your data with the parent, including BPKI cross-registration, and generates a return message containing your parent's BPKI trust anchors, a service URL for contacting your parent via the "up-down" protocol, and (usually) either an offer of publication service (if your parent operates a repository) or a referral from your parent to whatever publication service your parent does use. Referrals include a CMS-signed authorization token that the repository operator can use to determine that your parent has given you permission to home underneath your parent in the publication tree. * Each of your parents sends (...) back the response XML file generated by the "configure_child" command. * You feed the response message you just got into myrpki using the "configure_parent" command. This registers the parent's information in your database, including BPKI cross-certification, and processes the repository offer or referral to generate a publication request message. * You send (...) the publication request message to the repository. The contact_info element in the request message should (in theory) provide some clue as to where you should send this. * The repository operator processes your request using myrpki's "configure_publication_client" command. This registers your information, including BPKI cross-certification, and generates a response message containing the repository's BPKI trust anchor and service URL. * Repository operator sends (...) the publication confirmation message back to you. * You process the publication confirmation message using myrpki's "configure_repository" command. At this point you should, in theory, have established relationships, exchanged trust anchors, and obtained service URLs from all of your parents and repositories. The last setup step is establishing a relationship with your RPKI service host, if you're not self-hosted, but as this is really just the first message of an ongoing exchange with your host, it's handled by the data maintenance commands. The two commands used in data maintenence phase are "configure_resources" and "configure_daemons". The first is used by the resource holder, the second is used by the host. In the self-hosted case, it is not necessary to run "configure_resources" at all, myrpki will run it for you automatically. Hosted case The basic steps involved in getting started for a resource holder who is being hosted by somebody else are: * Run through steps listed in the_myrpki_overview_section. * Run the configure_resources command to generate myrpki.xml. * Send myrpki.xml to the rpkid operator who will be hosting you. * Wait for your rpkid operator to ship you back an updated XML file containing a PKCS #10 certificate request for the BPKI signing context (BSC) created by rpkid. * Run configure_resources again with the XML file you just received, to issue the BSC certificate and update the XML file again to contain the newly issued BSC certificate. * Send the updated XML file back to your rpkid operator. At this point you're done with initial setup. You will need to run configure_resources again whenever you make any changes to your configuration file or CSV files. Warning: Once myrpki knows how to update BPKI CRLs, you will also need to run configure_resources periodically to keep your BPKI CRLs up to date. Any time you run configure_resources myrpki, you should send the updated XML file to your rpkid operator, who should send you a further updated XML file in response. Self-hosted case The first few steps involved in getting started for a self-hosted resource holder (that is, a resource holder that runs its own copy of rpkid) are the same as in the hosted_case above; after that the process diverges. The [current] steps are: * Follow the basic installation instructions in the_Installation_Guide to build the RFC-3779-aware OpenSSL code and associated Python extension module. * Run through steps listed in the_myrpki_overview_section. * Set up the MySQL databases that rpkid et al will use. The package includes a tool to do this for you, you can use that or do the job by hand. See MySQL database_setup for details. * If you are running your own publication repository (that is, if you are running pubd), you will also need to set up an rsyncd server or configure your existing one to serve pubd's output. There's a sample configuration file in $top/rpkid/examples/rsyncd.conf, but you may need to do something more complicated if you are already running rsyncd for other purposes. See the rsync(1) and rsyncd.conf(5) manual pages for more details. * Start the daemons. You can use $top/rpkid/rpki-start-servers.py to do this, or write your own script. If you intend to run pubd, you should make sure that the directory you specified as publication_base_directory exists and is writable by the userid that will be running pubd, and should also make sure to start rsyncd. * Run myrpki's configure_daemons command, twice, with no arguments. You need to run the command twice because myrpki has to ask rpkid to create a keypair and generate a certification request for the BSC. The first pass does this, the second processes the certification request, issues the BSC, and loads the result into rpkid. [Yes, we could automate this somehow, if necessary.] At this point, if everything went well, rpkid should be up, configured, and starting to obtain resource certificates from its parents, generate CRLs and manifests, and so forth. At this point you should go figure out how to use the relying party tool, rcynic: see $top/rcynic/README if you haven't already done so. If and when you change your CSV files, you should run configure_daemons again to feed the changes into the daemons. Hosting case If you are running rpkid not just for your own resources but also to host other resource holders (see hosted_case above), your setup will be almost the same as in the self-hosted case (see self-hosted_case, above), with one procedural change: you will need to tell configure_daemons to process the XML files produced by the resource holders you are hosting. You do this by specifying the names of all those XML files on as arguments to the configure_daemons command. So, if you are hosting two friends, Alice and Bob, then, everywhere the instructions for the self-hosted case say to run configure_daemons with no arguments, you will instead run it with the names of Alice's and Bob's XML files as arguments. Note that configure_daemons sometimes modifies these XML files, in which case it will write them back to the same filenames. While it is possible to figure out the set of circumstances in which this will happen (at present, only when myrpki has to ask rpkid to create a new BSC keypair and PKCS #10 certificate request), it may be easiest just to ship back an updated copy of the XML file after every you run configure_daemons. "Pure" hosting case In general we assume that anybody who bothers to run rpkid is also a resource holder, but the software does not insist on this. Todo: Er, well, rpkid doesn't, but myrpki now does -- "pure" hosting was an unused feature that fell by the wayside while simplifying the user interface. It would be relatively straightforward to add it back if we ever need it for anything, but the mechanism it used to use no longer exists -- the old [myirbe] section of the config file has been collapsed into the [myrpki] section, so testing for existance of the [myrpki] section no longer works. So we'll need an explicit configuration option, no big deal, just not worth chasing now. A (perhaps) plausible use for this capability would be if you are an rpkid- running resource holder who wants for some reason to keep the resource-holding side of your operation completely separate from the rpkid-running side of your operation. This is essentially the pure-hosting model, just with an internal hosted entity within a different part of your own organization. Troubleshooting If you run into trouble setting up this package, the first thing to do is categorize the kind of trouble you are having. If you've gotten far enough to be running the daemons, check their log files. If you're seeing Python exceptions, read the error messages. If you're getting TLS errors, check to make sure that you're using all the right BPKI certificates and service contact URLs. TLS configuration errors are, unfortunately, notoriously difficult to debug, because connection failures due to misconfiguration happen early, deep in the guts of the OpenSSL TLS code, where there isn't enough application context available to provide useful error messages. If you've completed the steps above, everything appears to have gone OK, but nothing seems to be happening, the first thing to do is check the logs to confirm that nothing is actively broken. rpkid's log should include messages telling you when it starts and finishes its internal "cron" cycle. It can take several cron cycles for resources to work their way down from your parent into a full set of certificates and ROAs, so have a little patience. rpkid's log should also include messages showing every time it contacts its parent(s) or attempts to publish anything. rcynic in fully verbose mode provides a fairly detailed explanation of what it's doing and why objects that fail have failed. You can use rsync (sic) to examine the contents of a publication repository one directory at a time, without attempting validation, by running rsync with just the URI of the directory on its command line: $ rsync rsync://rpki.example.org/where/ever/ Known Issues The lxml package provides a Python interface to the Gnome libxml2 and libxslt C libraries. This code has been quite stable for several years, but initial testing with lxml compiled and linked against a newer version of libxml2 ran into problems (specifically, gratuitous RelaxNG schema validation failures). libxml2 2.7.3 worked; libxml2 2.7.5 did not work on the test machine in question. Reverting to libxml2 2.7.3 fixed the problem. Rewriting the two lines of Python code that were triggering the lxml bug appears to have solved the problem, so the code now works properly with libxml 2.7.5, but if you start seeing weird XML validation failures, it might be another variation of this lxml bug. An earlier version of this code ran into problems with what appears to be an implementation restriction in the the GNU linker ("ld") on 64-bit hardware, resulting in obscure build failures. The workaround for this required use of shared libraries and is somewhat less portable than the original code, but without it the code simply would not build in 64-bit environments with the GNU tools. The current workaround appears to behave properly, but the workaround requires that the pathname to the RFC-3779-aware OpenSSL shared libraries be built into the _POW.so Python extension module. If necessary, you can override this by setting the LD_LIBRARY_PATH environment variable, see the ld.so man page for details. This is a relatively minor variation on the usual build issues for shared libraries, it's just annoying because shared libraries should not be needed here and would not be if not for this GNU linker issue.