Re: Libvirt dnsmasq oddity
On 1/16/23 05:02, Charles Curley wrote: On Sun, 15 Jan 2023 18:18:00 -0600 Nicholas Geovanis wrote: I would first want to find out why the samba server is doing that "sometimes" but not others. My first guess would be that you have a hostname identified somewhere that resolves to 2 different addresses, depending. And one or both may be defaulted addresses. Indeed. And you are correct, but not, I think, in the way you mean. On the network's DNS server, hawk (the samba server and host for the vms in question) resolves to an address on the internal network for the benefit of other computers on the network. But, thanks to /etc/hosts, on hawk it resolves to an address on the loopback interface. The problem appears to be that libvert's dnsmasq instance picks up the contents of /etc/hosts in order to serve them to the VMs, all well and good, except that it serves up the address of hawk as well. root@hawk:~# cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 hawk.localdomainhawk # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters root@hawk:~# I don't think I added those entries. I just checked a few other machines, including a vm I recently built, and they all show similar entries. Perhaps I should comment out one or both entries for hawk. Or use [1]. [1] https://libvirt.org/formatnetwork.html#network-namespaces -- John Doe
Re: technologie pour brontosaures
On 29/11/2018 18:38, Basile Starynkevitch wrote: On 11/29/18 6:18 PM, Yves Rutschle wrote: (en me citant, c'est moi qui "blaguait" en suggérant d'écrire un serveur SMTP) et rien n'interdit d'écrire le sien. Le bon sens, peut-être? :-) C'est quand même assez gros, générateur de vulnérabilités potentielles, et ça a déjà été fait plusieurs fois, pourquoi recommencer? Oui, bien sûr. C'était un peu une boutade. Juste pour signaler que SMTP est suffisamment documenté pour que ça soit possible (mais pas raisonnable) Il existe des bibliothèques qui faciliteraient ce travail, dont https://www.vmime.org/ Et ça pourrait avoir du sens, par exemple pour pré-trier automatiquement des courriels d'une entreprise, les stocker sur un serveur distant pour archivage, conserver les méta données ou carnets d'adresse, vérifier le format, la nature, et le volume des pièces jointes, filtrer le SPAM, etc etc. -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: Libvirt dnsmasq oddity
On Sun, 15 Jan 2023 18:18:00 -0600 Nicholas Geovanis wrote: > I would first want to find out why the samba server is doing that > "sometimes" but not others. > > My first guess would be that you have a hostname identified somewhere > that resolves to 2 different addresses, depending. And one or both > may be defaulted addresses. Indeed. And you are correct, but not, I think, in the way you mean. On the network's DNS server, hawk (the samba server and host for the vms in question) resolves to an address on the internal network for the benefit of other computers on the network. But, thanks to /etc/hosts, on hawk it resolves to an address on the loopback interface. The problem appears to be that libvert's dnsmasq instance picks up the contents of /etc/hosts in order to serve them to the VMs, all well and good, except that it serves up the address of hawk as well. root@hawk:~# cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 hawk.localdomainhawk # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters root@hawk:~# I don't think I added those entries. I just checked a few other machines, including a vm I recently built, and they all show similar entries. Perhaps I should comment out one or both entries for hawk. I think you meant some sort of inadvertent double definition of a host. I haven't made that mistake in a while. > But Charles you seem to be past those kinds of mistakes usually :-) Usually. Thank you. Alas, Murphy can strike us all. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Debian Nordic 2022 & 2023 -- Wiki Updated & Matrix Server Move
Hello Debian friends! The Community day for foss-north 2023: https://foss-north.se/2023/ has been announced and is decided to be on Sunday 23th April 2023 in Gothenburg. Any Debian people in the Nordics that want to do anything then? as i did talk about last year or not? On Sat, Jul 23, 2022 at 11:06 AM Luna Jernberg wrote: > > Hello Debianites! > > I updated the Wiki page during the meeting of Local Teams at Debconf > 2022 in Kosovo > Don't have the energy to host any events myself > https://wiki.debian.org/DebianEvents/Nordic and not sure if anyone > wanna host something this year, but guessed maybe we can have > something at the psychical foss-north 2023 in Gothenburg in April > 2023: https://foss-north.se/ > > And also there was discussions about making the Matrix Chat server > more official and move it from :debian.social to :debian.org > https://pad.dc22.debconf.org/p/4-debiansocial-bof there will be > another meeting about this 23:e August 20:00-21.00
Re: Debian Nordic 2022 & 2023 -- Wiki Updated & Matrix Server Move
Hello Debian friends! The Community day for foss-north 2023: https://foss-north.se/2023/ has been announced and is decided to be on Sunday 23th April 2023 in Gothenburg. Any Debian people in the Nordics that want to do anything then? as i did talk about last year or not? On Sat, Jul 23, 2022 at 11:06 AM Luna Jernberg wrote: > > Hello Debianites! > > I updated the Wiki page during the meeting of Local Teams at Debconf > 2022 in Kosovo > Don't have the energy to host any events myself > https://wiki.debian.org/DebianEvents/Nordic and not sure if anyone > wanna host something this year, but guessed maybe we can have > something at the psychical foss-north 2023 in Gothenburg in April > 2023: https://foss-north.se/ > > And also there was discussions about making the Matrix Chat server > more official and move it from :debian.social to :debian.org > https://pad.dc22.debconf.org/p/4-debiansocial-bof there will be > another meeting about this 23:e August 20:00-21.00
Re: Libvirt dnsmasq oddity
On Tue, Jan 10, 2023, 12:10 PM Charles Curley < charlescur...@charlescurley.com> wrote: > I seem to have hit an oddity in how dnsmasq operates for libvirt. > > I have two host machines each with several guests. One of those is also > the local samba server. Guests on the non-samba server can resolve the > samba server's host name correctly, so far without fail. > > Guests on the samba server sometimes get the correct IP address for the > samba server, and other times get an IP address for the samba server of > 127.0.1.1. That is the IP address provided in the host's /etc/hosts. > > I have a workaround of hard coding the IP address in the fstab entry, > but that's tacky. Is there a better way to handle this? > I would first want to find out why the samba server is doing that "sometimes" but not others. My first guess would be that you have a hostname identified somewhere that resolves to 2 different addresses, depending. And one or both may be defaulted addresses. But Charles you seem to be past those kinds of mistakes usually :-) -- > Does anybody read signatures any more? > > https://charlescurley.com > https://charlescurley.com/blog/ > >
Fwd: Disable RDRAND RDSEED VAES AES-NI via OPENSSL_ia32cap
Forwarded Message Subject: Disable RDRAND RDSEED VAES AES-NI via OPENSSL_ia32cap Date: Sun, 8 Jan 2023 00:19:84 +1984 From: operation.privacyenforcem...@secure.mailbox.org To: debian-user@lists.debian.org Hello, I want to disable RDRAND RDSEED VAES AES-NI via OPENSSL_ia32cap. Which parameters do I need to set in which file to apply the configuration system wide? https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_ia32cap.html How can multiple variables applied systemwide and how can this be tested after reboot? Best regards operation privacyenforcement
Re: Debian Bullseye 64 bits
On Saturday 14 January 2023 22:11:25 ajh-valmer wrote: > Ceci à la suite d'une réinstallation de Debian Bullseye 64 bits, > j'ai ce message, je ne peux rien faire : > "Système de fichiers en lecture seulement" > J'ai aussi ces messages répétitifs au boot : > "Begin Running /scripts/local-block done" Le problème était l'UUID de la partition système qui avait un chiffre de trop (honte à moi), ça ne pouvait que mettre un beau bazar. Quelques solutions en cas de dégats : init 1 mount -r -o remount, rw / rm -rf /var/lib/apt/lists/* apt clean && apt update Après, tout est revenu à la normale. L'objectif est de copier les 2 partitions debian 64 bits / et /home, par l'outil rsync vers un autre ordinateur. Ceci évite de faire une installation depuis zéro, de devoir tout réinstaller. ça fonctionne parfaitement, si on boote d'abord sur l'ordinateur cible en mode "rescue", pour lui permettre de se mettre au diapason du nouveau matériel. Hope it helps somebody.
Re: Fixing errors on a BTRFS partition?
* On 2023 15 Jan 10:07 -0600, Andy Smith wrote: > Hello, > > On Thu, Jan 12, 2023 at 04:57:07PM -0600, Intense Red wrote: > > > Everything online hints that attempting repair is particularly > > > dangerous, but what else am I to do? > > > >You sum up my experience with BTRFS. I too was "scared" off from it and > > reformatted my BTRFS partitions and went back to ext4 -- it's a known > > quantity fit for humans with tons of advice of how to handle > > problems/errors. > > I too don't have a lot of love for btrfs, but I think it is a bit > unfair to criticise it in this scenario, which is a failing SD card > with no redundancy. If there'd been redundancy then btrfs should > have noticed the problems and got the data from the other > copy/copies, but here it had no opportunity to do so. > > In the same situation, ext4 would have just carried on until it got > read/write errors but this wouldn't have been any better. btrfs got > the same errors and reported more of its own that it noticed from > the incorrect checksums. > > It sounds like the OP's use case didn't involve redundancy nor did > it involve any of the other btrfs features such as compression or > snapshots, so btrfs probably wasn't a good choice here. ext4 or XFS > may have been better here just because they are simpler. I can > understand not wanting to have a learning experience when it comes > to one's data. Perhaps this needs to be taken up with the Freedom Box Foundation (it has close ties to Debian) as it is the image they provide that chose btrfs to be written to the micro-SD card and used as an appliance on the Freedom Box Pioneer hardware (Olimex A20-OLinuXino-LIME2). *I* did not choose this filesystem for this application, just to be clear. If there is a better choice for what is intended to be an appliance running from a micro-SD card, then that should be communicated to the Freedom Box people. I have an SSD on order and will rebuild with ext4. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Replacing drive in Btrfs Raid10 partition? (Was: Fixing errors on a BTRFS partition?)
Guys, Quick offtop question as we are talking about Btrfs: How do you replace drives in Btrfs Raid10 array? I am in the process of upgrading 4 drives to twice as big ones. Since forever, I've been using this (example): sudo btrfs device add -f /dev/sdf1 /home sudo btrfs device remove /dev/sdd1 /home But now I am reading, newer fancy method is: sudo btrfs replace /dev/sdd1 /dev/sdf1 /home Which one is better please? For both situation where drive has failed or is still operational? -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: X11 and hot-plugged keyboards and multiple layouts
Nicolas George writes: > Does the xmodmap effect stay if you run it manually after the keyboard > is hot-plugged? Yes. I don't have a desktop environment in use on my desktop computer either so this should work for me.
Re: need kino. or a substitute that can work with a sony hi-8 metal 720 by handicam.
gene heskett writes: > What happened to kino? That was an all in one package, and while > kdenlive is pretty, it can't capture from the camera... Looks like kino has died. The last version is currently in unstable though, apparently there has been some issue that made it impossible to include it in Bullseye and Bookworm. The same devs produced the program dvgrab and that's still in Debian, maybe you could use that to grab video from the camera? Looks like a command line tool though. Possibly you could also install kino from Buster but that's a bit of a Hail Mary. I have done that a couple of times to run some software available in a previous Debian release.
Re: heu provat programari de conversió d'àudio a text?
Moltes gràcies a tothom pels vostres consells Àlex El 9/1/23 a les 14:47, Àlex ha escrit: Bon any nou, Us volia fer una pregunta per si algú de vosaltres ha fet servir programari de conversió d'àudio a text. Tinc un amic que ha de transcriure multituds d'entrevistes en castellà, i no té temps. Li vaig ensenyar a instal.lar-se Linux Mint (-sí, he pecat, ja sé que no és Debian-), que és el sistema que ara té. Ell ha trobat com a eina ParlaType , però sembla que no és una eina de conversió, sinó que és un reproductor molt adaptat a fer transcripcions: https://www.parlatype.org/ Jo li he trobat eines online, però no he provat cap: https://www.google.com/search?q=convert+audio+text Vosaltres heu fet servir alguna eina a Debian per conversió d'àudio a text que podeu recomanar? Gràcies Àlex
Re: fstrim(8) Recommendation
Hello, On Thu, Jan 12, 2023 at 06:44:59PM -0800, John Conover wrote: > I'm installing an SSD replacement for an HD in a small 24/7 mail > server. > > I would appreciate suggestions for the most reliable way to do > fstrim(8). The two ways to do it are: a) Add "discard" into the mount options for each filesystem (not supported for swap) b) Let the systemd service fstrim do it periodically These days there shouldn't really be any reliability issues whichever way you do it. Mostly people prefer (b) since it happens in batches rather than a tiny discard every time something is deleted. So I would just do nothing out of the ordinary and let the default fstrim service do its job. Things get more complicated if you are running virtual machines, or LVM volumes or things like that, but it sounds like you aren't. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Fixing errors on a BTRFS partition?
Hello, On Thu, Jan 12, 2023 at 04:57:07PM -0600, Intense Red wrote: > > Everything online hints that attempting repair is particularly > > dangerous, but what else am I to do? > >You sum up my experience with BTRFS. I too was "scared" off from it and > reformatted my BTRFS partitions and went back to ext4 -- it's a known > quantity fit for humans with tons of advice of how to handle problems/errors. I too don't have a lot of love for btrfs, but I think it is a bit unfair to criticise it in this scenario, which is a failing SD card with no redundancy. If there'd been redundancy then btrfs should have noticed the problems and got the data from the other copy/copies, but here it had no opportunity to do so. In the same situation, ext4 would have just carried on until it got read/write errors but this wouldn't have been any better. btrfs got the same errors and reported more of its own that it noticed from the incorrect checksums. It sounds like the OP's use case didn't involve redundancy nor did it involve any of the other btrfs features such as compression or snapshots, so btrfs probably wasn't a good choice here. ext4 or XFS may have been better here just because they are simpler. I can understand not wanting to have a learning experience when it comes to one's data. The btrfs mailing list is pretty helpful. I think if one was not scared to ask for help there regarding unfamiliar steps, btrfs in a redundant configuration is pretty safe for your data. My gripes with it over the years have been user interface, bugs and availability issues, not resilience i.e. I've never lost data to it. Having said that, I really do not trust things like SD cards or CompactFlash cards (remember those? I still have one in service in a firewall) for main storage unless they will be largely or entirely read-only. In my mind they are more suited to phones and cameras and similar devices. Similarly, USB storage. Attaching a USB drive (or stick!) to an Intel NUC or Raspberry Pi and exposing that over SMB is what some people consider network attached storage, and I'm sure there's people reading this who have done this for years and never had a problem, but I've had and seen so many problems with non-trivial use of USB storage. For myself, I'd want any long term setup to be attached by SATA or NVMe or over network to same. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: An AMD graphics bug is coming to unstable/testing repo
Hi David, hi All :) thank You very much for this informative mail, David. It is very kind of You to think about all AMD Debian users. Much appreciated ! I don't have to add much. The issue at Freedesktop.org is: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 There is a fix but everybody is unsure when it will find it's way into mainline. Thank You again, David & have a nice day, Y'all, Martin On 2023-01-15 12:04, David wrote: Hi list readers A FYI: I am far from expert in these things but I noticed that a kernel with a known bug affecting AMD graphics is about to enter the unstable distribution [1], and possibly the testing distribution as well. [1]:""" I would like to upload linux version 6.1.6-1 to unstable. [...] Notably though there is no fix for #1028451 """ So I quote below from that bug report [2][3] for readers here so that you can decide if you want to go read it. My words end here, the rest of this message is quotes from the footnotes given at the bottom. [2]: """ Basically this issue breaks all usage of Displayport MST on amdgpu systems. Which roughly translates to breaking external monitors for everyone using an USB-C docks with multiple display outputs (which is pretty common these days) on AMD laptops. As well as those like myself who daisy-chain display port monitors with an amdgpu using graphics card. So I would expect this impacts a lot of people :/ Which is also why there is loads of activity and duplicates on the fd.o bug now that 6.1 is trickling into distributions. For what it's worth; The revert as currently suggested also reverts big chunks for Intel and nvidia based GPUs, which unsurprisingly the maintainers of those aren't too thrilled about. And really i'd be amazed if it doesn't cause regressions for those systems... Unless the AMD folks pull a small/targetted fix out their hats, this is likely going to take weeks if not months before it's resolved in a way that's acceptable for 6.1.y :/ """ [3]: """ The revert may cause much wider issues which upstream may or may not care (much) about. And it would be a divergence from upstream. Getting wider testing of the 6.1 kernel is something I find much more important. There could be other issues lurking which would not get exposure and therefor wouldn't get fixed until this bug would be fixed. Uploading 6.1.6 now would give (us/)upstream a couple of more days to figure out a potential *better* way to deal with it. One which should be acceptable for the upstream Stable Kernel maintainers. But I wouldn't let this bug cause further delays to Testing. Testing is meant to test things for the next Stable release and things can and will break from time to time. If people can't deal with that, they should not be running Testing. """ [1] https://lists.debian.org/debian-kernel/2023/01/msg00169.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028451#35 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028451#40
Re: Debian Bullseye 64 bits
Hello, Plus bas, quelques suggestions de pointeurs dont la lecture pourrait aider à ta résolution de problèmes : 14 janv. 2023, 22:11 de awache...@gmail.com: > j'ai ce message, je ne peux rien faire : > "Système de fichiers en lecture seulement" > https://askubuntu.com/questions/197459/how-to-fix-sudo-unable-to-open-read-only-file-system https://linuxtect.com/read-only-file-system-error-and-solutions/ > J'ai aussi ces messages répétitifs au boot : > "Begin Running /scripts/local-block done" > https://mike632t.wordpress.com/2021/03/21/error-message-running-scripts-local-block-on-boot/ https://askubuntu.com/questions/1013927/begin-running-scripts-local-block-done-stuck-in-initramfs-on-ubuntu-17 Bon dimanche l0f4r0
An AMD graphics bug is coming to unstable/testing repo
Hi list readers A FYI: I am far from expert in these things but I noticed that a kernel with a known bug affecting AMD graphics is about to enter the unstable distribution [1], and possibly the testing distribution as well. [1]:""" I would like to upload linux version 6.1.6-1 to unstable. [...] Notably though there is no fix for #1028451 """ So I quote below from that bug report [2][3] for readers here so that you can decide if you want to go read it. My words end here, the rest of this message is quotes from the footnotes given at the bottom. [2]: """ Basically this issue breaks all usage of Displayport MST on amdgpu systems. Which roughly translates to breaking external monitors for everyone using an USB-C docks with multiple display outputs (which is pretty common these days) on AMD laptops. As well as those like myself who daisy-chain display port monitors with an amdgpu using graphics card. So I would expect this impacts a lot of people :/ Which is also why there is loads of activity and duplicates on the fd.o bug now that 6.1 is trickling into distributions. For what it's worth; The revert as currently suggested also reverts big chunks for Intel and nvidia based GPUs, which unsurprisingly the maintainers of those aren't too thrilled about. And really i'd be amazed if it doesn't cause regressions for those systems... Unless the AMD folks pull a small/targetted fix out their hats, this is likely going to take weeks if not months before it's resolved in a way that's acceptable for 6.1.y :/ """ [3]: """ The revert may cause much wider issues which upstream may or may not care (much) about. And it would be a divergence from upstream. Getting wider testing of the 6.1 kernel is something I find much more important. There could be other issues lurking which would not get exposure and therefor wouldn't get fixed until this bug would be fixed. Uploading 6.1.6 now would give (us/)upstream a couple of more days to figure out a potential *better* way to deal with it. One which should be acceptable for the upstream Stable Kernel maintainers. But I wouldn't let this bug cause further delays to Testing. Testing is meant to test things for the next Stable release and things can and will break from time to time. If people can't deal with that, they should not be running Testing. """ [1] https://lists.debian.org/debian-kernel/2023/01/msg00169.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028451#35 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028451#40
