Re: Debian:12.4/stable [amd64] ...
On 1/27/24, Andrew M.A. Cater wrote:
> I am consistently *puzzled* by what you are trying to do: I think that
> that is just effectively recording the repository that the package comes
> from. What does your /etc/sources.list consist of - and if it references
> bookworm, in what way does 12.4 surprise you? (Hint: That will change
> in about two weeks to 12.5 ...)
Thank you! I didn't know what it meant.
> Your approach to all of this is best described as idiosyncratic - if
> you really don't trust Debian and apt and the way we do things
Debian and apt and the way things are done within this OS cultural
ecosystem are fine, except for the assumption of using the Internet as
a trusted medium to any extent ("except", right? ;-)). I just got some
retribution from the Internet AI Gods, it seems. No internet access
for a week ...
> what
> *do* you trust?
Well, let me just say that it somehow makes me feel somewhat
satisfied. As some sort of conservation law I think when they give me
sh!t you are not getting it ...
lbrtchx
Re: Problemen met rechten LetsEncrypt
On Sat, 27 Jan 2024 14:16:52 +0100 Paul van der Vlis wrote: > > Ik neem aan dat de user wel lid is van de groep ssl-cert. Eerst > > uitloggen en weer inloggen voordat de user echt tot de groep hoort. > > Misschien is dat het? > > Alles in /etc/letsencrypt was root:root. > Dan helpt het niet als een user lid is van een groep. > > Ik heb dit nu gewijzigd, maar met kans op fouten. En ook een kans dat > het weer fout gaat bij een nieuw certificaat of bij het verlengen van > een certificaat. [addendum] Ik heb, zoals Geert al opperde, de hele boel wel eens opnieuw opgezet. En sinds de laatste keer gaat het eigenlijk best wel goed. -- richard lucassen http://contact.xaq.nl/
Re: Problemen met rechten LetsEncrypt
On Sat, 27 Jan 2024 14:16:52 +0100 Paul van der Vlis wrote: > > Ik neem aan dat de user wel lid is van de groep ssl-cert. Eerst > > uitloggen en weer inloggen voordat de user echt tot de groep hoort. > > Misschien is dat het? > > Alles in /etc/letsencrypt was root:root. > Dan helpt het niet als een user lid is van een groep. > > Ik heb dit nu gewijzigd, maar met kans op fouten. En ook een kans dat > het weer fout gaat bij een nieuw certificaat of bij het verlengen van > een certificaat. Ik gebruik ook certbot en ik heb gemerkt dat het af en toe misgaat en dan maakt-ie directories aan met domain.tld-0001 of dirs van gelijke strekking (iets met een nummer als 0001, 0002 etc). Ik heb destijds een quick and dirty script in elkaar gejast: ### #!/bin/dash certbot \ --manual \ --preferred-challenges dns \ certonly \ -d domain.tld \ -d www.domain.tld \ --config-dir ~/share/letsencrypt/etc/ \ --work-dir ~/share/letsencrypt/certs/ \ --logs-dir ~/share/letsencrypt/log/ cd ~/share/letsencrypt/etc/live/domain.tld cat fullchain.pem privkey.pem > domain.tld-bundle.pem scp domain.tld-bundle.pem \ root@:/etc/ssl/domain.tld/ ssh root@ service lighttpd restart ### Op de server zet ik die bundel op chmod 400. De server start toch als root op, leest de spullen uit en gaat dan verder met een unprivileged user. HTH, R. -- richard lucassen http://contact.xaq.nl/
Re: Do I have to worry about system zsh config files getting wiped out?
On Sat, Jan 27, 2024 at 02:31:07PM -0500, Dotfiles wrote: > > > > Debian always does this with configuration files. > > > > OK, thanks. I’ve seen those prompts before with other config files but I > wasn’t sure if it also happened with zsh. But it sounds like this is standard > behavior for all config files. Good to know. The packager has to mark them as so-called conffiles. Files going to /etc are these days, by default, conffiles (so the packager would have to go out of their way for it to not be so). Cheers -- t signature.asc Description: PGP signature
Re: Do I have to worry about system zsh config files getting wiped out?
> > Debian always does this with configuration files. > OK, thanks. I’ve seen those prompts before with other config files but I wasn’t sure if it also happened with zsh. But it sounds like this is standard behavior for all config files. Good to know.
Re: Do I have to worry about system zsh config files getting wiped out?
On Sat, Jan 27, 2024 at 01:56:57PM -0500, Dotfiles wrote: > If I make changes to the config files in /etc/zsh, do I have to worry about > them getting overwritten if I do an upgrade to the next major Debian release? If that release comes with a new config file, you will be asked at installation time whether you want to keep your old config file or install the new one. You'll be offered to see a diff between your version and the new one, and in any case, the "other" file (your old, modified file or the new one) is kept under a different name. Debian always does this with configuration files. Cheers -- t signature.asc Description: PGP signature
Do I have to worry about system zsh config files getting wiped out?
If I make changes to the config files in /etc/zsh, do I have to worry about them getting overwritten if I do an upgrade to the next major Debian release?
Request about Boot Repair Disk
I have installed Windows 10 on a notebook Asus F552M. Then I installed Debian 12, but no Grub at reboot only Windows. If I use SuperGrub cd by manual booting I can access to debian and boot it. So I used Boort Repair Disk 64 to try to repair, but it gave me a report advicing me to ask online with that report here under: (it is a long report) < boot-repair-4ppa125 [20240127_1537] == Boot Info Summary === => Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 567169024 of the same hard drive for core.img. core.img is at this location and looks for (,gpt6)/boot/grub. It also embeds following components: modules --- fshelp ext2 part_gpt biosdisk --- sda1: __ File system: vfat Boot sector type: Windows 8/2012: FAT32 Boot sector info: No errors found in the Boot Parameter Block. Operating System: Boot files: /efi/Boot/bootx64.efi /efi/Microsoft/Boot/bootmgfw.efi /efi/Microsoft/Boot/bootmgr.efi /efi/Microsoft/Boot/memtest.efi sda2: __ File system: Boot sector type: - Boot sector info: sda3: __ File system: ntfs Boot sector type: Windows 8/2012: NTFS Boot sector info: No errors found in the Boot Parameter Block. Operating System: Windows 10 Boot files: /Windows/System32/winload.exe sda4: __ File system: ntfs Boot sector type: Windows 8/2012: NTFS Boot sector info: No errors found in the Boot Parameter Block. Operating System: Boot files: sda5: __ File system: BIOS Boot partition Boot sector type: Grub2's core.img Boot sector info: sda6: __ File system: ext4 Boot sector type: - Boot sector info: Operating System: Debian GNU/Linux 12 (bookworm) Boot files: /boot/grub/grub.cfg /etc/fstab /etc/default/grub /boot/grub/i386-pc/core.img sda7: __ File system: swap Boot sector type: - Boot sector info: sda8: __ File system: ext4 Boot sector type: - Boot sector info: Operating System: Boot files: 2 OS detected = OS#1: Debian GNU/Linux 12 (bookworm) on sda6 OS#2: Windows 10 on sda3 Architecture/Host Info CPU architecture: 64-bit Live-session OS is Ubuntu 64-bit (Boot-Repair-Disk 64bit 20200604, bionic, x86_64) = UEFI = BIOS is EFI-compatible, and is setup in EFI-mode for this live-session. efibootmgr -v No BootOrder is set; firmware will attempt recovery df480f092e56b632513b4616bdeade95 sda1/Boot/bootx64.efi df480f092e56b632513b4616bdeade95 sda1/Microsoft/Boot/bootmgfw.efi 0a70ebdfe73694eb6188f70e81b47a79 sda1/Microsoft/Boot/bootmgr.efi = Drive/Partition Info = Disks info: sda : is-GPT, hasBIOSboot, has---ESP, not-usb, not-mmc, has-os, 2048 sectors * 512 bytes Partitions info (1/3): _ sda1 : no-os, 32, nopakmgr, no-docgrub, nogrub, nogrubinstall, no-grubenv, noupdategrub, not-far sda3 : is-os, 32, nopakmgr, no-docgrub, nogrub, nogrubinstall, no-grubenv, noupdategrub, farbios sda4 : no-os, 32, nopakmgr, no-docgrub, nogrub, nogrubinstall, no-grubenv, noupdategrub, farbios sda6 : is-os, 64, apt-get, grub-pc , grub2, grub-install, grubenv-ok, update-grub, farbios sda8 : no-os, 32, nopakmgr, no-docgrub, nogrub, nogrubinstall, no-grubenv, noupdategrub, farbios Partitions info (2/3): _ sda1 : is---ESP, part-has-no-fstab, no-nt, no-winload, no-recov-nor-hid, no-bmgr, notwinboot sda3 : isnotESP, part-has-no-fstab, no-nt, haswinload, no-recov-nor-hid, no-bmgr, notwinboot sda4 : isnotESP, part-has-no-fstab, no-nt, no-winload, recovery-or-hidden, no-bmgr, notwinboot sda6 : isnotESP, fstab-without-efi, no-nt, no-winload, no-recov-nor-hid, no-bmgr, notwinboot sda8 : isnotESP, part-has-no-fstab, no-nt, no-winload, no-recov-nor-hid, no-bmgr, notwinboot Partitions info (3/3): _ sda1 : not-sepboot, no-boot, part-has-no-fstab, not-sep-usr, no---usr, part-has-no-fstab, std-grub.d, sda sda3 :
Re: Problemen met rechten LetsEncrypt verwacht
On Sat, Jan 27, 2024 at 06:07:28PM +0100, Geert Stappers wrote: > On Sat, Jan 27, 2024 at 02:16:52PM +0100, Paul van der Vlis wrote: > > Op 27-01-2024 om 00:00 schreef Richard Lucassen: > > > On Wed, 24 Jan 2024 15:15:37 +0100 Paul van der Vlis wrote: > > > > > > > Op een vers geinstalleerde Debian12 heb ik een raar probleem met > > > > LetsEncrypt certificaten. (Ik gebruik certbot, weet niet of dat van > > > > belang is.) > > > > > > > > Eerder was het zo dat gebruikers die lid waren van de groep ssl-cert > > > > bij de certicaten en keys mochten, maar nu niet meer. Alleen root mag > > > > erbij. > > > > > > > > Weet iemand hier meer van? Ik zag geen bug. > > > > > > Ik neem aan dat de user wel lid is van de groep ssl-cert. Eerst > > > uitloggen en weer inloggen voordat de user echt tot de groep hoort. > > > Misschien is dat het? > > > > Alles in /etc/letsencrypt was root:root. > > Dan helpt het niet als een user lid is van een groep. > > Lees verder > Voor een nieuwe poging. [1] > > > Ik heb dit nu gewijzigd, maar met kans op fouten. En ook een kans dat het > > weer fout gaat bij een nieuw certificaat of bij het verlengen van een > > certificaat. > > Vastwel > Waar het mis is gegaan is mijn inziens minder belangrijk dan hoe het goed te krijgen. Advies om het in **meerdere stappen** goed te krijgen. (in 1 keer goed halen we al niet meer :-) Eerste stap: * sudo rm -rf /etc/letsencrypt # ja, dat is erg lomp [0] * sudo mkdir /etc/letsencrypt * sudo chmod a+rwx /etc/letsencrypt Tweede stap: * Laat certbot zijn ding doen > > > > (Ik gebruik certbot, weet niet of dat van belang is.) Derde stap: * Kijk in /etc/letsencrypt naar wie bestandseigenaar is. (vermoedelijk "certbot") * Kijk ook naar file-permissies Vierde stap: * Ga met chmod aan de slag in /etc/letsencrypt, verwijder de te ruime permissies Vijfde stap: * Voorkom dat het op andere systemen nodig is. > Tot zo Tussen de letsencrypt acties is het verstandig om voldoende "wachttijd" te hebben. Denk in weken, zeker langer dan in dagen. Groeten Geert Stappers [0] Overweeg om vooraf een kopie van /etc/letsencrypt te maken [1] De > > Alles in /etc/letsencrypt was root:root. > > Dan helpt het niet als een user lid is van een groep. vind ik nog steeds een halve waarheid. En eigenlijk een hele leugen. -- Silence is hard to parse
Re: Playing a sound when initrd wants a password
David Wright (12024-01-26): > It looks as if the root directory is decrypted by > /usr/share/initramfs-tools/scripts/local-top/cryptroot > and, from its prereqs, that this script makes sure it > is the last to run from scripts/local-top, by actually > being run from scripts/local-block/cryptroot. > (Correct me if I'm wrong: I'm a tyro in here.) > > I notice that there is a slew of empty directories in > /etc/initramfs-tools/scripts/, and I can only assume > that anything you drop into these gets merged with > those in /usr/share/initramfs-tools/scripts/ when > the initramfs is built. > > There is no scripts/local-block/ directory under /etc/, > possibly because it's not intended that you interfere > with the "ordering trick" mentioned above. Thanks for pulling on this plate of spaghetti for me. > So I would try dropping a logging/printing script into > /etc/initramfs-tools/scripts/local-top/ in order to see > whether it runs, and at the right time. The script > could also look and see what support is already > available for making noises. That would run the script just before cryptsetup is called. That is almost what I want, but the small gap is blocking: cryptsetup might ask for the password several times (if the user types it wrong), and the sound must be played again too in that case. Regards, -- Nicolas George
Re: Playing a sound when initrd wants a password
Curt (12024-01-27): > (Anyway, this is what my personal robot explained to me and may be subject to > imperfection and error.) I started explaining all the ways this answer is obviously nonsensical, but I got fed up and deleted it. If I wanted the answers from a stupid AI, I could have asked directly. I wrote to this list in the small hope of having an answer from somebody competent who knows what about the issue. -- Nicolas George, starting a list
Re: Debian:12.4/stable [amd64] ...
On Sat, Jan 27, 2024 at 02:32:57PM +, Albretch Mueller wrote: > apt-get installation logs (in --dry-run mode) show lines like: > ... > Inst libvncclient1 (0.9.14+dfsg-1 Debian:12.4/stable [amd64]) > Inst vlc-bin (3.0.20-0+deb12u1 Debian:12.4/stable [amd64]) > Inst vlc-plugin-qt (3.0.20-0+deb12u1 Debian:12.4/stable [amd64]) > ... > you can get most parts of the suffix: "Debian:12.4/stable [amd64]", in > various way except the ".4" and the "stable" parts. > > How could you get, list those ".4" and "stable" attributes prior to > running apt-get? > > lbrtchx > Hi Albretch (and every time I see that I want to write Albrecht, sorry) I am consistently *puzzled* by what you are trying to do: I think that that is just effectively recording the repository that the package comes from. What does your /etc/sources.list consist of - and if it references bookworm, in what way does 12.4 surprise you? (Hint: That will change in about two weeks to 12.5 ...) Your approach to all of this is best described as idiosyncratic - if you really don't trust Debian and apt and the way we do things, what *do* you trust? Andy (amaca...@debian.org)
Re: Playing a sound when initrd wants a password
On Sat, Jan 27, 2024 at 05:07:37PM -, Curt wrote: > On 2024-01-26, Nicolas George wrote: > > Curt (12024-01-26): > >> A play-sound.timer unit file in /usr/lib/systemd/system-generators/initrd > >> directory. > > > > I see no mention of this directory on the web. Where did yo find the > > idea of using it, I want to check the doc. > > I guess that path should've been /usr/local/lib/systemd/system-generators/*. Emphasing "guess" > https://manpages.debian.org/testing/systemd/systemd.generator.7.en.html Text from that URL: Generators are small executables placed in /lib/systemd/system-generators/ and other directories listed above. systemd(1) will execute these binaries very early at bootup and at configuration reload time — before unit files are loaded. Their main purpose is to convert configuration and execution context parameters that are not native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins, so that they can extend the unit file hierarchy the service manager subsequently loads and operates on. > > And what should I put in the timer file to express “when a password is > > asked”? > > > In fact, what relation do you see between a timer and cryptsetup asking > > for a password? > > > } Harmfull text > > (Anyway, this is what my personal robot explained to me Do mankind a favor and next time start with expressing that. > and may be subject to imperfection and error.) I'm fairly sure it is an error. And the first two laws of Clarke say I should not have sent this email. Groeten Geert Stappers [1] https://en.wikipedia.org/wiki/Clarke%27s_three_laws -- Silence is hard to parse
Re: Playing a sound when initrd wants a password
On 2024-01-26, Nicolas George wrote: > Curt (12024-01-26): >> A play-sound.timer unit file in /usr/lib/systemd/system-generators/initrd >> directory. > > I see no mention of this directory on the web. Where did yo find the > idea of using it, I want to check the doc. I guess that path should've been /usr/local/lib/systemd/system-generators/*. https://manpages.debian.org/testing/systemd/systemd.generator.7.en.html > And what should I put in the timer file to express “when a password is > asked”? > In fact, what relation do you see between a timer and cryptsetup asking > for a password? > **Step 1: Create the Timer Unit File** 1. Create a timer unit file named `play-sound-cryptsetup.timer` in the `/usr/local/lib/systemd/system-generators/initrd` directory. 2. Add the following content to the `play-sound-cryptsetup.timer` file: ``` [Unit] Description=Play sound when cryptsetup prompts for a password [Timer] OnBootSec=0 [Install] WantedBy=initrd.target ``` This timer will be triggered immediately after the initrd is loaded, ensuring the sound is played at the very beginning of the boot process. **Step 2: Create the Service Unit File** 1. Create a service unit file named `play-sound-cryptsetup.service` in the same directory as the timer unit file (`/usr/local/lib/systemd/system-generators/initrd`). 2. Add the following content to the `play-sound-cryptsetup.service` file: ``` [Unit] Description=Play sound when cryptsetup prompts for a password [Service] Type=oneshot ExecStart=/usr/bin/cryptsetup --key-file /dev/null open-dialog cryptluks ExecStartPost=/bin/play -q /path/to/your/sound.wav ``` Replace `cryptluks` with the actual device name of your encrypted partition. **Step 3: Create the Initrd Image** 1. Build the initrd image using the `mkinitrd` tool: ``` mkinitrd -f /boot/initramfs-$(uname -r).img -v ``` 2. Update the initrd image to be used by systemd: ``` sudo update-initramfs -u ``` **Step 4: Enable and Start the Timer** 1. Enable the timer to ensure it runs every time the system boots: ``` sudo systemctl enable play-sound-cryptsetup.timer ``` 2. Start the timer to play the sound immediately: ``` sudo systemctl start play-sound-cryptsetup.timer ``` Now, every time you boot your system and cryptsetup prompts for a password, the specified sound file (`/path/to/your/sound.wav`) will play. (Anyway, this is what my personal robot explained to me and may be subject to imperfection and error.)
Re: Problemen met rechten LetsEncrypt verwacht
On Sat, Jan 27, 2024 at 02:16:52PM +0100, Paul van der Vlis wrote: > Op 27-01-2024 om 00:00 schreef Richard Lucassen: > > On Wed, 24 Jan 2024 15:15:37 +0100 Paul van der Vlis wrote: > > > > > Op een vers geinstalleerde Debian12 heb ik een raar probleem met > > > LetsEncrypt certificaten. (Ik gebruik certbot, weet niet of dat van > > > belang is.) > > > > > > Eerder was het zo dat gebruikers die lid waren van de groep ssl-cert > > > bij de certicaten en keys mochten, maar nu niet meer. Alleen root mag > > > erbij. > > > > > > Weet iemand hier meer van? Ik zag geen bug. > > > > Ik neem aan dat de user wel lid is van de groep ssl-cert. Eerst > > uitloggen en weer inloggen voordat de user echt tot de groep hoort. > > Misschien is dat het? > > Alles in /etc/letsencrypt was root:root. > Dan helpt het niet als een user lid is van een groep. Lees verder > Ik heb dit nu gewijzigd, maar met kans op fouten. En ook een kans dat het > weer fout gaat bij een nieuw certificaat of bij het verlengen van een > certificaat. Vastwel > Groet, > Paul Tot zo Geert Stappers -- Silence is hard to parse
Re: Monospace fonts, Re: Changing The PSI Definition
On Fri, Jan 26, 2024 at 01:50:38PM -0600, David Wright wrote: On Fri 26 Jan 2024 at 07:25:13 (-0500), Dan Ritter wrote: Greg Wooledge wrote: > On Thu, Jan 25, 2024 at 07:32:38PM -0500, Thomas George wrote: > > The current PSI works perfectly but I don't like the pale green prompt. > > > > Tried editing .bashrd , /ext/fprofile and /ext/bash.bashrc but no changes to > > the PSI definition had any effect > > You appear to be asking about the shell prompt. > > In bash, the shell prompt is defined in the PS1 variable, which stands > for "Prompt String One (1)". The last character is the numeral 1, not > the capital letter I. Might be time for a new font. I like Inconsolata, but l1I! should never look similar, nor O0@ or S$. I'll give a shout-out for Hack,¹ which I can't fault for use in xterms. Comparingxterm -geometry 80x25+0+0 -fa hack -fs 16 with xterm -geometry 80x25+0+0 -fa inconsolata -fs 18 (to make the sizes roughly the same), I find the inconsolata stroke width on the basic Roman alphabet is a little spindly. I've been pretty happy with the Intel One Mono font lately, it seems to incorporate the lessons learned from previous attempts at a highly readable mono font and I find it extremely legible. There are complaints about certain features being "ugly", but I'm well into a stage of life where I care more about being able to easily read the text without eyestrain than what it looks like on a sample sheet.
Re: File has unexpected size (x != y). Mirror sync in progress? [IP: ...] ...
On 1/19/24, David Wright wrote: > On Fri 19 Jan 2024 at 22:19:21 (+), Albretch Mueller wrote: >> Package dependencies to me are just DAGs, > Are they? No circular dependencies? The way I see them, "circular dependencies" are "cultural". "organizational" issues not essentially technical ones. circular dependencies happen in packages which should be part of the same node. Show me examples in which it is not the case. >> [ … ] I haven’t found a book yet, explaining it all. >> At times I have found great explanations about single aspects. > What sales figures would you expect to see with such a book? ... and since that sounds to me like ransom money aren't you the one who would determine the amount yourself? lbrtchx
Debian:12.4/stable [amd64] ...
apt-get installation logs (in --dry-run mode) show lines like: ... Inst libvncclient1 (0.9.14+dfsg-1 Debian:12.4/stable [amd64]) Inst vlc-bin (3.0.20-0+deb12u1 Debian:12.4/stable [amd64]) Inst vlc-plugin-qt (3.0.20-0+deb12u1 Debian:12.4/stable [amd64]) ... you can get most parts of the suffix: "Debian:12.4/stable [amd64]", in various way except the ".4" and the "stable" parts. How could you get, list those ".4" and "stable" attributes prior to running apt-get? lbrtchx
AW: su su- sudo dont work
Good afternoon Thank You There is only one password. The problem was created until the update to DEBIAN 11 created panic. Before sudo su su - did work. Regards Sophie Von: Gareth Evans Gesendet: Mittwoch, 24. Januar 2024 04:31 An: debian-user@lists.debian.org Cc: debian-user@lists.debian.org Betreff: Re: su su- sudo dont work > On 23 Jan 2024, at 18:30, Hans wrote: > > Am Dienstag, 23. Januar 2024, 13:54:25 CET schrieb Schwibinger Michael: > For gvetting root as normal user, best is use "su -". > > Note: It is not "su-", but "su -", with a space between su and the minus sign. Also su requires root's password, not the user's, just in case that's worth mentioning...
Re: Problemen met rechten LetsEncrypt
Op 27-01-2024 om 00:00 schreef Richard Lucassen: On Wed, 24 Jan 2024 15:15:37 +0100 Paul van der Vlis wrote: Op een vers geinstalleerde Debian12 heb ik een raar probleem met LetsEncrypt certificaten. (Ik gebruik certbot, weet niet of dat van belang is.) Eerder was het zo dat gebruikers die lid waren van de groep ssl-cert bij de certicaten en keys mochten, maar nu niet meer. Alleen root mag erbij. Weet iemand hier meer van? Ik zag geen bug. Ik neem aan dat de user wel lid is van de groep ssl-cert. Eerst uitloggen en weer inloggen voordat de user echt tot de groep hoort. Misschien is dat het? Alles in /etc/letsencrypt was root:root. Dan helpt het niet als een user lid is van een groep. Ik heb dit nu gewijzigd, maar met kans op fouten. En ook een kans dat het weer fout gaat bij een nieuw certificaat of bij het verlengen van een certificaat. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: Postponed publickey before Accepted publickey - what's happening there then?
Hi, On Sat, Jan 27, 2024 at 09:55:16AM +, Michael Kjörling wrote: > On 27 Jan 2024 08:12 +, from a...@strugglers.net (Andy Smith): > > This only happens when I log in as root using a public key, i.e. > > > > ssh -i /path/to/pubkey r...@t.example.com > > According to https://access.redhat.com/solutions/20057 this can happen > in cases where multiple authentication methods are tried. You should > be able to confirm this by adding -v to your ssh command line and > looking for authentication methods that are not your presumably > intended publickey. The only authentication methods that are tried are publickey, it's just that it seems it tries several public keys that won't work first: debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/andy/.ssh/id_rsa debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Offering ED25519 public key: andy@jameson debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Offering RSA public key: /home/andy/.ssh/id_rsa debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Offering RSA public key: /home/andy/.ssh/foo_rsa debug1: Server accepts key: pkalg rsa-sha2-512 blen 535 debug1: Authentication succeeded (publickey). Authenticated to t.example.com ([2001:db8:0:1f1::13]:922). (/home/andy/.ssh/foo_rsa being what was specified on the ssh command line with -i) Presumably if there WERE no working public keys then it would get around to trying another method, but publickey is offered first. If I do: $ ssh -o IdentitiesOnly=yes -i ~/.ssh/foo_rsa r...@t.example.com then only that single public key is offered and there is no message about publickey being postponed, so that must be it. Though I still wonder why it bopthers to log anything about publickey being postponed in the first place. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: rsync --delete vs rsync --delete-after
On Fri, 2024-01-26 at 16:11 +0100, hw wrote: > I've never had issues with any UPS due to self tests. The batteries > need to be replaced when they are worn out. How often that is > required depends on the UPS and the conditions it is working in, > usually every 3--5 years. It was with some small to mid APC model, I think. We had about 1 to 2kW worth of servers on it, so it was not that small, definitely no consumer type. When I took over maintenance somebody had configured some sort of weekly or biweekly self-test, that switched over to battery, was supposed to run the battery down to 25% or similar, and then return to mains power/charging. Except once what the UPS considered 25% charge seemingly was not, and everything shut down instantly. > I rather spend the money on new batteries (EUR 40 last time after 5 > years) every couple years rather than spending thousands on replacing > the hardware when a power surge damages it which could have been > prevented by the UPS, and it's better to have the machines shut down > properly rather taking risks with potential data loss, regardless of > file systems and RAID setups in use. I think having hardware for "thousands" and having a UPS with that cheap batteries is not that common. In above company we certainly had hardware for thousands, but changing batteries cost hundreds of Euros, even with off-brand aftermarket parts. It also was complicated to order the right parts etc. > RAID isn't as complicated as you think. Hardware RAID is most > simple, > followed by btrfs, followed by mdadm. I have to disagree with that too. Some hardware RAIDs might be simple, but others are not. Tracking down the rebrandings of Adaptec, aquisitions and mergers, is a science by itself. As is finding and installing their Firmware and utilites. Are they still calles Avago, or something new again? Or all that BBU stuff: Tracking the state of battery backup units on the controller, and ordering and replacing the correct battery is also not really easy. Clearly enterprise IT type of stuff, keeping even knowledgeable people busy for hours, if you don't do it at scale and regularily. Also often Linux support is problematic. Yes, it will work, but sometimes certain utilities are not available or work as good as with Windows. On the other hand mdadm software RAID is well documented and painless. > > With hardware RAID I can instruct someone who has no idea what > they're > doing to replace a failed disk remotely. Same goes for btrfs and > mdadm, though it better be someone who isn't entirely clueless In fact this was my job for some time: Administering hardware RAID equipped servers, and instructing "remote hands" or customers to swap harddisks. It was not always easy, not always were the correct disks pulled, even though it was correctly labelled. Sometimes clueless people tried swapping by themselves, mixing stuff up. We also had one server with wrong labelling, for whatever reason. That was no fun ;) Now I won't dispute that RAID has its place in data centers and many other applications. I just doubt that it is the correct choice for many home users. > More importantly, the hassle involved in trying to recover from a > failed disk is ridiculously enormous without RAID and can get > expensive when hours of work were lost. With RAID, you don't even > notice unless you keep an eye on it, and when a disk has failed, you > simply order a replacement and plug it in. Yes, that can happen. But more often than not the scenario is like it is with most notebooks today. You send your notebook in for repair, and have to reinstall anyway. Happened to me. I backed up my Debian system, sent the device in for hardware repair, got it back with Windows 10 ;) And no, it was not the disk that was broken, but the touchpad. > > It's not like you could go to a hardware store around the corner and > get a new disk same or next day. Even if you have a store around, > they will need to order the disk, and that can, these days, take > weeks > or months or longer if it's a small store. For consumer hard disks? I just go to my favourite shop if I need a replacement, and they've got maybe 20 or 30 types of hard disk in stock, to be bought right away. Even more with SSDs. And I am in a smallish city, pop. 250.000. > That is simply wrong. RAID doesn't protect you from malware, and > nothing protects you from user error. If you have data losses from > malware and/or user error more often than from failed disks, you're > doing something majorly wrong. In my experience user error is the main source of data loss. By far. > This shows that you have no experience with RAID and is not an > argument. I've got years of experience with RAID, both in my personal use and with employers doing stuff on RAID for customers and internal services. In my experience RAID is a nice solution for data center type setups. RAID often is problematic for home users or even small offices. > Making backups
Re: AW: AW: su su- sudo dont work
Hello, On Sat, Jan 27, 2024 at 11:05:30AM +0100, Thomas Schmitt wrote: > Andy Smith wrote: > > It is hard to understand how what Michael/Sophie/Tobias does can in > > any way be "fun" for them, though maybe that is just our lack of > > understanding. > > I expressed my suspicion of a "Hurz" performance in > https://lists.debian.org/debian-user/2023/05/msg00100.html Okay, but it seems to me that watching an audience try to take a nonsense opera seriously is a bit more sophisticated and has scope for amusement, unlike for example an endless stream of mispastes and misunderstandings about "sudo" and "su". But I guess what one finds amusing can have a very wide variability… Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Changing The PSI Definition
>> On Fri, Jan 26, 2024 at 07:42:30AM -0500, Dan Ritter wrote:
> Might be time for a new font. I like Inconsolata, but l1I!
> should never look similar, nor O0@ or S$.
My eyesight sucks like a black hole with daddy issues, so I like fonts
that are a bit larger than most. My favorites on xterm:
* xft:Menlo-Regular:pixelsize=20:bold
* xft:Bitstream Vera Sans Mono:pixelsize=21:bold
* xft:Cascadia:pixelsize=22:bold
* xft:FiraMono-Regular:pixelsize=22
Your examples above are very readable with Menlo. These aren't bad:
* xft:Edlo:pixelsize=21:bold
* xft:Inconsolata-Bold:pixelsize=25:bold
* xft:Meslo LG S:pixelsize=20:bold
* xft:Meslo LG S:pixelsize=21:bold
* xft:UbuntuMono-B:pixelsize=25:bold
I run two xterms side-by-side on a 23-inch monitor:
/usr/local/bin/xterm -geometry 80x40-0+0 -j -b 10 -sb \
-si -sk -ls -u8 -sl 4000 -cr blue -bd black -bg white \
-fa xft:Menlo-Regular:pixelsize=20:bold -title Remote
For browsing (Firefox), my "prefs.js" file holds:
user_pref("browser.display.use_document_fonts", 0);
user_pref("font.default.x-western", "sans-serif");
user_pref("font.internaluseonly.changed", false);
user_pref("font.minimum-size.x-western", 18);
user_pref("font.name.monospace.x-western", "DejaVu Sans");
user_pref("font.name.sans-serif.x-western", "sans-serif");
user_pref("font.name.serif.x-western", "DejaVu Serif");
user_pref("font.size.fixed.x-western", 18);
user_pref("font.size.variable.x-western", 18);
--
Karl Vogel I don't speak for anyone but myself
Slogan of 105.9, the classic rock radio station in Chicago:
"Of all the radio stations in Chicago...we're one of them."
Re: AW: AW: su su- sudo dont work
Hi, Andy Smith wrote: > It is hard to understand how what Michael/Sophie/Tobias does can in > any way be "fun" for them, though maybe that is just our lack of > understanding. I expressed my suspicion of a "Hurz" performance in https://lists.debian.org/debian-user/2023/05/msg00100.html Have a nice day :) Thomas
Re: Postponed publickey before Accepted publickey - what's happening there then?
On 27 Jan 2024 08:12 +, from a...@strugglers.net (Andy Smith): > 2024-01-27T07:59:42.003881+00:00 t.example.com sshd[12319]: Postponed > publickey for root from 2001:db8:1f1:f0c2::2 port 37032 ssh2 [preauth] > 2024-01-27T07:59:42.01+00:00 t.example.com sshd[12319]: Accepted > publickey for root from 2001:db8:1f1:f0c2::2 port 37032 ssh2: RSA > SHA256:iC8C78UYVJdr+bsqV1hbtBFuft6KHi0b8i308Zn0C9o > 2024-01-27T07:59:42.020718+00:00 t.example.com sshd[12319]: > pam_unix(sshd:session): session opened for user root by (uid=0) > 2024-01-27T07:59:42.033599+00:00 t.example.com systemd-logind[1729]: New > session 18604 of user root. Thank you for using 2001:db8::/32 and example.com instead of some random made-up prefix and domain name. :-) > This only happens when I log in as root using a public key, i.e. > > ssh -i /path/to/pubkey r...@t.example.com According to https://access.redhat.com/solutions/20057 this can happen in cases where multiple authentication methods are tried. You should be able to confirm this by adding -v to your ssh command line and looking for authentication methods that are not your presumably intended publickey. According to https://forums.centos.org/viewtopic.php?t=52896 and https://stackoverflow.com/questions/46525629/ssh-failing-after-postponed-publickey-and-single-attempt it can also happen if there is a problem with accessing the secret key, but it looks like in those cases authentication ultimately fails, which is not the case for you, so that cause seems less likely. So I would first try adding to your ssh command: -o PreferredAuthentications=publickey If that causes the message to go away on the server side, then update your SSH client configuration accordingly. You can also try disabling all unwanted authentication methods as suggested on the Red Hat page, and maybe enabling them on a host-by-host and as-needed basis. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)
On Fri, 26 Jan 2024, David Wright wrote: On Fri 26 Jan 2024 at 19:03:33 (+0100), Roger Price wrote: I currently have two Eaton Ellipse ECO 1600's. ... The four screws are deeply recessed and difficult to see. They have different heads: some are Torx 10, others are a star. 20/20 hindsight might suggest that you were only intended to remove the star, if by that you mean Philips/Pozidrive. What I called "star" is probably a Quadrex. Roger
Re: AW: AW: su su- sudo dont work
Hi Hans, On Sat, Jan 27, 2024 at 10:23:09AM +0100, Hans wrote: > I see this exactly as you and are watching this list for may years. I'm not sure who you're replying to as you've removed those details, though I may guess from your In-Reply-To header which doesn't point to a list message. You haven't replied to an off-list (personal) mail back onto the list have you? Be careful there! > But since the beginning, I had the suspicion, that someone just > wants to make fun with us. It is hard to understand how what Michael/Sophie/Tobias does can in any way be "fun" for them, though maybe that is just our lack of understanding. Either they are incredibly confused by Linux or they are pretending to be for reasons beyond my understanding. Whatever the case, I don't think I have ever seen one of their threads result in a positive resolution. It's probably best to not assume that what we don't understand is hostile and/or an AI experiment. Even so, that doesn't mean it is possible to help. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: AW: AW: su su- sudo dont work
I see this exactly as you and are watching this list for may years. However, I wanted not to be so directly because I want not to blame anyone on this list. But since the beginning, I had the suspicion, that someone just wants to make fun with us. Aleady from the beginning I checked after the mail adress (please note, I am German myself) and found some theater group behind the mailadress. So I personally(!) believe, the group is making fun with us, but even then I gave him a chance. And again I personally(!) (and this is my very personal opinion), I think, nobody is so stupid, that he/she can not do a su or install a package. NOT after 2 years!!! For me, I will get no help here for this person, just ignore it. This is my very personal decision! Sorry to say it, but for me personally it looks like fake! Like a morone, like a troll. And those I can not support, sorry. Please excuse, I do not want to hurt anyone, just tell, what I think. Best regards Hans > I see very similar posts in the German language list from the last two > years but as Tobias Schwibingerr or similar - also signed by a Sophie > > When I asked this question some time ago, it seems that the German language > list had concluded that this person might be a troll (or even a psychology > experiment / AI) :( > > Like you, I have attempted to engage - but I think none of us will see > any change - I think the German list pays no attention / may have blocked > this user. >
Postponed publickey before Accepted publickey - what's happening there then?
Hi, I typically have logcheck send me anomalous logs. In the last week, all Debian 10 machines (I know, I know, upgrade needed) started logging this whenever I logged in from a particular other host by SSH: 2024-01-27T07:59:42.003881+00:00 t.example.com sshd[12319]: Postponed publickey for root from 2001:db8:1f1:f0c2::2 port 37032 ssh2 [preauth] 2024-01-27T07:59:42.01+00:00 t.example.com sshd[12319]: Accepted publickey for root from 2001:db8:1f1:f0c2::2 port 37032 ssh2: RSA SHA256:iC8C78UYVJdr+bsqV1hbtBFuft6KHi0b8i308Zn0C9o 2024-01-27T07:59:42.020718+00:00 t.example.com sshd[12319]: pam_unix(sshd:session): session opened for user root by (uid=0) 2024-01-27T07:59:42.033599+00:00 t.example.com systemd-logind[1729]: New session 18604 of user root. (host names and IPv6 addresses are made up as not relevant here) As you can see, this login was successful. What I had not seen before was the line: 2024-01-27T07:59:42.003881+00:00 t.example.com sshd[12319]: Postponed publickey for root from 2001:db8:1f1:f0c2::2 port 37032 ssh2 [preauth] This only happens when I log in as root using a public key, i.e. ssh -i /path/to/pubkey r...@t.example.com (though in reality a script doing this, but I can replicate the same when doing it manually). The "postponed" line doesn't happen when I log in by key as my own user. What is actually happening there to cause that line to be logged then? Is it possibly something to do with my ssh-agent having another key that would allow that to work, but it waits to use the key specified on the ssh command line? I am not aware of any change made in the last week or two that would cause this to start happening, although I did reboot the client host (2001:db8:1f1:f0c2::2 here) in that time frame so possibly my ssh-agent environment has changed in some way. Thanks, ]Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
