Refactor part of server settings code

[reddevillg]

It's difficult to fix some corner case, such as

1. turn share_printers and remote_any on, keep remote_admin off
2. turn share_printers off.
   remote_admin is still take effect.

found a similar problem #158

[michaelrsweet]

We need to do a lot of regression testing here - the proposed changes look like they might cause problems when updating a customized cupsd.conf file, and we absolutely want to minimize how much of the cupsd.conf file is changed. The most common support advice is "enable debug logging with cupsctl --debug-logging", but if doing so wrecks an otherwise working configuration then we'll have angry users...

[reddevillg]

The intention here is only change the order of options in cupsd.conf. If this is not desired, we need write options in two place as before.

1. First time encountering a option.
2. Write any required missing option.

But we don‘t need to record if the option was changed (don't need test the condition remote_admin >=0, just assign old_remote_admin to remote_admin in first place), because it will write to new cupsd.conf file anyway。It is this part that complicates things。I can update the patch if it makes sense to you。

[michaelrsweet]

@reddevillg Thanks for the feedback! I'm not specifically opposed to your changes, I just want to make sure they don't introduce any regressions... I'd be doing the same if I was making the changes, if only because I've broken things a time or two in the past... :)

[AZero13]

Any update on this?

[zdohnal]

Hi @AtariDreams ,

I'm planning refactor the cupsctl code to prevent removal of comments, so cupsctl can be used more widely (this will need more explicit comments in the cupsd.conf, so then we won't need to add comments of our own during the execution of the command) - I'm keeping this PR opened for later checking the functionality from PR is in the new code as well.

[zdohnal]

Hi @reddevillg ,

thank you for the PR! We are trying to implement comment preserving functionality in #640 , so it would be great if the PR didn't add comments and didn't change the position of directives, because if it does, it can move the directive from the comment which is relevant to the directive.

Would you mind adjusting the PR based on this premise or you don't mind if I do it?

Either way we should add cupsctl tests into test suite as well before merging this PR.

[reddevillg]

@zdohnal I'm not sure if "comment preserving" is a good idea. Thinking about someone adding a comment to explain the following directives, cupsctl changes server settings later, but preserving the comment which explain the directives changed before.
I think user(admin) should aware that if change cupsd.conf by manual, it should do it always.

[zdohnal]

@zdohnal I'm not sure if "comment preserving" is a good idea. Thinking about someone adding a comment to explain the following directives, cupsctl changes server settings later, but preserving the comment which explain the directives changed before.

We've updated the default comments to be as generic as they can be, so they could make sense with more configuration combinations. So unless the user doesn't add the exact comment like "This allows remote access", we're ok. But in such cases IMO it is a user error - if user adds comments on his own, he is responsible for its contents.

I think user(admin) should aware that if change cupsd.conf by manual, it should do it always.

IMO the combined use of manual edit and of a tool is ok - tool should manipulate with directives and its values, limit or policy scopes and shouldn't touch comments at all, and manual edit is here for more precise changes.

[reddevillg]

@zdohnal OK, I can live with that :)
Back to the original issue, i'm glad to continue the PR, I will see how to do it in a few days.

[michaelrsweet]

Definitely not for 2.4.x, maybe for 2.5.

@zdohnal Can I get you to look at this since it affects the cupsd.conf code?