NethServer-SavaPage module

Feature
, , ,
81

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.

2 Likes
82

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:

83

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.

84

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.

2 Likes
85

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
86

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?

2 Likes
87

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
88

Perhaps not entirely Linux FHS, but all SavaPage files are contained in /opt/savapage

Depending on when and what you want to backup with nethserver-backup-config and nethserver-backup-data, you can configure alternative locations for certain parts, and set JVM Temporary Files location.

Note that /opt/savapage/server/data contains email-outbox/ and print-jobtickets/ that act as persistent queues for SMTP and Print Job Tickets. These locations are not configurable (yet).

1 Like
89

Just a question: is it necessary to stop the savapage service before making a backup?

1 Like
90

If you want to backup the complete installation including ad-hoc customization and persisted runtime data you must stop SavaPage first.

Reminder: Save Encryption Keys at first installation.

2 Likes
91

Thank you @rijkr and @robb, I’ll try to provide an updated package asap…

1 Like
92

I’d like to do another test round. Do you have an ETA on these last changes? Running into problems?

93

I’d like to provide the new package until the end of this week…

2 Likes
94

Here you are:

yum install http://markusneuberger.at/download/nethserver-savapage-0.0.1-8.ns7.x86_64.rpm

  • added backup-config and backup-data
    /opt/savapage is saved which also includes encryption.properties and weekly savapage autobackup
  • savapage 1.0.0 rc is included
  • replaced savapage user with new ldapservice user
  • improved firewall ports
    All ports were allowed TCP and UDP, I changed to 5353 UDP, rest TCP.
1 Like
95

If I remember correctly there was a need for a database update for SavaPage 1.0 @rijkr, can you confirm that>

@mrmarkuz, great work… I will test it asap

  • Joining a remote Samba4AD domain works. users are automatically imported in SavaPage. Since I have more than 5 users in Samba4 AD, I was prompted on the Dashboard there were 39 days left (grace period of 40 days?)

  • Joining a local LDAP domain works, users are automatically imported.

  • Joining a remote LDAP domain works. All remote users are imported.

  • Joining a local Samba4AD domain works as expected.

Am I far off when I state that this module can be published in NethForge(testing) repo?
@davidep @giacomo Can this be established?

1 Like
96

The 0.9.12 snapshot used by @mrmarkuz already used the latest db schema, so no need for a db update.

@mrmarkuz I made a overview of File Locations.

2 Likes
97

Of course, NethForge welcomes any contributed RPM! If @mrmarkuz agrees I can enable his GitHub RSA public key for uploads to nethforge-testing repo.

BTW already existing accesses are granted to @stephdl (also to nethforge “production”), @areguera @dz00te @gecco @mark_nl

4 Likes
98

I agree.

5 Likes
99

How awesome is this!!! The nethserver-savapage module has been added to nethforge-testing repository.
You can try and install it through:
yum install --enablerepo=nethforge-testing nethserver-savapage -y

Let’s get this great module into NethForge!

/edit: ran into some trouble. Installing from nethforge testing didn’t work out. No link in applications section and SavaPage webinterface does not respond.
Whay is nethserver-savapage version 0.0.1-7 in nethforge testing and not the latest nethserver-savapage version 0.0.1-8?

1 Like
100

It looks like it’s the original rpm and not our new one…