configure.ac: Add options to configure several server features

[zdohnal]

PAPPL provides several options and server options to use when running lprint as a daemon. This PR provides a way how to configure them during configuration phase to provide a different defaults in different environments.

[michaelrsweet]

I'm generally not too keen on these because it makes the actual behavior/defaults different from the documented behavior/defaults. Also, PAPPL/LPrint now support configuration files in /etc so it might make more sense to simply put these in a generated lprint.conf file and not embed the setting in the systemd service file.

[zdohnal]

Hmm... it can work, although it would be great if PAPPL could adapt a feature which I know from systemd - that /etc/lprint.conf is only for admin/maintainers overrides of default settings, and upstream defaults would be somewhere outside of /etc, e.g. /usr/lib/lprint/lprint.conf - files in this directory would be under full lprint control.
Combination of admin-accessible and daemon-accessible files in the same directory is a problem in OCI containers, where files in /etc are read-only by default. It can be overridden by adding more volumes to the image, but it is more complicated. And in the end, users with large print servers uses configuration files like printers.conf from CUPS for migration (just copy the file to the new machine).

[michaelrsweet]

Hmm... it can work, although it would be great if PAPPL could adapt a feature which I know from systemd - that /etc/lprint.conf is only for admin/maintainers overrides of default settings, and upstream defaults would be somewhere outside of /etc, e.g. /usr/lib/lprint/lprint.conf - files in this directory would be under full lprint control. Combination of admin-accessible and daemon-accessible files in the same directory is a problem in OCI containers, where files in /etc are read-only by default. It can be overridden by adding more volumes to the image, but it is more complicated. And in the end, users with large print servers uses configuration files like printers.conf from CUPS for migration (just copy the file to the new machine).

I personally hate this behavior - because different distros (and versions of systemd) move where these files live, it is almost impossible to know how to customize the configuration of any given service.

Systemd is one service management framework in use on Linux, and is not used anywhere else. I'd much rather have a "/etc/lprint.conf.default" file that users can copy to "/etc/lprint.conf" and make changes. This file can provide comments that explain the supported options, is easy to find, and doesn't break the user's configuration file no matter how the installation is done.

[zdohnal]

I personally hate this behavior - because different distros (and versions of systemd) move where these files live, it is almost impossible to know how to customize the configuration of any given service.

IMO if you want to customize, it means you want to override any defaults are there - so putting the changes into /etc will do the trick.
This behavior is the same the whole time I'm with RHEL - for 8 years, since RHEL 7 when systemd was introduced.

Systemd is one service management framework in use on Linux, and is not used anywhere else. I'd much rather have a "/etc/lprint.conf.default" file that users can copy to "/etc/lprint.conf" and make changes.

I think one of the reasons for this systemd behavior was making systemd better suited for containers (/etc is read-only there, left for admins to populate when they spawn the container, but never changed after container is up - another was to make machine start even with empty /etc, which is taken as admin space, where might and might not to be overrides).

So to sum it up, lprint.conf.default and lprint.conf would be fine as long the daemon does not write into it. This does not seem to be the case with current lprint, where lprint.conf has similar purpose as printers.conf in CUPS - the file is meant to be writable for daemon, but people uses the file for migrations. It would be great if the files for saving daemon configuration were outside of /etc, so they would be writable regardless where the daemon runs.

[zdohnal]

But to mention - I don't mind having those settings in a configuration file. I made the PR based on my current knowledge that some of options are available only as parameters, so I made changes to service file. If you would be okay with that I create and send PR regarding reading configuration, I can work on it.

My proposal would be:

• split /etc/lprint.conf into configuration and state files - configuration would stay in /etc (for some time it will have to be writeable - so we can handle already existing lprint setups - move state relevant settings into state file), state file (internal printer definitions, defaults set in the daemon etc) will be somewhere else (/usr/lib/lprint/lprint.state?)
• since there will be at least .default and normal conf, move configs to /etc/lprint,
• support 3 types of conf files - lprint.conf.default (project defaults), lprint.conf.vendor (OS defaults), lprint.conf (user defaults)

WDYT?

[michaelrsweet]

Sigh... So there is some legacy stuff still in LPrint, and I didn't realize it until now.

The system state file is normally stored in /var/lib/BASENAME.state. For snaps this becomes $SNAP_COMMON/BASENAME.state. For per-user instances it depends on the environment but can be ~/.config/BASENAME.state, ~/Library/Application Support/BASENAME.state, or ~/AppData/Local/BASENAME.state.

LPrint currently overrides this to use the ".conf" suffix, so I need to fix that...

The spool directory (which also contains resource files and other longer-lived data) is normally stored in /var/spool/BASENAME. For snaps this becomes $SNAP_COMMON/BASENAME.d. For per-user instances it will be ~/.config/BASENAME.d, ~/Library/Application Support/BASENAME.d (macOS), or ~/AppData/Local/BASENAME.d (Windows).

PAPPL looks for options in BASENAME.conf files in $SNAP_COMMON, /etc, /usr/local/etc, ~/.config, ~/Library/Application Support (macOS), and ~/AppData/Local (Windows). Obviously that is going to cause problems with LPrint users... :/

The point of allowing BASENAME.conf files in various standard locations is to allow for customization when the corresponding managing service causes problems with customization - systemd, launchd, snap, etc. all have this problem.

[zdohnal]

The system state file is normally stored in /var/lib/BASENAME.state. For snaps this becomes $SNAP_COMMON/BASENAME.state. For per-user instances it depends on the environment but can be ~/.config/BASENAME.state, ~/Library/Application Support/BASENAME.state, or ~/AppData/Local/BASENAME.state.

LPrint currently overrides this to use the ".conf" suffix, so I need to fix that...

Hmm... there is no lprint related file in ~/.config - .conf or .state. Not even in /root, since lprint is run as root

Looks all stuff is in /etc/lprint.conf, since the server is started with systemd (maybe we should move it to be user service?).

[michaelrsweet]

Issue #129 has fixed the state filenames, where necessary, to avoid conflicts with the .conf files and putting them in the proper directories.