Re: [DNG] OpenRC and Runit without SysVinit packages
On Thu, Oct 11, 2018 at 11:55:29PM -0400, Steve Litt wrote: > On Fri, 12 Oct 2018 03:24:44 + > alecfeld...@disroot.org wrote: > > > > 1. Split the runit package into separate packages with alternate > > stage files. > > > > 2. Provide a configuration file for how runit should act. For > > instance, if openrc or sysvinit is installed, runit can depend > > on /etc/init.d and /etc/rc*.d scripts for booting. > > On a related note, I think the best way of acquiring runit run files is > to install Void Linux on a VM, install all the various daemons, and > then view the run files in /etc/sv/$daemonname/run. > > Void has had enough time supporting runit that most of their run files > work great. The exceptions usually assume device names that shouldn't > be assumed. > > Devuan could thus acquire a whole bunch of run scripts and not have to > beg the upstreams to do it. > The main problem remains how to distribute those scripts, without having to fork all the packages that provide a runit script and don't have one in the corresponding Debian package. Any concrete proposal is welcome there (but I know that most of the simple ones won't work, since people willing to use runit want their preferred service to work ootb and already have runit scripts, and only when they install that specific server...). Also, we are not just talking of supporting either openrc or runit, but to add support for runit *on top* of sysvinit and openrc. We should definitely find a way through, but I can't see the optimal one at the moment :\ 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
[DNG] passwordless console autologin
Hallo, for a video display, I installed devuan with a passwordless console autologin, but my current configuration (below) gives me a "deprecated" warning: /etc/login.defs NO_PASSWORD_CONSOLE tty1 /etc/inittab 1:2345:respawn:/sbin/getty --autologin devuan tty1 Is there an up-to-date solution to achieve this? Thank you and libre Grüße, Florian -- [message sent mobile] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Runit without SysVinit packages
On Fri, Oct 12, 2018 at 10:56:26AM +0200, KatolaZ wrote: > On Thu, Oct 11, 2018 at 11:55:29PM -0400, Steve Litt wrote: > > On Fri, 12 Oct 2018 03:24:44 + > > alecfeld...@disroot.org wrote: > > > > > > > 1. Split the runit package into separate packages with alternate > > > stage files. > > > > > > 2. Provide a configuration file for how runit should act. For > > > instance, if openrc or sysvinit is installed, runit can depend > > > on /etc/init.d and /etc/rc*.d scripts for booting. > > > > On a related note, I think the best way of acquiring runit run files is > > to install Void Linux on a VM, install all the various daemons, and > > then view the run files in /etc/sv/$daemonname/run. > > > > Void has had enough time supporting runit that most of their run files > > work great. The exceptions usually assume device names that shouldn't > > be assumed. > > > > Devuan could thus acquire a whole bunch of run scripts and not have to > > beg the upstreams to do it. > > > > The main problem remains how to distribute those scripts, without > having to fork all the packages that provide a runit script and don't > have one in the corresponding Debian package. Any concrete proposal is > welcome there (but I know that most of the simple ones won't work, > since people willing to use runit want their preferred service to work > ootb and already have runit scripts, and only when they install that > specific server...). > > Also, we are not just talking of supporting either openrc or runit, > but to add support for runit *on top* of sysvinit and openrc. And while we're at it, we want not to support systemd. But living with inert systemd scripts is at least tolerable. Ideally there should be some systematic solution for all of this, leaving the choices to the sysadmin, but I don't see it as easy. -- hendrik > > We should definitely find a way through, but I can't see the optimal > one at the moment :\ > > 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 ] > ___ > 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] passwordless console autologin
Am 12. Oktober 2018 15:42:54 MESZ schrieb fsmithred : > On 10/12/2018 08:14 AM, Florian Zieboll wrote: > > Hallo, > > > > for a video display, I installed devuan with a passwordless console > autologin, but my current configuration (below) gives me a > "deprecated" warning: > > > > /etc/login.defs > > NO_PASSWORD_CONSOLE tty1 > > > > /etc/inittab > > 1:2345:respawn:/sbin/getty --autologin devuan tty1 > > > > Is there an up-to-date solution to achieve this? > > > > Thank you and libre Grüße, > > Florian > > > > > live-config edits inittab to use this: > 1:2345:respawn:/bin/login -f user /dev/tty1 2>&1 > > where user is the login name. It does not use /etc/login.defs, and the > line you posted is commented out with a warning that it's obsolete. > > fsmithred Very nice, thank you! (I guess it's OK to reply to the list?!) Florian -- [message sent mobile] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Runit without SysVinit packages
On 12/10/18 at 15:44, Hendrik Boom wrote: > living with inert systemd scripts Uh? What scripts? What systemd scripts (i.e. executable, interpreted text files) do Devuan packages install? Alessandro -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] passwordless console autologin
On 12/10/18 at 14:14, Florian Zieboll wrote: > Hallo, > > for a video display, I installed devuan with a passwordless console > autologin, but my current configuration (below) gives me a "deprecated" > warning: > > /etc/login.defs > NO_PASSWORD_CONSOLE tty1 > > /etc/inittab > 1:2345:respawn:/sbin/getty --autologin devuan tty1 > > Is there an up-to-date solution to achieve this? Passwordless accounts is a feature that was taken over by PAM. In man pam_unix(8) I can read: nullok The default action of this module is to not permit the user access to a service if their official password is blank. The nullok argument overrides this default and allows any user with a blank password to access the service. So, you should add this parameter to those pam config files in /etc/pam.d/ that use pam_unix and hope it works. PAM can easily get out of hand and mess up your system, so be careful and have backup copies of your pam.d files in case you lock yourself out of your box for an invalid PAM login configuration. Alessandro -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Weird network issue - slow to resolve IPs
Greetings everyone, Something funny is going on with my networking. It's taking a very long time to resolve host IPs across all browsers. It's been happening for a week or two but I'm just now getting annoyed enough to troubleshoot. When I ping Google at 8.8.8.8 or various websites, they arrive immediately but just keep knocking on the door and never fully resolve. After several interminable seconds, pages do eventually come up. Talked to my ISP and they are sending someone out tomorrow. Just want to make sure this isn't something on my end. My networking knowledge is very limited - I just plug in the cable - and other than a ping have no idea how to troubleshoot this. I'm wondering if I might have to open an incoming port? (Apologies if that's a really stupid idea.) Just wondering if anyone else is experiencing this after recent updates or might have ideas what might be happening not ISP-related. Hoping to learn something in the process. Cheers, golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] passwordless console autologin
On 10/12/2018 11:39 AM, Florian Zieboll wrote: > > Very nice, thank you! (I guess it's OK to reply to the list?!) > > Florian > > Yes, I clicked the wrong button. (I guess I need more practice.) fsmithred ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On 12-10-18 21:21, goli...@dyne.org wrote: > Greetings everyone, > > Something funny is going on with my networking. It's taking a very > long time to resolve host IPs across all browsers. It's been happening > for a week or two but I'm just now getting annoyed enough to > troubleshoot. > > When I ping Google at 8.8.8.8 or various websites, they arrive > immediately but just keep knocking on the door and never fully > resolve. After several interminable seconds, pages do eventually come > up. > > Talked to my ISP and they are sending someone out tomorrow. Just want > to make sure this isn't something on my end. My networking knowledge > is very limited - I just plug in the cable - and other than a ping > have no idea how to troubleshoot this. I'm wondering if I might have > to open an incoming port? (Apologies if that's a really stupid idea.) > > Just wondering if anyone else is experiencing this after recent > updates or might have ideas what might be happening not ISP-related. > Hoping to learn something in the process. > > Cheers, > > golinux > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng I had something similar but with ssh. Some debugging learned that IPv6 was preferred but my ISP connection does not have IPv6. After 60 seconds ssh time out and changed back to IPv4 and made connection after all. After this discovery I disabled IPv6 on my local network. Grtz. Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
Quoting info at smallinnovations dot nl (i...@smallinnovations.nl): > I had something similar but with ssh. Some debugging learned that IPv6 > was preferred but my ISP connection does not have IPv6. After 60 seconds > ssh time out and changed back to IPv4 and made connection after all. > After this discovery I disabled IPv6 on my local network. This is a common problem and is why you shouldn't test networking problems using Web browsers, but rather with simple command-line tools such as dig, ping, traceroute, and tcptracroute. I note that dig has flags '-4' and '-6' to limit DNS resolution to only IPv4 or only IPv6, respectively. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On 2018-10-12 15:25, Rick Moen wrote: Quoting info at smallinnovations dot nl (i...@smallinnovations.nl): I had something similar but with ssh. Some debugging learned that IPv6 was preferred but my ISP connection does not have IPv6. After 60 seconds ssh time out and changed back to IPv4 and made connection after all. After this discovery I disabled IPv6 on my local network. This is a common problem and is why you shouldn't test networking problems using Web browsers, but rather with simple command-line tools such as dig, ping, traceroute, and tcptracroute. I note that dig has flags '-4' and '-6' to limit DNS resolution to only IPv4 or only IPv6, respectively. ___ Thanks for the responses. I suspect that IPv6 might indeed be the culprit. Let me start by posting a traceroute to google.com: $ traceroute google.com traceroute to google.com (74.125.129.102), 30 hops max, 60 byte packets 1 * * * 2 tge0-0-0.ausdtx2802h.texas.rr.com (66.68.2.205) 45.543 ms 46.092 ms 46.373 ms 3 agg30.ausxtxir02r.texas.rr.com (24.175.42.144) 24.660 ms 25.364 ms 25.750 ms 4 agg22.hstqtxl301r.texas.rr.com (24.175.41.48) 31.765 ms 36.379 ms 35.651 ms 5 ae-1-0.p0.atl90.tbone.rr.com (66.109.1.218) 50.802 ms 44.462 ms 39.178 ms 6 bu-ether12.dllstx976iw-bcr00.tbone.rr.com (66.109.6.39) 45.106 ms 34.283 ms 107.14.19.49 (107.14.19.49) 36.338 ms 7 0.ae1.pr1.dfw10.tbone.rr.com (107.14.17.234) 35.058 ms 0.ae2.pr1.dfw10.tbone.rr.com (107.14.17.236) 27.868 ms 25.589 ms 8 ix-ae-23-0.tcore2.dt8-dallas.as6453.net (66.110.57.97) 32.475 ms 39.941 ms 52.998 ms 9 74.125.50.214 (74.125.50.214) 31.421 ms 34.253 ms 38.467 ms 10 * * * 11 216.239.63.238 (216.239.63.238) 34.677 ms 108.170.226.56 (108.170.226.56) 29.073 ms 108.170.226.182 (108.170.226.182) 29.651 ms 12 108.170.240.145 (108.170.240.145) 29.667 ms 108.170.240.209 (108.170.240.209) 32.095 ms 108.170.252.130 (108.170.252.130) 34.320 ms 13 216.239.59.168 (216.239.59.168) 29.987 ms 108.170.233.117 (108.170.233.117) 30.326 ms 108.170.228.84 (108.170.228.84) 31.091 ms 14 209.85.250.37 (209.85.250.37) 30.081 ms 38.277 ms 35.229 ms 15 209.85.246.182 (209.85.246.182) 56.902 ms 209.85.246.84 (209.85.246.84) 77.541 ms 209.85.246.182 (209.85.246.182) 73.471 ms 16 216.239.56.175 (216.239.56.175) 63.061 ms 216.239.54.65 (216.239.54.65) 61.564 ms 216.239.48.67 (216.239.48.67) 65.893 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 jm-in-f102.1e100.net (74.125.129.102) 168.457 ms 171.191 ms 170.337 ms Good grief!!! Another trace route eventually got to one of my websites: $ traceroute stopcta.info traceroute to stopcta.info (185.203.114.117), 30 hops max, 60 byte packets 1 * * * 2 tge0-0-0.ausdtx2801h.texas.rr.com (66.68.2.201) 330.761 ms 331.380 ms 331.773 ms 3 agg30.ausutxla01r.texas.rr.com (24.175.42.142) 25.345 ms 26.732 ms 27.302 ms 4 agg22.dllatxl301r.texas.rr.com (24.175.41.46) 37.000 ms 33.044 ms 37.558 ms 5 bu-ether14.dllstx976iw-bcr00.tbone.rr.com (66.109.6.88) 41.860 ms 66.109.1.216 (66.109.1.216) 40.157 ms 41.325 ms 6 66.109.5.121 (66.109.5.121) 31.192 ms 42.090 ms 25.595 ms 7 dls-b21-link.telia.net (62.115.156.208) 27.346 ms 28.104 ms 27.084 ms 8 atl-b22-link.telia.net (80.91.246.74) 49.968 ms 58.985 ms 49.461 ms 9 mai-b1-link.telia.net (62.115.122.53) 69.445 ms 67.043 ms 59.106 ms 10 init7-ic-318278-mai-b1.c.telia.net (62.115.148.55) 70.009 ms 77.143 ms 72.151 ms 11 r2nyc3.core.init7.net (193.47.153.231) 71.850 ms 70.682 ms 78.191 ms 12 r1nyc3.core.init7.net (193.47.153.238) 80.221 ms 73.209 ms 69.531 ms 13 r1nyc2.core.init7.net (193.47.153.234) 84.886 ms 74.355 ms 70.098 ms 14 r1lon2.core.init7.net (77.109.128.14) 140.249 ms 140.124 ms 147.072 ms 15 r1bsl1.core.init7.net (77.109.128.102) 173.037 ms 162.066 ms 164.498 ms 16 r1zrh2.core.init7.net (77.109.128.129) 159.150 ms 152.605 ms r1bsl3.core.init7.net (82.197.168.18) 160.159 ms 17 r1glb1.core.init7.net (77.109.128.238) 165.343 ms r1zrh8.core.init7.net (82.197.168.74) 155.252 ms r1glb1.core.init7.net (77.109.128.238) 171.133 ms 18 empty.init7.net (77.109.141.139) 159.961 ms 156.963 ms 165.937 ms 19 * r1glb1.core.init7.net (77.109.140.205) 156.057 ms 159.736 ms 20 empty.init7.net (77.109.141.139) 165.136 ms 117-114-203-185.place5.ungleich.ch (185.203.114.117) 169.960 ms empty.init7.net (77.109.141.139) 161.785 ms I (or rather Evilham and Nico) recently moved my websites to a devuan IPv6 VPS which is set up to serve IPv4 too through some sort of server-side magic I don't really understand. I suspect this might be what triggered things. I am clueless how to test if IPv6 is actually enabled on my network or how to disable it if it is. Maybe someone can save me some hours of searching? I really need to work on the refracta website
Re: [DNG] Weird network issue - slow to resolve IPs
On 12-10-18 23:35, goli...@dyne.org wrote: > On 2018-10-12 15:25, Rick Moen wrote: >> Quoting info at smallinnovations dot nl (i...@smallinnovations.nl): >> >>> I had something similar but with ssh. Some debugging learned that IPv6 >>> was preferred but my ISP connection does not have IPv6. After 60 >>> seconds >>> ssh time out and changed back to IPv4 and made connection after all. >>> After this discovery I disabled IPv6 on my local network. >> >> This is a common problem and is why you shouldn't test networking >> problems using Web browsers, but rather with simple command-line tools >> such as dig, ping, traceroute, and tcptracroute. >> >> I note that dig has flags '-4' and '-6' to limit DNS resolution to only >> IPv4 or only IPv6, respectively. >> ___ >> > Thanks for the responses. I suspect that IPv6 might indeed be the > culprit. > > Let me start by posting a traceroute to google.com: > > $ traceroute google.com > traceroute to google.com (74.125.129.102), 30 hops max, 60 byte packets > 1 * * * > 2 tge0-0-0.ausdtx2802h.texas.rr.com (66.68.2.205) 45.543 ms 46.092 > ms 46.373 ms > 3 agg30.ausxtxir02r.texas.rr.com (24.175.42.144) 24.660 ms 25.364 > ms 25.750 ms > 4 agg22.hstqtxl301r.texas.rr.com (24.175.41.48) 31.765 ms 36.379 > ms 35.651 ms > 5 ae-1-0.p0.atl90.tbone.rr.com (66.109.1.218) 50.802 ms 44.462 ms > 39.178 ms > 6 bu-ether12.dllstx976iw-bcr00.tbone.rr.com (66.109.6.39) 45.106 > ms 34.283 ms 107.14.19.49 (107.14.19.49) 36.338 ms > 7 0.ae1.pr1.dfw10.tbone.rr.com (107.14.17.234) 35.058 ms > 0.ae2.pr1.dfw10.tbone.rr.com (107.14.17.236) 27.868 ms 25.589 ms > 8 ix-ae-23-0.tcore2.dt8-dallas.as6453.net (66.110.57.97) 32.475 ms > 39.941 ms 52.998 ms > 9 74.125.50.214 (74.125.50.214) 31.421 ms 34.253 ms 38.467 ms > 10 * * * > 11 216.239.63.238 (216.239.63.238) 34.677 ms 108.170.226.56 > (108.170.226.56) 29.073 ms 108.170.226.182 (108.170.226.182) 29.651 ms > 12 108.170.240.145 (108.170.240.145) 29.667 ms 108.170.240.209 > (108.170.240.209) 32.095 ms 108.170.252.130 (108.170.252.130) 34.320 ms > 13 216.239.59.168 (216.239.59.168) 29.987 ms 108.170.233.117 > (108.170.233.117) 30.326 ms 108.170.228.84 (108.170.228.84) 31.091 ms > 14 209.85.250.37 (209.85.250.37) 30.081 ms 38.277 ms 35.229 ms > 15 209.85.246.182 (209.85.246.182) 56.902 ms 209.85.246.84 > (209.85.246.84) 77.541 ms 209.85.246.182 (209.85.246.182) 73.471 ms > 16 216.239.56.175 (216.239.56.175) 63.061 ms 216.239.54.65 > (216.239.54.65) 61.564 ms 216.239.48.67 (216.239.48.67) 65.893 ms > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 jm-in-f102.1e100.net (74.125.129.102) 168.457 ms 171.191 ms > 170.337 ms > > Good grief!!! Another trace route eventually got to one of my websites: > > $ traceroute stopcta.info > traceroute to stopcta.info (185.203.114.117), 30 hops max, 60 byte > packets > 1 * * * > 2 tge0-0-0.ausdtx2801h.texas.rr.com (66.68.2.201) 330.761 ms > 331.380 ms 331.773 ms > 3 agg30.ausutxla01r.texas.rr.com (24.175.42.142) 25.345 ms 26.732 > ms 27.302 ms > 4 agg22.dllatxl301r.texas.rr.com (24.175.41.46) 37.000 ms 33.044 > ms 37.558 ms > 5 bu-ether14.dllstx976iw-bcr00.tbone.rr.com (66.109.6.88) 41.860 ms > 66.109.1.216 (66.109.1.216) 40.157 ms 41.325 ms > 6 66.109.5.121 (66.109.5.121) 31.192 ms 42.090 ms 25.595 ms > 7 dls-b21-link.telia.net (62.115.156.208) 27.346 ms 28.104 ms > 27.084 ms > 8 atl-b22-link.telia.net (80.91.246.74) 49.968 ms 58.985 ms > 49.461 ms > 9 mai-b1-link.telia.net (62.115.122.53) 69.445 ms 67.043 ms > 59.106 ms > 10 init7-ic-318278-mai-b1.c.telia.net (62.115.148.55) 70.009 ms > 77.143 ms 72.151 ms > 11 r2nyc3.core.init7.net (193.47.153.231) 71.850 ms 70.682 ms > 78.191 ms > 12 r1nyc3.core.init7.net (193.47.153.238) 80.221 ms 73.209 ms > 69.531 ms > 13 r1nyc2.core.init7.net (193.47.153.234) 84.886 ms 74.355 ms > 70.098 ms > 14 r1lon2.core.init7.net (77.109.128.14) 140.249 ms 140.124 ms > 147.072 ms > 15 r1bsl1.core.init7.net (77.109.128.102) 173.037 ms 162.066 ms > 164.498 ms > 16 r1zrh2.core.init7.net (77.109.128.129) 159.150 ms 152.605 ms > r1bsl3.core.init7.net (82.197.168.18) 160.159 ms > 17 r1glb1.core.init7.net (77.109.128.238) 165.343 ms > r1zrh8.core.init7.net (82.197.168.74) 155.252 ms > r1glb1.core.init7.net (77.109.128.238) 171.133 ms > 18 empty.init7.net (77.109.141.139) 159.961 ms 156.963 ms 165.937 ms > 19 * r1glb1.core.init7.net (77.109.140.205) 156.057 ms 159.736 ms > 20 empty.init7.net (77.109.141.139) 165.136 ms > 117-114-203-185.place5.ungleich.ch (185.203.114.117) 169.960 ms > empty.init7.net (77.109.141.139) 161.785 ms > > I (or rather Evilham and Nico) recently moved my websites to a devuan > IPv6 VPS which is set up to serve IPv4 too through some sort of > server-side magic I don't really understand. I suspect this might
Re: [DNG] passwordless console autologin
Le 12/10/2018 à 18:43, Alessandro Selli a écrit : On 12/10/18 at 14:14, Florian Zieboll wrote: Hallo, for a video display, I installed devuan with a passwordless console autologin, but my current configuration (below) gives me a "deprecated" warning: /etc/login.defs NO_PASSWORD_CONSOLE tty1 /etc/inittab 1:2345:respawn:/sbin/getty --autologin devuan tty1 Is there an up-to-date solution to achieve this? Passwordless accounts is a feature that was taken over by PAM. In man pam_unix(8) I can read: nullok The default action of this module is to not permit the user access to a service if their official password is blank. The nullok argument overrides this default and allows any user with a blank password to access the service. So, you should add this parameter to those pam config files in /etc/pam.d/ that use pam_unix and hope it works. PAM can easily get out of hand and mess up your system, so be careful and have backup copies of your pam.d files in case you lock yourself out of your box for an invalid PAM login configuration. Seems to me this doesn't solve the same problem. This PAM feature would apply to all sessions with the given user or even all users while the question was to enable autologin only on tty1 for only one user. And, yes, PAM can easily mess up the system. Better keep some backdoor when testing. ssh server can be easily configured to bypass PAM. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On 2018-10-12 17:06, info at smallinnovations dot nl wrote: On 12-10-18 23:35, goli...@dyne.org wrote: On 2018-10-12 15:25, Rick Moen wrote: Quoting info at smallinnovations dot nl (i...@smallinnovations.nl): I had something similar but with ssh. Some debugging learned that IPv6 was preferred but my ISP connection does not have IPv6. After 60 seconds ssh time out and changed back to IPv4 and made connection after all. After this discovery I disabled IPv6 on my local network. This is a common problem and is why you shouldn't test networking problems using Web browsers, but rather with simple command-line tools such as dig, ping, traceroute, and tcptracroute. I note that dig has flags '-4' and '-6' to limit DNS resolution to only IPv4 or only IPv6, respectively. ___ Thanks for the responses. I suspect that IPv6 might indeed be the culprit. Let me start by posting a traceroute to google.com: $ traceroute google.com traceroute to google.com (74.125.129.102), 30 hops max, 60 byte packets 1 * * * 2 tge0-0-0.ausdtx2802h.texas.rr.com (66.68.2.205) 45.543 ms 46.092 ms 46.373 ms 3 agg30.ausxtxir02r.texas.rr.com (24.175.42.144) 24.660 ms 25.364 ms 25.750 ms 4 agg22.hstqtxl301r.texas.rr.com (24.175.41.48) 31.765 ms 36.379 ms 35.651 ms 5 ae-1-0.p0.atl90.tbone.rr.com (66.109.1.218) 50.802 ms 44.462 ms 39.178 ms 6 bu-ether12.dllstx976iw-bcr00.tbone.rr.com (66.109.6.39) 45.106 ms 34.283 ms 107.14.19.49 (107.14.19.49) 36.338 ms 7 0.ae1.pr1.dfw10.tbone.rr.com (107.14.17.234) 35.058 ms 0.ae2.pr1.dfw10.tbone.rr.com (107.14.17.236) 27.868 ms 25.589 ms 8 ix-ae-23-0.tcore2.dt8-dallas.as6453.net (66.110.57.97) 32.475 ms 39.941 ms 52.998 ms 9 74.125.50.214 (74.125.50.214) 31.421 ms 34.253 ms 38.467 ms 10 * * * 11 216.239.63.238 (216.239.63.238) 34.677 ms 108.170.226.56 (108.170.226.56) 29.073 ms 108.170.226.182 (108.170.226.182) 29.651 ms 12 108.170.240.145 (108.170.240.145) 29.667 ms 108.170.240.209 (108.170.240.209) 32.095 ms 108.170.252.130 (108.170.252.130) 34.320 ms 13 216.239.59.168 (216.239.59.168) 29.987 ms 108.170.233.117 (108.170.233.117) 30.326 ms 108.170.228.84 (108.170.228.84) 31.091 ms 14 209.85.250.37 (209.85.250.37) 30.081 ms 38.277 ms 35.229 ms 15 209.85.246.182 (209.85.246.182) 56.902 ms 209.85.246.84 (209.85.246.84) 77.541 ms 209.85.246.182 (209.85.246.182) 73.471 ms 16 216.239.56.175 (216.239.56.175) 63.061 ms 216.239.54.65 (216.239.54.65) 61.564 ms 216.239.48.67 (216.239.48.67) 65.893 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 jm-in-f102.1e100.net (74.125.129.102) 168.457 ms 171.191 ms 170.337 ms Good grief!!! Another trace route eventually got to one of my websites: $ traceroute stopcta.info traceroute to stopcta.info (185.203.114.117), 30 hops max, 60 byte packets 1 * * * 2 tge0-0-0.ausdtx2801h.texas.rr.com (66.68.2.201) 330.761 ms 331.380 ms 331.773 ms 3 agg30.ausutxla01r.texas.rr.com (24.175.42.142) 25.345 ms 26.732 ms 27.302 ms 4 agg22.dllatxl301r.texas.rr.com (24.175.41.46) 37.000 ms 33.044 ms 37.558 ms 5 bu-ether14.dllstx976iw-bcr00.tbone.rr.com (66.109.6.88) 41.860 ms 66.109.1.216 (66.109.1.216) 40.157 ms 41.325 ms 6 66.109.5.121 (66.109.5.121) 31.192 ms 42.090 ms 25.595 ms 7 dls-b21-link.telia.net (62.115.156.208) 27.346 ms 28.104 ms 27.084 ms 8 atl-b22-link.telia.net (80.91.246.74) 49.968 ms 58.985 ms 49.461 ms 9 mai-b1-link.telia.net (62.115.122.53) 69.445 ms 67.043 ms 59.106 ms 10 init7-ic-318278-mai-b1.c.telia.net (62.115.148.55) 70.009 ms 77.143 ms 72.151 ms 11 r2nyc3.core.init7.net (193.47.153.231) 71.850 ms 70.682 ms 78.191 ms 12 r1nyc3.core.init7.net (193.47.153.238) 80.221 ms 73.209 ms 69.531 ms 13 r1nyc2.core.init7.net (193.47.153.234) 84.886 ms 74.355 ms 70.098 ms 14 r1lon2.core.init7.net (77.109.128.14) 140.249 ms 140.124 ms 147.072 ms 15 r1bsl1.core.init7.net (77.109.128.102) 173.037 ms 162.066 ms 164.498 ms 16 r1zrh2.core.init7.net (77.109.128.129) 159.150 ms 152.605 ms r1bsl3.core.init7.net (82.197.168.18) 160.159 ms 17 r1glb1.core.init7.net (77.109.128.238) 165.343 ms r1zrh8.core.init7.net (82.197.168.74) 155.252 ms r1glb1.core.init7.net (77.109.128.238) 171.133 ms 18 empty.init7.net (77.109.141.139) 159.961 ms 156.963 ms 165.937 ms 19 * r1glb1.core.init7.net (77.109.140.205) 156.057 ms 159.736 ms 20 empty.init7.net (77.109.141.139) 165.136 ms 117-114-203-185.place5.ungleich.ch (185.203.114.117) 169.960 ms empty.init7.net (77.109.141.139) 161.785 ms I (or rather Evilham and Nico) recently moved my websites to a devuan IPv6 VPS which is set up to serve IPv4 too through some sort of server-side magic I don't really understand. I suspect this might be what triggered things. I am clueless how to test if IPv6 is actually enabled on my network or how to disable it if it is. Maybe someone can save me
Re: [DNG] Weird network issue - slow to resolve IPs
Quoting goli...@dyne.org (goli...@dyne.org): > >Disabling IPv6 can be done with adding in /etc/sysctl.conf: > > > >net.ipv6.conf.all.disable_ipv6 = 1 > > > >and executing sysctl -p or reboot > > > >Grtz. > > > >Nick > > > > > > Thanks Nick. Much appreciated. Will sort that later and report back. Well, might make it really difficult to use transport to a IPv6 VPS, that way. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On Saturday 13 October 2018 at 00:26:04, Rick Moen wrote: > Quoting goli...@dyne.org: > > >Disabling IPv6 can be done with adding in /etc/sysctl.conf: > > > > > >net.ipv6.conf.all.disable_ipv6 = 1 > > > > > >and executing sysctl -p or reboot > > > Well, might make it really difficult to use transport to a IPv6 VPS, > that way. True, if it's IPv6 *only*. That's pretty unusual at present. Antony. -- If you were ploughing a field, which would you rather use - two strong oxen or 1024 chickens? - Seymour Cray, pioneer of supercomputing 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] Weird network issue - slow to resolve IPs
Quoting Antony Stone (antony.st...@devuan.open.source.it): > True, if it's IPv6 *only*. > > That's pretty unusual at present. My point being that this assumption should be borne in mind and if necessary revisited, if shutting off IPV6. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On Fri, Oct 12, 2018 at 04:35:17PM -0500, goli...@dyne.org wrote: > Thanks for the responses. I suspect that IPv6 might indeed be the culprit. I doubt it, since both traceroutes are using IPv4, and both have odd delays. > $ traceroute google.com > traceroute to google.com (74.125.129.102), 30 hops max, 60 byte packets > 1 * * * > 2 tge0-0-0.ausdtx2802h.texas.rr.com (66.68.2.205) 45.543 ms 46.092 ms > 46.373 ms > 3 agg30.ausxtxir02r.texas.rr.com (24.175.42.144) 24.660 ms 25.364 ms > 25.750 ms > 4 agg22.hstqtxl301r.texas.rr.com (24.175.41.48) 31.765 ms 36.379 ms > 35.651 ms > 5 ae-1-0.p0.atl90.tbone.rr.com (66.109.1.218) 50.802 ms 44.462 ms > 39.178 ms > 6 bu-ether12.dllstx976iw-bcr00.tbone.rr.com (66.109.6.39) 45.106 ms > 34.283 ms 107.14.19.49 (107.14.19.49) 36.338 ms > 7 0.ae1.pr1.dfw10.tbone.rr.com (107.14.17.234) 35.058 ms > 0.ae2.pr1.dfw10.tbone.rr.com (107.14.17.236) 27.868 ms 25.589 ms > 8 ix-ae-23-0.tcore2.dt8-dallas.as6453.net (66.110.57.97) 32.475 ms > 39.941 ms 52.998 ms > 9 74.125.50.214 (74.125.50.214) 31.421 ms 34.253 ms 38.467 ms > 10 * * * > 11 216.239.63.238 (216.239.63.238) 34.677 ms 108.170.226.56 > (108.170.226.56) 29.073 ms 108.170.226.182 (108.170.226.182) 29.651 ms > 12 108.170.240.145 (108.170.240.145) 29.667 ms 108.170.240.209 > (108.170.240.209) 32.095 ms 108.170.252.130 (108.170.252.130) 34.320 ms > 13 216.239.59.168 (216.239.59.168) 29.987 ms 108.170.233.117 > (108.170.233.117) 30.326 ms 108.170.228.84 (108.170.228.84) 31.091 ms > 14 209.85.250.37 (209.85.250.37) 30.081 ms 38.277 ms 35.229 ms > 15 209.85.246.182 (209.85.246.182) 56.902 ms 209.85.246.84 (209.85.246.84) > 77.541 ms 209.85.246.182 (209.85.246.182) 73.471 ms Looks to me like dropped packets start around here: > 16 216.239.56.175 (216.239.56.175) 63.061 ms 216.239.54.65 (216.239.54.65) > 61.564 ms 216.239.48.67 (216.239.48.67) 65.893 ms > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 jm-in-f102.1e100.net (74.125.129.102) 168.457 ms 171.191 ms 170.337 > ms > I reproduced the above traceroute to the same IP, and am seeing similar results, even though my packets took a different route from yours. This suggests it could be a problem with that particular IP. > Good grief!!! Another trace route eventually got to one of my websites: > > $ traceroute stopcta.info > traceroute to stopcta.info (185.203.114.117), 30 hops max, 60 byte packets > 1 * * * > 2 tge0-0-0.ausdtx2801h.texas.rr.com (66.68.2.201) 330.761 ms 331.380 ms > 331.773 ms > 3 agg30.ausutxla01r.texas.rr.com (24.175.42.142) 25.345 ms 26.732 ms > 27.302 ms > 4 agg22.dllatxl301r.texas.rr.com (24.175.41.46) 37.000 ms 33.044 ms > 37.558 ms > 5 bu-ether14.dllstx976iw-bcr00.tbone.rr.com (66.109.6.88) 41.860 ms > 66.109.1.216 (66.109.1.216) 40.157 ms 41.325 ms > 6 66.109.5.121 (66.109.5.121) 31.192 ms 42.090 ms 25.595 ms > 7 dls-b21-link.telia.net (62.115.156.208) 27.346 ms 28.104 ms 27.084 ms > 8 atl-b22-link.telia.net (80.91.246.74) 49.968 ms 58.985 ms 49.461 ms > 9 mai-b1-link.telia.net (62.115.122.53) 69.445 ms 67.043 ms 59.106 ms > 10 init7-ic-318278-mai-b1.c.telia.net (62.115.148.55) 70.009 ms 77.143 ms > 72.151 ms > 11 r2nyc3.core.init7.net (193.47.153.231) 71.850 ms 70.682 ms 78.191 ms > 12 r1nyc3.core.init7.net (193.47.153.238) 80.221 ms 73.209 ms 69.531 ms > 13 r1nyc2.core.init7.net (193.47.153.234) 84.886 ms 74.355 ms 70.098 ms A rather large delay seems to start here: > 14 r1lon2.core.init7.net (77.109.128.14) 140.249 ms 140.124 ms 147.072 > ms > 15 r1bsl1.core.init7.net (77.109.128.102) 173.037 ms 162.066 ms 164.498 > ms > 16 r1zrh2.core.init7.net (77.109.128.129) 159.150 ms 152.605 ms > r1bsl3.core.init7.net (82.197.168.18) 160.159 ms > 17 r1glb1.core.init7.net (77.109.128.238) 165.343 ms r1zrh8.core.init7.net > (82.197.168.74) 155.252 ms r1glb1.core.init7.net (77.109.128.238) 171.133 > ms > 18 empty.init7.net (77.109.141.139) 159.961 ms 156.963 ms 165.937 ms > 19 * r1glb1.core.init7.net (77.109.140.205) 156.057 ms 159.736 ms > 20 empty.init7.net (77.109.141.139) 165.136 ms > 117-114-203-185.place5.ungleich.ch (185.203.114.117) 169.960 ms > empty.init7.net (77.109.141.139) 161.785 ms > > I (or rather Evilham and Nico) recently moved my websites to a devuan IPv6 > VPS which is set up to serve IPv4 too through some sort of server-side magic > I don't really understand. I suspect this might be what triggered > things. It's possible. I reproduced this traceroute also, and am seeing the large delay as well. This suggests that everything is fine with your home network, as well as your ISP. > I > am clueless how to test if IPv6 is actually enabled on my network or how to > disable it if it is. If you've disabled IPv6 already, you'll need to enable it again first. Then, use traceroute6 (which actually just calls traceroute with the -6
Re: [DNG] Weird network issue - slow to resolve IPs
On 10/12/18 4:55 PM, Gregory Nowak wrote: On Fri, Oct 12, 2018 at 04:35:17PM -0500, goli...@dyne.org wrote: Thanks for the responses. I suspect that IPv6 might indeed be the culprit. I doubt it, since both traceroutes are using IPv4, and both have odd delays. $ traceroute google.com traceroute to google.com (74.125.129.102), 30 hops max, 60 byte packets 1 * * * 2 tge0-0-0.ausdtx2802h.texas.rr.com (66.68.2.205) 45.543 ms 46.092 ms 46.373 ms 3 agg30.ausxtxir02r.texas.rr.com (24.175.42.144) 24.660 ms 25.364 ms 25.750 ms 4 agg22.hstqtxl301r.texas.rr.com (24.175.41.48) 31.765 ms 36.379 ms 35.651 ms 5 ae-1-0.p0.atl90.tbone.rr.com (66.109.1.218) 50.802 ms 44.462 ms 39.178 ms 6 bu-ether12.dllstx976iw-bcr00.tbone.rr.com (66.109.6.39) 45.106 ms 34.283 ms 107.14.19.49 (107.14.19.49) 36.338 ms 7 0.ae1.pr1.dfw10.tbone.rr.com (107.14.17.234) 35.058 ms 0.ae2.pr1.dfw10.tbone.rr.com (107.14.17.236) 27.868 ms 25.589 ms 8 ix-ae-23-0.tcore2.dt8-dallas.as6453.net (66.110.57.97) 32.475 ms 39.941 ms 52.998 ms 9 74.125.50.214 (74.125.50.214) 31.421 ms 34.253 ms 38.467 ms 10 * * * 11 216.239.63.238 (216.239.63.238) 34.677 ms 108.170.226.56 (108.170.226.56) 29.073 ms 108.170.226.182 (108.170.226.182) 29.651 ms 12 108.170.240.145 (108.170.240.145) 29.667 ms 108.170.240.209 (108.170.240.209) 32.095 ms 108.170.252.130 (108.170.252.130) 34.320 ms 13 216.239.59.168 (216.239.59.168) 29.987 ms 108.170.233.117 (108.170.233.117) 30.326 ms 108.170.228.84 (108.170.228.84) 31.091 ms 14 209.85.250.37 (209.85.250.37) 30.081 ms 38.277 ms 35.229 ms 15 209.85.246.182 (209.85.246.182) 56.902 ms 209.85.246.84 (209.85.246.84) 77.541 ms 209.85.246.182 (209.85.246.182) 73.471 ms Looks to me like dropped packets start around here: 16 216.239.56.175 (216.239.56.175) 63.061 ms 216.239.54.65 (216.239.54.65) 61.564 ms 216.239.48.67 (216.239.48.67) 65.893 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 jm-in-f102.1e100.net (74.125.129.102) 168.457 ms 171.191 ms 170.337 ms I reproduced the above traceroute to the same IP, and am seeing similar results, even though my packets took a different route from yours. This suggests it could be a problem with that particular IP. Good grief!!! Another trace route eventually got to one of my websites: $ traceroute stopcta.info traceroute to stopcta.info (185.203.114.117), 30 hops max, 60 byte packets 1 * * * 2 tge0-0-0.ausdtx2801h.texas.rr.com (66.68.2.201) 330.761 ms 331.380 ms 331.773 ms 3 agg30.ausutxla01r.texas.rr.com (24.175.42.142) 25.345 ms 26.732 ms 27.302 ms 4 agg22.dllatxl301r.texas.rr.com (24.175.41.46) 37.000 ms 33.044 ms 37.558 ms 5 bu-ether14.dllstx976iw-bcr00.tbone.rr.com (66.109.6.88) 41.860 ms 66.109.1.216 (66.109.1.216) 40.157 ms 41.325 ms 6 66.109.5.121 (66.109.5.121) 31.192 ms 42.090 ms 25.595 ms 7 dls-b21-link.telia.net (62.115.156.208) 27.346 ms 28.104 ms 27.084 ms 8 atl-b22-link.telia.net (80.91.246.74) 49.968 ms 58.985 ms 49.461 ms 9 mai-b1-link.telia.net (62.115.122.53) 69.445 ms 67.043 ms 59.106 ms 10 init7-ic-318278-mai-b1.c.telia.net (62.115.148.55) 70.009 ms 77.143 ms 72.151 ms 11 r2nyc3.core.init7.net (193.47.153.231) 71.850 ms 70.682 ms 78.191 ms 12 r1nyc3.core.init7.net (193.47.153.238) 80.221 ms 73.209 ms 69.531 ms 13 r1nyc2.core.init7.net (193.47.153.234) 84.886 ms 74.355 ms 70.098 ms A rather large delay seems to start here: 14 r1lon2.core.init7.net (77.109.128.14) 140.249 ms 140.124 ms 147.072 ms 15 r1bsl1.core.init7.net (77.109.128.102) 173.037 ms 162.066 ms 164.498 ms 16 r1zrh2.core.init7.net (77.109.128.129) 159.150 ms 152.605 ms r1bsl3.core.init7.net (82.197.168.18) 160.159 ms 17 r1glb1.core.init7.net (77.109.128.238) 165.343 ms r1zrh8.core.init7.net (82.197.168.74) 155.252 ms r1glb1.core.init7.net (77.109.128.238) 171.133 ms 18 empty.init7.net (77.109.141.139) 159.961 ms 156.963 ms 165.937 ms 19 * r1glb1.core.init7.net (77.109.140.205) 156.057 ms 159.736 ms 20 empty.init7.net (77.109.141.139) 165.136 ms 117-114-203-185.place5.ungleich.ch (185.203.114.117) 169.960 ms empty.init7.net (77.109.141.139) 161.785 ms I (or rather Evilham and Nico) recently moved my websites to a devuan IPv6 VPS which is set up to serve IPv4 too through some sort of server-side magic I don't really understand. I suspect this might be what triggered things. It's possible. I reproduced this traceroute also, and am seeing the large delay as well. This suggests that everything is fine with your home network, as well as your ISP. I am clueless how to test if IPv6 is actually enabled on my network or how to disable it if it is. If you've disabled IPv6 already, you'll need to enable it again first. Then, use traceroute6 (which actually just calls traceroute with the -6 flag), like: traceroute6 google.com There are other ways of course, but that's probably the simplest. If y
Re: [DNG] GPL version 2 is a bare license. Recind. (Regarding (future) linux Code of Conduct Bannings).
On Wed, 10 Oct 2018 13:01:42 +0200 "Enrico Weigelt, metux IT consult" wrote: > * they're trying to introduce a kind of legal system into a tech > project this. It's the introduction of a parallel legal system. It is then used as a special exception to the actual legal system, as a tool of power. Ill-defined rules allow for biased interpretation. Too many rules allow for selective enforcement. This should be obvious. Why isn't this obvious? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GPL version 2 is a bare license. Recind. (Regarding (future) linux Code of Conduct Bannings).
On Wed, 10 Oct 2018 12:20:00 +0100 Rowland Penny wrote: > You know what, that sounds very like what the EU is trying to become, > thank your deity we are getting out of it. FYI, "The European Union".. 1) Internally refers to themselves as "The Union". 2) Has been making efforts to include countries in north Africa. *cough* guess what the result of that will be.. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GPL version 2 is a bare license. Recind. (Regarding (future) linux Code of Conduct Bannings).
On 2018-10-12 20:40, spiralofhope wrote: On Wed, 10 Oct 2018 13:01:42 +0200 "Enrico Weigelt, metux IT consult" wrote: * they're trying to introduce a kind of legal system into a tech project this. It's the introduction of a parallel legal system. It is then used as a special exception to the actual legal system, as a tool of power. Ill-defined rules allow for biased interpretation. Too many rules allow for selective enforcement. This should be obvious. Why isn't this obvious? ___ Why isn't it obvious that this thread should die? Everyone, please exercise some restraint. This babbling is a turnoff to new list members who are expecting technical discussions not political debates/rants. We are better than these last few sad weeks. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
