we are using cups 1.7 (cups-1.7.5-9.1.x86_64) on SLES 12 as printserver for SAP Retail. Now we notice that when a print job is received by cups-lpd from a user which has umlauts in his SAP username the cups service terminate.
This is the last log entry in cups error_log:
add_job: requesting-user-name=“VG▒BBEL”
The username should be VGÖBBEL.
/var/log/messages shows this
2015-11-27T13:34:25.786133+01:00 plato cupsd[16407]: process 16407: arguments to dbus_message_iter_append_basic() were incorrect, assertion “_dbus_check_is_valid_utf8 (*string_p)” failed in file dbus-message.c line 2676.
thank you for your reply. This is my main problem. I tried to open a service request at novell but they told me, i have only the subscription, no support. I was surprised, that it is possible to buy only the subscription. In our order there was something like BASIC MAINTEANCE, 3 YEAR.
I think this must be a bug in cups or dbus.
I was surprised, that it is possible to buy only the subscription. In our order there was something like BASIC MAINTEANCE, 3 YEAR.
yes, these were available (and in a few places still are). “Basic maintenance” gives you updates, but no individual support. If you can run your own support, you can save some money, but if you cannot, it cuts you off from a valuable resource (SUSE engineering).
I’ll have a look at things tonight, I’m really short on time ATM.
i installed from this repository http://download.opensuse.org/repositories/Printing/SLE_12/ now cups 2.1
The new version behaves exactly in the same manner as 1.7. After receiving a print job from a user with umlauts (berkeley printing protocol port 515 tcp) the cupsd daemon dies:
2015-12-02T08:49:47.790959+01:00 plato cupsd[11963]: process 11963: arguments to dbus_message_iter_append_basic() were incorrect, assertion “_dbus_check_is_valid_utf8 (*string_p)” failed in file dbus-message.c line 2676.
2015-12-02T08:49:47.791188+01:00 plato cupsd[11963]: This is normally a bug in some application using the D-Bus library.
2015-12-02T08:49:47.791321+01:00 plato cupsd[11963]: D-Bus not built with -rdynamic so unable to print a backtrace
2015-12-02T08:49:47.792639+01:00 plato cups-lpd[17189]: Unable to create job - Success
2015-12-02T08:49:47.793295+01:00 plato cups-lpd[17189]: Closing connection
2015-12-02T08:49:47.793768+01:00 plato xinetd[11766]: EXIT: printer status=1 duration=1(sec)
…
… 2015-12-02T08:50:30.253795+01:00 plato xinetd[11766]: START: printer from=10.126.195.97
2015-12-02T08:50:30.256522+01:00 plato cups-lpd[17229]: Connection from dosap61.xxxx.com (IPv4 10.126.195.97)
2015-12-02T08:50:30.256806+01:00 plato cups-lpd[17229]: Send queue state (long) for d149
2015-12-02T08:50:30.259209+01:00 plato cups-lpd[17229]: Unable to connect to server /run/cups/cups.sock: Bad file descriptor
2015-12-02T08:50:30.259453+01:00 plato cups-lpd[17229]: Closing connection
2015-12-02T08:50:30.259736+01:00 plato xinetd[11766]: EXIT: printer status=1 duration=0(sec)
i compiled cups-2.1.0-189.1.src.rpm now without dbus function (–disable-dbus). Now printing works as expected. Does anybody knows what restrictions cups now have without dbus?
sorry for not answering with details sooner… I’m off-site for a few days.
i compiled cups-2.1.0-189.1.src.rpm now without dbus function (–disable-dbus). Now printing works as expected. Does anybody knows what restrictions cups now have without dbus?
I’ll forward your questions to my SUSE contacts for comments… but don’t hold your breath, please
Cups (since 1.3.4) does not support iso8859 encodings anymore. So any client needs to be able to send UTF-8-encoded content.
You wrote that SAP on the same SLES12 server is one of the sources of non-UTF-8 user names - I suggest to contact them, it may well be that they’re passing through umlaut-containing user names from MS Windows environments in a binary fashion. This would need fixing in the SAP layer, either by converting when receiving such “content” by a UTF-8 component (SAP on a UTF-8 server) or when handing out to other subsystems on such a server (i.e. when forwarding data to CUPS).
I don’t have any details, but probably they have this covered for the actual printing data and just omitted conversions for user names…
Before SLES 12 we were using openSuSE 11.1 with cups 1.3.5 and we did not have such problems.
The SAP System has its own user management and the SAP System is not a unicode system. By submitting a print job via berkeley printing protocol from a user who has umlauts in his username cups dies. I can’t imagine that i have to fix something in the SAP System (or in any other non unicode system) in order that the cups daemon won’t die again. Without dbus in cups it works.
I am really sure that this is a bug in cups and has to be fixed. I can’t find anything in the documentation that says don’t try to print with lpr from a non unicode system, because cups don’t support this.
this got me thinking for a moment, too - but my bet is that your OpenSUSE 11.1 system was set up to use ISO8859-15, rather than UTF-8.
From my experience with mixed-encoding environments, I can not only imagine this, but am rather sure that the source of the trouble. Hence my earlier suggestion to talk to SAP as well.
I’ve not have to deal with SAP yet, but to me its design seems to be rather “MS Windows”-minded. So it wouldn’t surprise me that much if is code page handling would suffer from the typical differences.
[QUOTE]
Since CUPS 1.3.4 only UTF-8 (which includes 7-bit ASCII)
is supported.
Consequences:
The cupsd accepts only UTF-8 encoded data.
Therefore applications communicating with the cupsd
such as printer setup tools or printer dialog tools
do no longer work if neither a plain 7-bit ASCII
nor a UTF-8 locale is used for the user who runs
such applications.
Printing Legacy Encoded Text Files:
The printing system no longer converts legacy encoded
text files such as ISO-8859-1, windows-1252,
and Asian encodings on its own.
Only UTF-8 and thus ASCII is supported.
To print a legacy encoded text file, you must convert it
from its encoding (only you can know it) to the universal
UTF-8 encoding before sending it to the CUPS server.
To print an ISO-8859-1 text file, you may use:
iconv -f iso-8859-1 -t utf-8 filename.txt | lp -d printer
Printing of PDF or PS or graphics files (JPEG, PNG, etc.)
works as before.[/QUOTE]
