previous
2021-09-11
09:33:35 <Hydragyrum> any reasonably easy way to check which files in /etc differ from the defaults shipped with packages?
10:04:07 <gnarface> Hydragyrum: check for copies with an additional extension like .dpkg-new .dpkg-old or .dpkg-dist, stuff like that
10:04:26 <gnarface> if there's a collision during an upgrade with a file a user changed, there's usually a backup of some sort
10:05:43 <gnarface> off the top of my head i can't think of a simple command to actually compare them all recursively without writing scripts to automate looping through the process of re-downloading the stock package from the repo
10:06:23 <gnarface> the best practice of course is to have already made a backup of /etc
10:06:39 <gnarface> i realize that might not help much at this point though
10:06:40 <onefang> Or use etckeeper.
10:06:46 <Hydragyrum> yeah, I forgot to set up etckeeper on this install
10:06:49 <Hydragyrum> I usually do use it
10:31:32 <fsmithred> debsums -ca
10:31:41 <fsmithred> Hydragyrum, gnarface ^^^
10:32:40 <Hydragyrum> where does that come from? apt-file doesn't find me a package containing anything called debsums
10:33:20 <Hydragyrum> nvm my apt-file seems to be acting up
11:22:10 <fsmithred> Package: debsums
11:22:10 <fsmithred> Version: 2.2.3
11:22:10 <fsmithred> Priority: optional
11:31:04 <Hydragyrum> yeah that worked really well, ty
16:58:03 <chomwitt> Trying to install an epson inkjet driver,but as dpkg --info shows and as dpkg -i complains it has a dependency on 'lsb' a package non existant
17:16:16 <rrq> the lsb package doesn't seem to provide anything other than a coupld of branding files and some subsystem dependencies, esp "cups"... an equivs package would probably wotk for you...
17:16:38 <rrq> see https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=lsb&x=submit
17:18:29 <chomwitt> i'll try $ sudo apt-get install printer-driver-escpr
17:18:59 <chomwitt> must be the driver i need
17:48:14 <chomwitt> cool ,, its done, with cups installed i can print to a wifi printer while i am connected wired in the same access point
18:40:03 <nckx> Does Devuan rely on eudev by default, and if is there a plan regarding its deprecation? <https://wiki.linuxfromscratch.org/lfs/ticket/4914>
18:53:40 <fsmithred> nckx, yes and yes. #devuan-eudev
18:57:13 <nckx> I wasn't aware of that channel.
18:57:59 <fsmithred> it's only existed for a day or two
21:19:28 * chomwitt finds debtree diagrams on pkginfo.devuan.org cool!
21:21:06 * chomwitt finds clickable debtree diagrams cooler ...
22:34:15 <jason1234> LFS guys... https://gitlab.com/openbsd98324/openbrt unpack the rootfs.tar.gz and boot out of grub. you will get the smallest linux ever, without any base at all ... you can use it on top to make your own distribution of linux. Only the -static is needed to run command.s it allows to deploy devuan out of it, using tar and dpkg -x
22:42:12 <blockhead> gotta love those git hub sites that don't even say what the project is or does *golf clap*. Nothing to do with real Linux From Scratch, it turns out. Oh, and oh dear, that's off topic, isn't it?
---------- 2021-09-12 ----------
00:09:40 <fsmithred> in beowulf and ascii, I could resize a qemu window by grabbing the corner with the mouse and moving it. In chimaera, this does not work. Any ideas on how to fix it?
00:30:02 <fsmithred> grep -v no longer works? wtf?
00:31:10 <fsmithred> how do I search inside every file on my computer to find the string 'lightdm-xsession' and only return lines that have that string?
00:31:56 <fsmithred> or more to the point, how do I get xfce or whatever is sending me the error to stop trying to load a lightdm-xsession after lightdm has been purged and replaced with lxdm?
00:33:13 <fsmithred> Xsession: unable to launch "lightdm-xsession" --- lightdm-xsession not found; falling b
00:54:15 <ksx4system> fsmithred, only thing that comes to my mind would be writing a script executing cat and then grep on every file you'd like to "scan"
00:54:28 <ksx4system> but there's probably better solution
00:54:45 <fsmithred> I'm grepping one dir at a time to skip /proc
00:54:51 <fsmithred> which was spamming the console
01:20:07 <Xenguy> fsmithred, grep -rv foo *
01:20:14 <Xenguy> should work, no?
01:20:36 <fsmithred> Xenguy, not today
01:20:48 <Xenguy> Otherwise, not sure how efficient it is, but could a combination of find and grep e.g.
01:21:07 <fsmithred> I'm past that, anyway. Looking at $DESKTOP_SESSION now
01:21:33 <fsmithred> yeah, I already used find with -exec to delete every file on the hard drive with lightdm in its name
01:21:38 <Xenguy> find . -type f -exec grep -i foo {} \;
01:21:43 <fsmithred> no shit. I am pissed off about this.
01:22:10 <fsmithred> something is telling Xsession to use lightdm-session
01:22:32 <fsmithred> I suspect it may be startxfce4, but if so, it's new in chimaera
01:22:53 <fsmithred> I've used lxdm with xfce in beowulf and ascii, and it worked fine.
01:23:09 <fsmithred> just had to set the session=/usr/bin/startxfce4 in lxdm.conf
01:25:13 <fsmithred> and this isn't even the real issue. I just wanted to try lxdm to see if it made a difference.
01:25:41 <fsmithred> how to get xfce to respect the language/locale that is selected at boot in a live iso?
01:26:35 <fsmithred> in desktop-live isos and refracta-runit isos it works. In new refracta-xfce isos it does not work. I only get the keyboard on the desktop.
01:32:53 <fsmithred> found it! in ~/.dmrc: session=lightdm-xsession (I changed it to default and set startxfce4 in lxdm.conf
01:57:31 <fsmithred> Cestino!
01:58:19 <fsmithred> I think that's where lightdm is going in Refracta
04:03:57 <systemdlete> I am trying to set up a ssh and scp connection to a machine running dropbear (not openssh, etc). I can successfully scp a file to the remote (dropbear server), but ssh does not work. I'm using a ec22519 key pair. on the local system, I am using openssh-client on beowulf. Could there be a compatibility problem with this combination?
04:04:27 <systemdlete> user and root logins to the remote are disabled.
04:05:07 <systemdlete> (the public key file was transferred to the dropbear server side; scp works.)
04:06:57 <systemdlete> thank you
04:30:33 <rwp> systemdlete, Was it that logins were disabled? Was that the end result of the debug?
04:30:56 <systemdlete> rwp: Never mind. I think I have this fire under control... ALMOST.
04:31:06 <rwp> Most often on the client side I use 1 or 3 -v on the ssh to see what it says.
04:31:27 <rwp> ssh -v remotehost.example.com, Hmm... ssh -vvv remotehost.example.com, and hopefully find a clue in there.
04:31:40 <rwp> Multiple -v's increase verbosity.
04:31:40 <systemdlete> I think the problem is that I am specifying the wrong user. But now it seems to be working, even though the pub file spec on the remote belongs to a regular user.
04:31:52 <systemdlete> (yes, I did a trace.)
04:32:05 <systemdlete> but root login is disabled.
04:32:09 <systemdlete> on the remote I mean
04:32:13 <rwp> If scp works then almost by definition ssh should work since scp *is* ssh and is using ssh. But your interactive login comment could be it.
04:32:33 <systemdlete> "interactive login comment?"
04:32:37 <rwp> Everyone disables root by default these days. Which is a pity.
04:32:50 <rwp> You had said, ":04 <systemdlete> user and root logins to the remote are disabled."
04:32:58 <systemdlete> Oh
04:33:01 <systemdlete> I did that
04:33:23 <systemdlete> I want all ssh and scp traffic to use secure connections.
04:33:39 <systemdlete> besides, it avoids having to enter a password all the time
04:34:03 <rwp> The OpenSSH default these days is "PermitRootLogin prohibit-password".
04:34:19 <rwp> Which allows the use of keys, but not passwords.
04:34:36 <systemdlete> right.
04:34:53 <rwp> But many distros set that to an actual "PermitRootLogin no". Which just blocks it entirely.
04:35:18 <systemdlete> well, I have disabled root login with password on the remote.
04:35:59 <systemdlete> here's what is puzzling me. the key pair I am using was generated by an admin user not root on the local host.
04:36:10 <systemdlete> I copied the pub file to the remote.
04:36:25 <rwp> How did you disable root login with password?
04:36:47 <rwp> Disabled it in /etc/shadow? Or used passwd -l or whatever?
04:36:51 <systemdlete> but it allows root to connect without password, which I don't expect. The pub file has the username and hostname of the local, not root for the local
04:37:08 <systemdlete> first off, the remote is running dropbear, not openssh.
04:37:40 <systemdlete> second, there's a UI for all of this for the remote (it's a router)
04:37:47 <systemdlete> (openwrt router)
04:38:07 <systemdlete> hopefully that explains things more clearly.
04:38:08 <rwp> Oh it's OpenWRT. Gotcha.
04:38:22 <systemdlete> sorry. should have pointed that out more and earlier
04:38:26 <rwp> Yes. I can *almost* but not quite know what is going on with OpenWRT.
04:38:34 <systemdlete> yes.
04:38:46 <systemdlete> I am also soliciting help in their channel with this.
04:39:08 <rwp> The problem being that I (we?) don't actually know what the web UI is doing behind the scenes internally on the box.
04:39:11 <systemdlete> I am no expert on cryptography or ssh.
04:39:19 <systemdlete> right.
04:39:34 <systemdlete> and it is a brand new release that has had some bugs so far
04:39:40 <systemdlete> ergo, y'know
04:39:41 <rwp> Fortunately we can mostly ignore the cryptography and just assume that part works like any other connection.
04:40:10 <systemdlete> oh, I meant the keys and the manner in which ssh works in general, as opposed to specific tools and implementations
04:40:37 <rwp> And since scp is working then we know that the crypto is working between the boxes. So no concerns about incompatibility between the ciphers or anything.
04:40:41 <systemdlete> like in this instance, the way the protocol is supposed to do matching of identities etc
04:41:04 <systemdlete> right. and ssh is working also. but it is working for root, not just my regular user
04:41:04 <rs> systemdlete: Are you specifying root while attempting to ssh to openwrt? Doesn't ssh need a user regardless?
04:41:12 <systemdlete> yes
04:41:20 <systemdlete> well
04:41:22 <systemdlete> yes and yes
04:41:25 <rs> Or connect with "user"@host?
04:41:32 <systemdlete> yep
04:42:01 <systemdlete> erase! erase! erase!
04:42:03 <systemdlete> doh
04:42:09 <systemdlete> I got my windows mixed up
04:42:27 <systemdlete> no, it really is the regular user that is successful with both ssh and scp
04:43:54 <rs> why would you not want to login as root on openwrt? with a key and no http, or http'd disabled unless needed, im not sure the need to block ssh to root@host.
04:44:42 <systemdlete> it isn't.
04:45:05 <systemdlete> the router blocks users including root from entering a password
04:45:12 <rwp> Right. I always unblock root entirely because I use long random generated passwords but with a key only is very safe.
04:45:40 <rs> rwp: exactly. i also disable http entirely and use ssh to enable when necessary
04:46:10 <systemdlete> is there a problem with things this way?
04:46:24 <rwp> I also say no http/https on the WAN side but only allowed on the LAN side.
04:46:26 <systemdlete> It is more convenient not to have to enter a password for one thing.
04:46:48 <systemdlete> rwp: currently the router only allows connections from the lan side.
04:46:49 <rwp> There is convenience. And then there is the initial setup debug time when things are not working.
04:47:06 <rwp> But yes ssh keys are convenient and more secure. So that is what I use 99.44% of the time.
04:47:07 <rs> systemdlete: Well, you shouldn't need a password for anything -- assuming you command line everything via ssh.
04:47:33 <systemdlete> moreover, these will be "canned" instructions -- specific scripts, not ad hoc instructions
04:48:19 <systemdlete> (actually, really only one script. so far anyway)
04:48:26 <systemdlete> thanks to you both btw
04:50:16 <rwp> If it wasn't OpenWRT but a standard system I would suggest looking in /var/log/auth.log for the server side of the debug trail.
04:50:31 <rwp> Does the OpenWRT have any log files available for that side of the debug trail?
04:50:52 <systemdlete> eh, not so much no
04:51:06 <systemdlete> I think there are ways to increase the verbosity and so on, but I have not done that really
04:51:37 <systemdlete> in fact, I have actually redirected logging to a local system where it is easier to do hunting
04:51:59 <systemdlete> Also uses less space on the router
04:52:23 <systemdlete> but I am not having any problems now, thanks to you guys
04:52:31 <rwp> This is why my house router and WiFi Access Point is an actual small system running Beowulf. Have a full software stack there. Everything is just Devuan and normal.
04:52:48 <rwp> You have things working and happy now?
04:52:52 <systemdlete> yes
04:52:56 <systemdlete> happy
04:53:01 <systemdlete> very happy
04:53:56 <rwp> What was the secret that made everything work?
04:54:28 <systemdlete> the secret? Well, to start with, specifying the correct user on the command line to ssh :D
04:54:53 <rwp> That would do it! :-)
04:55:31 <systemdlete> and then later, when I thought i was getting local root to execute ssh on the router, suddenly realizing the local shell was logged in as the local admin (regular) user, not local root!
04:55:41 <systemdlete> I confused myself with that.
04:56:23 <rwp> It can be easy to get tripped up that way. I most often do it when I am comparing three different remote system things and confuse myself on which terminal is which.
04:57:50 <systemdlete> Yeah, I am using several command windows also. Some window managers don't keep up well with re-titling windows as I log in to remote systems, change users, etc
04:59:03 <systemdlete> but on this desktop, which is lxde, it actually does a pretty good job of updating the window titles. I am even wearing my computer eyeglasses. So there is no excuse.
04:59:48 <systemdlete> When they were giving out brains, I thought they said trains...
05:01:00 <rwp> I use the normal PS1 which puts the user and hostname in the prompt. That helps.
05:01:11 <rwp> But for OpenWRT I don't know what they have set up there.
05:01:13 <systemdlete> agreed
05:01:21 <systemdlete> pretty much that
05:02:33 <systemdlete> it is 'root@routername# '
05:02:51 <systemdlete> and that shows up the same in ssh session, so that is fine.
05:03:16 <systemdlete> the bigger problem is the window titles because I usually leave a lot of windows open all the time.
05:04:56 <systemdlete> heck, I even label my desktop to reflect which host I'm on -- no kidding.
05:05:40 <systemdlete> What I do is I change the comment field for the login user (not root) to say something like "welcome to beowulf" or whatever.
05:05:46 <systemdlete> And that shows up in either the action widget or some other control on the panel for that desktop.
05:05:56 <systemdlete> It helps a lot when I have to update/upgrade my VMs
05:06:04 <rwp> I (ab)use the /etc/debian_chroot file for that all of the time on systems that don't otherwise have a reasonable name.
05:06:17 <rwp> The default .bashrc file has PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ ' which puts the contents of that file in the prompt.
05:06:53 <rwp> Personally I don't use the window titles very much. But it's a work flow ergo thing as everyone has different ways of doing things.
05:12:25 <systemdlete> linux/unix are certainly flexible and adaptable
05:12:51 <rwp> "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." --Dennis Ritchie
05:13:13 <systemdlete> yeah, what you said
05:13:30 <rwp> dmr said it not me! I just quoted him.
05:13:39 <systemdlete> sorry...
05:13:51 <rwp> And he should know. One of the two main original authors of the Unix system!
05:14:09 <systemdlete> and one of two creators of C
07:03:09 <nemo> https://askubuntu.com/questions/1227667/df-command-throws-error-on-run-user-1000-doc-folder
07:03:52 <nemo> so. I found this in search for:
07:03:52 <nemo> # ls -l /run/user/1000/doc
07:03:53 <nemo> ls: cannot access '/run/user/1000/doc': Permission denied
07:04:00 <nemo> d????????? ? ? ? ? ? doc
07:04:06 <nemo> which seemed... pretty buggy
07:04:38 <nemo> what the heck is xdg-document-portal anyway?
07:06:22 <nemo> https://github.com/flatpak/xdg-desktop-portal
07:06:31 <nemo> doesn't sound like anything I'd care about at all
07:06:33 * nemo removes it
07:06:54 <nemo> I think I have 0 flatpak apps.
08:00:55 <ham5urg> If I pair a headset with xfce and chimaera, I get no audiodevice in the xfce's pulseaudio-module. Is this expected? Do I have install some package?
08:02:01 <fsmithred> ham5urg, you have pavucontrol installed?
08:02:24 <fsmithred> I assume you mean a usb headset, and not just a mini-jack
08:03:25 <ham5urg> fsmithred, yes pavucontrol is installed. I have a bluetooth headset paired (via shell) but I can't get see it in alsamixer or xfce's mixer
08:03:39 <ham5urg> get to see*
08:04:25 <fsmithred> I can get bluetooth to work about three out of every 10 attempts
08:04:48 <fsmithred> that's with an android tablet mostly, and tried with a phone a couple of times.
08:04:57 <ham5urg> Now it works...
08:05:02 <ham5urg> Yes, you are right
08:05:20 <ham5urg> It's a bit of gambling
08:05:28 <ham5urg> like gambling
08:05:32 <fsmithred> now I use a wire when I want to transfer files from the tablet to the laptop
08:06:13 <ham5urg> Today it worked well to transfer via bluetooth, but this headset was unknown to the computer till now
08:06:14 <fsmithred> wires are good. We should not get rid of all the wires. Phones were reliable for about 100 years until we got rid of the wires.
08:06:19 <fsmithred> sorry for the rant
08:06:29 <ham5urg> Yes, I have a big box of cables
08:07:19 <ham5urg> The most wicked is USB-C, mb/s and ampere are a bit of a gamble there
08:09:39 <Hydragyrum> my bluetooth usually Just Works™, but sometimes the adapter bricks itself and doesn't have a reset switch I can trigger in software -- so I have no choice but to reboot
08:13:18 <ham5urg> are there other bluetooth stacks?
08:13:46 <ham5urg> bluez is used now
08:15:09 <ham5urg> Under Gnome bluetooth-audio works flawlessly, maybe another bluetooth-stack is used.
08:15:49 <ksx4system> ham5urg, never had any luck with GNOME's bluetooth audio support
08:16:24 <ksx4system> it was shitty on few different adapters and few different pair of decent (Bose, Oppo, Sony) headphones
08:16:38 <Hydragyrum> my bluez has worked fine for me (using it with cmd-line bluetoothctl and pulseaudio-bluetooth)
08:19:12 <ham5urg> Maybe it's blueman, it does not switch to a2dp
08:21:25 <Hydragyrum> I've found often a nice little pulseaudio -k or a disconnect/reconnect cycle is needed
08:32:58 <ham5urg> I've found the problem in my case. The power the antenna (laptop) is sending the bluetooth is not strong enough. If I put the headset right next to the monitor, it is ok. Only 30 cm away and it is to weak.
08:33:10 <ham5urg> Signal strength I guess.
08:36:04 <djph> BT is "only" 2.4 GHz -- what else is running in that bad? Maybe something's interfering
08:36:34 <ham5urg> Can I increase the signal of the laptop?
08:36:42 <ham5urg> via bluetoothctl?
08:37:33 <Hydragyrum> I don't think so -- but moving your wifi to 5ghz may help
08:38:36 <ham5urg> It is, at least with a Ubuntu-Iso it worked quite well. It does now too, but I have to be right next to the monitor/antenna.
08:45:15 <_ds_> 5 gram-hecto-zepto?
2021-09-12
next