dragonresearch / rpki.net

Dragon Research Labs rpki.net RPKI toolkit
54 stars 26 forks source link

Upon purge (debian) of rpki-ca/rpki-rp errors in the postgresql bits #840

Open sraustein opened 8 years ago

sraustein commented 8 years ago

(Reading database ... 47096 files and directories currently installed.) Removing rpki-ca (0.6442~jessie) ... RPKI Apache configuration: platform "Debian", action "remove" Removing /etc/rpki/apache.conf.sample Removing /etc/apache2/sites-available/rpki.conf Running a2dissite rpki removing dangling symlink /etc/apache2/sites-enabled/rpki.conf Running service apache2 restart Purging configuration files for rpki-ca (0.6442~jessie) ... dpkg: warning: while removing rpki-ca, directory '/usr/share/rpki/rrdp-publication' not empty so not removed dpkg: warning: while removing rpki-ca, directory '/usr/share/rpki/publication' not empty so not removed Removing rpki-rp (0.6442~jessie) ... Initialized PostgreSQL driver, pw pwd.struct_passwd(pw_name='postgres', pw_passwd='x', pw_uid=108, pw_gid=114, pw_gecos='PostgreSQL administrator,,,', pw_dir='/var/lib/postgresql', pw_shell='/bin/bash') Purging configuration files for rpki-rp (0.6442~jessie) ... DROP DATABASE DO psql:/etc/rpki/drop_databases.sql:10: NOTICE: database "rpki" does not exist, skipping DROP DATABASE psql:/etc/rpki/drop_databases.sql:18: NOTICE: role "rpki" does not exist, skipping CONTEXT: SQL statement "DROP ROLE IF EXISTS rpki" PL/pgSQL function inline_code_block line 6 at SQL statement DO psql:/etc/rpki/drop_databases.sql:19: NOTICE: database "rpki" does not exist, skipping DROP DATABASE psql:/etc/rpki/drop_databases.sql:27: NOTICE: role "rpki" does not exist, skipping CONTEXT: SQL statement "DROP ROLE IF EXISTS rpki" PL/pgSQL function inline_code_block line 6 at SQL statement DO psql:/etc/rpki/drop_databases.sql:28: NOTICE: database "rpki" does not exist, skipping DROP DATABASE psql:/etc/rpki/drop_databases.sql:36: NOTICE: role "rpki" does not exist, skipping CONTEXT: SQL statement "DROP ROLE IF EXISTS rpki" PL/pgSQL function inline_code_block line 6 at SQL statement DO

These are probably harmless? but I'm not sure at this point and figure speaking up is good practice.

Trac ticket #834 component rpkid priority minor, owner None, created by morrowc on 2016-06-27T14:23:01Z, last modified 2016-06-27T17:59:22Z

sraustein commented 8 years ago

Make sure you have the latest tk705/, rpki-rp, and rpki-ca packages installed. If you just installed, you can ignore this. But, if you have been running for a while, you may need to purge and reinstall to clear an upgrade error:

{{{

systemctl stop rpki-ca

killall -u rpki

apt-get update

apt-get purge rpki-ca rpki-rp

apt-get install rpki-rp rpki-ca

}}} The systemctl stop should shut down the servers. The killall is paranoia in case some cron job happens to be using the database at exactly the wrong moment -- PostgreSQL won't let you drop the database while any process has it open.

If you do the upgrade, you will have to go back and reconfigure the CA as above in
[https://wiki.rg.net/wiki/RPKItmp#CAConfiguration-rpki.conf CA Configuration]

=== The !Upgrade/Migration Sequence ===

The upgrade itself needs to take place with the servers disabled, and includes a bit of additional voodoo (notes below):

If you're running as root, you can omit any sudo which isn't immediately followed by a -u rpki.

In case the upgrade/install restarted the daemons, we need to kill them again. {{{

systemctl stop rpki-ca

killall -u rpki

}}}

The rm, database drop, install, and database create are just wiping the state already present from the install and whatever testing you did, so we can start fresh. {{{

rm -rf /usr/share/rpki/.{tal,cer} /usr/share/rpki/publication/ /usr/share/rpki/rrdp-publication/* /var/log/rpki/*

rpki-sql-setup --postgresql-root-username postgres drop

install -d -o rpki -g rpki /var/run/rpki /var/log/rpki /usr/share/rpki/publication /usr/share/rpki/rrdp-publication

rpki-sql-setup --postgresql-root-username postgres create

}}}

The Django migrations are needed to rebuild the database schemas after the drop and create cycle. {{{

sudo -u rpki rpki-manage migrate rpkidb --settings rpki.django_settings.rpkid --no-color

sudo -u rpki rpki-manage migrate pubdb --settings rpki.django_settings.pubd --no-color

sudo -u rpki rpki-manage migrate irdb --settings rpki.django_settings.irdb --no-color

sudo -u rpki rpki-manage migrate --settings rpki.django_settings.gui --no-color

}}}

These produced the only significant output {{{

sudo -u rpki rpki-manage migrate rpkidb --settings rpki.django_settings.rpkid --no-color

Operations to perform: Apply all migrations: rpkidb Running migrations: Rendering model states... DONE Applying rpkidb.0001_initial... OK Applying rpkidb.0002_root... OK

sudo -u rpki rpki-manage migrate pubdb --settings rpki.django_settings.pubd --no-color

Operations to perform: Apply all migrations: pubdb Running migrations: Rendering model states... DONE Applying pubdb.0001_initial... OK Applying pubdb.0002_auto_20160221_0617... OK Applying pubdb.0003_remove_delta_xml... OK

sudo -u rpki rpki-manage migrate irdb --settings rpki.django_settings.irdb --no-color

Operations to perform: Apply all migrations: irdb Running migrations: Rendering model states... DONE Applying irdb.0001_initial... OK

sudo -u rpki rpki-manage migrate --settings rpki.django_settings.gui --no-color

Operations to perform: Synchronize unmigrated apps: staticfiles, routeview Apply all migrations: rcynicdb, sessions, app, auth, contenttypes, gui_rpki_cache, irdb Synchronizing apps without migrations: Creating tables... Creating table routeview_routeorigin Creating table routeview_routeoriginv6 Running deferred SQL... Installing custom SQL... Running migrations: Rendering model states... DONE Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying app.0001_initial... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying gui_rpki_cache.0001_initial... OK Applying gui_rpki_cache.0002_auto_20160411_2311... OK Applying gui_rpki_cache.0003_auto_20160420_2146... OK Applying rcynicdb.0001_initial... OK Applying rcynicdb.0002_auto_20160227_2003... OK Applying rcynicdb.0003_auto_20160301_0333... OK Applying sessions.0001_initial... OK }}}

Trac comment by randy on 2016-06-27T14:26:37Z

sraustein commented 8 years ago

At Mon, 27 Jun 2016 14:26:37 -0000, Trac Ticket System wrote:

834: Upon purge (debian) of rpki-ca/rpki-rp errors in the postgresql bits

----------------------+------------------- Reporter: morrowc | Owner: Type: defect | Status: new Priority: minor | Component: rpkid Resolution: | Keywords: Blocked By: | Blocking: ----------------------+-------------------

Comment (by randy):

Make sure you have the latest tk705/, rpki-rp, and rpki-ca packages installed. If you just installed, you can ignore this. But, if you have been running for a while, you may need to purge and

this is a fresh (this morning) purge/install. I can run that again, since I broke myself anyway :)

reinstall to clear an upgrade error:

{{{

systemctl stop rpki-ca

killall -u rpki

apt-get update

apt-get purge rpki-ca rpki-rp

apt-get install rpki-rp rpki-ca

}}} The systemctl stop should shut down the servers. The killall is paranoia in case some cron job happens to be using the database at exactly the wrong moment -- PostgreSQL won't let you drop the database while any process has it open.

If you do the upgrade, you will have to go back and reconfigure the CA as above in [https://wiki.rg.net/wiki/RPKItmp#CAConfiguration-rpki.conf CA Configuration]

=== The !Upgrade/Migration Sequence ===

The upgrade itself needs to take place with the servers disabled, and includes a bit of additional voodoo (notes below):

If you're running as root, you can omit any sudo which isn't immediately followed by a -u rpki.

In case the upgrade/install restarted the daemons, we need to kill them again. {{{

systemctl stop rpki-ca

killall -u rpki

}}}

The rm, database drop, install, and database create are just wiping the state already present from the install and whatever testing you did, so we can start fresh. {{{

rm -rf /usr/share/rpki/.{tal,cer} /usr/share/rpki/publication/

/usr/share/rpki/rrdp-publication/* /var/log/rpki/*

rpki-sql-setup --postgresql-root-username postgres drop

install -d -o rpki -g rpki /var/run/rpki /var/log/rpki

/usr/share/rpki/publication /usr/share/rpki/rrdp-publication

rpki-sql-setup --postgresql-root-username postgres create

}}}

The Django migrations are needed to rebuild the database schemas after the drop and create cycle. {{{

sudo -u rpki rpki-manage migrate rpkidb --settings

rpki.django_settings.rpkid --no-color

sudo -u rpki rpki-manage migrate pubdb --settings

rpki.django_settings.pubd --no-color

sudo -u rpki rpki-manage migrate irdb --settings

rpki.django_settings.irdb --no-color

sudo -u rpki rpki-manage migrate --settings

rpki.django_settings.gui --no-color }}}

These produced the only significant output {{{

sudo -u rpki rpki-manage migrate rpkidb --settings

rpki.django_settings.rpkid --no-color Operations to perform: Apply all migrations: rpkidb Running migrations: Rendering model states... DONE Applying rpkidb.0001_initial... OK Applying rpkidb.0002_root... OK

sudo -u rpki rpki-manage migrate pubdb --settings

rpki.django_settings.pubd --no-color Operations to perform: Apply all migrations: pubdb Running migrations: Rendering model states... DONE Applying pubdb.0001_initial... OK Applying pubdb.0002_auto_20160221_0617... OK Applying pubdb.0003_remove_delta_xml... OK

sudo -u rpki rpki-manage migrate irdb --settings

rpki.django_settings.irdb --no-color Operations to perform: Apply all migrations: irdb Running migrations: Rendering model states... DONE Applying irdb.0001_initial... OK

sudo -u rpki rpki-manage migrate --settings

rpki.django_settings.gui --no-color Operations to perform: Synchronize unmigrated apps: staticfiles, routeview Apply all migrations: rcynicdb, sessions, app, auth, contenttypes, gui_rpki_cache, irdb Synchronizing apps without migrations: Creating tables... Creating table routeview_routeorigin Creating table routeview_routeoriginv6 Running deferred SQL... Installing custom SQL... Running migrations: Rendering model states... DONE Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying app.0001_initial... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying gui_rpki_cache.0001_initial... OK Applying gui_rpki_cache.0002_auto_20160411_2311... OK Applying gui_rpki_cache.0003_auto_20160420_2146... OK Applying rcynicdb.0001_initial... OK Applying rcynicdb.0002_auto_20160227_2003... OK Applying rcynicdb.0003_auto_20160301_0333... OK Applying sessions.0001_initial... OK }}}

Ticket URL: https://trac.rpki.net/ticket/834#comment:1 RPKI project tracker https://rpki.net/ Tracker for RPKI project

Trac comment by morrowc on 2016-06-27T17:59:22Z