Re: wget et ping refusent d'utiliser l'adresse source spécifiée

[Pierre Malard]

Bonjour,

Il ne me semble pas que ce soit un problème de route si il a attribué à son 
serveur une IP dans la même classe réseau. Dans ce cas c’est le broadcast qui 
est utilisé pour trouver la destination. Par contre pour éviter un problème de 
routage avec le switch intermédiaire, j’aurai connecté mon serveur directement 
sur le switch DLink. Par contre le fait que le switch ne réponde pas n’est pas 
forcément anormal. Peut-être que le DLink  filtre ce genre de traffic.

Ce que je proposerai c’est de connecter directement un poste quelconque 
configuré dans la classe du DLink directement sur le DLink et de suivre la doc 
pour le configurer. Cela m’étonne que DLink n’ai pas une description de la mise 
en route de son switch et qu’ils n’est pas prévu, par exemple, un accès en IPv6 
locale ou une possibilité de connexion en mode console.

Sinon, dans la configuration actuelle je tenterai un « nmap -sS 10.90.90.90 » 
(ou avec « -Pn » pour savoir sur quels ports répond, ou pas.

> Le 15 déc. 2022 à 20:02, Erwann Le Bras  a écrit :
> 
> bonsoir
> 
> il ne manquerait pas une route pour utiliser l'interface en 10.90.90 pour 
> joindre spécifiquement ce sous-réseau?
> 
> Ta route par défaut doit indiquer d'utiliser la mauvaise interface réseau, 
> d'où l'échec du ping.
> 
> Le 12/12/2022 à 18:07, Olivier a écrit :
>> Bonjour,
>> 
>> J'ai une machine distante sous Stretch indirectement connectée à un
>> nouveau commutateur DLink de la façon suivante:
>> Serveur - Switch Mikrotik - Switch DLink
>> 
>> Comme chacun sait, les nouveaux commutateurs DLink sont livrés avec
>> une IP par défaut égale à 10.90.90.90/8.
>> 
>> Afin de configurer ce switch pour la première fois, j'ai attribué à
>> mon serveur l'IP 10.90.90.91/24 à l'unique interface Ethernet  de mon
>> serveur (avec la commande ip addr add 10.90.90.91/8 dev eno1).
>> 
>> À ma grande surprise, chaque ping depuis le serveur vers le nouveau
>> commutateur, avec la commande ping -c1 -I 10.90.90.91 10.90.90.90,
>> échoue (pas de réponse)
>> 
>> J'ai pourtant utilisé des dizaines et des dizaines de fois l'option -I
>> de ping permettant de spécifier l'adresse ou l'interface source
>> utilisée lors du ping.
>> 
>> Avec la commande tshark, j'ai:
>> 
>> # tshark -f 'ip host 10.90.90.90' -i eno1
>> Running as user "root" and group "root". This could be dangerous.
>> Capturing on 'eno1'
>> 1 0.0 192.168.1.24→ 10.90.90.90  ICMP 98 Echo (ping)
>> request  id=0x15e9, seq=1/256, ttl=64
>> 
>> Ceci me laisse penser que l'option -I est ignorée puisque le serveur
>> semble émettre avec son adresse par défaut 192.168.1.24.
>> 
>> En utilisant une commande wget --bind-address 10.90.90.91
>> http://10.90.90.90 , tshark indique une IP source en 
>> 192.168.1.24 et
>> non en 10.90.90.91, comme demandé.
>> 
>> En attribuant une autre adresse du réseau 10.0.0.0/8 au switch
>> Mikrotik, le ping de celui-ci vers 10.90.90.90 réussit, ce qui me
>> confirme que le switch DLink répond.
>> 
>> Une piste ?
>> 
>> Slts
>> 

--
Pierre Malard
Responsable architectures système CDS DINAMIS/THEIA Montpellier
IRD - UMR Espace-Dev - UAR CPST - IR Data-Terra
Maison de la Télédétection
500 rue Jean-François Breton
34093 Montpellier Cx 5
France

   « le passé n'éclairant plus l'avenir, l'esprit marche dans les ténèbres »
  Alexis de Tocqueville - Démocratie en 
Amérique
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Debian failed

[George Olson]

On 12/4/22 16:09, hw wrote:

On Sun, 2022-12-04 at 15:00 +, Andrew M.A. Cater wrote:

On Sun, Dec 04, 2022 at 03:52:31PM +0100, hw wrote:

Hi,

so I wanted to have Debian on a Precision R7910 with AMD graphics card
and it failed because it refuses to use the amdgpu module.  I tried
forcing to load it when booting and it still didn't work.

So I'm stuck with Fedora.  What's wrong with Debian that we can't even
get AMD cards to work.


Hi hw

How did you install - what image, what steps?

debian-11.5.0-amd64-netinst.iso


Did you use the firmware installer?

Installed the radeon firmware with aptitude.


You *only* have the ADMFirePro and no Nvidia card.

No, it's a RX 6600 XT.  Since that card is built unreasonably large, I
put a NVIDIA 1080ti FE into the workstation which I thought is broken.
However, at least with nouveau drivers, the card works fine.  Once I can
install NVIDIA drivers I'll see if it still works ...

They need to make AMD cards that aren't too large to fit ...



Sorry to be really brief on this, getting ready to head out for 
something important. But thought I would respond here.


I have an RX 6600 XT also. I use a 4 monitor setup and had to configure 
things so that it would work with 2 on top and 2 on the bottom. I can't 
remember exactly how I did it, but I first installed Bullseye and 
figured out it wasn't going to work. I had enough of a functional 
graphics environment and terminal to change all my sources to Testing, 
which goes by the codename Bookworm, because to me that was easier than 
trying to figure out how to use backports to install a newer kernel.


Once I got that running, it has basically been going without a hitch. 
Testing seems to be almost as stable as regular Debian Bullseye like I 
have on my laptop. I haven't run into any major snags yet.


I am really new to Debian, having only just installed this around the 
end of September. I came over from openSUSE. If you have been using 
Fedora for a long time, I am sure you will be able to figure out how to 
make it work. I know it can be frustrating to go through hours and hours 
of trying to find this out, find that out, but it will be worth it to 
finally get through it and see it working. It has been for me.


tribe

apt update fails due to Label and Version changes for buster security

[John Boxall]

The following happened just now when updating my Buster system:


+ apt update
Hit:1 http://deb.debian.org/debian buster InRelease 



Get:2 http://security.debian.org/debian-security buster/updates 
InRelease [34.8 kB] 

Hit:3 http://dl.google.com/linux/chrome/deb stable InRelease 

Hit:4 http://deb.debian.org/debian buster-updates InRelease 

E: Repository 'http://security.debian.org/debian-security buster/updates 
InRelease' changed its 'Label' value from 'Debian' to 'Debian-Security'
N: Repository 'http://security.debian.org/debian-security buster/updates 
InRelease' changed its 'Version' value from '10.13' to '10'
N: This must be accepted explicitly before updates for this repository 
can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this 
repository? [y/N] n
Hit:5 https://download.virtualbox.org/virtualbox/debian buster InRelease 



Hit:6 https://updates.signal.org/desktop/apt xenial InRelease 



Reading package lists... Done 



E: Failed to fetch 
http://security.debian.org/debian-security/dists/buster/updates/InRelease
E: Some index files failed to download. They have been ignored, or old 
ones used instead.

-


I didn't have this issue about four hours ago. Does anyone have any ideas?
--
Regards,

John Boxall

Re: stopping mass surveillance

[Dan Ritter]

operation.privacyenforcem...@secure.mailbox.org wrote: 
> Dan Ritter wrote:
> > operation.privacyenforcem...@mailbox.org wrote:
> > > On 1/9/84 19:84, Jeremy Hendricks message was saved by the all seeing eye:
> > > > Please provide code examples, flow chart, or a white paper.
> > > 
> > > Releasing anything of requested documents is not desired yet. The idea is
> > > not patented yet and will make the developers a high value target for a 
> > > lot
> > > of agencies worldwide.
> > 
> > If your project is going to be patented, it can't be part of
> > Debian unless you want to give a patent license to everyone in
> > the world, which defeats the point of patenting it in the first
> > place.
> 
> A patent can protect only a brand or product name.

That's a trademark. Everything you've discussed up until now
fits a patent, which is a request for a monopoly on an
invention. A trademark is a request for a monopoly on a given
name in a specific field of business. Receiving a trademark
prevents other people from calling their products by the same
or confusingly similar names, not from using your product.


> This
> 
> >> I am open minded to release the idea confidentially to a
> >> trustworthy developer group of an open source project to let them develop
> it
> >> and make it available as FLOSS completely for everyone. It needs to be
> built
> >> before privacy is dead, with or without earning money. It needs to be
> >> enforced before we will loose privacy forever.
> 
> would match Debians policies?

You say contradictory things. You shift positions. You don't
give details as to how this hypothetical thing might work. 

> I wanted to request a feedback how important this topic seems to be for the
> Debian user base, would you use it? Would you prefer it to be open source?
> Do you feel unprotected on Debian? Do you think this is neccessary?
> Later I want to find potentially interested developers if the Debian
> priciples would be applied and released completely FLOSS.
> 
> The release of the solution is more important then profit.

Why don't you start a discussion group, forum, mailing list, or
similar communications methodology, tell us about that, and then
come back when you have a first working draft?

-dsr-

Re: stopping mass surveillance

[The Wanderer]

On 2022-12-15 at 19:34, operation.privacyenforcem...@secure.mailbox.org
wrote:

> Dan Ritter wrote:
> 
>> operation.privacyenforcem...@mailbox.org wrote:

>>> Releasing anything of requested documents is not desired yet. The
>>> idea is not patented yet and will make the developers a high
>>> value target for a lot of agencies worldwide.
>> 
>> If your project is going to be patented, it can't be part of Debian
>> unless you want to give a patent license to everyone in the world,
>> which defeats the point of patenting it in the first place.
> 
> A patent can protect only a brand or product name.

The only thing I'm aware of that is called a "patent" and can be applied
to branding / etc. like that is a design patent, which is typically very
different and I don't see how it could be applied to software (though it
could potentially be applied to UI).

Trademarks, et cetera, might be applicable - but they are not patents.

>>> I am looking for people, developers, companies that would be
>>> interested in using or developing such a solution, planning a
>>> commercial high price launch on the market, licensed will be
>>> current revisions. Older revisions with less features or security
>>> will be released under an open source license. If this is
>>> impossible I am open minded to release the idea confidentially to
>>> a trustworthy developer group of an open source project to let
>>> them develop it and make it available as FLOSS completely for
>>> everyone. It needs to be built before privacy is dead, with or
>>> without earning money. It needs to be enforced before we will
>>> loose privacy forever.
>> 
>>> Governments, police, politicians will be excluded via license in
>>> any case.
>> 
>> None of the open source licenses that Debian will accept can be 
>> limited in that way, so, again, Debian is not the home for your 
>> project.
> 
> This
> 
>>> I am open minded to release the idea confidentially to a
>>> trustworthy developer group of an open source project to let them
>>> develop it and make it available as FLOSS completely for
>>> everyone. It needsto be built before privacy is dead, with or
>>> without earning money. It needsto be enforced before we will
>>> loose privacy forever.
> 
> would match Debians policies?

That part could, but

>>> Governments, police, politicians will be excluded via license in 
>>> any case.

definitely would not. Even a license statement that "This software shall
be used for Good, not Evil" is deemed to not be DFSG-free; a license
which explicitly excludes a category of user, or a field of endeavor,
would definitely not qualify.

-- 
   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

Re: stopping mass surveillance

[operation . privacyenforcement]

Dan Ritter wrote:

operation.privacyenforcem...@mailbox.org wrote:

On 1/9/84 19:84, Jeremy Hendricks message was saved by the all seeing eye:

Please provide code examples, flow chart, or a white paper.


Releasing anything of requested documents is not desired yet. The idea is
not patented yet and will make the developers a high value target for a lot
of agencies worldwide.


If your project is going to be patented, it can't be part of
Debian unless you want to give a patent license to everyone in
the world, which defeats the point of patenting it in the first
place.


A patent can protect only a brand or product name.




I am looking for people, developers, companies that would be interested in
using or developing such a solution, planning a commercial high price launch
on the market, licensed will be current revisions. Older revisions with less
features or security will be released under an open source license. If this
is impossible I am open minded to release the idea confidentially to a
trustworthy developer group of an open source project to let them develop it
and make it available as FLOSS completely for everyone. It needs to be built
before privacy is dead, with or without earning money. It needs to be
enforced before we will loose privacy forever.



Governments, police, politicians will be excluded via license in any case.


None of the open source licenses that Debian will accept can be
limited in that way, so, again, Debian is not the home for your
project.


This

>> I am open minded to release the idea confidentially to a
>> trustworthy developer group of an open source project to let them 
develop it
>> and make it available as FLOSS completely for everyone. It needs to 
be built

>> before privacy is dead, with or without earning money. It needs to be
>> enforced before we will loose privacy forever.

would match Debians policies?




Curious about everyones opinion regarding this.


It might be interesting, but it's definitely not suitable for
this mailing list.


I wanted to request a feedback how important this topic seems to be for 
the Debian user base, would you use it? Would you prefer it to be open 
source? Do you feel unprotected on Debian? Do you think this is neccessary?
Later I want to find potentially interested developers if the Debian 
priciples would be applied and released completely FLOSS.


The release of the solution is more important then profit.

operation privacyenforcement

Re: testing update of firefox (to firefox_108.0-1) may not work

[Ash Joubert]

On 15/12/2022 10:30, Ash Joubert wrote:

Also affects sid. For those affected, the bug is:
#1026072: firefox: fails to start (cannot load libnssutil3.so)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026072
I have run "apt-mark hold firefox" and will continue to hold firefox (at 
107.0.1-1 on sid) until this bug is fixed.


This bug is now fixed in firefox 108.0-2 on sid.

Kind regards,

--
Ash Joubert (they/them) 
Director / Game Developer
Transient Software Limited 
New Zealand

Re: stopping mass surveillance

[Dan Ritter]

operation.privacyenforcem...@mailbox.org wrote: 
> On 1/9/84 19:84, Jeremy Hendricks message was saved by the all seeing eye:
> > Please provide code examples, flow chart, or a white paper.
> 
> Releasing anything of requested documents is not desired yet. The idea is
> not patented yet and will make the developers a high value target for a lot
> of agencies worldwide.

If your project is going to be patented, it can't be part of
Debian unless you want to give a patent license to everyone in
the world, which defeats the point of patenting it in the first
place.

> I am looking for people, developers, companies that would be interested in
> using or developing such a solution, planning a commercial high price launch
> on the market, licensed will be current revisions. Older revisions with less
> features or security will be released under an open source license. If this
> is impossible I am open minded to release the idea confidentially to a
> trustworthy developer group of an open source project to let them develop it
> and make it available as FLOSS completely for everyone. It needs to be built
> before privacy is dead, with or without earning money. It needs to be
> enforced before we will loose privacy forever.

> Governments, police, politicians will be excluded via license in any case.

None of the open source licenses that Debian will accept can be
limited in that way, so, again, Debian is not the home for your
project.

> Curious about everyones opinion regarding this.

It might be interesting, but it's definitely not suitable for
this mailing list.

https://randomstring.org/~dsr/eula.html is hereby incorporated by reference.

-dsr-

Re: stopping mass surveillance

[debian-user]

[snip]

Sorry but what does all this have to do with Debian, and specifically
with supporting Debian users?

Re: stopping mass surveillance

[operation . privacyenforcement]

On 1/9/84 19:84, Jeremy Hendricks message was saved by the all seeing eye:

Please provide code examples, flow chart, or a white paper.


Releasing anything of requested documents is not desired yet. The idea 
is not patented yet and will make the developers a high value target for 
a lot of agencies worldwide.

Would be smart to make plans secretly and silently.

The product would protect against

-data amount transfered in total
-data routing timing information
-datarate per time interval
-communication destination and source with anonymization
-communication destination and source without anonymization (needs 
specially processed traffic routing)

-any system or user impact on the routed traffic
-used encryption on user level or system level of origin and destination
-probably makes DPI impossible

The solution, idea can be used with Tor, without Tor, any VPN 
connection, any connection, protocol with and without anonymization and 
protects against any correlation of activity. It can offer several 
layers of security and obfuscation. The obfuscation can be done very 
simple or highly complex, depending on the users, organizations 
threadmodell, endpoint, connection to the net, platform and hardware.
It would be possible to fake fingerprints to fool automatic government 
analytics and make them think you are person X, while you are not and 
your traffic only looks like traffic from person X.


It is possible to build the solution via software or via hardware.
Software hardware combination is possible to increase the security and 
separate attack vectors to different layers, endpoints, devices.


I am looking for people, developers, companies that would be interested 
in using or developing such a solution, planning a commercial high price 
launch on the market, licensed will be current revisions. Older 
revisions with less features or security will be released under an open 
source license. If this is impossible I am open minded to release the 
idea confidentially to a trustworthy developer group of an open source 
project to let them develop it and make it available as FLOSS completely 
for everyone. It needs to be built before privacy is dead, with or 
without earning money. It needs to be enforced before we will loose 
privacy forever.


Governments, police, politicians will be excluded via license in any case.
Companies against privacy will be excluded via license in any case.
Licensed users will get the current solution to refinance the freemium, 
F(L)OSS model. It is my desire to reinvest most of the profit back to 
linux, projects, social projects and supporting people with tech ideas. 
The greatest part needs to be used to buy and support privacy for the 
society.


Curious about everyones opinion regarding this.

I am not interested in contact with officials from police, spy agencies, 
agencies, governments, any officials of a countries government, fake 
companies like Crypto AG, privacy hating companies, radical people, 
harmful people without necessity to self defend, people not respecting 
the integrity of people, people not respecting countries or their land 
boundaries, people who have no fundamental values like respect, 
integrity, trustworthyness, self confidence and similar, people who 
prefer chatcontrol, client side scanning, metadata correlation, metadata 
aggregation, telemetry, telemetry diagnostics, crash reports without 
full user opt-in, big data analytics without users having fully 
opted-in, push services, any official or inofficial surveillance program 
workers, people who worked actively on it or on supporting it, agency 
analysts.

Re: stopping mass surveillance

[operation . privacyenforcement]

On 1/9/84 19:84, Timothy M Butterworth wrote something which will never 
be deleted again by the all seeing eye, selector match found



Any commercial VPN service provider provides the same level of protection
as Tor.


No, it does not.

Commercial VPN providers with no-log policy often had logs they handed 
out to the authorities. The authorities are acting on the laws in their 
jurisdiction. They do not care about moral or fundamental rights.


Commercial VPNs often lack multi-hop support.

Commercial VPNs do not apply a workaround to avoid RDRAND, RDSEED 
instructions of the CPU like Tor does.


Commercial VPNs can be run by governments or agencies, infiltrated by 
agencies more easily, are provided mostly by only one company. On Tor 
you need to be routed through 3 bad nodes to be busted.

Circuit sets (and providers) are random, VPN multihops do not need to be.

Commercial VPNs are lacking the .onion part of Tor.

Commercial VPNs can be used to consolidate users traffic at one provider 
or instance, jurisdiction, e.g. IP protection of Safari, iCloud+ relay, 
Google One are deployed to force users traffic through servers under US 
jurisdiction control because their hoster headquarters are under US 
jurisdiction.


Commercial VPNs can be used to apply agency selectors more specificly to 
a region, household, country, area of a country, income bracket if run 
by agencies or governments.


Commercial VPNs can be used to run statistical analytics or intercept 
traffic of their "specially interesting" users.


Commercial VPNs can be used to integrate their targets into the 
providers LAN as a target.


Using VPNs or Tor does not protect against traffic correlation attacks.


Bulk data collection is immoral and unethical. Back in 2006 I found that
the USA was hosting photo shopped child porn. They used a JavaScript
vulnerability to create a backdoor on the visiting PC. Their hack only
worked if the user's account has admin privileges. Never surf the web on
windows using an account with admin privileges. The last time I checked on
the vulnerability was in 2010 and it was still not fixed even though it was
well known. I personally believe that the federal government was not
letting MS fix the vulnerability because they were using it as a back door
for data collection. 2006 is when I first moved to GNU/Linux with SUSE
Enterprise Linux Desktop SLED 10. By 2011 I no longer used Windows on my
personal systems so I stopped tracking the vulnerability. I can guess that
it is probably still not fixed.


Governments treat security vulnerabilities as doors and not as holes to 
fix. They are willing to risk any critical infrastructure, company, 
device, society member to apply surveillance.
If security vulnerabilites are used by bad guys the government will use 
it to scream for more protection, meaning more surveillance to protect 
society against bad guys. win-win business regards surveillance.


If you read about Intel Management Engine and AMD PSP it is much worse 
if you consider it is a backdoor.

-integration into system components via kernel modules
-integration into system through user space application, e.g. Windows 
Intel Management system packages

-integration of PAVP and HDCP via Intel Me (serial tracing?)
-KVM access
-network stack of UEFI
-iAMT
-direct and silent CPU, RAM access
-full remote manageability
-anti theft
-outbreak containment heuristic
-TLS
-IPV6
-autoshutdown after 30 minutes if ME is broken
-government agency HAP bit to disable it for high assurance platforms
-uefi integration, only the UEFI GUI for ME can be disabled. Not the ME 
function itself

-full access to storage without the OS or antimalware scanners knowledge

Tech is completely broken if you are a normal society member and not 
some of the more important people.

It is built to deploy surveillance, profit and stimulate user activity.


The USA does not have a constitutional right to privacy from the
government. The only thing that comes close is the constitutional right
requiring a warrant for search and seizure of documents and property.

Iceland has a constitutional right to privacy. I don't know if there is a
VPN company running in Iceland but if there is that would be the one I
would get. https://ctemplar.com/icelandic-privacy-laws/ It would be nice if
the UN would push to follow Iceland's example.



It is important the company is not under any jurisdiction which is 
against fundamental rights or privacy. Companies are required to 
cooperate if under pressure. If they not comply they will be shutdown.

Iceland protects Facebook nasty practices.

Re: wget et ping refusent d'utiliser l'adresse source spécifiée

[Erwann Le Bras]

bonsoir

il ne manquerait pas une route pour utiliser l'interface en 10.90.90 
pour joindre spécifiquement ce sous-réseau?


Ta route par défaut doit indiquer d'utiliser la mauvaise interface 
réseau, d'où l'échec du ping.


Le 12/12/2022 à 18:07, Olivier a écrit :

Bonjour,

J'ai une machine distante sous Stretch indirectement connectée à un
nouveau commutateur DLink de la façon suivante:
Serveur - Switch Mikrotik - Switch DLink

Comme chacun sait, les nouveaux commutateurs DLink sont livrés avec
une IP par défaut égale à 10.90.90.90/8.

Afin de configurer ce switch pour la première fois, j'ai attribué à
mon serveur l'IP 10.90.90.91/24 à l'unique interface Ethernet  de mon
serveur (avec la commande ip addr add 10.90.90.91/8 dev eno1).

À ma grande surprise, chaque ping depuis le serveur vers le nouveau
commutateur, avec la commande ping -c1 -I 10.90.90.91 10.90.90.90,
échoue (pas de réponse)

J'ai pourtant utilisé des dizaines et des dizaines de fois l'option -I
de ping permettant de spécifier l'adresse ou l'interface source
utilisée lors du ping.

Avec la commande tshark, j'ai:

# tshark -f 'ip host 10.90.90.90' -i eno1
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eno1'
 1 0.0 192.168.1.24→ 10.90.90.90  ICMP 98 Echo (ping)
request  id=0x15e9, seq=1/256, ttl=64

Ceci me laisse penser que l'option -I est ignorée puisque le serveur
semble émettre avec son adresse par défaut 192.168.1.24.

En utilisant une commande wget --bind-address 10.90.90.91
http://10.90.90.90, tshark indique une IP source en 192.168.1.24 et
non en 10.90.90.91, comme demandé.

En attribuant une autre adresse du réseau 10.0.0.0/8 au switch
Mikrotik, le ping de celui-ci vers 10.90.90.90 réussit, ce qui me
confirme que le switch DLink répond.

Une piste ?

Slts

Re: How to investigate sudden shutdown?

[David Wright]

On Thu 15 Dec 2022 at 16:12:32 (+0100), Tobias Diekershoff wrote:
> 
> > > perhaps someone of you can help me with tool / log file I have not 
> > > investigated
> > > so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma 
> > > as main
> > > desktop environment and from time to time it just turn off without prior
> > > indication to do so.
> >
> > How old is the machine?
> 
> About 5 years

Ridiculously considered quite old for a laptop (mine are 5, 9 and 18).

> > Spinning rust or SSD?
> 
> SSD
> 
> > How have the battery and power handling been performing recently?
> 
> Well, no problems there.
> 
> > What type of connector is used for the AC power adapter?
> 
> It's a German Schuko connector.

Actually I meant the other end. Mine have three different types. The
newest has USB-C. They aren't the most reliably mechanically seated.
That machine was retired from business work on account of the HDMI
socket being unreliable, but all the sockets are as bad now.

The middle one got its power through the pseudo-USB-A connector
used for a while by Lenovo. It now has to run with the weight of
the machine trapping the power cable underneath, keeping just
the right torsion on the connector.

The only one that has a reliable connector is the oldest, which uses
the age-old coaxial barrel connector. The battery is dead, but this
is the only one of the three laptops that can be used on the lap.

> > > It it not particular warm before and journalctl / dmsg logs are looking
> > > unsuspicious around these sudden shutdowns for me.
> > >
> > > Any pointer what else could be investigated (and I do realize that these 
> > > are
> > > very vague symptoms) would be appreciated!
> >
> > Do shutdowns occur only on AC, or only on battery, or both?
> 
> Both, though the notebook runs on AC most of the time.
> 
> > Do the shutdowns coincide with moments of high load?
> 
> Not that I remember.
> 
> > Do they occur when you adjust the angle of the screen?
> 
> No.

My deceased 2008 Dell would sometimes power off when the screen
was adjusted. Eventually the screen would blank a few seconds
after power-on, unless the machine had been left for a week or so
without power, when the screen might stay lit for a minute or two.

> > Do they occur when the machine is mechanically undisturbed,
> > ie when it's sitting on a table?
> 
> Yes

Not much of a hint, from these replies, of what's causing your
problem. (I'm assuming that the symptom is sudden total power
loss, just like pulling the power plug out of a desktop PC.)

Cheers,
David.

Re: testing update of firefox (to firefox_108.0-1) may not work

[Brad Rogers]

On Thu, 15 Dec 2022 08:49:07 -0500
songbird  wrote:

Hello songbird,

>  thank you for pointing that out.

NP.  I do similar things - i.e. set stuff up in a non-conventional way,
then forget about it.   Then I can't understand why people don't see
what I see.  When light dawns, and I realise it's *my* fault, there's an
embarrassed shuffling of feet - metaphorically speaking.   :-)

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
It's not your heart, it's your bank I want to break
It's Yer Money - Wonder Stuff


pgpExcr6Heinn.pgp
Description: OpenPGP digital signature

Aw: Re: How to investigate sudden shutdown?

[Tobias Diekershoff]

Hey Alexander!

> > perhaps someone of you can help me with tool / log file I have not 
> > investigated
> > so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as 
> > main
> > desktop environment and from time to time it just turn off without prior
> > indication to do so.
> 
> Does it power off unexpectedly while you actively working on it, or you just 
> see it powered off when you check it after a while?

Yes to both.

> These kinds of symptoms are hard to diagnose and usually indicate a hardware 
> problem.
> Please, give us more information about your laptop. You can use "inxi" 
> utility for that:
>     # inxi -a -v8 -z -za
> 
> You can send the output from "inxi" to paste service[1] and provide us with 
> just a link to it in next mail.

Here is the output
https://paste.debian.net/hidden/b7901559/

> Is laptop's battery(-ies) in good shape, i.e. it can sustain laptop at least 
> for a few minutes with PSU disconnected?

Yes, the batteries last for at least 3-4 hours still.

> If battery is dead, disconnect the battery and try to reproduce the issue 
> with only PSU connected.
>  
> > It it not particular warm before and journalctl / dmsg logs are looking
> > unsuspicious around these sudden shutdowns for me.
> > 
> > Any pointer what else could be investigated (and I do realize that these are
> > very vague symptoms) would be appreciated!
> A good place to start is to check journald logs for previous boot:
>     # journalctl --boot -1

Thanks for that hint, I'll have a look when the shutdown happens next time. 
Right now I don't have the time to figure out which last boot process was the 
last that failed ;-)
  Tobias

Re: Debian failed

[Andrew M.A. Cater]

On Thu, Dec 15, 2022 at 06:25:35AM -0500, Dan Ritter wrote:
> hw wrote: 
> > On Sat, 2022-12-10 at 23:05 -0600, David Wright wrote:
> > > On Sun 11 Dec 2022 at 04:39:02 (+0100), hw wrote:
> > > > 
> > > > How can Debian be so old?
> > > 
> > > Maturity takes a little ageing.
> > 
> > Then Debian needs to figure out how to become sufficiently mature
> > without becoming outdated.
> > 

Further to what Dan said:

A release cycle starts as soon as a new stable release is made.
What was testing becomes stable: a new testing is forked.

The stable release remains supported and bug fixed for an average of three
years. Security fixes are fixed, some fixes are backported, some fast-moving
packages - like Firefox - get updated in the course of the release as 
upstream removes support for older versions.

Testing has two or so years to develop on average before release. The final
choice of kernel is normally one that is LTS by the upstream kernel 
developers.

Nvidia and other video card manufacturers: most require workarounds.
Nvidia requires more than most - that's the way of it. The Nouveau
drivers are improving but many people want and need the proprietary
drivers. That carries with it the need to use dkms, potentially, and to
sacrifice secure boot.

We do provide more up to date kernels in debian-backports and more up to date
firmware where we can. 

Stability _is_ paramount: that's why Stable changes relatively rarely and
almost always to provide major fixes (or to remove packages we can no longer
support for whatever reason).

Testing is testing - and should always be installable.

Sid is permanently unstable - is not intended as a current release version:
if it breaks, you get to keep both pieces :) Unless you are experienced and
can fix package conflicts / groups of packages being uninstallable for a while
no one should contemplate daily use of Sid.

Codenames are good: they follow the release from testing -> stable -> 
oldstable -> oldoldstable. using the code names means that you don't 
get nasty surprises round release day as things slip under you.

There are always trade-offs: there's a reason that Linux takes longer
to support brand new hardware than Windows, potentially. Linux allows
you to use older hardware for longer in many cases.

With every good wish as ever,

Andy Cater

> > How is this working anyway?  Debian waits like 2 years or longer to
> > become mature while the rest of the world has already moved on to more
> > recent (versions of the same) software which has the bugs now fixed
> > Debian is still struggling with?  Or is Debian fixing the bugs in
> > outdated versions in order to continue to use those for some reason?
> 
> If an upstream project makes changes that fix bugs, and the bugs
> are important, Debian will apply those changes if possible. If
> the upstream project makes those bug-fix changes in a way which
> changes other behaviors, Debian will avoid those changes.
> 
> 
> That's "stable". You should be able to build on it without
> having APIs or command line arguments change underneath you.
> 
> 
> Meanwhile, a new stable version is being created, and exposed to
> people who want to work on it in two releases:
> 
> unstable is not a real release. It's a repository to hold
> packages that are being worked on. Every so often, someone
> decides to rely on a package in unstable because it has a
> feature that they want. They often regret it. unstable is for
> developers, and it is not for their main machine.
> 
> testing is almost a real release, but it is never quite there
> except in the months leading up to it being frozen as the new
> stable. testing has packages that have met a minimal set of
> criteria to be promoted out of unstable. It has not been tested,
> it is in the process of testing.
> 
> If you can stand the occasional failure, a person might use
> testing for some things. It's not a good idea to run production
> on it.
> 
> -dsr-
> 

Re: Conseils sur PXE pour l'installation de serveurs

[Olivier]

J'ai pu initialiser ce matin, ma première machine en utilisant PXE et preseed.
La seule action qu'il me reste à faire au clavier est de sélectionner
l'option PXE/Pressed que j'ai ajoutée à celles de l'installeur Debian
: presque tout le reste est choisi automatiquement sans action de ma
part.

1. Objectivement, la seule chose qui me gêne maintenant est le partitionnement.

J'ai supposé n'avoir à chaque qu'un unique disque, utiliser en totalité.
Je le partitionne avec LVM, en swap, /root, /usr, /var, /home et /tmp
en utilisant l'algo par défaut de l'installeur.
Le seul point qui me gène dans cette procédure est que la taille de
/var est nettement plus petite que celle de /home.
Pour des serveurs, j'ai très souvent eu besoin d'avoir des partitions
/home et /var de même taille.

Pour palier à cette limitation, j'ai une clé system-rescue avec
laquelle je sais importer et exécuter un programme qui église les
tailles de /home et /var (ie qui diminue /home au profit de /var).

Idéalement, je préférerai remplacer l'utilisation de  system-rescue
par des paramètres dans mon fichier preseed.

2. Autre point à améliorer

J'aimerai avoir une procédure rigoureuse pour identifier les firmwares
qui manquent.
Aujourd'hui, je vais parcourir rapidement le contenu de dmesg mais
c'est fastidieux.


Le sam. 10 déc. 2022 à 21:15, Erwann Le Bras
 a écrit :
>
> bonsoir
>
> à mon sens, c'est une très bonne idée d'utiliser un serveur PXE pour des 
> installations car cela évite de s’embêter avec un jeu de CD ou de clé USB.
> Enfin, si le client le permet. A part des modèles antediliviens, tous savent 
> démarrer en PXE.
>
> PXE sert pour l'amorçage ; une fois démarré, on se retrouve comme si on avait 
> démarré sur une clé USB ou sur un CD. D'ailleurs, PXE permet de télécharger, 
> monter et booter directement sur un ISO (mais attention à sa taille il est 
> téléchargé et monté en RAM).
>
> Le client a tout ce qu'il faut en natif pour rechercher et booter sur un 
> serveur PXE présent.
>
> Le serveur PXE présente au client un menu (pour choisir le système à 
> démarrer) ou a des consignes pour que le client télécharge directement une 
> amorce, par TFTP, HTTP ou NFS le plus souvent.
>
> Une fois cette amorce chargé, le reste du démarrage continue comme pour un CD 
> ; donc oui, à mon sens, il est possible de faire tout ce que le démarrage  
> "standard" prévoit.
>
> Debian propose un kit d'install prévu pour être démarré par PXE. Il suffit de 
> le télécharger et d'indiquer au serveur de démarrer dessus.
> On les trouve par exemple sur 
> https://pkgmaster.devuan.org/devuan/dists/beowulf/main/installer/current/images/netboot
>
> amuse-toi bien
>
> Erwann
>
> Le 08/12/2022 à 18:19, Olivier a écrit :
>
> Bonjour,
>
> Je souhaite me lancer dans l'utilisation du PXE pour initialiser des
> serveurs x86 classiques le permettant.
>
> Actuellement, j'initialise ces serveurs en utilisant une clé USB sur
> laquelle j'ai copié un fichier ISO comme celui en [1].
>
> Pour l'initialisation par PXE, j'ai compris qu'il fallait utiliser un
> fichier du type netboot.tar.gz à la place de ces fichiers ISO.
>
> 1. Existe-t-il de tels fichiers netboot.tar.gz incluant aussi les
> firmware exotiques pour le cas où le serveur en aurait besoin ?
>
> 2. Beaucoup de machines savent démarrer en mode EFI ou en mode Legacy.
> C'est souvent configurable au niveau du BIOS.
> Je n'ai pas de connaissance des enjeux liés à ce choix.
> Quels sont-ils ?
>  Y a-t-il des précautions particulières à prendre à cet égard (en
> sélectionnant via le BIOS, le mode EFI ou Legacy) ou bien on ne risque
> pas grand chose à laisser le hasard faire les choses (ie on prépare le
> serveur PXE pour qu'il sache répondre à tout type de demande (EFI,
> ...) ?
>
> 3. J'ai l'habitude de fournir un fichier preseed.cfg volontairement
> incomplet quand j'installe par clé USB. Les réponses non renseignées
> dans le fichier preseed.cfg sont demandées à l'écran.
> A-t-on toujours cette possibilité avec PXE ou bien faut-il
> impérativement répondre à toutes les questions.
>
> 4. Il m'est arrivé (rarement, heureusement) de rencontrer des serveurs
> NUC dont l'interface réseau était mal supportée par Stretch.
> Est-il possible de lancer une initialisation par PXE sur un adaptateur
> réseau externe (sur port USB) (je n'ai jamais vu ce type d'option mais
> sait-on jamais)
>
> [1] 
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.5.0+nonfree/multi-arch/iso-cd/firmware-11.5.0-amd64-i386-netinst.iso
>
> Slts
>

Aw: Re: How to investigate sudden shutdown?

[Tobias Diekershoff]

Hey David!

> > perhaps someone of you can help me with tool / log file I have not 
> > investigated
> > so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma as 
> > main
> > desktop environment and from time to time it just turn off without prior
> > indication to do so.
>
> How old is the machine?

About 5 years

> Spinning rust or SSD?

SSD

> How have the battery and power handling been performing recently?

Well, no problems there.

> What type of connector is used for the AC power adapter?

It's a German Schuko connector.

> > It it not particular warm before and journalctl / dmsg logs are looking
> > unsuspicious around these sudden shutdowns for me.
> >
> > Any pointer what else could be investigated (and I do realize that these are
> > very vague symptoms) would be appreciated!
>
> Do shutdowns occur only on AC, or only on battery, or both?

Both, though the notebook runs on AC most of the time.

> Do the shutdowns coincide with moments of high load?

Not that I remember.

> Do they occur when you adjust the angle of the screen?

No.

> Do they occur when the machine is mechanically undisturbed,
> ie when it's sitting on a table?

Yes

Thanks!
  Tobias

Aw: Re: How to investigate sudden shutdown?

[Tobias Diekershoff]

 Gesendet: Mittwoch, 14. Dezember 2022 um 10:00 Uhr

> On Wed, Dec 14, 2022 at 01:40:06PM +0500, Alexander V. Makartsev wrote:
> > On 14.12.2022 12:22, Tobias Diekershoff wrote:
> > > Hey everyone,
> > >
> > > perhaps someone of you can help me with tool / log file I have not 
> > > investigated
> > > so far. I have a Thinkpad with Debian Bullseye on it, running KDE/Plasma 
> > > as main
> > > desktop environment and from time to time it just turn off without prior
> > > indication to do so.
> > Does it power off unexpectedly while you actively working on it, or you just
> > see it powered off when you check it after a while?
> 
> As another avenue: have you tried to run something else (e.g. memtest) on the
> machine for a while?

Good thought! I had almost forgot about memtest... will try that when there is 
some
time to spare to have it running for a while.

Thanks!
  Tobias

Re: testing update of firefox (to firefox_108.0-1) may not work

[songbird]

Brad Rogers wrote:
...
> songbird's subject is ambiguous;
> Could mean "testing repo..."
> Could mean "I am testing v108"
>
> AFAICS the issue only affects sid, since Firefox only exists there never
> anywhere else.  Only firefox-esr is migrated out of sid.  Now, that's not
> to say the bad version couldn't be migrated to -esr, but that seems
> unlikely.
>
> ff-esr in testing isn't at 108, only 102.  Therefore, my guess is that
> songbird meant the second of the two options for subject meaning.
>
> Finally, the second option can be sub-divided into;
> "...v108 from sid"
> or
> "...v108 from the Mozilla web site"

  arg!  i normally run testing but i do pull in firefox from
sid.

  thank you for pointing that out.


  songbird  (hits self with wet noodle 12 times
 (morale improves
 (stops flogging

Re: Debian failed

[Dan Ritter]

hw wrote: 
> On Sat, 2022-12-10 at 23:05 -0600, David Wright wrote:
> > On Sun 11 Dec 2022 at 04:39:02 (+0100), hw wrote:
> > > 
> > > How can Debian be so old?
> > 
> > Maturity takes a little ageing.
> 
> Then Debian needs to figure out how to become sufficiently mature
> without becoming outdated.
> 
> How is this working anyway?  Debian waits like 2 years or longer to
> become mature while the rest of the world has already moved on to more
> recent (versions of the same) software which has the bugs now fixed
> Debian is still struggling with?  Or is Debian fixing the bugs in
> outdated versions in order to continue to use those for some reason?

Debian has stable releases. During the life of a stable release:

- programs are updated to fix bugs
- programs are updated to fix security issues
- a very small set of programs is updated because of high
volatility and demand for same:
https://packages.debian.org/bullseye-updates/
- otherwise, programs are not updated.

If an upstream project makes changes that fix bugs, and the bugs
are important, Debian will apply those changes if possible. If
the upstream project makes those bug-fix changes in a way which
changes other behaviors, Debian will avoid those changes.


That's "stable". You should be able to build on it without
having APIs or command line arguments change underneath you.


Meanwhile, a new stable version is being created, and exposed to
people who want to work on it in two releases:

unstable is not a real release. It's a repository to hold
packages that are being worked on. Every so often, someone
decides to rely on a package in unstable because it has a
feature that they want. They often regret it. unstable is for
developers, and it is not for their main machine.

testing is almost a real release, but it is never quite there
except in the months leading up to it being frozen as the new
stable. testing has packages that have met a minimal set of
criteria to be promoted out of unstable. It has not been tested,
it is in the process of testing.

If you can stand the occasional failure, a person might use
testing for some things. It's not a good idea to run production
on it.

-dsr-

Re: markdown, logo en JPG via pandoc naar PDF

[Gijs Hillenius]

[...] enorme knip

> Waarschijnlijk is het beter om alle, echte alle pandoc compomenten
> van de verschillende gebruikte system te vergelijken en dan recht
> trekken.  (En dan zorgen dat ze qua versie gelijk blijven.)

Ja, zoiets zal het zijn.

Die collega is juist bezig om via Nix af te dwingen dat de gebruikte
software identiek is, of je de markdown nou voorbereidt op deze of een
andere Linux machine.

Ik heb een reserve-laptop, ook Debian sid; en daar gaat het wel
goed. Beide up-to-date. 

Collega is ergens wel blij met de edge-case. Hij heeft het commando en
de Nix receptuur aangepast, om dit gedonder te voorkomen.

Maar wat het nou veroorzaakt(e), daar ben ik nog niet achter. 

Ik dee op beide machines

dpkg --get-selections >> laptop-[1,2]

en als ik weer tijd vrij heb ga ik met diff kijken of me iets opvalt.

Er zijn daarnaast verschillen in de locales van de twee machines. De
tips van Paul en Rob waren me welkom.

Re: wat zijn de side-effects van LC_ALL="C"

[Wouter Verhelst]

On Fri, Dec 09, 2022 at 08:54:28AM +0100, Gijs Hillenius wrote:
> Hoi!
> 
> Een collega op het werk helpt me met het combineren van super-eenvoudig
> te schrijven serietje van MarkDown regeltjes, die je dan met een enkel
> commando:
> 
> ,
> | nix run git+https://url...dinges-theme/#pandoc-presentation --refresh -- 
> presentation.md 
> `
> 
> omzet in een PDF.
> 
> Het werkt vlekkeloos op zijn machine (100% nix).
> 
> Het werkt bijna vlekkeloos op een VM ingericht met yum (rpm). Daar
> moeten we  dat commando dan beginnen als:
> 
> LC_ALL="C" nix run git

LC_ALL="C" betekent:

Doe alsof er geen vertalingsinfrastructuur bestaat, en zet alle UTF-8 uit.

Debian heeft een C.UTF-8 locale. Heb je die geprobeerd?

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.