| freaxeh | so steam, does it work on devuan desktop? | 11:28 |
|---|---|---|
| djph | yes | 11:29 |
| freaxeh | sweet | 11:29 |
| freaxeh | ty | 11:29 |
| gnarface | freaxeh: install the "steam-installer" package from the repos, not the deb package from valve | 11:42 |
| djph | gnarface: huh, i've always just used Valve's *deb | 11:43 |
| freaxeh | the first hurdle is getting wifi working | 11:46 |
| freaxeh | any love for a rtw8821ce? | 11:46 |
| freaxeh | i can go buy an ethernet cable and be happy but not today | 11:46 |
| djph | You need some degree of connectivity first. I can't remember if that's one of the ones that have the driver on 6.2+, or if you still need to compile it | 11:48 |
| djph | either way, it'll need internet for a little bit. | 11:48 |
| freaxeh | i'll borrow the cable from another computer for a bit brb | 11:49 |
| sixwheeledbeast | I'd trust the a distro's version of steam over valve any day | 11:54 |
| djph | ... it's the same steam .. | 11:55 |
| gnarface | there were a couple minor library issues with the one from valve's website i don't know if they ever fixed | 11:55 |
| djph | it's been playing nice since Chimaera here | 11:56 |
| gnarface | the distro version basically has a one line wrapper script fix, last i checked | 11:56 |
| gnarface | most people have just symlinked around the issue by hand, i suspect | 11:56 |
| djph | probably | 11:56 |
| gnarface | maybe it's all old news though, been a while since i did a fresh install of it | 11:57 |
| amarsh04 | Does one have to enable multi-arch to be able to install Steam? | 11:57 |
| gnarface | uh, maybe | 11:58 |
| gnarface | yea, i think so | 11:58 |
| djph | yep | 11:58 |
| amarsh04 | steam-installer requires steam-libs-i386 which is unavailable in my x86-64 only installation | 11:59 |
| freaxeh | which repos am i installing from? | 12:06 |
| freaxeh | i'm assuming im installing a repo into sources.list then apt-getting it | 12:06 |
| freaxeh | < noob | 12:06 |
| freaxeh | i tried running apt install steam-installer but it has no installation candidate | 12:07 |
| freaxeh | https://linuxcapable.com/how-to-install-steam-on-debian-linux/ | 12:08 |
| freaxeh | right according to this i use repo.steampowered.com | 12:09 |
| gnarface | freaxeh: it's in contrib, but you'll probably want non-free as well | 12:09 |
| gnarface | freaxeh: no, just fix your sources.list; your first instinct was correct | 12:09 |
| freaxeh | k | 12:09 |
| gnarface | freaxeh: like this: https://paste.debian.net/1326349/ | 12:10 |
| gnarface | (although, personally i typically run with only main enabled, and just put the others in when i want something specific from them updated, since they tend to have lower quality control than the stuff in main) | 12:10 |
| gnarface | i think you also will want to run "dpkg --add-architecture i386" then "apt-get update" before using the new sources.list | 12:12 |
| freaxeh | i've got steam-libs, steam-libs-i386:i386 and steamcmd:i386 but no steam-installer | 12:15 |
| freaxeh | this is in synaptic gui | 12:16 |
| freaxeh | do i need to use version 6? | 12:16 |
| freaxeh | i'm on daedalus 5.0.1 | 12:16 |
| gnarface | no, you shouldn't need version 6 | 12:17 |
| gnarface | it should be there: https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=%5Esteam-installer%24&x=submit | 12:18 |
| gnarface | it's steam-installer:amd64 though, not steam-installer:i386 | 12:18 |
| gnarface | it just depends on both so you need to enable both | 12:18 |
| gnarface | (you'll probably need to install a bunch of other i386 versions of drivers and libraries you already have, too) | 12:18 |
| freaxeh | i am using deb.devuan.org as the repo | 12:19 |
| gnarface | did you make your /etc/apt/sources.list match the one i pasted here? https://paste.debian.net/1326349/ | 12:19 |
| freaxeh | yes | 12:19 |
| gnarface | did you run 'apt-get update' ? | 12:20 |
| freaxeh | ah i forgot to add contrib | 12:20 |
| freaxeh | that fixed it, i can see steam-installer now | 12:21 |
| freaxeh | 183 new packages to install sounds about right.. | 12:22 |
| freaxeh | updating steam... | 12:24 |
| freaxeh | yay we have login | 12:25 |
| freaxeh | now to find my lost usb drive, bbl | 12:25 |
| freaxeh | that was easy btw, also thank you | 12:26 |
| freaxeh | whats the best way to install nvidia drivers? synaptic? | 12:34 |
| freem | Hi. I have an issue with ssh (on debian) and copy paste: I have 3 terminals open (more, really, but..). 1 local, and 2 ssh sessions toward the same remote computer. I can copy from the local terminal to paste on a ssh one, but I can't copy-paste from a remote toward local, nor from a remote toward the other remote (again: same target), but I can from a remote to itself. I am 95% certain this is a "recent" change in Debian, and was wondering if any of | 12:54 |
| freem | you knew what could create this problem. I smell some kind of bullshit security measure behind this... same as the stuff to annoy me when I try to copy several lines from urxvt to copy them into urxvt... | 12:54 |
| djph | as in your chosen DE doesn't play nice with the copy/paste? | 12:56 |
| freem | why would that only apply to ssh sessions, then? And I'm pretty certain this changed along a major release, without me changing my wm (i3) | 12:58 |
| gnarface | freaxeh: apt-get or aptitude will work fine too | 12:58 |
| gnarface | freaxeh: the trick is just that they're spread out across a lot of packages, and for steam to work you'll need both the :amd64 and :i386 versions of a lot of them | 13:00 |
| freaxeh | gnarface: sounds too confusing, my amd card should arrive tomorrow or friday so i'll just wait until then i guess | 13:00 |
| djph | freem: I've never noticed it here... i'll have to check later when I have a box with a DE | 13:00 |
| djph | or, well, WM rather | 13:01 |
| gnarface | freaxeh: it's not a super big deal for me to paste a working package list for you, but if you don't have the nvidia drivers installed already then waiting will save you some cleanup i suppose... | 13:02 |
| freem | yeah, took me a long while to be annoyed enough by this, because for a long while I didn't remote connected much, so... | 13:02 |
| freaxeh | gnarface: i'm thinking that aswell. want to keep the system clean | 13:02 |
| freem | oh... regarding my copy+paste problem... it's even worst! apparently, it is when I try to copy from/to a remote vim session, but how can this have any impact? | 13:24 |
| djph | I have noticed vim gets kinda weird sometimes, as if the usual copy/paste (highlight -> mid-click) is doing something "new" | 13:31 |
| djph | though I have at least four different systems (devuan daedalus, chimaera, ubuntu-server-2x.04, and a debian who's name escapes me now -- the equivalent to Chimaera) | 13:32 |
| djph | always just attributed it to "different version" (and/or 'user-error'). Will do some digging this evening | 13:33 |
| freem | all my systems are running the same OS. Not exact same packages installed, ofc, but same debian version | 15:15 |
| stripinska8 | just upgraded from Daedalus to Excalibur which went surprising well with only a few problems with texlive. Now suddenly many shared libraries seem to have vanished. | 16:45 |
| stripinska8 | Not sure if this is the right forum to talk about testing, if not please direct me to where I should be. | 16:47 |
| fsmithred | stripinska8, did you install the usrmerge package before doing the upgrade to excalibur? | 16:50 |
| golinux | Did you do the usrmerge before upgrading? UsrMerge Status: Testing/Excalibur and more | 16:50 |
| golinux | https://www.devuan.org/os/explore | 16:51 |
| stripinska8 | Yes I did that some time ago and it was working fine. | 16:51 |
| stripinska8 | I did UsrMerge a week or so later the usual sudo apt update, sudo apt upgrade, change sources.list to point to Excalibur | 16:53 |
| fsmithred | Things seem to have vanished because stuff is not working or because during the upgrade it said it was removing stuff? | 16:53 |
| stripinska8 | Then update, upgrade, a few apt --fix-broken install, got hung up on texlive requires texlive base24 but 22 is installed which neither apt nor aptitude could resolve | 16:55 |
| stripinska8 | Downloaded the new texlive and texlive-fonts and installed with dpkg. This sorted out the problem and apt --fix-broken install completed installing some removing others. | 16:57 |
| stripinska8 | Thereafter apt update, upgrade completed with no problems. apt dist-upgrade also completed with no problems. During this KDE was removed but apart from that everything was running fine. | 16:59 |
| stripinska8 | After a couple of reboots everything is still working fine so I tried installing kde-full which also seemed to have worked properly, upgrade and dist-upgrade tell me everything is installed there are some packages installed and not needed to use apt autoremove. This seems to have been a big mistake as it seems to have taken out a lot of shared libraries. | 17:02 |
| stripinska8 | I'll be away for about half an hour as I need to walk the dog, back soon. | 17:03 |
| stripinska8 | One of the missing libraries is apparmor.so.1 which prevents me using sudo to reinstall the missing files. | 17:59 |
| stripinska8 | I can however use su to become root and work from there. This brings up the next problem. | 18:00 |
| stripinska8 | any attempt to install anything with apt brings up this message /bin/sh: 1: /usr/bin/apt-listchanges: not found | 18:03 |
| rwp | stripinska8, That is probably a configured hook in /etc/apt/apt.conf or /etc/apt/apt.conf.d/* and removing that configuration would avoid the apt-listchanges hook. | 20:06 |
| rwp | if it is a file in /etc/apt/apt.conf.d/* then I would remove it. Then purge apt-listchanges. Then after you recover if you install apt-listchanges it will install the hook config itself correctly. | 20:07 |
| rwp | (I say that because everyone wants to comment out or save these things and that actually gets in the way of it automatically working correctly later.) | 20:07 |
| rwp | If you still have the .deb file in /var/cache/apt/archives/ and if dpkg works then you can re-install any of those packages again using dpkg -i and the path to the .deb file. Verify that the version is the same version as what you have installed and it should be okay. | 20:10 |
| rwp | If you are trying to re-install to recover a missing conffile in /etc then you must use dpkg --force-confmiss in order to tell dpkg to install the missing file. | 20:12 |
| rwp | (This behavior I completely disagree with and it is a change from the original. It was successfully argued to be the Policy conforming behavior some years ago by a particularly pedantic person who claimed that removing a config file was explicit local admin configuration.) | 20:12 |
| rwp | And so the behavior of dpkg was changed and it gained a --force-confmiss option which I always specify now. Via apt it is apt -o DPkg::Options::=--force-confmiss | 20:12 |
| stripinska8 | Ok thank you I will try that and let you know in the morning (my time) how it worked. | 20:18 |
| stripinska8 | Removing that file fixed part of it but now everything is in German | 20:34 |
| dvbst | hello again | 21:24 |
| dvbst | i come to inform you of a wierd bug in the devuan daedalus netinstall | 21:25 |
| rwp | stripinska8, You can override and force the compiled in default local with "export LC_ALL=C" and then set the local properly "dpkg-reconfigure locales" later when things are working. | 21:25 |
| rwp | dvbst, Don't keep us in suspense! What's the bug? | 21:26 |
| dvbst | so i have a setup with /dev/sda and /dev/sdb where the sdb is the install media, and i chose to install it with encrypted lvm, full disk, no bonus partitions, and it decided to wipe out not only sda but also sdb and the installation failed cuz you know what happens when you dd on the system drive | 21:27 |
| dvbst | that is all | 21:28 |
| rwp | That's with the netinst image? At least you haven't lost anything because you were installing and so didn't have anything there yet. | 21:37 |
| dvbst | yup | 21:37 |
| dvbst | but now i have to reflash it | 21:37 |
| dvbst | and it is precisely the devuan_daedalus_5.0.1_amd64_netinstall.iso | 21:38 |
| rwp | Were you following the instructions from here? https://www.devuan.org/os/documentation/install-guides/daedalus/install-devuan | 21:38 |
| rwp | There are screenshot images of every dialog. It's really a pretty good reference for the installation. | 21:38 |
| dvbst | no i werent following any instructions, i had done this a hundred times already so i know what im doing, i shouldve went with manual partitioning but i was lazy | 21:39 |
| rwp | Honestly I don't know how this could have happened. I have been through that installation process myself a zillion times and am very familiar with it. | 21:40 |
| dvbst | yea thats what im saying | 21:41 |
| dvbst | but it did say "the blah blah of following will be changed: sda sdb" | 21:42 |
| dvbst | but i thought, thats odd, must be some error in printing the message, and just clicked ok on it | 21:42 |
| dvbst | but it turns out it wasnt kidding when it said sdb | 21:43 |
| paculino | Is repo.jing.rocks down? | 21:43 |
| fsmithred | paculino, check apt-panopticon | 21:47 |
| fsmithred | http://veritas.devuan.org/apt-panopticon/results/Report-web.html | 21:48 |
| paculino | Thank you | 21:49 |
| paculino | Yeah, it's down. I tried toggling internet, but it didn't work | 21:49 |
| systemdlete | I have dns-nameservers set in my interfaces file, yet the /etc/resolv.conf file does not get updated when I restart the networking service. Am I using this incorrectly? Or is this no longer supported? | 21:49 |
| systemdlete | I looked through docs online, and they say that now I have to run resolveconf (or is it resolvctl?). | 21:50 |
| systemdlete | I figured the tools do this for you, but I guess they dont | 21:51 |
| fsmithred | systemdlete, I make /etc/resolv.conf immutable so network-manager won't change it. | 21:51 |
| rwp | repo.jing.rocks is responding for me okay. | 21:52 |
| systemdlete | I need it to be updated/changed sometimes. | 21:52 |
| systemdlete | I am not using network-manager or wicd, or connman | 21:53 |
| systemdlete | do I need one of those to get this to work successfully? | 21:53 |
| rwp | I switched from NetworkManager to wpagui recently and now am back to using ifupdown+wpa_gui and am much happier again. | 21:54 |
| rwp | Somehow I had missed knowing about wpagui all of this time. It works well. I could have been using it instead of the awful NM all of this time. (me smacks forehead with palm) | 21:55 |
| fsmithred | I occasionally need to change resolv.conf so I just do it manually. | 21:55 |
| rwp | I have seen a weird glitch though. Every so often something causes *another* dhclient to be started. Having TWO dhclients running breaks things. Causes the connection to be cycled repeatedly as the two dhclients fight with each other for control. | 21:56 |
| rwp | To resolve that I can run ifdown wlan0 and verify that all dhclients are not running, killing any still running, then ifup wlan0 and things are reset to working. | 21:56 |
| systemdlete | I'm not using dhcp for this; only static IPs | 21:57 |
| rwp | I have no idea what causes another dhclient to be launched but it's completely broken when that occurs. It most often happens immediately upon me connecting to a brand new Access Point through the wpa_gui interface. | 21:57 |
| systemdlete | But I need to be able to switch network config frequently. | 21:57 |
| systemdlete | anyone comment on connman? | 21:58 |
| rwp | If not using dhcp then that would be prime to also not be using network-manager and just using static ifupdown configurations. | 21:58 |
| fsmithred | maybe defining virtual interfaces would help | 21:58 |
| fsmithred | I think that's what it's called. | 21:58 |
| fsmithred | just an alias in /etc/network/interfaces | 21:58 |
| rwp | connman worked okay for me. It functioned. But the user interface of connman was odd/bizarre for me. I just didn't warm up to it. | 21:58 |
| systemdlete | I'm using virtual interfaces, actually. But that isn't the issue. I only want one of those virtual interfaces up at any time | 21:59 |
| systemdlete | rwp: Istr using connman at some point, maybe on my tablet/laptop. | 21:59 |
| fsmithred | yeah, so you do ifdown mynet 1 && ifup mynet2 | 21:59 |
| systemdlete | no, I run service networking stop; service networking start | 22:00 |
| systemdlete | (after updating the interfaces file) | 22:01 |
| rrq | should be stop+change+start really | 22:01 |
| rwp | That follows the principle that there are always multiple ways to do something. | 22:01 |
| systemdlete | (it is; I was avoiding typing) | 22:01 |
| rrq | :) | 22:01 |
| systemdlete | fsmithred, so I could have one interfaces file and turn off and on interfaces as needed... hmmm. | 22:02 |
| systemdlete | Not sure why that didn't occur to me first. | 22:02 |
| systemdlete | thanks! | 22:02 |
| systemdlete | always appreciating the help here. | 22:02 |
| fsmithred | https://wiki.debian.org/NetworkConfiguration Look at Multiple IP addresses on one interface. They show eth0 for example, but I've seen it used for wlan0 which is more likely to get used in different locations. | 22:06 |
| fsmithred | and I think I've seen it as wlan0=something rather than wlan0:0 | 22:07 |
| fsmithred | but I'm remembering the debian manual for wheezy. | 22:07 |
| fsmithred | https://refracta.org/docs/debian-handbook-wheezy.pdf | 22:08 |
| rwp | I don't like the change to ifupdown which added what they call iproute2 method in that doc. The addition then required a bunch of semaphores to be added because it's creating a facade that there are multiple interfaces when there isn't and I have had problems with it. | 22:15 |
| rwp | I much prefer what they say is the Manual approach as that matches the system directly and is more clear because that's what is happening at the system level. | 22:15 |
| systemdlete | fsmithred, thanks, but multiple addresses on one interface wouldn't work for what I am doing. | 22:17 |
| rwp | If all else fails then one could always configure the interface manually using the underlying ip commands directly. That is how things are actually getting done under ifupdown. | 22:20 |
| fsmithred | systemdlete, I thought you were using different dns addresses and that you were putting them in the interfaces file | 22:21 |
| fsmithred | define two different logical interfaces with the same ip address but different dns addresses | 22:23 |
| rrq | systemdlete: how do you declare DNS address(es) in /etc/network/interfaces? | 22:55 |
| rrq | is it bmo an if-up.d/ script that recognizes a DNS attribute and edits /etc/resolv.conf (which is where applicable DNS addresses are declared) ? | 23:02 |
| systemdlete | rrq: As I said above, I use "dns-nameservers 192.168.x.y" (where x & y are actual numbers, yada yada) | 23:04 |
| systemdlete | "bmo?" | 23:05 |
| rrq | by means of | 23:05 |
| systemdlete | oh | 23:05 |
| systemdlete | ty | 23:05 |
| systemdlete | A. No idea. | 23:05 |
| rrq | hmm is dns-nameservers part of the "static" method? (it's not in "man interfaces") | 23:06 |
| rrq | i.e. do you have any manual/doc about using a dns-nameservers attrobute? | 23:09 |
| systemdlete | rrq: This is a major part of the problem. The docs don't seem to be consistent everywhere. I've seen examples where they used "dns-nameserver" (not plural) which is, according to one doc I saw, not valid. (It just seems to be ignored). | 23:10 |
| systemdlete | Strangely, in the interfaces file, you can only have one line of dns-nameservers and all the ones you want must follow, space separated | 23:11 |
| systemdlete | BUT | 23:11 |
| systemdlete | In the /etc/resolv.conf file, only "nameserver" is valid, and you can only specify one address per line. | 23:11 |
| * systemdlete guesses that the big planning session for the design phase was canceled, or everyone was out sick with the flu) | 23:12 | |
| rrq | ifupdown is a very open system which generally is based on scripts in /etc/if-*.d/ that get invoked with the attributes as environment variables | 23:12 |
| systemdlete | so the syntax is inconsistent (not intuitive) and poorly doxed | 23:12 |
| rrq | so different utilities plop different scripts into there to do things | 23:13 |
| systemdlete | I see. | 23:14 |
| systemdlete | does ifupdown properly update the resolv.conf file? | 23:14 |
| rrq | no not by itself | 23:14 |
| systemdlete | or does it also require endless iterations, gyrations, tortubations, and sensations? | 23:15 |
| rrq | ifupdown doesn't touch it.. but some/many/most dhcp implementations do since they typically get DNS info from their server | 23:15 |
| systemdlete | have you noticed/used ifupdown2? | 23:15 |
| systemdlete | also, ifupdown-ng | 23:16 |
| rrq | no .. do they do majorly different things? | 23:16 |
| systemdlete | I mean, as long as we are talking about alternatives here.... | 23:16 |
| systemdlete | description for ifupdown2: "Network Interface Management tool similar to ifupdown" | 23:17 |
| systemdlete | for ifupdown-ng: "Network Interface Management tool similar to ifupdown{,2}" | 23:17 |
| rrq | "but rewritten in python" .. | 23:17 |
| systemdlete | which, to a user, means: _______________________ ? | 23:18 |
| systemdlete | (that was rhetorical...) | 23:18 |
| rrq | means does the same (in a worse way) ... (that's opiniated :) | 23:18 |
| systemdlete | why not perl, for that matter? | 23:19 |
| systemdlete | but anyway, to avoid getting too far afield | 23:19 |
| rrq | a script in if-up.d/ will be invoked by "ifup" with IF_DNS_NAMESERVER being set | 23:19 |
| systemdlete | do you use ifupdown yourself? | 23:19 |
| rrq | yes lots | 23:19 |
| rrq | only | 23:19 |
| systemdlete | does it use the interfaces file? | 23:20 |
| rrq | ifup uses interfaces file | 23:20 |
| systemdlete | what about interaction with the networking services in /etc/init.d? | 23:20 |
| systemdlete | seamless? | 23:20 |
| rrq | "networking" belongs to ifupdown and it uses ifup | 23:21 |
| systemdlete | so I probably already have it then | 23:21 |
| rrq | even udev uses ifup for its networking (which acts on the allow-hotplug interfaces) | 23:21 |
| systemdlete | I have networking in /etc/init.d but I have not installed ifupdown | 23:22 |
| rrq | I use it for setup of all "my" systems including various VPN setup etc | 23:22 |
| systemdlete | so I am a bit confused here | 23:22 |
| systemdlete | you say that "networking" is part of ifupdown, but I do not have ifupdown installed. | 23:23 |
| rrq | what does "dpkg -S bin/ifup" say? | 23:23 |
| systemdlete | ifupdown: /sbin/ifup | 23:23 |
| rrq | you have ifupdown installed | 23:24 |
| systemdlete | I'm basing this on output from apt info ifupdown | 23:24 |
| systemdlete | It does not show it is installed, which I thought meant it is not installed | 23:24 |
| systemdlete | (forgive my poor apt skills) | 23:24 |
| rrq | I don't know apt .. maybe "apt list --installed" includes ifupdown? | 23:24 |
| systemdlete | oh crum. I was in a non-root window when I ran those commands... | 23:25 |
| systemdlete | (forgive my poor windowing skills) | 23:25 |
| rrq | most of apt is (should be) available to non-root | 23:25 |
| rrq | (other than installing) | 23:26 |
| systemdlete | yes, but I was unable to run ifup, because I was not root | 23:26 |
| systemdlete | so that is why I got confused | 23:26 |
| rrq | ok | 23:26 |
| systemdlete | (damned shell windows--they all look alike!) | 23:26 |
| systemdlete | (and, yes, I know about the "-T" option) | 23:26 |
| systemdlete | (and I use it, but not all the time) | 23:27 |
| systemdlete | well, now I have the knowledge needed (thanks to you and fsmithred) to implement what I need. | 23:27 |
| systemdlete | thank you for all the info and instruction | 23:27 |
| rrq | yes.. ifupdown offers a scriptable network configuration system that allows extensions to the attributes you put into the iface blocks | 23:28 |
| systemdlete | Those extensions might be more than I need, though. I think ifup/ifdown will likely do the trick for me. | 23:28 |
| systemdlete | (scripting, e.g., if I find I need that) | 23:29 |
| systemdlete | oh | 23:29 |
| systemdlete | as far as upding the /etc/resolv.conf file, how do I make that happen? I'd think by now there would be no need to cobble my own script to do that. | 23:29 |
| systemdlete | *updating | 23:29 |
| systemdlete | (forgive my poor typing) | 23:29 |
| rrq | if you need "dns-nameserver" to be handled you need a script that does that | 23:30 |
| systemdlete | and no one has already done that? | 23:31 |
| systemdlete | I mean, not a part of the "canon" of ifupdown? | 23:31 |
| rrq | the deal is that if you document the extansion but not the scripting then you make it look like magic :) | 23:31 |
| systemdlete | I prefer to re-cycle work already done to save electronic bits (not to mention maintenance) | 23:32 |
| systemdlete | So I need to brush up on my magic skills now? | 23:32 |
| rrq | amen to recycling :) | 23:32 |
| systemdlete | (forgive my poor magic skills) | 23:32 |
| rrq | I don't know which program/scripting uses a dns-nameserver attribute | 23:33 |
| onefang | So long as your poor apt, windowing, typing, and magic skills don't result in you dleting your system. | 23:34 |
| rrq | it looks like something a DHCP method could include, but you want static method(s) | 23:34 |
| rrq | put a script in /etc/network/if-up.d ... that recognizes the presence of environment IF_DNS_NAMESERVER and does smoe good things with its value | 23:35 |
| systemdlete | rrq: I'm guessing I can figure this out | 23:35 |
| systemdlete | IF_DNS_NAMESERVER is the ticket then | 23:35 |
| systemdlete | or I should say $IF_DNS_NAMESERVER | 23:35 |
| rrq | yes attribute "dns-nameserver" becomes IF_DNS_NAMSERVER | 23:36 |
| systemdlete | coolbeans | 23:36 |
| systemdlete | ty ty | 23:36 |
| rrq | that script will be invoked for every ifup call regardless of interface | 23:36 |
| systemdlete | of course it will | 23:37 |
| rrq | so it shouldn;t do things without the envirnment variable | 23:37 |
| rwp | dns-nameserver along with dns-search IIRC is implemented in the "resolvconf" package. | 23:37 |
| rrq | (thanks) | 23:37 |
| rwp | Editing of the /etc/resolv.conf file was abstracted away into resolvconf. (How well it was done some people will argue about because there is now openresolvconf(sp?) now.) | 23:37 |
| systemdlete | rwp: Yes, it is. And some web pages suggest resolveconf should be run with... -u? | 23:38 |
| systemdlete | I notice there is a resolvctl also | 23:38 |
| rwp | resolvctl? (looking...) | 23:38 |
| systemdlete | oopsy | 23:38 |
| systemdlete | resolv(e)ctl | 23:38 |
| systemdlete | (just love the consistency) | 23:39 |
| rwp | I don't have resolv* anything other than resolvconf installed. | 23:39 |
| systemdlete | resolvectl even has an option to set the logging level for systemd-resolved | 23:40 |
| systemdlete | (just love the hardcoding) | 23:40 |
| rwp | Ahem, this is Devuan and I don't have systemd-resolvd installed. | 23:40 |
| rrq | maybe we are loitering into the dark back streets of debian here | 23:40 |
| systemdlete | Dangerous characters lurk there... | 23:40 |
| rwp | systemd-resolvd is terribly buggy with regards to DNSSEC too. | 23:40 |
| systemdlete | WHAT? | 23:41 |
| systemdlete | you are kidding around, for sure | 23:41 |
| rwp | No. It's buggy. It doesn't handle cases such as where a top level domain is implementing DNSSEC but lower level subdomains do not. Just for one example. | 23:41 |
| systemdlete | systemd permeates every linux distro these days (except ours and a few others) so you must be wrong | 23:41 |
| systemdlete | /sarcasm | 23:42 |
| systemdlete | this is getting OT | 23:42 |
| rwp | (shrug) This has caused sites to *drop* DNSSEC from their top level domain which reduces security just because of the complaints from systemd distro users. | 23:42 |
| rwp | Back on the topic then... The resolvconf implementation got into a pushing match between resolvconf package and bind9 package as to who should handle /etc/resolvconf/update.d/resolvconf-update-bind for updating the config for a locally installed bind9 configuration. | 23:45 |
| rwp | This is an example of where resolvconf is less than working out of the box for people if they also have bind9 installed as a caching nameserver. Which is a bummer. It used to work out of the box. Now I must install that script myself in order to have it work. | 23:45 |
| rwp | I think things like that have given people a bad experience with resolvconf. And even I myself only install resolvconf on my mobile laptops which roam around. I do not install resolvconf on static IP servers. | 23:46 |
| rwp | There is also the problem of how to handle VPNs. And these days VPNs are everywhere. Merging in different DNS domains is just a good thought problem by itself. | 23:47 |
| rrq | is there something "smaller" than resolvconf.. just acting on the dns-nameserver attribute (without trying to solve all possible problem variations)? | 23:53 |
| onefang | Hmm, only reason I have bind9 anything installed is for the dig tool. Wonder if there's something better, now that you mention it. | 23:56 |
| onefang | I was gonna suggest resolvconf-admin, but I got half way through reading the apt description, then it turned into systemd propaganda. Pffft | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!