>>
>> FYI I've committed some changes to sks-keyservers.net in order to use
>> the reported Hostname of the SKS keyserver rather than the hostname
>> listed in any given peer list. One of the reasons for this is the
>> magnitude of aliases in use resulting in multiple occurrences in the
>> pool list.
>>
>
> Your remarks resemble my key servers. Can't be helped, sorry.
>
I found myself thinking towards an RFE for sks-keyservers.net
while resurrecting a server over the past month.
The disk on the original server "failed" (actually I used the wrong
device and clobbered the boot and am too lazy to resurrect the
file system instead of re-installing).
Yes no backups *shrug*.
In order to resurrect the membership file, I grep'ed "unauthorized"
out of recon.log, adding IP addresses until messages went away, and
then set about manually reconstructing FQDN. More tedious than hard.
What was really ultimately most useful was the meta columns on your
status pages in identifying the desired FQDN for various IP addresses
I could not reverse to FQDN.
Here is the RFE of sks-keyservers.net:
Would it be possible to pull a syntactically accurate membership file
directly
from sks-keyservers.net?
And here is another RFE that might help with identifying aliasing issues,
particularly with IPv6:
Perhaps its time to generate/publish some unique host id that can
be remotely accessed through HKP for disambiguating aliasing.
hth
73 de Jeff
_______________________________________________
Sks-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/sks-devel
