[01:42] <lotuspsychje> good morning
[10:41] <Maik> lotuspsychje: Ubuntu should do it like Fedora, keep at least three kernels and when a new one is added it removes the oldest one automatically
[10:43] <ravage> it usually keeps the latest 2. but when you switch to a newer kernel like it happened with 20.04 (HWE -> 5.15) it keeps those too
[10:43] <lotuspsychje> i installed focal at a customer recently wich pulled HWE 5.15 on updates
[10:43] <ravage> and the other kernels he had were from previous ubuntu releases. sometimes you just have to clean up a bit
[10:43] <lotuspsychje> but didnt check the remaining ones
[17:14] <leftyfb> ogra: I've got octoprint all tricked out to do lots of things for me. I get periodic notifications on my phone of the print status with a picture, I have it set to power off the printer when the print is finished, also turns off the custom LCD screen on the pi that I use to control octoprint. I can gracefully cancel prints or just select objects or areas of the print bed to stop printing if only that part is failing, while it continues to 
[17:14] <leftyfb> print everything else. I also use the Obico(previous the spaghetti detective) service to monitor prints and will warn me or pause the print if it detects any major failures. I can also print all my past sliced prints saved on the pi. I can start prints remotely if I like. Also, if for whatever reason the bed or hot end are left on for a period of time without activity, it'll shut itself down
[17:15] <leftyfb> ogra: I'm curious if your prints failed due to clog or something. ALSO, a while back before I upgraded to a pi4 4gb, a couple times the pi did run out of memory for whatever reason and did kill the print. I guess this would be a downside to octoprint. But since upgrading over a year ago and printing scores of objects since, I
[17:15] <leftyfb> I've had zero issues
[17:16] <ogra> yeah, it is helpful if you do really remote things ... but i rarely do nowadays ... printer sits next to me in the office and i have the cam stream visible in my living room in case i'm not near it ... i rarely print while not at home 
[17:17] <leftyfb> my printer is almost always running :)
[17:17] <ogra> i dont even have the usb attaced anymore ... SD and hitting th print button on the printer is good enough
[17:17] <ogra> i only use USB for E-Step calibration and such ... but thats something you only do once every now and then anyway
[17:18] <leftyfb> I don't trust sd cards at all
[17:18] <leftyfb> also haste sneakernetting
[17:18] <leftyfb> hate*
[17:19] <ogra> the "plastic vomit incidents" were all with my former delta printer and due to some mechanical issues it had ...
[17:19] <leftyfb> right, so what does that have to do with octoprint?
[17:19] <ogra> but if you forget to watch it for a few hours the "hairball" it produces can gt quite big ... and a mess to clean up 🙂
[17:20] <leftyfb> see, that's where obico comes in
[17:20] <ogra> has indeed nothing to do with octoprint ... i just dont use it anymore, my printer rarely prints unattended
[17:20] <leftyfb> I have always watched the first layer. Other than that, I walk away or don't pay attention (the printer is about a foot away from me while I work)
[17:22] <ogra> similar here ... 
[17:23] <leftyfb> https://photos.app.goo.gl/4tmRzVpDvcK4w6xt8
[17:24] <ogra> neat 
[17:24] <leftyfb> the interface on the LCD on the right has changed since I took the picture
[17:24] <ogra> putting the reels at the top is pretty brave ... 
[17:25] <leftyfb> why? That's it's design
[17:25] <ogra> i have had that before but saw awful pics when something went wrong ... its like an accelerant if your bed verheats and sets stuff on fire or some such
[17:26] <ogra> i.e. the worst place you could put it when there is fire ... 
[17:27] <leftyfb> again, if the hot end and bed stay on too long without movement, it'll shut them off and the printer shuts off
[17:27] <leftyfb> it's also directly below a smoke detector :)
[17:28] <ogra> heh ... clever
[17:28] <leftyfb> octoprint sends a signal to a smart plug which kills power to the printer completely 
[20:46] <webchat117> Hello!  My boss has assigned me to find out if it's the year of the Linux Desktop yet.  Anyone here successfully managing Ubuntu laptops in an enterprise environment?
[20:47] <sarnold> oh man, you must have aced the "replace the blinker fluid in all the fleet cars" to get assigned this job
[20:49] <oerheks> webchat117, keep polling, and mail your boss the results in 2030
[20:50] <leftyfb> webchat117: there are plenty of businesses that utilize linux workstations
[20:50] <leftyfb> webchat117: polling isn't going to help you at all. Start with your needs and test to see if ubuntu on the desktop works for you.
[20:51] <sarnold> oh snap, real advice :)
[20:54] <tomreyn> according to your bosses' website, the company is already using linux desktops. i guess the assignment won't add much value then.
[20:57] <leftyfb> stock photos?
[21:00] <tomreyn> entirely possible
[21:00] <leftyfb> not sure if we're looking at the same side, but I'm pretty sure they are using mac's in these picutres. I know one of them definitely is. And I see a macbook in one picture
[21:00] <leftyfb> can't seem to grab the damn pic though. Stupid hidden html
[21:01] <sarnold> network inspector?
[21:01] <leftyfb> good call
[21:01] <tomreyn> https://www.hudsonrivertrading.com/wp-content/uploads/2020/02/Home-Hero-0201.jpg and https://www.hudsonrivertrading.com/wp-content/uploads/2019/11/Home-Hero-03-Updated.jpg
[21:01] <tomreyn> right-click "open image in new tab" on firefox. not on chrom*
[21:02] <leftyfb> yeah, the 2nd one is the one I was looking at
[21:03] <leftyfb> no indication it's linux. Not the workstation anyway
[21:03] <leftyfb> and the macbook is on the left
[21:03] <leftyfb> 2 of them 
[21:05] <webchat117> Being a bit tongue in cheek.  Yeah, we're mostly a Mac shop.  I'm investigating putting together a plan to roll out some Linux endpoints and wanted to know if anyone had advice.
[21:05] <leftyfb> webchat117: try it
[21:07] <webchat117> I am currently in the midst of trying it, but the seeming lack of an MDM is troubling to my Mac-brain.  I didn't know if there were any management idioms in the Linux world.  If this is the wrong place and I just need to RTFM, feel free to say so.
[21:08] <leftyfb> I don't know of any MDM for linux
[21:08] <tomreyn> i guess it depends much on how much central management / auditing you need. if you want to restrict users to non root access they will hardly be happy, and if you don't then maybe you won't be able to convince all auditors that "you are working securely"
[21:08] <arraybolt3[m]> webchat117: Linux is successfully deployed in enterprise environments all over the place - in fact, Google uses their own version of Debian exclusively.
[21:08] <arraybolt3[m]> webchat117: Ubuntu is designed for enterprise use.
[21:10] <arraybolt3[m]> webchat117: As far as MDM, give users non-root access, set a BIOS password, and keep Secure Boot on. Maybe also set up your own account so you can SSH into the system whenever if they're connected to the primary VPN.
[21:10] <tomreyn> to get you started, there is https://ubuntu.com/landscape/features and there is sssd
[21:11] <arraybolt3[m]> webchat117: You could even set it up so that the system always tried to connect to the VPN and maybe even block Internet access if the VPN wasn't connected so that users had to be connected to the corporate network in order for the system to really work.
[21:11] <leftyfb> arraybolt3[m]: that's not MDM
[21:11] <webchat117> We need to have EDR and DLP software in place, and we need some assurance they don't get out of place.  We're talking about developers, so non-root is out of the question.
[21:11] <arraybolt3[m]> leftyfb: True, but I've dealt with MDM devices and this is about as close as you can get with a desktop AFAIK.
[21:11] <leftyfb> webchat117: with root, all bets are off
[21:11] <webchat117> That
[21:11] <leftyfb> unless you add in something like grsec
[21:12] <webchat117> 's my concern.
[21:12] <arraybolt3[m]> webchat117: Why not keep them non-root on the physical hardware and give them a VM that they can run as root?
[21:12] <tomreyn> that'd be my take, too
[21:12] <webchat117> At that point I'd just give them a Mac, a Linux server, and SSH/X11 forwarding.
[21:12] <arraybolt3[m]> GNOME Boxes + a Lubuntu ISO = developer gets root access without being allowed to wreak havoc on the physical machine.
[21:13] <arraybolt3[m]> (Oh, also, you'd want to set a password on the GRUB bootloader so that someone couldn't drop into the bootloader and boot whatever they wanted to.)
[21:13] <webchat117> Re Landscape, that's the reason I'm in ubuntu-discuss and not some other-discuss
[21:14] <tomreyn> you should probably have this discussion with sales@canonical, too
[21:15] <tomreyn> but i guess the DLP + EDR parts will be difficult if you also want to keep the platform open
[21:15] <tomreyn> or even in general, because there won't be much 'accredited' software which provides linux desktop support
[21:15] <webchat117> Oh yeah, I've reached out to sales.
[21:15] <tomreyn> maybe start with this first, if it's a fixed requirement
[21:16] <arraybolt3[m]> https://help.ubuntu.com/community/MyDLP
[21:16] <webchat117> I'm not that much of a jackass, I did some amount of due diligence before bothering y'all
[21:17] <tomreyn> interesting, i wasn't aware of 'MyDLP'
[21:17] <arraybolt3[m]> And there's also various Linux EDR solutions I can see, though they don't look like they're provided by Canonical.
[21:18] <webchat117> Yeah, we've got EDR and DLP in place on other platforms and I'm hoping to use those.  They're both currently running somewhat happily on my test machine, so that box is checked.
[21:18] <arraybolt3[m]> (Then again MyDLP doesn't appear to be Canonical's doing either.)
[21:19] <tomreyn> webchat117: oh, that's quite the achievement already, i would have thought this will be the hardest part.
[21:19] <arraybolt3[m]> Really, if you want to give users root access without giving them root access, virtualization is probably going to be the way to go IMO. Containerization might also work (I'm not sure on this one, other's probably know way more about that than I do), but I know for a fact you can give a user full root access in a VM and only standard access on the host system.
[21:20] <tomreyn> webchat117: well, the other hard part will be convincing the dev's they can't have root on the main system
[21:21] <webchat117> Honestly, if they have root in the VM and that VM has network access, it's no solution.
[21:21] <webchat117> The issue is less about the endpoint and more about what it can touch.
[21:21] <tomreyn> you'd need a software request management system like all the enterprises have it. tick a box on this web app to request this software to be installe don your computer. if licensing fees are involved, granting that wish will depend on your role or line managers' decision.
[21:22] <arraybolt3[m]> If that's the case, I'm missing something - that sounds like a security issue to be tackled on those other systems.
[21:23] <tomreyn> you could limit network access for the guest on the host
[21:23] <tomreyn> or just via cgroups
[21:24] <tomreyn> but normally you want to do such using network firewalls / proxy servers, i guess.
[21:24] <oerheks> i still have 3 packages held back; The following packages have been kept back:  python3-distupgrade ubuntu-release-upgrader-core ubuntu-release-upgrader-gtk 
[21:24] <webchat117> The problem with root is being able to remove EDR/DLP software and then do bad things to IP/infrastructure.  Defense in depth is the name of the game, but having what is essentially a rogue endpoint is never a great thing.
[21:24] <oerheks> err wrong channel
[21:25] <arraybolt3[m]> webchat117: And that EDR/DLP software would have to run on the guest?
[21:25] <arraybolt3[m]> webchat117: My thinking was, run the EDR/DLP on the host and then give the devs a clean, do whatever you want VM to develop in.
[21:25] <webchat117> I guess the solution would be zero trust network access where non-compliant devices cannot talk, but that's currently bordering on a fictional technology
[21:26] <webchat117> The VM would be functionally identical to the rogue physical machine as far as being able to ruin my day
[21:26] <arraybolt3[m]> webchat117: Require the presence of the EDR/DLP software in order to allow connecting to the corporate VPN?
[21:27] <arraybolt3[m]> I dunno if that's a thing, but that seems like it would be easy enough to do from a programming standpoint.
[21:27] <webchat117> That'd be the ZTNA piece.  We'd also need to figure out an on-prem solution.
[21:28] <webchat117> The problem itself is simple, but I'm not aware of a solution that really solves the problem yet.  I assume it's an implementation nightmare, otherwise someone would have done it by now.  MS is making strides with Azure/Defender
[21:28] <arraybolt3[m]> (Just fyi, I'm not an expert at any of this - this is just me throwing around what I know of Linux to try to help solve the problem.)
[21:29] <webchat117> No worries, I appreciate hearing ideas
[21:29] <arraybolt3[m]> webchat117: So, here's something to think about - an employee could potentially bring in a copy of QEMU that was statically linked, and run their own VM with root privileges within the VM and network access, without having to have root on the host. Would that also mess up your system? Because if so, that sounds like a poorly designed system to me.
[21:31] <webchat117> I mean, "mess up" isn't the right way to think about this.  It adds risk.  A rogue endpoint shouldn't actually cause a catastrophic failure, but if you stack enough risks, systems will start failing.
[21:31] <webchat117> See "it never gets cold in Florida" leading to the Challenger
[21:31] <arraybolt3[m]> I see what you're saying.
[21:32]  * arraybolt3[m] goes afk
[21:32] <webchat117> Thanks for the chat all, this was helpful
[21:38] <arraybolt3[m]> webchat117: I have another thought.
[21:38] <tomreyn> they wont listen
[21:38] <arraybolt3[m]> webchat117: What is it that a user can do with root in a VM that they couldn't do without root in that same VM? (No need to answer, just think about it.)
[21:38] <leftyfb> they left
[21:38] <arraybolt3[m]> leftyfb: Oh, my chat isn't showing me that.
[21:39]  * arraybolt3[m] grumbles at Matrix
[21:39] <tomreyn> one of the fewer interesting discussions we've had here, though :)
[21:39] <leftyfb> if the VM needs to be bridged on the network, it's just another node that is now unencumbered 
[21:39] <leftyfb> no different than the host
[21:39] <arraybolt3[m]> Right. Maybe that was the confusion part - I was thinking of a VM with usermode networking.
[21:40] <arraybolt3[m]> Where QEMU's network access appears to be the same as any other application. No network bridging.
[21:40] <arraybolt3[m]> s/confusion/confusing