RE: Debian Bullseye 64 bits

[Frédéric BOITEUX]

Bonjour,

Je me suis peut-être mal exprimé : Sur une Debian 11 fraîchement installée, si 
on veut renommer les interfaces-réseau, il faut maintenant passer par des 
fichiers XXX.link placés dans /etc/systemd/network/ (c'est systemd qui gère le 
renommage). Voir la page de manuel systemd.link . Mais par défaut, ce 
répertoire est vide et le [nouveau] schéma de nommage s'applique.

Cdlt,
Fred.

-Message d'origine-
De : ajh-valmer  
Envoyé : mardi 17 janvier 2023 23:06
À : debian-user-french@lists.debian.org
Objet : Re: Debian Bullseye 64 bits

Merci pour votre aide,
j'ai résolu les 2 problèmes, Wifi et
"Begin Running /scripts/local-block done".

/etc/systemd/network/*.link :
le répertoire /etc/systemd/network/ est vide...

Re: OpenSSL 3.0 support for Debian11

[David]

On Wed, 18 Jan 2023 at 10:24, Ben Lavender  wrote:

> Stable releases don't always provide the latest software, generally that
> isn't always respectively "stable".
>
> The latest seems to be available via the repositories Debian testing and
> unstable of which you can still run on Debian 11 if you configure it so.

Hi,

Debian 11 is current Debian Stable release.
There's a page on the Debian wiki titled
"Advice For New Users On Not Breaking Their Debian System" [1]

and the very first item of advice there is
"If you're trying to install software that isn't available in the current Debian
Stable release, it's not a good idea to add repositories for other
Debian releases."

So it might be a good idea for anyone considering adding additional software
outside of what is officially packaged for a Debian Stable release to evaluate
the information given on that page regarding different methods of doing so,
and possible consequences.

[1] https://wiki.debian.org/DontBreakDebian

Re: Setting up bindfs mount in LXC container

[Richard Hector]

On 18/01/23 16:38, Max Nikulin wrote:

On 18/01/2023 03:52, Richard Hector wrote:

On 17/01/23 23:52, Max Nikulin wrote:


lxc.idmap = u 0 10 1000
lxc.idmap = u 1000 1000 1

lxc.mount.entry = /home/richard/sitename/doc_root 
srv/sitename/doc_root none bind,optional,create=dir


My goal is not to map container users to host users, but to allow a 
container user (human user) to access a directory as another container 
user (non-human owner of files). This should also be doable for 
multiple human users for the same site.


Do you mean mapping several users (human and service ones) from a single 
container to the same host UID? The approach I suggested works for 1:1 
mapping. Another technique is group permissions and ACLs, but I would 
not call it straightforward. A user may create a file that belongs to 
wrong group or inaccessible by another user.


I'll use more detail :-)

I have a Wordpress site. The directory /srv/sitename/doc_root, and most 
of the directories under it, are owned by user 'sitename'.


PHP runs as 'sitename-run', which has access (via group 'sitename') to 
read all of that, but not write it. Some subdirectories, eg 
.../doc_root/wp-content/uploads, are group-writeable so that it can save 
things there.


An authorised site maintainer, eg me ('richard') (but there may be any 
number of others), needs to be able to write under /srv/sitename, so I 
use bindfs to mount /srv/sitename under /home/richard/sitename, which 
presents it as owned by me, and translates the ownership back to 
'sitename' when I write to it. So each human user sees the site as owned 
by them, but it's all mapped to 'sitename' on the fly.


These users I guess map to host users, but I'm not particularly 
interested in that ... actually I should care more, because it actually 
maps to a real but unrelated user id on the host, which could have bad 
implications - but I think that's a separate issue.


I'm not ignoring the rest of your message; I'll look at that separately :-)

Cheers,
Richard

Re: OpenSSL 3.0 support for Debian11

[tomas]

On Tue, Jan 17, 2023 at 11:23:41PM +, Ben Lavender wrote:
> Stable releases don't always provide the latest software, generally that
> isn't always respectively "stable".

To be more precise, "stable" means "it doesn't change". In general,
no new major versions, especially not libraries (which would imply
a flurry of updates of dependencies).

Of course, security updates, bug fixes, etc. still come in. If an
upstream library only gets an important (e.g.) security update in
a later major version, the maintainer tries hard to backport this
fix.

The result is a "no surprises" upgrade process whithin a stable
release.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Setting up bindfs mount in LXC container

[Max Nikulin]

On 18/01/2023 03:52, Richard Hector wrote:

On 17/01/23 23:52, Max Nikulin wrote:


lxc.idmap = u 0 10 1000
lxc.idmap = u 1000 1000 1

lxc.mount.entry = /home/richard/sitename/doc_root 
srv/sitename/doc_root none bind,optional,create=dir


My goal is not to map container users to host users, but to allow a 
container user (human user) to access a directory as another container 
user (non-human owner of files). This should also be doable for multiple 
human users for the same site.


Do you mean mapping several users (human and service ones) from a single 
container to the same host UID? The approach I suggested works for 1:1 
mapping. Another technique is group permissions and ACLs, but I would 
not call it straightforward. A user may create a file that belongs to 
wrong group or inaccessible by another user.



I would look into lxcfs hook for inspiration


Interesting; will do. Not sure exactly where to start, but will get there.


/usr/share/lxcfs/lxc.mount.hook (lxcfs package)


lxc-device -n ${LXC_NAME} add /dev/fuse


Is there any reason why it can not be done using lxc.mount.entry in 
the container config?


Is that usable for adding a device file? The only way I found to do that 
is using lxc-device from outside the container. mknod inside doesn't work.


I use it to pass /dev/dri and /dev/video0 to a container. The only issue 
is that the webcam is a USB device, so permissions become wrong after 
suspend to RAM and the following resume.



lxc-attach -n ${LXC_NAME} /usr/local/bin/bindfs_mount


I would consider adding a systemd unit inside container. Unsure if 
could be done using an udev rule.


That might be better, but it does need to rely on the device existing 
first.


I see no difference since in your approach device presence is ensured by 
a hook. With a lxc.mount.entry it should be even more reliable.


So even for running stuff manually, run it from systemd? Interesting, 
will investigate further. I wasn't aware of systemd-run.


I use unprivileged containers to experiment with applications packaged 
for other linux distributions or just in relatively isolated 
environment. My experience that even after searching for particular 
errors it is not obvious what should be done to fix it.


Delegate=yes is mandatory for lxc-start. To attach:

systemd-run --user --scope --property=Delegate=yes -- \
lxc-attach --clear-env --keep-var TERM ...

At first I tried --pty instead of --scope for interactive sessions, but 
I noticed some issues as well.


- 
https://discuss.linuxcontainers.org/t/pam-cgfs-how-to-setup-with-cgroup-v2/10741/

  "Pam_cgfs How to setup with cgroup v2?"
- https://github.com/lxc/lxc/issues/3221#issuecomment-648829685
  "Unable to start an unprivileged container on fresh install of Fedora 
31 · Issue #3221 · lxc/lxc"

Re: Running Windows on a VM: getting files from the original Windows host

[David]

On Wed, 18 Jan 2023 at 10:39, Tom Browder  wrote:
> On Tue, Jan 17, 2023 at 10:06 Tom Browder  wrote:

>> In a previous thread you fellow Debianites gave me excellent advice on 
>> running Windows on a VM running on a Debian host. Now I have my shiny new 
>> Debian Silent PC host quietly waiting.
>
> I've followed the instructions from the Debian wiki,

Hi, please provide more information, such as a link.
So that we don't have to guess what you mean by "the instructions".

> fired up virt-manager, and got this warning:
>
> KVM is not available. This may mean the KVM package is not installed
> or the KVM kernel modules are not loaded.

I rarely use KVM so am probably not the best person to reply, but
I have a couple of initial suggestions.

I do not recognise that error message, which might indicate a specific
(possibly kernel package related) issue and fix, if someone recognises it.

In the meantime, a couple of general things you can check and
report on:

Confirm that you have hardware virtualization enabled.
Search the web for instructions how to do that on your hardware.
It might be disabled in your BIOS.

When you have done that, paste your confirmation here.

Check that the output of 'id' command confirms that the
username is in group 'libvirt'. That check must be done in
the GUI, if you intend to use virt-manager.

Note that this preparatory step
  # adduser  libvirt
does not affect any login sessions that  has
created before running that command. If your GUI was running
before you ran that command, you will need to logout of it
and login again.

When you have done that, paste your confirmation here.

In general, if you use the commandline instead of the GUI then you are
more likely to see any error messages, that you could then paste here to
receive further help.

Re: Running Windows on a VM: getting files from the original Windows host

[Tom Browder]

On Tue, Jan 17, 2023 at 17:38 Tom Browder  wrote:
.,,

> I've followed the instructions from the Debian wiki, fired up
> virt-manager, and got this warning:
>
> KVM is not available. This may mean the KVM package is not installed
> or the KVM kernel modules are not loaded.
>

And it seems that's true since it appears to be sluggish on my system.

-Tom

Re: Passwords

[Jeffrey Walton]

On Tue, Jan 17, 2023 at 3:55 AM DdB
 wrote:
>
> Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> > вт, 17 янв. 2023 г. в 11:01, David :
> >> Looking on the internet it says the passwords are stored in /etc/passwd
> >> and /etc/shadow
> >
> >  In /etc/shadow only password's hashes, some data, one-way calculated
> > from password string.
> >
> >> The password string in /etc/shadow looks as if it's encoded, how can I
> >> read this string?
> >
> > You can't.
> Everyone (and their friend) seem to know, how to work around this, which
> apparently is common debian knowledge (which is nice).
>
> But somehow, i feel there could be more caring about avoiding to teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list? - I doubt it.

There's nothing extraordinary in the answers to recover a lost
password. Reiterating them here does not provide additional advantage
to an attacker.

If you don't have physical security on your machine, then you are
already pwn'd. You may not realize it yet, but it's already game over.

Jeff

Cómo elegir entre dos tarjetas gráficas

[Darío]

Hola buenos días!
Tengo una notebook que tiene dos tarjetas gráficas, la integrada y una NVIDIA:
$ inxi -Gx
Graphics:
  Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics 
  vendor: Dell driver: i915 v: kernel bus ID: 00:02.0 
  Device-2: NVIDIA GF119M [NVS 4200M] vendor: Dell driver: nvidia v: 390.157 
  bus ID: 01:00.0 
  Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting 
  unloaded: fbdev,vesa resolution: 1366x768~60Hz 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 3000 (SNB GT2) 
  v: 3.3 Mesa 20.3.5 direct render: Yes 
Mi duda es cómo saber cuál tarjeta está utilizando, según el comando anterior 
infiero que es la integrada.

Mi otra duda es instalar los driver de nvidia:
$ nvidia-detect
Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119M [NVS 4200M] 
[10de:1056] (rev a1)

Checking card:  NVIDIA Corporation GF119M [NVS 4200M] (rev a1)
Your card is only supported up to the 390 legacy drivers series.
It is recommended to install the
nvidia-legacy-390xx-driver
package.
Una vez ya instalada la recomendación, ejecuto el comando:
$ sudo lsmod | grep -i nvidia
nvidia_modeset   1060864  0
nvidia  15888384  1 nvidia_modeset
ipmi_msghandler   118784  2 ipmi_devintf,nvidia
aclaro que antes de instalar el driver no arrajaba ningún resultado, sin 
embargo sigo sin saber cómo hacer que utilice esta tarjeta, si es que no la 
está utilizando ya.

Muchas gracias y saludos!
Darío

Re: Running Windows on a VM: getting files from the original Windows host

[Tom Browder]

On Tue, Jan 17, 2023 at 10:06 Tom Browder  wrote:

> In a previous thread you fellow Debianites gave me excellent advice on
> running Windows on a VM running on a Debian host. Now I have my shiny new
> Debian Silent PC host quietly waiting.


I've followed the instructions from the Debian wiki, fired up virt-manager,
and got this warning:

KVM is not available. This may mean the KVM package is not installed
or the KVM kernel modules are not loaded.

I searched the system (with aptitude) and couldn't find any evident package
missing. I am proceeding just for the experience, but I would appreciate
any suggestions.

Thanks.

-Tom

Re: OpenSSL 3.0 support for Debian11

[Ben Lavender]

Stable releases don't always provide the latest software, generally that 
isn't always respectively "stable".


The latest seems to be available via the repositories Debian testing and 
unstable of which you can still run on Debian 11 if you configure it so.


https://tracker.debian.org/pkg/openssl

On 17/01/2023 14:33, Shaheena Kazi wrote:

Hello Team,

We are using Debian 11 with OpenSSL 1.1.1n
As OpenSSL 1.1.1 series is going EOL on 11th September 2023.

We would like to know if Debian is planning to add OpenSSL 3.0 support 
on Debian 11 any time soon.


Regards,

Re: Debian Bullseye 64 bits

[ajh-valmer]

On Tuesday 17 January 2023 12:18:57 Frédéric MASSOT wrote:
> Le 16/01/2023 à 20:05, ajh-valmer a écrit :
> > J'ai toujours ces messages répétitifs au boot :
> > "Begin Running /scripts/local-block done"
> > que je n'ai pas avec les 2 autres ordinateurs.
> > Quid ?

> Je crois que c'est lié au fichier "/etc/initramfs-tools/conf.d/resume". 
> On met l'UUID du swap pour permettre au système de savoir où il récupère 
> le système après une hibernation.

Merci pour votre aide, 
j'ai résolu les 2 problèmes, Wifi et 
"Begin Running /scripts/local-block done".

/etc/systemd/network/*.link :
le répertoire /etc/systemd/network/ est vide...

Tout semble bien marcher maintenant.

A. Valmer

Re: Setting up bindfs mount in LXC container

[Richard Hector]

On 17/01/23 23:52, Max Nikulin wrote:

On 17/01/2023 04:06, Richard Hector wrote:


I'm using bindfs in my web LXC containers to allow particular users to 
write to their site docroot as the correct user.


I am not familiar with bindfs, so I may miss something important for 
your use case.


First of all I am unsure why you prefer bindfs instead of mapping some 
container users to host users using namespaces. With the following 
configuration 1000 inside a container and on the host is the same UID:


lxc.idmap = u 0 10 1000
lxc.idmap = u 1000 1000 1
lxc.idmap = u 1001 101001 64535
lxc.idmap = g 0 10 1000
lxc.idmap = g 1000 1000 1
lxc.idmap = g 1001 101001 64535

lxc.mount.entry = /home/richard/sitename/doc_root /srv/sitename/doc_root 
none bind,optional,create=dir


Disclaimer - I haven't actually tried any of your suggestions yet.

My goal is not to map container users to host users, but to allow a 
container user (human user) to access a directory as another container 
user (non-human owner of files). This should also be doable for multiple 
human users for the same site.



In /usr/local/bin/fuse.hook:


I would look into lxcfs hook for inspiration


Interesting; will do. Not sure exactly where to start, but will get there.


In /usr/local/bin/fuse.hook.s2:

lxc-device -n ${LXC_NAME} add /dev/fuse


Is there any reason why it can not be done using lxc.mount.entry in the 
container config?


Is that usable for adding a device file? The only way I found to do that 
is using lxc-device from outside the container. mknod inside doesn't work.



lxc-attach -n ${LXC_NAME} /usr/local/bin/bindfs_mount


I would consider adding a systemd unit inside container. Unsure if could 
be done using an udev rule.


That might be better, but it does need to rely on the device existing first.

If I don't use the at job, but run those commands manually after boot, 
it works fine with no error messages.


Unsure if it is relevant, but it is better to run lxc-start and 
lxc-attach as a systemd unit with Delegate=yes configuration, either a 
temporary one (systemd-run) or configured as a service. It ensures 
proper cgroup and scope. Otherwise some cryptic errors may happen.


So even for running stuff manually, run it from systemd? Interesting, 
will investigate further. I wasn't aware of systemd-run.


Thanks,
Richard

Re: Passwords

[gene heskett]

On 1/17/23 01:01, David wrote:

Morning All,

I have forgotten my password to a Debian PC using an SD stick as it's
main drive.

Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow

The password string in /etc/shadow looks as if it's encoded, how can I
read this string?

David.

.
TBH, you can't, its a one way hash, add a "single" to the grub boot line 
which should give you a text shell, from which you can set a new root 
pw. Make it hard for the hackers, minimum 20 characters, every character 
you add, multiplies the effort they have to use to find it.


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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Debian Bullseye 64 bits

[l0f4r0]

Bonjour,

16 janv. 2023, 20:05 de awache...@gmail.com:

> J'ai toujours ces messages répétitifs au boot :
> "Begin Running /scripts/local-block done"
> que je n'ai pas avec les 2 autres ordinateurs.
> Quid ?
>
Que donne la lecture des liens précédemment transmis ?

l0f4r0

Re: Plantages Xorg sur Bookworm

[Basile Starynkevitch]

On 17/01/2023 15:26, Thierry wrote:

Bonjour

J'ai toujours un comportement étrange de la session graphique sur 
Bookworm.


Constat: aléatoirement, clavier et souris partent en vrille. Par 
exemple, je peux bouger la souris, mais le click ne donne rien. Au 
clavier certaines touches sont inopérantes, d'autres affichent autre 
chose (ex: le t affiche un :).


Pour débloquer, je lance une session non graphique (Ctrl Alt F1) et je 
reviens (Ctrl Alt F7) et çà repart..


Dans le log Xorg, je vois les lignes suivantes:

19411.561] (II) event2  - Power Button: device removed
[ 19411.710] (II) event3  - Video Bus: device removed
[ 19411.755] (II) event1  - Power Button: device removed
[ 19411.770] (II) event4  - MOSART Semi. 2.4G Wireless Mouse: device 
removed

[ 19411.803] (II) event0  - AT Translated Set 2 keyboard: device removed
[ 19412.252] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 19414.029] (II) AIGLX: Resuming AIGLX clients after VT switch

Une idée de la cause du problème?



Non, mais peut-être que l'utilitaire xev (probablement dans le paquet 
/x11-utils/) pourrait vous aider à le comprendre.



Bonne année à tous.


PS. Je cherche des gens intéressés par le projet logiciel libre 
/RefPerSys/ en http://refpersys.org/  .



--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Passwords

[Joe]

On Tue, 17 Jan 2023 15:02:03 +0100
steve  wrote:

> Le 17-01-2023, à 08:07:02 -0500, Greg Wooledge a écrit :
> 
>
> >
> >If you went in via a Live CD, and mounted the Debian root partition,
> >the next step is to chroot into the Debian root partition.  Then you
> >can run "passwd root" in the chroot shell.  Then exit from the shell,
> >and unmount the Debian partition.  
> 
> chroot can be tricky for newcommers…
> 

No harder than the easy first bit of an installation (i.e. language,
keyboard etc.)

About two or three minutes gets you to the point where you can select a
root drive and chroot into it, all the mounting details handled for you.

-- 
Joe

Running Windows on a VM: getting files from the original Windows host

[Tom Browder]

In a previous thread you fellow Debianites gave me excellent advice on
running Windows on a VM running on a Debian host. Now I have my shiny new
Debian Silent PC host quietly waiting.

I intend to try to copy data from the old Win box via the network but, if
that doesn't work, can I do this:

Take the SSD from the old Win box, mount it in a hot-swap slot on the
Debian host, and use it with the freshly-installed Windows VM? The Win SSD
has two drives defined: C: and D: with my important data on the D: drive.

Thanks.

-Tom

Re: Bitlbee user

[Greg Wooledge]

On Tue, Jan 17, 2023 at 10:10:50AM -0500, The Wanderer wrote:
> On 2023-01-17 at 09:49, Richmond wrote:
> 
> > Why is there a user called bitlbee on my system (nologin) when
> > bitlbee is not installed?
> > 
> > Also there is a user saned but sane is not installed.
> 
> At a guess: because those packages were installed at some point in the
> past.
> 
> Typically, when a package creates a user for its programs to run as,
> that user is not removed or otherwise cleaned up when the package is
> removed. The reason is that the filesystem may still contain files or
> directories which are owned by that user, and if the user were removed,
> the record of who owned those files or directories would be lost; they
> would show up as owned only by the numeric UID/GID, with no record
> remaining of who those IDs corresponded to.

Even worse: if that UID gets recycled, and assigned to a new user, for
a new package, then the leftover files would suddenly be owned by the
new package's user.

Re: Passwords

[DdB]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

thx everyone for sharing your point of view(s).
I am enjoying that food-for-thought and reconsidering ...

Am 17.01.2023 um 15:05 schrieb to...@tuxteam.de:
>> chroot can be tricky for newcommers…
> That's why passwd is nice to us and has the -R option :)
Whoa! nice one, much easier, in fact.
Much appreciated hint. Thank you
DdB

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEumgd33HMGU/Wk4ZRe3aiXLdoWD0FAmPGu1wACgkQe3aiXLdo
WD1vkBAAifiu2NoiTxD0nWV+zrX0KW8bIcop3VTAyajepFHY8T9FPh78Ol5D7fp8
2WpJYtX5FTchQz/i/Qy5n+yc1gkHP4A0MVpz/3OYJ/dXJ29l6b7rSNY9KDkAa7gB
VkO1COHKe6Oo459IwmsBNhmT49ZzlYj91d0LU3nB71pWKOw/iYVbCjtTZqmpVaGd
amQXGYr/xolDkYrj5RkzE9ReN5q1f8hLGQ4kDSYQqLVKj8+9Qz353KoYcxI1TTFu
NQcybsLQ/KAEHYcEV9o0LxiuPXWPC+tczgXicO6TGcP2LNQ+tvS9fb8IrmD1T49w
zwOAZoePr/eqfXUkfA6yKycTB1OHO2dltQ5CDoVPusIm3MuwfNhSDTJtSzYGdcde
4suGr1r3axHM2dTr/ivXQrxDPvcYcRWWKjXPilxS4MPrLIsAP6BK5xOpFSll7Rka
BSgw67dGLbyGT+ugVjqLm2lzPrc72KWEaFKTm6LLgqfTPynAikiHb4XOY9T6K5iH
f0PznG6xdTn5QA+18dVXRoWr3lLiFroJWHplV6sb+uNlHDuoPazvHLyJZ9vAWiL8
xHaxuaPpgRXSDYjRt7i5EXJCurfAFzhTGSmpOGE/k9IXQ5qdMD9v5xAX6tP2CFEJ
vkrd5dvXkoCO+8dl2jL85WXffLlE44Qp7KM4k5Rx4xFFQpILWbI=
=eIKP
-END PGP SIGNATURE-

Re: Bitlbee user

[The Wanderer]

On 2023-01-17 at 09:49, Richmond wrote:

> Why is there a user called bitlbee on my system (nologin) when
> bitlbee is not installed?
> 
> Also there is a user saned but sane is not installed.

At a guess: because those packages were installed at some point in the
past.

Typically, when a package creates a user for its programs to run as,
that user is not removed or otherwise cleaned up when the package is
removed. The reason is that the filesystem may still contain files or
directories which are owned by that user, and if the user were removed,
the record of who owned those files or directories would be lost; they
would show up as owned only by the numeric UID/GID, with no record
remaining of who those IDs corresponded to.

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

Bitlbee user

[Richmond]

Why is there a user called bitlbee on my system (nologin) when bitlbee
is not installed?

Also there is a user saned but sane is not installed.

Re: OpenSSL 3.0 support for Debian11

[The Wanderer]

On 2023-01-17 at 09:33, Shaheena Kazi wrote:

> Hello Team,
> 
> We are using Debian 11 with OpenSSL 1.1.1n
> As OpenSSL 1.1.1 series is going EOL on 11th September 2023.
> 
> We would like to know if Debian is planning to add OpenSSL 3.0 support on
> Debian 11 any time soon.

While I have no special inside knowledge on the subject:

Debian 11 is, from what I understand, the current stable release.

It is unlikely that such an important package would be updated from one
major version to another within a stable release. It's not entirely
impossible, e,g, via the stable-security repository, but I would not
expect it to happen.

However, we are apparently currently approaching the freeze date for
preparing the next stable release of Debian, which would presumably be
Debian 12. Current Debian testing (which will, following the polishing
process during the freeze period, be released as the new stable)
includes OpenSSL 3.x, so it is nearly certain that that will be included
in the next stable release.

The length of the freeze period varies depending on how long it takes
for things to become ready to release, but my understanding is that it
will typically be four to six months.

Given that 2023-09-11 is a little less than eight months away, I think
that there should be a new stable release - including OpenSSL 3.x - out
before that happens.

However, you probably won't be able to update to that version while
remaining on Debian 11; you will probably need to update to Debian 12 in
order to get it.

-- 
   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: OpenSSL 3.0 support for Debian11

[tomas]

On Tue, Jan 17, 2023 at 08:03:23PM +0530, Shaheena Kazi wrote:
> Hello Team,
> 
> We are using Debian 11 with OpenSSL 1.1.1n
> As OpenSSL 1.1.1 series is going EOL on 11th September 2023.
> 
> We would like to know if Debian is planning to add OpenSSL 3.0 support on
> Debian 11 any time soon.

It seems to be in bookworm. You can search yourself via 
https://packages.debian.org/:

  
https://packages.debian.org/search?keywords=openssl=names=all=all

Cheers
-- 
t


signature.asc
Description: PGP signature

OpenSSL 3.0 support for Debian11

[Shaheena Kazi]

Hello Team,

We are using Debian 11 with OpenSSL 1.1.1n
As OpenSSL 1.1.1 series is going EOL on 11th September 2023.

We would like to know if Debian is planning to add OpenSSL 3.0 support on
Debian 11 any time soon.

Regards,

Re: Passwords

[tomas]

On Tue, Jan 17, 2023 at 03:30:32PM +0100, steve wrote:
> Le 17-01-2023, à 15:05:37 +0100, to...@tuxteam.de a écrit :
> 
> > > chroot can be tricky for newcommers…
> > 
> > That's why passwd is nice to us and has the -R option :)
> 
> Thanks Tomas, didn't know that option. Will go to bed a bit less stupid
> tonight :-)

Alas, as far as I'm concerned, I fear I'm leaking at least as much
wisdom as I try to fill from the top :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Passwords

[steve]

Le 17-01-2023, à 15:05:37 +0100, to...@tuxteam.de a écrit :


chroot can be tricky for newcommers…


That's why passwd is nice to us and has the -R option :)


Thanks Tomas, didn't know that option. Will go to bed a bit less stupid
tonight :-)

Plantages Xorg sur Bookworm

[Thierry]

Bonjour

J'ai toujours un comportement étrange de la session graphique sur Bookworm.

Constat: aléatoirement, clavier et souris partent en vrille. Par 
exemple, je peux bouger la souris, mais le click ne donne rien. Au 
clavier certaines touches sont inopérantes, d'autres affichent autre 
chose (ex: le t affiche un :).


Pour débloquer, je lance une session non graphique (Ctrl Alt F1) et je 
reviens (Ctrl Alt F7) et çà repart..


Dans le log Xorg, je vois les lignes suivantes:

19411.561] (II) event2  - Power Button: device removed
[ 19411.710] (II) event3  - Video Bus: device removed
[ 19411.755] (II) event1  - Power Button: device removed
[ 19411.770] (II) event4  - MOSART Semi. 2.4G Wireless Mouse: device removed
[ 19411.803] (II) event0  - AT Translated Set 2 keyboard: device removed
[ 19412.252] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 19414.029] (II) AIGLX: Resuming AIGLX clients after VT switch

Une idée de la cause du problème?

Pas bloquant, mais pénible à la longue.

Merci

Re: Passwords

[tomas]

On Tue, Jan 17, 2023 at 03:02:03PM +0100, steve wrote:
> Le 17-01-2023, à 08:07:02 -0500, Greg Wooledge a écrit :
> 
> > On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:
> > > Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :

> > If you went in via a Live CD, and mounted the Debian root partition,
> > the next step is to chroot into the Debian root partition [...]

> chroot can be tricky for newcommers…

That's why passwd is nice to us and has the -R option :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Passwords

[steve]

Le 17-01-2023, à 08:07:02 -0500, Greg Wooledge a écrit :


On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:

Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :

> On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:
> > Easier would be to delete the second field in /etc/shadow for root, so there
> > won't be anymore root password (it's empty). You can then create one with 
the
> > 'passwd' command.
>
> If you can edit the /etc/shadow file, you're already root, which means
> you can simply run "passwd root" to set a new password.  You will not
> be prompted for the old password, so there's no need to clear the old
> password hash preemptively.

You're right if you're editing the file in the OS, but not if you have
accessed data from a live-cd, which was what I was thinking. Sorry.


If you went in via a Live CD, and mounted the Debian root partition,
the next step is to chroot into the Debian root partition.  Then you
can run "passwd root" in the chroot shell.  Then exit from the shell,
and unmount the Debian partition.


chroot can be tricky for newcommers…


Of course, your way (which I'm assuming is "mount the Debian root
partition, edit the /debian/etc/shadow file to clear the hash, unmount
it, reboot into Debian, login as root with no password, and run "passwd")
also works, but it's a bit more effort.


Sure but it's pretty straightforward and simple to understand.

Anyway, thanks for the other options, always good to have a refresh :)

Re: pregunta sobre telefon i s.o. offtopic

[Marcfp Gmail]

si si...no dic el contrari!! 


El 14 de gener de 2023 10:13:44 CET, Narcis Garcia  ha 
escrit:
>El què t'he donat són pàgines amb els enllaços clau als sistemes operatius i 
>guies.
>
>Salut.
>
>
>El 14/1/23 a les 8:22, Marcfp Gmail ha escrit:
>> vaig responen sl cos del correu.
>> 
>> El 13 de gener de 2023 15:08:07 CET, Narcis Garcia  
>> ha escrit:
>>> Aquí hi ha algunes referències:
>>> www.gilug.org/mobils
>> 
>> Aquí no hi trobo el model que tinc.
>> 
>>> (el web necessita col·laboracions per a què tornin a funcionar les 
>>> actualitzacions automàtiques)
>> 
>>> 
>>> I aquí una guia antiga:
>>> https://wiki.gilug.org/index.php/Canviar_Android_per_CyanogenMod
>> Gràcies, busco quelcom per a usuaris més inexperts en el tema.
>> La cerca continua.
>>   
>>> 
>>> 
>>> 
>>> El 13/1/23 a les 14:31, Marcfp Riseup ha escrit:
 Bon dia,
 escric aquest correu ja que estic interessat en començar a usar un s.o. 
 lliure en el telefon que disposo.
 El telefon és un xaomi redmi 8 model m1908c3ig. Adjunto imatge.
 Si vull canviar, és per posar un sistema que no sigui tant dependent de 
 google com és android, però alhora també busco que hi puigui instal·lar 
 whatsapp, telegram, matrix, osm, colabora office, un gestor de correu com 
 k9 mail( per dir el que uso), i a banda d'això,també si sabeu d'algun 
 manual per informatics que no hem formatejat mai un telefon .
 Si em falla la imatge, o la instalació, que puc fer??( no vull haverme de 
 comprar un telefon nou per que m'hagi carregat el que tinc ara...)
 Escric aquí ja que he trobat manuals, però abans de fer res, tinc la mala 
 costum de preguntar, ja que no he reinstalat mai un  telefon una imatge 
 que no es la que du.
 Gràcies per tot i perdó per l'offtopic
>>> 
>> 
>
>-- 
>
>Narcis Garcia
>
>__
>I'm using this dedicated address because personal addresses aren't masked 
>enough at this mail public archive. Public archive administrator should fix 
>this against automated addresses collectors.
>

Re: Passwords

[Greg Wooledge]

On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:
> Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :
> 
> > On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:
> > > Easier would be to delete the second field in /etc/shadow for root, so 
> > > there
> > > won't be anymore root password (it's empty). You can then create one with 
> > > the
> > > 'passwd' command.
> > 
> > If you can edit the /etc/shadow file, you're already root, which means
> > you can simply run "passwd root" to set a new password.  You will not
> > be prompted for the old password, so there's no need to clear the old
> > password hash preemptively.
> 
> You're right if you're editing the file in the OS, but not if you have
> accessed data from a live-cd, which was what I was thinking. Sorry.

If you went in via a Live CD, and mounted the Debian root partition,
the next step is to chroot into the Debian root partition.  Then you
can run "passwd root" in the chroot shell.  Then exit from the shell,
and unmount the Debian partition.

Of course, your way (which I'm assuming is "mount the Debian root
partition, edit the /debian/etc/shadow file to clear the hash, unmount
it, reboot into Debian, login as root with no password, and run "passwd")
also works, but it's a bit more effort.

Re: Passwords

[tomas]

On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:
> Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :
> 
> > On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:
> > > Easier would be to delete the second field in /etc/shadow for root, so 
> > > there
> > > won't be anymore root password (it's empty). You can then create one with 
> > > the
> > > 'passwd' command.
> > 
> > If you can edit the /etc/shadow file, you're already root, which means
> > you can simply run "passwd root" to set a new password.  You will not
> > be prompted for the old password, so there's no need to clear the old
> > password hash preemptively.
> 
> You're right if you're editing the file in the OS, but not if you have
> accessed data from a live-cd, which was what I was thinking. Sorry.

Or mounted the disk externally on another system.

Still there's the -R (chroot) option for passwd(1) as an alternative
for those cases. But editing is definitely a valid option (esp. if
you are dealing with an OS you suspect format compatibility problems
because of its age or some such).

There is more than... and so on :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Passwords

[steve]

Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :


On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:

Easier would be to delete the second field in /etc/shadow for root, so there
won't be anymore root password (it's empty). You can then create one with the
'passwd' command.


If you can edit the /etc/shadow file, you're already root, which means
you can simply run "passwd root" to set a new password.  You will not
be prompted for the old password, so there's no need to clear the old
password hash preemptively.


You're right if you're editing the file in the OS, but not if you have
accessed data from a live-cd, which was what I was thinking. Sorry.

Re: I've noticed a general protection fault

[Richmond]

Richmond  writes:

> This occurs during shutdown. I've also noticed occasional delays "a stop
> job is running". These occur when I am using a desktop
> environment. Currently I am using gnome.
>
> kernel: traps: dconf worker[2353] general protection fault
> ip:7fe4564ec4a6 sp:7fe448e31090 error:0 in
> libc-2.31.so[7fe4564d3000+15a000]

5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux

These errors started on 5th January, but kernel 5.10.0-20 has been in
since December 26th.

Debian 11. Gnome.

Re: Passwords

[Greg Wooledge]

On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:
> Easier would be to delete the second field in /etc/shadow for root, so there
> won't be anymore root password (it's empty). You can then create one with the
> 'passwd' command.

If you can edit the /etc/shadow file, you're already root, which means
you can simply run "passwd root" to set a new password.  You will not
be prompted for the old password, so there's no need to clear the old
password hash preemptively.

Re: Passwords

[Greg Wooledge]

On Tue, Jan 17, 2023 at 07:38:28AM +0100, Toni Mas Soler wrote:
> You don't need  a live-usb/cd.
> If your boot system is grub you only have to change command to exec=/bin/bash
> 
> Once you are in your system you can change root password and others.

For the record, the kernel parameter you wanted was "init=/bin/bash".

Re: Passwords

[Jude DaShiell]

pass phrase length and complexity.  At least 16 characters; Starts and
ends with a letter, has two symbols, two numbers two upper-case two
lower-case.  Nothing found in dictionaries in pass phrase no keyboard
walking, no recognizeable keyboard patterns may work for a few seconds.



Jude  "There are four boxes to be used in
defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Tue, 17 Jan 2023, daven...@tuxfamily.org wrote:

> Hello
>
> On 2023-01-17 09:51, DdB wrote:
> > Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> >> ??, 17 ???. 2023 ?. ? 11:01, David :
> >>> Looking on the internet it says the passwords are stored in /etc/passwd
> >>> and /etc/shadow
> >>
> >> In /etc/shadow only password's hashes, some data, one-way calculated
> >> from password string.
> >>
> >>> The password string in /etc/shadow looks as if it's encoded, how can I
> >>> read this string?
> >>
> >> You can't.
> > Everyone (and their friend) seem to know, how to work around this, which
> > apparently is common debian knowledge (which is nice).
> >
> > But somehow, i feel there could be more caring about avoiding to teach
> > future hackers by accident. Is this kind of lesson appropriate for a
> > users list? - I doubt it.
> >
> > just my 2 cents
> > DdB
>
>
> It's not hacking. It's typical administration system stuff. A required
> knowledge so you don't end up locked out of your own system in non-encypted
> installation. It requires physical access to the computer, so applicable from
> distance as you need to either
> - remove then mount the hard drive on another machine.
> - boot from a live USB.
> - boot into GRUB's rescue-shell.
>
> But if you're worried about physical access to your computer (as a laptop than
> can be easily stolen, or left in hotel room, or whatever), an account password
> isn't going to protect your data or from someone alter your password /install
> fishy stuff?
>
> In such case, you need to protect your system by encrypt it. And not just
> encrypt /home as the files you need to protect in order to protect the system
> from password tampering are NOT in /home. Debian installer has an option to
> encrypt the system quite easily, you just need time for the initial
> installation is it spends an good amount of writing random data (m?re or less
> acceptable duration depending on your disk speed and CPU performance). And
> re-ecrypt it when needed/when algorithmes get broken and new better ones
> become the new recommended standard/if your decryption passphrase is known by
> someone else/whatever.
>
> But it only makes sense of your decryption key has a long complex passphase.
> An easily brute-forceable or guessable password for disk encryption defeats
> the very own purpose of disk encryption. It basically means if you forget the
> passphrase, you're pretty much screwed until you either remembrer it, or
> reinstall and reconfigure everything. so you need to have backup [1] in secure
> place.
>
> ---
> 1. But again, backups are required anyway, encrypted installs or not. Storage
> support do fail and/or get stolen. Never trust a single storage device. Or a
> "cloud" backup bullshit. Cloud being nothing else than someone's else computer
> who can do whatever they want on it, kick users whenever they please or abuse
> personal data for profit if they want to (whether they do it in a "legal" or
> semi-legal way or not doesn't matter. As they have the technical means to do
> so and users have no means to check what's going on [2]. Including when data
> is "encrypted" IF encryption and decryption happens on their systems).
> 2. It's already hard enough to know what's going on on one's own computer, let
> alone distant systems managed by someone else?
>
>
>

I've noticed a general protection fault

[Richmond]

This occurs during shutdown. I've also noticed occasional delays "a stop
job is running". These occur when I am using a desktop
environment. Currently I am using gnome.

kernel: traps: dconf worker[2353] general protection fault
ip:7fe4564ec4a6 sp:7fe448e31090 error:0 in
libc-2.31.so[7fe4564d3000+15a000]

Re: Debian Bullseye 64 bits

[Frédéric MASSOT]

Le 16/01/2023 à 20:05, ajh-valmer a écrit :

Bonjour,

J'ai toujours ces messages répétitifs au boot :
"Begin Running /scripts/local-block done"
que je n'ai pas avec les 2 autres ordinateurs.
Quid ?


Je crois que c'est lié au fichier "/etc/initramfs-tools/conf.d/resume". 
On met l'UUID du swap pour permettre au système de savoir où il récupère 
le système après une hibernation.



--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Debian Bullseye 64 bits

[Frédéric MASSOT]

Le 17/01/2023 à 12:18, Frédéric MASSOT a écrit :

Le 16/01/2023 à 20:05, ajh-valmer a écrit :

Bonjour,

J'ai toujours ces messages répétitifs au boot :
"Begin Running /scripts/local-block done"
que je n'ai pas avec les 2 autres ordinateurs.
Quid ?


Je crois que c'est lié au fichier "/etc/initramfs-tools/conf.d/resume". 
On met l'UUID du swap pour permettre au système de savoir où il récupère 
le système après une hibernation.


J'oubliais, après avoir modifié ce fichier, il faut reconstruire 
l'initramfs avec :


sudo update-initramfs -u -k all



--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Setting up bindfs mount in LXC container

[Max Nikulin]

On 17/01/2023 17:52, Max Nikulin wrote:
lxc.mount.entry = /home/richard/sitename/doc_root /srv/sitename/doc_root 
none bind,optional,create=dir


Sorry, path inside the container should be without the leading slash.

lxc.mount.entry = /home/richard/sitename/doc_root srv/sitename/doc_root 
none bind,optional,create=dir

Re: Setting up bindfs mount in LXC container

[Max Nikulin]

On 17/01/2023 04:06, Richard Hector wrote:


I'm using bindfs in my web LXC containers to allow particular users to 
write to their site docroot as the correct user.


I am not familiar with bindfs, so I may miss something important for 
your use case.


First of all I am unsure why you prefer bindfs instead of mapping some 
container users to host users using namespaces. With the following 
configuration 1000 inside a container and on the host is the same UID:


lxc.idmap = u 0 10 1000
lxc.idmap = u 1000 1000 1
lxc.idmap = u 1001 101001 64535
lxc.idmap = g 0 10 1000
lxc.idmap = g 1000 1000 1
lxc.idmap = g 1001 101001 64535

lxc.mount.entry = /home/richard/sitename/doc_root /srv/sitename/doc_root 
none bind,optional,create=dir



In /usr/local/bin/fuse.hook:


I would look into lxcfs hook for inspiration


In /usr/local/bin/fuse.hook.s2:

lxc-device -n ${LXC_NAME} add /dev/fuse


Is there any reason why it can not be done using lxc.mount.entry in the 
container config?



lxc-attach -n ${LXC_NAME} /usr/local/bin/bindfs_mount


I would consider adding a systemd unit inside container. Unsure if could 
be done using an udev rule.


If I don't use the at job, but run those commands manually after boot, 
it works fine with no error messages.


Unsure if it is relevant, but it is better to run lxc-start and 
lxc-attach as a systemd unit with Delegate=yes configuration, either a 
temporary one (systemd-run) or configured as a service. It ensures 
proper cgroup and scope. Otherwise some cryptic errors may happen.

Re: Passwords

[Timothy M Butterworth]

On Tue, Jan 17, 2023 at 1:01 AM David  wrote:

> Morning All,
>
> I have forgotten my password to a Debian PC using an SD stick as it's
> main drive.
>
> Looking on the internet it says the passwords are stored in /etc/passwd
> and /etc/shadow
>
> The password string in /etc/shadow looks as if it's encoded, how can I
> read this string?
>
> David.
>
>
Do you have a root account? If so then log in as root and run `passwd
 `

If you do not have root then you can login using single user mode and set a
root password.
https://devconnected.com/single-user-mode-secure-boot-on-ubuntu-debian/

Tim

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

Re: Passwords

[tomas]

On Tue, Jan 17, 2023 at 09:51:46AM +0100, DdB wrote:

[...]

> Everyone (and their friend) seem to know, how to work around this, which
> apparently is common debian knowledge (which is nice).
> 
> But somehow, i feel there could be more caring about avoiding to teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list? - I doubt it.

You don't improve security by keeping knowledge secret.

On the contraty, only knowing what's possible you can make your
system more secure.

Please, don't advocate for knowledge being reserved to a closed
cast of "priests". Arguably, we're here for making knowledge
available to all.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Passwords

[davenull]

Hello

On 2023-01-17 09:51, DdB wrote:

Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:

вт, 17 янв. 2023 г. в 11:01, David :
Looking on the internet it says the passwords are stored in 
/etc/passwd

and /etc/shadow


 In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can 
I

read this string?


You can't.
Everyone (and their friend) seem to know, how to work around this, 
which

apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

just my 2 cents
DdB



It's not hacking. It's typical administration system stuff. A required 
knowledge so you don't end up locked out of your own system in 
non-encypted installation. It requires physical access to the computer, 
so applicable from distance as you need to either

- remove then mount the hard drive on another machine.
- boot from a live USB.
- boot into GRUB's rescue-shell.

But if you're worried about physical access to your computer (as a 
laptop than can be easily stolen, or left in hotel room, or whatever), 
an account password isn't going to protect your data or from someone 
alter your password /install fishy stuff…


In such case, you need to protect your system by encrypt it. And not 
just encrypt /home as the files you need to protect in order to protect 
the system from password tampering are NOT in /home. Debian installer 
has an option to encrypt the system quite easily, you just need time for 
the initial installation is it spends an good amount of writing random 
data (mère or less acceptable duration depending on your disk speed and 
CPU performance). And re-ecrypt it when needed/when algorithmes get 
broken and new better ones become the new recommended standard/if your 
decryption passphrase is known by someone else/whatever.


But it only makes sense of your decryption key has a long complex 
passphase. An easily brute-forceable or guessable password for disk 
encryption defeats the very own purpose of disk encryption. It basically 
means if you forget the passphrase, you're pretty much screwed until you 
either remembrer it, or reinstall and reconfigure everything. so you 
need to have backup [1] in secure place.


---
1. But again, backups are required anyway, encrypted installs or not. 
Storage support do fail and/or get stolen. Never trust a single storage 
device. Or a "cloud" backup bullshit. Cloud being nothing else than 
someone's else computer who can do whatever they want on it, kick users 
whenever they please or abuse personal data for profit if they want to 
(whether they do it in a "legal" or semi-legal way or not doesn't 
matter. As they have the technical means to do so and users have no 
means to check what's going on [2]. Including when data is "encrypted" 
IF encryption and decryption happens on their systems).
2. It's already hard enough to know what's going on on one's own 
computer, let alone distant systems managed by someone else…

Re: Passwords

[Bastien Durel]

Le mardi 17 janvier 2023 à 09:51 +0100, DdB a écrit :
> Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> Everyone (and their friend) seem to know, how to work around this,
> which
> apparently is common debian knowledge (which is nice).
> 
> But somehow, i feel there could be more caring about avoiding to
> teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list? - I doubt it.

Local user is king. They can change boot-loader, extract disks to put
them in another computer ... Not only Debian-related, much computer-
related ^^

To prevent that, you should encrypt your disks, so no-one can mount
them and change your passwords/read your data. (But you won't recover
for lostt passphrase, then ;))

Regards,

-- 
Bastien

Re: Passwords

[Joe]

On Tue, 17 Jan 2023 09:51:46 +0100
DdB  wrote:

> Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> > вт, 17 янв. 2023 г. в 11:01, David :  
> >> Looking on the internet it says the passwords are stored in
> >> /etc/passwd and /etc/shadow  
> > 
> >  In /etc/shadow only password's hashes, some data, one-way
> > calculated from password string.
> >   
> >> The password string in /etc/shadow looks as if it's encoded, how
> >> can I read this string?  
> > 
> > You can't.  
> Everyone (and their friend) seem to know, how to work around this,
> which apparently is common debian knowledge (which is nice).

It's common Internet knowledge generally. Google will find you a
method, and will also find you a utility to fix a lost password in
Windows, if you can trust it.
> 
> But somehow, i feel there could be more caring about avoiding to teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list? - I doubt it.
>

First rule of security: keep your computer physically secure. If it's
portable, encrypt it, if it isn't, generally don't, because encryption
really is impossible to recover if the key is lost. My laptop isn't
encrypted, but all significant data is stored in a VeraCrypt volume. I
don't care if the machine is booted by a thief, because I'll never see
it again, and I have backup copies of the data.

-- 
Joe

Re: Passwords

[David]

On Tue, 2023-01-17 at 09:51 +0100, DdB wrote:
> Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> > вт, 17 янв. 2023 г. в 11:01, David :
> > > Looking on the internet it says the passwords are stored in
> > > /etc/passwd
> > > and /etc/shadow
> > 
> >  In /etc/shadow only password's hashes, some data, one-way
> > calculated
> > from password string.
> > 
> > > The password string in /etc/shadow looks as if it's encoded, how
> > > can I
> > > read this string?
> > 
> > You can't.
> Everyone (and their friend) seem to know, how to work around this,
> which
> apparently is common debian knowledge (which is nice).
> 
> But somehow, i feel there could be more caring about avoiding to
> teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list? - I doubt it.

For this sort of `cracking', there would need to be direct access to
the machine. It would involve house breaking after having discerned the
address in the other country the target resided in, and travelling
there.
Cheers!

Re: Passwords

[davenull]

Hello

On 2023-01-17 08:58, Tim Woodall wrote:

On Tue, 17 Jan 2023, Stanislav Vlasov wrote:


??, 17 ???. 2023 ?. ? 11:01, David :


I have forgotten my password to a Debian PC using an SD stick as it's
main drive.


Looking on the internet it says the passwords are stored in 
/etc/passwd

and /etc/shadow


In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can 
I

read this string?


You can't.
But you can set new password, if you boot from live-usb/live-cd, mount
your system to dir and run `chroot dir && passwd $user`



One other thing you can do if you don't have a quick and easy way to
boot is to manually replace the hash in /etc/shadow with one that you 
do

know the password for. (This might be the case, for example, where the
USB stick is for booting ARM but all your other machines are x86, 
mount,

change password, umount is much quicker than trying to work out how to
live boot a headless arm system...)


No, don't do that. It's requires to do more steps manually and might 
lead to less security. And you need to make sure to use you use 
cryptographic salt. crypt, the utility used to set passwords stored in 
/etc/shadow, use salts. There is just to many things you could do wrong, 
especially if you use a different tool to henerate the password and 
trust it default settings.


For instance, you might choose (or use by default) the "wrong" 
encryption when you generate the password, which might by less secure 
than the default one. For instance, I just realised after readding this 
thread and checking, Debian 11 now uses yescrypt ($y$ prefix, see 
crypt(5) man entry: `man 5 crypt`). If I replaced the hash manually, I 
would probably used an older encryption algo without realizing it…


You're better off editing /etc/shadow and remove instead of replacing 
the second field, which is the hash with it's encryption identifier 
prefix ($*$) of the salted password. Then boot and log into your 
now-passwordless user account, then set a password again, as you would 
normally normally, using `passwd` command.


IMPORTANT NOTE: Not sure if you need to edit /etc/passwd to remove the 
second field as well, the "x" that indicated a hidden/hashed password is 
used/expected, before rebooting to re-set your password. Last time I did 
that, multiples "debian-stable-versions ago", I remove it "just in case" 
as it doesn't cost anything whether it's necessary or not.




This is something I did in ancient times when most systems still used
crypt and the system I was having problems with was the only one (so
far) that had been converted to use SHA? hashes. I replaced root's 
hash,

which I'd forgotten with that of my user account, which I did know.

And if you don't have any hashes that you know the password for then 
ask

here, someone can generate one for you - or see this thread:

https://unix.stackexchange.com/questions/81240/manually-generate-password-for-etc-shadow

Obviously manually editing these files isn't something to be done
without care. I always have backups so worst case is "restore from
backup" and not "I've lost everything"

Re: Passwords

[Alexander V. Makartsev]

On 17.01.2023 13:51, DdB wrote:

Everyone (and their friend) seem to know, how to work around this, which
apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.
This is not hacking. How to reset password on your computer is the is 
most basic system administration knowledge everyone should know.
This information is described in system administration manual and mostly 
applies for any Linux-based system.


Since it is so easy to reset user password on a computer you have 
physical access to, and it doesn't matter if OS is Windows or Linux-based,
so making your user password so long and complex, to the point it could 
be forgotten, is so not necessary.
Even 4-6 digit password is enough to secure access to local user account 
and impossible to forget.


Long and complex passwords are only necessary for non-local user 
accounts, e.g. Web-sites, e-Mail accounts, or any accounts exposed to 
the Internet.


--
With kindest regards, Alexander.

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

Re: Passwords

[Tixy]

On Tue, 2023-01-17 at 09:51 +0100, DdB wrote:
> 
> But somehow, i feel there could be more caring about avoiding to teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list?

Yes. It's a common occurrence, and trivial to deal with - if you have
physical access to the computer or disk. And if you have such access 
then that password isn't actually protecting anything you couldn't do
without the password.

If you google "linux forgotten root password" then you will find these
techniques are explained all over the web, e.g. Redhat's site, Arch
wiki etc.

-- 
Tixy

 

RE: Debian Bullseye 64 bits : wlan wifi pas possible

[Hugues Larrive]

Bonjour,

--- Original Message ---
Le mardi 17 janvier 2023 à 09:12, Frédéric BOITEUX  
a écrit :


> 

> 

> Bonjour,
> 

> C’est dans la doc d’installation : pour les nouvelles installation de Debian 
> 11, le nommage des interfaces n’est plus géré par udev mais par systemd (avec 
> des noms du genre de wlp2s0, pas forcément bien intuitif). Si on veut les 
> renommer, il faut passer par des fichiers dans /etc/systemd/network/*.link 
> (avec un initrd regéréré avec cette config…).
> 

Pour apporter quelques précisions à ce sujet, on peut trouver toutes les 
explications sur la façon dont systemd renome les interfaces dans une page de 
man systemd.net-naming-scheme.

Si comme moi vous préférez que les interfaces gardent leur nom linux vous 
pouvez ajouter net.ifnames=0 à GRUB_CMDLINE_LINUX_DEFAULT dans 
/etc/default/grub suivi d'un update-grub et si systemd vous "gonfle" il y a 
toujours la possibilité de migrer le système en devuan : 
https://www.devuan.org/os/documentation/install-guides/chimaera/bullseye-to-chimaera

Toutefois il semble qu'il y ait un autre soucis mais je ne comprends pas : si 
ifconfig -a retourne wlp2s0, alors ifup wlp2s0 ne devrait pas retourner 
d'erreur.

Que donne dmesg | grep wlan ?

Quel est le contenu de /etc/network/interfaces ?

Utilisez-vous interfaces + wpa_supplicant pour configurer le wifi ou bien 
network-manager (je crois qu'il y a aussi une 3ème possibilité avec systemd) ?

@+
Hugues


> Cdlt,
> Fred.
> 

> -Message d'origine-
> De : ajh-valmer awache...@gmail.com
> 

> Envoyé : lundi 16 janvier 2023 23:48
> À : debian-user-french@lists.debian.org
> Objet : Re: Debian Bullseye 64 bits : wlan wifi pas possible
> 

> Bonjour,
> 

> Ma connexion réseau fonctionne bien mais qu'en mode filaire Ethernet eth0.
> 

> Par contre, plus de connexion wlan possible :
> J'ai bien modifié le fichier "70-persistent-rules" par eth0 et wlan0, 
> rebooté, "wlp2s0" reste présent dans la commande ifconfig -a , ifup wlan0 ou 
> wlp2s0 : "cannot find wlan0 et wlp2s0"
> (interfaces non reconnues).
> 

> Malgré consultation de nombreux liens sur ce sujet, rien ne fonctionne.
> 

> Merci d'une aide, une piste...
> 

> A. Valmer

publickey - hlarrive@pm.me - 0xE9429B87.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Passwords

[DdB]

Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> вт, 17 янв. 2023 г. в 11:01, David :
>> Looking on the internet it says the passwords are stored in /etc/passwd
>> and /etc/shadow
> 
>  In /etc/shadow only password's hashes, some data, one-way calculated
> from password string.
> 
>> The password string in /etc/shadow looks as if it's encoded, how can I
>> read this string?
> 
> You can't.
Everyone (and their friend) seem to know, how to work around this, which
apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

just my 2 cents
DdB

[was: Debian Bullseye 64 bits] Re: Debian Bullseye 64 bits : wlan wifi pas possible

[didier gaumet]

- ifconfig est remplacé par ip et gère les interfaces filaires

- iwconfig est remplacé par iw et gère les interfaces sans fil: si tu
veux gérer une interface sans fil en CLI par des commandes de bas-
niveau à effet immédiat c'est iw qui est adapté.

- dans le même genre les commandes init et telinit que tu as
mentionnées dans un précédent post sont remplacées (si tu utilises
Systemd ce qui est le cas par défaut sous Debian) par systemctl
start/stop graphical.target pour être ou non dans une session
graphique.

- si tu utilises Trinity, tu peux regarder par apt quelles sont les
dépendances de ses paquets et tu vas plus que probablement découvrir
qu'il utilise network-manager ou quelque chose d'approchant. Et donc
que tout ce que tu configures à la main par ailleurs relativement au
wifi risque d'entrer en conflit avec la gestion du sans-fil par
Trinity: il vaudrait mieux dans ce cas à mon sens oublier tes
paramétrages manuels et laisser Trinity s'occuper de ça (paramétrer
dans Trinity ton réseau sans fil avec la carte qui t'es proposée)

Re: Passwords

[steve]

Le 17-01-2023, à 07:58:40 +, Tim Woodall a écrit :



One other thing you can do if you don't have a quick and easy way to
boot is to manually replace the hash in /etc/shadow with one that you do
know the password for. (This might be the case, for example, where the
USB stick is for booting ARM but all your other machines are x86, mount,
change password, umount is much quicker than trying to work out how to
live boot a headless arm system...)


Easier would be to delete the second field in /etc/shadow for root, so there
won't be anymore root password (it's empty). You can then create one with the
'passwd' command.

Re: Debian Bullseye 64 bits : wlan wifi pas possible

[Basile Starynkevitch]

On 17/01/2023 09:12, Frédéric BOITEUX wrote:

Bonjour,

C’est dans la doc d’installation : pour les nouvelles installation de Debian 
11, le nommage des interfaces n’est plus géré par udev mais par systemd (avec 
des noms du genre de wlp2s0, pas forcément bien intuitif). Si on veut les 
renommer, il faut passer par des fichiers dans /etc/systemd/network/*.link 
(avec un initrd regéréré avec cette config…).

Cdlt,
Fred.

-Message d'origine-
De : ajh-valmer 
Envoyé : lundi 16 janvier 2023 23:48
À : debian-user-french@lists.debian.org
Objet : Re: Debian Bullseye 64 bits : wlan wifi pas possible

Bonjour,

Ma connexion réseau fonctionne bien mais qu'en mode filaire Ethernet eth0.

Par contre, plus de connexion wlan possible :
J'ai bien modifié le fichier "70-persistent-rules" par eth0 et wlan0, rebooté, "wlp2s0" 
reste présent dans la commande ifconfig -a , ifup wlan0 ou wlp2s0 : "cannot find wlan0 et wlp2s0"
(interfaces non reconnues).




L'utilitaire iw pourrait être utile. https://linuxcommandlibrary.com/man/iw

(paquet Debian iw)



--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

RE: Debian Bullseye 64 bits : wlan wifi pas possible

[Frédéric BOITEUX]

Bonjour,

C’est dans la doc d’installation : pour les nouvelles installation de Debian 
11, le nommage des interfaces n’est plus géré par udev mais par systemd (avec 
des noms du genre de wlp2s0, pas forcément bien intuitif). Si on veut les 
renommer, il faut passer par des fichiers dans /etc/systemd/network/*.link 
(avec un initrd regéréré avec cette config…).

Cdlt,
Fred.

-Message d'origine-
De : ajh-valmer  
Envoyé : lundi 16 janvier 2023 23:48
À : debian-user-french@lists.debian.org
Objet : Re: Debian Bullseye 64 bits : wlan wifi pas possible

Bonjour,

Ma connexion réseau fonctionne bien mais qu'en mode filaire Ethernet eth0.

Par contre, plus de connexion wlan possible :
J'ai bien modifié le fichier "70-persistent-rules" par eth0 et wlan0, rebooté, 
"wlp2s0" reste présent dans la commande ifconfig -a , ifup wlan0 ou wlp2s0 : 
"cannot find wlan0 et wlp2s0"
(interfaces non reconnues).

Malgré consultation de nombreux liens sur ce sujet, rien ne fonctionne.

Merci d'une aide, une piste...

A. Valmer