poeinklum | golinux: Ok, but - assuming this hasn't been reported, where do I report it? | 00:00 |
---|---|---|
golinux | MaxFun: https://wiki.debian.org/DontBreakDebian/#Don.27t_make_a_FrankenDebian | 00:00 |
golinux | Same goes for Devuan. | 00:01 |
golinux | poeinklum: If the package in Devuan is merged from Debian, report it in Debian. If we forked it report it to Devuan | 00:02 |
poeinklum | golinux: Ok... we'll se what happens. | 00:02 |
furrymcgee | There is still likely to be something of chasm between the two distributions, but any rapprochement should be welcome news to most https://lwn.net/Articles/770093/ | 00:09 |
golinux | poeinklum: Happy hunting! | 00:14 |
saptech | hello all | 01:02 |
saptech | I just noticed when I type 'ls -la' I see different group names | 01:03 |
saptech | https://bpaste.net/show/a7763b5f8cdc | 01:03 |
saptech | shouldn't the groups be same name as user, saptech saptech, instead of saptech adm? | 01:04 |
saptech | How can I change it? | 01:04 |
redrick | Isn't group 'adm' something to do with system monitoring tasks? I vaguely so recall. | 01:06 |
redrick | Like, many logs in /var/log are owned by group adm and are 0640 permissions, so anything that needs to read them should be running as group adm. | 01:08 |
redrick | https://wiki.gacq.com/index.php/Debian_default_system_groups_description | 01:08 |
redrick | 'adm: Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group.' | 01:08 |
redrick | Doesn't exactly answer your question, but perhaps points you in the right direction, e.g., the reason these subtrees areon't owned by your group (saptech) is that system monitoring tools are creating and writing them, not you. | 01:10 |
rwp | saptech, Something is wrong with your user and/or group setup. Those should not be group adm in your home directory. | 01:10 |
rwp | Yes. The default is UPG (user-private-groups) and every user gets their own group as their default in that strategy. | 01:10 |
redrick | rwp: Makes sense, so perhaps saptech's real task is to find out what system process is writing stuff in his homedir and make it stop that mishegoss. | 01:11 |
rwp | Before changing it one must first determine what is wrong. What is the output of "id" "id saptech" and probably also "grep '^adm:' /etc/group" so that we know the current configuration before suggesting a change to it. | 01:12 |
saptech | rwp, the default is UPG, I've never seen that with different distros | 01:13 |
rwp | Classical old legacy Unix typically put all users into a "users" group. That is the alternative. But it isn't as nice as UPG for many reasons. | 01:13 |
rwp | The idea is that a user will be in their own group. And may also be in other groups. | 01:14 |
rwp | For example a minimum for me might be: uid=1000(rwp) gid=1000(rwp) groups=1000(rwp),4(adm),27(sudo),50(staff) | 01:15 |
saptech | here is output from the id command, https://bpaste.net/show/af6edb8f4c66 | 01:15 |
saptech | $ grep '^adm:' /etc/group adm:x:4: | 01:16 |
rwp | Good! Your primary group is "gid=1000(saptech)" and so when new files are created they will be of that group. | 01:16 |
rwp | Hmm.. Why aren't you listed in /etc/group for the adm group? | 01:17 |
saptech | yes that is strange | 01:17 |
rwp | And grep ^saptech: /etc/passwd shows saptech:x:1000:1000:...other stuff for you? | 01:17 |
rwp | Okay. Next idea. Did the group of /home/saptech get set to be sgid adm and g+ws by mistake? | 01:18 |
rwp | If that were to happen then new files created there would assume the group set by the group of the directory with the g+ws sgid bit set. | 01:18 |
saptech | it may have. When I first installed devuan, I needed adm for my external hdd | 01:19 |
saptech | but I thought I was adding my user to the adm group | 01:19 |
saptech | that last grep command gives me two No such file or directory | 01:20 |
rwp | Looking I don't see you listed in the paste as being in the adm group. You should add yourself to it. | 01:21 |
rwp | "adduser saptech adm" and also to staff is convenient too "adduser saptech staff" | 01:22 |
saptech | ok | 01:22 |
rwp | In any case... I suggest fixing the group of those files in your home directory. find ~/ -group adm -exec chgrp -v saptech {} + | 01:22 |
rwp | That finds files with the group adm and executes chgrp verbosely so it will print what files it is changing to your group. Doesn't touch other files not changed. | 01:23 |
rwp | Then I wouldn't do anything more and just take a wait and see attitude. Future files should be your upg group. If other files show up otherwise then investigate further. | 01:24 |
saptech | wow, great command, I think :) | 01:26 |
saptech | here is the output, https://bpaste.net/show/f458a2d708c0 | 01:26 |
saptech | yes, it changed the adm to saptech | 01:27 |
saptech | rwp, thanks a heap | 01:28 |
rwp | Good stuff. Now look for files that are NOT group saptech in case they are something else: find ~/ ! -group saptech -ls | 01:29 |
rwp | Also find ~/ ! -user saptech -ls | 01:29 |
rwp | In case root owned files or whatever snuck in there too. | 01:30 |
rwp | 'find' is an awsomely useful command to know about. | 01:30 |
saptech | looks all files are correct now in Documents, Downloads etc | 01:31 |
saptech | like* | 01:31 |
rwp | Good deal! You are good to go then. | 01:32 |
saptech | now looking in /usr/local, some directories are showing Root Staff | 01:33 |
saptech | I just created a couple of files and they have the correct groups listed | 01:38 |
rwp | /usr/local is normal to be group staff. That's standard. | 01:42 |
rwp | Although in debian buster that is getting removed. After two decades of good service since 1999. Sad. | 01:42 |
saptech | again, it seems my other distros, /usr/local are root root. but I'll check to be certain when I boot into it | 01:43 |
rwp | I am sure the other distros are root:root. And Debian will be again. But for 20 years Debian has been root:staff. Which has been useful. | 01:44 |
saptech | ok, I haven't used Debian itself in a few years | 01:45 |
rwp | Here is a reference: https://bugs.debian.org/538392#62 | 01:45 |
saptech | I guess I never noticed it when I did run debian | 01:45 |
saptech | I'm not doubting you, you know wayyy more then me | 01:46 |
rwp | When that goes away for real then I *strongly* advocate installing local software in /usr/local/stow created and owned either by the user or by group staff. And then using GNU Stow to manage it. | 01:46 |
rwp | Just a couple of weeks ago I found a Makefile misbehaving and trying to install things outside of the PREFIX=/usr/local and into /usr/lib directly! | 01:47 |
rwp | Removing group staff will have the effect that people will do 'sudo make install' instead and that will not catch those mistakes but will jab into the wrong places. | 01:47 |
rwp | Anway... I need to run off. Good luck! | 01:47 |
saptech | thanks again | 01:47 |
bleb | is mapping caps lock to control doable through the gui yet | 01:48 |
vvande | Everybody else probably saw this story from yesterday. I just caught up | 04:46 |
vvande | https://www.theregister.co.uk/2019/01/10/systemd_bugs_qualys/ | 04:46 |
* vvande gloats :) | 04:46 | |
redrick | Yep. I posted that to the Dng mailing list. | 04:46 |
redrick | I also made one ironic comment, here: http://linuxmafia.com/pipermail/sf-lug/2019q1/013712.html | 04:56 |
Xenguy | It seems like it is the inevitable 'big bug' people have been predicting, based on the attack surface | 04:59 |
Xenguy | From my impressions, I predict more of them | 05:00 |
vvande | yeah, more bugs will come | 05:25 |
vvande | However, if I felt that systemd was philosophically a good choice, I'd go with it despite the bugs. | 05:25 |
vvande | But that's not the case. :( | 05:26 |
guy | has anybody here had issues with bootloaders refusing to install no matter what | 06:34 |
gnarface | doesn't ring a bell, guy | 07:54 |
gnarface | maybe see if you can write zeroes to the first 2MB of the disk | 07:55 |
guy | tried gpt and msdos partitions, uefi and non uefi, raid and on raid | 07:55 |
guy | the netinst simply does not install bootloaders, LILO and GRUB do not install | 07:56 |
xrogaan | grub not installed properly? | 08:01 |
xrogaan | I had that with the beta netinstal | 08:02 |
golinux | Are you installing to the device ie. /dev/sdx ? | 08:03 |
golinux | Are you talking about a usb or hard disk? | 08:04 |
guy | installing to a hard disk. i've tried everything under the sun and it just doesnt work | 08:33 |
guy | im about to try the debian stretch installer to see if that works | 08:34 |
golinux | guy: Of course it works or thousands of users would be here ranting. | 08:49 |
stripe | hi everyone, setting up wireless from tty, will I just need to enter the stanza into /etc/network/interfaces ? (sorry memory is going lol) cheers :) | 12:40 |
Bjornn | the was a guy here a while back, fsmithred I think was his name. He was quite active. I wonder if he is well? | 15:46 |
Bjornn | he helped me a few times | 15:46 |
Bjornn | very smart it seemed to me. | 15:47 |
plasma41 | Bjornn: Yes, fsmithred is behind the Devuan live ISOs and the Refracta derivative distro. | 17:07 |
golinux | Bjornn et al . . . fsmithred will be back soon. | 18:12 |
Bjornn | thanks plasma41 1 | 18:14 |
Bjornn | ! | 18:14 |
Bjornn | :) | 18:14 |
Bjornn | oh, and golinux | 18:15 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!