Re: Debian 10 logrotate

[Gene Heskett]

On Wednesday 24 July 2019 21:04:13 Tan Shao Yi wrote:

> Hi Sven,
>
> Thank you for the explanation.
>
> I just wanted to add that when doing "systemctl edit
> logrotate.service", we also need to include the "[Service]" header
> before specifying ReadWritePaths.
>
> Thank you.
>
> Regards,
> Tan Shao Yi
>
> On 21/7/19, 5:55 PM, "Sven Joachim"  wrote:
>
> On 2019-07-21 02:42 +, Tan Shao Yi wrote:
> > I upgraded to Debian 10 recently and it looks like logrotate is
> > not working on files outside the /var directory:
>
> This is correct.

This is going to be a problem for me unless its fixable. My email logs 
were moved to /home/me/log many years ago because I got tired of 
fighting with somebody's idea of security denying fetchmail and procmail 
rights to keep their logs in /var. Logrotate was easily fixed then. And 
I believe its fixed for the stretch I'm running atm.


> > For example,
> >
> > Jul 21 00:00:01 server-name logrotate[8874]: error: error
> > renaming /usr/local/apache/logs/https-error_log.12.gz to
> > /usr/local/apache/logs/https-error_log.13.gz: Read-only file
> > system Jul 21 00:00:03 server-name logrotate[8874]: error:
> > unable to open /usr/local/backup/mysql/mysql.sql.1 for
> > compression
> >
> > The files are present, and I am able to logrotate them manually
> > as root when I run logrotate against the config files in
> > /etc/logrotate.d--it just fails when it is run automatically.
> >
> > May I know if something has changed recently to cause this?
>
> It is the ProtectSystem=full directive in logrotate.service which
> causes /usr to be mounted read-only for logrotate.  See the SANDBOXING
> section in systemd.exec(5).
>
> You can make /usr/local writable with
> "systemctl edit logrotate.service", enter the following line:
>
> ReadWritePaths=/usr/local
>
> in your editor and you're done.
>
> Cheers,
>Sven


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: column - how to get it updated?

[Richard Hector]

On 25/07/19 3:26 PM, Andrew Punnett wrote:
> Hi,
> 
> Debian currently uses the `column` command from FreeBSD. However, the
> `column` command included in the util-linux package from the Linux
> Kernel Organisation is much more useful.
> 
> There is a bug report about this at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908975, which ends
> with the Debian util-linux package maintainer stating:
> 
> "Until you've convinced the bsdmainutils maintainers we should change
> to the util-linux versions, there's nothing that can be done on the
> util-linux/bsdutils side - thus the wontfix tag."
> 
> How can we persuade the Debian bsdmainutils package maintainers to
> allow the Linux version of column to be shipped?

Can't they all get along by using /etc/alternatives?

Richard




signature.asc
Description: OpenPGP digital signature

Re: column - how to get it updated?

[Kenneth Parker]

On Wed, Jul 24, 2019 at 11:45 PM Andrew Punnett 
wrote:

>
> Debian currently uses the `column` command from FreeBSD. However, the
> `column` command included in the util-linux package from the Linux
> Kernel Organisation is much more useful.
>
> There is a bug report about this at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908975, which ends
> with the Debian util-linux package maintainer stating:
>
> "Until you've convinced the bsdmainutils maintainers we should change
> to the util-linux versions, there's nothing that can be done on the
> util-linux/bsdutils side - thus the wontfix tag."
>

In my "Development Days", I would have gotten the Source for the newer
version, Compile it in my own System, copy the result into /usr/local/bin
and put it before /usr/bin.

Do people still do Workarounds like this?

Are there ways to, then "Package it", and submit it back to Debian?  Based
on the above Bug Report, would that get you anywhere?  Thank you.


> How can we persuade the Debian bsdmainutils package maintainers to
> allow the Linux version of column to be shipped?
>

Do they have an Email List?

Kenneth Parker

column - how to get it updated?

[Andrew Punnett]

Hi,

Debian currently uses the `column` command from FreeBSD. However, the
`column` command included in the util-linux package from the Linux
Kernel Organisation is much more useful.

There is a bug report about this at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908975, which ends
with the Debian util-linux package maintainer stating:

"Until you've convinced the bsdmainutils maintainers we should change
to the util-linux versions, there's nothing that can be done on the
util-linux/bsdutils side - thus the wontfix tag."

How can we persuade the Debian bsdmainutils package maintainers to
allow the Linux version of column to be shipped?

Cheers,

Andrew

-- 
Andrew Punnett 

Re: Debian 10 logrotate

[Tan Shao Yi]

Hi Sven,

Thank you for the explanation.

I just wanted to add that when doing "systemctl edit logrotate.service", we 
also need to include the "[Service]" header before specifying ReadWritePaths.

Thank you.

Regards,
Tan Shao Yi

On 21/7/19, 5:55 PM, "Sven Joachim"  wrote:

On 2019-07-21 02:42 +, Tan Shao Yi wrote:

> I upgraded to Debian 10 recently and it looks like logrotate is not
> working on files outside the /var directory:

This is correct.

> For example,
>
> Jul 21 00:00:01 server-name logrotate[8874]: error: error renaming
> /usr/local/apache/logs/https-error_log.12.gz to
> /usr/local/apache/logs/https-error_log.13.gz: Read-only file system
> Jul 21 00:00:03 server-name logrotate[8874]: error: unable to open 
/usr/local/backup/mysql/mysql.sql.1 for compression
>
> The files are present, and I am able to logrotate them manually as
> root when I run logrotate against the config files in
> /etc/logrotate.d--it just fails when it is run automatically.
>
> May I know if something has changed recently to cause this?

It is the ProtectSystem=full directive in logrotate.service which causes
/usr to be mounted read-only for logrotate.  See the SANDBOXING section
in systemd.exec(5).

You can make /usr/local writable with
"systemctl edit logrotate.service", enter the following line:

ReadWritePaths=/usr/local

in your editor and you're done.

Cheers,
   Sven

Re: dpkg-reconfigure keyboard-configuration (Swedish with "|")

[Jonas Smedegaard]

Quoting David Wright (2019-07-16 19:41:17)
> On Sat 11 May 2019 at 01:22:09 (+0200), Jonas Smedegaard wrote:
> > > Den 2019-05-10 kl. 18:21, skrev David Wright:
> > > > For example, I append lines to /etc/console-setup/remap.inc to 
> > > > do things like enhancing the navigation keys, and preventing 
> > > > Alt-space from producing NO-BREAK SPACE (because it's too easy 
> > > > to catch the Alt by mistake). Little things like that. And in 
> > > > fvwm I have keys for audio control, taking screen shots, 
> > > > capturing the screen as a movie, rotating the monitor with 
> > > > xrandr, etc.
> > 
> > @David, if you care to share your personal tweaks then I am 
> > interested in having a closer look, for inspiration and possibly for 
> > more general use.
> 
> Sorry for the delay replying, but in view of my managing to get 
> stretch installed on the last of my machines, and with buster coming 
> up, I'd thought I'd do a bit of tidying.

Thanks a lot!

I am currently deeply engaged at Debconf in Curitiba, Brazil - but I 
will sure have a closer look at your many details later, and see if I 
can make some of them more reusable.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

nemo, no error-crashes [in Stretch]

[deb]

on Debian Stretch 9.8 to 9.9,
has anyone else run into nemo just flat out crashing?

No errors shown at crash.
No errors that I can dig out in logs.

nemo just flat out "goes away", often at the end of completing a copy. 
Sometimes just when tapping a folder. No set type of copy. No set folder.



If more than one nemo is open -- they all go away at the same time.


No such error from nautilus.

 * Memory usage is generally 30% at all times.
 * Plenty of swap space.


I was just wondering if other folks have seen this -- because I did not 
catch it mentioned in the lists' subject-lines.



Thank you.

Re: buster, ekiga.

[tomas]

On Wed, Jul 24, 2019 at 05:12:39PM -0400, Greg Wooledge wrote:
> On Wed, Jul 24, 2019 at 11:02:33PM +0200, to...@tuxteam.de wrote:
> > On Wed, Jul 24, 2019 at 03:49:38PM -0500, David Wright wrote:
> > 
> > [...]
> > 
> > > If I read a file that has an embedded NUL into an editor, I would
> > > consider it suboptimal if the editor ceased reading any more of the
> > > file when it hit a NUL.
> > 
> > Vim and Emacs both qualify. Are there other editors? (yes, a bit
> > tongue-in-cheek ;-P
> 
> I was curious, so I generated a "text" file with a NUL in it, and opened
> it in nano.  To my surprise, nano actually handled it extremely well.

Phew :-)

Thanks
-- t


signature.asc
Description: Digital signature

Re: buster, ekiga.

[Greg Wooledge]

On Wed, Jul 24, 2019 at 11:02:33PM +0200, to...@tuxteam.de wrote:
> On Wed, Jul 24, 2019 at 03:49:38PM -0500, David Wright wrote:
> 
> [...]
> 
> > If I read a file that has an embedded NUL into an editor, I would
> > consider it suboptimal if the editor ceased reading any more of the
> > file when it hit a NUL.
> 
> Vim and Emacs both qualify. Are there other editors? (yes, a bit
> tongue-in-cheek ;-P

I was curious, so I generated a "text" file with a NUL in it, and opened
it in nano.  To my surprise, nano actually handled it extremely well.
The NUL was rendered as the two characters ^@ in the terminal, and
the cursor only "rested" on one of the two characters when moving
left-to-right across that line.  Ctrl-D (with the cursor on one of the ^@
characters) removed both characters from the terminal display, and after
saving, the NUL byte was gone from the file.

It was basically identical to how vim handles it, just with different
key bindings.

Re: buster, ekiga.

[tomas]

On Wed, Jul 24, 2019 at 10:57:09PM +0200, Sven Joachim wrote:
> On 2019-07-24 15:49 -0500, David Wright wrote:
> 
> > Where is the definition of NUL as "ignore everything following this
> > character"? AFAICT the mutt manual says nothing about NUL at all.
> 
> In the design of the C language, where NUL is the end of the string as
> we know it.

But you don't read (in C) off a random file (or worse, off The
Intertubes!) and expect well-formed strings. Because then, you're
in hot water anyway (or shouldn't be doing C, perhaps).

Cheers
-- t


signature.asc
Description: Digital signature

Re: buster, ekiga.

[tomas]

On Wed, Jul 24, 2019 at 03:49:38PM -0500, David Wright wrote:

[...]

> If I read a file that has an embedded NUL into an editor, I would
> consider it suboptimal if the editor ceased reading any more of the
> file when it hit a NUL.

Vim and Emacs both qualify. Are there other editors? (yes, a bit
tongue-in-cheek ;-P

FWIW, I (somewhat strongly) disagree with Michael here. I'm a
strong proponent of Postel's principle (both sides!). But I do
know theres the exactly opposite position. That's life.

Cheers
-- t


signature.asc
Description: Digital signature

Re: buster, ekiga.

[Sven Joachim]

On 2019-07-24 15:49 -0500, David Wright wrote:

> Where is the definition of NUL as "ignore everything following this
> character"? AFAICT the mutt manual says nothing about NUL at all.

In the design of the C language, where NUL is the end of the string as
we know it.

Cheers,
   Sven

Re: buster, ekiga.

[Greg Wooledge]

On Wed, Jul 24, 2019 at 03:49:38PM -0500, David Wright wrote:
> If I read a file that has an embedded NUL into an editor, I would
> consider it suboptimal if the editor ceased reading any more of the
> file when it hit a NUL.
> 
> In the same way, I expect mutt and its pager to behave much the
> likewise. The only debate would be how/whether to display the NUL
> itself. It could just ignore it entirely, as if it wasn't there, or
> it could escape it in various ways. Having no indication of the
> *existence* of the characters following the NUL is suboptimal in
> my book.
> 
> Where is the definition of NUL as "ignore everything following this
> character"? AFAICT the mutt manual says nothing about NUL at all.

If you feel strongly about this issue, then you probably need to take
it up with the mutt maintainers, on their mailing list or however they
track bugs and problems.  I don't want to speak for the Debian developers
here, but this seems like the kind of bug report that would just get
forwarded upstream anyway.

Re: buster, ekiga.

[David Wright]

On Wed 24 Jul 2019 at 13:51:22 (-0400), Michael Stone wrote:
> On Wed, Jul 24, 2019 at 07:28:11PM +0200, to...@tuxteam.de wrote:
> > On Wed, Jul 24, 2019 at 01:10:49PM -0400, Michael Stone wrote:
> > > On Wed, Jul 24, 2019 at 09:29:47AM -0500, David Wright wrote:
> > > >However, I would not award +1 to the MUAs that, we are told,
> > > >truncate the message, or even just the line, at the first
> > > >NUL byte. That could yield a message with a very different sense
> > > >from what the sender wrote.
> > > 
> > > And that is what happens when you do something that is out of spec
> > > for the protocol--the recipient's behavior is undefined and possibly
> > > suboptimal. (A NUL is specifically disallowed per RFC 2822.)
> > 
> > But never forget the Postel Principle. In RFC land, nasal daemons
> > are frowned upon ;-)
> 
> The reason it was specifically disallowed in RFC2822 is because it
> broke things and gave unexpected results. Just arguing that things
> should be other than they are rarely changes anything. Raw NULs are
> going to cause problems for software that uses NUL-terminated strings.

If I read a file that has an embedded NUL into an editor, I would
consider it suboptimal if the editor ceased reading any more of the
file when it hit a NUL.

In the same way, I expect mutt and its pager to behave much the
likewise. The only debate would be how/whether to display the NUL
itself. It could just ignore it entirely, as if it wasn't there, or
it could escape it in various ways. Having no indication of the
*existence* of the characters following the NUL is suboptimal in
my book.

Where is the definition of NUL as "ignore everything following this
character"? AFAICT the mutt manual says nothing about NUL at all.

All this ignores how the NUL got into the message: accidentally placed
there, or accidentally converted from 0x80, or deliberately included
(correctly encoded in, say, quoted-printable).

> There are ways around that, and some of those techiniques have already
> been implemented such that there are standard mechanisms for sending
> binary data in email. Insisting that everybody also handle
> non-compliant input from people who chose not to implement those
> standards in the past 20+ years, and to do so in a particular way, is
> a waste of time because it simply won't happen. The Postel approach is
> why some MTAs actually accepted the message even though it was
> noncompliant, and on the modern internet it's quite likely that many
> recipients never saw it because their MTA simply threw it away. (And
> many recipients who did see it also saw that it got a bump in its spam
> score because it contained bogus content.) The idea that everyone must
> accept anything is obsolete on the modern internet, and while sending
> noncompliant data out of sheer cussedness may be satisfying, it's also
> likely to leave you shouting to an empty room. A better implementation
> of the robustness principle would have bounced the message early so
> the sender would know that there was a problem with the message which
> would likely interfere with recipients' ability to read
> it.

Cheers,
David.

Re: Slab Unreclaimable is continually growing

[Reco]

Hi.

On Wed, Jul 24, 2019 at 06:54:42PM +0200, Matthias Böttcher wrote:
>   OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
> 307534 304741  99%0,20K  16186   19 64744K vm_area_struct
>  14280  14274  99%3,69K   17858 57120K task_struct
> 178048 152224  85%0,25K  11128   16 44512K filp
>   8536   8536 100%4,00K   10678 34144K kmalloc-4096
>  14640  14640 100%2,06K976   15 31232K sighand_cache
> 
> How can I detect what is eating up my memory in SUnreclaim (slab 
> unreclaimable)?

You did it already.
"vm_area_struct" is a kernel structure for anonymous memory allocations.
"task_struct" is a kernel structure for maintaining process execution.
"filp" is a kernel structure for virtual memory.

My guess is - a small number of processes that constantly allocate
memory in small numbers by executing brk(2) or its modern equivalents.

Or a relatively large number of short-lived processes.


I'd start with "pidstat -rl 1 10".

Reco

Programming pointer? -- options to run Python3 from web page (not via Flask/cgi/Django)

[deb]

I have a large static html/AJAX .js apache2 site.

If I want to have a server-side script just to
handle a contact  and push mail out;
is there a non-(Django/cgi**/Flask) way to
run a small Python3 script to do this?

The python3 mail script already works standalone (tests out fine from 
CLI, on the server).


I'd rather not Flask out the whole website just to get the ability to 
run one .py script for contact mail.


I'd rather not add .php to the server just to do this contact form.

** /cgi-bin to run the single python3 script is deprecated [Correct?].

It is a straight-up HTML5 form ... that USED to post to .aspx.



While I would prefer the answer to be python-ish,
it does to Have to be python.


Thank you!

Re: Sending multiple copies to printers results in only one copy printing

[Brian]

On Wed 24 Jul 2019 at 07:31:47 -0700, Shahryar Afifi wrote:

> Try different driver
> 
> On Wed, 2019-07-24 at 09:14 -0400, Oflameo wrote:
> > I have a Brother DCP-L2550DW series and a Brother MFC-J497DW. When I
> > send multiple copies of one page to be print out to either printer,
> > the printer only prints the first copy and stops printing.

Such as? This is chocolate fireguard advice.

Oflameo would do better to say which OS he is using? What versions of
CUPS and cups-filters are in use? What is being used to print (command
line, application)? What non-free packages have been installed?. What
PPD is being used?

-- 
Brian.

Re: buster, ekiga.

[Michael Stone]

On Wed, Jul 24, 2019 at 07:28:11PM +0200, to...@tuxteam.de wrote:

On Wed, Jul 24, 2019 at 01:10:49PM -0400, Michael Stone wrote:

On Wed, Jul 24, 2019 at 09:29:47AM -0500, David Wright wrote:
>However, I would not award +1 to the MUAs that, we are told,
>truncate the message, or even just the line, at the first
>NUL byte. That could yield a message with a very different sense
>from what the sender wrote.

And that is what happens when you do something that is out of spec
for the protocol--the recipient's behavior is undefined and possibly
suboptimal. (A NUL is specifically disallowed per RFC 2822.)


But never forget the Postel Principle. In RFC land, nasal daemons
are frowned upon ;-)


The reason it was specifically disallowed in RFC2822 is because it broke 
things and gave unexpected results. Just arguing that things should be 
other than they are rarely changes anything. Raw NULs are going to cause 
problems for software that uses NUL-terminated strings. There are ways 
around that, and some of those techiniques have already been implemented 
such that there are standard mechanisms for sending binary data in 
email. Insisting that everybody also handle non-compliant input from 
people who chose not to implement those standards in the past 20+ years, 
and to do so in a particular way, is a waste of time because it simply 
won't happen. The Postel approach is why some MTAs actually accepted the 
message even though it was noncompliant, and on the modern internet it's 
quite likely that many recipients never saw it because their MTA simply 
threw it away. (And many recipients who did see it also saw that it got 
a bump in its spam score because it contained bogus content.) The idea 
that everyone must accept anything is obsolete on the modern internet, 
and while sending noncompliant data out of sheer cussedness may be 
satisfying, it's also likely to leave you shouting to an empty room. A 
better implementation of the robustness principle would have bounced the 
message early so the sender would know that there was a problem with the 
message which would likely interfere with recipients' ability to read

it.

Re: buster, ekiga.

[tomas]

On Wed, Jul 24, 2019 at 01:10:49PM -0400, Michael Stone wrote:
> On Wed, Jul 24, 2019 at 09:29:47AM -0500, David Wright wrote:
> >However, I would not award +1 to the MUAs that, we are told,
> >truncate the message, or even just the line, at the first
> >NUL byte. That could yield a message with a very different sense
> >from what the sender wrote.
> 
> And that is what happens when you do something that is out of spec
> for the protocol--the recipient's behavior is undefined and possibly
> suboptimal. (A NUL is specifically disallowed per RFC 2822.)

But never forget the Postel Principle. In RFC land, nasal daemons
are frowned upon ;-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: buster, ekiga.

[Michael Stone]

On Wed, Jul 24, 2019 at 09:29:47AM -0500, David Wright wrote:

However, I would not award +1 to the MUAs that, we are told,
truncate the message, or even just the line, at the first
NUL byte. That could yield a message with a very different sense
from what the sender wrote.


And that is what happens when you do something that is out of spec for 
the protocol--the recipient's behavior is undefined and possibly 
suboptimal. (A NUL is specifically disallowed per RFC 2822.)

Slab Unreclaimable is continually growing

[Matthias Böttcher]

Hi list,

my buster is using more and more memory until the oom-killer is
invoked. This occurs after two days of uptime, but no process is using
that memory. Slab seems suspicious to me.

Kernel: 4.19.37-5+deb10u1 (2019-07-19) x86_64

from /proc/meminfo after 8 hours uptime:

MemTotal:4041116 kB
MemFree: 3165992 kB
MemAvailable:3246560 kB
Buffers:   30144 kB
Cached:   240356 kB
SwapCached:0 kB
Active:   162056 kB
Inactive: 144268 kB
SwapTotal:   4194300 kB
SwapFree:4194300 kB

Slab: 521364 kB
SReclaimable:  66776 kB
SUnreclaim:   454588 kB

My Top 5 in slabtop:

$ sudo slabtop --sort c --once | head -n12

 Active / Total Objects (% used): 2234301 / 2270100 (98,4%)
 Active / Total Slabs (% used)  : 70832 / 70832 (100,0%)
 Active / Total Caches (% used) : 98 / 124 (79,0%)
 Active / Total Size (% used)   : 501034,52K / 509459,17K (98,3%)
 Minimum / Average / Maximum Object : 0,01K / 0,22K / 8,00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
307534 304741  99%0,20K  16186   19 64744K vm_area_struct
 14280  14274  99%3,69K   17858 57120K task_struct
178048 152224  85%0,25K  11128   16 44512K filp
  8536   8536 100%4,00K   10678 34144K kmalloc-4096
 14640  14640 100%2,06K976   15 31232K sighand_cache

Active / Total Size is growing continually about 60 MB per hour.

How can I detect what is eating up my memory in SUnreclaim (slab unreclaimable)?

Thanks in advance
Matthias Böttcher

Re: Sending multiple copies to printers results in only one copy printing

[Shahryar Afifi]

Try different driver


On Wed, 2019-07-24 at 09:14 -0400, Oflameo wrote:
> I have a Brother DCP-L2550DW series and a Brother MFC-J497DW. When I
> send multiple copies of one page to be print out to either printer,
> the printer only prints the first copy and stops printing.

Re: buster, ekiga.

[David Wright]

On Wed 24 Jul 2019 at 07:10:14 (-0400), rhkra...@gmail.com wrote:
> On Tuesday, July 23, 2019 11:07:37 AM 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.
> 
> +1

Well, since Greg's message was posted, the OP has explained their
actions, which were made with good intentions. I hope my reply in
the other thread will save the OP some time and effort as well as
benefitting us all here.

However, I would not award +1 to the MUAs that, we are told,
truncate the message, or even just the line, at the first
NUL byte. That could yield a message with a very different sense
from what the sender wrote. If the MUA is outputting Unicode,
there exists a REPLACEMENT CHARACTER (U+FFFD) for replacing an
unknown, unrecognized or unrepresentable character. But if the
MUA decides that it's valid, but unprintable, it should just
escape it as is usual.

Cheers,
David.

Sending multiple copies to printers results in only one copy printing

[Oflameo]

I have a Brother DCP-L2550DW series and a Brother MFC-J497DW. When I
send multiple copies of one page to be print out to either printer, the
printer only prints the first copy and stops printing.

Re: buster, ekiga.

[rhkramer]

On Tuesday, July 23, 2019 11:07:37 AM 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.

+1

Re: About haproxy and CVE-2019-14241

[Reco]

Hi.

On Wed, Jul 24, 2019 at 10:05:49AM +0200, Martin wrote:
> I've received an advisory issued by one of my client's CERT. It is about 
> haproxy and CVE-2019-14241:
> 
> "HAProxy contains a flaw in the htx_manage_client_side_cookies() function in 
> proto_htx.c that is triggered when handling certain threads. This may allow a 
> remote attacker to cause a denial of service."
> 
> At MITRE, this CVE exists, but I did not get any about it from the DSA or 
> oss-security list. Does one of you know about more this?

[1] lists CVE-2019-14241 as "resolved".
Presumably there was no DSA because Debian haproxy is not affected by
this issue.

As for the oss-security - reporting vulnerabilities there is merely a
courtesy. Reporting a vulnerability to the upstream - that's a must.

Reco

[1] https://security-tracker.debian.org/tracker/source-package/haproxy

About haproxy and CVE-2019-14241

[Martin]

Hi list,

I've received an advisory issued by one of my client's CERT. It is about 
haproxy and CVE-2019-14241:

"HAProxy contains a flaw in the htx_manage_client_side_cookies() function in 
proto_htx.c that is triggered when handling certain threads. This may allow a 
remote attacker to cause a denial of service."

At MITRE, this CVE exists, but I did not get any about it from the DSA or 
oss-security list. Does one of you know about more this?

Martin