>The "lowest IP address" favoritism decision is totally arbitrary, no?
Absolutely, yes. I think ... looking at the source code, the comparison is done in 3 places in vote.c. You could replace that with anything else. I've always thought that an explicit ordering would make more sense, but I never cared enough to actually write the code. >We're kind of screwed unless there's a way around it, >and really would not like to have to apply a local patch >with every rollout. Have you considered making the "lowest" server a clone? Clones are like other database servers, except that they can never be elected as a sync site. The (default) election winner then would be the next closest. Also, it's not commonly understood but Ubik voting is what I like to call "Chicago style"; the incumbent is always the winner of the election even if he's not the best candidate. Thus if you shut off the database servers of the lowest IP address, once a new election takes place the winner will be sync-site-for-life (unless he's out of service past the Ubik change voting interval). Just trying to present possible solutions that don't involve code changes. --Ken _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
