#devuan

19:30:42 <ksx4system> anyone tried Devuan under modern OpenVZ? by modern I mean 4.x kernel instead of 2.6.x

21:01:34 <Guest42> I was here before, asking for help with the wireless card problems.

21:03:36 * golinux is always wired so of no help

21:05:12 <Hydragyrum> what wireless card problems?

21:06:47 <golinux> (Hydragyrum rides to the rescue (hopefully))

21:07:18 <Guest42> gnarface you asked me to restart window manager, and check if it will help.

21:07:33 * Hydragyrum has had some wireless card issues in the past and may be able to help

21:07:35 <Guest42> Logging out, and in, does the same, right?

21:07:58 <gnarface> Guest42: no, you have to then also restart the login manager

21:08:12 <gnarface> if it's lightdm for example: /etc/init.d/lightdm restart

21:08:24 <Guest42> I logged out and in, and it didn't help.

21:08:27 <gnarface> it'll tell you if you get it wrong

21:10:17 <Guest42> gnarface But alt-prntscreen-k should do that, right?

21:11:54 <Guest42> It breaks in a random manner. Last time it happened just a couple minutes after turning on.

21:12:19 <Guest42> Changing NM to Connman didn't help at all.

21:13:04 <Guest42> gnarface Should the previously mentioned shortcut do this?

21:14:07 <gnarface> Guest42: no because the login manager is a separate program from the window manager

21:14:39 <gnarface> Guest42: if you were getting into X with startx it would be sufficient to log out and startx again but in your case you have to restart the login daemon too

21:40:50 <_ds_> You're not supposed to run the init scripts directly (environment setup reasons) – “invoke-rc.d lightdm restart” or (I think) “service restart lightdm”

21:46:36 <fluffywolf> I've always used /etc/init.d/foo restart...

21:49:48 <onefang> The problem with the service command is that (as per the man page) if there's a systemd unit and a sysvinit script, the systemd unit is used. Devuan has LOTS of systemd units.

21:53:08 <blockhead> onefang: so that means don't use the service command?

21:58:07 <onefang> Read the man page yourself, check out the locations it looks for systemd units, see if there's any on your system that'll get in the way of using the service command.

21:58:59 <onefang> I did, there was just way to many systemd units to bother trusting the service command, so I don't use it.

22:02:22 <mason> Middle ground: env -i /etc/init.d/foo

22:02:45 <mason> You get the clean environment service would have given you, but no quackery with systemd units

22:04:19 <fluffywolf> wouldn't the devuan script attepting to do systemd anything be considered a bug?

22:09:51 <mason> fluffywolf: My fear and absence lately has been this overwhelming recognition that there's no escaping an ever-increasing deluge of systemd while still based on Debian. It won't be possible.

22:24:53 <onefang> Another option is sysv-rc-conf. Might be more useful depending on what you are doing.

22:25:12 <onefang> It can be used to start or stop services from the list of all of them it shows.

22:44:55 <gnarface> i assume Guest42 is still having wifi issues

22:46:43 <gnarface> i forget if it was suggested to try to see if disabling power management for the networking device was possible with a module parameter

22:47:23 <gnarface> i think i was thinking maybe a graphical problem was interfering with the UI widgets or something

22:47:54 <gnarface> but i think he was saying it just drops and we still have no evidence about why

22:48:33 <blockhead> gnarface: the disabling power management sounds like a good idea: i'd had that problem ages ago

22:51:17 <gnarface> i think the "service" wrapper is just a convenience tool; the init.d scripts are still meant to be called directly too

22:51:32 <gnarface> it's not required to be installed even

22:52:28 <gnarface> some systemd stuff might require it now, i don't know, but it actually predates systemd by a lot

23:00:24 <rwp> gnarface, The problem that the service command solves is when a user has an environment that is different from root's boot time environment.

23:00:51 <rwp> Who might be those with a different environment? All of us! All of us have a customized PATH for example. Or at least I do.

23:01:34 <rwp> But perhaps it is the SSH_AUTH_SOCK variable that causes more trouble. Because then system init services inherit the setting of that variable and behave differently.

23:02:07 <rwp> There are many different ways that a user's environment will leak into the init scripts. And service is one of the utilities that uniformly avoids those problems.

23:02:35 <rwp> By first cleaning the environment. Basically "env -i" and ensuring a boot time clean setting for PATH and other variables.

23:03:09 <rwp> And service first does a "cd /" so that it does not spawn daemons with a cwd on a mount point. Which would then be busy forever and stuck.

23:03:45 <rwp> Those are all things that users often do to shoot themselves in the foot. Especially when using "sudo /etc/init.d/foo restart" or some such.

23:04:21 <rwp> Of course I know that you almost certainly never use sudo and always have a very tidy and clean /root environment. "su -" and then as root "# /etc/init.d/foo restart" and that's fine.

23:04:58 <rwp> But a whole generation of users are now doing crazy things with their login environment and that leaks into init scripts and it causes trouble later.

23:05:04 <rwp> Using service avoids those environment leakage problems.

23:47:41 <onefang> If only there was a configuration option to get service to either ignore systemd units, or not have them be top priority over sysv init scripts.

23:51:19 <rwp> But here we are in Devuan without systemd and therefore there shouldn't be any systemd units to ignore. :-)

23:52:29 <rwp> However on a systemd system the service command does pass through the request to systemctl though.

23:52:41 <onefang> But there are heaps of them.

23:53:33 <onefang> All those packages that have systemd units, but that have not been forked by Devuan, still install systemd units.

23:54:02 <rwp> But since systemd is not running service doesn't call systemctl but calls /etc/init.d/foo directly.

23:54:28 <onefang> That's not what man service says.

23:55:02 * rwp goes to read the man page again...

23:55:10 <onefang> "The existence of a systemd unit of the same name as a script in /etc/init.d will cause the unit to take precedence over the init.d script."

23:56:36 <rwp> That's insufficiently correct about the actual action of the script. :-(

23:56:46 <rwp> Please browse the script /usr/sbin/service and find "if [ -d /run/systemd/system ]; then is_systemd=1; fi" sets that variable.

23:57:25 <rwp> Then subsequently if "if [ -n "$is_systemd" ]" is true or false various actions occur.

23:59:09 <onefang> If the docs say it does exactly what I don't want to do, and my previous method still works fine, I got better things to do that deep dive into the code to see if the docs lie. shrugs

23:59:38 <onefang> Only reason I looked at it at all is it's a shorter command, less to type. lol

00:00:09 <rwp> What is "your previous method"?

00:01:29 <rwp> Also maybe an example. In Beowulf/Buster the maintainer removed the init script for Mailman. The bugger!

00:01:53 <rwp> "service mailman start" in that case returns "mailman: unrecognized service"

00:02:25 <rwp> Because Beowulf is not running systemd. Yet the package contains a systemd service unit. /lib/systemd/system/mailman.service is ignored though.

00:30:05 <sadoon_albader[m> Is there an RSS feed for devuan news?

00:42:40 <rwp> sadoon_albader[m, As far as I know the main RSS news feed is at https://dev1galaxy.org/ the web forum.

00:42:55 <rwp> But that's not project news as it is community forum news.

00:43:36 <sadoon_albader[m> What about the project?

09:38:47 <ksx4system> I've upgraded an OpenVZ VPS from Debian stretch to Devuan beowulf. Everything went well but SSH login now freezes for a long time (a minute maybe?) before displaying command prompt

09:39:24 <daemon> hmm might be totally unrelated but I have seen that on a few of my freebsd boxes

09:39:27 <daemon> that do not have configured nameservers

09:39:31 <ksx4system> ssh -vvv shows me that it freezes exactly at "debug1: pledge: exec" point

09:39:39 <ksx4system> nameservers are configured correctly ofc

09:40:20 <daemon> what might be interesting is doing a diff on a standard sshd_config vs the one on your system

09:40:25 <daemon> see if there is anything obvious

09:40:52 <ksx4system> even reinstalled openssh-server, replaced sshd_config for a standard file

09:41:02 <daemon> well pledge: exec, is that the step that normally passes off to zsh/bash etc?

09:41:32 <daemon> ssh -vvv on one that does not have that problem

09:41:36 <daemon> see what is meant to happen

09:42:10 <daemon> because presumable whatever it is meant to be exec()'ing is blocking for some reason

09:42:35 <ksx4system> nope, there's lots of things happening after "pledge: exec" on healthy box

09:42:53 <ksx4system> as far as I've googled it might be related to PAM somehow

09:42:58 <daemon> I assume after the minute, the b0rked system does all those same steps

09:43:18 <daemon> after the pledge: exec that is

09:43:35 <daemon> ok so now we just need to know what the heck pledge exec is actually doing :)

09:44:20 <ksx4system> also: "su root" to get root privileges freezes exactly the same way (while within ssh session of course)

09:44:41 <daemon> as a million to one, try: ssh -o GSSAPIAuthentication=no

09:44:59 <daemon> though indeed it does sound PAM'y

09:45:15 <daemon> almost sounds like its trying ldap or something and failing through out of timeout before reverting to a different auth backend

09:45:21 <ksx4system> same freeze with that gssapi option

09:46:19 <daemon> diff /etc/pam.d on a working system and your current one?

09:46:23 <daemon> see if you have a different setup somehoiw

09:46:41 <daemon> on my linux system for instance I have these changes:

09:46:41 <daemon> system-services:session optional pam_ldap.so

09:46:41 <daemon> system-auth:auth sufficient pam_ldap.so use_first_pass

09:46:53 <daemon> but that is for a gentoo box, may be slightly different on devuan

09:47:49 <daemon> oh someone reported precisely the issue you have for redhad: https://bugzilla.redhat.com/show_bug.cgi?id=1452804

09:48:22 <ksx4system> daemon, I've got another healthy Devuan box to compare :) even more than one

09:53:02 <ksx4system> on a healthy system mc displays properly

09:53:13 <ksx4system> on this b0rked VPS it displays... well, b0rked

09:53:51 * ksx4system should've got KVM VPS

09:53:57 <ksx4system> and install Devuan from scratch

09:54:20 <ksx4system> https://www.devuan.org/os/documentation/dev1fanboy/en/stretch-to-beowulf

09:54:22 <daemon> if you only just got the system you can likely cancel it for refund and grab a KVM instead

09:54:35 <ksx4system> daemon: this procedure used to work well on OpenVZ boxes

09:54:58 <ksx4system> daemon, got 14 days to cancel so I'll probably play around a little more and cancel after

09:55:03 <daemon> it sounds like your locales and or term are screwed up as well

09:55:31 <daemon> as a raw curiosity have you tried making a brand new user and seeing if that has problems

09:55:46 <ksx4system> locally it's fine (Crostini on Chrome OS so basically vanilla Debian oldstable), displays fine on other healthy hosts

09:56:39 <daemon> so strange set of problems

09:57:08 <daemon> we came to the idea that it might be pam, hence the su - being slow thing

09:57:19 <daemon> but that would not explain the terminal or locale being busted too

09:57:32 <ksx4system> well, afaics there's no locale whatsoever XD

09:58:06 <ksx4system> I'll try fixing PAM quick and dirty way (copying config from healthy box)

09:58:10 <daemon> so it should default to 'C'

09:58:26 <daemon> for messing about with pam make sure you stick a terminal logged in as root somewhere else :P

09:58:32 <daemon> just incase you totally break logins

09:58:37 <ksx4system> daemon: got out of band console lol

09:59:41 <ksx4system> "reboot command not found"

10:00:01 <buZz> ksx4system: try sudo reboot

10:00:12 <ksx4system> buZz, that was executed from root ;)

10:00:41 <ksx4system> Devuan beowulf, migrated from (supposedly clean) stretch image

10:00:51 <ksx4system> on a ghetto OpenVZ box

10:01:00 <buZz> and your /sbin dir does -not- have 'reboot' ?

10:01:18 <buZz> or 'as root user without root PATH?'

10:01:36 <daemon> wait a mo ... can you actually reboot an openvz instance, I mean its not a real vm its just a soft jail

10:02:04 <buZz> daemon: yeah it still works

10:02:07 <ksx4system> /sbin/reboot mysteriously worked

10:02:19 <ksx4system> daemon, yup, it's just a container

10:02:21 <buZz> ksx4system: next time you 'go to root' maybe do so with 'sudo -s'

10:02:27 <buZz> then your PATH will be correct aswell

10:02:40 <ksx4system> buZz, don't have sudo on this system atm

10:02:58 <daemon> right looking at what we have problems with: We have issues with terminal settings, auth and now paths

10:03:07 <daemon> it sounds like when a user logs in their env is not being setup right

10:03:18 <daemon> which would explain all problems in one go

10:03:22 <ksx4system> daemon: copying /etc/pam.d from healthy box didn't help with slow SSH logins :(

10:03:39 <buZz> 'ssh freezing on log in' 'and also su root' <-- thats a DNS problem

10:04:03 <ksx4system> buZZ: /etc/resolv.conf has "nameserver 1.1.1.1" in it

10:04:10 <daemon> 'UseDNS no' in sshd_config would be fastest way to test

10:04:22 <ksx4system> daemon, tried that - didn't help

10:04:43 <ksx4system> I guess image I've migrated from was simply b0rked

10:05:15 <ksx4system> they have Debian 10 image too but migrating from this one leaves me with no networking lol

10:05:20 <daemon> wait though even though old did the old image work correctly?

10:05:48 <ksx4system> daemon, before migrating to Devuan SSH worked fine

10:06:27 <daemon> time wise I would just get the VKM sod the migration do a fresh install

10:06:33 <daemon> curiosity wise, I would try doing the migration by hand

10:06:54 <ksx4system> daemon, I've migrated manually lol

10:07:09 <ksx4system> but using that "official" procedure from Devuan's webpage

10:07:27 <daemon> how big of a jump/migration was this

10:08:17 <ksx4system> buster to beo didn't work (no network after rebooting without bullshitd)

10:08:52 <ksx4system> but actually I didn't have initscripts at that point soooooo maybe it's worth trying again

10:09:01 <ksx4system> just different sequence of doing things

10:09:02 <daemon> mhmm there is a hack for that, slap some of your own network init stuff in /etc/rc.local

10:09:22 <ksx4system> ok, so let's wipe that box

10:09:33 <ksx4system> and then migration to beo again

10:10:14 <ksx4system> fun fact: this box has 256MB RAM

10:10:29 <daemon> hehe its not to bad for light loads

10:10:45 <ksx4system> enough for ZNC and rarely used Icecast2

10:11:07 <daemon> yeah I think ZNC uses about what 50M ... hmm im curious

10:11:16 <daemon> 772 znc 4 20 0 61M 26M select 148:28 0.00% znc

10:11:29 <ksx4system> but tbh enough to host my websites too, no SQL whatsoever so 256M should be plenty

10:11:56 <ksx4system> I don't use any databases as of now

10:12:52 <daemon> ... I think I am correct with what I am about to say but if someone could validate it would be handy! ... I think you can get a VM at aws 'free tier' with more resources than that

10:14:07 <ksx4system> previous (stretch-based) image showed me that I'm running 4.9 kernel

10:15:37 <ksx4system> not really possible to run anything newer than 3.10 for this setup

10:17:15 <daemon> I thought openvz just used whatever the host was using

10:20:15 <ksx4system> daemon, generally yes it does

10:20:40 <ksx4system> (or at least did for all these years)

10:22:04 <daemon> kind of weird I have managed to avoid openvz so far in life, use jails, hyperv and bhyve more

10:23:40 <ksx4system> my first VPS around 2009 ran on that

10:24:17 <daemon> First containerization/seperation type thing I used was freebsd jail system

10:24:30 <daemon> no idea what year that was

10:25:11 <daemon> you ever consider getting a cheap dedicated and just running your own openvz containers?

10:25:38 <daemon> will be a thousand times better than other peoples stack who likely have set it up using script they found on stack overflow :)

10:26:11 <ksx4system> nah, I don't have that much stuff to make renting a dedi reasonable

10:26:27 <ksx4system> if I had a little faster line at home I'd just host it all here

10:26:50 <daemon> if you work at a small enough company, they might let you host something with them

10:27:07 <ksx4system> I'm self employed lol

10:28:06 <daemon> yeah it does not sound like its super happy

10:28:12 <ksx4system> I'll get a KVM, much less problematic

10:29:12 <daemon> hey if you get a KVM it might have enough space to take a clone of that broken openvz system so you can continue figuring out what was wrong for fun :)

10:30:48 <ksx4system> daemon, or I could simply rsync it to home PC lol

10:30:52 <daemon> though speaking of infra I need to go look at the upgrade paths for my dedi I actually managed to 100% a Intel Core i7-7700 with rust and redis

10:31:04 <daemon> yeah that would work too! :_)

10:48:57 <ksx4system> daemon, someone's running pretty big apps lol

10:50:57 <daemon> ksx4system, would you believe all it is, is tracking every crypto currency on binance at the same time, who would have thought it would cost so much in cpu and memory bandwidth :P

10:53:45 <daemon> the actual other comedy is the first 'prototype' of that application I wrote in perl/POE ... it worked obviously way to slow to handle that much data so I thought ... no issue I will write it in c#

10:53:54 <daemon> .... wait hold on that can't keep up either

10:54:05 <daemon> rust just manages to do it

13:46:29 <mason> ksx4system: Did you solve your issue?

13:48:40 <mason> ksx4system: I worked this up as the first step to debugging ssh issues for work: https://bpa.st/ABNA

13:48:54 <mason> Might be useful. Do that on your problem case, do it on a healthy case, and you can compare.

14:44:34 <psionic> wow now debian systemd free? I did the default install didnt see no option for that

14:46:41 <mason> psionic: Debian isn't systemd-free.

14:52:11 <ham5urg> Is there a meta package to install common printers for auto-discovery (network printers)?

14:53:36 <ham5urg> It is but the printer is not popping up

14:54:25 <fsmithred> there are some extra packages you might need. I don't know the names off the top of my head.

14:54:58 <ham5urg> hplip and some printer-driver?

14:55:15 <fsmithred> search for cups and you'll get a long list

14:55:51 <fsmithred> maybe foomatic* maybe gutenprint*

14:56:53 * fsmithred is still using parallel port printer

14:59:24 <sixwheeledbeast> jetdirect not work? ip:9100

15:05:52 <mason> ham5urg: if you have a printer that needs a proprietary HP plugin, install hplip and IIRC it's hplip-setup, and that'll configure a CUPS queue

15:06:28 <mason> ham5urg: If it's not that, or if it's remote, rather than browsing, which can be very hit or miss, you can set a path directly with lpadmin.

15:07:04 <mason> ham5urg: If it's a remote printer attached to some Unix box, remember to treat it as raw on your local box as double-filtering will effectively make it not print ever.

15:08:14 <ham5urg> mason, it is a lan attached epson laser printer, PS-capabale.

15:08:39 <mason> ham5urg: Local example: lpadmin -p HP -v ipp://print-server.my.internal/printers/HP_LaserJet_Professional_P1109w -m raw -E

15:09:06 <mason> Sometimes browsing doesn't work, and upstream CUPS is in a bit of disarray recently.

15:09:53 <mason> I really dislike CUPS, FWIW, as compared with lpd.

15:18:30 <ham5urg> mason, the printer just got stucked. Its OS is restarting. I will try lpd.

15:19:46 <Xenguy> CUPS always worked fine for me. Sorry to hear it's maybe gone downhill

15:28:14 <ham5urg> There is a package lpr and a lprng. Which one should I choose?

15:28:44 <ham5urg> Once I installed CUPS, it was a zeroconf solution, install & discover all printers in a LAN.

15:31:22 <ham5urg> AFAIK cups depends on avahi, a "avahi-browse --all -t -r" should show all printers.

15:34:03 <joerg> my system not even heard of avahi-browse, then this is not a devuan

15:36:26 <ham5urg> But cups pulls in avahi-daemon

15:57:31 <joerg> jr@saturn:~> whichgrep *cups*

15:58:33 <joerg> alias whichgrep='find `echo $PATH|sed "s/:/ /g"` -iname '

16:15:36 <joerg> what the? unsolicited reconnect, sorry

16:17:01 <mason> Xenguy: Apple stopped maintaining it after being the principle caretakers for years. It's transitioning.

16:17:04 <fsmithred> ham5urg, add --no-install-recommends and then add in the Recommends that you want

16:17:09 <mason> The new maintainers might do okay.

16:59:03 <Xenguy> mason, That's right, I recall reading that the whole CUPS scheme originated with good ol' Apple

17:13:46 <chomwitt> after a lengthy discussion in oftc #lxqt i decided to create an issue https://github.com/lxqt/lxqt-config/issues/767

17:14:50 <chomwitt> a lxqt developer suggested that devuan should move to lxqt 0.17

17:15:44 <golinux> We move to whatever version Debian offers

17:16:39 <chomwitt> a related debian (so maybe devuan) related filelight issue https://github.com/lxqt/lxqt-panel/issues/1661

17:17:03 <chomwitt> golinux, ok , i just say what they said to me

17:19:22 <golinux> Thanks for letting us know

17:55:48 <ham5urg_> Is fwupd a good or bad thing?

18:03:20 <ham5urg_> How does "root 2653 1 0 00:42 ? 00:00:01 /usr/libexec/fwupd/fwupd" got loaded? I can't find it in /etc/init.d/

18:08:40 <ham5urg_> I guess it is autoload when fwupdmgr is invoked and not been shutdown afterwards.