Re: Threading; was Re: HTTP shimmed to HTTPS
pe...@easthope.ca writes: * From: Reco recovery...@enotuniq.net * Date: Mon, 22 Jul 2019 17:35:27 +0300 > You're breaking threading. Just a friendly note. I've been adding References manually. By "breaking" do you refer to omission of older references (For example, http://lists.debian.org/debian-user/2019/07/msg01131.html has only two references whereas it was about 8 from the original.) or to the presence of links labelled [ & # 128270; ]? ( <== Spaces inserted to suppress character reference.) The omission is only that I failed to put all of them. Others have already mentioned the issues with the missing In-Reply-To header etc. The most problematic thing seems to be the inclusion of NUL-characters in the lines of form: * From: Reco recovery...@enotuniq.net | ^^ The indicated columns (with `^`) seem to appear as tabs, NUL bytes or pad bytes in other mail user agents. It is problematic that these occur in your e-mails because they cause the mails to be displayed wrongly for some users (some clients see only the begin of line until the first NUL, others only the begin of message until the first NUL). Check the source code of https://lists.debian.org/debian-user/2019/07/msg01178.html to find out that there are unexpected NUL-bytes: $ wget -Otest.html https://lists.debian.org/debian-user/2019/07/msg01178.html From a hex editor ($ dhex test.html): AD0 3e 0a 3c 21 2d 2d 58 2d 42 6f 64 79 2d 6f 66 2d >.. PROBLEM vv--v AF0 2a 09 46 72 6f 6d 3a 20 52 65 63 6f 20 00 72 65 *.From: Reco .re B00 63 6f 76 65 72 79 6d 34 6e 40 65 6e 6f 74 75 6e coverym4n@enotun B10 69 71 2e 6e 65 74 00 0a 2a 09 44 61 74 65 3a 20 iq.net..*.Date: PROBLEM --^^-^ B20 4d 6f 6e 2c 20 32 32 20 4a 75 6c 20 32 30 31 39 Mon, 22 Jul 2019 B30 20 31 37 3a 33 35 3a 32 37 20 2b 30 33 30 30 0a17:35:27 +0300. B40 26 67 74 3b 20 59 6f 75 27 72 65 20 62 72 65 61 > You're brea I am using a niché e-mail client as well, so I wish you the best of luck in fixing that issue... HTH Linux-Fan [...] pgpHhoUykeepv.pgp Description: PGP signature
Re: Can Grub Boot Through a USB Port on an Old PC?
Pascal Hambourg writes: > If the system on the USB drive is GNU/Linux, you just need to put /boot on > the internal drive so that GRUB can load them. > > > > as I have some PIC > microcontroller development tools that don't make in today's > world. > > > Did you consider chroot instead of multiboot ? Not until I read this message! I have used chroot a few times and know that the directory is now the root of the jail you have made but I didn't stop to think that this also means that while one is in that jail, all the pathsare now relative to the bounds of the jail including libraries and executables which also see only wheezy libraries so any executables should be happy. The binaries we make with the assembler never execute on site but do so in the tiny brains of the PIC processors. The programming device we use to flash the PIC eprom connects to a native serial port or a usb-to-serial converter and if those work through the walls of the jail, there should be no trouble. If the programmer still works, that is a winner and many thanks. Martin McCormick
Re: Odd character, was Re: buster, ekiga.
On Tue, Jul 23, 2019 at 09:35:59PM +0200, to...@tuxteam.de wrote:
On Tue, Jul 23, 2019 at 03:31:12PM -0400, Michael Stone wrote:
On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote:
>I don't see any NUL characters, but x80 as shown below. I'm reading
>the cached message that mutt downloaded from an IMAP server. Is that
>different from you?
I see it as x80 in mutt and x00 in the raw file on the imap server.
I assume mutt is trying to defang the nul, similar to java's
conversion to 0xc0 0x80, but I haven't actually looked through the
code to confirm.
Heh. that is strange: with mutt ("edit raw") I do see an x00 (shown
by vim as ^@).
My message doesn't go through an IMAP server, fwiw. Dunno what exim
does to it, though :-)
I guess it's the imapd defanging then, before it gets to mutt.
Re: Odd character, was Re: buster, ekiga.
On Tue, Jul 23, 2019 at 03:38:33PM -0400, Greg Wooledge wrote: > On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote: > > On Tue 23 Jul 2019 at 11:07:37 (-0400), Greg Wooledge wrote: > > > Yup. Two NUL bytes in the body of the message. How completely bizarre. > > > > > > Apparently what mutt does is truncate that *line* at the first NUL > > > byte, but then show all the other lines after that just fine. > > > I don't see any NUL characters, but x80 as shown below. I'm reading > > the cached message that mutt downloaded from an IMAP server. Is that > > different from you? > > In my case, the email is sent first to a Debian 9 system running qmail + > magic-smtpd [...] > I'll try to remember to keep a copy of the next one for hex-dumping. Looking forward :-) > Meanwhile, as a test, I ran the following from my home system outside > the workplace firewall: [...] Interesting. Note that both your tests have a Content-Transfer-Encoding (first: 8bit, second: quoted-printable; the first one gets a slight indigestion, the second not). The original messages have no Content-Type, much less Content-Transfer-Encoding (so x00 as well as x80 should be both a no-no anyway). Cheers -- t signature.asc Description: Digital signature
Re: Odd character, was Re: buster, ekiga.
On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote: > On Tue 23 Jul 2019 at 11:07:37 (-0400), Greg Wooledge wrote: > > Yup. Two NUL bytes in the body of the message. How completely bizarre. > > > > Apparently what mutt does is truncate that *line* at the first NUL > > byte, but then show all the other lines after that just fine. > I don't see any NUL characters, but x80 as shown below. I'm reading > the cached message that mutt downloaded from an IMAP server. Is that > different from you? In my case, the email is sent first to a Debian 9 system running qmail + magic-smtpd (with possible interference from corporate firewall products over which I have no control), and from there to my Debian 10 desktop system, also running qmail, with qmail-smtpd as the receiver. Mail is delivered locally on the Debian 10 system to a Maildir in my home directory, and mutt reads it directly from there. No IMAP or POP3 for me. I'll try to remember to keep a copy of the next one for hex-dumping. Meanwhile, as a test, I ran the following from my home system outside the workplace firewall: printf 'Testing \0nul\0\nDid it work?\n' | mailx -s test wool...@eeg.ccf.org Here's what hd shows (last few lines only): 0370 38 22 0a 43 6f 6e 74 65 6e 74 2d 54 72 61 6e 73 |8".Content-Trans| 0380 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 38 62 |fer-Encoding: 8b| 0390 69 74 0a 0a 54 65 73 74 69 6e 67 20 0a 44 69 64 |it..Testing .Did| 03a0 20 69 74 20 77 6f 72 6b 3f 0a| it work?.| 03aa Which probably means mailx on my sender truncates the line with the raw NUL bytes, and the test is inconclusive. So, next test: printf 'Test two \0nul\0\nDid it work?\n' | mutt -s test wool...@eeg.ccf.org Here's what I got: 03b0 73 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 71 |sfer-Encoding: q| 03c0 75 6f 74 65 64 2d 70 72 69 6e 74 61 62 6c 65 0a |uoted-printable.| 03d0 58 2d 4f 70 65 72 61 74 69 6e 67 2d 53 79 73 74 |X-Operating-Syst| 03e0 65 6d 3a 20 4c 69 6e 75 78 20 34 2e 31 39 2e 30 |em: Linux 4.19.0| 03f0 2d 35 2d 61 6d 64 36 34 0a 55 73 65 72 2d 41 67 |-5-amd64.User-Ag| 0400 65 6e 74 3a 20 4d 75 74 74 2f 31 2e 31 30 2e 31 |ent: Mutt/1.10.1| 0410 20 28 32 30 31 38 2d 30 37 2d 31 33 29 0a 0a 54 | (2018-07-13)..T| 0420 65 73 74 20 74 77 6f 20 3d 30 30 6e 75 6c 3d 30 |est two =00nul=0| 0430 30 0a 44 69 64 20 69 74 20 77 6f 72 6b 3f 0a |0.Did it work?.| 043f ... well, that's self-explanatory, isn't it. I don't feel like writing a script to send raw NUL bytes through /usr/sbin/sendmail or through netcat mxhost 25 at this time, so I'll just leave it at that.
Re: Threading; was Re: HTTP shimmed to HTTPS
On Tue 23 Jul 2019 at 08:56:36 (-0700), pe...@easthope.ca wrote: > In future I'll make more effort with the references. Beyond 3 or 4 it > can be tedious. If you're typing (or pasting) the references, I would just add the In-Reply-To instead. That way, you can Cut/Copy the original's Message-ID: Paste the line untouched, then edit *just* these characters: Message-ID:change intoIn-Reply-To: which will make your message thread correctly. As for the From/Date lines you're adding into the *body* of the message, just use their names. (Yours would be peter, not pe...@easthope.ca and certainly not &pe...@easthope.ca& where & is some weird character you happened upon.) Cheers, David.
Re: Odd character, was Re: buster, ekiga.
On Tue, Jul 23, 2019 at 03:31:12PM -0400, Michael Stone wrote:
> On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote:
> >I don't see any NUL characters, but x80 as shown below. I'm reading
> >the cached message that mutt downloaded from an IMAP server. Is that
> >different from you?
>
> I see it as x80 in mutt and x00 in the raw file on the imap server.
> I assume mutt is trying to defang the nul, similar to java's
> conversion to 0xc0 0x80, but I haven't actually looked through the
> code to confirm.
Heh. that is strange: with mutt ("edit raw") I do see an x00 (shown
by vim as ^@).
My message doesn't go through an IMAP server, fwiw. Dunno what exim
does to it, though :-)
Cheers
-- t
signature.asc
Description: Digital signature
Re: Odd character, was Re: buster, ekiga.
On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote: I don't see any NUL characters, but x80 as shown below. I'm reading the cached message that mutt downloaded from an IMAP server. Is that different from you? I see it as x80 in mutt and x00 in the raw file on the imap server. I assume mutt is trying to defang the nul, similar to java's conversion to 0xc0 0x80, but I haven't actually looked through the code to confirm. So it would appear the OP has pasted the Unicode "RIGHT-POINTING MAGNIFYING GLASS" character into their postings, which seems somewhat reasonable as it's used on the Debian web pages to mark all the Message-IDs and references thereto. Where that gets mangled along the way, I can't guess. but it would see that 0x80 is a reasonable choice as that's a Latin-1 Control Character with the meaning PAD. https://en.wikipedia.org/wiki/Latin-1_Supplement_(Unicode_block) I'm not entirely surprised that an MUA that is unaware of the changes to internet mail that have happened since the early 80s (codified back in 2001) is also unaware of unicode.
Re: Odd character, was Re: buster, ekiga.
On Tue, Jul 23, 2019 at 02:19:27PM -0500, David Wright wrote: [...] > I don't see any NUL characters, but x80 as shown below [...] Oh, that's cute :-) If I followed along correctly, the questionable mails have neither Content-Type nor Content-Transfer-Encoding. So the content type defaults to text/plain; charset=us-ascii, right? If you kill the high bit in x80 you're left with x00. Hmmm... Cheers -- tomás signature.asc Description: Digital signature
Odd character, was Re: buster, ekiga.
On Tue 23 Jul 2019 at 11:07:37 (-0400), Greg Wooledge wrote: > On Tue, Jul 23, 2019 at 07:41:20AM -0700, pe...@easthope.ca wrote: > > * From: Brad Rogers > > Oh, it's this guy again. > > /me looks at the raw mail message with less(1) > > * From: Brad Rogers ^@b...@fineby.me.uk^@ > > Yup. Two NUL bytes in the body of the message. How completely bizarre. > > Apparently what mutt does is truncate that *line* at the first NUL > byte, but then show all the other lines after that just fine. > > Other people are seeing the entire message truncated at that point, not > just one line truncated. > > Peter, whatever you're doing with your outgoing mail is really strange, > and if possible, you should try to stop it. Embedding raw NUL characters > in the body of an email is a problem. I don't see any NUL characters, but x80 as shown below. I'm reading the cached message that mutt downloaded from an IMAP server. Is that different from you? 17C0 64 2D 73 65 │ 61 72 63 68 │ 2F 45 31 68 │ 70 76 79 69 │ 2D 30 30 30 d-search/E1hpvyi-000 17D4 31 6E 78 2D │ 4B 6C 40 64 │ 61 6C 74 6F │ 6E 2E 69 6E │ 76 61 6C 69 1nx-Kl@dalton.invali 17E8 64 0A 52 65 │ 73 65 6E 74 │ 2D 44 61 74 │ 65 3A 20 54 │ 75 65 2C 20 d.Resent-Date: Tue, 17FC 32 33 20 4A │ 75 6C 20 32 │ 30 31 39 20 │ 31 34 3A 35 │ 37 3A 32 30 23 Jul 2019 14:57:20 1810 20 2B 30 30 │ 30 30 20 28 │ 55 54 43 29 │ 0A 0A 2A 09 │ 46 72 6F 6D + (UTC)..*.From 1824 3A 20 42 72 │ 61 64 20 52 │ 6F 67 65 72 │ 73 20 80 62 │ 72 61 64 40 : Brad Rogers .brad@ 1838 66 69 6E 65 │ 62 79 2E 6D │ 65 2E 75 6B │ 80 0A 2A 09 │ 44 61 74 65 fineby.me.uk..*.Date 184C 3A 20 46 72 │ 69 2C 20 31 │ 39 20 4A 75 │ 6C 20 32 30 │ 31 39 20 31 : Fri, 19 Jul 2019 1 1860 39 3A 33 32 │ 3A 34 36 20 │ 2B 30 31 30 │ 30 0A 3E 20 │ 49 74 20 77 9:32:46 +0100.> It w 1874 61 73 20 72 │ 65 70 6C 61 │ 63 65 64 20 │ 62 79 20 45 │ 6D 70 61 74 as replaced by Empat 1888 68 79 2E 0A │ 0A 54 68 61 │ 6E 6B 73 2E │ 20 20 45 6D │ 70 61 74 68 hy...Thanks. Empath Well, here's what I think is going on. The OP wrote "The links are from the debian mailing list software. 128270(9) = 1F50E(E) or 128270(decimal) = 1F50E(hexadecimal). U+1F50E is beyond the list in …" So it would appear the OP has pasted the Unicode "RIGHT-POINTING MAGNIFYING GLASS" character into their postings, which seems somewhat reasonable as it's used on the Debian web pages to mark all the Message-IDs and references thereto. Where that gets mangled along the way, I can't guess. but it would see that 0x80 is a reasonable choice as that's a Latin-1 Control Character with the meaning PAD. https://en.wikipedia.org/wiki/Latin-1_Supplement_(Unicode_block) Converting it to NUL seems hazardous to me, almost asking for trouble. Cheers, David.
Re: Can Grub Boot Through a USB Port on an Old PC?
Le 23/07/2019 à 20:28, Pascal Hambourg a écrit : If the system on the USB drive is GNU/Linux, you just need to put /boot on the internal drive so that GRUB can load them. Oops, my sentence was a bit incomplete. You just need to put /boot on the internal drive so that GRUB can load the kernel image (vmlinuz) and the initramfs (initrd) from there.
Re: Can Grub Boot Through a USB Port on an Old PC?
Le 23/07/2019 à 17:37, Martin McCormick a écrit : It may turn out to be less of a headache to make it a duel-boot system. One boot would be the latest debian console and the other would be Debian Wheezy If the system on the USB drive is GNU/Linux, you just need to put /boot on the internal drive so that GRUB can load them. as I have some PIC microcontroller development tools that don't make in today's world. Did you consider chroot instead of multiboot ?
Re: Threading; was Re: HTTP shimmed to HTTPS
On Tue, 23 Jul 2019 12:28:50 -0400 Greg Wooledge wrote: Hello Greg, >We may be seeing different symptoms as a result of *whatever* Peter is >doing, depending on how each individual mail transport agent and each >mail user agent deals with the incoming mess. Indeed. I looked up his MUA (Oberon, based on the X-Mailer header). There seems to be exactly one web site mentioning it. Definitely minority MUA. Given what you and others are saying regarding non-RFC compliant headers, added manually, no less, it seems like this MUA should be avoided until improvements are made. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" I can't do a thing 'cause I can't relax Independence Day - Comsat Angels pgpR1XFXOh2Es.pgp Description: OpenPGP digital signature
Re: buster, ekiga.
On Tue, Jul 23, 2019 at 11:07:37AM -0400, Greg Wooledge wrote: > On Tue, Jul 23, 2019 at 07:41:20AM -0700, pe...@easthope.ca wrote: > > * From: Brad Rogers > > Oh, it's this guy again. > > /me looks at the raw mail message with less(1) > > * From: Brad Rogers ^@b...@fineby.me.uk^@ > > Yup. Two NUL bytes in the body of the message. How completely bizarre. FWIW, I'm seeing those two null bytes too. OTOH I use the same MUA as you (Mutt), but on the other hand this is a sample of a different MTA path, at least from the Debian mailing list servers to each of us. Whatever... Cheers -- t signature.asc Description: Digital signature
Re: Can Grub Boot Through a USB Port on an Old PC?
On Tue 23 Jul 2019 at 10:37:46 -0500, Martin McCormick wrote: > Pascal Hambourg writes: > > Le 23/07/2019 à 04:53, Martin McCormick a écrit : > > > Do you mean that GRUB is installed on an internal drive ? > > Yes. > > > By default, GRUB relies on the BIOS disk services to access drives. But it > > also has native ATA and USB drivers which are not loaded by default. See > > the 'nativedisk' command. > > > > > > > > Be aware that loading native drivers switches GRUB to a new different > > world > > : BIOS drives (hdX) will not be available any more and environment > > variables pointing at drives such as $root and $prefix will need to be > > updated with native drive names (ataX, usbX...). > > Thanks again for the heads up. I tried the nativedisk command of GRUB some years ago but cannot recollect in any detail whether it solved my issue with three machines unable to boot from a USB stick. I went back to using Plop with GRUB either because nativedisk didn't help or because Plop is an easy to implemennt solution. https://www.plop.at/ -- Brian.
Re: Threading; was Re: HTTP shimmed to HTTPS
On Tue, Jul 23, 2019 at 05:22:44PM +0100, Brad Rogers wrote: > On Tue, 23 Jul 2019 12:16:31 -0400 > Greg Wooledge wrote: > > Hello Greg, > > >You need to add "In-Reply-To:" as well. And stop doing whatever it is > >you're doing that puts NUL bytes in your "* From:" lines. Or simply > >drop those lines altogethe > > I /think/ they're tab characters. At least, that seems to be the case > from a quick glance at the message source: A 5 character (or so) space > was 'jumped' when my cursor encountered those chars. We may be seeing different symptoms as a result of *whatever* Peter is doing, depending on how each individual mail transport agent and each mail user agent deals with the incoming mess. The file I had in my ~/Maildir/new/ directory definitely had NUL bytes in it (it's gone now -- I don't save these mails). I suppose it's conceivable that someone else's MTA may translate the NULs to TABs, or that someone's MUA may display the NULs as TABs. Or that *my* MTA is translating something else into NUL bytes. Who knows? All I can say for sure is: Peter, whatever you're doing, please fix it.
Re: Threading; was Re: HTTP shimmed to HTTPS
Hi. On Tue, Jul 23, 2019 at 08:56:36AM -0700, pe...@easthope.ca wrote: > * From: Reco ?recovery...@enotuniq.net? > * Date: Mon, 22 Jul 2019 17:35:27 +0300 > > You're breaking threading. Just a friendly note. > > I've been adding References manually. By "breaking" do you refer to > omission of older references (For example, > http://lists.debian.org/debian-user/2019/07/msg01131.html has only two > references whereas it was about 8 from the original.) This. And, I have to add, you're adding them wrong. What you do is a violation of RFC2822: References: e1hp6yw-0002kn...@enotuniq.net E1hpYQe-tm-Lx@dalton.invalid e1hpzan-0001lu...@enotuniq.net What sane MUA does to be RFC2822-compliant is: References: > or to the presence of links labelled [ & # 128270; ]? ( <== Spaces > inserted to suppress character reference.) Does not bother me. You e-mails look somewhat unusual, but it's a part of my job to deal with malformed e-mails. I've seen stranger e-mails. It is a problem for other participants of this maillist though. > The omission is only that I failed to put all of them. Also, quoting RFC2822, The "References:" field will contain the contents of the parent's "References:" field (if any) followed by the contents of the parent's "Message-ID:" field (if any). So, the omission of certain values from parent's "References" also violates RFC2822. On a side note, your e-mails lack "In-Reply-To" header, and that can break threading for some MUAs. Again, RFC2822. In short, please consider using another e-mail client. Implementing RFC2822 by hand in every e-mail you write is something that should not require a human intervention. ktnxbye, Reco
Re: Threading; was Re: HTTP shimmed to HTTPS
On Tue, 23 Jul 2019 12:16:31 -0400 Greg Wooledge wrote: Hello Greg, >You need to add "In-Reply-To:" as well. And stop doing whatever it is >you're doing that puts NUL bytes in your "* From:" lines. Or simply >drop those lines altogethe I /think/ they're tab characters. At least, that seems to be the case from a quick glance at the message source: A 5 character (or so) space was 'jumped' when my cursor encountered those chars. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" I ain't got no time for intellectual music, e.g. Hergest Ridge Heads Down No Nonsense Mindless Boogie - Alberto y Lost Trios Paranoias pgpMR1NW7LKSH.pgp Description: OpenPGP digital signature
Re: Threading; was Re: HTTP shimmed to HTTPS
On Tue, Jul 23, 2019 at 08:56:36AM -0700, pe...@easthope.ca wrote: > * From: Reco > > You're breaking threading. Just a friendly note. > > I've been adding References manually. You need to add "In-Reply-To:" as well. And stop doing whatever it is you're doing that puts NUL bytes in your "* From:" lines. Or simply drop those lines altogether.
Threading; was Re: HTTP shimmed to HTTPS
* From: Reco
Re: Can Grub Boot Through a USB Port on an Old PC?
Pascal Hambourg writes: > Le 23/07/2019 à 04:53, Martin McCormick a écrit : > Do you mean that GRUB is installed on an internal drive ? Yes. > By default, GRUB relies on the BIOS disk services to access drives. But it > also has native ATA and USB drivers which are not loaded by default. See > the 'nativedisk' command. > > > > Be aware that loading native drivers switches GRUB to a new different > world > : BIOS drives (hdX) will not be available any more and environment > variables pointing at drives such as $root and $prefix will need to be > updated with native drive names (ataX, usbX...). Thanks again for the heads up. > > Also, note that chainloading a bootloader (boot sector or ntldr) which > relies on BIOS disk services will not work. Loading a kernel and initramfs > should work if they include native USB drivers. My thanks to all who responded. In addition to your responses, I later found a discussion on one of the stackexchange sites dealing with this same issue and was about to kick myself for wasting everybody's time but it turned out every response touched on a different aspect of the issue so it sounds like it will keep me busy for awhile. It may turn out to be less of a headache to make it a duel-boot system. One boot would be the latest debian console and the other would be Debian Wheezy as I have some PIC microcontroller development tools that don't make in today's world. This is a Dell Dimension motherboard with 1 GB of RAM and a 600-MHZ Pentium which works very well in the command-line world so I'll run it until the motherboard fries. Yup! It's about 20 years old but no reason to trash it yet. Martin WB5AGZ
Re: buster, ekiga.
On Tue, 23 Jul 2019 07:41:20 -0700 pe...@easthope.ca wrote: Hello pe...@easthope.ca, >* From: Brad Rogers * Date: Fri, 19 Jul 2019 19:32:46 >> It was replaced by Empathy. ... >item are pale gray. Ideas about contacts? All I know about Empathy is that it replaced Ekiga. I've never used either package. Sorry. >Thanks again, ... P. YW. I'm just sorry that I can't be of more help. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" I'll tell you something, I think that you should know Rich Kids - Rich Kids pgpyD0lHLmvAo.pgp Description: OpenPGP digital signature
Re: buster, ekiga.
On Tue, Jul 23, 2019 at 07:41:20AM -0700, pe...@easthope.ca wrote: > * From: Brad Rogers Oh, it's this guy again. /me looks at the raw mail message with less(1) * From: Brad Rogers ^@b...@fineby.me.uk^@ Yup. Two NUL bytes in the body of the message. How completely bizarre. Apparently what mutt does is truncate that *line* at the first NUL byte, but then show all the other lines after that just fine. Other people are seeing the entire message truncated at that point, not just one line truncated. Peter, whatever you're doing with your outgoing mail is really strange, and if possible, you should try to stop it. Embedding raw NUL characters in the body of an email is a problem.
Re: buster, ekiga.
* From: Brad Rogers
Re: clone ACL permissions
On 23/07/19 12:20, Thomas Schmitt wrote: Hi, consider this from man setfacl: --restore=file Restore a permission backup created by `getfacl -R' or similar. All permissions of a complete directory subtree are restored using this mechanism. If the input contains owner comments or group comments, setfacl attempts to restore the owner and owning group. If the input contains flags comments (which define the setuid, setgid, and sticky bits), setfacl sets those three bits accordingly; otherwise, it clears them. This option cannot be mixed with other options except `--test'. You could write a program which reads the text blocks in the getfacl -R file and only writes those to a new file, which contain lines other than the chmod-related "user::", "group::", "other::". This would curb the eagerness of setfacl --restore to the files which really need it. Depending on your situation. some manipulation of the file paths in the -R file might be necessary. (And of course you urgently need a backup of your ACLs. If your favorite backup tool does not record them, consider to run getfacl -R and to include the resulting file in your backup.) Have a nice day :) Thomas Hi Thomas, Thank you for a quick and useful reply. I definitely need to review all backups and include ACLs where needed. I'm also wondering if rsync is capable of syncing ACLs without touching anything else. I vaguely recall using it for a similar purpose some time ago. Thanks, Adam
Re: clone ACL permissions
Adam Weremczuk [2019-07-23T11:42:00+01] wrote: > Is it possible to "clone" ACL permissions? > > I.e. recursively read ACL (getfacl?) on all files and folders and > write (setacl?) to the same list of files and folders elsewhere? Maybe rsync's -A/--acls option is useful here. rsync --verbose --archive --acls --dry-run somewhere/ somewhere-else -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tliko...@iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen signature.asc Description: PGP signature
Re: clone ACL permissions
Hi, consider this from man setfacl: --restore=file Restore a permission backup created by `getfacl -R' or similar. All permissions of a complete directory subtree are restored using this mechanism. If the input contains owner comments or group comments, setfacl attempts to restore the owner and owning group. If the input contains flags comments (which define the setuid, setgid, and sticky bits), setfacl sets those three bits accordingly; otherwise, it clears them. This option cannot be mixed with other options except `--test'. You could write a program which reads the text blocks in the getfacl -R file and only writes those to a new file, which contain lines other than the chmod-related "user::", "group::", "other::". This would curb the eagerness of setfacl --restore to the files which really need it. Depending on your situation. some manipulation of the file paths in the -R file might be necessary. (And of course you urgently need a backup of your ACLs. If your favorite backup tool does not record them, consider to run getfacl -R and to include the resulting file in your backup.) Have a nice day :) Thomas
clone ACL permissions
Hi all, I've just found out that my backups were missing ACL and the restore will not work until this is fixed. Luckily I have the luxury of checking what the permissions should look like on a running system, e.g: RESTORED: # file: samba/sysvol # owner: root # group: 300 user::rwx group::rwx other::--- RUNNING: # file: samba/sysvol # owner: root # group: 300 user::rwx user:root:rwx group::rwx group:300:rwx group:301:r-x group:302:rwx group:303:r-x mask::rwx other::--- default:user::rwx default:user:root:rwx default:group::--- default:group:300:rwx default:group:301:r-x default:group:302:rwx default:group:303:r-x default:mask::rwx default:other::--- There are no trivial permissions patterns to follow so manual reconciliation would take very long and be error prone. QUESTION: Is it possible to "clone" ACL permissions? I.e. recursively read ACL (getfacl?) on all files and folders and write (setacl?) to the same list of files and folders elsewhere? Thanks, Adam
Re: why flash fails for this web site?
On Sun, 21 Jul 2019 21:04:27 + (UTC) Long Wind wrote: > my firefox for stretch can display flash, for example: > http://www.10jqka.com.cn/flash/ > but it can't display > https://www.gtja.com/jccy/syhq.htmli can't see any error msg, the page is > blank > > my other stretch can display https://www.gtja.com/jccy/syhq.html Maybe your flash plugins are different, or totally missing from the first installation. Are you sure the content you are playing is for flash?
Re: Hibernation takes too long
And here’s an example where the output media is an SD card: rbthomas@nuc8:/media/rbthomas/99602c92-f887-4578-b6bc-39c91d49c43c/rbthomas$ dd if=/dev/zero of=tempfile bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.48058 s, 2.2 GB/s rbthomas@nuc8:/media/rbthomas/99602c92-f887-4578-b6bc-39c91d49c43c/rbthomas$ dd if=/dev/zero of=tempfile bs=1M count=1024 oflag=sync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 34.044 s, 31.5 MB/s > On Jul 23, 2019, at 1:19 AM, Rick Thomas wrote: > > Here’s an example from one of my machines with a SATA-III SSD and lots of RAM: > > rbthomas@nuc8:~$ dd if=/dev/zero of=tempfile bs=1M count=1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.77789 s, 604 MB/s > > rbthomas@nuc8:~$ dd if=/dev/zero of=tempfile bs=1M count=1024 oflag=sync > 1024+0 records in > 1024+0 records out > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.88158 s, 220 MB/s
Re: Hibernation takes too long
You need to add the clause “oflag=sync” on your dd commands. Without it the MB/s numbers are really just measuring how fast you can fill up the RAM cache (for write) or scoop up data from the RAM cache (in the case of read). Here’s an example from one of my machines with a SATA-III SSD and lots of RAM: rbthomas@nuc8:~$ dd if=/dev/zero of=tempfile bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.77789 s, 604 MB/s rbthomas@nuc8:~$ dd if=/dev/zero of=tempfile bs=1M count=1024 oflag=sync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.88158 s, 220 MB/s Hope it helps! Rick > On Jul 21, 2019, at 2:44 PM, Shahryar Afifi wrote: > > Correct! > I attached a screen shot of read write speed. > The 2 min hibernation time is when there is little or no contents > present. If I have many things opened, it would take more.
Re: Hibernation takes too long
Hi all, sorry for having spread half-knowledge here. On 22.07.19 15:53, Stefan Monnier wrote: > Also, if the problem is in the time it takes to write the hibernation > data, then those 2 minutes should mostly be spent with a display that > says "blabla ... NN%" where the NN slowly goes from 0 to 100. > > IIUC this is not what you're seeing This leads back to OPs question: Where can he find some log entry showing what's going on? Is it maybe connected to an old CPU somehow? What would be relevant infos to collect, the output of hwinfo piped to a text file? Best Michael signature.asc Description: OpenPGP digital signature
