At one point it appears I was either directed to add, or that upgradeprovision added, dns/{MACHINE} (or something similar, not where I can validate names) to spn_update_list in /usr/local/samba/private. Many upgradeprovision --full later, this line still exists in CONTROLLERMACHINE$, where it should be removed (since it was added autoatmically) as well as where it belongs: dns-CONTROLLERMACHINE. upgradeprovision should remove the dns/{MACHINE} from spn_update_list and the appropriate spn from CONTROLLERMACHINE$. Thank you Andrew Bartlett for your help in tracking this down.
Matthieu, please have a look at this!
(In reply to comment #0) > At one point it appears I was either directed to add, or that upgradeprovision > added, dns/{MACHINE} (or something similar, not where I can validate names) to > spn_update_list in /usr/local/samba/private. > Pretty unlikely, upgradeprovision copy the spn_update_list from the reference provision if it's not existing, if it's existing then it copy nothing so you must have run upgradeprovision when there was still the DNS/${HOSTNAME} in it that is to say up to 25th september last year. > Many upgradeprovision --full later, this line still exists in > CONTROLLERMACHINE$, where it should be removed (since it was added > autoatmically) as well as where it belongs: dns-CONTROLLERMACHINE. The rule for upgradeprovision is not to remove spn as it can be quite dangerous, there might be users still relying on the old form of DNS where it was still dns/{MACHINE}. > > upgradeprovision should remove the dns/{MACHINE} from spn_update_list and the > appropriate spn from CONTROLLERMACHINE$. So it's _very_ hard to do so, because now upgradeprovision updates record only modified or created by provision and previous upgradeprovision. In your case the DNS/${HOSTNAME} come from the copy of a not so great spn_update_list that is to say that the change has occurred out of the control of upgradeprovision and it will by default avoid this update. We can add exceptions but the number of persons concerned by this is very limited (that's people who have done upgradeprovision from July 2010 to 25/09/2010). It might be more efficient and safe to produce a warning message for users in the same case as you.
How to proceed here, ekacnet?
I would not do anything, because the problem is just for trever I think so there is no sense doing a patch for 1 person. Trever are you ok for a WONTFIX resolution ?
I suppose this bug and the original mailing list posts are enough documentation. I have fixed all of my machines. If closing this as WONTFIX is the right solution, feel free to do so.
I'm closing this with "WONTFIX". Thanks for the collaboration!