search

ExLibrisGroup / alma-print-daemon

Application which listens for and prints letters from the Ex Libris Alma print queues.
BSD 3-Clause "New" or "Revised" License
11 stars 2 forks source link

Server installation running as a service with a single configuration profile #44

Closed dregad closed 8 months ago

dregad commented 2 years ago

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

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 commented 1 year ago

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 commented 1 year ago

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

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 commented 1 year ago

@mgobat an update on this would be appreciated

mgobat commented 1 year ago

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

dregad commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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.

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

dregad commented 1 year ago
  • 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 (https://github.com/ExLibrisGroup/alma-print-daemon/issues/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 commented 1 year ago

@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 commented 1 year ago

@dregad, new proposal based on Windows security issues:

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 https://github.com/ExLibrisGroup/alma-print-daemon/issues/77#issuecomment-1609093457), but this is a great step forward.

mgobat commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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

mgobat commented 11 months ago

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

mgobat commented 8 months ago

Assumed working as expected since no response.

dregad commented 4 months ago

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.