Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[didier gaumet]

Le 15/04/2021 à 02:29, Albretch Mueller a écrit :


  if I boot up passing to the kernel the start up option:

  knoppix64 debug pci=nomsi noapic

  I would get just two lines further bellow:

  pci :00:01:0: MSI quirk detected; subordinated MSI disabled
  PCI Interrupt Link [LNKA] enabled at IRQ 11
  PCI: setting IRQ 11 as level-triggered

  and the boot process would stop.

  is there a way for me to know what the next step would be? The kernel
boot up logs should be " (do)ing ", "... ok"

[...]

Hello Albretch,

I do not know if there is a way to deduce what the next step is in the 
boot process of a particular hardware. And with systemd, the boot 
procedure is parallelized


I am afraid I have no tried and easy solution to propose to you

I do not know what you motherboard is and how old it is.

What I suggest would be to investigate if your BIOS or UEFI has 
particular settings for PCI and try to adapt them to the hardware 
present and the OS installed/to be installed.


As a further measure, you could try to play with the different kernel 
parameters to see if there is an improvement:

 https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html

concerned parameters could be:
- *debug* (to increase the level on information you get at boot, but I 
doubt it alittle because the Debian kernel is not built with all debug 
options in order to be quicker at runtime)

- *irq* (whith the nomsi option, the system would, it seems, be in irq mode)
- *acpi*
- *bios* (to try to forbid the bios to be called by the OS to determine 
how to call MSI/IRQ)

- *pci* and *pcie*

As with Knoppix, you can pass a kernel option to the boot in Debian by 
hitting "e" key at boot to edit the command line to launch the kernel


Good luck :-)

Re: [OT] Help with clonezilla-live: LUKS/LVM2 image backup without partclone.dd

[didier gaumet]

Ouch! both the two replies I made yesterday on this list were too rough 
and I should have read the original posts more carefully.

 Sorry for that and not being able to propose a solution :-)

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[piorunz]

On 15/04/2021 03:15, Celejar wrote:


It certainly works fine for me. I use https only mode for many months
now. Can you bring an example of a page which returns good page on http,
but 404 error on https?


http://www.daat.ac.il/
https://www.daat.ac.il/

Celejar


Their webserver is misconfigured. AFAIR, if they don't support https,
their server should redirect to http page. Instead, they throw 404 error.

Your web browser behaviour is as intended, everything is fine.
If webadmins of that page don't know their sh*t, are you sure you want
to use that website? Who knows what else they forgot to implement.

Disclaimer: I never worked in IT, all self taught, but I have webpage
which I put up myself on Debian computer, with https cert (it's free),
TLS 2.0/3.0 only, PFS, HSTS preload with long duration, OCSP stapling,
top spec security. These guys? They can't even redirect to their http page.


--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[Gene Heskett]

On Thursday 15 April 2021 03:50:19 didier gaumet wrote:

> Le 15/04/2021 à 02:29, Albretch Mueller a écrit :
> >   if I boot up passing to the kernel the start up option:
> >
> >   knoppix64 debug pci=nomsi noapic
> >
> >   I would get just two lines further bellow:
> >
> >   pci :00:01:0: MSI quirk detected; subordinated MSI disabled
> >   PCI Interrupt Link [LNKA] enabled at IRQ 11
> >   PCI: setting IRQ 11 as level-triggered
> >
> >   and the boot process would stop.
> >
> >   is there a way for me to know what the next step would be? The
> > kernel boot up logs should be " (do)ing ", "... ok"
>
> [...]
>
> Hello Albretch,
>
> I do not know if there is a way to deduce what the next step is in the
> boot process of a particular hardware. And with systemd, the boot
> procedure is parallelized
>
> I am afraid I have no tried and easy solution to propose to you
>
> I do not know what you motherboard is and how old it is.
>
> What I suggest would be to investigate if your BIOS or UEFI has
> particular settings for PCI and try to adapt them to the hardware
> present and the OS installed/to be installed.
>
> As a further measure, you could try to play with the different kernel
> parameters to see if there is an improvement:
>  
> https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.ht
>ml
>
> concerned parameters could be:
> - *debug* (to increase the level on information you get at boot, but I
> doubt it alittle because the Debian kernel is not built with all debug
> options in order to be quicker at runtime)
> - *irq* (whith the nomsi option, the system would, it seems, be in irq
> mode) - *acpi*
> - *bios* (to try to forbid the bios to be called by the OS to
> determine how to call MSI/IRQ)
> - *pci* and *pcie*
>
> As with Knoppix, you can pass a kernel option to the boot in Debian by
> hitting "e" key at boot to edit the command line to launch the kernel
>
> Good luck :-)

Or you could do what I did after fighting with an msi board for several 
years a decade back, feed it to the trash can and replace it with an ARK 
shoebox w/intel atom D-525-MW motherboad that was just enough power to 
get the job done, and Just Worked for a decade. But just in the last 90 
days has been replaced with a stack of Dell 7010's with i5 cpu's, off 
lease stuff for $150/copy. Much faster stuff, and makes 4 of the 6 
running in my farm identical. Simplifies things quite a bit.

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: for the mutt users

[Jonathan Dowland]

On Tue, Apr 13, 2021 at 02:06:29PM +0300, Reco wrote:

On Tue, Apr 13, 2021 at 06:52:57AM -0400, Jude DaShiell wrote:

The mixmaster package comes up as a suggested install for mutt and is
not in debian repositories so far as I know.


It was removed from the main back in 2017, see #880101.


Thanks, I've filed patches for mutt and neomutt to remove the reference.

--
Please do not CC me, I am subscribed to the list.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Darac Marjal]

On 15/04/2021 11:16, piorunz wrote:
> On 15/04/2021 03:15, Celejar wrote:
>
>>> It certainly works fine for me. I use https only mode for many months
>>> now. Can you bring an example of a page which returns good page on
>>> http,
>>> but 404 error on https?
>>
>> http://www.daat.ac.il/
>> https://www.daat.ac.il/
>>
>> Celejar
>
> Their webserver is misconfigured. AFAIR, if they don't support https,
> their server should redirect to http page. Instead, they throw 404 error.

If they don't support https, they shouldn't respond at all. Receiving a
404 comes after successful TLS negotiation. With HTTPS you first
establish a TCP connection to port 443 on the server, then you establish
a TLS tunnel to the server; only once those are complete can you send
the "GET" verb over the tunnel. The server has then, securely, responded
"I don't have a page called /".

While it's common practice for HTTP  and HTTPS sites to be identical,
it's not really built in to the protocol. I could well see a situation
where a webmaster might configure, say, just the /admin part to be
accessible over HTTPS.

That said, common use is changing. It's now expected that 
http://example.com, https://example.com, http://www.example.com and
https://www.example.com all serve identical content (mostly because
humans are terrible at paying attention to the full URL and just see
that all as "example dot com".

>
> Your web browser behaviour is as intended, everything is fine.
> If webadmins of that page don't know their sh*t, are you sure you want
> to use that website? Who knows what else they forgot to implement.
>
> Disclaimer: I never worked in IT, all self taught, but I have webpage
> which I put up myself on Debian computer, with https cert (it's free),
> TLS 2.0/3.0 only, PFS, HSTS preload with long duration, OCSP stapling,
> top spec security. These guys? They can't even redirect to their http
> page.
>
>
> -- 
>
> With kindest regards, piorunz.
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Greg Wooledge]

On Thu, Apr 15, 2021 at 11:16:59AM +0100, piorunz wrote:
> TLS 2.0/3.0 only

Nitpick: TLS 1.2 and 1.3.

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Celejar]

On Thu, 15 Apr 2021 11:16:59 +0100
piorunz  wrote:

> On 15/04/2021 03:15, Celejar wrote:
> 
> >> It certainly works fine for me. I use https only mode for many months
> >> now. Can you bring an example of a page which returns good page on http,
> >> but 404 error on https?
> >
> > http://www.daat.ac.il/
> > https://www.daat.ac.il/
> >
> > Celejar
> 
> Their webserver is misconfigured. AFAIR, if they don't support https,
> their server should redirect to http page. Instead, they throw 404 error.

Do you have a reference for this as required by the standards?

> Your web browser behaviour is as intended, everything is fine.
> If webadmins of that page don't know their sh*t, are you sure you want
> to use that website? Who knows what else they forgot to implement.

No, everything is not fine. The website in question is a very valuable
one - it contains a wealth of important academic articles that are
valuable to my work. The techie attitude that the value of a resource
is somehow correlated to the technical competence of its implementation
is unfortunate and misguided.

I might indeed be reluctant to trust such a site with sensitive
personal information, but to suggest that we should shun websites just
because their administrators should be doing a better job is illogical.

> Disclaimer: I never worked in IT, all self taught, but I have webpage
> which I put up myself on Debian computer, with https cert (it's free),
> TLS 2.0/3.0 only, PFS, HSTS preload with long duration, OCSP stapling,
> top spec security. These guys? They can't even redirect to their http page.

Celejar

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Eduardo M KALINOWSKI]

On 15/04/2021 09:12, Celejar wrote:

On Thu, 15 Apr 2021 11:16:59 +0100
piorunz  wrote:


On 15/04/2021 03:15, Celejar wrote:


http://www.daat.ac.il/
https://www.daat.ac.il/

Celejar


I can confirm the problem, by the way.


Their webserver is misconfigured. AFAIR, if they don't support https,
their server should redirect to http page. Instead, they throw 404 error.

Do you have a reference for this as required by the standards?


I don't think this is required by any standard.

But it's certainly bad practice: if they don't want to support https, 
they should disable it, and not return a 404 error. It may not be a 
requirement that the http and https content have to be the same, but it 
certainly makes a lot of sense that they are.


So I'd agree that the website is misconfigured. You might try contacting 
them.


Unlike the HTTPS Everywhere extension, that has a list of sites that 
should be accessed only with https, the built-in Firefox function seems 
to just try to make an https connection, and if it succeeds, assumes 
(reasonably, IMHO) that the site supports https. Since 404 is a valid 
response that in no way indicates lack of https support (on the 
contrary), it then redirects everything to https.


The docs say you can disable https for a specific site: 
https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/ 
. But if this happens a lot, it might be simpler to simply disable that 

Firefox feature. Not because it's buggy, but because it make reasonable 
assumptions about websites' behaviours, which unfortunately are not 
followed by everyone.




--
Canada Bill Jones's Motto:
It's morally wrong to allow suckers to keep their money.

Canada Bill Jones's Supplement:
A Smith and Wesson beats four aces.

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[Andrew M.A. Cater]

On Thu, Apr 15, 2021 at 06:30:41AM -0400, Gene Heskett wrote:
> On Thursday 15 April 2021 03:50:19 didier gaumet wrote:
> 
> > Le 15/04/2021 à 02:29, Albretch Mueller a écrit :
> > >   if I boot up passing to the kernel the start up option:
> > >
> > >   knoppix64 debug pci=nomsi noapic
> > >
> > >   I would get just two lines further bellow:
> > >
> > >   pci :00:01:0: MSI quirk detected; subordinated MSI disabled
> > >   PCI Interrupt Link [LNKA] enabled at IRQ 11
> > >   PCI: setting IRQ 11 as level-triggered
> > >
> > >   and the boot process would stop.
> > >
> > >   is there a way for me to know what the next step would be? The
> > > kernel boot up logs should be " (do)ing ", "... ok"
> >

Hello Albretch

Are you still subject to constraints in what you can do with your hardware: I 
know a while back in other threads on this mailing list you said that you had
to use virtual machines / live disks.

Is this a desktop / laptop and do you have the ability to change whatever
settings you need?

All the very best, as ever,

Andy C.


> > [...]
> >
> > Hello Albretch,
> >
> > I do not know if there is a way to deduce what the next step is in the
> > boot process of a particular hardware. And with systemd, the boot
> > procedure is parallelized
> >
> > I am afraid I have no tried and easy solution to propose to you
> >
> > I do not know what you motherboard is and how old it is.
> >
> > What I suggest would be to investigate if your BIOS or UEFI has
> > particular settings for PCI and try to adapt them to the hardware
> > present and the OS installed/to be installed.
> >
> > As a further measure, you could try to play with the different kernel
> > parameters to see if there is an improvement:
> >  
> > https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.ht
> >ml
> >
> > concerned parameters could be:
> > - *debug* (to increase the level on information you get at boot, but I
> > doubt it alittle because the Debian kernel is not built with all debug
> > options in order to be quicker at runtime)
> > - *irq* (whith the nomsi option, the system would, it seems, be in irq
> > mode) - *acpi*
> > - *bios* (to try to forbid the bios to be called by the OS to
> > determine how to call MSI/IRQ)
> > - *pci* and *pcie*
> >
> > As with Knoppix, you can pass a kernel option to the boot in Debian by
> > hitting "e" key at boot to edit the command line to launch the kernel
> >
> > Good luck :-)
> 
> Or you could do what I did after fighting with an msi board for several 
> years a decade back, feed it to the trash can and replace it with an ARK 
> shoebox w/intel atom D-525-MW motherboad that was just enough power to 
> get the job done, and Just Worked for a decade. But just in the last 90 
> days has been replaced with a stack of Dell 7010's with i5 cpu's, off 
> lease stuff for $150/copy. Much faster stuff, and makes 4 of the 6 
> running in my farm identical. Simplifies things quite a bit.
> 
> 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: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Jonathan Dowland]

On Thu, Apr 15, 2021 at 11:44:21AM +0100, Darac Marjal wrote:

If they don't support https, they shouldn't respond at all.


Perhaps they do, but not for the hostname being used here to access the
web server.


--
Please do not CC me, I am subscribed to the list.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Jonathan Dowland]

On Thu, Apr 15, 2021 at 01:31:45PM +0100, Jonathan Dowland wrote:

On Thu, Apr 15, 2021 at 11:44:21AM +0100, Darac Marjal wrote:

If they don't support https, they shouldn't respond at all.


Perhaps they do, but not for the hostname being used here to access the
web server.


Although looking at the cert, the CN is for that host (www.daat.ac.il).

--
Please do not CC me, I am subscribed to the list.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[mett]

2021-04-15 21:12 に Celejar さんは書きました:

On Thu, 15 Apr 2021 11:16:59 +0100
piorunz  wrote:


On 15/04/2021 03:15, Celejar wrote:

>> It certainly works fine for me. I use https only mode for many months
>> now. Can you bring an example of a page which returns good page on http,
>> but 404 error on https?
>
> http://www.daat.ac.il/
> https://www.daat.ac.il/
>
> Celejar

Their webserver is misconfigured. AFAIR, if they don't support https,
their server should redirect to http page. Instead, they throw 404 
error.


Do you have a reference for this as required by the standards?


Your web browser behaviour is as intended, everything is fine.
If webadmins of that page don't know their sh*t, are you sure you want
to use that website? Who knows what else they forgot to implement.


No, everything is not fine. The website in question is a very valuable
one - it contains a wealth of important academic articles that are
valuable to my work. The techie attitude that the value of a resource
is somehow correlated to the technical competence of its implementation
is unfortunate and misguided.

I might indeed be reluctant to trust such a site with sensitive
personal information, but to suggest that we should shun websites just
because their administrators should be doing a better job is illogical.


Disclaimer: I never worked in IT, all self taught, but I have webpage
which I put up myself on Debian computer, with https cert (it's free),
TLS 2.0/3.0 only, PFS, HSTS preload with long duration, OCSP stapling,
top spec security. These guys? They can't even redirect to their http 
page.


Celejar


Hi,

The site address you provided support https:


So, indeed, some misconfiguration it seems.
Maybe they simply forget to redirect http to https.


Though I agree no need to shun them.

HTH

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[Dan Ritter]

Gene Heskett wrote: 
> 
> Or you could do what I did after fighting with an msi board for several 
> years a decade back, feed it to the trash can and replace it with an ARK 


MSI the motherboard manufacturer has nothing to do with the 
PCI feature we are discussing here.

https://www.kernel.org/doc/html/latest/PCI/msi-howto.html

-dsr-

Re: KVM: GPU passthrough

[Gokan Atmaca]

Hello

> Just to confirm: you have at least two graphics cards? One for
> the host to boot with, one for your guest to take over?

I saw it working in my trials. But of course, since there is only one
graphics card, the image of the host system is gone. :) I am looking
for a motherboard where I can install two graphics cards.

On Fri, Apr 9, 2021 at 2:51 AM Dan Ritter  wrote:
>
> Gokan Atmaca wrote:
> > Hello
> >
> > I want to use the graphics card directly in the virtual machine. IOMMU
> > seems to be running, but unfortunately it doesn't work when I want to
> > start the virtual machine.
> >
> >
> > error:
> > pci,host=:01:00.0,id=hostdev0,bus=pci.0,addr=0x9: vfio
> > :01:00.0: group 1 is not viable
> > Please ensure all devices within the iommu_group are bound to their
> > vfio bus driver.
>
> Just to confirm: you have at least two graphics cards? One for
> the host to boot with, one for your guest to take over?
>
> And you loaded the vfio mod and configured it with the PCI ids
> for your second card? There could be several.
>
> -dsr-

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Dan Ritter]

Kenneth Parker wrote: 
> 
> I use lighttpd for eyeblinkuniverse.com, with nano as my editor. I don't
> quite understand the Certificates required for https. I guess it is time
> for some lessons.

The easiest thing to do here is to install certbot.

Assuming that your web root is /var/www and your domain name is
eyeblinkuniverse.com:

certbot certonly --webroot -w /var/www -d eyeblinkuniverse.com -d 
www.eyeblinkuniverse.com

It will ask you some questions, then it should drop some files
in /etc/letsencrypt/live/eyeblinkuniverse.com/

Now you need to combine those files for lighttpd:

cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
/etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
/etc/letsencrypt/live/eyeblinkuniverse/merged.pem

And then tell lighttpd to use it:

$SERVER["socket"] == ":443" {
 ssl.engine   = "enable"
 ssl.ca-file  = "/etc/letsencrypt/live/eyeblinkuniverse.com/chain.pem"
 ssl.pemfile  = "/etc/letsencrypt/live/eyeblinkuniverse.com/merged.pem"
}


And restart lighttpd. Test your new https://www.eyeblinkuniverse.com 

Last step: create a cron job to run once a week that does
this:

certbot renew && \
cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
/etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
/etc/letsencrypt/live/eyeblinkuniverse/merged.pem && \
service lighttpd restart

That should take care of you. If you run into trouble, you're
using the largest issuer of SSL certs and the most popular
client, and the cron job should let you know a month before the
cert actually expires.

-dsr-

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[piorunz]

On 15/04/2021 13:40, mett wrote:


So, indeed, some misconfiguration it seems.
Maybe they simply forget to redirect http to https.


Though I agree no need to shun them.

HTH


If webadmin FORGETS to implement https in 2021, then he deserves losing
his job. 🤯


--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Kenneth Parker]

On Thu, Apr 15, 2021, 9:32 AM Dan Ritter  wrote:

> Kenneth Parker wrote:
> >
> > I use lighttpd for eyeblinkuniverse.com, with nano as my editor. I don't
> > quite understand the Certificates required for https. I guess it is time
> > for some lessons.
>
> The easiest thing to do here is to install certbot.
>
> Assuming that your web root is /var/www and your domain name is
> eyeblinkuniverse.com:
>
> certbot certonly --webroot -w /var/www -d eyeblinkuniverse.com -d
> www.eyeblinkuniverse.com
>
> It will ask you some questions, then it should drop some files
> in /etc/letsencrypt/live/eyeblinkuniverse.com/
>
> Now you need to combine those files for lighttpd:
>
> cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
> /etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
> /etc/letsencrypt/live/eyeblinkuniverse/merged.pem
>
> And then tell lighttpd to use it:
>
> $SERVER["socket"] == ":443" {
>  ssl.engine   = "enable"
>  ssl.ca-file  = "/etc/letsencrypt/live/eyeblinkuniverse.com/chain.pem"
>  ssl.pemfile  = "/etc/letsencrypt/live/eyeblinkuniverse.com/merged.pem"
> }
>
>
> And restart lighttpd. Test your new https://www.eyeblinkuniverse.com
>
> Last step: create a cron job to run once a week that does
> this:
>
> certbot renew && \
> cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
> /etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
> /etc/letsencrypt/live/eyeblinkuniverse/merged.pem && \
> service lighttpd restart
>
> That should take care of you. If you run into trouble, you're
> using the largest issuer of SSL certs and the most popular
> client, and the cron job should let you know a month before the
> cert actually expires.
>

Wow.  Thanks!  I had, also discussed this with the Support Staff at
Linode.  You said it "MUCH" clearer than they did.

I am in the process of a System Upgrade (from Ubuntu 14.04 to Debian
Buster) and this will become, one of my, more enjoyable tasks.

Kenneth Parker

>

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Erwan David]

Le 15/04/2021 à 16:16, piorunz a écrit :

On 15/04/2021 13:40, mett wrote:


So, indeed, some misconfiguration it seems.
Maybe they simply forget to redirect http to https.


Though I agree no need to shun them.

HTH


If webadmin FORGETS to implement https in 2021, then he deserves losing
his job. 🤯




But nothing says that http:// and https:// must have 
same content.

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Celejar]

On Thu, 15 Apr 2021 09:31:11 -0300
Eduardo M KALINOWSKI  wrote:

> 
> On 15/04/2021 09:12, Celejar wrote:
> > On Thu, 15 Apr 2021 11:16:59 +0100
> > piorunz  wrote:
> >
> >> On 15/04/2021 03:15, Celejar wrote:
> >>
> >>> http://www.daat.ac.il/
> >>> https://www.daat.ac.il/
> >>>
> >>> Celejar
> 
> I can confirm the problem, by the way.
> 
> >> Their webserver is misconfigured. AFAIR, if they don't support https,
> >> their server should redirect to http page. Instead, they throw 404 error.
> > Do you have a reference for this as required by the standards?
> 
> I don't think this is required by any standard.
> 
> But it's certainly bad practice: if they don't want to support https, 
> they should disable it, and not return a 404 error. It may not be a 
> requirement that the http and https content have to be the same, but it 
> certainly makes a lot of sense that they are.
> 
> So I'd agree that the website is misconfigured. You might try contacting 
> them.
> 
> Unlike the HTTPS Everywhere extension, that has a list of sites that 
> should be accessed only with https, the built-in Firefox function seems 
> to just try to make an https connection, and if it succeeds, assumes 
> (reasonably, IMHO) that the site supports https. Since 404 is a valid 
> response that in no way indicates lack of https support (on the 
> contrary), it then redirects everything to https.

Thank you. That was my analysis of the problem as well.

> The docs say you can disable https for a specific site: 
> https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/
>  

I tried the setting, but it didn't seem to work.

> . But if this happens a lot, it might be simpler to simply disable that 
> 
> Firefox feature. Not because it's buggy, but because it make reasonable 
> assumptions about websites' behaviours, which unfortunately are not 
> followed by everyone.

I may have to do that.

Celejar

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[piorunz]

On 15/04/2021 15:49, Erwan David wrote:


If webadmin FORGETS to implement https in 2021, then he deserves losing
his job. 🤯



But nothing says that http:// and https:// must have
same content.


 Of course, 404 error on https version of the website it a
great piece of content. Admins are doing great job.

--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[Albretch Mueller]

> What I suggest would be to investigate if your BIOS or UEFI has particular 
> settings for PCI and try
> to adapt them to the hardware present and the OS installed/to be installed.

> As a further measure, you could try to play with the different kernel 
> parameters to see if there is an
> improvement: 
> https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html
> concerned parameters could be:
> - *debug* (to increase the level on information you get at boot, but I doubt 
> it alittle because
> the Debian kernel is not built with all debug options in order to be quicker 
> at runtime)
> - *irq* (whith the nomsi option, the system would, it seems, be in irq mode)
> - *acpi*
> - *bios* (to try to forbid the bios to be called by the OS to determine how 
> to call MSI/IRQ)
> - *pci* and *pcie*

> As with Knoppix, you can pass a kernel option to the boot in Debian by 
> hitting "e" key at boot to edit the command line to launch the kernel

 Thank you. I have tried every possible option combination with
knoppix and I have studied reports on similar problems by other
people, but I haven't still been able to make that mobo boot up.

 The problem is that the idiots that designed that motherboard make it
hard for you to get to their BIOS (I haven't even figured out that)
and I haven't been able to find their manual/specs for that board
online (most probably for other reasons)

> Or you could do what I did after fighting with an msi board for
> several years a decade back ...

 I may have too, but I must work under constraints and on a short
budget and I must be hopeful as well ;-).

> Are you still subject to constraints in what you can do
> with your hardware: I know a while back in other threads
> on this mailing list you said that you had to use virtual
> machines / live disks.

 Well, yes. I can only access the internet using live CDs/DVDs
(preferably while using knoppix with the toram option). I have higher
powers actively messing with me. Some people tell me that they "mess
with", monitor everyone that I am just aware and I hate them and their
bs because it messes with my line of work.

 I never effing ever connect my work machine to the Internet. I mean,
noticing my doctor telling me whatever with a computer connected to
the Internet makes me anxious and if you think I am "paranoid" all I
have to say is: "thank you". These times being "paranoid" about such
matters is a healthy state of mind.

 So, live DVDs with some extra scripts to customize things a bit and I
am fine to go.

 I like Debian very much, just using apt in the way that it is
supposed to be used assuming that the Internet is a safe, "trusted"
environment is an odd joke to me. we have had these constant back and
forths in the mailing list. I have even been dreaming about coding a
version of apt based on java (japt?), so that you could go anywhere
with any laptop and get all libraries and etc's, it shouldn't be hard
at all but right now I cannot dedicate time and mind to any other
thing.

>MSI the motherboard manufacturer has nothing to do with the
>PCI feature we are discussing here.

>https://www.kernel.org/doc/html/latest/PCI/msi-howto.html

thank you. it was a confusing coincidence. The thing is that the
motherboard on that box is an:

MSI MS-7641 Ver.3.0 + AMD Athlon II x2 250

 the two links were very good but also "too intertaining" I just need
to get the thing to work for me asap.

lbrtchx

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[didier gaumet]

Le 15/04/2021 à 20:14, Albretch Mueller a écrit :
[...]

and I haven't been able to find their manual/specs for that board
online (most probably for other reasons)

[...]

MSI MS-7641 Ver.3.0 + AMD Athlon II x2 250

[...]

the page of this MB support on the MSI website:
 https://www.msi.com/Motherboard/support/760GM-P23-FX#down-bios

the manual:
 https://download.msi.com/archive/mnu_exe/M7641v3.0.zip
(hit  at boot to access the BIOS)

Re: pci 0000:00:01:0: MSI quirk detected; subordinated MSI disabled ...

[Alexander V. Makartsev]

On 15.04.2021 23:14, Albretch Mueller wrote:

https://www.kernel.org/doc/html/latest/PCI/msi-howto.html

thank you. it was a confusing coincidence. The thing is that the
motherboard on that box is an:

MSI MS-7641 Ver.3.0 + AMD Athlon II x2 250

  the two links were very good but also "too intertaining" I just need
to get the thing to work for me asap.

lbrtchx


Have you tried to update BIOS? [1] Patch notes look promising.
For me it's usually a first step of troubleshooting and resolving 
possibly hardware related problems.
If first link doesn't lead to support page for your motherboard, you 
have to find your exact motherboard model using search. [2]

If you flash wrong BIOS image you will brick your motherboard.


[1] https://us.msi.com/Motherboard/support/760GM-P23-FX
[2] https://us.msi.com/search/MS-7641?page=1

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Firefox HTTPS-only mode breaks sites that return 404 for HTTPS connections

[Richard Hector]

On 16/04/21 1:32 am, Dan Ritter wrote:

Last step: create a cron job to run once a week that does
this:

certbot renew && \
cat /etc/letsencrypt/live/eyeblinkuniverse.com/privkey.pem \
/etc/letsencrypt/live/eyeblinkuniverse.com/cert.pem > \
/etc/letsencrypt/live/eyeblinkuniverse/merged.pem && \
service lighttpd restart


Doesn't the certbot package create a cronjob/timer for you?

And I'd probably put the merge in a deploy hook, rather than modifying 
the cronjob and/or systemd timer.


Not to say the above won't work, of course - except that if you create 
or modify the cronjob without touching the systemd timer (and you're 
using systemd), you might get unexpected results.


And I haven't tested my thoughts :-)

Richard