PDA

View Full Version : SLES 12 Problem with cups



kmeyer1
01-Dec-2015, 10:32
Hello,

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.

How can we fix this?

Regards
Klaus

jmozdzen
01-Dec-2015, 12:30
Hi Klaus,

> How can we fix this?

your best bet is to open a service request with SUSE - this is something that, AFAICT, needs to be fixed within programming.

Regards,
Jens

kmeyer1
01-Dec-2015, 12:45
Hello Jens,

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.

Now i don't know how to go on.

Regards
Klaus

jmozdzen
01-Dec-2015, 13:18
Hi Klaus,

> 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.

Regards,
Jens

kmeyer1
02-Dec-2015, 09:09
Hi Jens,

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)

Regards
Klaus

kmeyer1
02-Dec-2015, 11:27
Hello,

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?

Regards,
Klaus

jmozdzen
03-Dec-2015, 12:32
Hi Klaus,

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 :)

Regards,
Jens

jmozdzen
15-Dec-2015, 12:33
Hi Klaus,

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...

Regards,
Jens

kmeyer1
22-Dec-2015, 10:31
Hi Jens,

thank you very much for your effort.


Cups (since 1.3.4) does not support iso8859 encodings anymore. So any client needs to be able to send UTF-8-encoded content.
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.

Perhaps i try to report this issue in bugzilla.

Kind regards,

Klaus

jmozdzen
22-Dec-2015, 11:46
Hi Klaus,

Before SLES 12 we were using openSuSE 11.1 with cups 1.3.5 and we did not have such problems.

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.


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.

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.

I've checked the archives and found the following thread from 2010: http://comments.gmane.org/gmane.comp.printing.cups.general/26873 - Johannes to me is authoritative on the subject...



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.

Best regards & seasonal greetings,
Jens