However, we still believe that DOMAIN\username parsing with Fast Printer is an important and valuable feature for the SavaPage project. In many enterprise environments (especially AD-based infrastructures), Fast Printer combined with domain-based authentication is a common and scalable use case.
Since the exact same configuration works without any issue on v1.6.0, and fails on v1.7.0, this still strongly looks like a regression introduced in the newer version.
Even though we have a workaround now, having proper DOMAIN\username support restored for Fast Printer would significantly increase the value of SavaPage for Active Directory environments.
We are happy to provide logs, configuration details, or perform tests if needed to help identify the root cause.
Thanks for taking the time to develop such a great product. Allowing it to be accessible to use without restrictive licensing is just amazing!
I have a specific question. I am running:
1.6.0-final (Build 20251215)
PostgreSQL 18.2 (Ubuntu 18.2-1.pgdg24.04+1)\
on Ubuntu 24.04
Nearly everything has been effortless and works perfectly. My question is around the source of the information that is presented by SavaPage IPP. The below, is from the airprint queue that is created and reserved as part of the setup. ipptool -tv ipp://my.server:8631/printers/airprint get-printer-attributes.test
printer-more-info (uri) → is showing the server’s IP, not the hostname.
media-default (keyword) → is showing the wrong size iso_a4_210x297mm
I have the locale in SavaPage set to en_US (I am in Canada and Ubuntu is set for Canada)
I have the default paper size set to letter in SavaPage admin
I have /etc/papersize set to letter
While I am not new to Linux or UNIX (~25 years) I am sure I must be missing something obvious.
@markwb Welcome to SavaPage! Do you refer to setting the Default Paper Size in SavaPage? Which user scenario is failing? What is the end result you expect and what do you see?
Hey! Thanks for the response.
Yes, I took a look at the Default Paper Size option in the admin interface. It’s been set to letter and the savapage service has been restarted.
The problem I am encountering, is iOS devices are only seeing A4 paper size when printing. They should see Letter and Legal with Letter as the default. If I go ahead with the A4 paper size, the job submits fine, but it is showing as A4 in the user job release web interface and then when sent to the proxy printer, the job is asking for A4 paper on the printer. This problem is not affecting MacOS clients. They are seeing letter as the default and are printing fine.
The second thing, the printer-more-info url, is what is displayed to iOS clients when they look at the printer information in the print dialogue (think). “Show Printer Web Page” is the link text. It is supposed to be a link to allow them to sign in to the web console to create the link between their device and their username/account on savapage. It’s not using the server hostname in the link, it’s using the IP. I have an nginx reverse proxy providing SSL termination. I don’t think the reverse proxy is the source of the problems. See below for the ipptool test. Right now the url is presented on iOS devices as: https:// 192.168.80.8:8632/user I want this to be https:// printserver.domain/user
I know that I can create the iOS “app” button to allow users to print, and I have, but I would like to fix this url that is being placed in the printer dialogue too if I can.
Both of these issues appear to be coming from the /printers/airprint virtual queue. If I use the ipptool to query the queue for it’s attributes, I can see that the information coming from the queue contains the wrong url information, and contains the wrong default papersize.
If you need any more information, or screen shots etc. Please let me know.
I have a question as a new user on print routing. I have 3 printers in my office. It’s only me working there. I have a color laser MFP, a hi speed black and white, and small black and white. I print a lot, about 8000 pages every 4 months. A lot of documents, and also envelopes. What I want is to setup 1 virtual printer, print everything to that, and then route the job to either the dedicated envelope printer if the paper size is envelopes, or to the hi speed printer if letter black and white or the mfp if letter sized color… But I’m not quite sure how to set that up and not seeing a good example online to follow.
I decided to go forward with some testing, and when I try to print I get the following error:
User “matthew” print on queue “/” from 10.0.5.15 denied. Reason: org.hibernate.PersistentObjectException: detached entity passed to persist: org.savapage.core.jpa.DocLog
I googled this, and it’s something way over my head.. I’ve configured a lot of different open source software programs over the years, but I’m definitely no programmer.
As background: I’m running this inside of an LXC container on proxmox, using Ubuntu 24.04. Proxy printers are a Canon MF665 and Kyocera P3055 both of which have linux native drivers. Running Savapage 1.70-rc
@deerefanatic Welcome to SavaPage! The scenario you describe is not supported. The best thing to do is to create three Queues for the three print cases (Color, B/W, Envelopes), to configure IPP Routing for each Queue and route to the right Printer. So, you need three printers on your desktop that refer to these queues and pick the right printer for Color, B/W, or Envelope print jobs.
Can I configure a queue, to hold incoming jobs and present them to an Operator for release to the printer the Operator chooses?
Details: I configured a second server, to act as an AirPrint reflector. Unauthenticated AirPrint jobs are received by the second server, then immediately sent to SavaPage, to a queue named print-hold. The CUPS queue on the reflector server is configured to print to SavaPage using a username(AirPrintProxy)/password that is defined in SavaPage. This, combined with allowing all AirPrint jobs to come from a common IP allows me to AirPrint, as an authenticated user(AirPrintProxy), without needing to login to the SavaPage portal first. All jobs show as coming from AirPrintProxy no matter who print but this works for my requirements. Currently, the jobs are received and placed in the SafePages for the AirPrintProxy user that I defined.
What I would like, is for jobs to bypass the SafePages of the AirPrintProxy user and go directly to my PrintOperator user for release to the printer that PrintOperator chooses. I am assuming I will have to do this with with Job Tickets, but I am not sure how to accomplish having the jobs bypass SafePages and go directly to the Job Ticket queue for release.
It would even be ok if I just needed a simple cronjob that would call an API (or similar) to just release the jobs from the SafePages by creating the job ticket automatically.
I managed to get this to work, almost perfectly…. by use of IPP routing rules I can make the jobs automatically show up for the PrintOperator but the IPP routing only allows selection of a specific printer and not the proxy printer group. The PrintOperator is not able to route the job to a different printer, only the printer defined in the IPP routing rule is showing when the PrintOperator looks at the Job Ticket.
Thanks for any help you can offer. If there is a specific section of the manual that covers this, please let me know. No rush for an answer either…. I am just testing scenarios that occur in my environment and getting use to the SavaPage terminology, workflow etc.
Choose a name for a Printer Group that will contain Proxy Printers to which an Operator can release Print Job Tickets. The group name is just a tag and not a separate entity. In this example “MyTicketPrinters” is used.
Edit each Proxy Printer a Job Ticket Operator can print to and make them part of group “MyTicketPrinters” by adding the name of this group to the Proxy Printer Groups field.
Mark these printers as Internal, so they are visible for Job Ticket Operators only.
Create a printer in CUPS, e.g. with name “JOB-TICKET”, that will act as Ticket Printer in SavaPage. Pick a PPD with options that are compatible with the printers in the “MyTicketPrinters” group. Tip: because this Ticket Printer is “virtual”, you can just create a RAW printer with URI file:///dev/null and use a dummy .ppde file to mimic the supported IPP options.
Refresh the Proxy Printer list, edit Proxy Printer “JOB-TICKET”, mark it as Job Ticket Printer and enter “MyTicketPrinters” as printer group with compatible redirect printers.
Edit your “/print-hold” Queue: set IPP Routing to Proxy Printer “JOB-TICKET”.
Important: users that print to “/print-hold” must have role Job Ticket Creator. If not, these jobs are denied. Roles can be set on Group or User level.
Prints to the “/print-hold” Queue are hold as Print Ticket.
Any user with role Job Ticket Operator can open the Job Tickets Web App and release the tickets to a printer that is member of the “MyTicketPrinters” group.