Re: Unreadable YUM cron job logs.
On 2012-10-30 13:46, Andrew Schretter wrote: The problem is caused by bad RPMs that write out text during install/update/etc and that text happens to contain non printable ASCII characters (like a carriage return character or some garbage like that). The mail program on linux sees these characters and automatically converts the mail to base64 before sending it. The patch I have to fix it is to put a " /usr/bin/tr -cd '\11\12\40-\176' " to filter the yum response before it is mailed. Works for me : Why not just change that UUoC to "cat -v"? As for the thunderbird issue, possibly related: https://bugzilla.mozilla.org/show_bug.cgi?id=333880 https://bugzilla.mozilla.org/show_bug.cgi?id=535584 https://bugzilla.mozilla.org/show_bug.cgi?id=580017 / Delreich
Re: Unreadable YUM cron job logs.
Sorry for the delay, I've been out of the office. I'll take a closer look at this patch some time this week. Pat On 10/30/2012 07:46 AM, Andrew Schretter wrote: On 10/29/2012 08:08 PM, Steven Haigh wrote: On 27/10/2012 1:36 PM, Steven Haigh wrote: On 27/10/2012 10:58 AM, David Sommerseth wrote: Content-Type: application/octet-stream This is somewhat odd, I'd expect this to be text/plain or something in that direction. But that's set based on the data the mailer receives. If it contains some control characters or other binary bytes, it might flip over to octet-stream. Content-Transfer-Encoding: base64 ^^ The mail is encoded as base64. At first glance, the mail headers looks appropriate to me. Which makes me wonder what kind of mail client you use? The problem is caused by bad RPMs that write out text during install/update/etc and that text happens to contain non printable ASCII characters (like a carriage return character or some garbage like that). The mail program on linux sees these characters and automatically converts the mail to base64 before sending it. The patch I have to fix it is to put a " /usr/bin/tr -cd '\11\12\40-\176' " to filter the yum response before it is mailed. Works for me : --- /etc/cron.daily/yum-autoupdate.bak 2012-09-10 10:25:37.0 -0400 +++ /etc/cron.daily/yum-autoupdate 2012-09-25 14:55:11.535869852 -0400 @@ -322,7 +323,7 @@ echo " Mail Needs To Be Sent" echo " /bin/mail -s \"YUM:$HOSTNAME:$TODAY\" $MAILLIST " fi - cat $TEMPMAILFILE | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST + cat $TEMPMAILFILE | /usr/bin/tr -cd '\11\12\40-\176' | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST fi else if [ "$DEBUG" = "true" ] ; then @@ -330,7 +331,7 @@ echo " Mail Needs To Be Sent" echo "/bin/mail -s \"YUM:$HOSTNAME:$TODAY\" $MAILLIST " fi - cat $TEMPMAILFILE | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST + cat $TEMPMAILFILE | /usr/bin/tr -cd '\11\12\40-\176' | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST fi fi fi -- Pat Riehecky Scientific Linux Developer
Re: Unreadable YUM cron job logs.
On 10/29/2012 08:08 PM, Steven Haigh wrote: > On 27/10/2012 1:36 PM, Steven Haigh wrote: >> On 27/10/2012 10:58 AM, David Sommerseth wrote: Content-Type: application/octet-stream >>> >>> This is somewhat odd, I'd expect this to be text/plain or something in >>> that direction. But that's set based on the data the mailer receives. >>> If it contains some control characters or other binary bytes, it might >>> flip over to octet-stream. >>> Content-Transfer-Encoding: base64 >>> ^^ >>> The mail is encoded as base64. At first glance, the mail headers looks >>> appropriate to me. Which makes me wonder what kind of mail client you >>> use? The problem is caused by bad RPMs that write out text during install/update/etc and that text happens to contain non printable ASCII characters (like a carriage return character or some garbage like that). The mail program on linux sees these characters and automatically converts the mail to base64 before sending it. The patch I have to fix it is to put a " /usr/bin/tr -cd '\11\12\40-\176' " to filter the yum response before it is mailed. Works for me : --- /etc/cron.daily/yum-autoupdate.bak 2012-09-10 10:25:37.0 -0400 +++ /etc/cron.daily/yum-autoupdate 2012-09-25 14:55:11.535869852 -0400 @@ -322,7 +323,7 @@ echo " Mail Needs To Be Sent" echo " /bin/mail -s \"YUM:$HOSTNAME:$TODAY\" $MAILLIST " fi - cat $TEMPMAILFILE | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST + cat $TEMPMAILFILE | /usr/bin/tr -cd '\11\12\40-\176' | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST fi else if [ "$DEBUG" = "true" ] ; then @@ -330,7 +331,7 @@ echo " Mail Needs To Be Sent" echo "/bin/mail -s \"YUM:$HOSTNAME:$TODAY\" $MAILLIST " fi - cat $TEMPMAILFILE | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST + cat $TEMPMAILFILE | /usr/bin/tr -cd '\11\12\40-\176' | /bin/mail -s "YUM:$HOSTNAME:$TODAY" $MAILLIST fi fi fi -- Andrew Schretter Systems Programmer, Duke University Dept. of Mathematics (919) 660-2866
Re: Unreadable YUM cron job logs.
On 27/10/2012 1:36 PM, Steven Haigh wrote: On 27/10/2012 10:58 AM, David Sommerseth wrote: Content-Type: application/octet-stream This is somewhat odd, I'd expect this to be text/plain or something in that direction. But that's set based on the data the mailer receives. If it contains some control characters or other binary bytes, it might flip over to octet-stream. Content-Transfer-Encoding: base64 ^^ The mail is encoded as base64. At first glance, the mail headers looks appropriate to me. Which makes me wonder what kind of mail client you use? Thats pretty much what I see as well... The mail client is Thunderbird 16.0.1 on Windows 7 - so I wouldn't expect issues here... but you never know. If you take that "gibberish blob" below and send it through 'base64 -d' or 'openssl base64 -d', then you'll get something quite readable out. So from what I see, it should be all good. Yeah, I couldn't see anything at first glance either... I'm suspecting a mail client which doesn't parse the Content-Transfer-Encoding field very well - or that it rejects to display mails with application/octet-stream. Maybe - but I'd expect thunderbird would do the right thing? :\ For what its worth, I also looked at these emails on my iPad. They come up with an attachment and no actual content in the body of the email. CC'ing Pat & sl-devel for comment - as I'm pretty sure the yum auto-update plugin isn't default in TUV... Link address for full thread: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1210&L=scientific-linux-users&T=0&P=15732 -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 smime.p7s Description: S/MIME Cryptographic Signature
Re: Unreadable YUM cron job logs.
On 27/10/2012 10:58 AM, David Sommerseth wrote: Content-Type: application/octet-stream This is somewhat odd, I'd expect this to be text/plain or something in that direction. But that's set based on the data the mailer receives. If it contains some control characters or other binary bytes, it might flip over to octet-stream. Content-Transfer-Encoding: base64 ^^ The mail is encoded as base64. At first glance, the mail headers looks appropriate to me. Which makes me wonder what kind of mail client you use? Thats pretty much what I see as well... The mail client is Thunderbird 16.0.1 on Windows 7 - so I wouldn't expect issues here... but you never know. If you take that "gibberish blob" below and send it through 'base64 -d' or 'openssl base64 -d', then you'll get something quite readable out. So from what I see, it should be all good. Yeah, I couldn't see anything at first glance either... I'm suspecting a mail client which doesn't parse the Content-Transfer-Encoding field very well - or that it rejects to display mails with application/octet-stream. Maybe - but I'd expect thunderbird would do the right thing? :\ -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 smime.p7s Description: S/MIME Cryptographic Signature
Re: Unreadable YUM cron job logs.
On 26/10/12 21:03, Steven Haigh wrote: Hi all, Recently I've noticed a trend to get some logs from yum updates that happen automatically that don't display. Looking at the message source, I see: Return-Path: Delivered-To: net...@crc.id.au Received: from xenhost.lan.crc.id.au (unknown [IPv6:2002:cb38:f71b:1:52e5:49ff:fe4d:4af6]) by mail.crc.id.au (Postfix) with ESMTP id 9566D9E for ; Sat, 27 Oct 2012 04:12:57 +1100 (EST) Received: by xenhost.lan.crc.id.au (Postfix) id CC9A412A; Sat, 27 Oct 2012 04:12:56 +1100 (EST) Delivered-To: r...@xenhost.lan.crc.id.au Received: by xenhost.lan.crc.id.au (Postfix, from userid 0) id BE3B614D; Sat, 27 Oct 2012 04:12:56 +1100 (EST) Date: Sat, 27 Oct 2012 04:12:56 +1100 To: r...@xenhost.lan.crc.id.au Subject: YUM:xenhost.lan.crc.id.au:2012-10-27 User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: application/octet-stream This is somewhat odd, I'd expect this to be text/plain or something in that direction. But that's set based on the data the mailer receives. If it contains some control characters or other binary bytes, it might flip over to octet-stream. Content-Transfer-Encoding: base64 ^^ The mail is encoded as base64. At first glance, the mail headers looks appropriate to me. Which makes me wonder what kind of mail client you use? The message that is in my cron folder shows as blank. While I'm not an expert in email formatting, is it possible the encoding is incorrect causing it not to display properly? This one isn't really my field of expertise... If you take that "gibberish blob" below and send it through 'base64 -d' or 'openssl base64 -d', then you'll get something quite readable out. So from what I see, it should be all good. I'm suspecting a mail client which doesn't parse the Content-Transfer-Encoding field very well - or that it rejects to display mails with application/octet-stream. kind regards, David Sommerseth
Re: Unreadable YUM cron job logs.
On 27/10/2012 6:29 AM, Stephen John Smoogen wrote: Something in the mail system is encoding this as base64 but not putting in the mime headers to tell you that.. I don't think that this is done via cron or yum so I would check to see how the postfix or some option in between I'm sure its *something* to do with the yum auto-updates plugin - as all other messages / cron job logs get delivered fine. The *only* ones that appear blank (even though you can see some content in the message source) are the ones marked YUM: in the subject. I can reproduce this on at least 4 systems... -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 smime.p7s Description: S/MIME Cryptographic Signature
Re: Unreadable YUM cron job logs.
On 26 October 2012 13:03, Steven Haigh wrote: > Hi all, > > Recently I've noticed a trend to get some logs from yum updates that happen > automatically that don't display. Looking at the message source, I see: Something in the mail system is encoding this as base64 but not putting in the mime headers to tell you that.. I don't think that this is done via cron or yum so I would check to see how the postfix or some option in between http://www.opinionatedgeek.com/dotnet/tools/base64decode/ will show you the unencoded message. > Return-Path: > Delivered-To: net...@crc.id.au > Received: from xenhost.lan.crc.id.au (unknown > [IPv6:2002:cb38:f71b:1:52e5:49ff:fe4d:4af6]) > by mail.crc.id.au (Postfix) with ESMTP id 9566D9E > for ; Sat, 27 Oct 2012 04:12:57 +1100 (EST) > Received: by xenhost.lan.crc.id.au (Postfix) > id CC9A412A; Sat, 27 Oct 2012 04:12:56 +1100 (EST) > Delivered-To: r...@xenhost.lan.crc.id.au > Received: by xenhost.lan.crc.id.au (Postfix, from userid 0) > id BE3B614D; Sat, 27 Oct 2012 04:12:56 +1100 (EST) > Date: Sat, 27 Oct 2012 04:12:56 +1100 > To: r...@xenhost.lan.crc.id.au > Subject: YUM:xenhost.lan.crc.id.au:2012-10-27 > User-Agent: Heirloom mailx 12.4 7/29/08 > MIME-Version: 1.0 > Content-Type: application/octet-stream > Content-Transfer-Encoding: base64 > Message-Id: <20121026171256.be3b6...@xenhost.lan.crc.id.au> > From: r...@xenhost.lan.crc.id.au (root) > > IC0tLS0tLS0tLS0tLS0tLS0tLS0tCiBZVU0gLSBzZWN1cml0eQogLS0tLS0tLS0tLS0tLS0t > LS0tLS0KCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 > PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CiBQYWNrYWdlICAgICAgICAgICAg > ICAgQXJjaCAgICAgICAgICBWZXJzaW9uICAgICAgICAgICAgUmVwb3NpdG9yeSAgICAgICAg > IFNpemUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 > PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KVXBkYXRpbmc6CiB4ZW4gICAgICAg > ICAgICAgICAgICAgeDg2XzY0ICAgICAgICA0LjIuMC00LmVsNiAgICAgICAga2VybmVsLXhl > biAgICAgICAgMS4wIE0KIHhlbi1kb2MgICAgICAgICAgICAgICB4ODZfNjQgICAgICAgIDQu > Mi4wLTQuZWw2ICAgICAgICBrZXJuZWwteGVuICAgICAgICA5ODIgawogeGVuLWh5cGVydmlz > b3IgICAgICAgIHg4Nl82NCAgICAgICAgNC4yLjAtNC5lbDYgICAgICAgIGtlcm5lbC14ZW4g > ICAgICAgIDQuMyBNCiB4ZW4tbGlicyAgICAgICAgICAgICAgeDg2XzY0ICAgICAgICA0LjIu > MC00LmVsNiAgICAgICAga2VybmVsLXhlbiAgICAgICAgMzQ0IGsKIHhlbi1saWNlbnNlcyAg > ICAgICAgICB4ODZfNjQgICAgICAgIDQuMi4wLTQuZWw2ICAgICAgICBrZXJuZWwteGVuICAg > ICAgICAgNDUgawogeGVuLXJ1bnRpbWUgICAgICAgICAgIHg4Nl82NCAgICAgICAgNC4yLjAt > NC5lbDYgICAgICAgIGtlcm5lbC14ZW4gICAgICAgIDUuNyBNCgpUcmFuc2FjdGlvbiBTdW1t > YXJ5Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 > PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClVwZ3JhZGUgICAgICAgNiBQYWNrYWdl > KHMpCgpUb3RhbCBkb3dubG9hZCBzaXplOiAxMiBNClN0b3BwaW5nIHhlbmNvbnNvbGVkIGRh > ZW1vbjogWyAgT0sgIF0NClN0YXJ0aW5nIHhlbmNvbnNvbGVkIGRhZW1vbjogWyAgT0sgIF0N > ClN0b3BwaW5nIHhlbmQgZGFlbW9uOiBbICBPSyAgXQ0KU3RhcnRpbmcgeGVuZCBkYWVtb246 > IFsgIE9LICBdDQoKVXBkYXRlZDoKICB4ZW4ueDg2XzY0IDA6NC4yLjAtNC5lbDYgICAgICAg > ICAgICAgICAgIHhlbi1kb2MueDg2XzY0IDA6NC4yLjAtNC5lbDYgICAgICAgICAKICB4ZW4t > aHlwZXJ2aXNvci54ODZfNjQgMDo0LjIuMC00LmVsNiAgICAgIHhlbi1saWJzLng4Nl82NCAw > OjQuMi4wLTQuZWw2ICAgICAgICAKICB4ZW4tbGljZW5zZXMueDg2XzY0IDA6NC4yLjAtNC5l > bDYgICAgICAgIHhlbi1ydW50aW1lLng4Nl82NCAwOjQuMi4wLTQuZWw2ICAgICAKCgo= > > The message that is in my cron folder shows as blank. While I'm not an > expert in email formatting, is it possible the encoding is incorrect causing > it not to display properly? This one isn't really my field of expertise... > > -- > Steven Haigh > > Email: net...@crc.id.au > Web: http://www.crc.id.au > Phone: (03) 9001 6090 - 0412 935 897 > Fax: (03) 8338 0299 > -- Stephen J Smoogen. "Don't derail a useful feature for the 99% because you're not in it." Linus Torvalds "Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
