| systemdlete | how do I control or view the power settings for wifi? | 05:01 |
|---|---|---|
| systemdlete | hmmm.. pm-utils? | 05:06 |
| mason | systemdlete: Generally the iw* tools. iwconfig, probably iw | 05:11 |
| mason | I don't know the newer tools, but check the man pages for all of them. | 05:11 |
| mason | Example: https://unix.stackexchange.com/questions/269661/how-to-turn-off-wireless-power-management-permanently | 05:11 |
| systemdlete | how can I write a rule for udev to turn off the power saver? I tried this: | 06:13 |
| systemdlete | ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on" | 06:14 |
| systemdlete | but that gives an error when I run it with udevadm test | 06:14 |
| rrq | which error? | 06:21 |
| rrq | the missing comma before RUN ? | 06:24 |
| onefang | I'm having issues with root running a program as another user. The exact same sudo command runs fine when running it as a user that has sudo rights. su and runuser tell me the user I'm trying to run the program as isn't a sudoer. | 06:26 |
| onefang | root@Superbitch:/opt/opensim_SC-DG# runuser opensimsc whoami | 06:27 |
| onefang | /usr/bin/whoami: /usr/bin/whoami: cannot execute binary file | 06:27 |
| onefang | root@Superbitch:/opt/opensim_SC-DG# runuser -u opensimsc /home/opensimsc/runGrid.sh | 06:27 |
| onefang | opensimsc is not in the sudoers file. This incident will be reported. | 06:28 |
| onefang | Same for -l, and same for su versions. | 06:28 |
| rrq | that first example lacks -u .. just a mistake here? | 06:32 |
| rrq | runuser opensimsc whoami .. should be: runuser -u opensimsc whoami | 06:33 |
| rrq | other: is opensimsc a sudoer ? | 06:34 |
| onefang | I gave examples with and without -u. | 06:37 |
| onefang | opensimsc isn't a sudoer, but I though these commands was for root to run, and run the argument as the given user. | 06:38 |
| onefang | man runuser doesn't mention sudoer at all. | 06:38 |
| rrq | "runuser -u blah foo" runs foo as user blah ... if foo is a script using sudo then that gets invoked as user blah | 06:39 |
| onefang | In theory yes, in practice nope. | 06:40 |
| rrq | which ... runuser or script/sudo ? | 06:40 |
| onefang | It's not running anything as the specified user. | 06:41 |
| rrq | well, it sets the effective user of the process to be that user regardless of whether the user has a login shell or not | 06:41 |
| onefang | runuser -u opensimsc bash | 06:41 |
| onefang | That works. lol | 06:42 |
| onefang | I was hoping to avoid yet another layer. I guess I can do runuser -l opensimsc bash -c "actualprogram" | 06:43 |
| rrq | If the option -u is not given, runuser falls back to su-compatible semantics and a shell is executed | 06:43 |
| rrq | says the man page :) | 06:43 |
| onefang | runuser -u opensimsc /home/opensimsc/runGrid.sh | 06:45 |
| onefang | opensimsc is not in the sudoers file. This incident will be reported. | 06:45 |
| onefang | You would think, huh? lol | 06:45 |
| systemdlete | rrq: I fixed that. Actually, I just found out I can run a preconnect script in wicd. I'm doing that now | 06:46 |
| systemdlete | onefang in BIIIIIG trouble... | 06:48 |
| systemdlete | (he's been reported!) | 06:48 |
| onefang | Reported to myself. lol | 06:48 |
| systemdlete | still | 06:49 |
| rrq | mmm onefang runs as root to run a user that runs as root ... | 06:50 |
| onefang | No, I'm trying to get root to run a user that DOESN'T run as root and has no special prigiledges, so I can run the command from /etc/rc.local | 06:51 |
| onefang | Ah start-stop-daemon is behaving better for this task. | 06:56 |
| onefang | Or not, it's giving me exactly the same bullshit sudo did in the first place. lol | 07:08 |
| onefang | OK, one extra level of bash it is then. Pffft | 07:17 |
| rwp | Use "su -" to switch user to root, add yourself to the sudo group as root "adduser myusername sudo" (while there add the "adm" and "staff" groups too) then log out and log back in again and sudo will work. | 07:57 |
| rwp | And being in the adm group then you can look at /var/log/* log files without needing root too. Since then you will be in the adm group on your system. | 08:00 |
| rwp | onefang, Both start-stop-daemon and su need to be started from root already so that they can switch user to the non-root non-privileged account. | 08:01 |
| rwp | Using start-stop-daemon is useful if one is also using pidfiles and/or if someone wants to kill the process using a pidfile though. | 08:03 |
| rwp | If not then su is generally the traditional approach. I was never really sure of the advantage of runuser. | 08:04 |
| onefang | The problem isn't ME being in the sudo group. The problems was trying to sudo (as root) to the other user, who isn't in the sudo group, and should not be in that group | 08:17 |
| onefang | Adding an extra level of bash -c to what I was trying to run solved the problem. | 08:19 |
| onefang | Managed to cut it down to just two recursive bash -c. lol | 08:26 |
| systemdlete | onefang: What about sudo, using the -u (and maybe -g) options to set the user, group? Just wondering | 08:53 |
| onefang | sudo -u is what ended up working, just with one more bash -c in front of the actual program. | 09:06 |
| rwp | Who is the initial sudo -u being run from? Root or non-root? | 09:23 |
| onefang | root | 09:30 |
| onefang | The exact same sudo command worked fine when done as my usual user. Doing it as root needed the extra bash -c in front of it. shrugs | 09:32 |
| onefang | Works now, moved on. | 09:32 |
| spike1 | Hello, has anyone managed to get FVWM running on Beowulf? I installed Beowulf without a GUI and booted into a terminal session. Then I installed FVWM. When I run 'startx' it crashes the machine and I have to reboot. The error that the X server displays is 'Xf86EnableIOPorts: Failed to set IOPO for I/O (operation not permitted)'. | 20:44 |
| rwp | spike1, Do you have xserver-xorg-legacy installed? I think that might be required. Not sure though. | 20:50 |
| nemo | https://lists.opensuse.org/archives/list/kernel@lists.opensuse.org/thread/PI44AW623CFLV3RRJPPZEIKDXN6QS5WI/ will this commit make it into chimæra? | 20:51 |
| rwp | spike1, I am always running with xserver-xorg-legacy due to other reasons. I am running i3 but previously ran fvwm and think both have similar requirements. | 20:52 |
| spike1 | rwp, yes, I do have xserver-xorg-legacy installed. Interestingly, as I was typing this on another machine I issued 'startx' again and it actually did start after a minute or so. Normally, FVWM should start almost instantaneously. So now I am investigating what is causing the delay. | 20:58 |
| rwp | spike1, That does sound like an exact timeout of some sort. | 21:04 |
| spike1 | rwp, yes, I was able to inspect the log now that it was actually saved. The delay is 30 seconds, according to the logfile. | 21:05 |
| rwp | Most of my Devuan systems are headless servers. Three of the rest are running XFCE. My fvwm system is, ahem, not yet running Devuan so don't know. Sorry. | 21:07 |
| rwp | nemo, Isn't that just a stable kernel patch? In which case all of those should flow through without problem. | 21:07 |
| spike1 | I am suspecting that it *might* have something to do with domain name resolution. The machine does not have access to a network and I might be trying to resolve some names before timing out. I am not sure how to disable that. | 21:10 |
| rwp | Traditionally distros have used localhost.localdomain as a completely offline but consistent naming strategy. | 21:11 |
| rwp | But you could put an override for whatever names you are using in /etc/hosts | 21:11 |
| nemo | rwp: yeah. I was just a bit unclear as to whether it was just going to be in ubuntu or not | 21:14 |
| nemo | rwp: looks like it was an OpenSuSE patch that got pushed last year after ubuntu declared stable LTS - I just didn't know how that worked with chimæra | 21:14 |
| nemo | when the cutoff was | 21:14 |
| nemo | rwp: and then, since it wasn't tagged (according to ubuntu kernel team) as fixes/cc:stable it got overlooked until the launchpad bug report last year | 21:15 |
| nemo | er | 21:15 |
| nemo | last *month* | 21:15 |
| nemo | hm... but since I'm on 5.10 in chimæra already, I guess that probably means this got picked up just fine | 21:15 |
| rwp | There is no cutoff time for security patches. Those flow through the security suite. But if it is a feature patch then I don't know. But it is pretty late in the release cycle for features to be added. | 21:15 |
| nemo | rwp: well... basically, if the remote windows machine reboots, the cifs module crashes | 21:16 |
| nemo | and only fix we'd found so far was rebooting linux | 21:16 |
| nemo | couldn't unload the cifs module and reload it | 21:16 |
| nemo | it was pretty annoying since there was one windows machine used in dev that got rebooted a lot | 21:17 |
| rwp | That does seem to be a good candidate then. | 21:17 |
| nemo | so it killed linux pretty easily without that patch | 21:17 |
| nemo | rwp: yeah, I was more just wondering if it was already in there or not | 21:17 |
| nemo | maybe I need to talk to the debian team | 21:17 |
| nemo | but figured I'd ask in channel I was more comfortable in first | 21:17 |
| nemo | like where in kernel history is chimæra right now. | 21:17 |
| nemo | would it have a standard patch from last august | 21:17 |
| rwp | Well... I am not the right person to talk to about kernel patches. I am just another kernel user. I suggest looking a little deeper. | 21:19 |
| rwp | For one you could test the chimaera kernel out and see if it suffers from the problem or not. That's probably the best way to really know. | 21:20 |
| nemo | ew | 21:20 |
| nemo | far preferable to check the revisions and RTFS 😃 | 21:20 |
| nemo | hm hm | 21:20 |
| nemo | lessee who here would know where the chimæra kernel comes from | 21:21 |
| * nemo looks at fsmithred hopefully | 21:21 | |
| fsmithred | ? | 21:22 |
| fsmithred | nemo, can you summarize? | 21:23 |
| nemo | https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/cifs/connect.c?id=a52930353eaf443489a350a135c5525a4acbbf56 | 21:23 |
| nemo | ^^^ is this commit in chimæra | 21:23 |
| fsmithred | no clue | 21:23 |
| fsmithred | we use debian kernels | 21:23 |
| fsmithred | unchanged | 21:23 |
| fsmithred | is it a security patch? | 21:23 |
| nemo | hm. ok. so I need to find... debian buster? | 21:23 |
| nemo | fsmithred: it fixes a crasher if remote windows machine reboots a cifs mount. we hit it about once a day right now forcing linux reboot | 21:24 |
| nemo | but. not on the devuan machines yet, since they don't have long-term cifs mounts yet | 21:24 |
| nemo | I was just trying to be proactive ☺ | 21:24 |
| nemo | but. I don't think it was tagged as security | 21:24 |
| fsmithred | go to salsa.debian.org, find the official linux-image archive and start reading commit messages or changelog | 21:25 |
| fsmithred | I guess | 21:25 |
| nemo | wheee 😃 | 21:25 |
| nemo | ok | 21:25 |
| nemo | kernel-team I suppose | 21:26 |
| nemo | hm. | 21:26 |
| nemo | fsmithred: so... buster right? | 21:26 |
| fsmithred | buster=beowulf | 21:27 |
| fsmithred | well... | 21:27 |
| nemo | oh. doh | 21:27 |
| fsmithred | buster > beowulf | 21:27 |
| fsmithred | no! | 21:27 |
| fsmithred | damn dyslexia | 21:27 |
| fsmithred | beowulf > buster! | 21:27 |
| debdog | hrrhrr | 21:27 |
| fsmithred | kernel team sounds good | 21:28 |
| nemo | oh. actually. duh. none of our servers are on chimæra yet - they are all beowulf. sooo odds are probably pretty good that by the time chimæra is released, this will have made it into upstream debian | 21:28 |
| nemo | fsmithred: so... sid? | 21:29 |
| nemo | but maybe I should just not worry about it | 21:30 |
| nemo | eh. bullseye I guess | 21:30 |
| fsmithred | sid/ceres and bullseye/chimaera all have the same kernel now, I think | 21:30 |
| fsmithred | 5.10 | 21:31 |
| nemo | 5.10 was released last december, so this patch prooobably made it in | 21:31 |
| fsmithred | it seems like something that they would port to older kernels | 21:31 |
| nemo | I'll just keep an eye out for it once chimæra is released | 21:32 |
| nemo | fsmithred: oh. yeah. definitely. ubuntu just didn't notice, and I guess they don't use the debian kernel. | 21:32 |
| fsmithred | at this point, we're just getting the bugs out of installer and live isos and desktop theme | 21:32 |
| fsmithred | anyone who is running chimaera is very happy with it | 21:33 |
| nemo | yep. I have it on all the machines at home | 21:33 |
| nemo | just haven't moved the servers at work | 21:33 |
| fsmithred | :) | 21:33 |
| brocashelm | correct, both chimaera and ceres use 5.10. will be interesting once bullseye is released with more recent packages right this moment | 21:40 |
| brocashelm | as buster/beowulf were 4.19 | 21:40 |
| onefang | Kernel 5.10 is in beowulf backports. I use it on my desktop for recent AMD GPU support. | 23:19 |
| brocashelm | nice | 23:21 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!