Since 1.0.0, this project updates like any other project. First, update the source code, if you use git:
git pull origin master
or if you installed django-ca via pip:
pip install -U django-ca
then upgrade with these commands:
pip install -U -r requirements.txt python ca/manage.py migrate # if you use the webinterface python ca/manage.py collectstatic
If you installed django-ca in a virtualenv, don’t forget to activate it before executing any python or pip commands using:
Update to 1.12.0 or later¶
If you also want to switch to a different storage system (e.g. from django-storages), switch to relative paths everywhere first, then migrate to the new storage system by configuring CA_FILE_STORAGE and copying all files to the new location.
The old way of accessing files works until (and including) version 1.14.
In most cases, you will be able to migrate using a simple manage.py command:
$ python manage.py migrate_ca <serial>: Updating <old path> to <new path>.
If you have stored some private keys outside of the filesystem, you will need to force them being moved into the directory configured by CA_DIR:
$ python manage.py migrate_ca <serial>: <old path> is not in a subdir of <CA dir>. Use --force to move files. $ python manage.py migrate_ca --force <serial>: Move <old path> to <CA dir>.
Note that this command can safely be executed multiple times if some migrations didn’t work (e.g. because of missing permissions) the first time.
Migrate OCSP responder¶
If you have configured a manual OCSP responder, you have to move the files into the directory referenced by
CA_DIR (if they’re not there already) and update
responder_cert to a relative path.
You can test your configuration change invoking
python manage.py shell and running:
>>> import os >>> from django_ca import ca_settings >>> from django_ca.utils import read_file >>> ca_settings.CA_DIR '/home/example/django-ca/ca/files' >>> responder_key = 'responder/responder.key' # this the same as "responder_key" in your OCSP view >>> absolute_path = os.path.join(ca_settings.CA_DIR, responder_key) >>> os.path.exists(absolute_path) # test that <CA_DIR>/<responder_key> exists True >>> read_file(responder_key) '-----BEGIN CERTIFICATE----- ...'
Update from 1.0.0b2¶
If you’re updating from a version earlier then 1.0.0 (which was the first real release), you have to first update to 1.0.0.b1 (see below), then to 1.0.0.b2, apply all migrations and reset existing migrations Since all installed instances were probably private, it made sense to start with a clean state.
To update from an earlier git-checkout, to:
Upgrade to version 1.0.0b2
Apply all migrations.
Upgrade to version 1.0.0
Remove old migrations from the database:
python manage.py dbshell > DELETE FROM django_migrations WHERE app='django_ca';
Fake the first migration:
python manage.py migrate django_ca 0001 –fake
Update from pre 1.0.0b1¶
Prior to 1.0.0, this app was not intended to be reusable and so had a generic name. The app was renamed to django_ca, so it can be used in other Django projects (or hopefully stand-alone, someday). Essentially, the upgrade path should work something like this:
# backup old data: python manage.py dumpdata certificate --indent=4 > certs.json # update source code git pull origin master # create initial models in the new app, but only the initial version! python manage.py migrate django_ca 0001 # update JSON with new model name sed 's/"certificate.certificate"/"django_ca.certificate"/' > certs-updated.json # load data python manage.py loaddata certs-updated.json # apply any other migrations python manage.py migrate