search

saltstack-formulas / openssh-formula

http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html
Other
90 stars 297 forks source link

Indicate deprecated config #156

Closed wolfpackmars2 closed 5 years ago

wolfpackmars2 commented 5 years ago

I propose indicating options in the example pillar that are deprecated with a concise format. I will create a pull request which will give an example.

Using inline comments after the option it applies to would appear as thus:

sshd_config:
    UsePrivilegeSeparation: 'sandbox' # D: >=7.5

This would indicate that the option is deprecated in sshd version 7.5 and higher.

Additional comments can be included at the beginning of the example pillar which could describe the format.

sshd_config:
  # Deprecated and Removed sshd options will be indicated by inline
  # comments. D: indicates an option that is deprecated. R: indicates
  # an option that is removed. These will be followed by the version
  # of sshd where this applies.
  UsePrivilegeSeparation: 'sandbox' # D: >=7.5
  Protocol: 2 # D: >=1.2 R: >7.5

Note that this hypothetical example would indicate that the UsePrivilegeSeparation option is deprecated in sshd versions 7.5 and higher and the Protocol option is deprecated in versions 1.2 and higher and removed in version 7.5. (I don't actually know when or if protocol was ever deprecated, this is an example only).

The examples above are based on the release notes for openssh 7.5. https://www.openssh.com/txt/release-7.5

Related #102 and #150

alxwr commented 5 years ago

@wolfpackmars2 I like the idea, but I don't like the huge maintenance cost. :-) Who is going to keep those annotations up to date? One of the main reason why we didn't want to keep track of which directive comes / goes in what version was that it's a never-ending time-consuming task. Hardly anybody is able to keep track of all the patched OpenSSH versions in all the distros out there. Therefore we shifted the responsibility to keep track of ones servers to the owners/admins of those machines, where it actually belongs.

As discussed in #102 this formula does not keep track of differences between versions or flavours of OpenSSH (any more than it absolutely must). I'm strictly against reintroducing this solved problem again.

I still really like the idea though, but rather than keeping track of OpenSSH release notes (and discrepancies between docs, code and distro patches) I propose we add a big warning in pillar.example and refer the reader to https://www.openssh.com/releasenotes.html and https://www.openssh.com/manual.html.

wolfpackmars2 commented 5 years ago

I agree it would be difficult to document all the changes. If we were to add these to the documentation, it would have to be understood that it is a convenience feature and the information may (most likely) be out of date. As people, like myself, would come across changes, they could update the notes and create pull requests.

It would be great if someone would create such a list and post it online. Maybe someday when I'm old and retired and have nothing better to do... :p

If I create an initial pull request we could maybe try it out. If it proves to be a burden (too many issues, too many PRs, too many complaints) we could remove them.

We can close this issue. I may create a pull request in the future with this feature and it can be decided whether it's worth trying or not?