Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#32768 - [cups] default cupsd.conf triggers "Unknown directive DefaultAuthType on line 25."

Attached to Project: Arch Linux
Opened by René Herman (rene) - Tuesday, 20 November 2012, 01:23 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 21 November 2012, 19:28 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



The (arch?) default /etc/cups/cupsd.conf{,.default} files contain the DefaultAuthType directive which is according to cupsd an unknown directive. Probably just a log-esthetic "problem", but given that it might be security related, thought I'd report to someone who might have a clue. Maybe arch-specific if cupsd compiled with/without some option?

To reproduce: start cups and view system log:

e600 cupsd[214]: Unknown directive DefaultAuthType on line 25.

Version: cups-1.6.1-6
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Wednesday, 21 November 2012, 19:28 GMT
Reason for closing:  Upstream
Comment by Andreas Radke (AndyRTR) - Tuesday, 20 November 2012, 14:19 GMT
From cupsd.conf.default:
# Default authentication type, when authentication is required...
DefaultAuthType Basic

What's your setting? Please post the related error.log lines.
Comment by René Herman (rene) - Tuesday, 20 November 2012, 15:01 GMT
That same "DefaultAuthType Basic". As said, this is with the arch default cupsd.conf/cupsd.conf.default. The (single) related line in the (journalctl) log is also as already quoted above:

e600 cupsd[214]: Unknown directive DefaultAuthType on line 25.

In /var/log/cupds/error_log I seem to (or may) have nothing related. There's a lot of:

"AddProfile failed: org.freedesktop.DBus.Error.UnknownMethod:No such interface `org.freedesktop.ColorManager' [ ... ]"

errors, but I don't know if that's related. My printers work fine, by the way.
Comment by Andreas Radke (AndyRTR) - Tuesday, 20 November 2012, 19:26 GMT
Hm. I'm running pure systemd on my server and don't get that msg. Do you use rc.conf compat stuff?

Please set cupsd to debug logging level and check a manual service restart.
Comment by René Herman (rene) - Wednesday, 21 November 2012, 10:04 GMT
This looked like it was it going to be a trivial one...

No, pure systemd system. And just built up from the ground in fact, so also no "legacy" stuff lingering anywhere. While I have the error_log from a CUPS restart attached, I don't believe it's all that relevant: I don't personally see anything related to this in that log (not a clue about the color-manager stuff though). Only that one line in the system log.

Are you quite sure you're not getting this? It's looking to be a fully inconsequential matter of cups having removed that directive -- but in that case, you should be seeing it as well. For me, it's at the end of every "journalctl -b" after every restart of CUPS.

Google found these:

Things that I've tried:

1. Start Avahi.

Don't usually have that running as I've no need for it. Doesn't change this issue (with or without nss-mdns installed and/or enabled in /etyc/nsswitch.conf)

2. Change my current "Listen localhost:631" to "Listen *:631"

With Avahi running, this actually completely stopped CUPS from starting -- but only after saying "Unknown directive DefaultAuthType" like before, so let's not go debug that.

3. Add "Allow localhost" or "Allow @LOCAL" or ...

Just adds an additional "Unknown directive Allow" to the system log, just before the "Unknown directive DefaultAuthType".

The solution these other people posted and you not seeing it seem to imply that this directive ("slash" these directives) are only processed under specific circumstances, but I do get the feeling they're unknown anyway and that the solution will simply be to remove them from the default cups.conf same as that "Browse" directive in the above mentioned closed report -- and from the documentation, since they're also still in there.

Asking the CUPS people will need someone with more clue about CUPS than I have, so I hope you could. It's not hugely important, but if the CUPS configuration AND documentation is lingering CUPS development, that's certainly confusion to users.

I have now just commented out the DefaultAuthType line /etc/cupsd.conf. Works for me. You'll notice from my default printer that I'm not much of a printing person anyway... :-/
Comment by Andreas Radke (AndyRTR) - Wednesday, 21 November 2012, 19:27 GMT
This is what upstream says (M.Sweet), see cups-general ML:

This is a known issue, probably caused by a search and replace at some point. A fix is pending for 1.6.2.

Closing this as upstream and no major funcionality being broken.