Discussion:
[Sks-devel] dump-only server (gossip but not public pool availability)
Hendrik Visage
2018-02-05 00:26:36 UTC
Permalink
Good day,

As I can’t dump the SKS database while running, and the file snapshot setup not quite feasible for my setup(s) yet, I was wondering about a gossiping only server (and only gossiping to a limited set servers close peers) that isn’t connected/advertised to the SKS pool.
This would then be a server I could easily take offline and dump keys every so often, not impacting the pool availability etc.

Which settings should I use to achieve the above, as it seems the moment I start the server, it starts to broadcast it’s availability to be included in the pool?

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
***@envisage.co.za
Moritz Wirth
2018-02-05 00:43:47 UTC
Permalink
Hi,

I am not completely sure how new keyservers are determined, one way
seems to be the peering list. If you advertise the same hostname on
multiple keyservers, only one node will be included (see keys1.flanga.io
and keys2.flanga.io are both included in peering lists but only
keys.flanga.io as loadbalancer appears in the sks-keyservers file),
however you will get into troubles if the keyserver is not reachable so
all servers would fall out of the pool (and it has some side effects on
the info about the peering, but I did not find anything that would cause
real operational issues).

If both keyservers are peered over private IP addresses, you can just
add them to the peering file - they are excluded from the pool (for
obvious reasons).

Furthermore, there is a global exclude list, ask Kristian for that.

Best regards,
Post by Hendrik Visage
Good day,
 As I can’t dump the SKS database while running, and the file snapshot
setup not quite feasible for my setup(s) yet, I was wondering about a
gossiping only server (and only gossiping to a limited set servers
close peers) that isn’t connected/advertised to the SKS pool.
 This would then be a server I could easily take offline and dump keys
every so often, not impacting the pool availability etc.
Which settings should I use to achieve the above, as it seems the
moment I start the server, it starts to broadcast it’s availability to
be included in the pool?
---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
brent s.
2018-02-05 00:43:54 UTC
Permalink
Post by Hendrik Visage
Good day,
 As I can’t dump the SKS database while running, and the file snapshot
setup not quite feasible for my setup(s) yet, I was wondering about a
gossiping only server (and only gossiping to a limited set servers close
peers) that isn’t connected/advertised to the SKS pool.
 This would then be a server I could easily take offline and dump keys
every so often, not impacting the pool availability etc.
Which settings should I use to achieve the above, as it seems the moment
I start the server, it starts to broadcast it’s availability to be
included in the pool?
i do the same thing by just running the dump box behind a NAT without
any port forwarding (and running the gossip over a vpn to my "real" peer
box).

i presume if you firewall off the HKP/HKPS port(s) and only expose the
recon port, it won't get listed in the pool.
--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info
Chris Kuethe
2018-02-05 00:45:00 UTC
Permalink
you can spin up a second instance on the same host, perhaps bound to
127.0.0.1:21370 and 127.0.0.1:21371. Have your public instance also peer
with the localhost-only instance, and the locallhost-only instance peer
only with your public instance. Then you can start and stop the
localhost-only instance to dump it.
Post by Hendrik Visage
Good day,
As I can’t dump the SKS database while running, and the file snapshot
setup not quite feasible for my setup(s) yet, I was wondering about a
gossiping only server (and only gossiping to a limited set servers close
peers) that isn’t connected/advertised to the SKS pool.
This would then be a server I could easily take offline and dump keys
every so often, not impacting the pool availability etc.
Which settings should I use to achieve the above, as it seems the moment I
start the server, it starts to broadcast it’s availability to be included
in the pool?
---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 <+27%2084%20612%205345> or +27-21-945-1192
<+27%2021%20945%201192>
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
brent s.
2018-02-05 00:50:04 UTC
Permalink
Post by Chris Kuethe
you can spin up a second instance on the same host, perhaps bound to
127.0.0.1:21370 <http://127.0.0.1:21370> and 127.0.0.1:21371
<http://127.0.0.1:21371>. Have your public instance also peer with the
localhost-only instance, and the locallhost-only instance peer only with
your public instance. Then you can start and stop the localhost-only
instance to dump it.
...now i feel silly for deploying and peering to a private separate
dumpbox. i totally didn't even THINK about localhost. cheers!
--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info
Andrew Gallagher
2018-02-05 01:12:47 UTC
Permalink
Which settings should I use to achieve the above, as it seems the moment I start the server, it starts to broadcast it’s availability to be included in the pool?
Your server doesn’t broadcast anything, the pool is determined by walking the (publicly readable) tree of peers and filtering out those that fail a set of sensible criteria. Since one of those criteria is that your server must be behind a reverse proxy (and be able to prove it!), you can intentionally fail the test by unsetting the Via: HTTP header in your proxy config.

Andrew.

Loading...