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?
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.
2 Likes
So allowing certs would be a better option than disabling SSL…
2 Likes
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.
I tried to find the savapage AD joining part, but no success.
Maybe we can automate it
Probably 
Christmas update:
yum -y install http://markusneuberger.at/download/nethserver-savapage-0.0.1-4.ns7.x86_64.rpm
- 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?
Open:
- disable SSL validation for self-signed certs, I couldn’t manage it
- test if savapage AD sync works with letsencrypt cert
4 Likes
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,
https://www.savapage.org/docs/manual/ch-security-encrypted-secrets.html
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?
https://www.savapage.org/docs/manual/app-tools-savapage-db.html
translation:
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?
2 Likes
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.
2 Likes
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 http://markusneuberger.at/download/nethserver-savapage-0.0.1-4.ns7.x86_64.rpm
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 http://markusneuberger.at/download/nethserver-savapage-0.0.1-4.ns7.x86_64.rpm
Syncing savapage users with LDAP:
And after syncing:
1 Like
Thanks for testing!
You are right, for now only local LDAP.is working. It will be included in the next update.
Ok so I’d use the user source that is provided by NethServer and some mail settings as default. Which currency or locale to use as default? Should we also enable Mail/Web Print or some converters?
thnx for confirming. i will have local ldap a go.
hmm… default settings for a globall community … i don’t know it would be a good idea to go with defaults?
Isn’t there a way to get those settings from NethServer? Or create several defaults and based on set locale in NethServer a SavaPage default is generated?
For instance: If the Organization Contacts (in the configuration section of the admin interface) gets a small extension with Country(code), we could generate a list with all currencies for each country and get the info from there?
When loggin in SavaPage, there are already several locales/translations available:
- German
- English
- French
- Spanish
- Russian
- Dutch
On the other hand, IMHO it wouldn’t be that bad if SavaPage remains with the need of some configuration. After all, it is a VERY complicated and extensive application that will need additional configuration for anyone that wants to use it anyway. There are so many scenarios thinkable that it is impossible to get them all covered through initial install.
After initial configuration the way users are allowed to print has to be determined. If they need to pay per print and how the payment is handled. There are so many different options…
If there is no easy option to add the initial configuration to the installer, maybe we should settle with a clear instruction how to do the initial configuration… Personally I wouldn’t have too much problems with that.
Just checked extra what post install things need configuration:
https://www.savapage.org/docs/manual/ch-install-configure.html
- Set Locale (Options → Advanced → Locale)
- Set Currency Code (Options → Financial)
- Set User Source (Options → User Source)
- Set Mail Options (Options → Mail)
When these things are set, you get the confirmation in Dashboard:
Yes, we also could use the NethServer timezone settings, I’ll have to check how to get currency.
I think this are just the web interface translations.
1 Like
That would be awesome!
Your are correct…
BTW, just thinking about user setup. If the NS instance has not joined LDAP or AD and no local LDAP or AD is configured, SavaPage should be configured with local users only. Of course this can be changed later if the NS instance with SavaPage joins LDAP or AD domain.
1 Like
Thanks, I did not cover this case but it’s on my todo list now.
1 Like
More work for you @mrmarkuz 
Rijk has done some work on the savapage-cfg command option.
https://issues.savapage.org/view.php?id=909
and already added it to the manual:
https://www.savapage.org/docs/manual/app-tools.html#cli-get-config-property
https://www.savapage.org/docs/manual/app-tools.html#cli-set-config-property
https://www.savapage.org/docs/manual/app-tools-savapage-db.html#app-tools-savapage-db-config-set
https://www.savapage.org/docs/manual/app-tools-savapage-db.html
A new snapshot is available:
https://www.savapage.org/download/snapshots/ (you need the file created 26th dec)
Great to see 2 communities work together like this…
1 Like
Hi Markus,
As Rob just posted, I added options to savapage-cmd and savapage-db to set config items.
Depending at what stage of the installation you want to add the items, you must use one of the two.
savapage-cmd is preferred, because it is swift. But, since it uses JSON-RPC, savapage server must already be running. savapage-db can be run stand-alone, when savapage server is not started. However, since each invocation establishes database connectivity over and over, performance is not that great for a simple row update (it takes approx. 4 seconds).
Good luck! Please let me know if you have any questions.
4 Likes
May I introduce to our community @rijkr : The developer of SavaPage. I am very glad he joined up here to have an even closer contact with the NethServer community and get us to the best print management experience possible in our NethServer ecosystem.
Thank you Rijk, for your effort and help so far!
2 Likes
Just amazing!
Thanks for your work! The added options will help a lot.