[17:45] <c0fe> how can I give ownership to a directory to all users in a specific group?
[17:48] <Ussat> chown it
[18:03] <c0fe> Ussat: chown :GroupA /var/www ?
[18:03] <c0fe> like that?
[18:04] <Ussat> man chown
[18:06] <c0fe> i know about that but wasn't helpful
[18:09] <TJ-> c0fe: use ACLs
[18:09] <c0fe> TJ-: this is on a LXD container
[18:13] <c0fe> TJ-: last time i tried it, i was getting a bunch of errors and seems like you can get it to run if you hack it together
[18:13] <teward> c0fe: LXD containers use ACLs and the concept of ACLs inside their containers
[18:14] <c0fe> teward: really? is there a guide?
[18:14] <teward> refer to Any Given "How To" on Linux permissions
[18:25] <c0fe> teward: i have tried it for another use but it just errored out
[18:33] <c0fe> i created multiple users, added them all to one group called "usersharegrp" but I am getting permission denied when accessing a share: https://dpaste.com/H4H95YYRU
[18:33] <c0fe> is there something wrong with my samba config?
[18:37] <c0fe> what am i doing wrong?
[18:44] <c0fe> teward: for acl does that need to be installed apt-get install acl ?
[19:00] <xibalba> i can't decide if i should use the builtin tiumesync service and point it at my Chrony/NTP host, or just setup Chrony on the system, and use my Chrony/NTP server as the upstream for time sync
[19:06] <teward> c0fe: yes you need to install `acl` for extended ACL systems
[19:06] <teward> but not for base chowns
[19:06] <teward> you DO need to make sure your user is in the right group and logout/login again
[19:06] <sdeziel> xibalba: I've found that for systems that are always on (servers), systemd-timesyncd was OK but for laptops that are sometimes suspended, it starts drifting (maybe my RTC is shitty?) enough to break my TOTP authentication. The laptop situation has been fixed by switching to chrony ;)
[19:07] <xibalba> thanks, these will be servers. builtin timesyncd seems perfectly sufficient. i think i'll go with the builtin and point it to my chrony box
[19:09] <c0fe> teward: what do you mean in the right group?
[19:11] <Ussat> for example if you chown root:group1 make sure the user is in group1
[19:13] <teward> ^ this
[19:14] <teward> what Ussat said (sorry i'm in meetings)
[19:14] <xibalba> lol see?! meetings are useless =p
[19:15] <Ussat> xibalba, if you would like to convince my Director of said, feel free :)
[19:19] <c0fe> Ussat: so if i want usera and userb to have access to folder1 I need to make they are both in the same group?
[19:19] <Ussat> yes
[19:20] <c0fe> i was under the impression ACL was better because it avoids this, then what does ACL have over regular chown?
[19:24] <noregret> https://bpa.st/5HADM - any idea why this service is exiting? nothing helpful in the logs
[19:24] <Ussat> ACL's are much more granular, yes
[19:24] <Ussat> and yes, ACL's avoid that, BUT ask yourself how granular do you need to go ? ACL's are generally not as strait forward
[19:25] <Ussat> Wether you use ACL or chown depends on a few things, and not having access to your system I have no idea what is best for you
[19:27] <c0fe> how much more granular can they get Ussat? I thought it was a way to avoid making sure users share a group
[19:27] <Ussat> thats one uyse, yes
[19:27] <Ussat> and this is IMHO not the place for a teatsie on ACL's, but very granular
[19:32] <c0fe> my setup isn't very complicated
[19:32] <c0fe> acl would be nice if i can avoid making sure everyone is in the same group
[19:33] <sarnold> noregret: you'll have to find where that service logs and see if it emitted anything
[19:34] <sarnold> noregret: also check the config file for that service and see if it's been instructed to not listen on any networks/ports/sockets etc
[19:36] <c0fe> teward: can you clarify on acl please?
[19:36] <sdeziel> noregret: /var/log/php7.4-fpm.log maybe?
[19:36] <c0fe> because i am not sure why you said users have to share the same group
[19:36] <Ussat> c0fe, ACL's are more difficult to manage
[19:37] <noregret> sdeziel: yeah, it exists, but empty
[19:37] <teward> c0fe: the users being in the same group has nothing to do with ACLs
[19:38] <teward> it has to do with UNIX permissions
[19:38] <teward> i'm in a meeting i can't elaborate but Ussat can :P
[19:39] <Ussat> Meeting here also, but honestly is there a specific reeason NOT to have then in the same group ?
[19:40] <Ussat> https://www.redhat.com/sysadmin/linux-access-control-lists
[19:40] <Ussat> https://manpages.ubuntu.com/manpages/xenial/man5/acl.5.html
[19:40] <Ussat> https://manpages.ubuntu.com/manpages/trusty/man1/setfacl.1.html
[19:41] <Ussat> https://manpages.ubuntu.com/manpages/trusty/man1/getfacl.1.html
[19:41] <Ussat> There
[19:41] <sdeziel> noregret: you have php 7.4 which would indicate Ubuntu 20.04 but the status output you shared doesn't match what I'd expect
[19:41] <Ussat> ACL's are very powerfull but also complicated
[19:41] <sdeziel> noregret: are you using a PPA or something like that to get PHP?
[19:42] <noregret> sdeziel: yes, a 3rd party repo
[19:42] <noregret> i'm still on 18.04
[19:44] <c0fe> Ussat: i have a few different users and having to coordinate the same group will mean I have to create a bunch of different groups for different use cases
[19:44] <Ussat> Then I suggest you learn ACL
[19:44] <Ussat> start reading
[19:44] <Ussat> its nothing that anyone will be able to explain over IRC
[19:46] <Ussat> you do realise that users can be in multiple groups ?
[19:46] <c0fe> i guess i am bit unsure why teward said that users need to be in the same group when using acl
[19:46] <Ussat> I dont believe he did
[19:47] <teward> i didn't
[19:47] <teward> i said you need users in the same group when NOT using acl
[19:48] <teward> and just using straight UNIX permissions
[19:49] <sdeziel> noregret: you'll need to check how php-fpm is configured then as it differs from what I'm used to work with :/
[19:50] <noregret> sdeziel: well, all was working fine until I updated earlier and php8.0 got installed from that repo. All versions are in /etc/php/phpxx/
[19:50] <c0fe> ah ok, my bad, sorry teward...i need more coffee
[19:53] <noregret> /etc/php/xx/ *
[19:54] <noregret> and /etc/php/7.4/fpm/pool.d/www.conf looks fine to me
[19:59] <teward> using ACL i can have a separate set of groups 'admins' 'users' 'idiots' etc. and give THOSE groups special acl rights independent of groups that are on the chown
[19:59] <sdeziel> noregret: it's a long shot but those fpm typically want to listen to unix sockets or TCP sockets. Maybe another fpm instance started before has bounded the same socket that php7.4-fpm wanted to listen to?
[19:59] <teward> but if you're working from the fact of pure UNIX permissions then group owner needs to be in the groups that the user is in for straight chown to work
[19:59] <teward> c0fe:  ^
[19:59] <teward> if you go the ACL routes it gets more complex
[20:00] <c0fe> teward: i have setup a group with nginx included in it but getting permission denied
[20:01] <teward> you'd have to share specifics
[20:04] <c0fe> teward: I got 3 users, Bobsmb, Jillsmb and nginx that all need to have read, write, execute access to /var/www/data. I have all three users created and all are part of smbsharegrp and i have the following samba config: https://dpaste.com/36WUC7LDP
[20:09] <noregret> sdeziel: nope, nothing is running
[20:09] <noregret> i'll try to remove php8 and try again
[20:10] <c0fe> teward: i am checking the logs but see nothing in there
[20:11] <teward> you are talking about what APPEARS to be separate issues,
[20:11] <teward> nginx runs only as `www-data` in a default config unless you altered it
[20:11] <teward> your *users* should never be in `www-data`
[20:12] <teward> at which point you'd have to do ACLs if you have *multiple* users who need to edit www-data group accessible files
[20:12] <teward> you *don't* want to alter that unless you *really* know what you're doing
[20:12] <teward> and 99% of people don't ;)
[20:12] <teward> with regards to your nginx web data what do I care about smbsharegrp in this case?
[20:13] <teward> because it has nothing to do with *nginx* unless you've altered your /var/www/data perms to be a nonstandard group like smbsharegrp and not www-data
[20:14] <c0fe> teward: nginx that is installed from their own repo uses "nginx" as the user and group
[20:14] <teward> ERR:ThirdPartyRepository ERR:NotSupportedByUbuntu ERR:WeirdConfigurationsFromUpstream
[20:14] <c0fe> so what is going on is that I am using nextcloud but since webdav is broken i am going to substitute in smb
[20:14] <teward> i'm in the middle of somehting I can't dedicate any cycles right now here...
[20:14] <c0fe> i can remove nginx from that group
[20:15] <c0fe> i just still need to make sure it can write into it
[20:16] <teward> Ussat: are you able to help ^ diagnose their permissions issues?
[20:16] <teward> They've got a complex setup here that at this point I think will need ACLs to really work with non-Samba directories at this point
[20:16] <teward> ERR: Busy With ${PAYING_JOB}
[20:25] <Ussat> I am not at the moment, I have meetings rest of the day with vendors, sorry
[23:19] <xibalba> i'm having a dumb problem i'm just not seeing, trying to load `named` and get open: /etc/bind/named.conf: permission denied but my permissions are root:bind and 660
[23:20] <sarnold> namei -l /etc/bind/named.conf may help you spot something
[23:20] <sarnold> also check dmesg or auditd logs, perhaps your process has an apparmor profile that is preventing the access
[23:20] <xibalba> ty will check both
[23:21] <xibalba> darn apparmor="DENIED" operation="mknod" profile="/usr/sbin/named
[23:22] <xibalba> good idea, thanks. i had another box i've been deploying against with my ansible playbook, tried myplaybook on a fresh box and got this error. guess i need to account for apparmor in my playbook now
[23:22] <sarnold> what is named trying to create?
[23:23] <xibalba> looks like /etc/bind/named.run , maybe i just fix up the permissions there.
[23:23] <xibalba> apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/named.run" pid=207990 comm="named" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
[23:27] <pcfreak30> Hello, I am having an issue suddenly where the network service hangs on 18.04.  When i go to recovery, i see the recovery-menu try to run networking.service but its not there, and I can see systemd-networkd + netplan seem to be used. I can use the network on a live cd. What should I be looking at?
[23:29] <sarnold> xibalba: named.run ? that's a funny file... it feels a bit like maybe something that ought to live in /run or /var instead?
[23:29] <xibalba> yeh and apparmor's profile for named shows the same
[23:30] <xibalba> i'm going to just nuke that box and rerun my playbook on a fresh one
[23:30] <sarnold> are you building named from source?
[23:30] <sarnold> maybe you just need a new ./configure --thingy to tell it where to store the file
[23:32] <xibalba> na, i'm not that crazy. though maybe i ought to be, i'm getting bind9 from apt
[23:32] <xibalba> i stopped building from source when i stopped using *bsd =p
[23:38] <sarnold> hrm; does your bind config specify where to put that file?
[23:39] <xibalba> no it should be all defaults. i bet i did something goofy to that box before, thats why i'm blasting it away. uploading my 20.04 gold images to the esxi box now then going to rerun that playbook
[23:39] <xibalba> i ran that playbook against 2 other ubuntu 20.04 hosts thus far and it worked fine
[23:40] <xibalba> hey do you know if there is there a way for me to alias an IP to a host, but make sure that IP is not used for any outbound connection instantiated by the host?
[23:40] <xibalba> i.e,. i have a host w/an any casted IP, I dont want it to use it's any cast IP to fetch updates via apt update
[23:41] <xibalba> i might have to move the anycast ip to loopback
[23:43] <sarnold> hmm, I don't know anything off the top of my head, no
[23:44] <xibalba> score, figured it out
[23:45] <xibalba> ip route change default via $YOUR_CURRENT_DEFAULT_GW src $THE_IP_YOU_WANT_TO_SRC_FROM
[23:47] <sarnold> nice
[23:59] <xibalba> alright! fresh box, ran my playbook and BIND + ExaBGP are online announcing a /32, neato burrito