[opensuse] cron job email attachment.bin
My daily backup script on a server mails the output to me (it's a cron job run by root). Recently, instead of sending me a plain text email message, it's started sending me an empty email with an attachment called 'attachment.bin'. This is just a plain text file with the same old content. Does anybody know how to make it send me plain text messages again? The only notable difference I can see in the messages is this header: < Content-Type: text/plain; charset=us-ascii ---
Content-Type: application/octet-stream; charset=us-ascii
I certainly haven't deliberately changed any settings, but is there a setting somewhere that controls this header? Does it depend on the settings on intermediate boxes that the mail passes through? The server is running Suse 9.2. Thanks and regards, Dave Howorth -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Dave Howorth wrote:
My daily backup script on a server mails the output to me (it's a cron job run by root). Recently, instead of sending me a plain text email message, it's started sending me an empty email with an attachment called 'attachment.bin'. This is just a plain text file with the same old content.
Does anybody know how to make it send me plain text messages again?
The only notable difference I can see in the messages is this header:
< Content-Type: text/plain; charset=us-ascii ---
Content-Type: application/octet-stream; charset=us-ascii
If there are characters in the mail not covered by ascii7 mail is automatically send as "application/octet-stream". This might happen if you have file names with strange characters. Instead of directly mailing the output you could save it into a file and use mime::lite to send it. #!/usr/bin/perl use MIME::Lite; ### Create a new message: $msg = MIME::Lite->new( From => 'sender@example.com', To => 'recipient@example.com', # Cc => 'morerecipients@example.com', Subject => 'backup result', Date => `date`, Type => 'text/plain', Encoding => 'base64', Path => '/path/to/file/', ); $msg->send;
I certainly haven't deliberately changed any settings, but is there a setting somewhere that controls this header? Does it depend on the settings on intermediate boxes that the mail passes through?
The server is running Suse 9.2.
You should probably update your server, 9.2 is no longer supported. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
Dave Howorth wrote:
My daily backup script on a server mails the output to me (it's a cron job run by root). Recently, instead of sending me a plain text email message, it's started sending me an empty email with an attachment called 'attachment.bin'. This is just a plain text file with the same old content.
Does anybody know how to make it send me plain text messages again?
The only notable difference I can see in the messages is this header:
< Content-Type: text/plain; charset=us-ascii ---
Content-Type: application/octet-stream; charset=us-ascii
If there are characters in the mail not covered by ascii7 mail is automatically send as "application/octet-stream". This might happen if you have file names with strange characters.
Good idea. But there's nothing greater than 122 ('z') in attachment.bin. The man page for nail actually says: "Otherwise, or if the filename has no extension, the content types text/plain or application/octet-stream are used, the first for text or international text files, the second for any file that contains formatting characters other than newlines and horizontal tabulators." But the only control character in the file is 10 (newline) :(
Instead of directly mailing the output you could save it into a file and use mime::lite to send it.
Sorry, it's not me that's mailing this. It's cron.
You should probably update your server, 9.2 is no longer supported.
Yes, it's in the queue of things to do :) I would have moved to 10.1
but that seemed to be a real dog, so now I'm being even more cautious
before moving to 10.2.
Thanks, Dave
FWIW, this is what /var/log/mail has to say on the server:
Jan 29 05:58:28 suse1 postfix/pickup[14756]: 1FED528317: uid=0 from=<root>
Jan 29 05:58:28 suse1 postfix/cleanup[14780]: 1FED528317:
message-id=<45BD8D03.mailBE81ISU8G@suse1.lmb.internal>
Jan 29 05:58:28 suse1 postfix/qmgr[18458]: 1FED528317:
from=
Dave Howorth wrote:
Sandy Drobic wrote:
Content-Type: application/octet-stream; charset=us-ascii If there are characters in the mail not covered by ascii7 mail is automatically send as "application/octet-stream". This might happen if you have file names with strange characters.
Good idea. But there's nothing greater than 122 ('z') in attachment.bin.
Well, something is in your backup result that causes nail not to see the text as ascii7.
Instead of directly mailing the output you could save it into a file and use mime::lite to send it.
Sorry, it's not me that's mailing this. It's cron.
Then change your script to use mime::lite to send the report. Tell your script to store the output in a file and use perl -e 'use MIME::Lite; $msg = MIME::Lite->new(From => 'sender@example.com',To => 'recipient@example.com', Subject => 'backup result', Date => `date`, Type => 'text/plain', Encoding => 'base64', Path => '/path/to/backup/report/',);' to send the report. The entire expression is one line.
You should probably update your server, 9.2 is no longer supported.
Yes, it's in the queue of things to do :) I would have moved to 10.1 but that seemed to be a real dog, so now I'm being even more cautious before moving to 10.2.
Due to installation trouble with 10.1 and 10.2 I decided to upgrade to 10.0 only. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
Dave Howorth wrote:
Sandy Drobic wrote:
Content-Type: application/octet-stream; charset=us-ascii If there are characters in the mail not covered by ascii7 mail is automatically send as "application/octet-stream". This might happen if you have file names with strange characters.
Good idea. But there's nothing greater than 122 ('z') in attachment.bin.
Well, something is in your backup result that causes nail not to see the text as ascii7.
I've attached a complete message. I can only see 7-bit characters and the only control characters I can see are TAB and NL. I really hope you can see something else, because I'm going mad!
Instead of directly mailing the output you could save it into a file and use mime::lite to send it.
Sorry, it's not me that's mailing this. It's cron.
Then change your script to use mime::lite to send the report.
I don't want to seem ungrateful but I'd rather not do this. It's just papering over the cracks. There's no good reason why cron shouldn't carry on mailing these messages as text exactly as it has done for ages. I want to find the cause of the current problem, not just mask its effect. Cheers, Dave
From - Fri Jan 26 08:10:22 2007 X-Account-Key: account2 X-UIDL: @l\"!4iI"!JaW"!'iT"! X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-path:
Envelope-to: dhoworth@alf1.lmb.internal Delivery-date: Fri, 26 Jan 2007 08:08:26 +0000 Received: from server1.lmb.internal ([10.1.0.0]) by alf1.lmb.internal with esmtp (Exim 4.32) id 1HAM8I-001Amd-G2 for dhoworth@alf1.lmb.internal; Fri, 26 Jan 2007 08:08:26 +0000 Received: from suse1.lmb.internal ([10.11.0.0]) by server1.lmb.internal with esmtp (Exim 4.10) id 1HAM8I-00030V-00 for djh02@mrc-lmb.cam.ac.uk; Fri, 26 Jan 2007 08:08:26 +0000 Received: by suse1.lmb.internal (Postfix) id 05CB628317; Fri, 26 Jan 2007 08:08:26 +0000 (GMT) Delivered-To: root@suse1.lmb.internal Received: by suse1.lmb.internal (Postfix, from userid 0) id 931506A92A; Fri, 26 Jan 2007 08:08:25 +0000 (GMT) Date: Fri, 26 Jan 2007 08:08:25 +0000 To: root@suse1.lmb.internal Subject: cronjob@suse1 - daily - OK Message-ID: <45B9B6F9.mail4YN11WBJW@suse1.lmb.internal> User-Agent: nail 11.4 8/29/04 MIME-Version: 1.0 Content-Type: application/octet-stream; charset=us-ascii Content-Transfer-Encoding: 7bit From: root@mrc-lmb.cam.ac.uk (root) X-UIDL: @l\"!4iI"!JaW"!'iT"!
running daily cronjob scripts SCRIPT: clean_catman, OK. SCRIPT: do_mandb, OK. SCRIPT: logrotate, OK. SCRIPT: suse.de-backup-rc.config, OK. SCRIPT: suse.de-backup-rpmdb, OK. SCRIPT: suse.de-check-battery, OK. SCRIPT: suse.de-clean-tmp, OK. SCRIPT: suse.de-cron-local, OK. SCRIPT: output (stdout && stderr) follows This is /root/bin/cron.daily.local on suse1. Fri Jan 26 04:15:44 GMT 2007 Mounting backup filesystems PDB: This is /root/bin/cron.daily.local.pdb.sh on suse1. PDB:Fri Jan 26 04:15:44 GMT 2007 PDB: Download the PDB archive 04:15:45 dirvish --vault pdb-mirror --image-time "22:00" Running dirvish-expire Expiring images as of 2007-01-26 04:15:53 VAULT:BRANCH IMAGE CREATED EXPIRED suse1-data-interpro:default 2007-01-22 2007-01-23 11:00 +3 days == 2007-01-25 22:00 suse1-data-other:default 2007-01-18 2007-01-19 09:07 +1 week == 2007-01-25 22:00 04:37:50 done PDB: Running dirvish-delete-duplicates examined images ... 2006-11-28 2006-12-05 2006-12-12 2006-12-17 2007-01-02 2007-01-10 2007-01-14 2007-01-23 2007-01-24 2007-01-25 results are 78 x 1 + 1 1 1 1 1 1 1 1 0 0 removing image 2007-01-24 PDB: Running link_latest_pdb.pl PDB: finished Fri Jan 26 04:47:28 GMT 2007 suse1-data-trembl:default 2007-01-22 2007-01-23 11:00 +3 days == 2007-01-25 22:00 suse1-data-uniprot:default 2007-01-22 2007-01-23 11:00 +3 days == 2007-01-25 22:00 suse1-home:default 2007-01-18 2007-01-19 07:31 +1 week == 2007-01-25 22:00 suse1-root:default 2007-01-18 2007-01-19 07:44 +1 week == 2007-01-25 22:00 suse2-data-a:default 2007-01-18 2007-01-19 07:47 +1 week == 2007-01-25 22:00 suse2-data-b:default 2007-01-18 2007-01-19 07:47 +1 week == 2007-01-25 22:00 suse2-root:default 2007-01-18 2007-01-19 07:46 +1 week == 2007-01-25 22:00 suse3-data-a:default 2007-01-18 2007-01-19 08:12 +1 week == 2007-01-25 22:00 suse3-data-b:default 2007-01-18 2007-01-19 08:12 +1 week == 2007-01-25 22:00 suse3-root:default 2007-01-18 2007-01-19 08:04 +1 week == 2007-01-25 22:00 Fri Jan 26 06:08:25 GMT 2007 Running dirvish-runall 06:08:26 dirvish --vault suse1-home --image-time "22:00" 06:31:40 dirvish --vault suse1-root --image-time "22:00" 06:35:02 dirvish --vault suse2-root --image-time "22:00" 06:43:24 dirvish --vault suse2-data-a --image-time "22:00" 06:43:25 dirvish --vault suse2-data-b --image-time "22:00" 06:43:28 dirvish --vault suse3-root --image-time "22:00" 07:15:59 dirvish --vault suse3-data-a --image-time "22:00" 07:16:00 dirvish --vault suse3-data-b --image-time "22:00" 07:16:01 dirvish --vault pcx36-root --image-time "22:00" dirvish pcx36-root:default error (10) -- error in socket IO dirvish error: branch /backup/pcx36/pcx36-root:default image 2007-01-25 failed 07:16:16 dirvish --vault pcx36-var --image-time "22:00" ssh: connect to host pcx36.mrc-lmb.cam.ac.uk port 22: No route to host pcx36-var:default pre-client failed (256) 07:16:19 dirvish --vault pcx36-usr --image-time "22:00" dirvish pcx36-usr:default error (10) -- error in socket IO dirvish error: branch /backup/pcx36/pcx36-usr:default image 2007-01-25 failed 07:16:35 dirvish --vault cpepc210-3-root --image-time "22:00" 07:16:56 dirvish --vault cpepc210-3-opt --image-time "22:00" 07:18:30 dirvish --vault cpepc210-3-srv --image-time "22:00" 07:19:59 dirvish --vault cpepc210-3-usr --image-time "22:00" 07:24:25 dirvish --vault cpepc210-3-var --image-time "22:00" 07:24:32 dirvish --vault suse1-data-trembl --image-time "22:00" 07:24:42 dirvish --vault suse1-data-interpro --image-time "22:00" 07:24:43 dirvish --vault suse1-data-uniprot --image-time "22:00" 07:24:52 dirvish --vault suse1-data-other --image-time "22:00" 08:08:20 done Filesystem Size Used Avail Use% Mounted on /dev/hda1 26G 14G 12G 53% / tmpfs 1004M 44K 1004M 1% /dev/shm /dev/hda2 11G 7.7G 2.4G 77% /suse9.2 /dev/mapper/storage-home 200G 138G 63G 69% /home /dev/mapper/storage-data 600G 576G 25G 96% /data /dev/mapper/backup-suse1 500G 476G 25G 96% /backup/suse1 /dev/mapper/backup-suse2 100G 21G 80G 21% /backup/suse2 /dev/mapper/backup-suse3 150G 105G 46G 70% /backup/suse3 /dev/mapper/backup-pcx36 150G 57G 94G 38% /backup/pcx36 /dev/mapper/backup-cpepc210--3 100G 13G 88G 13% /backup/cpepc210-3 Unmounting backup filesystems Fri Jan 26 08:08:24 GMT 2007 SCRIPT: suse.de-cron-local ------- END OF OUTPUT
Dave Howorth wrote:
Sandy Drobic wrote:
Dave Howorth wrote:
Sandy Drobic wrote:
Content-Type: application/octet-stream; charset=us-ascii If there are characters in the mail not covered by ascii7 mail is automatically send as "application/octet-stream". This might happen if you have file names with strange characters. Good idea. But there's nothing greater than 122 ('z') in attachment.bin. Well, something is in your backup result that causes nail not to see the text as ascii7.
I've attached a complete message. I can only see 7-bit characters and the only control characters I can see are TAB and NL. I really hope you can see something else, because I'm going mad!
I can't see anything though it doesn't mean there wasn't anything in it befor you decided to attach it. For example, in you mail there are not tabs any more, they are replaced with spaces.
Instead of directly mailing the output you could save it into a file and use mime::lite to send it. Sorry, it's not me that's mailing this. It's cron. Then change your script to use mime::lite to send the report.
I don't want to seem ungrateful but I'd rather not do this. It's just papering over the cracks. There's no good reason why cron shouldn't carry on mailing these messages as text exactly as it has done for ages. I want to find the cause of the current problem, not just mask its effect.
I see, a man of principles. In that case you might want to investigate the programs that are called in cron. cron does not control what these programs write to standard out, so it is reasonable to assume that some programs will produce output that causes nail to regard the text as not ascii7. I had the same problem a year ago when I set up cron to update antivir. I finally gave in and ran the output through "tr" to replace the characters causing nail to attach the text as a binary. Someone more savvy might see a way, but at least I can't tell you how cron should be able to control, what kind of characters the called programs write to standard out. Though I strongly suspect that it is simply not possible. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-01-29 at 19:19 +0100, Sandy Drobic wrote:
Dave Howorth wrote:
I don't want to seem ungrateful but I'd rather not do this. It's just papering over the cracks. There's no good reason why cron shouldn't carry on mailing these messages as text exactly as it has done for ages. I want to find the cause of the current problem, not just mask its effect.
Well, cron uses the system "mail" command, which was changed not long ago to "nail" (perhaps with 9.2, maybe 9.1). I understand that 10.2 has changed again to a new one, mailx (http://heirloom.sourceforge.net/mailx.html), which seems to be the new name or version of "nail". Perhaps the OP could try updating it, to see if it behaves differently.
I see, a man of principles. In that case you might want to investigate the programs that are called in cron. cron does not control what these programs write to standard out, so it is reasonable to assume that some programs will produce output that causes nail to regard the text as not ascii7.
I had the same problem a year ago when I set up cron to update antivir. I finally gave in and ran the output through "tr" to replace the characters causing nail to attach the text as a binary.
I'm starting to understand. yes, I also got emails from cron jobs as attachments and I didn't know why. Now I do. - From another post from the OP: | It's cron. /etc/crontab => /usr/lib/cron/run-crons => etc etc => | /root/bin/cron.daily.local | | (/usr/lib/cron/run-crons is the script that actually create and sends | the mail, I think: | if [ -n "${STATUS}" -o "$SEND_MAIL_ON_NO_ERROR" = true ] ; then | mail ${SEND_TO} -s "${TITLE}" < ${CONTROL_MAIL} | fi | ) So, the text to be mailed is piped to the standard input. If it could be given as a file via command, we could play with the filename extension to change the mime type used by nail. But I don't see how to do that. Perhaps using -q file, but the mail is not ended, it still wants stdin. An alternative would be to use the sendmail binary, old style, instead of nail. Perhaps: sendmail -B 8BITMIME -F root@localhost ${SEND_TO} < ${CONTROL_MAIL} I don't see how to specify the subject, though, unless it is by including it inside the piped text. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFvl/AtTMYHG2NR9URAhkgAJ4wi7HiGmyic/IF28GEUC1hygszYQCdGQ9S iuURS5mpHhwHf+1crV6VJIQ= =ZusP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
Dave Howorth wrote:
I've attached a complete message. I can only see 7-bit characters and the only control characters I can see are TAB and NL. I really hope you can see something else, because I'm going mad!
I can't see anything though it doesn't mean there wasn't anything in it befor you decided to attach it. For example, in you mail there are not tabs any more, they are replaced with spaces.
I'm subscribed to this list at home as well, and the file that arrived there still had the tabs, so I suspect it did when it arrived at your site too :P The only place they occur is in the Received header lines.
I see, a man of principles. In that case you might want to investigate the programs that are called in cron. cron does not control what these programs write to standard out, so it is reasonable to assume that some programs will produce output that causes nail to regard the text as not ascii7.
As well as the principle, I want to eliminate a potential bug. This was working fine for a long time and has suddenly broken, apparently of its own accord. So I want to find out what has really changed in case it is having some other undesirable effect.
Someone more savvy might see a way, but at least I can't tell you how cron should be able to control, what kind of characters the called programs write to standard out. Though I strongly suspect that it is simply not possible.
I've looked at the source of nail now and am pretty convinced that it's not to blame. And I agree with you that it doesn't seem like cron should be held responsible. Carlos E. R. wrote:
Well, cron uses the system "mail" command, which was changed not long ago to "nail" (perhaps with 9.2, maybe 9.1). I understand that 10.2 has changed again to a new one, mailx (http://heirloom.sourceforge.net/mailx.html), which seems to be the new name or version of "nail".
I found the history http://heirloom.sourceforge.net/mailx_history.html fascinating. Thanks!
Perhaps the OP could try updating it, to see if it behaves differently.
Thanks for the suggestion, but I think that would just introduce another variable into a situation that already has enough. I prefer to investigate the current nail and the actual data files.
| (/usr/lib/cron/run-crons is the script that actually create and | sends the mail, I think: | if [ -n "${STATUS}" -o "$SEND_MAIL_ON_NO_ERROR" = true ] ; then | mail ${SEND_TO} -s "${TITLE}" < ${CONTROL_MAIL} | fi | )
So, the text to be mailed is piped to the standard input. If it could be given as a file via command, we could play with the filename extension to change the mime type used by nail. But I don't see how to do that.
/usr/lib/cron/run-crons uses temporary files to cache the output from the scripts that it runs. I've hacked it so it doesn't delete them afterwards. Tomorrow morning, I should be able to see exactly what was produced by the scripts before it gets mangled by the mail system. Thanks, Sandy & Carlos. Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-01-30 at 11:18 -0000, Dave Howorth wrote:
As well as the principle, I want to eliminate a potential bug. This was working fine for a long time and has suddenly broken, apparently of its own accord. So I want to find out what has really changed in case it is having some other undesirable effect.
Probably it is just the cron script producing a char that mail doesn't like; perhaps it could be a file name.
Carlos E. R. wrote:
Well, cron uses the system "mail" command, which was changed not long ago to "nail" (perhaps with 9.2, maybe 9.1). I understand that 10.2 has changed again to a new one, mailx (http://heirloom.sourceforge.net/mailx.html), which seems to be the new name or version of "nail".
I found the history http://heirloom.sourceforge.net/mailx_history.html fascinating. Thanks!
It was pointed in this list some days back. I hadn't read that history part. Very interesting. Did you notice the last paragraph? | Portable scripts should either invoke mail without any options or | should use the standardized mailx interface. In any case, they should | set the MAILRC variable to /dev/null to bypass the user's | configuration. As this variable is present in mailx, but not in Mail, | using Mail for scripts does not work reliably anyway and should be | avoided. (In effect, this means that there is no reliable way to send | mail from a script on many BSD derivatives and Linux distributions. But | that is a fact one has to live with.)
Perhaps the OP could try updating it, to see if it behaves differently.
Thanks for the suggestion, but I think that would just introduce another variable into a situation that already has enough. I prefer to investigate the current nail and the actual data files.
Ok. But, once you have the output file you mention below, you could perhaps compile the new version, and without the "make install" phase, try sending it and see if there is a difference. Probably not, anyway. Without installing it will not replace your system mail; and even if you install it, it will go to /usr/local/somewhere, so the original one is not disturbed.
| (/usr/lib/cron/run-crons is the script that actually create and | sends the mail, I think: | if [ -n "${STATUS}" -o "$SEND_MAIL_ON_NO_ERROR" = true ] ; then | mail ${SEND_TO} -s "${TITLE}" < ${CONTROL_MAIL} | fi | )
So, the text to be mailed is piped to the standard input. If it could be given as a file via command, we could play with the filename extension to change the mime type used by nail. But I don't see how to do that.
/usr/lib/cron/run-crons uses temporary files to cache the output from the scripts that it runs. I've hacked it so it doesn't delete them afterwards. Tomorrow morning, I should be able to see exactly what was produced by the scripts before it gets mangled by the mail system.
Good idea! Another idea. Perhaps nail doesn't like utf-8. You could view that file as iso, and check if there are weird things. I have a small script, "/usr/local/bin/isoxterm", containing: LANG=en_US.ISO-8859-1 LC_ALL=en_US.ISO-8859-1 /usr/bin/xterm -bd blue & Maybe I could set it as an alias thing, but I havent bothered. The thing is, I have a shortcut to launch an xterm in ISO-8859-1 mode, instead of the default UTF-8 (with a blue left border to distingish it). You can do the same, and view the cron output file with less inside such an xterm to see at a glance utf specific chars. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFv0fHtTMYHG2NR9URAvYYAJ9VAYE60f3hRkl04VEoNsSm2ntBRwCdF69Z zeZKeEfamwnbsmsUBgeVYmw= =Soi3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Dave Howorth wrote:
Sandy Drobic wrote:
Dave Howorth wrote:
I've attached a complete message. I can only see 7-bit characters and the only control characters I can see are TAB and NL. I really hope you can see something else, because I'm going mad! I can't see anything though it doesn't mean there wasn't anything in it befor you decided to attach it. For example, in you mail there are not tabs any more, they are replaced with spaces.
I'm subscribed to this list at home as well, and the file that arrived there still had the tabs, so I suspect it did when it arrived at your site too :P The only place they occur is in the Received header lines.
Okay, I didn't check the header lines, only the body. I doubt that the Received lines were produced as output of the program, so I didn't check them. (^-^)
I see, a man of principles. In that case you might want to investigate the programs that are called in cron. cron does not control what these programs write to standard out, so it is reasonable to assume that some programs will produce output that causes nail to regard the text as not ascii7.
As well as the principle, I want to eliminate a potential bug. This was working fine for a long time and has suddenly broken, apparently of its own accord. So I want to find out what has really changed in case it is having some other undesirable effect.
I suspect that the programs you are calling have changed. Or are you using some kind of portable script that hasn't changed during upgrades? Another possibility is the data that is processed by the program has changed.
/usr/lib/cron/run-crons uses temporary files to cache the output from the scripts that it runs. I've hacked it so it doesn't delete them afterwards. Tomorrow morning, I should be able to see exactly what was produced by the scripts before it gets mangled by the mail system.
That would be very interesting to know. Please post your findings tomorrow. (^-^) -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
I suspect that the programs you are calling have changed. Or are you using some kind of portable script that hasn't changed during upgrades? Another possibility is the data that is processed by the program has changed.
Well. I don't remember anything that has changed over the period when the problem arose. But then again, some days I would forget my own head ... I suppose _something_ must have changed!
/usr/lib/cron/run-crons uses temporary files to cache the output from the scripts that it runs. I've hacked it so it doesn't delete them afterwards. Tomorrow morning, I should be able to see exactly what was produced by the scripts before it gets mangled by the mail system.
That would be very interesting to know. Please post your findings tomorrow. (^-^)
I messed up the hack (there was another rm command I didn't notice) so we'll have to wait another day. Stay tuned. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Dave Howorth wrote:
/usr/lib/cron/run-crons uses temporary files to cache the output from the scripts that it runs. I've hacked it so it doesn't delete them afterwards. Tomorrow morning, I should be able to see exactly what was produced by the scripts before it gets mangled by the mail system. That would be very interesting to know. Please post your findings tomorrow. (^-^)
I messed up the hack (there was another rm command I didn't notice) so we'll have to wait another day. Stay tuned.
It's obstinate and tricky! It took me ages to find all the rm statements and control variables and arrange for it to keep the files. But I've done that now. Sadly, or perhaps gladly, I still don't have the evidence. My overnight backup job has gone back to reporting it's output as plain text :) It may be because of something else I found. Two days ago, I happened to spot that root on that machine has LC_CTYPE=en_GB.UTF-8 I wondered if that might have anything to do with my problem, and I added explicit LC_CTYPE=C statements in the cron/backup scripts. The next backup run produced plain text, so I thought I'd solved it. So I took my LC_CTYPE=C statements out again in order to prove that was the factor. But this morning the log is still plain text! So I'm still confused. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Dave Howorth wrote:
It's obstinate and tricky! It took me ages to find all the rm statements and control variables and arrange for it to keep the files. But I've done that now.
Sadly, or perhaps gladly, I still don't have the evidence. My overnight backup job has gone back to reporting it's output as plain text :) It may be because of something else I found.
Two days ago, I happened to spot that root on that machine has LC_CTYPE=en_GB.UTF-8 I wondered if that might have anything to do with my problem, and I added explicit LC_CTYPE=C statements in the cron/backup scripts. The next backup run produced plain text, so I thought I'd solved it. So I took my LC_CTYPE=C statements out again in order to prove that was the factor. But this morning the log is still plain text! So I'm still confused.
Grin! Keep up the digging. Hopefully you will unearth some more settings to make programs behave and send in plain text. (^-^) -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
Dave Howorth wrote:
Two days ago, I happened to spot that root on that machine has LC_CTYPE=en_GB.UTF-8 I wondered if that might have anything to do with my problem, and I added explicit LC_CTYPE=C statements in the cron/backup scripts. The next backup run produced plain text, so I thought I'd solved it. So I took my LC_CTYPE=C statements out again in order to prove that was the factor. But this morning the log is still plain text! So I'm still confused.
Grin! Keep up the digging. Hopefully you will unearth some more settings to make programs behave and send in plain text. (^-^)
Since I have had the same problem with the output of logdigest (getting sent as an attachment) on my 10.2, I decided to check root's LANG environment. It was set to POSIX, while my user is set to en_US.UTF-8. I found this info on POSIX from Google ( http://www-1.ibm.com/support/docview.wss?uid=swg1IC34244 ) that says POSIX cannot handle characters > 127 ascii. I had never even thought of roots LANG setting, and I cannot now say I understand what it means. What should it be? Would this cause mailx to decide it is not plain text? I did change /etc/sysconfig/language ROOT_USES_LANG to yes from ctype, and now root also has en_US.UTF-8, so I will see if it does anything tomorrow I guess. I just checked my 9.3 server where logdigest works, and env | grep LANG returns nothing for root. so maybe? -- Joe Morris Registered Linux user 231871 running openSUSE 10.2 x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-01-29 at 10:04 -0000, Dave Howorth wrote:
My daily backup script on a server mails the output to me (it's a cron job run by root). Recently, instead of sending me a plain text email message, it's started sending me an empty email with an attachment called 'attachment.bin'. This is just a plain text file with the same old content.
How is it done? Look at the script.
The only notable difference I can see in the messages is this header:
< Content-Type: text/plain; charset=us-ascii ---
Content-Type: application/octet-stream; charset=us-ascii
I don't think that matters. I mean, that's not the origin.
I certainly haven't deliberately changed any settings, but is there a setting somewhere that controls this header?
In the mail program used.
Does it depend on the settings on intermediate boxes that the mail passes through?
No, it should not.
The server is running Suse 9.2.
I hope it is not exposed, that is no longer maintained. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFvc0ltTMYHG2NR9URAuCwAJ9eiPQX3A7GdG3AcImFyX0v3QRcLACdFhtU YRKA+5+al36Diw7WB1s4lMo= =3lez -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
The Monday 2007-01-29 at 10:04 -0000, Dave Howorth wrote:
My daily backup script on a server mails the output to me (it's a cron job run by root). Recently, instead of sending me a plain text email message, it's started sending me an empty email with an attachment called 'attachment.bin'. This is just a plain text file with the same old content.
How is it done? Look at the script.
It's cron. /etc/crontab => /usr/lib/cron/run-crons => etc etc => /root/bin/cron.daily.local (/usr/lib/cron/run-crons is the script that actually create and sends the mail, I think: if [ -n "${STATUS}" -o "$SEND_MAIL_ON_NO_ERROR" = true ] ; then mail ${SEND_TO} -s "${TITLE}" < ${CONTROL_MAIL} fi )
The only notable difference I can see in the messages is this header:
< Content-Type: text/plain; charset=us-ascii ---
Content-Type: application/octet-stream; charset=us-ascii
I don't think that matters. I mean, that's not the origin.
Not sure what you mean by that?
I certainly haven't deliberately changed any settings, but is there a setting somewhere that controls this header?
In the mail program used.
There's a header that says: User-Agent: nail 11.4 8/29/04. According to it's manpage, it seems the choice is automatic.
Does it depend on the settings on intermediate boxes that the mail passes through?
No, it should not.
Hmm, I still have no clue where to look :(
The server is running Suse 9.2.
I hope it is not exposed, that is no longer maintained.
No, it's internal. Upgrading is on my TODO list. Thanks, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 29 January 2007, Carlos E. R. wrote:
The server is running Suse 9.2.
I hope it is not exposed, that is no longer maintained.
Carlos, a linux install does not become instantly vulnerable because it falls from maintenance. I know of many places running backlevel servers, which have so few ports open that they are quite safe. By exposed, I suppose you mean not behind a firewall or a router. But think of this: When was the last update to the router's software done? These things sit there in the open, usually for their entire life without an update. My general theory is that a linux machine used by humans at the keyboard is 500 time more likely to be hacked than one uses solely as a server or firewall/router. Of course I can't prove this with numbers since the last machine of mine that was rooted was RedHat 5.2 while it was STILL under maintenance. -- _____________________________________ John Andersen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-01-29 at 12:03 -0900, John Andersen wrote:
On Monday 29 January 2007, Carlos E. R. wrote:
The server is running Suse 9.2.
I hope it is not exposed, that is no longer maintained.
Carlos, a linux install does not become instantly vulnerable because it falls from maintenance. I know of many places running backlevel servers, which have so few ports open that they are quite safe.
Of course, I know that.
By exposed, I suppose you mean not behind a firewall or a router.
I mean not exposed to internet (sp. as a server), or acting as a server in an environment where it could be attacked. It is chancy: a very secure system might be sucesfully atacked, and an old one, unmantained, may stay intact for years.
My general theory is that a linux machine used by humans at the keyboard is 500 time more likely to be hacked than one uses solely as a server or firewall/router. Of course I can't prove this with numbers since the last machine of mine that was rooted was RedHat 5.2 while it was STILL under maintenance.
Reminds me... a friend just phoned to tell me there is a price (10000Eur?) for somebody breaking Vista. But I'm no "cracker", no idea what to search for, so... no price for me. :-p - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFvo0vtTMYHG2NR9URAoeyAJ4nclRdPPei6WXQdv3CqtWxz6MIpQCfePGv X2nT5rsiPtgqFILnu2TTJOc= =dz41 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (5)
-
Carlos E. R.
-
Dave Howorth
-
Joe Morris (NTM)
-
John Andersen
-
Sandy Drobic