Re: CR/LF
On Sun, Dec 11, 2022 at 12:02:59AM -0500, Jim Popovitch wrote: [...] > welp. > > Hope you have a good day tomorrow, To be fair, Greg takes those things seriously. And is extremely helpful, see his writeups [1]. Recommended reading. And he has the sharpest eyes around here in things shell. I thing also he's right: there is no CR (unless your remote command is making up one). The "-n" on echo does not take away anything, it just keeps echo from adding something. That said. Greg, I was also shaken by your roaring tone. Cheers [1] http://mywiki.wooledge.org/ -- t signature.asc Description: PGP signature
Re: nftables transparent proxy for outbound connections on a server
Good morning, all.
Is there anyone around to help me to setup a transparent proxy on Debian,
please ?
I have tinyproxy running on my server, and I would like, with nftables,
to intercept any outbound web traffic (tcp ipv4.ipv6),
and to redirect to the proxy on 127.0.0.1:.
So far, I have seen these examples online:
> ...
> chain prerouting {
> type nat hook prerouting priority dstnat; policy accept;
> tcp dport { 80, 443 } counter dnat ip to 127.0.0.1:
> tcp dport { 80, 443 } counter dnat ip6 to [::1]:
> }
> ...
Or sometimes, I see using redirect or even tproxy
What is the best nftables approach, please ?
Can you copy and paste what you are using ?
Thanks,
André Rodier
Re: Debian failed
On Sun 11 Dec 2022 at 04:39:02 (+0100), hw wrote: > > How can Debian be so old? Maturity takes a little ageing. Cheers, David.
Re: e-mail with line in body beginning with "From"
On Sat 10 Dec 2022 at 20:45:37 (-0500), pa...@quillandmouse.com wrote: > On Sun, 11 Dec 2022 09:49:54 +1100 > David wrote: > > > On Sat, 10 Dec 2022 at 19:05, wrote: > > > On Fri, 9 Dec 2022 20:39:34 -0600 Greg Marks > > > wrote: > > [snip] > > > > > > I don't know the RFCs involved, but I'm guessing they mandate or > > > suggest this treatment. > > > > Here's a reference describing 'mbox' format, which provides > > reference RFCs: > > https://manpages.debian.org/bullseye/mutt/mbox.5.en.html > > > > Excellent reference. Just the thing. I'm guessing it's useful when . everyone is using systems that agree to do that type of escaping, so that it's safe to undo it, even to many levels, . the messages are for humans to read, and they can judge from the context whether the content has become mangled at all (which is why I enquired of the OP whether the precise format is important to the recipient). But now that there are fail-safe methods of encoding "From ", there doesn't seem much point after two decades in treating this part of the document as much more than historical. As for the RFCs cited within, *822 are both concerned only with From: headers, not what are termed From_ postmarks. And, without an excessively careful reading of 976 (hardly justified by its 3½ decade age), the escaping of From is only discussed in the context of message envelopes, without any consideration of what's contained within the message. Note that mbox(5) says "A /variant/ of this format was documented in RFC976" (my emphasis), and 976 starts by saying "It does not address the format for storage of messages on one machine". Cheers, David.
Re: CR/LF
On Sat 10 Dec 2022 at 23:16:12 (-0500), Jim Popovitch wrote:
> The following
> will add a CR/LF:
>
> TEST=`ssh -o LogLevel=QUIET -t user@server "echo -n ''"`; echo ${TEST}
>
> Using -n on the 2nd echo would remove a necessary CR/LF on any remote
> cmd that did produce output.
I didn't give much consideration to what's left of the semicolon.
But echo ${TEST} will always write a newline unless, quote:
-n do not output the trailing newline
-e enable interpretation of backslash escapes
The second of these allows you to spring surprises.
$ Test="abcd"
$ echo -n ${Test}
abcd$ echo ${Test}
abcd
$ Test=""
$ echo ${Test}
$ Test=
$ echo ${Test}
$ unset Test
$ echo ${Test}
$ Test="abcd\c"
$ echo -e ${Test}
abcd$
Cheers,
David.
Re: CR/LF
On Sat, 2022-12-10 at 23:44 -0500, Greg Wooledge wrote:
> On Sat, Dec 10, 2022 at 11:16:12PM -0500, Jim Popovitch wrote:
> > On Sat, 2022-12-10 at 22:10 -0500, Greg Wooledge wrote:
> > > On Sat, Dec 10, 2022 at 10:07:48PM -0500, Jim Popovitch wrote:
>
> > > > > > Why does this produce a CR/LF
>
> > > There is still no CR. At all. Ever. This is not Microsoft Windows.
> >
> > Why would you assume Windows is involved? This is about running cmds
> > from Debian 11 to Debian 11.
>
> Then there is no CR/LF. There is only LF.
>
> > > So... what are you actually trying to do?
> >
> > Run cmds on a remote system, that is captured locally in a variable,
> > where said cmds may or may not produce output.
>
> OK. You have a few choices:
>
> 1) Throw away the notion that you can store the output in a variable, and
> store it in a file instead. This is the simplest and safest thing to
> do. If the command produces binary data (including NUL bytes), it's
> not possible to store it directly in a shell variable. But it can
> always be stored in a file.
>
> Redirection to a file also dodges all the insane issues of data
> modification that you get with the other choices.
>
> 2) Use a command substitution. This has two issues:
>
> a) It cannot handle binary data -- only text.
> b) All trailing newlines will be stripped by the command substitution.
>
> If you're certain the output will be text, but you need to preserve
> the correct number of newlines in the output, then the standard
> workaround is to append a fixed character to the stream, and remove
> it afterward:
>
> myvar=$(ssh whatever; printf x)
> myvar=${myvar%x}
>
> That preserves the output stream in its original form.
>
> 3) Pipe the command through something like base64, and use a command
> substitution to store the base64 encoded data stream in the shell
> variable.
>
> Then use base64 -d (or whatever inverts your choice of encoding) when
> you need to use the data.
>
Thanks, all of that is very informative and certainly nothing like the
rants and ravings of a senile old man. :)
> > Taking $() out of the equation doesn't change the result. The following
> > will add a CR/LF:
>
> THERE IS NO CR!
>
> > TEST=`ssh -o LogLevel=QUIET -t user@server "echo -n ''"`; echo ${TEST}
>
> COMMAND SUBSTITUTION REMOVES ALL TRAILING NEWLINES.
>
> IT DOES NOT MATTER WHETHER YOU USE THE MODERN $() OR THE ANCIENT AND
> DEPRECATED BACKTICKS.
>
> YOU ARE **STILL** FAILING TO QUOTE CORRECTLY!
>
> YOU ARE **STILL** USING echo WHICH ADDS A NEWLINE AND THEN WONDERING WHY
> A NEWLINE IS ADDED.
>
> I'm done. Continuing the self-abuse of attempting to help you
> is going to be pointless, so please read the answers you've already
> been given. I won't give you any more.
>
welp.
Hope you have a good day tomorrow,
-Jim P.
Re: CR/LF
On Sat, Dec 10, 2022 at 11:16:12PM -0500, Jim Popovitch wrote:
> On Sat, 2022-12-10 at 22:10 -0500, Greg Wooledge wrote:
> > On Sat, Dec 10, 2022 at 10:07:48PM -0500, Jim Popovitch wrote:
> > > > > Why does this produce a CR/LF
> > There is still no CR. At all. Ever. This is not Microsoft Windows.
>
> Why would you assume Windows is involved? This is about running cmds
> from Debian 11 to Debian 11.
Then there is no CR/LF. There is only LF.
> > So... what are you actually trying to do?
>
> Run cmds on a remote system, that is captured locally in a variable,
> where said cmds may or may not produce output.
OK. You have a few choices:
1) Throw away the notion that you can store the output in a variable, and
store it in a file instead. This is the simplest and safest thing to
do. If the command produces binary data (including NUL bytes), it's
not possible to store it directly in a shell variable. But it can
always be stored in a file.
Redirection to a file also dodges all the insane issues of data
modification that you get with the other choices.
2) Use a command substitution. This has two issues:
a) It cannot handle binary data -- only text.
b) All trailing newlines will be stripped by the command substitution.
If you're certain the output will be text, but you need to preserve
the correct number of newlines in the output, then the standard
workaround is to append a fixed character to the stream, and remove
it afterward:
myvar=$(ssh whatever; printf x)
myvar=${myvar%x}
That preserves the output stream in its original form.
3) Pipe the command through something like base64, and use a command
substitution to store the base64 encoded data stream in the shell
variable.
Then use base64 -d (or whatever inverts your choice of encoding) when
you need to use the data.
> Taking $() out of the equation doesn't change the result. The following
> will add a CR/LF:
THERE IS NO CR!
> TEST=`ssh -o LogLevel=QUIET -t user@server "echo -n ''"`; echo ${TEST}
COMMAND SUBSTITUTION REMOVES ALL TRAILING NEWLINES.
IT DOES NOT MATTER WHETHER YOU USE THE MODERN $() OR THE ANCIENT AND
DEPRECATED BACKTICKS.
YOU ARE **STILL** FAILING TO QUOTE CORRECTLY!
YOU ARE **STILL** USING echo WHICH ADDS A NEWLINE AND THEN WONDERING WHY
A NEWLINE IS ADDED.
I'm done. Continuing the self-abuse of attempting to help you
is going to be pointless, so please read the answers you've already
been given. I won't give you any more.
Re: CR/LF
On Sat, 2022-12-10 at 22:10 -0500, Greg Wooledge wrote:
> On Sat, Dec 10, 2022 at 10:07:48PM -0500, Jim Popovitch wrote:
> > On Sat, 2022-12-10 at 20:35 -0600, David Wright wrote:
> > > On Sat 10 Dec 2022 at 21:01:29 (-0500), Jim Popovitch wrote:
> > > > Why does this produce a CR/LF
> > > >
> > > > ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo
> > > > ${TEST}
> > >
> > > Try echo -n ${TEST} at the end.
> >
> > Thanks, that works if the remote cmd produces no output, but if the
> > remote cmd produces output than the -n strips the intentional CR/LF.
>
> WOW, THAT WAS FAST!
There's really no need for snark.
>
> We have now reached the point where the question has changed,
No, it's still the same question, perhaps the reader is reading the
question differently now?
> so that the newline-stripping behavior of the $() command substitution is
> relevant.
Thanks, that's been the relevant part all along.
> There is still no CR. At all. Ever. This is not Microsoft Windows.
Why would you assume Windows is involved? This is about running cmds
from Debian 11 to Debian 11.
>
> So... what are you actually trying to do?
>
Run cmds on a remote system, that is captured locally in a variable,
where said cmds may or may not produce output. If the remote cmd does
not produce any output then there shouldn't be any output, e.g. CR/LF,
returned.
Taking $() out of the equation doesn't change the result. The following
will add a CR/LF:
TEST=`ssh -o LogLevel=QUIET -t user@server "echo -n ''"`; echo ${TEST}
Using -n on the 2nd echo would remove a necessary CR/LF on any remote
cmd that did produce output.
-Jim P.
Re: Debian failed
On Mon, 2022-12-05 at 16:20 +0800, Bret Busby wrote: > On 05/12/2022 16:14, hede wrote: > > On 04.12.2022 23:09 hw wrote: > > > On Sun, 2022-12-04 at 15:00 +, Andrew M.A. Cater wrote: > > > > On Sun, Dec 04, 2022 at 03:52:31PM +0100, hw wrote: > > > > [...] > > > > How did you install - what image, what steps? > > > > > > debian-11.5.0-amd64-netinst.iso > > > > see below... > > > > On 04.12.2022 21:49 hw wrote: > > > > > [...] > > > > > So I'm stuck with Fedora. What's wrong with Debian that we can't even > > > > > get AMD cards to work. > > > > > > > > I think you need around the 5.15 kernel. > > > > > > It was fully updated and the amdgpu module would load after forcing it, > > > yet it didn't work right. This is something that should --- and does > > > with Fedora --- work right out of the box. > > > > Fedora is a bleeding edge distribution. As such it's more comparable to > > Debian Unstable or maybe Testing than to Debian Stable (like currently > > Debian 11 "Bullseye"). > > > > Radeon RX 6000 series was released last year. I doubt it was possible to > > use one of these with Red Hat Enterprise Linux ootb in the beginning of > > this year before RHEL 9 was released. ;-) > > > > hede > > > Perhaps, the original poster should install and use, Debian Experimental? > > It seems fitting... > > :) No, testing was worse than bad enough.
Re: Debian failed
On Mon, 2022-12-05 at 09:14 +0100, hede wrote: > On 04.12.2022 23:09 hw wrote: > > On Sun, 2022-12-04 at 15:00 +, Andrew M.A. Cater wrote: > > > On Sun, Dec 04, 2022 at 03:52:31PM +0100, hw wrote: > > > [...] > > > How did you install - what image, what steps? > > > > debian-11.5.0-amd64-netinst.iso > > see below... > > On 04.12.2022 21:49 hw wrote: > > > > [...] > > > > So I'm stuck with Fedora. What's wrong with Debian that we can't even > > > > get AMD cards to work. > > > > > > I think you need around the 5.15 kernel. > > > > It was fully updated and the amdgpu module would load after forcing it, > > yet it didn't work right. This is something that should --- and does > > with Fedora --- work right out of the box. > > Fedora is a bleeding edge distribution. As such it's more comparable to > Debian Unstable or maybe Testing than to Debian Stable (like currently > Debian 11 "Bullseye"). And it works like 97% perfectly fine ... > Radeon RX 6000 series was released last year. I doubt it was possible to > use one of these with Red Hat Enterprise Linux ootb in the beginning of > this year before RHEL 9 was released. ;-) I don't know, I had NVIDIA cards before and there was never a problem with Debian or Fedora or Gentoo being too old for that. Last year was at least a year ago and Debian still can't use the card? Seriously? It's not even some kind of special card (except being way too large) but the minimum card you can get away with when you have a 4k display (and has only about half the performance or even less of the 1080ti FE I surprisingly resurrected.) On top of that, the AMD drivers are open source and in the standard kernel and are supposed to work. It doesn't make any sense. Who is cooperative with their drivers now, NVIDIA or AMD? Wayland still doesn't work with NVIDIA, but I can live without it for now ...
Re: Debian failed
On Sat, Dec 10, 2022 at 10:39 PM hw wrote: > On Sun, 2022-12-04 at 18:42 -0500, Jeffrey Walton wrote: > > ... > > Yeah, a newer kernel is probably worth a try. The 5.8 kernel may work. > > The 5.15 kernel will work based on my experience. > > > > For completeness, here is the mini-pc I was having trouble with: > > https://www.amazon.com/dp/B0B2RHXLDK . It is described as 'AMD Ryzen 5 > > 5560U with AMD Radeon Graphics'. > > > > [...] > > The thing that kept tripping me up was: > > > > # lspci | grep -v 'bridge:' > > ... > > 04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. > > [AMD/ATI] Device 1638 (rev c3) > > 04:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device 1637 > > > > Device 1638 was supposed to use amdgpu driver per [1,2]. But it didn't > > - it used an old ati driver. I did not realize the 5.4 kernel was too > > old. The 5.4 kernel lacked Cezanne support. > > > > [1] https://drmdb.emersion.fr/devices?driver=amdgpu > > [2] https://wiki.archlinux.org/title/AMDGPU > > IIRC, I got the amdgpu module to load and it still didn't detect the > graphics card right. > > How can Debian be so old? I thought I could use it for workstations and > servers, but when it can't even work right with a relatively old > graphics card, its usefulness becomes very questionable --- and it > leaves me without a good alternative. Here's the version of amdgpu I am using on Ubuntu 22.04: $ apt show amdgpu Package: amdgpu Version: 22.20.50200-1438747~22.04 Priority: optional Section: metapackages Maintainer: Advanced Micro Devices (AMD) Installed-Size: 9,216 B Depends: amdgpu-dkms, amdgpu-lib (= 22.20.50200-1438747~22.04) Download-Size: 1,684 B APT-Sources: https://repo.radeon.com/amdgpu/22.20/ubuntu jammy/main amd64 Packages Description: Meta package to install amdgpu components. ... The version of amdgpu on Ubuntu 20.04 did not recognize the card. It gave me a lot of trouble until I upgraded to 22.04 with the 5.15 kernel. Maybe you can try Debian Sid? Jeff
Re: Debian failed
On Sun, 2022-12-04 at 18:42 -0500, Jeffrey Walton wrote: > On Sun, Dec 4, 2022 at 5:30 PM hw wrote: > > > > On Sun, 2022-12-04 at 20:58 +, Andrew M.A. Cater wrote: > > > On Sun, Dec 04, 2022 at 09:49:59PM +0100, hw wrote: > > > > On Sun, 2022-12-04 at 13:58 -0500, Jeffrey Walton wrote: > > > > > On Sun, Dec 4, 2022 at 9:53 AM hw wrote: > > > > > > > > > > > > so I wanted to have Debian on a Precision R7910 with AMD graphics > > > > > > card > > > > > > and it failed because it refuses to use the amdgpu module. I tried > > > > > > forcing to load it when booting and it still didn't work. > > > > > > > > > > > > So I'm stuck with Fedora. What's wrong with Debian that we can't > > > > > > even > > > > > > get AMD cards to work. > > > > > > > > > > I think you need around the 5.15 kernel. > > > > > > > > It was fully updated and the amdgpu module would load after forcing it, > > > > yet it didn't work right. This is something that should --- and does > > > > with Fedora --- work right out of the box. > > > > > > > > > > If Jeffrey is right - and Debian stable will install, then install the > > > 6.0 kernel from backports and a more up to date firmware? > > > > Thanks, if I try again, that would be worth a try. > > Yeah, a newer kernel is probably worth a try. The 5.8 kernel may work. > The 5.15 kernel will work based on my experience. > > For completeness, here is the mini-pc I was having trouble with: > https://www.amazon.com/dp/B0B2RHXLDK . It is described as 'AMD Ryzen 5 > 5560U with AMD Radeon Graphics'. > > [...] > The thing that kept tripping me up was: > > # lspci | grep -v 'bridge:' > ... > 04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. > [AMD/ATI] Device 1638 (rev c3) > 04:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device 1637 > > Device 1638 was supposed to use amdgpu driver per [1,2]. But it didn't > - it used an old ati driver. I did not realize the 5.4 kernel was too > old. The 5.4 kernel lacked Cezanne support. > > [1] https://drmdb.emersion.fr/devices?driver=amdgpu > [2] https://wiki.archlinux.org/title/AMDGPU IIRC, I got the amdgpu module to load and it still didn't detect the graphics card right. How can Debian be so old? I thought I could use it for workstations and servers, but when it can't even work right with a relatively old graphics card, its usefulness becomes very questionable --- and it leaves me without a good alternative.
Re: CR/LF
On Sat, 10 Dec 2022 21:01:29 -0500
Jim Popovitch wrote:
> Why does this produce a CR/LF
>
> ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo
> ${TEST}
>
> whilst this same command does not:
>
> ~$ ssh -o LogLevel=QUIET -t user@server "echo -n ''"
Because the second echo in the first line does not have a -n.
All the ssh stuff is superfluous.
charles@jhegaala:~$ test=$(echo -n '') ; echo $test
charles@jhegaala:~$ test=$(echo -n '') ; echo -n $test
charles@jhegaala:~$
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
Re: CR/LF
On Sat, Dec 10, 2022 at 10:07:48PM -0500, Jim Popovitch wrote:
> On Sat, 2022-12-10 at 20:35 -0600, David Wright wrote:
> > On Sat 10 Dec 2022 at 21:01:29 (-0500), Jim Popovitch wrote:
> > > Why does this produce a CR/LF
> > >
> > > ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo
> > > ${TEST}
> >
> > Try echo -n ${TEST} at the end.
>
> Thanks, that works if the remote cmd produces no output, but if the
> remote cmd produces output than the -n strips the intentional CR/LF.
WOW, THAT WAS FAST!
We have now reached the point where the question has changed, so that
the newline-stripping behavior of the $() command substitution is
relevant.
There is still no CR. At all. Ever. This is not Microsoft Windows.
So... what are you actually trying to do?
Re: CR/LF
On Sat, 2022-12-10 at 20:35 -0600, David Wright wrote:
> On Sat 10 Dec 2022 at 21:01:29 (-0500), Jim Popovitch wrote:
> > Why does this produce a CR/LF
> >
> > ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo ${TEST}
>
> Try echo -n ${TEST} at the end.
Thanks, that works if the remote cmd produces no output, but if the
remote cmd produces output than the -n strips the intentional CR/LF.
-Jim P.
Re: CR/LF
On Sat, Dec 10, 2022 at 08:35:59PM -0600, David Wright wrote:
> On Sat 10 Dec 2022 at 21:01:29 (-0500), Jim Popovitch wrote:
> > Why does this produce a CR/LF
> >
> > ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo ${TEST}
>
> Try echo -n ${TEST} at the end.
You mean printf %s "$TEST" or at least echo -n "$TEST".[1]
Without the quotes, you may potentially get a VERY different result from
what you expect.
And we haven't even got to the part where $() strips the trailing newline
since there hasn't been a trailing newline coming from the remote system
yet. I'm waiting for the question to change, and then that one will be
relevant.
[1] Really, just stop using echo altogether, except with constant
arguments. printf is the only way to guarantee the expected output
when variables are involved.
Re: CR/LF
On Sat, Dec 10, 2022 at 09:01:29PM -0500, Jim Popovitch wrote:
> Why does this produce a CR/LF
>
> ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo ${TEST}
It does not produce a carriage return, unless you're on Windows.
The second echo command (the local one) produces a newline. Since you
did not give it any parameters, that's all it produces.
> whilst this same command does not:
>
> ~$ ssh -o LogLevel=QUIET -t user@server "echo -n ''"
The remote echo produces no output, and there's no local echo, so you
get no output.
Re: CR/LF
On Sat 10 Dec 2022 at 21:01:29 (-0500), Jim Popovitch wrote:
> Why does this produce a CR/LF
>
> ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo ${TEST}
Try echo -n ${TEST} at the end.
> whilst this same command does not:
>
> ~$ ssh -o LogLevel=QUIET -t user@server "echo -n ''"
Cheers,
David.
CR/LF
Why does this produce a CR/LF
~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo ${TEST}
whilst this same command does not:
~$ ssh -o LogLevel=QUIET -t user@server "echo -n ''"
tia,
-Jim P.
Re: e-mail with line in body beginning with "From"
On Sun, 11 Dec 2022 09:49:54 +1100 David wrote: > On Sat, 10 Dec 2022 at 19:05, wrote: > > On Fri, 9 Dec 2022 20:39:34 -0600 Greg Marks > > wrote: [snip] > > > I don't know the RFCs involved, but I'm guessing they mandate or > > suggest this treatment. > > Here's a reference describing 'mbox' format, which provides > reference RFCs: > https://manpages.debian.org/bullseye/mutt/mbox.5.en.html > Excellent reference. Just the thing. Paul -- Paul M. Foster Personal Blog: http://noferblatz.com Company Site: http://quillandmouse.com Software Projects: https://gitlab.com/paulmfoster
Re: e-mail with line in body beginning with "From"
On Sat, 10 Dec 2022 at 19:05, wrote: > On Fri, 9 Dec 2022 20:39:34 -0600 Greg Marks wrote: > > In a recent instance, the body of the e-mail contained a line > > beginning with the word "From"; the sendmail program prefixed the > > line with the character ">" and a space (evidently interpreting > > "From" as a header line that needed to be quoted). This was more > > than just a trivial annoyance, since it rendered my digital signature > > on the e-mail invalid. > > Is there a way to tell the Postfix sendmail command not to alter any > > such lines in the body of the message? (I'm afraid I wasn't able to > > discern an answer in the man page for sendmail or by searching the > > postfix.org site.) > You don't want to do this. Consider an MUA which stores your mail in > "mbox" format-- one email right after another in one file. The > delimiter is a line which starts at the left margin with the word > "From". For this to work, any other line which starts with "From" must > be "armored". And the way you do that is to precede it with "> ". > I don't know the RFCs involved, but I'm guessing they mandate or > suggest this treatment. Here's a reference describing 'mbox' format, which provides reference RFCs: https://manpages.debian.org/bullseye/mutt/mbox.5.en.html
Re: Xen backup and restore
Hello, On Wed, Dec 07, 2022 at 09:27:27AM +0100, Toth Zoltan wrote: > I am looking for a solution to backup and restore xen domU under > debian, but I did not anything. What does "backup and restore" mean to you in this context? Describe a scenario and what you would like to happen. Depending on what you want and what your existing setup is like there may be a few different solutions. It will also help if you describe your setup, such as what version of Debian you're using for dom0? Where you get your hypervisor packages from (Debian's own packages? Upstream source? Something else)? How are you providing storage for your domUs? Do you run PV domUs, PVH or HVM or a mixture of these? Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: e-mail with line in body beginning with "From"
On Sat 10 Dec 2022 at 08:24:05 (+0200), Teemu Likonen wrote: > * 2022-12-09 20:39:34-0600, Greg Marks wrote: > > > > I occasionally send e-mail from the command line via Postfix, using a > > script containing the command > > > >/usr/sbin/sendmail -oi -f -t < file > > Is there a way to tell the Postfix sendmail command not to alter any > > such lines ["From" lines] in the body of the message? Not knowing what prompts these occasions, it difficult to advise. If the precise format is unimportant, then passing through a filter to eleminate any occurrences would be one method: it could be the first step in a script that calls whatever method you're using to sign the email. If format precision matters, see the next quoted paragraph. As was pointed out, it's only "From " at the start that matters. > Probably Mutt email client can automatically do all the encoding and > pass the fully compliant message to sendmail. Mutt can be used in > command line. I didn't test it because I don't have any sendmails > installed. A lower level option for constructing valid emails is > "mime-construct". From this line, you should get confirmation of mutt's behaviour. But note that you have to turn it on with set encode_from in its muttrc. > From letters are in the beginning of this line because I want to test my > own message and email client: the file that is saved locally in my > computer and the file which comes through the mailing list. FWIW your client appears to encode the space, whereas mutt encodes the F. And mutt is cautious, as it ought to be, and encodes whether or not the From follows a blank line. Cheers, David.
Re: e-mail with line in body beginning with "From"
I remember some e-mail programs automatically add an extra space in front of a From in the message body if any line starts with From. Probably Thunderbird is one of them. to...@tuxteam.de wrote: > > On Sat, Dec 10, 2022 at 08:36:39AM -0500, Greg Wooledge wrote: > > [...] > > > Technically, it's the 5-character sequence "From " (including the space) > > that matters in mbox formats. If you begin a line with "Fromage" [...] > > I thusly propose to drop the '>' escaping of "From" and change every From > at a line start to "Fromage". > > Hmmm. Now I'm hungry. > > (Thanks for the laugh :-) > > Cheers > -- > t
Re: e-mail with line in body beginning with "From"
> On Sat, Dec 10, 2022 at 02:57:42AM -0500, pa...@quillandmouse.com > wrote: > > You don't want to do this. Consider an MUA which stores your mail in > > "mbox" format-- one email right after another in one file. The > > delimiter is a line which starts at the left margin with the word > > "From". > > Technically, it's the 5-character sequence "From " (including the > space) that matters in mbox formats. If you begin a line with > "Fromage", or "From:", or even "From" followed by a tab, it won't > need to be escaped/armored. There also has to be a blank line before it (unless it's the first five letters in a mailbox) so effectively it has to be the start of a paragraph that starts with 'From'. (and then has a particular address format after it. :)
Re: e-mail with line in body beginning with "From"
On Sat, Dec 10, 2022 at 08:36:39AM -0500, Greg Wooledge wrote: [...] > Technically, it's the 5-character sequence "From " (including the space) > that matters in mbox formats. If you begin a line with "Fromage" [...] I thusly propose to drop the '>' escaping of "From" and change every From at a line start to "Fromage". Hmmm. Now I'm hungry. (Thanks for the laugh :-) Cheers -- t signature.asc Description: PGP signature
Re: Monitor traffic on a port.
On 12/10/22 14:31, Greg Wooledge wrote: On Fri, Dec 09, 2022 at 11:25:36PM -0600, pe...@easthope.ca wrote: How is traffic on a specific port monitored now? The only tool I've ever used for that is tcpdump. If you need UDP then I don't know what to recommend. Traffic monitoring is not my forte. You can use that same utility to dump UDP packets! :) -- John Doe
Re: Monitor traffic on a port.
Hi, what about tcpdump? You can check the traffic or even dump and later analyse it with wireshark(or similar). -- Köszönettel: Vukovics Mihály On 2022. 12. 10. 16:12, Michel Verdier wrote: Le 10 décembre 2022 peter a écrit : Appears nettools is deprecated. How is traffic on a specific port monitored now? You could use wireshark. It can analyse network with restriction on some filters including selecting specific port.
Re: Monitor traffic on a port.
Le 10 décembre 2022 peter a écrit : > Appears nettools is deprecated. > > How is traffic on a specific port monitored now? You could use wireshark. It can analyse network with restriction on some filters including selecting specific port.
Re: Monitor traffic on a port.
In-reply-to: <20221210092451.4b3a5...@hpusdt5.der-he.de> References: <2e94402a808bb7535f81cb604e0e2...@easthope.ca> <20221210092451.4b3a5...@hpusdt5.der-he.de> From: hede Date: Sat, 10 Dec 2022 09:24:51 +0100 ... iptraf-ng ... Installed it and ran iptraf. If confirms no traffic on lo when a test is run. Thx, ... P.
Re: bash read and field separator
On Sat, Dec 10, 2022 at 07:18:13PM +0700, Max Nikulin wrote:
> It took some time for me to realize why you case is different. Please, try
>
> cd tmp
> find leaf leaf/ leaf// -printf '%T@/%TY-%Tm-%Td/%TT/%p\0' | while IFS=/ read
> -rd '' _ day time path; do printf '%s\n' "$path"; done
unicorn:~/tmp$ find leaf leaf/ leaf// -printf '%T@/%TY-%Tm-%Td/%TT/%p\0' |
while IFS=/ read -rd '' _ day time path; do printf '%s\n' "$path"; done
leaf
leaf
leaf//
Well, crap.
> I have found some speculations that it is standard behavior
> https://stackoverflow.com/questions/52762210/shell-read-sometimes-strips-trailing-delimiter
Shells are the WORST. What a pile of shit.
Stephane's workaround ("inserting an extra : and remove it afterwards")
is probably the way to go.
unicorn:~/tmp$ find leaf leaf/ leaf// -printf '%T@/%TY-%Tm-%Td/%TT/%p/\0' |
while IFS=/ read -rd '' _ day time path; do printf '%s\n' "${path%/}"; done
leaf
leaf/
leaf//
This doesn't matter for the "rlart" function, because we're restricting
the output to files. Even in the more general case, find is never going
to write a pathname that ends with "/" except where you begin the search
at "/", or where you add a trailing slash on the starting pathname, as
you did here. No sensible person would do either of those things, or
if they did, they would know enough to ignore the oddity on the first
line of the filtered output.
Now I've got a BashPitfalls section to update too. Damn it.
Re: e-mail with line in body beginning with "From"
On Sat, Dec 10, 2022 at 02:57:42AM -0500, pa...@quillandmouse.com wrote: > You don't want to do this. Consider an MUA which stores your mail in > "mbox" format-- one email right after another in one file. The > delimiter is a line which starts at the left margin with the word > "From". Technically, it's the 5-character sequence "From " (including the space) that matters in mbox formats. If you begin a line with "Fromage", or "From:", or even "From" followed by a tab, it won't need to be escaped/armored.
Re: Monitor traffic on a port.
On Fri, Dec 09, 2022 at 11:25:36PM -0600, pe...@easthope.ca wrote: > How is traffic on a specific port monitored now? The only tool I've ever used for that is tcpdump. If you need UDP then I don't know what to recommend. Traffic monitoring is not my forte.
RDD Process (firefox)
this is a prime example of a lack of common sense. firefox developers decided to break out the decode process so that it shows up under the list of running processes as "RDD Process". well of course it is a process. "firefox Remote Data Decoder". voila! useful and you don't have to wonder what it is. songbird
Re: bash read and field separator
On 09/12/2022 23:20, Greg Wooledge wrote:
On Fri, Dec 09, 2022 at 10:23:29PM +0700, Max Nikulin wrote:
find dir dir/ dir// -printf '%T@/%TY-%Tm-%Td/%TT/%p\0' | sort -zn |
while IFS=/ read -rd '' _ day time path; do
printf '%s %s %s\n' "$day" "${time%.*}" "$path";
done | sed -n l
2022-12-09 22:13:14 dir$
2022-12-09 22:13:14 dir$
2022-12-09 22:13:14 dir//$
Single trailing / disappeared. Using any other character may cause incorrect
path in the output.
I can't reproduce your result.
unicorn:~$ mkdir tmp/leaf
unicorn:~$ find tmp/leaf tmp/leaf/ tmp/leaf// -printf '%T@/%TY-%Tm-%Td/%TT/%p\0' | while
IFS=/ read -rd '' _ day time path; do printf '%s\n' "$path"; done
tmp/leaf
tmp/leaf/
tmp/leaf//
It took some time for me to realize why you case is different. Please, try
cd tmp
find leaf leaf/ leaf// -printf '%T@/%TY-%Tm-%Td/%TT/%p\0' | while IFS=/
read -rd '' _ day time path; do printf '%s\n' "$path"; done
I have found some speculations that it is standard behavior
https://stackoverflow.com/questions/52762210/shell-read-sometimes-strips-trailing-delimiter
Unfortunately I can not make similar conclusion after reading the cited
documents. From my point of view
set -- "$var"
is not the same as read. In the latter case remaining part of the line
is assigned to the last variable. The argument that with preserved
trailing separator it is impossible to express single field, does not
work for read as well.
In dash I see the same behavior after dropping unsupported -d and using
\n as record separator.
Re: e-mail with line in body beginning with "From"
Hi, pa...@quillandmouse.com wrote: > [...] any other line which starts with "From" must > be "armored". And the way you do that is to precede it with "> ". > I don't know the RFCs involved, but I'm guessing they mandate or > suggest this treatment. It does not look like being fully specified by an RFC. RFC 4155 "The application/mbox Media Type" mentions Many implementations are also known to escape message body lines that begin with the character sequence of "From " and points to http://qmail.org/man/man5/mbox.html where ">From quoting" is described in more detail. Debian's man 5 mbox stems from package mutt and describes quoting schemes "MBOXO", "MBOXRD", "MBOXCL". RFC 4155 decries the situation but then says Also note that this specification does not prescribe any escape syntax for message body lines that begin with the character sequence of "From ". Have a nice day :) Thomas
nftables transparent proxy for outbound connections on a server
Hello, all.
I have tinyproxy running on my server, and I would like, with nftables,
to intercept any outbound web traffic (tcp ipv4.ipv6), and to redirect
to the proxy on 127.0.0.1:.
So far, I have seen these examples online:
> ...
chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
tcp dport { 80, 443 } counter dnat ip to 127.0.0.1:
tcp dport { 80, 443 } counter dnat ip6 to [::1]:
> }
> ...
Or sometimes, I see using redirect or even tproxy
What is the best nftables approach, please ?
Can you copy and paste what you are using ?
Thanks,
Andre
Re: Monitor traffic on a port.
On Fri, 09 Dec 2022 23:25:36 -0600 pe...@easthope.ca wrote: > Appears nettools is deprecated. > How is traffic on a specific port monitored now? Do you mean netstat? There's "ss" in the iproute2 package. But I wouldn't call either of them "traffic monitoring" tools. None of the net-tools. With "traffic monitoring" I would think of iptraf-ng or iftop, but both of them are neither part of net-tools nor iproute2. Maybe I simply do not understand the question. ;-) hede
Re: e-mail with line in body beginning with "From"
On Fri, 9 Dec 2022 20:39:34 -0600 Greg Marks wrote: > I occasionally send e-mail from the command line via Postfix, using a > script containing the command > >/usr/sbin/sendmail -oi -f -t < file > > In a recent instance, the body of the e-mail contained a line > beginning with the word "From"; the sendmail program prefixed the > line with the character ">" and a space (evidently interpreting > "From" as a header line that needed to be quoted). This was more > than just a trivial annoyance, since it rendered my digital signature > on the e-mail invalid. > > I think I encountered a similar problem a couple decades ago using the > "mail" command on a FreeBSD machine, but I don't remember any solution > to the problem. > > Is there a way to tell the Postfix sendmail command not to alter any > such lines in the body of the message? (I'm afraid I wasn't able to > discern an answer in the man page for sendmail or by searching the > postfix.org site.) > > Best regards, > Greg Marks You don't want to do this. Consider an MUA which stores your mail in "mbox" format-- one email right after another in one file. The delimiter is a line which starts at the left margin with the word "From". For this to work, any other line which starts with "From" must be "armored". And the way you do that is to precede it with "> ". I don't know the RFCs involved, but I'm guessing they mandate or suggest this treatment. Paul -- Paul M. Foster Personal Blog: http://noferblatz.com Company Site: http://quillandmouse.com Software Projects: https://gitlab.com/paulmfoster
