NethServer-SavaPage module

What are you doing people here? Such a great job :slight_smile:


I see I have some testing to do tomorrow… great work!


Some months ago Rob asked me to do some work on Savapage but I had very little time for it. :frowning:

I have to say a great thank you to Saint Markus for the great job!! :clap:


It’s still based on your work, which helped a lot, so big thanks to you too!

1 Like

Testing the latest itteration of the nethserver-savapage module:

Test with Local AD:

Install went flawlessly! Great work
First screen after logging in to SavaPage admin user. All is configured and ready to use. Do take care of changing savapage admin user (important!)

SavaPage AD configuration page with savaaduser as savapage AD admin user.

Test with Local LDAP:

Also prompted with change admin password and ready for use after logging in with admin user.
Users from LDAP are synced:

Test with remote LDAP:

Prompted with change admin password and ready for use after logging in with admin user.
LDAP users are synced. LDAP admin is not filled in. BTW, I connected to remote LDAP with cn=ldapservice,dc=directory,dc=nh and remote bind credentials.

Do I understand correctly that there is no need to fill in the LDAP admin credentials in savapage in this case?

1 Like

Thanks for testing!

I recently recognized that there is a nethserver-dc/sssd in testing which makes AD support simple LDAP auth:

I didn’t test it, but this way we maybe don’t need the extra savaaduser.

That would be nice, because it would be a challenge to add a savaaduser to a remote (Samba4) AD account provider right? Probably the same for a remote LDAP account provider.

In this case it’s like we would need a user to create a user, so it won’t make sense.
For remote it has to be done manually, you have to enter username/password of an allowed user when binding NS to remote LDAP/AD except of anonymous bind is allowed. For savapage we just use the credentials given at NS account provider setup.

I managed to test all scenario’s (local AD, local LDAP, remote AD and remote LDAP) successfully. Would that mean that NethServer-SavaPage module is ready for nethforge-testing repo?

/edit: just to be complete, I also tested on NS with no accountprovider installed: flawless!

/edit2: stretched the test a bit further: After installing SavaPage on a NS7 without account provider, I installed Samba4 AD accountprovider. SavaPage automagically switches from local accounts to Samba4 AD account provider. After that, I deinstalled Samba4 AD account provider and installed LDAP account prvider. Again, SavaPage was configured automagically with LDAP settings.
Can’t say anything else but: GREAT WORK @mrmarkuz!


Thank you for testing! :+1:

There are some open todos:

  • Put latest savapage snapshot in the rpm package, it’s downloaded after install via config script at the moment.
  • Use ldapservice user instead of savaaduser
  • I didn’t really test printing for now so maybe we need some more default settings for that
1 Like

You have noticed that SavaPage is under constant development. @rijkr is doing a great job adding generic features in a way that specific wishes are implemented.
So it will be necessary to update the package regularly.
@rijkr: how can we make this a steady process? I mean, there are quite some new releases in the form of snapshots, but as soon as a major release has come out, we should get notified in some way so the module can be adapted.

You are right abouyt the ldap service user instead of a dedicated savaaduser. Especially with remote AD environments it is not expected to have access in creating a new user in AD.

About printing: this is IMO a next level configuration of SavaPage and does not belong in the module. This module should give a basic install that meets the first install needs. After that savapage needs a LOT of configuring. It is a very complex application with a lot of parameters. IMO we should not tinker with it. The admin that is installing SavaPage has to dive into configuration with the (official) SavaPage manual in his hands. Only then SavaPage can work and perform to its full potential.

1 Like

@mrmarkuz Will you be the maintainer of the module? If so, I can contact you as soon as new releases or important snapshots are published.

1 Like

@robb , you are right, a lot of scenario’s are supported. If practice shows there are common scenario’s for the NethServer community, we can rethink on how to give these scenario’s a kick-start by configuration.

Above that, the technicalities of getting printers to work as expected, especially staple, punch, fold and booklet finishings, can be “challenging”. Although SavaPage PPD Extensions offers ample possibilities to bend the PPD specifics of every printer into a simple printer setting dialog, this tailoring is not for the novice. If support is needed in that area I can assist. The good news is, that once PPD Extensions for printer type/models are known and published, they can be reused by everyone. To get an idea of the challenge, have a look at Appendix K. PPD Extensions


Yes, I think so :slight_smile:
Please just ping me on a new update but I am also thinking about an auto update feature as
it seems like downloading savapage-setup-*-linux-*.bin and install it should just work anytime.


Could an auto update feature be implemented?
If a new update is tested and works, the new update could be pushed to the repo and automagically be installed for nethserver-savapage users… :money_mouth_face:

Yes, I can imagine 3 approaches, which may partly also be combined:

  • Stable approach: Static RPM without auto-update, savapage is packed statically in the rpm, we are able to test a new savapage update, repack savapage and push a new update rpm to the repo. The build and push to repo process could be mostly automated. We are responsible for giving users the new savapage.

  • Compromise: Static RPM with manual update script: savapage packed into the RPM, but updateable to newest version via script. This script may also integrate a stable/snapshot version switch. This way we could be sure to pack a working/tested version and the user has the possibility to update if he wants. If a new package breaks nethserver-savapage it could be just reinstalled to get a working version again.

  • Newest features approach: RPM without savapage, actual savapage is downloaded and installed during package configuration. Savapage checks for updates and does them automatically. This way savapage is kept at newest version, but we risk that new functions or changes in savapage may break nethserver-savapage.

Consider that new SavaPage versions sometimes need a database schema update. This involves executing an SQL script, before running the new version.

Beware that update.sql scripts must be executed in the right order. So, when SavaPage is updated from version A to C (skipping version B), this implies that both the A-to-B.sql and B-to-C.sql update scripts must be run.

Also, it is good practice to back-up the database before executing any update.sql script.

Although SavaPage is prepared for automatic DB schema updates (and making a database backup before the update), I did not make use of it yet, and chose to make the sysadmin execute the upgrade.sql scripts manually.

This strategy is motivated by the fact that auto DB update introduces considerable overhead, as each schema version needs to be represented in the SavaPage installable. And, as repeated DB changes were envisioned, the extra work involved for each iteration was disproportionate.

As the database schema is more stable now, activation of auto DB update is certainly an option. This would of course imply a significant programming and test effort at the next DB schema change.

At least at the introduction of the SavaPage module, I advise to use “Stable approach”. In that way you have optimal control, user protection, and you can script upgrade.sql and database backup as needed. Depending on rate of deployment and community member reactions, we can decide on how to proceed next.


Thanks, I didn’t think about schema updates.

Fully agree as it may be really difficult to manage sql updates between different savapage versions.

1 Like

I tested the AD join with the new nethserver-sssd and it works with the ldapservice user so we don’t need the savaaduser anymore.

Open todos:

  • use ldapservice instead of savaaduser
  • implement Savapage service as NethServer service
  • backup with nethserver-backup-config and nethserver-backup-data
  • put a stable Savapage version to the RPM

Do I need more to backup than the database and /opt/savapage?


AFAIK the only place where savapage lives is in /opt/savapage/
Maybe @rijkr can shed some light on this, but my best guess would be that a backup of /opt/savapage/ and the savapage database should do the trick.

1 Like