Re: pkg-config does not see a package that i installed via apt-get (libmypaint)

[Dan Hitt]

On Mon, Nov 11, 2019 at 8:02 PM The Wanderer  wrote:

> On 2019-11-11 at 22:39, Dan Hitt wrote:
>
> > I installed the package libmypaint1.3.0 on my debian 10 system.
> >
> > I can tell it is installed because when i run the command
> > sudo apt-get install libmypaint-1.3.0
> > the system responds with "libmypaint-1.3-0 is already the newest
> version".
> >
> > It also says "libmypaint-1.3-0 set to manually installed", which i do not
> > know how to interpret.
>
> If you install a package named foo, and that package depends on another
> one named libbar, libbar will be installed but marked as automatically
> installed. What that means in practice is that if you later remove foo,
> apt will detect that nothing needs to keep libbar around, and will
> suggest that you might want to remove it. (At least I believe that's the
> default configuration.)
>
> If you want to keep libbar around for other reasons - for example, if
> you've compiled a program which loads that library, but haven't built a
> package to let apt know about that - then you can mark libbar as
> manually installed, and apt won't suggest removing it anymore.
>
> In practice doing this with library packages directly is usually not a
> great idea; it's usually better to do it with the matching -dev package
> instead. Speaking of which:
>
> > Nevertheless, if i run the command
> > pkg-config --exists --print-errors "libmypaint >= 1.3.0"
> > i get the message "No package 'libmypaint' found" (and exit status 1).
>
> package-config draws on .pc files.
>
> $ apt-file search libmypaint.pc
> libmypaint-dev: /usr/lib/x86_64-linux-gnu/pkgconfig/libmypaint.pc
>
> The .pc file for libmypaint is in libmypaint-dev, not in libmypaint-1.3-0.
>
> Try installing the -dev package.
>
> --
>The Wanderer
>
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard Shaw
>
>
Awesome, thank you so much Wanderer!

I installed libmypaint-dev, and now pkg-config sees the package as you
predicted.

dan

Re: pkg-config does not see a package that i installed via apt-get (libmypaint)

[The Wanderer]

On 2019-11-11 at 22:39, Dan Hitt wrote:

> I installed the package libmypaint1.3.0 on my debian 10 system.
> 
> I can tell it is installed because when i run the command
> sudo apt-get install libmypaint-1.3.0
> the system responds with "libmypaint-1.3-0 is already the newest version".
> 
> It also says "libmypaint-1.3-0 set to manually installed", which i do not
> know how to interpret.

If you install a package named foo, and that package depends on another
one named libbar, libbar will be installed but marked as automatically
installed. What that means in practice is that if you later remove foo,
apt will detect that nothing needs to keep libbar around, and will
suggest that you might want to remove it. (At least I believe that's the
default configuration.)

If you want to keep libbar around for other reasons - for example, if
you've compiled a program which loads that library, but haven't built a
package to let apt know about that - then you can mark libbar as
manually installed, and apt won't suggest removing it anymore.

In practice doing this with library packages directly is usually not a
great idea; it's usually better to do it with the matching -dev package
instead. Speaking of which:

> Nevertheless, if i run the command
> pkg-config --exists --print-errors "libmypaint >= 1.3.0"
> i get the message "No package 'libmypaint' found" (and exit status 1).

package-config draws on .pc files.

$ apt-file search libmypaint.pc
libmypaint-dev: /usr/lib/x86_64-linux-gnu/pkgconfig/libmypaint.pc

The .pc file for libmypaint is in libmypaint-dev, not in libmypaint-1.3-0.

Try installing the -dev package.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

pkg-config does not see a package that i installed via apt-get (libmypaint)

[Dan Hitt]

I installed the package libmypaint1.3.0 on my debian 10 system.

I can tell it is installed because when i run the command
sudo apt-get install libmypaint-1.3.0
the system responds with "libmypaint-1.3-0 is already the newest version".

It also says "libmypaint-1.3-0 set to manually installed", which i do not
know how to interpret.

Nevertheless, if i run the command
pkg-config --exists --print-errors "libmypaint >= 1.3.0"
i get the message "No package 'libmypaint' found" (and exit status 1).

I would like to fix this, but i don't want to do a frankendebian on my
system, especially so soon after i set it up about 10 days ago . . .

Oh -- and as to why i want pkg-config to see the package, that's because
i'm trying to build some software that's checking dependencies using
pkg-config, and the check seems pretty reasonable to me . . .

TIA for any info or advice.

dan

Re: intel video

[Felix Miata]

D. R. Evans composed on 2019-11-11 17:55 (UTC-0700):

>> Felix Miata wrote:

>>> At the grub menu use the E key to edit the linux line to include

>>> video=1920x1080

> Bingo! (Actually 1920x1200).

In your OP you wrote 1920x1280, so I had to guess what you meant.

> So I've added that to /etc/default/grub, and run update-grub, and now it looks
> fine once I log in.

> (For some reason, the actual login screen is still low-res; it looks ugly, but
> I can live with that unless someone wants to offer a suggestion to fix it.)

What you've done is a good workaround, but not a genuine fix, or determinative 
why
the problem presented.

Compare the output from xrandr on the problem system to xrandr from your two
others that use that display. I expect you'll find quite a difference.

There are some quirks I'm unfamiliar with in Skylake systems. Your log shows

(EE) modeset(G0): glamor initialization failed
(EE) Failed to open authorization file "/var/run/sd..": No such file or 
directory

Those are bad. I don't know why there should be both modeset(G0) and modeset(0) 
in
the same log when only one display is in use. IME, there should only be the 
latter
then only one GPU exists and only one output is in use.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: intel video

[D. R. Evans]

D. R. Evans wrote on 11/11/19 5:32 PM:
> Felix Miata wrote on 11/11/19 4:58 PM:
>> D. R. Evans composed on 2019-11-11 16:04 (UTC-0700):
>>
>>> The chip is an E3-1245, which is supposed to be able to operate at 4096x2304
>>> resolution.
>>
>>> Any suggestions as to what I might need to do to improve at least the
>>> logged-in resolution?
>>


>>
>> At the grub menu use the E key to edit the linux line to include

>>  video=1920x1080

Bingo! (Actually 1920x1200).

So I've added that to /etc/default/grub, and run update-grub, and now it looks
fine once I log in.

(For some reason, the actual login screen is still low-res; it looks ugly, but
I can live with that unless someone wants to offer a suggestion to fix it.)

Thanks so much.

  Doc

-- 
Web:  http://enginehousebooks.com/drevans





signature.asc
Description: OpenPGP digital signature

Re: intel video

[D. R. Evans]

Felix Miata wrote on 11/11/19 4:58 PM:
> D. R. Evans composed on 2019-11-11 16:04 (UTC-0700):
> 
>> The chip is an E3-1245, which is supposed to be able to operate at 4096x2304
>> resolution.
> 
>> Any suggestions as to what I might need to do to improve at least the
>> logged-in resolution?
> 
> Try a different video cable type if you can.
> 
> pastebinit /var/log/Xorg.0.log
> or
> pastebinit ~/.local/share/xorg/Xorg.0.log
> 
> whichever of the two exists and is the newer if both exist. From there we 
> might be
> able to turn an error message into a solution.

Only the first exists:
  http://paste.debian.net/1115831/

> 
> At the grub menu use the E key to edit the linux line to include
> 
>   plymouth.enable=0
> and/or
>   video=1920x1080
> 

I'll try those when I'm free to reboot the machine a couple of times, which
should be in two or three hours or so.

  Doc

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

Re: intel video

[D. R. Evans]

Michael Lange wrote on 11/11/19 4:11 PM:

> (...)
>> The chip is an E3-1245, which is supposed to be able to operate at
>> 4096x2304 resolution.
>>
>> Any suggestions as to what I might need to do to improve at least the
>> logged-in resolution?
>>
> 
> just a guess: maybe some firmware file(s) from the nonfree firmware
> package are missing? 
> 

Do you have any idea how I would find out if there are any such files missing?
Looking at the names and descriptions, I don't see anything obvious that would
help; but that might not mean much.

  Doc


-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

Re: intel video

[Felix Miata]

D. R. Evans composed on 2019-11-11 16:04 (UTC-0700):

> The chip is an E3-1245, which is supposed to be able to operate at 4096x2304
> resolution.

> Any suggestions as to what I might need to do to improve at least the
> logged-in resolution?

Try a different video cable type if you can.

pastebinit /var/log/Xorg.0.log
or
pastebinit ~/.local/share/xorg/Xorg.0.log

whichever of the two exists and is the newer if both exist. From there we might 
be
able to turn an error message into a solution.

At the grub menu use the E key to edit the linux line to include

plymouth.enable=0
and/or
video=1920x1080

might be worth testing to see if it makes a difference.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: intel video

[David]

On Tue, 12 Nov 2019 at 10:23, D. R. Evans  wrote:
> Felix Miata wrote on 11/11/19 4:08 PM:
> > D. R. Evans composed on 2019-11-11 16:04 (UTC-0700):
> >
> >> Any suggestions as to what I might need to do to improve at least the
> >> logged-in resolution?
> >
> > Make sure your kernel cmdline does not include nomodeset. Sometimes it is
> > necessary for installation to work, but when it remains on the installed 
> > system it
> > is a big handicap:
> > 
>
> No, there's nothing like that in /etc/default/grub, which I assume is where I
> needed to look.

Run the command:
cat /proc/cmdline

to see the command line that your kernel received when it
last booted.

Re: intel video

[Dan Ritter]

D. R. Evans wrote: 
> It's an Intel chipset. The installation procedure installed
> xserver-xorg-video-intel, which suggests removing that package if one's system
> is newer than 2007, and letting the X server handle everything. So I removed
> that package and rebooted, but nothing obvious changed: still a low-res login
> screen and a logged-in display limited to 1600x1200.
> 
> The chip is an E3-1245, which is supposed to be able to operate at 4096x2304
> resolution.
> 
> Any suggestions as to what I might need to do to improve at least the
> logged-in resolution?

I'm guessing that the EDID feedback from the monitor is being
mishandled. If it's VGA, swap to DVI or HDMI if you can. 

If not, or that doesn't solve it, put the intel specific xorg server
back in; as root run

X -configure

to generate a basic xorg.conf. Put it in /etc/X11/

and specify a 1920x1080 or 1920x1200 modeline.

-dsr-

Re: UVC device.

[Dan Ritter]

pe...@easthope.ca wrote: 
> From: Dan Ritter
> > Step 3: Does lsusb show the device?
> 
> peter@dalton:~$ lsusb -vs 005 | head
> Couldn't open device, some information will be missing
> 
> Bus 003 Device 005: ID 1164:f533 YUAN High-Tech Development Co., Ltd 
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.10
>   bDeviceClass  255 Vendor Specific Class
>   bDeviceSubClass 0 
>   bDeviceProtocol 0 
>   bMaxPacketSize064
>   
> The full output is at http://easthope.ca/lsusb.vs5.txt .  UVC not 
> mentioned.

Oooch, yeah. This is not going to work in anything other than a
Windows machine with the manufacturer's driver loaded.

> > Step 4: Why do you think it's UVC compliant? 
> 
> Naive assumption that USB + video = UVC.

I have been bitten too many times by that sort of assumption.
Now you have, too.

> Management by committee.  I suggested the Startech USB32VGCAPRO which 
> shows Mac support.  
> https://www.startech.com/AV/Converters/Video/usb-3-capture-device-vga~USB32VGCAPRO
> 
> Staples doesn't sell that but lists the Startech USB3HDCAP.  Someone 
> decided to substitute.  (This is the public sector. Throw money until 
> something works or the administration loses interest.)
> 
> We should aim for an adapter claiming to support UVC and Linux.  
> Two examples.
> https://inogeni.com/product/vga-to-usb-3-0
> https://www.epiphan.com/store/avio-hd/
> 
> (https://inogeni.com/product/hdmi-dvi-to-usb-3 can not convert 
> analogue to digital. Therefore can not be used with a passive VGA to 
> DVI adapter.)
> 
> USB in a disused Mac might work. For a PC with Debian buy the USB 
> adapter sold or recommended by the vendor of the converter.
> 
> Additional tips always welcome.

Don't send that "someone" out to buy things again. Order from a
store with a good reputation for taking returns.

I like the looks of that Inogeni, and you'd think that a public
sector org in Vancouver would like to buy from a Canadian
company. Or I think so, anyway.

-dsr-

Re: intel video

[D. R. Evans]

Felix Miata wrote on 11/11/19 4:08 PM:
> D. R. Evans composed on 2019-11-11 16:04 (UTC-0700):
> 
>> Any suggestions as to what I might need to do to improve at least the
>> logged-in resolution?
> 
> Make sure your kernel cmdline does not include nomodeset. Sometimes it is
> necessary for installation to work, but when it remains on the installed 
> system it
> is a big handicap:
> 
> 

No, there's nothing like that in /etc/default/grub, which I assume is where I
needed to look.

  Doc

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

Re: intel video

[Michael Lange]

Hi,

On Mon, 11 Nov 2019 16:04:56 -0700
"D. R. Evans"  wrote:

(...)
> The chip is an E3-1245, which is supposed to be able to operate at
> 4096x2304 resolution.
> 
> Any suggestions as to what I might need to do to improve at least the
> logged-in resolution?
> 

just a guess: maybe some firmware file(s) from the nonfree firmware
package are missing? 

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

It would be illogical to assume that all conditions remain stable.
-- Spock, "The Enterprise Incident", stardate 5027.3

Re: loading shared objects

[deloptes]

Lev wrote:

> Dear list,
> 
> 
> Maybe it is a bit off topic, but I encountered a dynamic linking problem
> on my Debian stable system.
> 
> A program (KiCad) tries (and fails) to load a library
> (libngspice.so.0.0.0).
> 
> I set LD_DEBUG=libs, and I get this:
> 
> [...]
>   7390:   find library=libngspice.so.0 [0]; searching
>   7390:search cache=/etc/ld.so.cache
>   7390: trying file=/usr/local/lib/libngspice.so.0
>   7390:
>   7390:   find library=libfftw3.so.3 [0]; searching
>   7390:search cache=/etc/ld.so.cache
>   7390: trying file=/usr/lib/x86_64-linux-gnu/libfftw3.so.3
>   7390:
>   7390:
>   7390:   calling init: /usr/lib/x86_64-linux-gnu/libfftw3.so.3
>   7390:
>   7390:
>   7390:   calling init: /usr/local/lib/libngspice.so.0
>   7390:
>   7390:
>   7390:   calling init: /usr/local/bin/_eeschema.kiface
>   7390:
>   7390:   find library=libngspice.so.0.0.0 [0]; searching
>   7390:search cache=/etc/ld.so.cache
>   7390:search
>  
path=/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64/x86_64:/lib/tls/x86_64:/lib/tls/x86_64:/lib/tls:/lib/x86_64/x86_64:/lib/x86_64:/lib/x86_64:/lib:/usr/lib/tls/x86_64/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64/x86_64:/usr/lib/x86_64:/usr/lib/x86_64:/usr/lib
>   (system search path)
>   7390: trying
>   file=/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libngspice.so.0.0.0
>   7390: trying
>   file=/lib/x86_64-linux-gnu/tls/x86_64/libngspice.so.0.0.0
>   7390: trying
>   file=/lib/x86_64-linux-gnu/tls/x86_64/libngspice.so.0.0.0
>   7390: trying file=/lib/x86_64-linux-gnu/tls/libngspice.so.0.0.0
>   7390: trying
>   file=/lib/x86_64-linux-gnu/x86_64/x86_64/libngspice.so.0.0.0
>   7390: trying file=/lib/x86_64-linux-gnu/x86_64/libngspice.so.0.0.0
>   7390: trying file=/lib/x86_64-linux-gnu/x86_64/libngspice.so.0.0.0
>   7390: trying file=/lib/x86_64-linux-gnu/libngspice.so.0.0.0
>   7390: trying
>   file=/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libngspice.so.0.0.0
>   7390: trying
>   file=/usr/lib/x86_64-linux-gnu/tls/x86_64/libngspice.so.0.0.0
>   7390: trying
>   file=/usr/lib/x86_64-linux-gnu/tls/x86_64/libngspice.so.0.0.0
>   7390: trying
>   file=/usr/lib/x86_64-linux-gnu/tls/libngspice.so.0.0.0
>   7390: trying
>   file=/usr/lib/x86_64-linux-gnu/x86_64/x86_64/libngspice.so.0.0.0
>   7390: trying
>   file=/usr/lib/x86_64-linux-gnu/x86_64/libngspice.so.0.0.0
>   7390: trying
>   file=/usr/lib/x86_64-linux-gnu/x86_64/libngspice.so.0.0.0
>   7390: trying file=/usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0
>   7390: trying file=/lib/tls/x86_64/x86_64/libngspice.so.0.0.0
>   7390: trying file=/lib/tls/x86_64/libngspice.so.0.0.0
>   7390: trying file=/lib/tls/x86_64/libngspice.so.0.0.0
>   7390: trying file=/lib/tls/libngspice.so.0.0.0
>   7390: trying file=/lib/x86_64/x86_64/libngspice.so.0.0.0
>   7390: trying file=/lib/x86_64/libngspice.so.0.0.0
>   7390: trying file=/lib/x86_64/libngspice.so.0.0.0
>   7390: trying file=/lib/libngspice.so.0.0.0
>   7390: trying file=/usr/lib/tls/x86_64/x86_64/libngspice.so.0.0.0
>   7390: trying file=/usr/lib/tls/x86_64/libngspice.so.0.0.0
>   7390: trying file=/usr/lib/tls/x86_64/libngspice.so.0.0.0
>   7390: trying file=/usr/lib/tls/libngspice.so.0.0.0
>   7390: trying file=/usr/lib/x86_64/x86_64/libngspice.so.0.0.0
>   7390: trying file=/usr/lib/x86_64/libngspice.so.0.0.0
>   7390: trying file=/usr/lib/x86_64/libngspice.so.0.0.0
>   7390: trying file=/usr/lib/libngspice.so.0.0.0
>   7390:
> 
> 
> I have this in my /etc/ld.so.conf.d/libc.conf:
> 
> /usr/local/lib
> 
> 
> so it shall find the library. But this is interesting that in the above
> log, /usr/local/lib is missing. I run ldconfig several times. I also
> greped ld.so.cache, and there is the library there.
> 
> Can you explain me what is going on here?
> 

I am not using recent KDE, but I recall it had it's own variables for the
libraries. Might be you need to read docs.

What I think will work (always worked for me) is set 

LD_LIBRARY_PATH=/usr/local/lib kicad

or 

export LD_LIBRARY_PATH=/usr/local/lib
kicad

also check that library 

Re: intel video

[Felix Miata]

D. R. Evans composed on 2019-11-11 16:04 (UTC-0700):

> Any suggestions as to what I might need to do to improve at least the
> logged-in resolution?

Make sure your kernel cmdline does not include nomodeset. Sometimes it is
necessary for installation to work, but when it remains on the installed system 
it
is a big handicap:

-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

intel video

[D. R. Evans]

I just installed buster on a new machine (well, new to me; I think that the
mobo is two or three years old).

The GUI splash screen comes up with very large icons (i.e., it's low res), and
once I am logged in, the (KDE) function to control the size of display
provides nothing higher than 1600x1200. My other two (non-Intel) buster
systems on the same monitor happily generate a high-res login screen and
operate at 1920x1280 once I'm logged in (possibly that's the resolution of the
login screen as well; I don't know how to determine the log-in resolution).

It's an Intel chipset. The installation procedure installed
xserver-xorg-video-intel, which suggests removing that package if one's system
is newer than 2007, and letting the X server handle everything. So I removed
that package and rebooted, but nothing obvious changed: still a low-res login
screen and a logged-in display limited to 1600x1200.

The chip is an E3-1245, which is supposed to be able to operate at 4096x2304
resolution.

Any suggestions as to what I might need to do to improve at least the
logged-in resolution?

  Doc

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

Re: UVC device.

[peter]

Apologies for the duplicate copy.

From: Dan Ritter
Date: Sat, 9 Nov 2019 08:03:35 -0500
> Step 1: are you using a USB3 port? It says it will not work in a
> USB2 port.

Missed that.  

None of the local shops in Vancouver has a USB 3 adapter card in 
stock.  Amazon and etc. offer them of course.  3.0 is more numerous 
than 3.1 which is > 3.2.   

> Step 2: is your USB3 chipset from Etron or ASMedia? It won't
> work with those.

See following.

> Step 3: Does lsusb show the device?

peter@dalton:~$ lsusb -vs 005 | head
Couldn't open device, some information will be missing

Bus 003 Device 005: ID 1164:f533 YUAN High-Tech Development Co., Ltd 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.10
  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  
The full output is at http://easthope.ca/lsusb.vs5.txt .  UVC not 
mentioned.

> Step 4: Why do you think it's UVC compliant? 

Naive assumption that USB + video = UVC.

> I didn't see it in
> the manual, and discussion on the web mostly seems to be about
> how mediocre the thing is when it works, always on Windows
> systems. StarTech doesn't even mention Mac OS, and I think that
> they would do that if it were at all honest for them to claim
> support.

Management by committee.  I suggested the Startech USB32VGCAPRO which 
shows Mac support.  
https://www.startech.com/AV/Converters/Video/usb-3-capture-device-vga~USB32VGCAPRO

Staples doesn't sell that but lists the Startech USB3HDCAP.  Someone 
decided to substitute.  (This is the public sector. Throw money until 
something works or the administration loses interest.)

We should aim for an adapter claiming to support UVC and Linux.  
Two examples.
https://inogeni.com/product/vga-to-usb-3-0
https://www.epiphan.com/store/avio-hd/

(https://inogeni.com/product/hdmi-dvi-to-usb-3 can not convert 
analogue to digital. Therefore can not be used with a passive VGA to 
DVI adapter.)

USB in a disused Mac might work. For a PC with Debian buy the USB 
adapter sold or recommended by the vendor of the converter.

Additional tips always welcome.

Thanks,   ... P.

-- 
https://en.wikibooks.org/wiki/Medical_Machines
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Re: Semi-OT: IPP doesn't auto-configure CUPS?

[Gene Heskett]

On Monday 11 November 2019 15:17:26 Kent West wrote:

> On 11/11/19 2:02 PM, Kent West wrote:
> > What I mean more specifically is, when I go into the CUPS web
> > interface to set up a new printer, and go through the Add Printer
> > stuff, and select "Other Network Printers" / "Internet Printing
> > Protocol (ipps)" (because the printer is on a different
> > subnet/virtual LAN and therefore doesn't get autodetected via
> > Bonjour/mDNS/DNS-SD), and then on the next screen enter the IP
> > address of the printer, I would have expected the IPP protocol to
> > then handle the rest of the printer setup, but instead I'm still
> > asked for the printer name and printer model (although I just now
> > noticed that what is currently selected (I'm not sure it was when I
> > started this email) is "{current_make_and_model} - IPP Everywhere" -
> > perhaps this option is doing what I was expecting?).
> >
> > (If I select that IPP Everywhere option, the next screen errors out
> > saying "Unable to open PPD file: Missing asterisk in column 1", so I
> > suspect that option is not doing what I was expecting.)
>
> Then again, maybe it does. After that failure, I went back into
> printer management and found that a printer had been created, that
> appeared broken. So I deleted it, and just to be thorough, I repeated
> the process above, again (only this time choosing "Internet Printing
> Protocol (http)". This time I did not get the error reported above,
> and the printer list now shows what looks to be a properly-installed
> printer, with an auto-populated model number (so apparently two-way
> IPP communication is working).
>
> I did a test print which was successful.
>
> So then I deleted that printer, and again added the printer, this time
> going back to using "Internet Printer Protocol (ipps)", and again I
> got the failure error message. Apparently there IS a difference
> between these four protocols:
>
> Internet Printing Protocol (http)
>
> Internet Printing Protocol (https)
>
> Internet Printing Protocol (ipp)
>
> Internet Printing Protocol (ipps)
>
> even though "ls -l /usr/lib/cups/backend" all show them to all be or
> symlink to the same file. So I'm left with my original question from
> my earlier-today post/question: What's the difference between these
> four protocols, and why would I select one over the others?
>
excellent questions. But I be far more interested is setting a printer as 
shared, and actually being able share it.  When configured as shared, 
when the page clears back to the printer, its marked not shared and is 
refusing to allow other computers on my local net to use it.

Thanks for any help that fixes this.

> Thanks!


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: fail2ban for apache2

[Cindy Sue Causey]

On 11/11/19, Greg Wooledge  wrote:
> On Mon, Nov 11, 2019 at 12:18:17PM -0500, Gene Heskett wrote:
>>
>> HTTP/1.1" 200 554724 "-" "Mozilla/5.0 (compatible; Daum/4.1;
>> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
>> coyote.coyote.den:80 203.133.169.54 - -
>> [11/Nov/2019:12:11:29 -0500] "GET
>> /gene/nitros9/level1/dalpha/modules/defsfile
>> HTTP/1.1" 200 248 "-" "Mozilla/5.0 (compatible; Daum/4.1;
>> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
>> coyote.coyote.den:80 203.133.169.54 - -
>> [11/Nov/2019:12:11:34 -0500] "GET
>> /gene/nitros9/level1/atari/modules/n1_scdwv.dd
>> HTTP/1.1" 200 280 "-" "Mozilla/5.0 (compatible; Daum/4.1;
>> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
>> coyote.coyote.den:80 203.133.169.54 - -
>> [11/Nov/2019:12:11:39 -0500] "GET
>> /gene/nitros9/level1/coco1_6309/bootfiles/bootfile_covga_cocosdc
>> HTTP/1.1" 200 16133 "-" "Mozilla/5.0 (compatible; Daum/4.1;
>> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
>>
>> I did ask earlier if daum was a bot but no one answered.  They are
>> becoming a mite pesky.
>
> Well, maybe nobody knows.
>
> I went to daum.net in a web browser, and it looks like it's in an Asian
> language.  It also looks like it's selling a bunch of stuff (at least,
> it's laid out the way a retailer's web page is typically laid out).
>
> I also went to the URL in your log
> .  Again, it's in a
> language that I can't read, but it's talking about robots.txt and shows
> an example of how to block them.
>
> So, yes, it's a bot.
>
> Did you not try either of these steps yourself?


I tried what I do when I get stuff like this: A search engine using
either "s-p-a-m" or abuse along with the site in question.

This "cs-daum" one pulls up talking a lot about being some kind of
mail server, too. That take was garnered yet again via the search
results without actually visiting any websites. That didn't make much
sense with respect to the complaint, other than it's something that a
well-rounded website might be offering.

If I'm real sure something's foul, I'll go straight for searching with
e.g. "Spamhaus" as an accompanying keyword. As an afterthought, I did
just that, too, and received the following:

"This is a confirmed bad bot but isn't blocked yet by the blocker:"

Credit without visiting the website appears to go to Github account
"mariusv" that is tracking issues for "nginx-badbot-blocker". That may
change if one actually visits the website. I'm not able to just this
second..

I'm glad I did the more generic search first. Mail didn't get much of
a mention when Spamhaus was used instead. Something called "hanmail"
that may or may not be related got a few "loud" head nods in my first
search but was much more buried in the second one.

Am donning a conspiracy hat now because of all the chatter about
machinery on regular occasion.

After a few seconds of contemplation, it comes to mind to wonder out
loud: Are they hitting it hard...

* Just because they can?

* Or because it appears to them that there may be steal-worthy
information they could turn around and patent or otherwise profit from
somehow?

The "espionage" angle is becoming ridiculous out there. Just saw
something in my inbox yesterday about the military going after a
product source or contractor that sold them "Made in the USA" products
that were instead made elsewhere.

Regular users discovered the fraud when foreign language characters
instead of en-US appeared on the screen that was monitoring military
folks wearing on-body cameras...

Not joking/exaggerating when I say I'm really starting to wonder about
ANY products we buy right now. It's at the top of my own list of
concerns because of all that sudden, simultaneous crash-and-burn of my
software and multiple pieces of hardware a few weeks ago.

Things were working just fine until I bought a couple various new,
small add-ons, e.g. a dual bay hard drive docking station and a couple
of 64GB [thumb drives].

Even those inexpensive, nay, CHEAP wifi dongles.. I mentioned I bought
3 of those myself a few months back...

Who knows

And how the doodles is the average user supposed to sanity/safety
check every single piece of computer-based, possibly chip containing
hardware from now on. The implication is that one computer compromised
internally that way is most likely networked with a whole bunch of
others in the meantime, too.

AND.. I don't think how we obtain these items affects any perceived
risk in the future. Something from a big box store can be just as
easily compromised as single items we may buy from "online
marketplaces"

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: armhf version of bzip2 is broken

[Gene Heskett]

On Monday 11 November 2019 15:17:20 Reco wrote:

>   Hi.
>
> On Mon, Nov 11, 2019 at 09:11:40PM +0100, Sven Joachim wrote:
> > On 2019-11-11 22:22 +0300, Reco wrote:
> > > Confirming, real debian armhf is affected. The problematic place
> > > is:
> > >
> > > $ strace -eopenat bzip2 -z 4038000640
> > > ...
> > > openat(AT_FDCWD, "4038000640", O_RDONLY) = -1 EOVERFLOW (Value too
> > > large for defined data type)
> > >
> > >
> > > And EOVERFLOW in openat(2) is:
> > >
> > > pathname refers to a regular file that is too large to be opened. 
> > > The usual scenario here is that an application compiled on a
> > > 32-bit platform without -D_FILE_OFFSET_BITS=64 tried to open  a 
> > > file  whose  size exceeds (1<<31)-1 bytes; see also O_LARGEFILE
> > > above.  This is the error specified by POSIX.1; in kernels before
> > > 2.6.24, Linux gave the error EFBIG for this case.
> > >
> > >
> > > So, yep, you've found a bug in Debian packaging, consider filling
> > > it via proper channels.
> >
> > Since I could reproduce the problem on i386, I have already done
> > that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557.
>
> Appreciate the effort, I'll subscribe to the bug.
>
> Reco

So have I as I'm curious to see how this works.

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 

emmc not recognised from kernel 4.19

[james poulsen]

Hi, I have done a lot of testing on my Lenovo S130-11IGM and discovered the 
internal primary disk (which is an emmc disk) is not recognised correctly. I 
can boot from Lubuntu 18.04 which uses the 4.15 kernel. It looks like something 
has changed from 4.19. The ubuntu bug folks suggested running tests on Debian 
to see when the kernel stopped functioning with this hardware. I can get any 
detailed info but not sure how to file the bug. I can boot from a live image 
but obviously cannot install. I'm going to test stretch and see if things are 
working. The bug reported with ubuntu is here;  
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848883

Re: Requisitos del sistema

[Paynalton]

Si un ave no rompe su huevo morirá antes de nacer.
Nosotros somos el ave y el mundo es nuestro huevo.
POR LA REVOLUCIÓN DEL MUNDO

Ciudad de México


El lun., 11 nov. 2019 a las 14:18, mauro botella rabanal (<
mauro24011...@gmail.com>) escribió:

> Queria saber los requisitos del sistema necesarios para instalar debian
>

Son estos:

https://www.debian.org/releases/jessie/mips/ch03s04.html.en

TL;DL

Ram: 128MB
HD: 500MB

En cuanto a procesadores es muy variado, revisa este documento:

https://www.debian.org/releases/stretch/i386/ch02s01.html.en

Obvio estos son requisitos mínimos, dependerá más de los programas y
servicios que desees ejecutar que del sistema operativo.

loading shared objects

[Lev]

Dear list,


Maybe it is a bit off topic, but I encountered a dynamic linking problem on my 
Debian stable system.

A program (KiCad) tries (and fails) to load a library (libngspice.so.0.0.0).

I set LD_DEBUG=libs, and I get this:

[...]
  7390: find library=libngspice.so.0 [0]; searching
  7390:  search cache=/etc/ld.so.cache
  7390:   trying file=/usr/local/lib/libngspice.so.0
  7390: 
  7390: find library=libfftw3.so.3 [0]; searching
  7390:  search cache=/etc/ld.so.cache
  7390:   trying file=/usr/lib/x86_64-linux-gnu/libfftw3.so.3
  7390: 
  7390: 
  7390: calling init: /usr/lib/x86_64-linux-gnu/libfftw3.so.3
  7390: 
  7390: 
  7390: calling init: /usr/local/lib/libngspice.so.0
  7390: 
  7390: 
  7390: calling init: /usr/local/bin/_eeschema.kiface
  7390: 
  7390: find library=libngspice.so.0.0.0 [0]; searching
  7390:  search cache=/etc/ld.so.cache
  7390:  search 
path=/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64/x86_64:/lib/tls/x86_64:/lib/tls/x86_64:/lib/tls:/lib/x86_64/x86_64:/lib/x86_64:/lib/x86_64:/lib:/usr/lib/tls/x86_64/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64/x86_64:/usr/lib/x86_64:/usr/lib/x86_64:/usr/lib
(system search path)
  7390:   trying 
file=/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libngspice.so.0.0.0
  7390:   trying 
file=/lib/x86_64-linux-gnu/tls/x86_64/libngspice.so.0.0.0
  7390:   trying 
file=/lib/x86_64-linux-gnu/tls/x86_64/libngspice.so.0.0.0
  7390:   trying file=/lib/x86_64-linux-gnu/tls/libngspice.so.0.0.0
  7390:   trying 
file=/lib/x86_64-linux-gnu/x86_64/x86_64/libngspice.so.0.0.0
  7390:   trying file=/lib/x86_64-linux-gnu/x86_64/libngspice.so.0.0.0
  7390:   trying file=/lib/x86_64-linux-gnu/x86_64/libngspice.so.0.0.0
  7390:   trying file=/lib/x86_64-linux-gnu/libngspice.so.0.0.0
  7390:   trying 
file=/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libngspice.so.0.0.0
  7390:   trying 
file=/usr/lib/x86_64-linux-gnu/tls/x86_64/libngspice.so.0.0.0
  7390:   trying 
file=/usr/lib/x86_64-linux-gnu/tls/x86_64/libngspice.so.0.0.0
  7390:   trying file=/usr/lib/x86_64-linux-gnu/tls/libngspice.so.0.0.0
  7390:   trying 
file=/usr/lib/x86_64-linux-gnu/x86_64/x86_64/libngspice.so.0.0.0
  7390:   trying 
file=/usr/lib/x86_64-linux-gnu/x86_64/libngspice.so.0.0.0
  7390:   trying 
file=/usr/lib/x86_64-linux-gnu/x86_64/libngspice.so.0.0.0
  7390:   trying file=/usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0
  7390:   trying file=/lib/tls/x86_64/x86_64/libngspice.so.0.0.0
  7390:   trying file=/lib/tls/x86_64/libngspice.so.0.0.0
  7390:   trying file=/lib/tls/x86_64/libngspice.so.0.0.0
  7390:   trying file=/lib/tls/libngspice.so.0.0.0
  7390:   trying file=/lib/x86_64/x86_64/libngspice.so.0.0.0
  7390:   trying file=/lib/x86_64/libngspice.so.0.0.0
  7390:   trying file=/lib/x86_64/libngspice.so.0.0.0
  7390:   trying file=/lib/libngspice.so.0.0.0
  7390:   trying file=/usr/lib/tls/x86_64/x86_64/libngspice.so.0.0.0
  7390:   trying file=/usr/lib/tls/x86_64/libngspice.so.0.0.0
  7390:   trying file=/usr/lib/tls/x86_64/libngspice.so.0.0.0
  7390:   trying file=/usr/lib/tls/libngspice.so.0.0.0
  7390:   trying file=/usr/lib/x86_64/x86_64/libngspice.so.0.0.0
  7390:   trying file=/usr/lib/x86_64/libngspice.so.0.0.0
  7390:   trying file=/usr/lib/x86_64/libngspice.so.0.0.0
  7390:   trying file=/usr/lib/libngspice.so.0.0.0
  7390:


I have this in my /etc/ld.so.conf.d/libc.conf:

/usr/local/lib


so it shall find the library. But this is interesting that in the above log, 
/usr/local/lib is missing. I run ldconfig several times. I also greped 
ld.so.cache, and there is the library there.

Can you explain me what is going on here?


Thanks,
Levente

-- 
Levente Kovacs
Senior Electronic Engineer

W: http://levente.logonex.eu

Re: Difference between ipp, ipps, http, https CUPS protocols?

[Kent West]

On 11/11/19 1:44 PM, Kent West wrote:



On 11/11/19 1:38 PM, Kent West wrote:


On 11/11/19 10:40 AM, Brian wrote:

On Mon 11 Nov 2019 at 10:18:26 -0600, Kent West wrote:


When adding a printer via the CUPS web interface (localhost:631) on my
Debian box, Administration / Add Printer / Other Network Printers, 
there are

four Internet Printing Protocol options:

https

ipp

http

ipps

Which one do I want to select? What are the differences?

'ls -l /usr/lib/cups/backend' tells you that it doesn't matter what
choice you make.



lrwxrwxrwx 1 root root  3 Oct 31 02:44 http -> ipp
lrwxrwxrwx 1 root root  3 Oct 31 02:44 https -> ipp
-rwxr-xr-x 1 root root  80120 Oct 31 02:44 ipp
lrwxrwxrwx 1 root root  3 Oct 31 02:44 ipps -> ipp

Thank you. That does tell me they are all the same. It does not tell 
me why CUPS on Debian makes the other three options available 
(thereby confusing the person adding the printer). There must be some 
reason why a person would expect to choose X over Y; that's the 
difference I'm looking for.




After some testing, I find that selecting "http" creates a working 
printer; selecting "ipps" does not. The latter generates an error page 
that says:


Unable to open PPD file:

   Missing asterisk in column 1


So apparently there is some difference between these protocols, and I'm 
left wondering what the differences are, and which one I should select.


--

Kent

Requisitos del sistema

[mauro botella rabanal]

Queria saber los requisitos del sistema necesarios para instalar debian

Re: Semi-OT: IPP doesn't auto-configure CUPS?

[Kent West]

On 11/11/19 2:02 PM, Kent West wrote:
What I mean more specifically is, when I go into the CUPS web 
interface to set up a new printer, and go through the Add Printer 
stuff, and select "Other Network Printers" / "Internet Printing 
Protocol (ipps)" (because the printer is on a different subnet/virtual 
LAN and therefore doesn't get autodetected via Bonjour/mDNS/DNS-SD), 
and then on the next screen enter the IP address of the printer, I 
would have expected the IPP protocol to then handle the rest of the 
printer setup, but instead I'm still asked for the printer name and 
printer model (although I just now noticed that what is currently 
selected (I'm not sure it was when I started this email) is 
"{current_make_and_model} - IPP Everywhere" - perhaps this option is 
doing what I was expecting?).


(If I select that IPP Everywhere option, the next screen errors out 
saying "Unable to open PPD file: Missing asterisk in column 1", so I 
suspect that option is not doing what I was expecting.)



Then again, maybe it does. After that failure, I went back into printer 
management and found that a printer had been created, that appeared 
broken. So I deleted it, and just to be thorough, I repeated the process 
above, again (only this time choosing "Internet Printing Protocol 
(http)". This time I did not get the error reported above, and the 
printer list now shows what looks to be a properly-installed printer, 
with an auto-populated model number (so apparently two-way IPP 
communication is working).


I did a test print which was successful.

So then I deleted that printer, and again added the printer, this time 
going back to using "Internet Printer Protocol (ipps)", and again I got 
the failure error message. Apparently there IS a difference between 
these four protocols:


Internet Printing Protocol (http)

Internet Printing Protocol (https)

Internet Printing Protocol (ipp)

Internet Printing Protocol (ipps)

even though "ls -l /usr/lib/cups/backend" all show them to all be or 
symlink to the same file. So I'm left with my original question from my 
earlier-today post/question: What's the difference between these four 
protocols, and why would I select one over the others?


Thanks!

--

Kent

Re: armhf version of bzip2 is broken

[Reco]

Hi.

On Mon, Nov 11, 2019 at 09:11:40PM +0100, Sven Joachim wrote:
> On 2019-11-11 22:22 +0300, Reco wrote:
> 
> > Confirming, real debian armhf is affected. The problematic place is:
> >
> > $ strace -eopenat bzip2 -z 4038000640
> > ...
> > openat(AT_FDCWD, "4038000640", O_RDONLY) = -1 EOVERFLOW (Value too large 
> > for defined data type)
> >
> >
> > And EOVERFLOW in openat(2) is:
> >
> > pathname refers to a regular file that is too large to be opened.  The
> > usual scenario here is that an application compiled on a 32-bit platform
> > without -D_FILE_OFFSET_BITS=64 tried to open  a  file  whose  size
> > exceeds (1<<31)-1 bytes; see also O_LARGEFILE above.  This is the
> > error specified by POSIX.1; in kernels before 2.6.24, Linux gave the
> > error EFBIG for this case.
> >
> >
> > So, yep, you've found a bug in Debian packaging, consider filling it via
> > proper channels.
> 
> Since I could reproduce the problem on i386, I have already done that:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557.

Appreciate the effort, I'll subscribe to the bug.

Reco

Re: armhf version of bzip2 is broken

[Sven Joachim]

On 2019-11-11 22:22 +0300, Reco wrote:

> Confirming, real debian armhf is affected. The problematic place is:
>
> $ strace -eopenat bzip2 -z 4038000640
> ...
> openat(AT_FDCWD, "4038000640", O_RDONLY) = -1 EOVERFLOW (Value too large for 
> defined data type)
>
>
> And EOVERFLOW in openat(2) is:
>
> pathname refers to a regular file that is too large to be opened.  The
> usual scenario here is that an application compiled on a 32-bit platform
> without -D_FILE_OFFSET_BITS=64 tried to open  a  file  whose  size
> exceeds (1<<31)-1 bytes; see also O_LARGEFILE above.  This is the
> error specified by POSIX.1; in kernels before 2.6.24, Linux gave the
> error EFBIG for this case.
>
>
> So, yep, you've found a bug in Debian packaging, consider filling it via
> proper channels.

Since I could reproduce the problem on i386, I have already done that:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557.

I think it would be reasonable to fix this bug in a buster point
release, but that is in the package maintainer's discretion.

Cheers,
   Sven

Re: Difference between ipp, ipps, http, https CUPS protocols?

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Kent West wrote:
> Probably answered somewhere, but I've been DuckDuckGo-ing for the past 
> two hours and can't find the answer.
>
> When adding a printer via the CUPS web interface (localhost:631) on my 
> Debian box, Administration / Add Printer / Other Network Printers, there 
> are four Internet Printing Protocol options:
>
> https
>
> ipp
>
> http
>
> ipps
>
> Which one do I want to select? What are the differences?

Whichever your printer supports (consult your manual).  Most would
probably go with ipp (or ipps, if you wanted TLS) these days.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl3JvvQACgkQjhHd8xJ5
ooGVEQgAps4FwbuvD/Q/sqIZ8BmIWeW6TRrSG5DXXokB8xVCzxWRfLSkS9pWuUrm
KiVWwYg1AG76s91EWkDtoBF22pE0QgMBjdcbfOo/Ojm/kcYDlYjFh48tjf1jFtve
kEWgBs5D11eZ9onxPHs/jZOzt4NGTdYbu7p44y/4M+4sAK3lT+rSYPGEUrMMu4Ob
TcxVRQOCucOGy5sN8LMdc76Sh/tqy8Y4FeVVqx/nP3cuH8uO3cG2rJkCmCI8rH6G
uWFwjDgFGmG9sbcU/YIy3006leFVJpWhptSLteLboMQq0/IR6HJEmsCBBjcBeU+R
WSOeGlLigQ9EpgsA/qLDfdG/J84cLQ==
=HNw3
-END PGP SIGNATURE-

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: armhf version of bzip2 is broken

[Gene Heskett]

On Monday 11 November 2019 14:22:59 Reco wrote:

>   Hi.
>
> On Mon, Nov 11, 2019 at 01:24:50PM -0500, Gene Heskett wrote:
> > On Monday 11 November 2019 12:34:08 Greg Wooledge wrote:
> > > On Mon, Nov 11, 2019 at 12:08:15PM -0500, Gene Heskett wrote:
> > > > And its man page says its a 2010 version. And it won't touch a
> > > > just over 4G built kernel tarball.
> > > >
> > > > Suggestions?
> > >
> > > 0) Give all the background details of your setup, like what
> > > version of Debian you're running, what hardware, what version of
> > > bzip2 is installed, where you got this input file
> >
> > Not debian since your arm is now arm64 from buster on.
>
> Your inability to locate armhf in Debian's main archive is well-known
> to debian-arm denizens, but please refrain from spreading your
> hopefully honest errors here.

I've made 2 passes at a netinstall of buster on that rpi4, once with 10.0 
and once with 10.1. both installs worked, both installs yielded an arm64 
install. Installing the amanda clients so I could make backups, crashed 
them without a clue in the logs nominally 4 seconds after the server 
touched them at backup time.

> > The problem is that a built kernel is 4038000640 byte when converted
> > to a tarball, but the best compressor is a 2010 version of bzip2 and
> > it has an instant tummy ache with that big a file:
> >
> > pi@rpi4:/media/pi/slash $ bzip2 -z 4.19.71-rt24-v7l+.tar
> > bzip2: Can't open input file 4.19.71-rt24-v7l+.tar: Value too large
> > for defined data type.
>
> Confirming, real debian armhf is affected. The problematic place is:
>
> $ strace -eopenat bzip2 -z 4038000640
> ...
> openat(AT_FDCWD, "4038000640", O_RDONLY) = -1 EOVERFLOW (Value too
> large for defined data type)
>
>
> And EOVERFLOW in openat(2) is:
>
> pathname refers to a regular file that is too large to be opened.  The
> usual scenario here is that an application compiled on a 32-bit
> platform without -D_FILE_OFFSET_BITS=64 tried to open  a  file  whose 
> size exceeds (1<<31)-1 bytes; see also O_LARGEFILE above.  This is the
> error specified by POSIX.1; in kernels before 2.6.24, Linux gave the
> error EFBIG for this case.
>
>
> So, yep, you've found a bug in Debian packaging, consider filling it
> via proper channels.
>

I've not succeeded in wadeing thru that to file a bug yet Reco. Probably 
my fault but somebody has always had to clean up the mess.
>
> EOVERFLOW is a known beast, working workarounds are:
>
> 1) "busybox bzip2" instead of "bzip2 -z" (-z is kind of redundant
> anyway).
>
> 2) cat foo | bzip2 -c > foo.bz2
>
or "bzip2 -c outputfile.tar.bz2"  redirections 

> > The realtime is totally moot IMO,
>
> True, one has to build a binary a certain way.
>
> > the size of slightly over 4Gigs is the real problem
>
> First, it's *under* 4Gb (assuming right and proper 1024=1Kb):
>
> $ echo 4038000640/1024/1024/1024 | bc -l
> 3.76068115234375
>
> Second, it's actually 2Gb-1 that's problematic.
>
> Reco

That level of detail will probably escape from  my ancient wet ram by 
tommorrow, Reco. But I have rx'd a recipe that works, so all is not 
lost. I should have it done and moved to the download space in an hour 
or a bit more.

Thank you.

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 

Semi-OT: IPP doesn't auto-configure CUPS?

[Kent West]

I've been trying to wrap my head around printing today, and I have come 
to understand that IPP is the up-and-coming standard for printing 
(replacing the older LPD / AppSocket / HP Jet Direct / etc), and more 
specifically, that IPPEverywhere is the new and up-and-coming standard 
(of which Apple's AirPrint is a variant/extension, more 
broadly-supported simply by being older, although not fully documented 
as is the newer IPPEverywhere).


It is further my understanding that IPP is supposed to query the printer 
for its capabilities (double-sided printing? stapling? A4 paper size in 
the tray, etc).


It is further my understanding that IPP can (does?) query the printer 
for this info just prior to each print job.


But I also thought that IPP would query the printer for this info when 
the printer is added to the client PC. I find that to not be the case, 
however, on my Debian Bullseye/sid box, and on a Mac Catalina MacBook. 
Am I incorrect about this setup-time polling?


What I mean more specifically is, when I go into the CUPS web interface 
to set up a new printer, and go through the Add Printer stuff, and 
select "Other Network Printers" / "Internet Printing Protocol (ipps)" 
(because the printer is on a different subnet/virtual LAN and therefore 
doesn't get autodetected via Bonjour/mDNS/DNS-SD), and then on the next 
screen enter the IP address of the printer, I would have expected the 
IPP protocol to then handle the rest of the printer setup, but instead 
I'm still asked for the printer name and printer model (although I just 
now noticed that what is currently selected (I'm not sure it was when I 
started this email) is "{current_make_and_model} - IPP Everywhere" - 
perhaps this option is doing what I was expecting?).


(If I select that IPP Everywhere option, the next screen errors out 
saying "Unable to open PPD file: Missing asterisk in column 1", so I 
suspect that option is not doing what I was expecting.)


Any info to help me understand better the process would be appreciated. 
Thanks!


--

Kent

Re: Difference between ipp, ipps, http, https CUPS protocols?

[Klaus Singvogel]

Kent West wrote:
> 
> lrwxrwxrwx 1 root root  3 Oct 31 02:44 http -> ipp
> lrwxrwxrwx 1 root root  3 Oct 31 02:44 https -> ipp
> -rwxr-xr-x 1 root root  80120 Oct 31 02:44 ipp
> lrwxrwxrwx 1 root root  3 Oct 31 02:44 ipps -> ipp
> 
> Thank you. That does tell me they are all the same. It does not tell me why
> CUPS on Debian makes the other three options available (thereby confusing
> the person adding the printer). There must be some reason why a person would
> expect to choose X over Y; that's the difference I'm looking for.

Not exactly.

Depending on argv[0] (under which name program is started) the program
might work different.

Common practice, if protocols are similiar and only slightly different.

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: UVC device.

[peter]

From: Dan Ritter
Date: Sat, 9 Nov 2019 08:03:35 -0500
> Step 1: are you using a USB3 port? It says it will not work in a
> USB2 port.

Missed that.  

None of the local shops in Vancouver has a USB 3 adapter card in 
stock.  Amazon and etc. offer them of course.  3.0 is more numerous 
than 3.1 which is > 3.2.   

> Step 2: is your USB3 chipset from Etron or ASMedia? It won't
> work with those.

See following.

> Step 3: Does lsusb show the device?

peter@dalton:~$ lsusb -vs 005 | head
Couldn't open device, some information will be missing

Bus 003 Device 005: ID 1164:f533 YUAN High-Tech Development Co., Ltd 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.10
  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  
The full output is at http://easthope.ca/lsusb.vs5.txt .  UVC not 
mentioned.

> Step 4: Why do you think it's UVC compliant? 

Naive assumption that USB + video = UVC.

> I didn't see it in
> the manual, and discussion on the web mostly seems to be about
> how mediocre the thing is when it works, always on Windows
> systems. StarTech doesn't even mention Mac OS, and I think that
> they would do that if it were at all honest for them to claim
> support.

Management by committee.  I suggested the Startech USB32VGCAPRO which 
shows Mac support.  
https://www.startech.com/AV/Converters/Video/usb-3-capture-device-vga~USB32VGCAPRO

Staples doesn't sell that but lists the Startech USB3HDCAP.  Someone 
decided to substitute.  (This is the public sector. Throw money until 
something works or the administration loses interest.)

We should aim for an adapter claiming to support UVC and Linux.  
Two examples.
https://inogeni.com/product/vga-to-usb-3-0
https://www.epiphan.com/store/avio-hd/

(https://inogeni.com/product/hdmi-dvi-to-usb-3 can not convert 
analogue to digital. Therefore can not be used with a passive VGA to 
DVI adapter.)

USB in a disused Mac might work. For a PC with Debian buy the USB 
adapter sold or recommended by the vendor of the converter.

Additional tips always welcome.

Thanks,   ... P.


-- 
https://en.wikibooks.org/wiki/Medical_Machines
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Re: fail2ban for apache2

[Frank McCormick]

Sorry Gene. Hit reply instead of reply list.

On 11/11/19 12:18 PM, Gene Heskett wrote:

On Monday 11 November 2019 08:33:13 Greg Wooledge wrote:


I have a list of ipv4's I want fail2ban to block.


Not sure that fail2ban is the best tool for the job. Where you
already have a list of IPs that you want to block why not just
directly create the iptables rules?


just did that, got most of them but semrush apparently has fallback
addys to use.  But I'm no longer being DDOSed, which was the point.
Thanks.


In case it wasn't already clear, what fail2ban does is parse a log
file looking for repeated instances of an invalid login (or whatever).
  You have to tell it what to look for, and what to do about it.





coyote.coyote.den:80 40.94.105.9 - -
[11/Nov/2019:12:08:53 -0500] "GET /gene/ HTTP/1.1" 200
5141 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36"
coyote.coyote.den:80 40.94.105.9 - -
[11/Nov/2019:12:08:53 -0500] "GET /gene/pix/EasterSundayCropped2004-1.jpg
HTTP/1.1" 200 194478 "http://geneslinuxbox.net:6309/gene/; "Mozilla/5.0
(Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/57.0.2987.133 Safari/537.36"
coyote.coyote.den:80 40.94.105.9 - -
[11/Nov/2019:12:08:56 -0500] "GET /favicon.ico HTTP/1.1" 200
1705 "http://geneslinuxbox.net:6309/gene/; "Mozilla/5.0 (Windows NT
10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/57.0.2987.133 Safari/537.36"
coyote.coyote.den:80 203.133.169.54 - -
[11/Nov/2019:12:10:52 -0500] "GET /robots.txt HTTP/1.1" 200
1092 "-" "Mozilla/5.0 (compatible; Daum/4.1;
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - -
[11/Nov/2019:12:10:53 -0500] "GET /gene/nitros9/level1/d64/modules/sysgo_h0
HTTP/1.1" 200 706 "-" "Mozilla/5.0 (compatible; Daum/4.1;
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - -
[11/Nov/2019:12:10:58 -0500] "GET 
/gene/nitros9/level1/coco2b/NOS9_6809_L1_coco2b_cocosdc.dsk
HTTP/1.1" 200 4718822 "-" "Mozilla/5.0 (compatible; Daum/4.1;
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - -
[11/Nov/2019:12:11:21 -0500] "GET 
/gene/nitros9/level1/coco2_6309/NOS9_6309_L1_coco2_6309_dw_directmodempak.dsk
HTTP/1.1" 200 554724 "-" "Mozilla/5.0 (compatible; Daum/4.1;
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - -
[11/Nov/2019:12:11:29 -0500] "GET /gene/nitros9/level1/dalpha/modules/defsfile
HTTP/1.1" 200 248 "-" "Mozilla/5.0 (compatible; Daum/4.1;
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - -
[11/Nov/2019:12:11:34 -0500] "GET /gene/nitros9/level1/atari/modules/n1_scdwv.dd
HTTP/1.1" 200 280 "-" "Mozilla/5.0 (compatible; Daum/4.1;
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - -
[11/Nov/2019:12:11:39 -0500] "GET 
/gene/nitros9/level1/coco1_6309/bootfiles/bootfile_covga_cocosdc
HTTP/1.1" 200 16133 "-" "Mozilla/5.0 (compatible; Daum/4.1;
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"

I did ask earlier if daum was a bot but no one answered.  They are
becoming a mite pesky.



Here's your answer:

https://www.distilnetworks.com/bot-directory/bot/daum-4-1/





Thanks.

Cheers, Gene Heskett



--
Frank McCormick

Re: Difference between ipp, ipps, http, https CUPS protocols?

[Richard Hector]

On 12/11/19 8:38 AM, Kent West wrote:
> 
> On 11/11/19 10:40 AM, Brian wrote:
>> On Mon 11 Nov 2019 at 10:18:26 -0600, Kent West wrote:
>>
>>> Probably answered somewhere, but I've been DuckDuckGo-ing for the
>>> past two
>>> hours and can't find the answer.
>>>
>>> When adding a printer via the CUPS web interface (localhost:631) on my
>>> Debian box, Administration / Add Printer / Other Network Printers,
>>> there are
>>> four Internet Printing Protocol options:
>>>
>>> https
>>>
>>> ipp
>>>
>>> http
>>>
>>> ipps
>>>
>>> Which one do I want to select? What are the differences?
>> 'ls -l /usr/lib/cups/backend' tells you that it doesn't matter what
>> choice you make.
>>
> 
> lrwxrwxrwx 1 root root  3 Oct 31 02:44 http -> ipp
> lrwxrwxrwx 1 root root  3 Oct 31 02:44 https -> ipp
> -rwxr-xr-x 1 root root  80120 Oct 31 02:44 ipp
> lrwxrwxrwx 1 root root  3 Oct 31 02:44 ipps -> ipp
> 
> Thank you. That does tell me they are all the same.

It doesn't tell me that.

It tells me that they're all the same file, but an executable can find
out what name it was called with, and change its behaviour accordingly.
Busybox is an extreme example.

> It does not tell me
> why CUPS on Debian makes the other three options available (thereby
> confusing the person adding the printer). There must be some reason why
> a person would expect to choose X over Y; that's the difference I'm
> looking for.
> 
> But your answer certainly helps. I now know it doesn't matter which of
> these I select.

I would guess that the *s versions use TLS, but beyond that I don't
know. I'd agree with deloptes that it probably depends on what the
remote end can support.

Richard




signature.asc
Description: OpenPGP digital signature

Re: armhf version of bzip2 is broken

[Sven Joachim]

On 2019-11-11 20:00 +0100, Michael wrote:

> On Monday, November 11, 2019 7:24:50 PM CET, Gene Heskett wrote:
>> pi@rpi4:/media/pi/slash $ bzip2 -V
>> bzip2, a block-sorting file compressor.  Version 1.0.6, 6-Sept-2010.
>
> strange enough, i use the same bzip2 version on an rpi3 with raspbian
> and it works with a 4621074432 byte iso image...

It is probably not exactly the same version, the support for large files
seems to have been inadvertently dropped in buster.  I suppose you are
still using stretch on your rpi3?

Cheers,
   Sven

Re: Difference between ipp, ipps, http, https CUPS protocols?

[Kent West]

On 11/11/19 1:38 PM, Kent West wrote:


On 11/11/19 10:40 AM, Brian wrote:

On Mon 11 Nov 2019 at 10:18:26 -0600, Kent West wrote:


When adding a printer via the CUPS web interface (localhost:631) on my
Debian box, Administration / Add Printer / Other Network Printers, 
there are

four Internet Printing Protocol options:

https

ipp

http

ipps

Which one do I want to select? What are the differences?

'ls -l /usr/lib/cups/backend' tells you that it doesn't matter what
choice you make.



lrwxrwxrwx 1 root root  3 Oct 31 02:44 http -> ipp
lrwxrwxrwx 1 root root  3 Oct 31 02:44 https -> ipp
-rwxr-xr-x 1 root root  80120 Oct 31 02:44 ipp
lrwxrwxrwx 1 root root  3 Oct 31 02:44 ipps -> ipp

Thank you. That does tell me they are all the same. It does not tell 
me why CUPS on Debian makes the other three options available (thereby 
confusing the person adding the printer). There must be some reason 
why a person would expect to choose X over Y; that's the difference 
I'm looking for.



Okay, just learned why the CUPS web interface presents all four options; 
it's because it's just reading what's available in 
/usr/lib/cups/backend. When I did this:



cd /usr/lib/cups/backend

sudo ln -s ipp bub


I got this when I refreshed my CUPS web interface page:

Other Network Printers: Backend Error Handler
Internet Printing Protocol (https)
Internet Printing Protocol (ipp)
Internet Printing Protocol (http)
AppSocket/HP JetDirect
LPD/LPR Host or Printer
Internet Printing Protocol (ipps)
Internet Printing Protocol (bub)
Windows Printer via SAMBA

Re: armhf version of bzip2 is broken

[Gene Heskett]

On Monday 11 November 2019 14:00:51 Michael wrote:

> On Monday, November 11, 2019 7:24:50 PM CET, Gene Heskett wrote:
> > pi@rpi4:/media/pi/slash $ bzip2 -V
> > bzip2, a block-sorting file compressor.  Version 1.0.6, 6-Sept-2010.
>
> strange enough, i use the same bzip2 version on an rpi3 with raspbian
> and it works with a 4621074432 byte iso image...
>
> nevertheless, there are two things you can try (i didn't, so i cannot
> verify that it will work!):
>
> - read the bzip2 man page and try to compress it using pipes, e.g.
>
 bzip2 -c - /path/to/your/compressed/archive.tar.bz2

This seems to be working:

  bzip2 -c - <4.19.71-rt24-v7l+.tar >4.19.71-rt24-v7l+.tar.bz2

ls -l
-rw-r--r--  1 pi   pi   4038000640 Nov 11 10:05 4.19.71-rt24-v7l+.tar
-rw-r--r--  1 pi   pi780468224 Nov 11 14:33 4.19.71-rt24-v7l+.tar.bz2

No drama yet. Big grin though. ;-)

> or
> - read the tar man page and create the compressed tar archive in one
> step, e.g.
>
>   > tar cjf /path/to/your/compressed/archive.tar.bz2 
> >
> > Rather ancient for 2019 code.
>
> old does not mean bad or even outdated. some things just serve their
> purpose for a very long time w/o the need to change anything.
>
> greetings...

Thanks Michael. When this is done I'll move it to download space and 
await the next error report. But since this tarball is slightly bigger 
that the first tarball I made from that exact source, I'm assuming the 
error some miscue caused has been fixed. The tarball gives a good list 
for a tar tf.

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: Difference between ipp, ipps, http, https CUPS protocols?

[Kent West]

On 11/11/19 10:40 AM, Brian wrote:

On Mon 11 Nov 2019 at 10:18:26 -0600, Kent West wrote:


Probably answered somewhere, but I've been DuckDuckGo-ing for the past two
hours and can't find the answer.

When adding a printer via the CUPS web interface (localhost:631) on my
Debian box, Administration / Add Printer / Other Network Printers, there are
four Internet Printing Protocol options:

https

ipp

http

ipps

Which one do I want to select? What are the differences?

'ls -l /usr/lib/cups/backend' tells you that it doesn't matter what
choice you make.



lrwxrwxrwx 1 root root  3 Oct 31 02:44 http -> ipp
lrwxrwxrwx 1 root root  3 Oct 31 02:44 https -> ipp
-rwxr-xr-x 1 root root  80120 Oct 31 02:44 ipp
lrwxrwxrwx 1 root root  3 Oct 31 02:44 ipps -> ipp

Thank you. That does tell me they are all the same. It does not tell me 
why CUPS on Debian makes the other three options available (thereby 
confusing the person adding the printer). There must be some reason why 
a person would expect to choose X over Y; that's the difference I'm 
looking for.


But your answer certainly helps. I now know it doesn't matter which of 
these I select.


--

Kent

Re: Difference between ipp, ipps, http, https CUPS protocols?

[deloptes]

Brian wrote:

>> When adding a printer via the CUPS web interface (localhost:631) on my
>> Debian box, Administration / Add Printer / Other Network Printers, there
>> are four Internet Printing Protocol options:
>> 
>> https
>> 
>> ipp
>> 
>> http
>> 
>> ipps
>> 
>> Which one do I want to select? What are the differences?
> 
> 'ls -l /usr/lib/cups/backend' tells you that it doesn't matter what
> choice you make.

Hmm, I was thinking it depends on what protocol the printer can talk.

But if it is a network printer it might be supporting all of these.

Re: armhf version of bzip2 is broken

[Reco]

Hi.

On Mon, Nov 11, 2019 at 01:24:50PM -0500, Gene Heskett wrote:
> On Monday 11 November 2019 12:34:08 Greg Wooledge wrote:
> 
> > On Mon, Nov 11, 2019 at 12:08:15PM -0500, Gene Heskett wrote:
> > > And its man page says its a 2010 version. And it won't touch a just
> > > over 4G built kernel tarball.
> > >
> > > Suggestions?
> >
> > 0) Give all the background details of your setup, like what version of
> >Debian you're running, what hardware, what version of bzip2 is
> >installed, where you got this input file
> Not debian since your arm is now arm64 from buster on.

Your inability to locate armhf in Debian's main archive is well-known to
debian-arm denizens, but please refrain from spreading your hopefully
honest errors here.


> The problem is that a built kernel is 4038000640 byte when converted to a 
> tarball, but the best compressor is a 2010 version of bzip2 and it has 
> an instant tummy ache with that big a file:
> 
> pi@rpi4:/media/pi/slash $ bzip2 -z 4.19.71-rt24-v7l+.tar
> bzip2: Can't open input file 4.19.71-rt24-v7l+.tar: Value too large for 
> defined data type.

Confirming, real debian armhf is affected. The problematic place is:

$ strace -eopenat bzip2 -z 4038000640
...
openat(AT_FDCWD, "4038000640", O_RDONLY) = -1 EOVERFLOW (Value too large for 
defined data type)


And EOVERFLOW in openat(2) is:

pathname refers to a regular file that is too large to be opened.  The
usual scenario here is that an application compiled on a 32-bit platform
without -D_FILE_OFFSET_BITS=64 tried to open  a  file  whose  size
exceeds (1<<31)-1 bytes; see also O_LARGEFILE above.  This is the
error specified by POSIX.1; in kernels before 2.6.24, Linux gave the
error EFBIG for this case.


So, yep, you've found a bug in Debian packaging, consider filling it via
proper channels.


EOVERFLOW is a known beast, working workarounds are:

1) "busybox bzip2" instead of "bzip2 -z" (-z is kind of redundant anyway).

2) cat foo | bzip2 -c > foo.bz2


> The realtime is totally moot IMO,

True, one has to build a binary a certain way.

> the size of slightly over 4Gigs is the real problem

First, it's *under* 4Gb (assuming right and proper 1024=1Kb):

$ echo 4038000640/1024/1024/1024 | bc -l
3.76068115234375

Second, it's actually 2Gb-1 that's problematic.

Reco

Re: armhf version of bzip2 is broken

[Michael]

On Monday, November 11, 2019 7:24:50 PM CET, Gene Heskett wrote:

pi@rpi4:/media/pi/slash $ bzip2 -V
bzip2, a block-sorting file compressor.  Version 1.0.6, 6-Sept-2010.


strange enough, i use the same bzip2 version on an rpi3 with raspbian and 
it works with a 4621074432 byte iso image...


nevertheless, there are two things you can try (i didn't, so i cannot 
verify that it will work!):


- read the bzip2 man page and try to compress it using pipes, e.g.
 > bzip2 -c - 
/path/to/your/compressed/archive.tar.bz2


or
- read the tar man page and create the compressed tar archive in one step, 
e.g.

 > tar cjf /path/to/your/compressed/archive.tar.bz2 



Rather ancient for 2019 code.


old does not mean bad or even outdated. some things just serve their 
purpose for a very long time w/o the need to change anything.


greetings...

Re: Migration Stretch vers Buster : plus de mode graphique

[ajh-valmer]

> > J'ai migré de Stretch vers Buster.
> > Carte graphique Nvidia geforce proprio,
> > qui marchait parfaitement sous Stretch.
> > En rebootant, j'ai ce message d'erreur au début :
> > "Failed to start openIPMI driver init script".
> > (openIPMI est bien installé),
> > ainsi que linux-headers-4.19... et linux-image-4.19...

On Monday 11 November 2019 19:35:13 Daniel Huhardeaux wrote:
> Est ce un serveur ? As tu besoin de IPMI ? 
> En tous cas rien à voir avec ton problème.

> Connexion ssh possible ? Peux tu te connecter sur une console 
> (Ctrl+Alt+F1 à F6)

Comme je l'avais écrit :
> Si je lance X, l'écran devient noir, rien,
> plus de clavier, bloqué, seule solution : hard reboot.

Si je supprime /etc/X11/xorg.conf,
pas de mode graphique, mais je peux reprendre la main, 
clavier fonctionnel, plus de blocage total.

Re: Migration Stretch vers Buster : plus de mode graphique

[Daniel Huhardeaux]

Le 11/11/2019 à 19:24, ajh-valmer a écrit :

Bonsoir à tous,


Bonsoir



J'ai migré de Stretch vers Buster.
Carte graphique Nvidia geforce proprio,
qui marchait parfaitement sous Stretch.

En rebootant, j'ai ce message d'erreur au début :
"Failed to start openIPMI driver init script".
(openIPMI est bien installé),
ainsi que linux-headers-4.19... et linux-image-4.19...


Est ce un serveur ? As tu besoin de IPMI ? En tous cas rien à voir avec 
ton problème.




modprobe nvidia n'affiche pas d'erreur.

Si je lance X, l'écran devient noir, rien,
plus de clavier, bloqué, seule solution : hard reboot.


Connexion ssh possible ? Peux tu te connecter sur une console 
(Ctrl+Alt+F1 à F6)


--
Daniel

Re: fail2ban for apache2

[Gene Heskett]

On Monday 11 November 2019 12:38:09 Greg Wooledge wrote:

> On Mon, Nov 11, 2019 at 12:18:17PM -0500, Gene Heskett wrote:
> > Only one log file seems to have useful data, the "other..." file,
> > and I have posted several single lines here, but here's a  few more:
> >
> > coyote.coyote.den:80 40.94.105.9 - -
> > [11/Nov/2019:12:08:53 -0500] "GET /gene/ HTTP/1.1" 200
> > 5141 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
> > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133
> > Safari/537.36"
> > coyote.coyote.den:80 40.94.105.9 - -
> > [11/Nov/2019:12:08:53 -0500] "GET
> > /gene/pix/EasterSundayCropped2004-1.jpg HTTP/1.1" 200 194478
> > "http://geneslinuxbox.net:6309/gene/; "Mozilla/5.0 (Windows NT 10.0;
> > Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
> > Chrome/57.0.2987.133 Safari/537.36"
> > coyote.coyote.den:80 40.94.105.9 - -
> > [11/Nov/2019:12:08:56 -0500] "GET /favicon.ico HTTP/1.1" 200
> > 1705 "http://geneslinuxbox.net:6309/gene/; "Mozilla/5.0 (Windows NT
> > 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
> > Chrome/57.0.2987.133 Safari/537.36"
> > coyote.coyote.den:80 203.133.169.54 - -
> > [11/Nov/2019:12:10:52 -0500] "GET /robots.txt HTTP/1.1" 200
> > 1092 "-" "Mozilla/5.0 (compatible; Daum/4.1;
> > +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> > coyote.coyote.den:80 203.133.169.54 - -
> > [11/Nov/2019:12:10:53 -0500] "GET
> > /gene/nitros9/level1/d64/modules/sysgo_h0 HTTP/1.1" 200 706 "-"
> > "Mozilla/5.0 (compatible; Daum/4.1;
> > +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> > coyote.coyote.den:80 203.133.169.54 - -
> > [11/Nov/2019:12:10:58 -0500] "GET
> > /gene/nitros9/level1/coco2b/NOS9_6809_L1_coco2b_cocosdc.dsk
> > HTTP/1.1" 200 4718822 "-" "Mozilla/5.0 (compatible; Daum/4.1;
> > +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> > coyote.coyote.den:80 203.133.169.54 - -
> > [11/Nov/2019:12:11:21 -0500] "GET
> > /gene/nitros9/level1/coco2_6309/NOS9_6309_L1_coco2_6309_dw_directmod
> >empak.dsk HTTP/1.1" 200 554724 "-" "Mozilla/5.0 (compatible;
> > Daum/4.1; +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> > coyote.coyote.den:80 203.133.169.54 - -
> > [11/Nov/2019:12:11:29 -0500] "GET
> > /gene/nitros9/level1/dalpha/modules/defsfile HTTP/1.1" 200 248 "-"
> > "Mozilla/5.0 (compatible; Daum/4.1;
> > +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> > coyote.coyote.den:80 203.133.169.54 - -
> > [11/Nov/2019:12:11:34 -0500] "GET
> > /gene/nitros9/level1/atari/modules/n1_scdwv.dd HTTP/1.1" 200 280 "-"
> > "Mozilla/5.0 (compatible; Daum/4.1;
> > +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> > coyote.coyote.den:80 203.133.169.54 - -
> > [11/Nov/2019:12:11:39 -0500] "GET
> > /gene/nitros9/level1/coco1_6309/bootfiles/bootfile_covga_cocosdc
> > HTTP/1.1" 200 16133 "-" "Mozilla/5.0 (compatible; Daum/4.1;
> > +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> >
> > I did ask earlier if daum was a bot but no one answered.  They are
> > becoming a mite pesky.
>
> Well, maybe nobody knows.
>
> I went to daum.net in a web browser, and it looks like it's in an
> Asian language.  It also looks like it's selling a bunch of stuff (at
> least, it's laid out the way a retailer's web page is typically laid
> out).
>
> I also went to the URL in your log
> .  Again, it's in a
> language that I can't read, but it's talking about robots.txt and
> shows an example of how to block them.
>
> So, yes, it's a bot.
>
> Did you not try either of these steps yourself?

I've at least 2 dozen robots.txt, with every known recipe scattered about 
including the one they read, and then ignored.  That leaves iptables...  
Its working and after several weeks I have some upload bandwidth left.

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: armhf version of bzip2 is broken

[Gene Heskett]

On Monday 11 November 2019 12:34:08 Greg Wooledge wrote:

> On Mon, Nov 11, 2019 at 12:08:15PM -0500, Gene Heskett wrote:
> > And its man page says its a 2010 version. And it won't touch a just
> > over 4G built kernel tarball.
> >
> > Suggestions?
>
> 0) Give all the background details of your setup, like what version of
>Debian you're running, what hardware, what version of bzip2 is
>installed, where you got this input file
Not debian since your arm is now arm64 from buster on.  But for realtime 
kernels, armhf from raspbian isn't arm64 but armhf. has a smaller stack 
frame and better latency's can be achieved for programs needing a 
realtime kernel. Linuxcnc is such a program.

The problem is that a built kernel is 4038000640 byte when converted to a 
tarball, but the best compressor is a 2010 version of bzip2 and it has 
an instant tummy ache with that big a file:

pi@rpi4:/media/pi/slash $ bzip2 -z 4.19.71-rt24-v7l+.tar
bzip2: Can't open input file 4.19.71-rt24-v7l+.tar: Value too large for 
defined data type.

> 1) Show the command you are running.

See the copy/paste from the rpi4's screen above.

> 2) Show the error message it produces.

See above. Do we have another compressor that will work? And gzip won't, 
it produces unrecoverable garbage from the above file, which lists just 
fine with a tar tf command.

pi@rpi4:/media/pi/slash $ bzip2 -V
bzip2, a block-sorting file compressor.  Version 1.0.6, 6-Sept-2010.

Rather ancient for 2019 code.

> 3) File a bug report.  Which will involve:

>a) Giving all the background details of your setup, like what
> version of Debian you're using, what hardware, what version of bzip2
> is installed, where you got the input file
>b) Showing the command you are running.
>c) Showing the error message it produces.

But since you'll ignore it since its (bzip2) not directly sourced from 
debian, I'll take  it to the raspbian forum, where since it involves a 
realtime kernel they also will ignore it.  The realtime is totally moot 
IMO, the size of slightly over 4Gigs is the real problem

Theres a sig floating around, that says all progress is caused/created by 
the unreasonable man. I guess I am that man.

So where then, do I find answers/help with problems such as this?  I have 
built linuxcnc to run on an rpi4, running a 1500 lb, 70 yo Sheldon lathe 
I've put good screws in and motors to turn those screws. Now I'd like to 
distribute that code so that others may also benefit.

Thanks Greg

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 

Migration Stretch vers Buster : plus de mode graphique

[ajh-valmer]

Bonsoir à tous,

J'ai migré de Stretch vers Buster.
Carte graphique Nvidia geforce proprio,
qui marchait parfaitement sous Stretch.

En rebootant, j'ai ce message d'erreur au début :
"Failed to start openIPMI driver init script".
(openIPMI est bien installé),
ainsi que linux-headers-4.19... et linux-image-4.19...

modprobe nvidia n'affiche pas d'erreur.

Si je lance X, l'écran devient noir, rien,
plus de clavier, bloqué, seule solution : hard reboot.

Merci d'une aide, une piste.

Bonne soirée,

A. Valmer

Re: fail2ban for apache2

[Greg Wooledge]

On Mon, Nov 11, 2019 at 12:18:17PM -0500, Gene Heskett wrote:
> Only one log file seems to have useful data, the "other..." file, and I 
> have posted several single lines here, but here's a  few more:
> 
> coyote.coyote.den:80 40.94.105.9 - - 
> [11/Nov/2019:12:08:53 -0500] "GET /gene/ HTTP/1.1" 200 
> 5141 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36"
> coyote.coyote.den:80 40.94.105.9 - - 
> [11/Nov/2019:12:08:53 -0500] "GET /gene/pix/EasterSundayCropped2004-1.jpg 
> HTTP/1.1" 200 194478 "http://geneslinuxbox.net:6309/gene/; "Mozilla/5.0 
> (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 
> Chrome/57.0.2987.133 Safari/537.36"
> coyote.coyote.den:80 40.94.105.9 - - 
> [11/Nov/2019:12:08:56 -0500] "GET /favicon.ico HTTP/1.1" 200 
> 1705 "http://geneslinuxbox.net:6309/gene/; "Mozilla/5.0 (Windows NT 
> 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 
> Chrome/57.0.2987.133 Safari/537.36"
> coyote.coyote.den:80 203.133.169.54 - - 
> [11/Nov/2019:12:10:52 -0500] "GET /robots.txt HTTP/1.1" 200 
> 1092 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> coyote.coyote.den:80 203.133.169.54 - - 
> [11/Nov/2019:12:10:53 -0500] "GET /gene/nitros9/level1/d64/modules/sysgo_h0 
> HTTP/1.1" 200 706 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> coyote.coyote.den:80 203.133.169.54 - - 
> [11/Nov/2019:12:10:58 -0500] "GET 
> /gene/nitros9/level1/coco2b/NOS9_6809_L1_coco2b_cocosdc.dsk 
> HTTP/1.1" 200 4718822 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> coyote.coyote.den:80 203.133.169.54 - - 
> [11/Nov/2019:12:11:21 -0500] "GET 
> /gene/nitros9/level1/coco2_6309/NOS9_6309_L1_coco2_6309_dw_directmodempak.dsk 
> HTTP/1.1" 200 554724 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> coyote.coyote.den:80 203.133.169.54 - - 
> [11/Nov/2019:12:11:29 -0500] "GET 
> /gene/nitros9/level1/dalpha/modules/defsfile 
> HTTP/1.1" 200 248 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> coyote.coyote.den:80 203.133.169.54 - - 
> [11/Nov/2019:12:11:34 -0500] "GET 
> /gene/nitros9/level1/atari/modules/n1_scdwv.dd 
> HTTP/1.1" 200 280 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> coyote.coyote.den:80 203.133.169.54 - - 
> [11/Nov/2019:12:11:39 -0500] "GET 
> /gene/nitros9/level1/coco1_6309/bootfiles/bootfile_covga_cocosdc 
> HTTP/1.1" 200 16133 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
> 
> I did ask earlier if daum was a bot but no one answered.  They are 
> becoming a mite pesky.

Well, maybe nobody knows.

I went to daum.net in a web browser, and it looks like it's in an Asian
language.  It also looks like it's selling a bunch of stuff (at least,
it's laid out the way a retailer's web page is typically laid out).

I also went to the URL in your log
.  Again, it's in a
language that I can't read, but it's talking about robots.txt and shows
an example of how to block them.

So, yes, it's a bot.

Did you not try either of these steps yourself?

Re: armhf version of bzip2 is broken

[Greg Wooledge]

On Mon, Nov 11, 2019 at 12:08:15PM -0500, Gene Heskett wrote:
> And its man page says its a 2010 version. And it won't touch a just over 
> 4G built kernel tarball.
> 
> Suggestions?

0) Give all the background details of your setup, like what version of
   Debian you're running, what hardware, what version of bzip2 is
   installed, where you got this input file

1) Show the command you are running.

2) Show the error message it produces.

3) File a bug report.  Which will involve:
   a) Giving all the background details of your setup, like what version
  of Debian you're using, what hardware, what version of bzip2 is
  installed, where you got the input file
   b) Showing the command you are running.
   c) Showing the error message it produces.

Re: ¿Hasta donde se desarrollan los paquetes Debian?

[Alberto Luaces]

Miguel de Dios Matias writes:

> El sáb., 9 nov. 2019 20:35, Roberto C. Sánchez  escribió:
>
>  On Sat, Nov 09, 2019 at 08:29:23PM +0100, Miguel de Dios Matias wrote:
>  >Buenas.
>  >Tengo otra pregunta "un poco rara".
>  >Cuándo un paquete el upstream este muerto. ¿Qué se hace el paquete 
> Debian?
>  >¿Se le abre un git en salsa y se sigue avanzando el paquete? ¿Sólo se
>  >mantiene los fallos de seguridad?¿Se elimina de Debian?
>  >Saludos.
>
>  Eso todo depende de la inclinación del que mantiene el paquete.  Hay
>  ejemplos de todas las tres posibilidades que mencionas.  ¿Tienes un
>  paquete específico que te interesa con respeto a tu pregunta?
>
> Tengo varios en mente, juegos viejitos que conocí en Debian Woody y que en 
> Sourceforge están muertos.
>
> Por ejemplo "Pachi el marciano".
>
> Me gustaría hacer algún arreglo a los bugs abiertos (...que creo que
> eso es es bastante asequible sin ser DD o DM) y después darle un poco
> de vida (...pero supongo que primero tengo que hacer todo el proceso
> de convertirse de DD o DM).

Los paquetes se mantienen indefinidamente hasta que los saque un fallo:
fallo al compilar, dependencias incumplidas o bien fallos de seguridad.
He visto paquetes muy viejos, sin que nadie se ocupe de ellos, perdurar
en el directorio simplemente porque no daban problemas.

Si estás interesado en ese paquete en particular, podrías buscar el
fallo que hizo que lo sacasen automáticamente de la distribución,
arreglarlo y después pedir a alguien que lo suba (no hace falta ser DD
ni DM, simplemente seguir las instrucciones en
https://mentors.debian.net/sponsors/rfs-howto) o solicitarlo a algún DD
que conozcas.

Un saludo,

-- 
Alberto

Re: fail2ban for apache2

[Gene Heskett]

On Monday 11 November 2019 08:33:13 Greg Wooledge wrote:

> > > > I have a list of ipv4's I want fail2ban to block.
> > >
> > > Not sure that fail2ban is the best tool for the job. Where you
> > > already have a list of IPs that you want to block why not just
> > > directly create the iptables rules?
> >
> > just did that, got most of them but semrush apparently has fallback
> > addys to use.  But I'm no longer being DDOSed, which was the point. 
> > Thanks.
>
> In case it wasn't already clear, what fail2ban does is parse a log
> file looking for repeated instances of an invalid login (or whatever).
>  You have to tell it what to look for, and what to do about it.
>
> The typical use is with an ssh server, looking for rapid, repeated
> login failures.  If enough failed logins occur from a single IP, then
> it adds a firewall rule to block that IP address.
>
> Hence "fail 2 ban", i.e. "fail -> ban".
>
> If you already know the IP addresses/ranges that you want to block,
> you don't need fail2ban.
>
> But once again, I really think you'd be better served by blocking this
> particular bot based on user-agent string, assuming it has an easily
> identifiable user-agent in your log files.  That way, when it changes
> its IP address, it'll still be blocked.
>
> I *know* I told you to look at your log files, and to turn on
> user-agent logging if necessary.
>
> I don't remember seeing you ever *post* your log files here, not even
> a single line from a single instance of this bot.  Maybe I missed it.

Only one log file seems to have useful data, the "other..." file, and I 
have posted several single lines here, but here's a  few more:

coyote.coyote.den:80 40.94.105.9 - - 
[11/Nov/2019:12:08:53 -0500] "GET /gene/ HTTP/1.1" 200 
5141 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36"
coyote.coyote.den:80 40.94.105.9 - - 
[11/Nov/2019:12:08:53 -0500] "GET /gene/pix/EasterSundayCropped2004-1.jpg 
HTTP/1.1" 200 194478 "http://geneslinuxbox.net:6309/gene/; "Mozilla/5.0 
(Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/57.0.2987.133 Safari/537.36"
coyote.coyote.den:80 40.94.105.9 - - 
[11/Nov/2019:12:08:56 -0500] "GET /favicon.ico HTTP/1.1" 200 
1705 "http://geneslinuxbox.net:6309/gene/; "Mozilla/5.0 (Windows NT 
10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/57.0.2987.133 Safari/537.36"
coyote.coyote.den:80 203.133.169.54 - - 
[11/Nov/2019:12:10:52 -0500] "GET /robots.txt HTTP/1.1" 200 
1092 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - - 
[11/Nov/2019:12:10:53 -0500] "GET /gene/nitros9/level1/d64/modules/sysgo_h0 
HTTP/1.1" 200 706 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - - 
[11/Nov/2019:12:10:58 -0500] "GET 
/gene/nitros9/level1/coco2b/NOS9_6809_L1_coco2b_cocosdc.dsk 
HTTP/1.1" 200 4718822 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - - 
[11/Nov/2019:12:11:21 -0500] "GET 
/gene/nitros9/level1/coco2_6309/NOS9_6309_L1_coco2_6309_dw_directmodempak.dsk 
HTTP/1.1" 200 554724 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - - 
[11/Nov/2019:12:11:29 -0500] "GET /gene/nitros9/level1/dalpha/modules/defsfile 
HTTP/1.1" 200 248 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - - 
[11/Nov/2019:12:11:34 -0500] "GET 
/gene/nitros9/level1/atari/modules/n1_scdwv.dd 
HTTP/1.1" 200 280 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"
coyote.coyote.den:80 203.133.169.54 - - 
[11/Nov/2019:12:11:39 -0500] "GET 
/gene/nitros9/level1/coco1_6309/bootfiles/bootfile_covga_cocosdc 
HTTP/1.1" 200 16133 "-" "Mozilla/5.0 (compatible; Daum/4.1; 
+http://cs.daum.net/faq/15/4118.html?faqId=28966)"

I did ask earlier if daum was a bot but no one answered.  They are 
becoming a mite pesky.

Thanks.

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 

armhf version of bzip2 is broken

[Gene Heskett]

And its man page says its a 2010 version. And it won't touch a just over 
4G built kernel tarball.

Suggestions?

Thanks.

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: Difference between ipp, ipps, http, https CUPS protocols?

[Brian]

On Mon 11 Nov 2019 at 10:18:26 -0600, Kent West wrote:

> Probably answered somewhere, but I've been DuckDuckGo-ing for the past two
> hours and can't find the answer.
> 
> When adding a printer via the CUPS web interface (localhost:631) on my
> Debian box, Administration / Add Printer / Other Network Printers, there are
> four Internet Printing Protocol options:
> 
> https
> 
> ipp
> 
> http
> 
> ipps
> 
> Which one do I want to select? What are the differences?

'ls -l /usr/lib/cups/backend' tells you that it doesn't matter what
choice you make.

-- 
Brian.

Re: Preseeding questions

[Brian]

On Mon 11 Nov 2019 at 10:13:05 -0600, Richard Owlett wrote:

> On 11/11/2019 08:53 AM, Jonas Smedegaard wrote:
> > Quoting Richard Owlett (2019-11-11 14:34:53)
> > > When I first used Debian, I found preseeding could handle the many of
> > > my needs/desires. I wish to explore further.
> > > 
> > > Where my might I find an exhaustive list of questions which may be
> > > preseeded?
> > 
> > Since debconf values are defined and processed by each package, you can
> > only find an exhaustive list inside the complete package set to be
> > installed on the target system - e.g. by installing a draft system and
> > query the debconf database there.
> > 
> > Beware that some debconf processing done by by debian-installer is
> > declared by special "udeb" packages normally only installed temporarily
> > during install, and therefore will only appear in debconf database of
> > systems actually installed using debian-installer - not e.g. if creating
> > a draft system in a chroot using debootstrap, multistrap, mmdebstrap or
> > some of the related tools skipping the use of those udeb packages.
> > 
> 
> Thank you.
> 
> Preseeding can evidently used in ways I never thought of.
> What I thought I was asking for was a list of all questions I would *see*
> while running the installer in "Expert" mode. I suspect the
> 'special "udeb" packages' are the key.

The udebs used in an ISO may be copied from it with bsdtar. Templates
files in the udebs can be extracted using apt-extracttemplates and then
processed to obtain the information you want.

-- 
Brian.

Difference between ipp, ipps, http, https CUPS protocols?

[Kent West]

Probably answered somewhere, but I've been DuckDuckGo-ing for the past 
two hours and can't find the answer.


When adding a printer via the CUPS web interface (localhost:631) on my 
Debian box, Administration / Add Printer / Other Network Printers, there 
are four Internet Printing Protocol options:


https

ipp

http

ipps

Which one do I want to select? What are the differences?

Thanks!

--

Kent

Re: Preseeding questions

[Richard Owlett]

On 11/11/2019 08:53 AM, Jonas Smedegaard wrote:

Quoting Richard Owlett (2019-11-11 14:34:53)

When I first used Debian, I found preseeding could handle the many of
my needs/desires. I wish to explore further.

Where my might I find an exhaustive list of questions which may be
preseeded?


Since debconf values are defined and processed by each package, you can
only find an exhaustive list inside the complete package set to be
installed on the target system - e.g. by installing a draft system and
query the debconf database there.

Beware that some debconf processing done by by debian-installer is
declared by special "udeb" packages normally only installed temporarily
during install, and therefore will only appear in debconf database of
systems actually installed using debian-installer - not e.g. if creating
a draft system in a chroot using debootstrap, multistrap, mmdebstrap or
some of the related tools skipping the use of those udeb packages.



Thank you.

Preseeding can evidently used in ways I never thought of.
What I thought I was asking for was a list of all questions I would 
*see* while running the installer in "Expert" mode. I suspect the

'special "udeb" packages' are the key.



Browsing the debconf related man pages was eyeopening.

Page Suggestion

[Sarah Watts]

Hi,

I am inquiring about whether you may be interested in linking to our site 
https://www.mathschase.com/ from your page?

http://wiki.mynooblife.org/index.php?title=Submenu:Divers_autres

Maths Chase is a completely free site where you can quickly test your times 
tables. The site is a very simple game but I think kids will find it a really 
fun way to learn their times tables. I wondering whether this could be a useful 
resource for your site readers?

Thank you very much for your consideration.

Kind Regards,
Sarah

Sarah Watts
i...@mathschase.com
https://www.mathschase.com/

Re: Preseeding questions

[Jonas Smedegaard]

Quoting Richard Owlett (2019-11-11 14:34:53)
> When I first used Debian, I found preseeding could handle the many of 
> my needs/desires. I wish to explore further.
> 
> Where my might I find an exhaustive list of questions which may be 
> preseeded?

Since debconf values are defined and processed by each package, you can 
only find an exhaustive list inside the complete package set to be 
installed on the target system - e.g. by installing a draft system and 
query the debconf database there.

Beware that some debconf processing done by by debian-installer is 
declared by special "udeb" packages normally only installed temporarily 
during install, and therefore will only appear in debconf database of 
systems actually installed using debian-installer - not e.g. if creating 
a draft system in a chroot using debootstrap, multistrap, mmdebstrap or 
some of the related tools skipping the use of those udeb packages.


 - Jonas

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

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

Re: fail2ban for apache2

[Greg Wooledge]

On Mon, Nov 11, 2019 at 02:52:36PM +0100, to...@tuxteam.de wrote:
> On Mon, Nov 11, 2019 at 08:33:13AM -0500, Greg Wooledge wrote:
> > > > > I have a list of ipv4's I want fail2ban to block.
> 
> [...]
> 
> > I don't remember seeing you ever *post* your log files here, not even
> > a single line from a single instance of this bot.  Maybe I missed it.
> 
> We had one sample in this thread.

Aye, I hadn't read all the way down that other branch of the thread yet.
The sample in question was from a bingbot, not a SemrushBot.

Re: fail2ban for apache2

[tomas]

On Mon, Nov 11, 2019 at 08:33:13AM -0500, Greg Wooledge wrote:
> > > > I have a list of ipv4's I want fail2ban to block.

[...]

> I don't remember seeing you ever *post* your log files here, not even
> a single line from a single instance of this bot.  Maybe I missed it.

We had one sample in this thread.

Cheers
-- t


signature.asc
Description: Digital signature

Preseeding questions

[Richard Owlett]

When I first used Debian, I found preseeding could handle the many of my 
needs/desires. I wish to explore further.


Where my might I find an exhaustive list of questions which may be 
preseeded?

Re: fail2ban for apache2

[Greg Wooledge]

> > > I have a list of ipv4's I want fail2ban to block.
> >
> > Not sure that fail2ban is the best tool for the job. Where you already
> > have a list of IPs that you want to block why not just directly create
> > the iptables rules?
> 
> just did that, got most of them but semrush apparently has fallback addys 
> to use.  But I'm no longer being DDOSed, which was the point.  Thanks.

In case it wasn't already clear, what fail2ban does is parse a log file
looking for repeated instances of an invalid login (or whatever).  You
have to tell it what to look for, and what to do about it.

The typical use is with an ssh server, looking for rapid, repeated
login failures.  If enough failed logins occur from a single IP, then
it adds a firewall rule to block that IP address.

Hence "fail 2 ban", i.e. "fail -> ban".

If you already know the IP addresses/ranges that you want to block, you
don't need fail2ban.

But once again, I really think you'd be better served by blocking this
particular bot based on user-agent string, assuming it has an easily
identifiable user-agent in your log files.  That way, when it changes
its IP address, it'll still be blocked.

I *know* I told you to look at your log files, and to turn on user-agent
logging if necessary.

I don't remember seeing you ever *post* your log files here, not even
a single line from a single instance of this bot.  Maybe I missed it.

debian.org - Website Revamp

[Logo Design Team]

Hello,

I hope you are doing good!

I just wanted to check if you have any plans for Website Revamp for (
www.debian.org).

The existing website was created long back and the style (UI/UX), web
technology like responsive structure, CMS platform etc have upgraded.

Please let me know if we can be of any help with this.

Thanks!

Regards

Bijoy

www.LogoDesignTeam.com
www.WebDesignTeam.com
www.AnimatedVideo.com
www.InfoGraphicDesignTeam.com

Re: fail2ban for apache2

[tomas]

On Sun, Nov 10, 2019 at 06:07:37PM -0500, Gene Heskett wrote:
> On Sunday 10 November 2019 16:07:22 to...@tuxteam.de wrote:
> 
> > On Sun, Nov 10, 2019 at 10:55:03AM -0500, Gene Heskett wrote:
> > > On Sunday 10 November 2019 08:02:46 Michael wrote:
> > >
> > > Which contains such gems as this:
> > > coyote.coyote.den:80 40.77.167.79 - -
> > > [10/Nov/2019:10:44:45 -0500] "GET /gene/fence/18.html HTTP/1.1" 200
> > > 1121 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0 like Mac OS X)
> > > AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A465
> > > Safari/9537.53 (compatible; bingbot/2.0;
> > > +http://www.bing.com/bingbot.htm)"
> > >
> > > But I've no clue which of the above blather is the "User agent"
> > > [...]
> >
> > It's the sixth field:
> >
> I don't see an obvious field delimiter in this. Tomas. Is it definable?

It's the "".

> >   "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0 like Mac OS X)
> >   AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A465
> >   Safari/9537.53 (compatible; bingbot/2.0;
> >   +http://www.bing.com/bingbot.htm)"
> >
> > Yes, a bit long. But focusing on the bingbot part seems reasonable.

This is the "Common Log Format" (cf. [1] and links therein:
of special interest all that software out there designed to
parse and grok that stuff) or some mutation thereof. And yes,
it can be configured at your heart's content by (drumroll...)
munging your Apache config [2] -- a topic on which you stubbornly
keep a suspicious silence ;-)

Cheers

[1] https://en.wikipedia.org/wiki/Common_Log_Format
[2] https://httpd.apache.org/docs/2.4/logs.html

-- tomás


signature.asc
Description: Digital signature

Re: fail2ban for apache2

[Michael]

On Monday, November 11, 2019 12:07:37 AM CET, Gene Heskett wrote:

On Sunday 10 November 2019 16:07:22 to...@tuxteam.de wrote:


On Sun, Nov 10, 2019 at 10:55:03AM -0500, Gene Heskett wrote: ...

I don't see an obvious field delimiter in this. Tomas. Is it definable?


like thomas told you earlier: there is a good documentation for apache2 at 
https://httpd.apache.org/docs/


just select the appropriate version (probably 2.4), and then klick on 'Log 
Files'. et voilà: you have your answer! double check it with the entries in 
your apache2-configuration in /etc/apache2/sites-enabled/ and you're all 
set.


please take any advice to read documentation seriously, because it might be 
enlightening, and can answer your questions even before they occur.


greetings...