Server installation running as a service with a single configuration profile

[dregad]

This is a follow-up on #13.

I'm testing the deployment of Alma Print Daemon (2.0.0-beta-03) on a server, running as a service. Our goal is to

• get rid of local, user-specific installations and configurations,
• centralize all the print queues configuration, having them monitored and processed at all times without the need for the software to be running on individual user's workstations.

Of course we also need to have more than one person having the ability to administer the print daemon (i.e. configure print profiles, etc), so the current behavior of having multiple, user-specific configuration files (which is the case even with a per-machine installation) is not satisfactory.

What would be needed is a single, global configuration file for the server, that everyone who logs in to the server can see and update.

Furthermore, when running as a service with nssm (following the instructions in the release notes), we need to have the print daemon running as the local SYSTEM or a Service account (i.e. not a regular user account), and have it use the global configuration.

[dregad]

The problem is still present in 2.1.0-beta2.

@mgobat I see you qualified this as an enhancement, but from my perspective, this is actually an important bug, because when the daemon is running as a service, it is very important for the currently logged-in user not only to know what the effective configuration used by the service is, but also to be able to update it as necessary, including printer profiles created by other users.

This is currently impossible: when I login to the server on which the daemon is running, I cannot see the printer profiles created by my colleague, only my own.

I kindly ask you to prioritize and fix this issue as soon as possible. Thanks in advance.

[dregad]

OK, so I do confirm the problem, here's some additional information.

• Alma print daemon version 2.1.0-beta2
• installed on a Windows Server 2019 Datacenter (version 1809, build 17763.3287)
• NSSM installed per documentation, except that the service is running under Local System user
• Configuration and printer profiles performed over Remote Desktop by 2 different users (myself and one colleague)
• No unified view of the configuration, as shown below (note the 2 distinct printer profiles, and different Interval in minutes, highlighted in red on the screenshots)

  Configuration dialog as I see it

  

  Configuration dialog as seen by my colleague

  

What would happen, if both users were to define the same printer in their profiles, but with different settings ? Which one would the service use ?

[dregad]

@mgobat an update on this would be appreciated

[mgobat]

@dregad, we are evaluating enhancements to implement for the next release now. However, there is no target date yet for the next release.

[dregad]

Thanks for your reply. Hopefully this can be considered for inclusion in the next release's scope, IMO this is a very important shortcoming of the current version.

[dregad]

Hello @mgobat, 3 months have passed... Do you have any news on this topic ? This is really problematic and an improved alma-print-daemon with a fix for this would be greatly appreciated.

[mgobat]

@dregad, at startup, the app would need to know where the global configuration file resides. Where would you expect the global configuration file to be stored? In the app's installation directory? Somewhere else?

[dregad]

@mgobat thanks for your reply.

From my perspective it does not really matter where the file is, and I don't have any expectations for that - I believe this is something that should be transparent for me as a user, and it does not even need to be a file for all I care.

What does matter is that when the print daemon is installed for All users, then the configuration needs to actually be shared and accessible by all users, including of course the service account used to run the NSSM service.

In other words, it should not be stored in any user's personal profile (%APPDATA%, e.g. C:\Users\<name>\AppData\Roaming\alma-print-daemon\alma-print-config.json), but in a location that is common to everyone on the machine where the program is installed. I'm not a Windows expert, but a directory under %PROGRAMDATA% (e.g. C:\ProgramData\alma-print-daemon) seems appropriate.

See also the discussion in #59.

[mgobat]

@dregad, I'm inclined to implement in this manner to get something to you quickly. Anything else would be a longer delivery and not a guarantee.

• Existence of a config file in the folder in which the application resides is considered a global configuration.
• Establishing a global configuration is a manual process; copy the master config file into the installation folder manually. Not ideal but leads to a quick implementation.
• Any user logged into the server/workstation will have access to read/update this global configuration using the application.
• The configuration dialog in the application will indicate "Global Configuration" in some way.
• Log files will be stored in the application's installation folder for a global configuration.
• Unfortunately, re-installing the application clears the installation directory. The global configuration file and any global log files will be erased. Global configuration file will need to be copied before installation and restored after.

Of course, I guess this may be pointless if we can't get your "Local System account" service installation working (#77).

[dregad]

• Establishing a global configuration is a manual process; copy the master config file into the installation folder manually. Not ideal but leads to a quick implementation.
• Unfortunately, re-installing the application clears the installation directory. The global configuration file and any global log files will be erased. Global configuration file will need to be copied before installation and restored after.

While this would definitely be an improvement over the current situation, the proposed implementation is indeed not ideal, mainly because of the risk of overwriting (and therefore losing) the configuration in case someone forgets to save it before upgrading.

But I guess we can rely on system backups to safeguard against that and restore the file if necessary. Also, considering that an upgrade is not something that would happen so frequently, the risk is acceptable.

I still hope you would consider a more stable and permanent fix for this, e.g. using %PROGRAMDATA% as storage for the configuration and log files, which would avoid the above-mention limitation.

I guess this may be pointless if we can't get your "Local System account" service installation working (#77).

I don't think it's pointless at all. This would in any case benefit other users who are not subject to a company policy forbidding end-user accounts to run services.

[mgobat]

@dregad, I agree that %PROGRAMDATA% is the better solution. However, the programming framework used in the Alma Print Daemon doesn't expose a method to get that path.

In testing the proposed solution, there may be some issues with Windows security. Looking at some other options.

[mgobat]

@dregad, new proposal based on Windows security issues:

• Establish a global configuration by having a workstation administrator place a globalConfiguration.json file in the directory in which the Alma Print Daemon is installed. This file contains a path to the location of the global alma-print-config.json file. All users must have read/write access to the location specified. Example globalConfiguration.json file:
  {"globalConfigPath": "c:\\APDGlobalConfiguration"}
  Note that the backslash character must be preceded by an escape character.
• Copy the master alma-print-config.json file into the folder specified as the globalConfigPath in the globalConfiguration.json file.
• The Alma Print Daemon application title bar will indicate a global configuration is in effect with the text "Using Global Configuration".
• The configuration dialog in the application will indicate "Global Configuration" in some way.
• Log files will be stored in the globalConfigPath specified in the globalConfiguration.json file.
• If the globalConfiguration.json file in the application's folder does not exist, or the globalConfigPath specified in it does not exist, the application will revert to user-specific alma-print-config.json files. Note that the absence of "Using Global Configuration" in the application's title bar indicates a user-specific configuration is in effect.

Since re-installing the application clears the installation directory, the globalConfiguration.json file must be saved and restored after re-installating. The alma-print-config.json file and the logs will remain in place in the globalConfigPath folder.

[dregad]

Hi @mgobat

The proposal to use a globalConfiguration.json file pointing to a directory with the config and log files sounds much better to me than the previous idea to place the config file in the daemon's installation directory, to be overwritten with the next install.

The specification you outline looks good to me, except for one thing on the last bullet point:

• If the globalConfiguration.json file in the application's folder does not exist, or the globalConfigPath specified in it does not exist, the application will revert to user-specific alma-print-config.json files.

It makes complete sense to fallback to the local configuration in %APPDATA% if the global config file does not exist,

On the other hand, in my opinion, the absence of the globalConfigPath directory (or if it exists but cannot be written to) must be considered as an ERROR, instead of just silently falling back to some undetermined and likely incorrect local user-specific configuration.

Also please consider some kind of error handling and reporting, in case there is a syntax error or invalid setting in globalConfiguration.json. Since it will be manually edited, this is something that could definitely happen, especially since JSON is not the most user-friendly format for a config file (for this kind of usage, I personally favor INI or YAML format).

Since re-installing the application clears the installation directory, the globalConfiguration.json file must be saved and restored after re-installating.

Not perfect of course, but given the constraints still much better than the previous scenario. The globalConfiguration.json file can be kept safe in the very directory it points to, and easily copied back to the installation directory if needed.

We really appreciate your efforts in finding a working solution to this issue. Would you be able to provide an estimate, as to when this could be implemented and released for testing ?

[mgobat]

@dregad, thank you for your feedback. The first beta version with this feature is available now at https://github.com/ExLibrisGroup/alma-print-daemon/releases/tag/v2.2.0-beta-03.

It has only been tested by a single user, with a known Windows network setup. Please do not deploy immediately into production.

Core functionality remains unchanged.

[dregad]

@mgobat many thanks for this !

I have installed the new version v2.2.0-beta-03 today, and testing so far confirms that the global configuration works as designed in interactive mode, i.e. when the globalConfiguration.json file is present in C:\Data\AlmaPrintDaemon, the UI shows Using Global Configuration in the window title, and Global Configuration in red at the bottom when updating configuration.

I am not able to perform proper tests when running as a service at the moment, but considering that the first line of the log file created when starting the service

2023-06-27T09:41:02.415Z:  Global config file: c:\Data\AlmaPrintDaemon\alma-print-config.json

I believe it should be OK too.

Unfortunately my printing problem is still not fully resolved yet, due to the shared printer issue (see #77 (comment)), but this is a great step forward.

[mgobat]

@dregad, thank you very much for your patience...and for testing this new feature. We will keep it as a beta/pre-release until you have successfully tested full-cycle.

[fruehanp1]

@mgobat, I have been using v.2.2.0-beta-03 for about a week now without any issues. It is running as a service via NSSM under the Local Service account with the globalconfiguration.json file. I will update if there are any new issues.

This update is much appreciated, it makes provisioning the server more secure and is easier to setup.

[mgobat]

@fruehanp1, thank you for the status update. We are glad this release is working better for you.

[mgobat]

@dregad, have you been able to test this full-cycle yet? Thanks.

[mgobat]

Assumed working as expected since no response.

[dregad]

Assumed working as expected since no response.

Hello @mgobat I apologize for the lack of reply, I have been busy with other projects at the end of 2023, and forgot to give you an update.

I do confirm that the global configuration is working as intended; while not perfect, it is good enough for us to be comfortable using it in Prod, and in fact it has been running like that since beginning of 2024.

For the record, we are still facing the issue with shared printers setup though (see #77). So far the only workaround we have is running the APD under an end-user account (against corporate security policy). I'll be resuming tests for that soon.