#devuan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11: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

11: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”

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

11: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.

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

11: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.

11: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.

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

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

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

12: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.

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

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

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

12: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

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

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

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

12: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

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

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

13: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.

13: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.

13: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.

13: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.

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

13: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.

13: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.

13: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.

13: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.

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

13: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.

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

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

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

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

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

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

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

13: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."

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

13: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.

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

13: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

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

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

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

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

14: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.

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

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

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

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

23: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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

00: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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

00: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

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

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

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

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

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

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

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

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

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

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

00: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 :)

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

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

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

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

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

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

00: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 :)

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

00: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

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

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

00: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

00: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#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

05: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

05: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.

05: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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

08: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/

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