| hyrcanus | btrfs is looking more interesting with newer kernel | 01:04 |
|---|---|---|
| golinux | hyrcanus: If you like to discuss btrfs, #devuan-offtopic would be the place to do so. #devuan would be the place to ask questions about installing and configuring it. | 01:15 |
| golinux | IOW chat vs support. Thanks | 01:16 |
| hyrcanus | ACK | 01:17 |
| Hydragyrum | hyrcanus, also for btrfs-specific stuff, #btrfs is rather active | 02:22 |
| mdt | hi, i am again trying to run wayland, especially sway. when i log in and start sway it says XDG_RUNTIME_DIR isnt set. i did so manually and get "User has no sessions". so what is supposed to create all these shiny details normally? | 12:26 |
| mdt | i tried https://wiki.gentoo.org/wiki/Sway which gives alot of hints but with no success (i finally want to run sway automatically on boot and tried those scripts) | 12:28 |
| mdt | i used `openvt` but that complains "Couldn't get a file descriptor referring to the console." when run as user | 12:30 |
| xrogaan | mdt: XDG is supposed to be set by your desktop environment. I don't run waylands, but I'd look at how your environment is being setup. | 12:33 |
| xrogaan | somewhere in /etc/wayland maybe? | 12:33 |
| mdt | xrogaan: i either login on the console or via ssh | 12:33 |
| xrogaan | I know that the environment for X is handled in /etc/X11 | 12:34 |
| mdt | both dont have any XGD_* env - so i wonder who is responsible for that.. | 12:34 |
| mdt | in my X session i dont have any of those (in a shell in a term) | 12:35 |
| xrogaan | is /etc/xdg/user-dirs.conf present and enabled? | 12:37 |
| xrogaan | you need the package xdg-user-dirs | 12:38 |
| mdt | that package seems to manage those weird default dirs in home... no XDG_ env | 12:44 |
| mdt | it seems systemd creates those vars on login... | 12:50 |
| GyrosGeier | yes, these belong to FreeDesktop | 12:51 |
| GyrosGeier | but apps should have reasonable defaults | 12:51 |
| mdt | sway doesnt seem to 😉 | 12:54 |
| ham5urg | Is there something behind the group 'staff'? The group of /usr/local/sbin is staff. | 20:03 |
| user____ | It's not something, it's someone :) | 20:07 |
| xrogaan | ham5urg: it's debian specific | 20:08 |
| xrogaan | ham5urg: https://wiki.debian.org/SystemGroups#Other_System_Groups | 20:09 |
| ham5urg | I see. 'staff' seems to be an empty group. To which group should I assign a binary in /usr/local/bin ? root or staff? | 20:13 |
| user____ | ham5urg: root | 20:37 |
| rwp | ham5urg, Up until the last release group staff was a useful half-way place for someone to be not root but install system tools. | 20:39 |
| rwp | Since then one could ./configure, make, make check, make install, as themselves. | 20:40 |
| rwp | It would configure and install to /usr/local and being in group staff meant it could be done as non-root. | 20:40 |
| rwp | However a release or so ago the new kids in charge got rid of that very useful feature. Claiming that anyone who wants it is always free to set it up themselves. | 20:41 |
| rwp | Sigh. It's the tyranny of the default though. I always set it up now. But it is no longer the default. | 20:41 |
| rwp | Older systems upgraded maintain the /usr/local group by "staff" but newer pristine installs don't have it. Unless you care enough to set it up. | 20:42 |
| rwp | Instead of the useful non-root ability to install local compiled software now all of the instructions are to become superuser root and run make install on random software projects. | 20:43 |
| rwp | What could possibly go wrong with that? :-( | 20:43 |
| ham5urg | I understand, thanks for the explanation. | 20:54 |
| user____ | You're supposed to install non root software in your own bin dirs, not globally. | 21:00 |
| user____ | Tbh it was a nasty side channel to mayhem imo, when used for compilation as above. | 21:00 |
| joerg | rwp: I thought you'd install such stuff into you rown homedir until the system admin aka root decides to make it available to all users and installs it as root to /usr/[local/]bin | 21:04 |
| joerg | oh, user____ already had it covered | 21:05 |
| jonadab | Depends what the purpose of installing it is. | 21:28 |
| jonadab | I can imagine situations in which you'd want to empower someone to install software, without giving them full root. College IT departments spring immediately to mind: every time a professor calls and says "we need foo for the students in CSI-389 by Tuesday"... | 21:30 |
| jonadab | But in this kind of context I don't think it matters what the default setup is, since anyone interacting with this stuff is NOT going to be an end user. | 21:31 |
| jonadab | And defaults are really only important when dealing with people who are too green or non-technically-inclined to know how to change settings. | 21:31 |
| jonadab | Anybody who can install an operating system, should be past that. | 21:32 |
| hyrcanus | yeah you'd think people could look up definitionns of things before 2020 also | 21:33 |
| peterrooney | jonadab: operating systems have become very easy to install. | 21:33 |
| hyrcanus | and realize the definitionnn was changed | 21:33 |
| jonadab | peterrooney: Yes, but changing settings isn't that hard either. I mean, editing /etc/sudoers for example, is not exactly rocket surgery. | 21:34 |
| peterrooney | jonadab: I can't imagine "Devuan: only install this if you know everything already" as a great slogan | 21:34 |
| jonadab | That's not what I'm saying. | 21:34 |
| hyrcanus | it's not wrong to deliver a product for professionals | 21:35 |
| peterrooney | jonadab: uh, it kinda is rocket surgery, which is why visudo exists. | 21:35 |
| jonadab | But if somebody wants adding users to a staff group to empower them to do certain things, hopefully they should know how to make that happen. | 21:35 |
| jonadab | peterrooney: Ok, yes, but visudo has been around for a couple of decades; we all know about it and it's not new. | 21:36 |
| jonadab | If you're at a tech-knowledge level where you are empowering other people to install software without giving them full root powers, I hope you know about visudo already. | 21:36 |
| rwp | Not just university departments, though that would be one good use. | 22:45 |
| rwp | For example before the previous release caught things up I wanted the newer tmux. | 22:45 |
| rwp | Therefore I did ./configure, make, make check, make install, of tmux so as to install it into /usr/local and made it available that way to everyone on the shared server machine. | 22:46 |
| rwp | But my main point is that running make install as root on random project software is a potentially dangerous situation. Accidents can happen. | 22:47 |
| rwp | Just yesterday we were talking about accidentally using dd to overwrite the wrong disk. | 22:47 |
| rwp | But you make your own luck. Running make install as root makes me nervous. Much more safe to run it as non-root. | 22:47 |
| rwp | Next topic, /etc/sudoers file. I never edit that file due to it being a dpkg "conffile". | 22:48 |
| rwp | Instead I always put local modifications into /etc/sudoers.d/sudoers-local so that it won't have any merge conflicts. | 22:48 |
| rwp | That way the dpkg dialog for modified conffiles is avoided. | 22:49 |
| rwp | Next topic, group "adm". I always add myself to group adm too. That way one can "less /var/log/syslog" (and other system log files there) as themselves without needing root for it. | 22:51 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!