OK, here is what I am testing (as I didn't get any feedback yet).

cms.blacklist [check ] [invert] []

The only new thing here is "invert" that makes the blacklist work like a whitelist.

The file rules are extended, and follows

[redirect ]
Either blacklists or whitelists the matching host unless redirect is specified. In which case the match will simply redirect the client to expanded list of hosts. I will likely extend this to allow multiple targets on the line. Currently, the only way you can have multiple targets is by DNS alias expansion via the "+" (same as in the config file). The redirect happens whether or not the blacklist is inverted.

A redirect to a server applies to all ,manager connections regardless of which manager sent it (the first one wins). This is to prevent inconsistent state when two replicated managers have conflicting redirects.

The above poses a large problem when you want a server to join two different clusters or federations. There is no good automatic solution to this. So, the idea is to expand the all.manager directive, as follows:

all.manager [ meta | peer | proxy ] [ all | any ] host[+]{:port | port} [site ] [if ...]

The addition of the site name groups together all connections to managers tagged with that site. This allows redirects to work independently at the site level. So far as I can tell no one has done multiple site federations which is good because it won't work past 64 servers due to a limitation on how redirects are handled in the current code (they work just fine for single site federations). You need not specify "site" if you have a single site federation.

Finally, the beta code still only applies blacklist redirects to servers that support it properly (i.e. old servers will simply be blacklisted but not redirected).

Finally, if there is no blacklist file then no black or white list applies and everyone can join just like today (subject to the allow directive). I am also pushing in some new code to make sure that blacklisting only gets turned on if you specified the cms.blacklist directive.

All comments welcomed.

—
Reply to this email directly or view it on GitHub.

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1