perfsonar-user - Re: [perfsonar-user] Pollution of service directory
Subject: perfSONAR User Q&A and Other Discussion
List archive
- From: Andrew Lake <>
- To: Brian Candler <>
- Cc: perfsonar-user <>
- Subject: Re: [perfsonar-user] Pollution of service directory
- Date: Wed, 10 Oct 2018 08:59:07 -0400
- Ironport-phdr: 9a23:YFLrURbk76yqja/LSBa2M4D/LSx+4OfEezUN459isYplN5qZoMq+bnLW6fgltlLVR4KTs6sC17KJ9fi4EUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCa/bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPCTQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjm58axlVAHnhzsGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7WYNEUSndbXstJWCNBDIGzYYsBAeQCIOhWsZXyqkAUoheiHwShHv/jxiNKi3LwwKY00/4hEQbD3AE4A98OtmnbrM/rO6YcTOu7yrPHzTbdYPhL3jry8o7IfQ0hoPyXQ71watDdyU8xGAPZl1idr5HuMT2S1uQIqWeb7uxgWPqyh2I7tw19uDmiy8g2hoXVnI4Z1lbJ/jh6zoYtPdC0VVB3bN2+HJZerS2XOJZ6TtkgTm11oCo21KEKtJqhcCUJyJkr3QPTZv2FfoSS/x7uUOKcLDFlj3x/Yr2/nQy98U24x+38SMa01FFKozJLktbSuX0BzRjT5dODSvdn8Ueh3iiP2xjS6uFCP080ibLWJ4M/zrMzjJYev17PEyDrlEnsjqKaa10o+u2y5OTmZrXmqIWcN4hxigzmKKsunNGwAOQjPwcQRGiX4+K826P//UHhWrVFkuU2krXFsJDdPckbvrC2AxVb0oY47Ba/CS2p0M4BkXkaN1JKZgiHgpPtO1HPO/D4Eey/j0q2nDdqwfDGIqPuAo/LLnfdjLftY6xx5FBBxwounphj4Md+ELAIJrrYU0n9sNHCRkszdQe9xerjBc9VzoQUXnLJCaicZvD8q1iNs8spL/OBe8cxsTXwY6ws4fL/pXIi31kQYf/6jtMsdHmkE6E+cA2ian32j4JESD9Ssw==
Hi Brian,
Thanks for letting us know. The records automatically expire after a couple hours, so turning off registration is enough. Doing a quick search I didn't see any of them anymore.
You are correct that currently the page shows a bunch of private addresses that should probably be filtered out. The service directory in general needs a lot of work, for example it doesn't even allow you to filter on the aforementioned node-access-policy. Right now even the addresses in public-space are hit-and-miss since its hard to know what ACLs they are behind, how bust they are, etc. I think you are hitting on some pieces of a much larger topic we've been discussing in the development team recently which is how we can make the lookup service and the data it contains more reliable. We don't know that we have all the answers yet, but this is something at the forefront of our minds.
Thanks,
Andy
On Tue, Oct 9, 2018 at 12:41 PM Brian Candler <> wrote:
My apologies...
I have been creating some test perfsonar instances for a workshop, using
unroutable RFC6598 address space (100.64.0.0/10) - these are basically
private addresses but they look like real ones.
Unfortunately it seems these test instances have ended up in the global
services directory, with addresses 100.64.0.200-206.
I've now disabled the registration daemon, but you may want to purge
this junk out of your database - I don't know if it auto-expires, and if
so how long that takes.
I notice a few RFC1918 addresses in the database (e.g. 192.168.20.192,
192.168.7.153), so it might be worth having a filter to exclude those
and other unroutable addresses.
There is a wider issue which I expect you've already considered: whether
it would be better for perfsonar nodes to register themselves only when
some of the host administration information has been configured, because
at the moment it seems to be registering immediately even when this is
all blank, and with a node access policy of "public" pre-selected. This
means that the moment you create a new node on the network you may be
unwittingly inviting people to use it, even if this wasn't something you
intended.
Having said that, I acknowledge that the majority of perfsonar nodes
*are* intended to be discoverable public resources, and you don't want
to make it any harder than necessary for this to happen.
Regards,
Brian.
- [perfsonar-user] Pollution of service directory, Brian Candler, 10/09/2018
- Re: [perfsonar-user] Pollution of service directory, Andrew Lake, 10/10/2018
Archive powered by MHonArc 2.6.19.