Depending on updated/enhanced versions of standard packages

[sraustein]

New ticket, since this isn't about Kimura-san's backtrace anymore. See #418 for context.

I think it may be better just to set up our own apt repository with newer versions of required software. As a test, I rebuilt python-django and python-django-south from the Quantal release and set up a repository:

deb http://sigpipe.org/rpki rpki main

I'm really tempted to say that if we're going to set up our own apt repository, we should use that to get RFC-3779-enabled OpenSSL libraries too, so we can move the binary packaging in a direction that the Debian and Ubuntu maintainers might accept. Not sure what we should do to the package version number in our forked package if we do that to make it all come out right.

Not sure we want to get into this in the next few days. The rpki-ca.postinst hack to run pip install works and may be simpler for the user (no need to fiddle apt repository configuration). Unless somebody feels strongly about this, I will probably just keep the pip hack for next week's hackathon.

Then again, if we did set up our own apt repository, our users could use apt-get instead of dpkg, which might outweigh the pain of configuring the apt repository and work out as a net gain.

I think the apt-repository thing is probably the right direction in the medium run (long run of course is to get this into distros and not our problem). Perhaps document how to do that, and advise me on what to do with the OpenSSL package version number. :)

Trac ticket #423 component rpkid priority minor, owner sra, created by sra on 2013-02-22T03:27:34Z, last modified 2016-08-05T17:28:50Z

[sraustein]

use the web page for this ticket, not the email, as the email line-wrap breaks things

Trac comment by randy on 2013-03-09T04:56:35Z

[sraustein]

can i safely lay this over an old rp-only install from michael's page?

Trac comment by randy on 2013-03-09T04:57:54Z

[sraustein]

Still to do:

• Clean up debian/ directory mess.
• Get builder.py running under cron (lock and ssh setup not done yet)
• Add "pbuilder-dist update" support to builder.py so it stays current
• Sign PGP key :)
• Put previous update ("how to use") someplace appropriate on wiki, once Randy has debugged the instructions

Trac comment by sra on 2013-03-09T05:00:10Z

[sraustein]

downloading dependencies will take a fair while

Trac comment by randy on 2013-03-09T05:04:01Z

[sraustein]

can i safely lay this over an old rp-only install from michael's page?

I really have no idea what apt-get will do in this case, and don't think it's worth trying to find out.

Recommended update procedure for this particular case (Michael feel free to chime in if I'm missing something):

• Remove old rpki-rp package: {{{ sudo apt-get remove rpki-rp }}}
• Edit /etc/apt/sources.list to remove entry you previously added pointing to Michael's repository
• Then follow the above instructions

If you manually edited /etc/rcynic.conf, save a copy of your modified version before doing this in case the update stomps on them. In theory we try to preserve such changes, in practice this has not been tested well (and I may be confusing the Ubuntu and FreeBSD cases on this point).

Trac comment by sra on 2013-03-09T05:08:11Z

[sraustein]

downloading dependencies will take a fair while

Same as it ever did, difference is just that now you get to sip tea and watch it rather than typing.

Trac comment by sra on 2013-03-09T05:09:05Z

[sraustein]

it appears to actually be

sudo rm /etc/apt/sources.list.d/rpki.list

Trac comment by randy on 2013-03-09T05:14:54Z

[sraustein]

My mistake, Michael has had us adding repositories both ways (editing sources.list and adding file to sources.list.d/) and I didn't remember which one he'd told us to do in this case.

Trac comment by sra on 2013-03-09T05:19:33Z

[sraustein]

downloading dependencies will take a fair while Same as it ever did, difference is just that now you get to sip tea and watch it rather than typing.

actually, i am thinking about a smoothie

Trac comment by randy on 2013-03-09T05:21:35Z

[sraustein]

rp install done and seems to work. it stepped on rcynic's crontab. smoothie time.

Trac comment by randy on 2013-03-09T05:24:21Z

[sraustein]

for CA/RP combined install, do i still follow https://trac.rpki.net/wiki/APRICOT-2013-Hackathon after the apt-get?

Trac comment by randy on 2013-03-09T05:34:16Z

[sraustein]

/etc/rpki.conf.sample has my identity as build-u, probably a bit confusing for folk. maybe should be 'fix-me' :)

Trac comment by randy on 2013-03-09T05:39:03Z

[sraustein]

Build script now running under cron, so in theory any changes checked in will automatically result in updated packages. Currently have this running every ten minutes, may fiddle with that later.

Trac comment by sra on 2013-03-09T20:43:51Z

[sraustein]

initially it was easier just to put in /etc/apt/source.list, but i got tired of typing that during testing my deb packages, so moved toward dropping a file in /etc/apt/sources.lists.d/.

Trac comment by melkins on 2013-03-10T04:43:47Z

[sraustein]

On Sat, Mar 09, 2013 at 05:08:11AM -0000, Trac Ticket System wrote:

423: Depending on updated/enhanced versions of standard packages

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

Comment (by sra):

can i safely lay this over an old rp-only install from michael's page?

I really have no idea what apt-get will do in this case, and don't think it's worth trying to find out.

assuming that the packages generated by sra have higher version number, it should overwrite my old packages without issue (they are built using the same scripts, essentially).

only issue is that sra's deb packages do not yet automatically install the cron jobs for the gui.

Trac comment by melkins on 2013-03-10T04:45:46Z

[sraustein]

It seemed to work

phone email, so sucky

Trac comment by randy on 2013-03-10T06:42:17Z

[sraustein]

assuming that the packages generated by sra have higher version number, it should overwrite my old packages without issue (they are built using the same scripts, essentially).

The thing I wasn't sure about was how much internal state the APT tools keep about the state of the APT repository. Doubt we'l switch repositories often enough to warrant serious research :)

only issue is that sra's deb packages do not yet automatically install the cron jobs for the gui.

I need to rewrite rcynic-cron anyway, the current setuid/chroot glorp is too complex and fragile. The GUI support code that involves looking at rcynic's output should go into that, so it's covered by the same lock over the rcynic database as everything else. I think I have a Python snippet from you in some ticket or another telling me what code I need to call under the lock for this.

Trac comment by sra on 2013-03-10T14:26:27Z

[sraustein]

The thing I wasn't sure about was how much internal state the APT tools keep about the state of the APT repository. Doubt we'l switch repositories often enough to warrant serious research :)

packages do not "remember" where they were installed from. see 'apt-cache policy' to start down the rabbit hole of how you can configure preferences on where to pull from when there are multiple options available.

Trac comment by melkins on 2013-03-10T14:47:22Z

[sraustein]

This is mostly finished. Remaining to do:

1. Hack up something to do automatic updates of the packages we're backporting when the upstream source package changes.
2. Hack up something to do these builds automatically under pbuilder-dist under cron.
3. Figure out what packages we need for Debian, and backport all of them too. In theory we can do all of this using pbuilder-dist on Ubuntu.

Trac comment by sra on 2013-05-12T11:22:33Z

[sraustein]

Ancient history from the time when we first started automated binary package builds for Ubuntu.

Trac comment by sra on 2016-08-05T17:28:50Z

[sraustein]

Closed with resolution fixed