sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] strange behavior with empty database


From: Chris Kuethe
Subject: Re: [Sks-devel] strange behavior with empty database
Date: Wed, 25 Feb 2004 13:08:26 -0700 (MST)

After loading up your keys, you need to run cleandb. Here's my mostly foolproof
method for setting up a keyserver:

ckuethe{1}: gpg --export ckuethe > /tmp/ckuethe.gpg
ckuethe{2}: sudo su - sks
sks{1}: rm -rf KDB PTree
sks{2}: sks build /tmp/ckuethe.gpg
sks{3}: sks pbuild -cache 200 -ptree_cache 200
sks{4}: sks cleandb
sks{5}: ( edit sksconf, mailsync, membership to you liking)
sks{6}: sks db &
sks{7}: sks recon &
sks{8}: sks merge /path/to/keydump/*.gpg

CK

On Wed, 25 Feb 2004, Fabio Massimo Di Nitto wrote:

> 
> Hi Yaron,
>       I am performing some tests starting a full resync using one sks
> instance with an empty database (using the latest cvs snapshot).
> 
> after i start the 2 sks servers, one of which is fully synced and the 2
> starts gossiping i get this error in the logs:
> 
> 2004-02-25 18:58:30 <reconciliation handler> error in callback.:
> Failure("Remote configuration rejected: filters do not match.\n\tlocal
> filters: [ yminsky.dedup yminsky.merge ]\n\tremote filters: [ ]")
> 
> Now checking the logs again i notice that on the server that has the db
> there is this entry:
> 
> 2004-02-25 19:10:53 Applied filters: yminsky.dedup, yminsky.merge
> 
> while on the other "yminsky.dedup, yminsky.merge" is missing.
> 
> at that point i imported a small set of keys in the empty db and these 2
> entries are back in.
> 
> now the 2 servers seem to talk but they keep resetting the session towards
> each other. Perhaps because of the number of keys that needs to be
> transferred?
> 
> NOTE: I am using the Dlong for numerix.ml on both the servers since one of
> them is a sparc. The fully synced one is i386 and it is still talking fine
> with its peers.
> 
> Thanks
> Fabio
> 
> -- 
> <user> fajita: step one
> <fajita> Whatever the problem, step one is always to look in the error log.
> <user> fajita: step two
> <fajita> When in danger or in doubt, step two is to scream and shout.
> 
> 
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/sks-devel
> 

-- 
Chris Kuethe, GCIA CISSP: Secure Systems Specialist - U of A CNS
      office: 157 General Services Bldg.    +1.780.492.8135
              address@hidden

     GDB has a 'break' feature; why doesn't it have 'fix' too?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]