Age | Commit message (Collapse) | Author |
|
for portability. With this change, the GUI appears to work with SQLite3.
svn path=/branches/tk705/; revision=6155
|
|
under yamltest. No obvious way to tell Django's CSRF protection to
allow this, not entirely sure we'd want to do so even if we could.
svn path=/branches/tk705/; revision=6154
|
|
running with new code base. Now working with
$ yamltest.py --sql mysql --gui smoketest.1.yaml
svn path=/branches/tk705/; revision=6153
|
|
or commenting conventions should be shot. If it so happens that it is
inconvenient to shoot him, then he is to be politely requested to recode
his program in adherence to the above standard."
-- Michael Spier, Digital Equipment Corporation
svn path=/branches/tk705/; revision=6152
|
|
postgresql sort of works with the core daemons and rpkic, well enough
to generate RPKI objects if one hand configures it, but one can't even
run migrations for the GUI, due to a few non-portable SQL data types,
and migrations from earlier version of the IRDB have similar problems.
svn path=/branches/tk705/; revision=6151
|
|
operations, so simplify code and schema by removing gratuitous
transformations to and from binary format.
svn path=/branches/tk705/; revision=6150
|
|
backend. Switch yamltest's default database configuration to sqlite3.
MySQL still has character set issues, which are almost certainly to do
with the communication channel rather than the database tables. It's
possible that one of the newer DB API drivers for MySQL fixes this,
might be worth trying one of them at some point (see the "MySQL notes"
discussion of MySQL DB API drivers in the Django documentation).
svn path=/branches/tk705/; revision=6149
|
|
database, so the garbage collector can clean it up automatically.
svn path=/branches/tk705/; revision=6148
|
|
else.
svn path=/branches/tk705/; revision=6147
|
|
incorrectly coded UTF-8 in BLOB fields holding ASN.1 DER data. This
is wrong in so many ways that I don't even know where to start, but,
bottom line, forcing Latin1 here is just making MySQL 5.6+ revert to
the behavior in MySQL 5.5.
This is just a workaround. The real solution is probably to switch to
an SQL engine that's not quite such a kludge tower.
svn path=/branches/tk705/; revision=6146
|
|
helped the MySQL UTF-8 whining. Same Python code running with MySQL
5.5 doesn't do this, so it's some kind of upgrade trainwreck.
BinaryField uses BLOBs too, just as one would expect, so in theory
this can't be happening. So it's an undocumented feature. Yum.
But we wanted to move to BinaryField anyway, and doing so doesn't seem
to have made the problem worse, so committing the changes.
svn path=/branches/tk705/; revision=6145
|
|
up-down protocol specification and, more importantly, avoid spurious
CMS Replay errors.
svn path=/branches/tk705/; revision=6144
|
|
UTF-8 whining on what are supposed to be binary fields that's probably
the result of a MySQL upgrade, and CMS Replay exceptions due to the
pseudo-random order in which HTTP client connections run in Tornado.
The UTF-8 mess is probably a good reason to change over to Django's
native binary field type, which we were going to want to do anyway.
The CMS Replay problem is not Tornado's fault: we probably would have
seen it in the old code were it not for an accidental side effect of a
long-since-abandoned attempt to use persistent HTTP connections. The
fix is probably to serialize requests to a particular host using use a
tornaodo.queue.Queue() object, or something like that.
svn path=/branches/tk705/; revision=6143
|
|
were ordinary functions. May want some kind of naming scheme or other
convention to make it easier to avoid this sort of thing.
svn path=/branches/tk705/; revision=6142
|
|
so on a faster machine.
svn path=/branches/tk705/; revision=6141
|
|
svn path=/branches/tk705/; revision=6140
|
|
quite working perfectly yet (cron is a bit wonky) but manages to
produce an initial set of ROAs without thowing any exceptions, and
code is already much cleaner than the old callback-based horror.
svn path=/branches/tk705/; revision=6139
|
|
svn path=/branches/tk705/; revision=6138
|
|
svn path=/branches/tk705/; revision=6137
|
|
svn path=/branches/tk705/; revision=6136
|
|
svn path=/branches/tk705/; revision=6135
|
|
bad choice for something implemented in Python, holdover from an older
specification, but Django ORM's troubles with "self" as a keyword
argument were the last straw. Enough already. Backwards
compatability should be a straightforward data migration.
svn path=/branches/tk705/; revision=6134
|
|
presence of namespace-using content: removes unnecessary prefixes,
while retaining those required for this particular output.
svn path=/branches/tk705/; revision=6133
|
|
svn path=/branches/tk705/; revision=6132
|
|
"myrpki" to new IETF standards track I-D syntax.
svn path=/branches/tk705/; revision=6131
|
|
svn path=/branches/tk705/; revision=6130
|
|
svn path=/branches/tk705/; revision=6129
|
|
svn path=/branches/tk705/; revision=6128
|
|
Django ORM. Duct tape and bailing wire everywhere, much clean-up left
to do, but basic "make yamltest" suite runs. Much of the clean-up
isn't worth doing until after revamping the I/O system, as it'll all
change again at that point anyway.
svn path=/branches/tk705/; revision=6127
|
|
svn path=/branches/tk705/; revision=6126
|
|
colors to the mast as far as Python and Django versions goes.
svn path=/branches/tk705/; revision=6125
|
|
svn path=/branches/tk705/; revision=6124
|
|
svn path=/branches/tk705/; revision=6123
|
|
svn path=/branches/tk705/; revision=6122
|
|
svn path=/branches/tk705/; revision=6121
|
|
left-right protocol and irdb and rpkidb models.
Not fully working yet, RRDP URI isn't yet showing up everywhere it
should, but this is probably more an indication that the previous hack
was incomplete than that the replacement broke something.
svn path=/branches/tk705/; revision=6120
|
|
configuration protocol instead of the crufty ancient "myrpki" version.
Semantics largely unchanged, differences are primarily syntax and
cleanup of historical baggage, but only the new protocol includes RRDP
support, which we're gonna need.
At some point we should write XSL transforms that map between the
useful portions of the old protocol and the modern equivalent.
svn path=/branches/tk705/; revision=6119
|
|
coding practice.
svn path=/branches/tk705/; revision=6118
|
|
from an etree_wrapper object, bypassing the filesystem entirely.
svn path=/branches/tk705/; revision=6117
|
|
svn path=/branches/tk705/; revision=6116
|
|
svn path=/branches/tk705/; revision=6115
|
|
svn path=/branches/tk705/; revision=6114
|
|
svn path=/branches/tk705/; revision=6113
|
|
svn path=/branches/tk705/; revision=6112
|
|
"From " line in case that's what's been giving the IRR code indigestion.
svn path=/trunk/; revision=6111
|
|
XML-related voodoo for models exposed in the left-right protocol.
svn path=/branches/tk705/; revision=6110
|
|
svn path=/branches/tk705/; revision=6109
|
|
rpki.left_right and start pruning the result down to figure out how
much really needs to be ported over to the new models.
svn path=/branches/tk705/; revision=6108
|
|
At this point, all the classes remaining in rpki.left_right pertain
are the pre-Django equivalents of models, and they're the only things
left still using rpki.xml_utils.
Some old test code remains broken (not yet converted). GUI code that
I know about has been converted but not tested (not all that much to
convert there, mostly the GUI just invokes the Zookeeper.
svn path=/branches/tk705/; revision=6107
|
|
rpki.left_right classes.
svn path=/branches/tk705/; revision=6106
|