3 ms·
What do you expect to happen when an upgrade to a daemon involves a policy choice? For example, let's say that you have Postfix using a smarthost as a relay, a
by dsr_ 4y ago
What do you expect to happen when an upgrade to a daemon involves a policy choice?
For example, let's say that you have Postfix using a smarthost as a relay, and the new version of Postfix requires relays to have a shared secret for authentication with each of their trusted clients. That isn't something that can be handled by an automated config translator.
This sort of thing happens a lot. The best that can be done is putting the changes into a document for you to read, understand, and then make decisions.
- mhitza 4y ago> This sort of thing happens a lot. The best that can be done is putting the changes into a document for you to read, understand, and then make decisions. A distro that has a simulate upgrade command, which generates a report on all these incompatibilties, would be one way.
- b112 4y agoDebian has a very complete upgrade doc, with gotchas, and workarounds. It should be read completely, if you maintain a lot of boxes... (It isn't the same as you want, but it absolutely does take "the unknown* away.)
- boris 4y ago> For example, let's say that you have Postfix using a smarthost as a relay, and the new version of Postfix requires relays to have a shared secret for authentication with each of their trusted clients. That isn't something that can be handled by an automated config translator. This would be roughly equivalent to adding a new column or a table in a relational database with some non-NULL/empty data in it, right? Somehow we deal with this in that case, or at least we are forced to deal with it or the transaction gets aborted rather than what we have currently, which is, "oops, new postfix has been installed, you didn't read the documentation carefully, and none of your servers can send mail anymore".