| fsmithred | nyov, oh I didn't notice you're using https. Only some of the mirrors are set up to use that, and we don't have control over that. | 00:00 |
|---|---|---|
| nyov | it's all good - I found the https mirrors on that second link ;) | 00:01 |
| golinux | You can also just use http | 00:10 |
| onefang | Don't use https for deb.devuan.org, for exactly that reason. | 00:28 |
| rwp | I recommend only using http:// protocol to avoid all of the problems of time skew and root certificates and all of that. | 01:17 |
| rwp | Things are designed to be secure using an insecure protocol. It's okay to use http:// as https is NOT needed for securely upgrading systems. | 01:17 |
| fsmithred | https will prevent your ISP from knowing what packages you install, if that helps. | 01:31 |
| brocashelm | fsmithred: like for your sources list? | 01:34 |
| fsmithred | mine? I don't use https. | 01:35 |
| brocashelm | i didn't until trying it out now. getting this: W: Failed to fetch https://deb.devuan.org/merged/dists/ceres/InRelease Certificate verification failed: The certificate is NOT trusted. The name in the certificate does not match the expected. Could not handshake: Error in the certificate verification. | 01:35 |
| rwp | I think if one is going to use https:// then it will be necessary to select an individual close mirror and then use the name associated with that mirror. | 01:37 |
| nyov | yes, http is sufficient for integrity purposes. it may, however, be exposing your software usage and therefore potential attack surface to an mitm on an untrustworthy network. | 01:37 |
| rwp | I don't like my current ISP but if I thought they were taking advantage of me at that level and had no other choice then a full VPN is the better alternative. | 01:38 |
| brocashelm | yeah, i'm behind a paid vpn 99.9% of the time | 01:38 |
| brocashelm | but to use https is even better, since, why not | 01:39 |
| nyov | obviously use-cases differ. running a public server behind a vpn is not usually the point of running the server :D | 01:39 |
| rwp | Don't let me say that https is always good or always bad but if bootstrapping a system it might have a clock set to 0 aka 1970 in which case no certificates will validate. For one example where https is troublesome. | 01:41 |
| rwp | But regardless one might want to install the ntp packages so that they can use those to set the clock. Which would then allow https to validate. | 01:42 |
| brocashelm | i got ntpsec installed a long time ago | 01:43 |
| rwp | Just a data point. I tried mirror.koddos.net which is listed as an https mirror. But all attempts get this error response: Invalid response from proxy: HTTP/1.0 403 CONNECT denied (ask the admin to allow HTTPS tunnels) | 01:44 |
| rwp | Same thing from mirrors.dotsrc.org too so I am sure that I don't understand what is happening. Other than reinforcing my avoidance of https to avoid problems. | 01:46 |
| brocashelm | i've always wondered why debian/devuan systems aren't really security-minded by default. packages like ntp, fail2ban, debsecan (i don't remember if they come installed), lynis, chkrootkit, tiger, etc. should be available out of the box IMO | 01:47 |
| brocashelm | especially since debian/devuan mainly targets servers | 01:47 |
| rwp | Server admins are generally equip'd to fully specify and fully configure what they have installed. I always start with the minimum and then install what I want from there. | 01:50 |
| nyov | hmm. if you get a 'HTTP/1.0 403 CONNECT' it looks like you may be using a http proxy that won't tunnel to a 443 https port | 01:56 |
| nyov | ...or the mirror may be misconfigured | 01:56 |
| rwp | Oh! Yes. Good catch! Sorry. I had forgotten I had configured a proxy. | 01:56 |
| rwp | Yes. Fixing that by removing my local apt-cacher-ng proxy and both https://mirror.koddos.net and https://mirrors.dotsrc.org work okay. No problem. Sorry. My bad! | 02:00 |
| Soltis | fsmithred: a variation of what you suggested worked, though the install steps I did didn't differ significantly from what I did originally. | 10:24 |
| Soltis | join #mariadb | 10:44 |
| Soltis | gah | 10:44 |
| Successus | Hi, I want to know the situation with Devuan's packages, are all packages patched so that they don't depend on any systemd component? | 15:24 |
| gnarface | Successus: yes* | 15:50 |
| gnarface | * except for these ones: http://deb.devuan.org/bannedpackages.txt, and the roughly ~60,000 other packages that didn't need to be patched | 15:52 |
| syco | \o/ installing ntp solved my clock drift problem! thanks for the help :) | 16:00 |
| Successus | I see | 16:05 |
| Xenguy | Can anyone remind me which application does various scans when installing new software with apt-get ? | 19:26 |
| Xenguy | e.g. with output like this: https://paste.debian.net/hidden/d3b34e5d/ | 19:29 |
| rwp | Xenguy, I don't run needrestart in /etc/apt/apt.conf.d/99needrestart (I comment it out) but that looks like probably needrestart? | 20:00 |
| rwp | The main reason being it spams every bash terminal saying that bash needs to be restarted. Which I find a step too far. | 20:02 |
| rwp | The secondary reason being that the actions during apt action time I don't prefer and prefer to run "needrestart -b" as a separate step afterward. | 20:02 |
| Xenguy | rwp, I think that's it, thanks very much | 20:03 |
| Xenguy | For anyone familiar with 'needrestart', it will sometimes offer to restart certain services... | 20:03 |
| Xenguy | I learned the hard way that restarting the 'slim' service will remove my current X session, which of course makes perfect sense in retrospect... | 20:04 |
| Xenguy | Currently I'm wondering what the outcome might be if I were to restart the 'dbus' service? | 20:04 |
| Xenguy | I haven't gone ahead and tried that yet, but it was recently one of the services that 'need restart' offered to restart. | 20:05 |
| rwp | I think dbus is one of those impossible to restart services that can only be started at boot time. | 20:05 |
| Xenguy | Interesting, hrm... | 20:06 |
| Xenguy | I suppose I could just try having 'needrestart' make the attempt to restart 'dbus', since it does offer to do so, and find out what happens... | 20:07 |
| rwp | I think the reason is that if dbus is restarted then every dbus-client daemon also needs to be restarted. | 20:07 |
| rwp | If you try it and find out either yes or no I would be interested in the details. | 20:08 |
| Xenguy | My main concern would be to avoid the same outcome as restarting 'slim', i.e. losing my current X session | 20:08 |
| Xenguy | rwp, I'd certain be happy to report back... | 20:08 |
| rwp | Yes restarting slim or lightdm or gdm will kill the associated X session. Bummer you learned that the hard way. :-( | 20:08 |
| Xenguy | I'd probably identify the current 'dbus' process ID, before attempting to restart the service, etc., and find out that way | 20:09 |
| rwp | A little poking around finds that on systemd systems systemd itself depends upon dbus and therefore restarting dbus requires systemd to be restarted. Requiring a reboot. | 20:09 |
| rwp | Which means that on non-systemd systems that I don't know the complete dependency tree. | 20:09 |
| Xenguy | rwp, I probably should have been able to anticipate the outcome of restarting 'slim' : -) Well, now I know for sure | 20:09 |
| rwp | Xenguy, This is informative: https://wiki.ubuntu.com/DbusRestart | 20:13 |
| Xenguy | Thanks kindly | 20:15 |
| rwp | I'll note that issue was first logged in 2005 and if it hasn't been addressed by now in 2022 that it seems unlikely ever to be address. | 20:29 |
| Xenguy | Makes sense | 20:32 |
| se7en | QUIT | 20:50 |
| fsmithred | Xenguy, confirmed: restarting dbus kills the xsession. I've done it in the past, but that was probably in wheezy or earlier. | 22:15 |
| Xenguy | fsmithred, Good to know, thanks. Still running Beowulf here, but from reading the article that rwp referenced, it looked like the best I could hope for if I restarted dbus would be a bunch of broken connections with other apps, and a non-sane state. Tellingly, all 'needrestart' offered (in this case) to restart 'slim', 'dbus', and 'unbound', only the latter was checked off by default. | 22:19 |
| Xenguy | s/all/although | 22:19 |
| fsmithred | all I did was log in again when the login screen came up | 22:19 |
| fsmithred | I did check all services to see what's running, and I think it's ok. | 22:19 |
| Xenguy | Same as I did when I checked off 'slim' | 22:19 |
| fsmithred | not really sure what all should be running. | 22:20 |
| fsmithred | systemd is not running. I'm sure of that one. | 22:20 |
| Xenguy | How did you inventory the running services BTW? | 22:20 |
| Xenguy | hah, let's hope so | 22:20 |
| fsmithred | service --status-all | 22:20 |
| Xenguy | nice | 22:20 |
| fsmithred | I just learned that one this year | 22:20 |
| fsmithred | to give you an idea of how much I've done with services in 21 years of using linus | 22:21 |
| Xenguy | I wasn't aware of it, but makes perfect sense that the option would exist, as I use 'service' regularly for other more normie uses | 22:21 |
| Xenguy | There's always more to learn, one of the things I love about *nix | 22:22 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!