Re: [DNG] ..should we set up our own usage policy wizard script?, was: OpenSSH: delay on beowulf
Quoting Dr. Nikolaus Klepp (dr.kl...@gmx.at): > The problem only exists if all of these conditions are met: > > - kernel 4.19. from beowulf > - network up, but DNS of ISP not reacting in time or dhcpcd did not > get a lease > - sshd_config has "UseDNS yes" > - first try to start sshd after boot > > The problem is solved by "UseDNS no" in sshd_config. > > Now that sshd uses DNS on first startup is quite surprising - at least > it was for me. I'm not. Having DNS information in your logging is valuable. In my opinion, instead of turning off sshd's lookup of DNS information, you should fix the broken DNS. I.e., solve the correct problem, not the wrong one. In particular, you should make sure you are not reliant on ISP DNS, e.g., either run some variety of local nameservice or have needed entries in /etc/hosts or bothIn particular, you should make sure you are not reliant on ISP DNS, e.g., either run some variety of local nameservice or have needed entries in /etc/hosts or both. (Even where ISP DNS is reliably reachable, it's reliably terrible.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] When programs take many seconds to start
Quoting Steve Litt (sl...@troubleshooters.com): > Hi all, > > Another thread spoke of 10+ seconds for sshd to spin up, and several > pointed to DNS. Back around the turn of the century I used to have > these problems, at bootup, frequently. I finally found out that this > happens when reverse DNS doesn't work. > > Nowadays, if I have long startup, the first thing I do make sure all my > forward DNS, especially for localhost and my computer's hostname vs ip > address. Amen to that. Also, there can be subtle delay problems caused by an attempt to do IPv6 DNS resolution, waiting for timeout, and then following up by IPv4 resolution. Test for that using dig's handy '-4' and '-6' switches. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] When programs take many seconds to start
Hi all, Another thread spoke of 10+ seconds for sshd to spin up, and several pointed to DNS. Back around the turn of the century I used to have these problems, at bootup, frequently. I finally found out that this happens when reverse DNS doesn't work. Nowadays, if I have long startup, the first thing I do make sure all my forward DNS, especially for localhost and my computer's hostname vs ip address. I always make sure my boot doesn't throw up a splash screen, so that if nfsd takes 20 seconds to start, I know it. SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Solved] Help testing new policykit in Beowulf
> On Sun, Feb 10, 2019 at 11:35:22PM +, stanz wrote: > > > > Could you make sure policykit-1-gnome is installed and then try again. > > > > Was Not Installed - installed, & after Reboot, IT WORKS! > > Would this fix make that package become a dependency(at install)? > > And would this justify a bug report, adding the need to install 2 different > > pkgs, > > to get 2 different programs working proper? > > What are the names of the 2 different packages - to report? (I don't know :) > > Good! > > By all means file a bug report against policykit-1. But I already have a patch > for policykit-1 to add Recommends: polkit-1-auth-agent queued for inclusion. > > Once you have policykit-1-gnome installed do you still need gvfs? > > Mark No. I purged gvfs and plugged in a usb - it mounted, I accessed..All Good!! Thx again Mark! signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] beowulf: thinkpad_acpi floods logfile
Quoting Dr. Nikolaus Klepp (dr.kl...@gmx.at): > Hi! > > I've found another strange thing after upgradeing to beowulf: > thinkpad_acpi floods dmesg with these messages: > > [ 21.025368] thinkpad_acpi: acpi_evalf(BCSG, dd, ...) failed: AE_NOT_FOUND > [ 21.025372] ACPI: \_SB_.PCI0.LPC_.EC__.HKEY: BCSG: evaluate failed > [ 22.841660] thinkpad_acpi: acpi_evalf(BCTG, dd, ...) failed: AE_NOT_FOUND > [ 22.841668] ACPI: \_SB_.PCI0.LPC_.EC__.HKEY: BCTG: evaluate failed > [ 22.841702] thinkpad_acpi: acpi_evalf(BCSG, dd, ...) failed: AE_NOT_FOUND > [ 22.841705] ACPI: \_SB_.PCI0.LPC_.EC__.HKEY: BCSG: evaluate failed > [ 23.665919] thinkpad_acpi: acpi_evalf(BCTG, dd, ...) failed: AE_NOT_FOUND > [ 23.665928] ACPI: \_SB_.PCI0.LPC_.EC__.HKEY: BCTG: evaluate failed > [ 23.665964] thinkpad_acpi: acpi_evalf(BCSG, dd, ...) failed: AE_NOT_FOUND > [ 23.665967] ACPI: \_SB_.PCI0.LPC_.EC__.HKEY: BCSG: evaluate failed > [ 29.129438] thinkpad_acpi: acpi_evalf(BCTG, dd, ...) failed: AE_NOT_FOUND > [ 29.129456] ACPI: \_SB_.PCI0.LPC_.EC__.HKEY: BCTG: evaluate failed > [ 29.129537] thinkpad_acpi: acpi_evalf(BCSG, dd, ...) failed: AE_NOT_FOUND > > This was not the case on ascii. Does anybody know how to stop this - > despite downgrading to kernel 4.9 ? I don't have your answer, but I have partial information: BCSG is short for BatteryCharge Capacity Threshold, which is one component of the ACPI information being monitored. Details: https://lore.kernel.org/patchwork/patch/858076/ https://www.reddit.com/r/thinkpad/comments/7hde0c/patch_for_linux_kernel_to_support_start_and_stop/ I'll bet something in thinkpad_acpi is trying to parse information from the hardware and failing concerning that one datum, and grumbling about the fact in dmesg (i.e., your pre-beowulf kernel didn't try to parse BCTG information, lacking the code patch to add that functionality to thinkpad_acpi, while the beowulf one tries and fails). I'll also bet that it doesn't really matter, though I'm no expert at the details of ACPI in ThinkPads. It might be that updating your system BIOS would make this go away, though that's pure speculation on my part. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Installing Steam on Devuan
I'm running two ASCII installs and am running Steam on both without issue. One is a laptop with an Intel video card which I mostly just use to keep in touch with my Steam peeps. However, I have verified that it will start and run games without crashing. Although, with the Intel graphics card I can't competitively play anything other than the games based on the original Half-Life engine, like the original CS. The other is my desktop with an Nvidia 760GTX with the Nvidia proprietary drivers which I use for my primary gaming rig. I use the Steam deb binary from https://www.steampowered.com. I'm just spit-balling here, but I have seen the exact error that is listed in this thread. In my experience, it was due to the fact that when you installed your graphics driver, you didn't install the 32bit libs with it. Even if you have the 32bit system libs, it still requires a 32bit graphics libs. The Nvidia proprietary driver specifically asks about this when installing. I have never been able to play any Steam game on Linux with an ATI card. It will install and run, but the graphics are so choppy, it's unplayable. HTH, *Linux O'Beardly* linux.obear...@gmail.com http://o.beard.ly On Mon, Feb 11, 2019 at 6:06 AM hal wrote: > > > On 2/10/19 3:25 PM, Adam Borowski wrote: > > > > your box please "dpkg --add-architecture i386". > > Ahh, yes. It's there now. > > > There's a number of reason why proprietary software is bad, but if you > want > > to use it anyway, it's much better to use the packaged client which has > been > > beaten to play nice with the rest of the distribution rather than the > > vendor's version. > > Thanks. Still getting the glxChooseVisual error. Something to do with > support libs or I suspect leftovers from the downloaded package from > steampowered.com which I installed earlier. > > $ steam > ... > glXChooseVisual failed > glXChooseVisual failedMain.cpp (332) : Assertion Failed: Fatal Error: > glXChooseVisual failed > ... > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..should we set up our own usage policy wizard script?, was: OpenSSH: delay on beowulf
Anno domini 2019 Mon, 11 Feb 15:17:16 +0100 KatolaZ scripsit: > On Mon, Feb 11, 2019 at 11:25:03AM +0100, Dr. Nikolaus Klepp wrote: > > Anno domini 2019 Mon, 11 Feb 10:51:09 +0100 > > Didier Kryn scripsit: > > > Le 10/02/2019 à 18:19, Arnt Karlsen a écrit : > > > >> > > > >> There's nothing in the logs. It just takes verry long to start. > > > > > > > > > Tried to set LogLevel in sshd_config? > > > > > > or launch sshd with the -d option ? > > > > > > > > > Didier > > > > Hi! > > > > The problem only exists if all of these conditions are met: > > > > - kernel 4.19. from beowulf > > - network up, but DNS of ISP not reacting in time or dhcpcd did not get a > > lease > > - sshd_config has "UseDNS yes" > > - first try to start sshd after boot > > > > The problem is solved by "UseDNS no" in sshd_config. > > > > Now that sshd uses DNS on first startup is quite surprising - at least it > > was for me. > > > This is something you must have specified in your sshd_config, since > the default for sshd is to *not* UseDNS. From `man sshd_config`: > > UseDNS Specifies whether sshd(8) should look up the remote host name, > and to check that the resolved host name for the re‐ > mote IP address maps back to the very same IP address. > > If this option is set to no (the default) then only addresses > and not host names may be used in > ~/.ssh/authorized_keys from and sshd_config Match > Host directives. > > So sshd is trying to make sure that the IP it is listening on actually > maps back to the hostname. > > My2Cents > > KatolaZ > hi! I have taken over the suggested sshd_config from the package. The line that was in sshd_config said: # UseDNS no But this line actually leads to sshd waiting for DNS (maybe) to become ready or timeout. I have not yet have time to figure out what sshd is waiting for. Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..should we set up our own usage policy wizard script?, was: OpenSSH: delay on beowulf
On Mon, Feb 11, 2019 at 11:25:03AM +0100, Dr. Nikolaus Klepp wrote: > Anno domini 2019 Mon, 11 Feb 10:51:09 +0100 > Didier Kryn scripsit: > > Le 10/02/2019 à 18:19, Arnt Karlsen a écrit : > > >> > > >> There's nothing in the logs. It just takes verry long to start. > > > > > > Tried to set LogLevel in sshd_config? > > > > or launch sshd with the -d option ? > > > > > > Didier > > Hi! > > The problem only exists if all of these conditions are met: > > - kernel 4.19. from beowulf > - network up, but DNS of ISP not reacting in time or dhcpcd did not get a > lease > - sshd_config has "UseDNS yes" > - first try to start sshd after boot > > The problem is solved by "UseDNS no" in sshd_config. > > Now that sshd uses DNS on first startup is quite surprising - at least it was > for me. This is something you must have specified in your sshd_config, since the default for sshd is to *not* UseDNS. From `man sshd_config`: UseDNS Specifies whether sshd(8) should look up the remote host name, and to check that the resolved host name for the re‐ mote IP address maps back to the very same IP address. If this option is set to no (the default) then only addresses and not host names may be used in ~/.ssh/authorized_keys from and sshd_config Match Host directives. So sshd is trying to make sure that the IP it is listening on actually maps back to the hostname. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Solved] Help testing new policykit in Beowulf
On Sun, Feb 10, 2019 at 11:35:22PM +, stanz wrote: > > Could you make sure policykit-1-gnome is installed and then try again. > > Was Not Installed - installed, & after Reboot, IT WORKS! > > Would this fix make that package become a dependency(at install)? > > And would this justify a bug report, adding the need to install 2 different > pkgs, > to get 2 different programs working proper? > What are the names of the 2 different packages - to report? (I don't know :) Good! By all means file a bug report against policykit-1. But I already have a patch for policykit-1 to add Recommends: polkit-1-auth-agent queued for inclusion. Once you have policykit-1-gnome installed do you still need gvfs? Mark ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..should we set up our own usage policy wizard script?, was: OpenSSH: delay on beowulf
Hi Nik, Dr. Nikolaus Klepp writes: > Anno domini 2019 Mon, 11 Feb 10:51:09 +0100 > Didier Kryn scripsit: >> Le 10/02/2019 à 18:19, Arnt Karlsen a écrit: >> >> >> >> There's nothing in the logs. It just takes verry long to start. >> >> >> Tried to set LogLevel in sshd_config? >> >> or launch sshd with the -d option ? >> >> >> Didier > > Hi! > > The problem only exists if all of these conditions are met: > > - kernel 4.19. from beowulf > - network up, but DNS of ISP not reacting in time or dhcpcd did not get a > lease > - sshd_config has "UseDNS yes" > - first try to start sshd after boot > > The problem is solved by "UseDNS no" in sshd_config. I've turned that off at the office because our DHCP clients were not getting registered with the corporate DNS server(s). Made SSH client connections slow as molasses. > Now that sshd uses DNS on first startup is quite surprising - at least > it was for me. That UseDNS defaults to "yes" is not that surprising (it's a way to catch spoofing attempts), but I fail to understand why it would slow down the server's startup ... or, wait, I've seem something similar before ... a service trying to connect to an SMTP server at start up (if configured to use email notifications). So I'm guessing sshd tries to connect to a DNS server when this option is on to make sure DNS can be used. Perhaps it shouldn't and just try to resolve on a per request basis, seeing as service availability may come and go at any given time for a number of reasons. Hope this clarifies a bit, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..should we set up our own usage policy wizard script?, was: OpenSSH: delay on beowulf
On 2/10/19 3:44 PM, Adam Borowski wrote: The problem is that a number of unexpected programs call home. Possbily the Steam client as well. Note 'upload yes' in my crash dump output. This is typical for many games these days. $ steam ... crash_20190211045022_6.dmp[15237]: file ''/tmp/dumps/crash_20190211045022_6.dmp'', upload yes: ''CrashID=bp-c0fe5875-cdd6-4632-89c8-f31352190211'' ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Installing Steam on Devuan
On 2/10/19 3:25 PM, Adam Borowski wrote: your box please "dpkg --add-architecture i386". Ahh, yes. It's there now. There's a number of reason why proprietary software is bad, but if you want to use it anyway, it's much better to use the packaged client which has been beaten to play nice with the rest of the distribution rather than the vendor's version. Thanks. Still getting the glxChooseVisual error. Something to do with support libs or I suspect leftovers from the downloaded package from steampowered.com which I installed earlier. $ steam ... glXChooseVisual failed glXChooseVisual failedMain.cpp (332) : Assertion Failed: Fatal Error: glXChooseVisual failed ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..should we set up our own usage policy wizard script?, was: OpenSSH: delay on beowulf
Anno domini 2019 Mon, 11 Feb 10:51:09 +0100 Didier Kryn scripsit: > Le 10/02/2019 à 18:19, Arnt Karlsen a écrit : > >> > >> There's nothing in the logs. It just takes verry long to start. > > > Tried to set LogLevel in sshd_config? > > or launch sshd with the -d option ? > > > Didier Hi! The problem only exists if all of these conditions are met: - kernel 4.19. from beowulf - network up, but DNS of ISP not reacting in time or dhcpcd did not get a lease - sshd_config has "UseDNS yes" - first try to start sshd after boot The problem is solved by "UseDNS no" in sshd_config. Now that sshd uses DNS on first startup is quite surprising - at least it was for me. The other anoying thing is, that networking is not started in background and there is no option to force it to start in background. Desktop users usually prefer their GUI up and running, no matter if the network is ready or not. I had a pre-up script referenced in /etc/network/interfaces on ascii: allow-hotplug eth0 iface eth0 inet dhcp pre-up /home/nik/bin/pre-up That script checked /sys/class/net/$IFACE/carrier to detect the precence of the carrier signal on eth0. Now with the new kernel that file is not readable when eth0 is brought up and the pre-up script is executed, so I cannot check the presence of the carrier any more. A minute or two later - when /etc/init.d/networking failed - the said file readable, but not earlier. My workaround is to modify /etc/init.d/networking so that the "start)"-part is executed in background: 122c122 < process_options --- > ( process_options 143a144 > ) & Maybe not the best idea, but it definitly works reliably for desktop users. Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..should we set up our own usage policy wizard script?, was: OpenSSH: delay on beowulf
On Monday 11 February 2019 at 10:51:09, Didier Kryn wrote: > Le 10/02/2019 à 18:19, Arnt Karlsen a écrit : > >> There's nothing in the logs. It just takes verry long to start. > > Tried to set LogLevel in sshd_config? > > or launch sshd with the -d option ? Maybe run wireshark at both client and server end, see what packets get sent / received, see which end is delaying, and whether it's doing DNS or similar during the delay. Antony. -- Just when you think you're done, a cat floats by with buttered toast strapped to its back. - Steve Krug, "Don't make me think" Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..should we set up our own usage policy wizard script?, was: OpenSSH: delay on beowulf
Le 10/02/2019 à 18:19, Arnt Karlsen a écrit : There's nothing in the logs. It just takes verry long to start. Tried to set LogLevel in sshd_config? or launch sshd with the -d option ? Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
