They all use the machine account AFAIK. But creating a savapage AD user shouldn’t be a problem, at least a warning notice to create one could be enough for now.
This is already in discussion in some threads because an AD user has advantages ie for remote join. But this would affect the whole app stack and is a kind of a big change.
Awesome work! I’ll test it asap…
Update:
yum install http://markusneuberger.at/download/nethserver-savapage-0.0.1-6.ns7.x86_64.rpm
I noticed some config elements not being setable with savapage-cmd:
Error [-32602]: INVALID_PARAMS Reason: Config Property "auth.ldap.host" update failed: ERROR_ACCESS_DENIED Error [-32602]: INVALID_PARAMS Reason: Config Property "auth.ldap.port" update failed: ERROR_ACCESS_DENIED Error [-32602]: INVALID_PARAMS Reason: Config Property "auth.ldap.use-ssl" update failed: ERROR_ACCESS_DENIED Error [-32602]: INVALID_PARAMS Reason: Config Property "financial.global.currency-code" update failed: ERROR_ACCESS_DENIED Error [-32602]: INVALID_PARAMS Reason: Config Property "system.default-locale" update failed: ERROR_ACCESS_DENIED Error [-32602]: INVALID_PARAMS Reason: Config Property "mail.from.address" update failed: ERROR_ACCESS_DENIED
I tried with savapage-db but similar error:
[root@testserver ~]# su - savapage -c "savapage-db --db-config-set auth.ldap.port=389" Config Property "auth.ldap.port" update failed: ERROR_ACCESS_DENIED
The savapage-cmd --sync-users-and-groups is working from shell but it isn’t in my install script. I have to start it a second time to sync the users but this issue may have nothing to do with savapage.
When testing I noticed that savapage-cmd --sync-users-and-groups outputs “null” in any case, no matter if the sync worked. @rijkr, could you change it to output the same text as in web interface?
[root@testserver ~]# savapage-cmd --sync-users-and-groups null
@rijkr, there’s another thing about certificate validation:
Savapage complains about the self-signed cert of NethServer when joining AD with SSL. Is there a workaround to trust all certs? Here are some ideas:
I allowed access for the items you mentioned. You can set “financial.global.currency-code” just once. If you want to change it afterwards you need the ./savapage-cmd --change-base-currency option.
The “null” output was not intended, and is fixed now. No output is given, with exit code 0 (zero), to indicate the sync was started successfully in the background. Since the sync proceeds in the background after ./savapage-cmd returns, no feedback can be given. If you definitely need to know in your install script when/how the background sync finished, an additional savapage-cmd option is needed.
Thanks, it works as expected!
No output anymore, thanks!
I use savapage-cmd --list-users to check first sync, that’s ok.
Because my account was on hold, I couldn’t tell you this yesterday …
I added config item auth.ldap.use-ssl.trust-self-signed. 0000912: Add option to trust self-signed certificate for LDAPS - SavaPage Issue Tracker . Since it defaults to N you need to set it to Y before starting the sync:
./savapage-cmd --set-config-property --name "auth.ldap.use-ssl.trust-self-signed" --value Y
Update:
yum install http://markusneuberger.at/download/nethserver-savapage-0.0.1-7.ns7.x86_64.rpm
What are you doing people here? Such a great job 
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. 
I have to say a great thank you to Saint Markus for the great job!! 
It’s still based on your work, which helped a lot, so big thanks to you too!
Testing the latest itteration of the nethserver-savapage module:
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.
Also prompted with change admin password and ready for use after logging in with admin user.
Users from LDAP are synced:
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.
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! 
There are some open todos:
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.
@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.
@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
