Bug 551213 - autotrust does not seems to update anything.
Summary: autotrust does not seems to update anything.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: autotrust
Version: 12
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Paul Wouters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-29 14:02 UTC by Jean-Baptiste Vignaud
Modified: 2010-12-04 01:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-04 01:06:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jean-Baptiste Vignaud 2009-12-29 14:02:24 UTC
Description of problem:

i discovered this tool after investigating on a problem (some keys seemed to have been updated i couldn't resolve some reverse...)

i installed autotrust and configured it to use bind and pointed it to the 
trusted-keys-file:      "/etc/pki/dnssec-keys/named.dnssec.keys" instead of the nonexistent /etc/pki/dnssec-keys/production.conf

i commented the unbound stuff. :
cat /etc/autotrust/autotrust.conf | grep -v "#" | grep -v ^$ :

config:
        working-dir:            "/var/lib/autotrust"
        log-file:               "/var/log/autotrust.log"
        state-file:             "/var/lib/autotrust/autotrust.state" 
        trusted-keys-file:      "/etc/pki/dnssec-keys/named.dnssec.keys"
        resolver-pidfile:               "/var/run/named/named.pid"

i launched it :

autotrust -v 5:

[autotrust] verbose: reading trusted keys file /etc/pki/dnssec-keys/named.dnssec.keys
[autotrust] verbose: reading trust anchor file /var/lib/autotrust/autotrust.state
[autotrust] verbose: updating trust anchor file /var/lib/autotrust/autotrust.state

but /var/lib/autotrust/autotrust.state is still 0 and nothing changed in  /etc/pki/dnssec-keys


Version-Release number of selected component (if applicable):

bind-9.6.1-7.P2
dnssec-conf-1.21-2
autotrust-0.3.1-2



How reproducible:


install autotrust
configure it to use the current keyfile (installed by dnssec-conf)
  
Actual results:

update some reverse keys (for example 88.in-addr.arpa. is 
AwEAAcd1+bra7EHWxTx0BD4u9yJiMXlmOyKCqGdGntevyZfyg78JSu23t9Ge1TPLdPJNa29pF9HbNDLE1vnv7Dfyyghq+aOwdnqIdcXWEIsZ2SgzQXTSot7kouQWj5UP1MZFGo1FXyuqGOkwcZnxqyxG7dj56qXVl67h1GnSqZVKkFjsHEV9sSWvaTgwrOa14qqCRNw1UjrhWXswT+pWgWYcUTqriLv8O6/rs2/2QiQ3T+Uy8pCSYcMT5iRwHj72wTxykgOcwnScsA862FEsbQIR9tD47hCXl0lzhHdX+csC1oclzH2aPG/gFBUgIRPqmfANhcx0M8gnuul5Zo+MlKJZtkk=
in  /etc/pki/dnssec-keys/production/reverse/88.in-addr.arpa.conf
and
AwEAAbHmcpnHwvc8VJw2ruQw+K7o3MOGUav12uT4UyUtqnN2PdQYVnYHjOLBK46ZYAHi7Xg16LMjzkmmSSZwkjuHJMjO6GdJJq6wRed6ELMYTuA5uCH/ExsUiUtHRtZInYeCJ31d9shyA34oaH7xQJaL2XJKFHr2U3DoIs2GLcMnxPNxusiKtDspfB1KUN8n2FLg5UlqEmdIE3GvcYPTHBCz2DRJQuqi4pdrnWigNdChXOSm+o12VC3z6DKNmrLxrbMS0EwFDLas13niV9qcFWg/Uvcs3GEc9/QSNXLKTzq1qkzGoya09cClwOW9iF//XxaNfTRMuwonq0EA696pFpQP5Mk=
in the https://www.ripe.net/projects/disi//keys/


Expected results:

updates the keys.

Additional info:
end of strace of autotrust (it still wakeup named even if nothing changed):

open("/var/log/autotrust.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2060, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd7f2cdc000
fstat(3, {st_mode=S_IFREG|0644, st_size=2060, ...}) = 0
lseek(3, 2060, SEEK_SET)                = 2060
chdir("/var/lib/autotrust")             = 0
open("/etc/pki/dnssec-keys/named.dnssec.keys", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=503, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd7f2cdb000
read(4, "include \"/etc/pki/dnssec-keys//production/bg.conf\";\ninclude \"/etc/pki/dnssec-keys//production/br.conf\";\ninclude \"/etc/pki/dnssec-keys//production/cz.conf\";\ninclude \"/etc/pki/dnssec-keys//production/gov.conf\";\ninclude \"/etc/pki/dnssec-keys//production/museum.conf\";\ninclude \"/etc/pki/dnssec-keys//production/org.conf\";\ninclude \"/etc/pki/dnssec-keys//production/pr.conf\";\ninclude \"/etc/pki/dnssec-keys//production/se.conf\";\ninclude \"/etc/pki/dnssec-keys//production/reverse/ripe-ncc-dnssec-keys-new.txt\";\n", 4096) = 503
read(4, "", 4096)                       = 0
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x7fd7f2cdb000, 4096)            = 0
open("/var/lib/autotrust/autotrust.state", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd7f2cdb000
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x7fd7f2cdb000, 4096)            = 0
open("/var/lib/autotrust/autotrust.state", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
close(4)                                = 0
open("/var/run/named/named.pid", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd7f2cdb000
read(4, "26800\n", 4096)                = 6
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x7fd7f2cdb000, 4096)            = 0
kill(26800, SIGHUP)                     = 0
close(3)                                = 0
munmap(0x7fd7f2cdc000, 4096)            = 0
exit_group(0)                           = ?


To make my named work again i had to manually download the ripe-ncc-dnssec-keys-new.txt file and to replace old reverse zone keys file reference in named.dnssec.keys by it.

Comment 1 Jean-Baptiste Vignaud 2010-01-02 12:07:54 UTC
Updated from fedora 11 to fedora 12 using yum, still the same problem.

Comment 2 Jean-Baptiste Vignaud 2010-01-04 10:26:09 UTC
ok, maybe this is a normal behavior (but sill strange):

It seems that autotrust does not manage the "include" keyword of bind.

I had to manually add the final conf files referenced by the "/etc/pki/dnssec-keys/named.dnssec.keys".

Still this is not very user friendly because thos files were initially added by dnssec-conf and i dont know if they are willing to be updated by a yum update.

Comment 3 Paul Wouters 2010-10-24 15:39:46 UTC
I'm thinking of removing autotrust. The functionality has been partially moved into unbound itself, and bind probably will (or should) get its own method for doing RFC 5011 rollover.

This is furthermore hard to test because the real world has not seen any real RFC 5011 rollovers yet. Just an "updated key" is not enough. So the RIPE key test you did is not a good test. They did not use any revoke bit with RFC 5011.

Comment 4 Bug Zapper 2010-11-04 02:18:05 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 Bug Zapper 2010-12-04 01:06:32 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.