NethServer-SavaPage module


(Markus Neuberger) #21

I reached a milestone: I’ve gone through your howto again and the db connection to postgresql works now.
Now I have a working template I can build on.
Don’t know exactly what the problem was:

  • database had wrong collation
  • installing nethserver-postgresql as build-require sets a password for postgresql so the psql commands afterwards didn’t work non-interactively.

I hope I can release an update with working pgsql asap…

With these steps one can make a fresh 7.4 NS to a savapage server (also phppgadmin is installed to manage postgresql via web UI)

Savapage install
yum -y install
yum -y update
yum -y install postgresql-server postgresql-contrib nethserver-cups nano which gzip strings perl java-1.8.0-openjdk-devel poppler-utils ImageMagick avahi-tools
useradd -r savapage
mkdir /opt/savapage
chown savapage:savapage /opt/savapage
grep -q -F "savapage" /etc/security/limits.conf || echo -e "savapage hard nofile 65535\nsavapage soft nofile 65535" >> /etc/security/limits.conf
config set savapage service status enabled TCPPorts 8631,8632,8639,5353,5222 UDPPorts 8631,8632,8639,5353,5222 access green
signal-event firewall-adjust
echo a4 > /etc/papersize
su savapage
cd /opt/savapage
chmod u+x savapage-setup-0.9.12-linux-x64.bin
./savapage-setup-0.9.12-linux-x64.bin -n
systemctl stop savapage
su savapage -c "/opt/savapage/server/bin/linux-x64/savapage-db --db-export"
postgresql-setup initdb
sed -i 's/ident/md5/g' /var/lib/pgsql/data/pg_hba.conf
sed -i 's/#password_encryption = on/password_encryption = on/g' /var/lib/pgsql/data/postgresql.conf
systemctl restart postgresql
su postgres -c "createuser savapage"
su postgres -c psql
alter user postgres with encrypted password 'POSTGRESSECRET';
alter user savapage with encrypted password 'SECRET';
su postgres -c "createdb -O savapage savapage"
echo 'pathmunge /opt/savapage/server/bin/linux-x64/' > /etc/profile.d/
chmod +x /etc/profile.d/
sed -i 's/database.type=Internal/#database.type=Internal/g' /opt/savapage/server/
sed -i 's/#database.type=PostgreSQL/database.type=PostgreSQL/g' /opt/savapage/server/
sed -i 's/#database.driver=/database.driver=/g' /opt/savapage/server/
sed -i 's/#database.url=/database.url=/g' /opt/savapage/server/
sed -i 's/#database.user=/database.user=savapage/g' /opt/savapage/server/
sed -i 's/#database.password=/database.password=SECRET/g' /opt/savapage/server/
su savapage -c "/opt/savapage/server/bin/linux-x64/savapage-db --db-init"
yum -y install nethserver-phppgadmin
systemctl start savapage

I saw that savapage saves its config in the database, so we may use the db import/export function to provide some default settings. If we want more, we have to analyze how the savapage db is working and where the important values are saved. The AD/LDAP config is also stored in the DB.

(Giacomo Sanchietti) #22

Excellent work guys!
I don’t have much spare time these days, but let me know if I can help you on something specific :wink:

(Alessio Fattorini) #23

We’re cheering for you guys!

(Rob Bosch) #24

So the question is now: how to create a specfile that specifies the described sequence of actions?

I do want to point that it should be considered to use backends that are already used with other applications (if possible)
Especially for Java and PostgreSQL. I would hate to see 2 different versions of java and PostgreSQL installed if it can be avoided.

(Markus Neuberger) #25

We use one Java and one postgres.


I did a “nightly” build.

  • savapage not included in RPM anymore which makes the build much faster and the package smaller
  • savapage download via script
  • postgresql working

You have to do this after installation:

I have to find out why it’s not working immediately after install…


  • Default configuration
  • Some props for e-smith db
  • Split config and download script
  • Snapshot/stable version switch
  • Some reverse proxy to have savapage on a default web port

In the specfile are the requires like java 1.8.0 and the system user is created.

The work is done now by /etc/e-smith/events/actions/nethserver-savapage-conf

I fully agree. Following modules are used:

  • nethserver-avahi
  • nethserver-cups
  • nethserver-postgresql
  • java 1.8.0 from centos, it is needed by savapage, I tried with 1.7.0 which webtop uses, but the savapage-db script didn’t work

(Markus Neuberger) #26

Nightly update:

  • LDAP works
  • AD only works when disabling TLS auth on nsdc container, did you ever try joining to AD with certs and java keystore?
  • Web printing works
  • Printing from my Windows 10 doesn’t work. The print stays for some seconds in the queue and then it’s gone without error. But may be a Windoze problem.

I’ll keep you updated…

(Davide Principi) #27

This seems the same issue @planet_jeroen found in another thread. I’d ask @gabriele_bulfon how he solved it for WebTop5 which runs on the same Java stack.

(gabriele_bulfon) #28

Hello, at the moment we added code to manage “trust all certs” etc during setup of SSL/TLS sockets.
This is a recurrent problem when working with secure sockets in Java, as installing certificates is always a headache.

Here you can see the ldap auth code that sets up the connection using a library that already features “AllowAnyTrustManager” and “AllowAnyHostnameVerifier”:

(Davide Principi) #29

Thank you for sharing the code snippets!

@robb we should ask Saveapage devs to implement the option that disables SSL cert verification.

(Markus Neuberger) #30

Thanks, guys! I’ll try the code asap!

(Rob Bosch) #31

I will bring it under their attention and tell what their response will be.
Is a more elegant way not possible? Like a smooth cert import procedure? It is not for nothing that SSL cert verification is in place. Could turning off SSL cert verification compromise payed/authorized printing in some way?

(Markus Neuberger) #32

I’ll try that even if some headache is predicted.

Disabling security mechanisms is always bad, but as far as I understand:
The problem are the self-signed certs when connecting to Nethserver AD.
You also have this kind of problem in your browser when you browse to https server with self signed cert but you are able to just allow the site and it works (the connection is still encrypted but the identities are not authorized by a third site)
In this case savapage wants to connect to Nethserver container and Nethserver (and samba as well) defaults to using TLS/SSL auth. So savapage has to connect with certs and complains about the self-signed cert of Nethserver.
I’d like the possibility, like you have in the browser, to say: I know that site, I’ll accept this cert, even if it is not fully valid.

If we don’t have this possibility savapage and AD will only work with valid certs or at least with Letsencrypt I think. For sure valid certs should also work, I don’t want to turn it off forever, it should just be the possibility to make it work with self-signed certs.

(Rob Bosch) #33

So allowing certs would be a better option than disabling SSL…

(Jeroen Visser) #34

I solved my AD cert issue by simply adding the fqdn of the samba container to it’s hosts letsencrypt cert, and copying it over the container’s certs.

This is the fastest route to valid certs, but needs work to keep current.

(Markus Neuberger) #35

I tried to find the savapage AD joining part, but no success.

Maybe we can automate it

(Jeroen Visser) #36

Probably :slight_smile:

(Markus Neuberger) #37

Christmas update:

yum -y install
  • local LDAP user sync works
  • AD settings are pre-configured now except of the password
  • no need to rerun update event after install anymore

For working AD password we have to find out how savapage encrypts the password before saving it to postgres db. Do you have an idea?


  • disable SSL validation for self-signed certs, I couldn’t manage it
  • test if savapage AD sync works with letsencrypt cert

(Rob Bosch) #38

Great work @mrmarkuz!
I will contact the savapage dev for info on that AD password.

/edit: got some replies on my question from Rijk Ravestijn, the dev of savapage:

Hallo Rob,

Ik begrijp dat Markus direct in PostgreSQL schrijft? Met die encrypted
secrets heeft hij dan een “uitdaging”. Hij kan de SavaPage code op
GitLab natuurlijk bekijken, en zien hoe dat in Java wordt gedaan…

Maar, misschien is het handiger om, zoals ik eerder al voorstelde,
SavaPage commandline API uit te breiden met een methode om config items
te zetten (updaten). De gebruiker van de API hoeft (behoort) niets te
weten van database schema en hoe passwords e.d. als encrypted secrets
worden opgeslagen.

What translates as:
I understand that Markus is writing directly to PostgreSQL? In that case he will have a ‘challenge’ with the encrypted secret. Of course he can have a look at the SavaPage code on gitlab so he can see how this is done in Java.
But perhaps it is more convenient to extend the SavaPage commandline API with a method to place (update) configuration items De user of the API doesn’t need to know anything about the database schema and how encrypted passwords are stored.

and a mail later:

Ik zou in analogie met savapage-db bijvoorbeeld een savapage-cfg
command-line util kunnen maken. Zoiets als …

./savapage-cfg --set-property
–id auth.ldap.admin-password
–value “plain text password”

Zou dat helpen?

I could, like already is done with “savapage-db” create something for “savapage-cfg” commandline util. Something like this:

./savapage-cfg --set-property
–id auth.ldap.admin-password
–value “plain text password”

Would that help?

@davidep what do you think? would that be a feasible solution?

(Markus Neuberger) #39

That would help a lot!

I tried to find the password encrypt part in that java code but without success. It’s done like this in Webtop where a Java code snippet is used to encrypt the password. But a command like savapage-cfg would make the whole thing easier I think.
Maybe in future the encryption method in savapage changes. When using “savapage-cfg” nothing has to be changed in nethserver-savapage.

(Rob Bosch) #40

Will do some tests this week with both LDAP and Samba4 AD, both local and remote.
Thanks again for this awesome job so far!

W I P:

test remote LDAP:

Created an NS7 VM with LDAP account provider.
Added 2nd NS7 as client to the LDAP and checked if the join was successful: yeah!
Installed SavaPage with latest rpm: yum -y install

Looks like the LDAP join is local ldap and not remote? Am I missing something here?
Also, before SavaPage admin interface will show (LDAP) users, it needs to be configured with some post install settings. For instance: Currency code in Options/Financial/Currency Code

test local LDAP

Created an NS7 VM with LDAP account provider.
Updated to latest patchlvl.
Installed SavaPage with latest rpm: yum -y install

Syncing savapage users with LDAP:

And after syncing: