[11:39] has anyone switched from isc-dhcp to kea-dhcp recently? any difficulties? [11:43] chl_: I haven't, so I can't offer any advice; one thing to note is that isc-kea is not in the set of packages that the Ubuntu Security team maintain, so you won't receive security updates for it. [11:44] Should be able to work around that, but thanks for the heads up Odd_Bloke [11:44] more precisely: there's no guarantee that you'll receive timely security patches for it. [11:45] any recommendations for another dhcp server? pref. with some kind of db support [11:46] Yes, thanks tomreyn, that's more accurate. [11:47] thanks [12:10] so, a bit of advice would be welcome here. I have several VM's running ubuntu-server. One of them is an NFS that others have to mount from. I am having a bit of a difficulty with getting permissions right for normal users to write to the NFS from other servers. Should I debug it further or just get LDAP up and running? [12:11] on the nfs server I have set the permissions so that group 33 (www-data) can write to the directories that are shared [12:12] on the nfs-client the user that is supposed to write is a member of the same group on the nfs-client machine (id=33, www-data) [12:13] still if I do a 'touch filename' on the nfs-client machine in the nfs mounted directories I get permission denied [12:13] but if I go up a directory into a local directory on the nfs-client machine that has ownership www-data:www-data and permissions 775 then I can write to that directory [12:21] hmmm, the writing works if I am using NFSv3 [12:23] argh! ... now it works fine [12:23] which is good, but still frustrating when it only needs time for things to work :-) [12:25] ahh, it needed one more thing then just time, the corresponding user on nfs-server had to be added to www-data group for the write to work, thats what fixed it [15:59] ahasenack: bug 1789527 is on the 180 not touched list. Please could you take a look? [15:59] bug 1789527 in resource-agents (Ubuntu) "Galera agent doesn't work when grastate.dat contains safe_to_bootstrap" [High,In progress] https://launchpad.net/bugs/1789527 [16:00] It is server-next but maybe that isn't pertinent any more due to the time delay [16:08] right, server-next can be dropped [16:08] back then I thought it was an escalation, but that wasn't the case [16:08] rbasak: ^ [16:30] ahasenack: thanks, I dropped the tag. Is Importance: High still accurate? Should we restore to Triaged and unassign you? [16:45] rbasak: yes please [16:46] I'd mark it medium [16:46] there is a workaround [16:48] Is there an upgrade path from 17.X --> 18.x ? [16:48] Ussat: 17.04 -> 17.10 -> 18.04 [16:48] OK, thankyas [16:48] or 17.10 -> 18.04 direct [16:49] Ya its at 17.10 now [16:50] Ussat: importantly, 17.04 to 17.10 is a major upgrade. Saying 17.X --> 18.x suggests to me that you have a dangerous misunderstanding of how Ubuntu release versions work. [16:50] ^ this though [16:51] No I understand, I just was not on the box to get the exact release when I typed that [16:51] and I did not remember [16:51] OK [16:51] I have a few hundread and dont remember exactly detail about each one [17:03] hey whats up guys [17:03] how can I force my end users to only have access to install things from ubuntu repo [17:17] probably shouldn't give end-users that kind of access, sounds like a security risk. [17:19] How about not letting users install things [17:20] ok so i have a tall order and im just trying to figure out how to make it work [17:20] as a POC we are looking at giving developers ubuntu workstations (laptops) that are managed with landscape [17:21] AvidWolf43: so setup the systems, and drop the 'users' to non-sudo users? [17:21] right, but they are developers who will need sudo acces for some things [17:21] just not all [17:21] the directive was "use your best judgement" [17:22] I'm just not sure what I want to allow / disallow them sudo for [17:22] What type of scenario are you looking to prevent by disallowing certain sudo access? [17:23] data exfiltration mainly [17:23] What - from elsewhere on the network? [17:23] installing unapproved applications that havent passed legal review [17:23] Are you going to prevent developers from creating VMs and/or containers? [17:23] no, we are trying to be as least restrictive as possible [17:24] Then a developer could just create a VM and install whatever software they like into that. [17:24] So what is achieved by blocking the developer from installing software on the host machine? [17:24] but at least we can log all the things? and hopefully have appropriate flags setup to alert in real time [17:24] You won't get a log of what happened in a VM. [17:25] You'd effectively be pushing developers from doing things in places that you _can_ log (eg. host machine package list via Landscape) to doing things in places that you can't see (inside a VM). [17:26] we can't see what is in the vm, but we can see if there are vm's installed. So we can have a policy that you can have vm's but you have to pipe logs to us for visibility? would that be acceptable? [17:26] I'm just brainstorming [17:30] Are packages for https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigate-new-microarchitectural-data-sampling-mds-vulnerabilities not out the door just yet? [17:31] Not seeing them here. [17:33] mason: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/MDS shows that packages were built already [17:34] paride, cpaelzer, ahasenack: FYI https://github.com/powersj/ubuntu-server-triage/pull/20 [17:34] sdeziel: Ah, maybe they're making their way out. [17:34] mason: looks that way [17:35] ty for the link, though - I'll bookmark it [17:38] I have a question regarding landscape, can I centerally managet encryption keys, something like the way an orginization can centerally manage TPM keys on windows ? [17:38] manage [17:55] AvidWolf43, its a trust thing more than a tech issue [17:56] All the polocies in the world are pointless if you dont trust your devs etc