updating rpki.net tools probably should not install new TAL files

[sraustein]

when updating an existing installation of rpki-rp using 'sudo sh rpki-portmaster.sh', the current behavior of [over-]writing a set of default TAL files is probably not the best. it is quite possible that the operator has modified the set of TAL files he/she wants to use, and might not remember to re-adjust these files again after each update.

this does not seem to happen with 'sudo apt-get update; sudo apt-get upgrade'

Trac ticket #657 component build priority minor, owner sra, created by jayb on 2013-11-22T02:26:28Z, last modified 2013-12-08T21:35:16Z

[sraustein]

there is a difference between changing the content of tals and changing the set of which tals i am using.

Trac comment by randy on 2013-11-22T02:32:48Z

[sraustein]

Not sure, but perhaps trust-anchor-directory pointing at the directory where software upgrades drop new TALs is not the right choice for an operator who wants to select which TALs to use.

That is: I think that, rather than whacking the contents of that directory, it might be better for the operator to edit rcynic.conf.

Otherwise, we're in an impossible bind: some users will expect us to update the TALs, some will get upset with us if we update the TALs, and Randy will get upset with me if I make people who don't care go back to listing which TALs to believe.

I think one can have automatic update or one can be picky but I am not sure that one can do both at the same time.

Trac comment by sra on 2013-11-22T02:39:29Z

[sraustein]

ok, i can see the bind. without causing too much in the way of extra documentation, might you be willing to add a comment statement in rcynic.conf.sample along the lines of "automatic updates will write a fresh set of default TAL files in /usr/local/etc/rpki/trust-anchors. if you do not want your active set of TAL files possibly stomped on, point trust-anchor-directory elsewhere."

Trac comment by jayb on 2013-11-22T02:56:44Z

[sraustein]

might you be willing to add a comment statement in rcynic.conf.sample along the lines of "automatic updates will write a fresh set of default TAL files in /usr/local/etc/rpki/trust-anchors. if you do not want your active set of TAL files possibly stomped on, point trust-anchor-directory elsewhere."

so, in order to get changes to the content of tals, does my private directory contain links to /usr/local/etc/rpki/trust-anchors? will you blow chuks all over when the soft link points to a tal which update has removed?

Trac comment by randy on 2013-11-22T03:02:34Z

[sraustein]

randy, are you saying that every default TAL that rpki-rp puts in the trust-anchor-directory ought to be in the set used by everyone? i checked not long ago, and found that ripe-pilot.tal and apnic-testbed.tal did not result in any VRPs, and those resulting from rpki.net-testbed.tal look to be from workshop exercises.

maybe it would be better in this regard if rcynic.conf stated specifically which TAL files should be used, rather than just pointing at the directory where they reside.

Trac comment by jayb on 2013-11-22T03:24:45Z

[sraustein]

are you saying that every default TAL that rpki-rp puts in the trust-anchor-directory ought to be in the set used by everyone?

no!

maybe it would be better in this regard if rcynic.conf stated specifically which TAL files should be used, rather than just pointing at the directory where they reside.

there are different reasonable use models

o i want the standard set of tals

o i am hacking the tal list, but if a tal changes content, of course i want to keep current

Trac comment by randy on 2013-11-22T03:29:57Z

[sraustein]

i am hacking the tal list, but if a tal changes content, of course i want to keep current

that's pretty much where i started. i'll gladly use most of the default TALs, but i'll add at least one and i'll take one or two away. what is the recommended way to handle this?

Trac comment by jayb on 2013-11-22T03:39:00Z

[sraustein]

just a friendly reminder to say i am honestly interested in learning the recommended way to manage a non-default rcynic configuration. on friday i re-built all ports on my freebsd server, and i see that in so doing the re-build of rpki-rp caused the TAL files i had removed to be re-installed in /usr/local/etc/rpki/trust-anchors.

one possible approach would be to edit /usr/local/etc/rcynic.conf to point my trust-anchor-directory somewhere other than /usr/local/etc/rpki/trust-anchors. i have not yet tried that, because i wonder whether a ports rebuild would also re-install a default version of /usr/local/etc/rcynic.conf, pointing me right back to /usr/local/etc/rpki/trust-anchors again. then there's also the issue of wanting to pick up legit changes to the TAL files i do want to use.

Trac comment by jayb on 2013-12-01T15:57:17Z

[sraustein]

At Fri, 22 Nov 2013 03:24:45 -0000, Trac Ticket System wrote:

maybe it would be better in this regard if rcynic.conf stated specifically which TAL files should be used, rather than just pointing at the directory where they reside.

One can certainly do that, simply by going back to the old way of specifying TALs: use trust-anchor-locator instead of trust-anchor-directory. Randy hated that approach, so we added trust-anchor-directory and now use it in the default configuration, but the older mechanism is still available.

Note that, due to idiosyncrasies of the underlying OpenSSL configuration file parser, multiple instances of the trust-anchor-locator command need a numeric suffix to keep the parser happy. Eg, if you wanted to generate a list of trust-anchor-locator directives for every TAL in /etc/rpki/trust-anchors/ which you could then edit manually and drop into rcynic.conf, you could use something like this (which is pretty much what the old installation code did):

{{{ ls /etc/rpki/trust-anchors/*.tal | awk '{printf "trust-anchor-locator.%d\t= %s\n", NR, $0}' >rcynic.tals.conf }}}

Trac comment by sra on 2013-12-08T21:35:13Z

[sraustein]

i wonder whether a ports rebuild would also re-install a default version of /usr/local/etc/rcynic.conf.

No. It might install a new rcynic.conf.sample, but it's not supposed to stomp on rcynic.conf. Trust anchors aside, there are ten zillion other parameters you might have tweaked; we tried to pick sensible defaults for all of them (well, OK, most of them -- a few of the defaults have not kept up with current usage), but if you really want to fiddle with the knobs, we're not going to stop you, that's why they're there.

there's also the issue of wanting to pick up legit changes to the TAL files i do want to use.

Using trust-anchor-locator instead of trust-anchor-directory would address this.

Alternatively, you could do what Randy seems to be doing on some machines: he points trust-anchor-directory somewhere else, then symlinks from that directory back to the one where the TALs really live. I confess that I don't really understand the value of doing it that way as opposed to just putting the configuration in, um, the configuration file, but presumably Randy has his reasons.

Trac comment by sra on 2013-12-08T21:35:16Z