The queue is added or re-installed, other queues are left untouched.
To inspect the list of queues, select: Show currently installed printers
You will be prompted for confirmation
for all commands that will change the print spooler configuration on your system.
This is just for your info, to see what is going on but not really to read all the details.
This should work on all Linux systems or at least show a message
that makes sense.
If installation seems to work but you still cannot print:
Inspect /var/log/cups/error_log for one of these messages:
(/usr/lib/cups/backend/smb) exited with no errors. Submitting the job should have succeeded, there is very probably a general printing error
(/usr/lib/cups/backend/smb) stopped with status 1. Then you may also see:
Connection failed: NT_STATUS_IO_TIMEOUT You can only connect to the printserver on the campus or through VPN
(/usr/lib/cups/backend/smb) stopped with status 2. Authentication required or bad password
And if that does not help:
Mail v.b.huijgen at tue.nl
, whatever you prefer.
Below follows the whole story.
Just a summary, despite its size, of the background information
that led to install_printers.sh .
Access to the Konica Minolta printers requires :
an account in the Active Directory (Exchange)
By now, most employees do have that account but Linux users need to be aware
that they need to use that account for "printing", sending jobs to the print queue.
Your campus card, that is:
it needs to be registered for printer access
you need to have it at hand to actually print jobs from the queue.
Printing without installation
If you want to print without installation,
you can only print files in PDF and a few other formats.
You cannot directly print window contents such as webpages and spreadsheets
from a running application.
So you need to capture the contents in a file first.
Most applications provide an option to
Export as PDF...
Print to file...
the window contents to a PDF file.
You can only follow default finishing options
as installed on the printserver.
That is probably A4, double sided, portrait, long binding, no punching.
Have your TUE card at hand and get a printout at a printer
You may know smbclient as a browser for file shares,
but it can also "browse" printer-queues, which are also shares in Windows parlance.
And it can "write" into such shares which is another word for printing.
smbclient -k //tueprint.campus.tue.nl/MFP-CAMPUS-PS
That is, without -Workgroup and -User
No password required
Have your TUE card at hand and get a printout at a printer
If the default tueprinter finishing options
cater your needs, this command is all you need for printing.
You could wrap one of these procedures into a shortcut which you could wrap into
a customized desktop menu-item.
Installing the printer
To be precise, we are going to install:
the client references to the printer queue
an authentication method
Since packaging depends on your Linux distribution,
here are just the names of the executables that you need to install:
Use your package manager to find out which packages provide them.
Required configuration - cups server
Using the print configuration wizard
The printer wizzard is system-config-printer .
You can start that from the commandline or try to find a printer icon
in the desktop menu structure.
The print configuration wizzard
has no option to do it right so that IMHO it should NOT be used.
In more detail, it only provides options:
to install your plain password in /etc/cups/printers.conf .
Moreover, it does not warn therefore.
to forget to install the trigger for the password dialogue so that you cannot authenticate at all for printing
(unless you happen to have a Kerberos ticket ready)
Devices → Network Printer → Windows Printer via SAMBA
printserver / printerqueue :
Option 1: for a single plain password
If you choose to Set authentication details now:
Prompt user if authentication is required
Set authentication details now
Username: john Password: ......
the password will be included correctly in /etc/cups/printers.conf
That is, in plain form, for which you get no warning from the printer wizzard.
Option 2: for credentials by dialogue
You may try to check
Prompt user if authentication is required
Set authentication details now
but no prompt will appear, in a later stage of the printer wizard and not when starting a printjob,
because the printer wizard forgets to insert the necessary directives into the configuration
to trigger the necessary credential dialogues.
This happens to be the correct preparation for kerberos authentication.
Option 3: prepare for kerberos
The printer configuration wizard has no direct support to configure
You could however:
Follow the configuration procedure for credentials by dialogue,
select Prompt user if authentication is required
After loading the database of known printers, the Driver dialogue will appear.
Actually, the driver for most printertypes is already known to be the cups filter
but it needs to be pointed yet to a printer-specific set of PostScript instructions
to insert for finishing options such as double-sided and orientation.
These PostScript instructions are published by suppliers as PPD files,
one of which you need to select.
At the time of writing, no PPD-file for the printer Konica Minolta C364 is available from the database,
so click the option to Provide a PPD file...
Select printer from database
Provide PPD file
Search for a printer driver to download
PostScript Printer Description (PPD) files can often be found...
When prompted later for credentials, you can omit the prefix TUE\ for your username
because it is already included in the DeviceURI
is a hint for applications, such as document viewers and browsers, to prompt the user for credentials
when a printjob is started.
and then pass these credentials to the cups server.
The credentials dialogue may supply an option to remember your password, that is, to store it in your keyring.
And if you confirm that option, the next and following jobs should not trigger the credentials dialogue anymore.
If it does not work that way, you may want to read the chapter
Option 3: prepare for kerberos
This ppd-file already reflects most of the options on our printers.
There are a few options that can be ordered separately at our site,
so that they are really installable options
which you may need to post-edit.
That can be done using one of the ppd-editors:
gnome-control-center, Printers, a printer, Options
system-config-printer, a printer, Properties
Depending on desktop policies, you may need to "unlock" access to the printer settings.
Required configuration - cups clients
This is for all printer clients and GUI tools for printer settings.
Make sure that cupsd is Listening to the ServerName
that you point the clients to.
Print job processing
Print jobs are usually initiated by document applications and held in a local queue by the cups server.
Document application print backends
Most document applications (viewers, editors, browsers) have an option to print the document.
That option is implemented by a print backend.
Unfortunately, there is no common print backend that is shared by all document applications.
So if printing, especially authentication, does not work as expected,
this message may help you to find a solution or workaround.
A few examples follow below:
The gtk3 libraries provide a cups print backend which is used by
evince, the document viewer
and maybe more.
The okular document application provides its own print backend which starts
the commandline lpr for printjobs.
Queue manager clients
As long as the jobs reside in the queue, on purpose or waiting for some error to be fixed, they can be managed by one of these queue managers:
A browser pointing to http://localhost:631
This is not only a configuration tool but also a queue manager
The applet version starting with closed windows
If your job is not submitted to the tueprinter queue,
start one of these queue managers and inspect the local queue.
Maybe your job is waiting for authentication.
The entry in /etc/cups/printers.conf
is a hint for both document application print backends and queue managers
to prompt the user for credentials and pass them to the cups server.
After changing your password...
in the Active Directory, it is NOT automatically changed in your keyring.
To force a keyring update, start the keyring manager (seahorse) and delete entry
Missing option to remember password
There was a flaw in gtk3 versions < 3.13.8 in the credentials (username, password)
dialogue, documented as bug 674264:
Credentials from gnome-keyring is not used while printing
so that you would need to enter credentials for each printjob.
On most Linux distributions, an indirect effect was that credentials dialogues could appear both without and with option to remember password.
In more detail, when starting a print job from evince:
the credentials were first requested by the gtk3 print backend,
by a dialogue without option to remember password
and, but not specifically
for gtk3 versions < 3.13.8 , with these initial values:
Username: the local username
After accidently (or on purpose, for testing) entering wrong credentials,
on a Linux distribution that has the
queuemanager-client also present and running,
that queuemanager-client would open a second dialogue which does provide an option
to remember the password.
After entering in this second credentials dialogue:
proper credentials (as proved by successfully finishing the job)
confirmation to remember the password (that is, in your keyring)
, starting the next job would still cause
the gtk3 dialogue (as you can see by the missing option to remember password) to appear,
instead of automatically retrieving credentials from the keyring.
And, on systems that have system-config-printer version < 1.4.4,
the second dialogue would only appear with the -applet version,
see redhat bug 999297
You can still print and authenticate with that bug,
but you need to explicitly start system-config-printer, open the printer, its queue,
find the job that is "Held for authentication",
select that job and open the dialogue to authenticate.
All these indirect effects of the gtk3 bug and the mixture of different credentials dialogues,
with and without option to save password, were very confusing.
The gtk3 bug was solved in August 2014.
But the solution may not have propagated yet to
your distribution or your update thereof in December 2014,
when this document with instructions for authenticated printing needed to be available for Linux users.
Especially for the Fedora distribution, the solution was included in Fedora 21,
for which the test stage was finished December 2014.
If you cannot easily upgrade gtk3 to version 3.13.8 or higher,
here is how to avoid repeatedly entering credentials, unfortunately not completely
avoiding the appearance of credential dialogues:
Ensure that system-config-printer-applet is running.
It may already be started as a session service on each login session by one of:
gnome-session-properties, for desktop type gnome
system-config-services, for desktop type xfce
Start a document viewer such as evince and start a printjob from there
It will open a credentials dialogue without option Remember password
just click OK...
you do not need to
correct any difference between the local username and that of the Active Directory
enter a password
... forcing the first execution of /usr/lib/cups/backend/smb to return an authentication failure
open another dialogue, with option Remember password, where you
now do enter your credentials
confirm Remember password, to remember not only the password but also:
the required Username
the relation to this printqueue
by storing them in your keyring.
restart the job, which should succeed now
Now the next and following printjobs can proceed as follows:
Just click OK on the first credentials dialogue, the one without option Remember password
system-config-printer-applet will supply credentials automatically from the keyring
Present but failing option to remember password
In case you're still with me:
The previous procedure to fallback to system-config-printer as (client of) the queuemanager
unfortunately fails if its version is less then 1.3.13 .
I do not have a direct bug reference at hand, but my own small test reported a Cancelled error
after checking the box to remember password, in update_job_keyring_attrs, as reported by
If your version of system-config-printer has this bug,
you can still print and authenticate but not have your password remembered.
Kerberos ticket procedures
What is kerberos and why should I care ?
Kerberos tickets provide authentication to the Active Directory.
That provides access to services such as printing, mail, address lists, calendar and network drives.
Using kerberos authentication obviate the need:
to keep a plain password in /etc/cups/printers.conf
to enter credentials for print backends that still do not use the keyring
to propagate password changes from the Active Directory to your keyring,
for print backends that do use the keyring.
That is, manually, for several entries,
at least one for each smb://printserver .
Because there is currently no common way to tag all these "different" credentials
as originating from the same directory.
Note that the gtk3 print backend, even after fixing
happily keeps using the old invalid password from the keyring,
instead of prompting for a new one.
So authentication fails silently and you need to start a
queue manager to find what is going on.
Kerberos configuration /etc/krb5.conf
Before you create a kerberos ticket,
you need to make sure that
the realm is CAMPUS.TUE.NL
the domaincontrollers are known
which can be done in two ways:
Explicit settings in /etc/krb5.conf
If you choose to have explicit settings, you need to include or update these entries:
default_realm = CAMPUS.TUE.NL
dns_lookup_realm = false
dns_lookup_kdc = true
# That is, for campus.tue.nl apply dns-lookup for: _ldap._tcp.campus.tue.nl
Especially, make sure that the default_realm
is notEXAMPLE.COM , as shipped with older kerberos versions.
With newer kerberos versions, this is already included as comment so that it is really an example.
Except for the realm, these settings are the default settings.
With dns_lookup_kdc enabled, domain controllers for campus.tue.nl
are queried in DNS, as you can replay by the query:
host -t srv _ldap._tcp.campus.tue.nl
Empty and default configuration
Since the necessary settings, especially dns_lookup_kdc=true,
are default, you could as well setup an empty kerberos configuration.
This can be done by one of:
KRB5_CONFIG=/dev/null in process environment.
This may be useful if you just want to run
kinit followed by a few
smblient -k -c print
commands with minimal configuration changes.
For the smb backend,
you would need to make sure that it
also has this entry in its process environment.
Creating a kerberos ticket
on Linux systems in the TU/e domain
Such as the Fedora 18 systems at the department of
Mathematics and Computer Science.
You already have a valid kerberos ticket since you logged in.
with the realmCAMPUS.TUE.NL
You need to repeat this procedure every few days, so that you may not like this option.
Applying a kerberos ticket
Kerberos tickets are applied by smbclients:
the print commandsmbclient -k -c print < file.pdf
The option -k explicitly attempts kerberos authentication
obviating the need to supply the
the smbbackend for cups:
which will use the ticket for authentication if no other source of credentials:
/etc/cups/printers.conf: DeviceURI smb://username:plainpasswd@TUE/tueprint...
dialogue or keyring, triggered by
/etc/cups/printers.conf: AuthInfoRequired: username,password
It needs to have access of course to the kerberos ticket.
In cupsd.conf (cups version <= 1.4)
or cups-files.conf (cups version >= 1.5) ,
you need to include:
that is your Linux username, instead of lp,
on your local Linux desktop system.
On systems with enhanced security:
with systemd, cupsd
is probably running with PrivateTmp=true
so that the usual /tmp/krb5cc_userid
is not accessible.
As a workaround, you could move the ticket to your homedirectory,
for example $HOME/.krb5cc by having process environment
in your shell before running kinit
in the process environment of smb-backend,
to be supplied by a wrapper.
with selinux enabled,
any descendants of the cupsd server,
disregarding their ownership, do not have access
So for now, it will not work on systems with both security features.
You have to disable at least one of them.
(or for selinux, fallback to a more permissive mode)
The smb-backend's authentication procedure is hard to monitor
since it sends its messages, including those about authentication procedures
that you may expect to be debug messages,
to stdout which is equivalent to /dev/null
in the context provided by the cupsserver.
You could wrap smb in a script
that redirects stdout to stderr
which is redirected in the cups server context to
so that smb's authentication-procedure messages will appear in that file.
In case you care about access for writing into error_log:
Since stderr is inherited from the main cupsd process
which has access to write into error_log,
the Group and User settings
in cups-files.conf do not matter for
the smb-backend's (or its wrapper's)
write access to error_log.
(And that inheritance is not obstructed by selinux,
in case you have installed and enabled that).