[00:12] <rfm> blahdeblah, easier to download a cloud-image and not bother running the installer at all
[00:16] <rfm> blahdeblah, lxd or multipass are both very quick ways of spinning up a ubuntu vm from an image library, if you can live with their quirks (mainly, they install by snap)  Last time i tried multipass it didn't allow bridged network, but that may have changed by now, I know it was in progress
[00:28] <blahdeblah> I haven't looked at multipass for a long time, but I'm struggling to understand how lxd would help anything here.  If I were going to download an image anyway, I would just download the ISO and boot from that in virt-manager (if I can find one that works - for some reason the last few I downloaded didn't, even though the checksum was fine).
[00:34] <rbasak> blahdeblah: running the installer in a VM is a backwards way of doing things unless you're testing the installer itself. Why download a thing that'll eventually generate the VM image you want when you can just download the VM image that we ship? It's sort of the equivalent of compiling from source instead of downloading a binary distribution.
[00:36] <rbasak> The only catch is that you need to tell the VM how to specialise itself for your purposes. Just like you have to tell the installer what you want.
[00:36] <rbasak> That's done with cloud-init, and tools like multipass and lxd know how to operate that out-of-the-box.
[01:28] <blahdeblah> rbasak: As in, multipass or lxd can provide the infrastructure and run the server side of cloud-init for me?
[01:30] <blahdeblah> I'd be very happy to do the specialisation with cloud-init.  I'm just not sure about how to plug the pieces together on a standalone VM host, and wondering about the overhead in time/setup for a low-churn host which might get a VM installed once a month or whatever.
[01:35] <rbasak> blahdeblah: absolutely - doing that is the point. For examle: "lxc launch --vm ubuntu:jammy yourvm" then "lxc shell yourvm". Drop the --vm for a (full system) container instead.
[01:37] <utkarsh2102> rbasak: isn't it very late for you there? :)
[01:37] <rbasak> It is :)
[01:37] <voltagex> rbasak: what if I *do* want to do the equivalent of building from source
[01:37] <rbasak> blahdeblah: for specialisation see https://cloudinit.readthedocs.io/en/latest/topics/examples.html for some examples
[01:38] <rbasak> voltagex: then you can, sure. It's not the usual use case though.
[01:38] <voltagex> I'm trying to track down how the ubuntu-server-live ISO is generated - it'd probably also be useful to know how the cloud images are generated.
[01:38] <rbasak> blahdeblah: "lxc profile create myprofile", "lxc profile edit myprofile", "lxc launch -p myprofile ..."
[01:39] <rbasak> blahdeblah: in the profile you put the #cloud-config thing under config.user.user-data
[01:43] <blahdeblah> rbasak: Perhaps I'm not explaining my problem clearly enough; those examples are for cloud-init config on the guest VM. 
[01:44] <blahdeblah> What I am asking is what the process is for setting up the server components.  Obviously it needs a web server that can serve ISOs or something, along with the cloud-init configs.
[01:45] <rbasak> There aren't any server components. There can be, if you want. But cloud-init will take it's configuration from a variety of sources, and one of those is to just look for a connected disk for example.
[01:46] <rbasak> For example, you can create a "nocloud" disk with the cloud-localds tool
[01:46] <rbasak> Then attach that disk as an additional disk to your VM
[01:47] <blahdeblah> Interesting; might be a good option
[01:47] <rbasak> When the VM boots a pristine Ubuntu cloud image (as a disk), it'll also find the additional disk with the cloud-init configuration on it, and use that.
[01:47] <rbasak> I'm not sure if lxd uses that mechanism or a different one. But it doesn't matter - lxd sets up the magic for you.
[01:47] <rbasak> (and the same with multipass)
[01:48] <rbasak> So all you do is give lxd the cloud-init configuration you want, and it does the rest.
[01:49] <blahdeblah> Cloud image as in https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-disk-kvm.img ?
[01:49] <rbasak> I think that's right yes
[01:49] <blahdeblah> Thanks rbasak; I'll go do some reading about the lxd magic.
[01:49] <rbasak> Try https://cloudinit.readthedocs.io/en/latest/topics/datasources.html and https://cloudinit.readthedocs.io/en/latest/topics/datasources/lxd.html
[01:49] <rbasak> Looks like cloud-init has specific support for lxd
[05:08] <cpaelzer> good morning
[05:29] <blahdeblah> Afternoon, cpaelzer \o
[05:43] <cpaelzer> hi blahdeblah
[05:45] <cpaelzer> blahdeblah: did you get happy with your experiments for cloud-images + cloud-init to customize your guests?
[05:54] <blahdeblah> Didn't get to it yet; other pressing work stuff happening. :-)
[12:11] <ahasenack> morning
[12:39] <MJCD> holla
[12:40] <MJCD> I am having an issue with snapd while trying to do a new certbot install
[12:40] <MJCD> i've previously used it via <other> methods
[12:42] <MJCD> when I do `sudo certbot --apache` after it installs and lists as enabled in snapd
[12:43] <MJCD> it says `permanently dropping privs did not work: File exists`
[12:43] <MJCD> I can't find any real info about it
[12:44] <MJCD> actually running certbot at all generates that so maybe not related to snapd
[12:44] <MJCD> humm
[13:01] <MJCD> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1760416
[13:01] <MJCD> closest thing i've found
[13:02] <MJCD> but I doubt it's a certbot bug even -- I would have been using the same exact version previously just without snapd
[13:02] <MJCD> however conflicting a bit moreeee
[13:02] <MJCD> I also can't run it in standalone mode
[13:02] <MJCD> same error
[13:17] <rbasak> MJCD: are you running as an ordinary user?
[13:17] <MJCD> `sudo certbot`
[13:18] <MJCD> but i'm logged in as regular user, yeah
[13:18] <MJCD> I did try as root
[13:18] <MJCD> same thing
[13:18] <MJCD> like tried as root directly I mean
[13:18] <rbasak> Have you tried running it as an ordrinary user?
[13:18] <MJCD> yeah same thing and infact even running it standalone mode which should always work, gives the same exact error
[13:18] <MJCD> which leads me to think it's something about snapd
[13:19] <rbasak> Like just "certbot --help"or something without sudo.
[13:19] <MJCD> i'm not using it for literally anything else
[13:19] <MJCD> ill try --help one sec
[13:19] <MJCD> hummm I reinstalled the snap and it's a bit different now
[13:20] <MJCD> so as regular user --help gives me proper output which is good
[13:20] <MJCD> running `certbot --apache` gives a permission error, which is good
[13:20] <MJCD> but then adding `sudo` doesn't help that lol
[13:20] <MJCD> hmm
[13:20] <MJCD> progress somehow though -- not sure what I did xD
[13:21] <rbasak> In the bug you referenced there was a problem with the configuration in /etc/passwd/group
[13:21] <MJCD> uhmmm
[13:21] <MJCD> ok so
[13:21] <MJCD> it was because apache was still running
[13:21] <MJCD> but
[13:21] <rbasak> What does "getent passwd $USER" say?
[13:21] <MJCD> if I `sudo service apache2 stop`
[13:21] <MJCD> then it goes back to permanent dropping privs did not work` again
[13:21] <MJCD> one sec
[13:22] <MJCD> mjcd:x:1000:1000:MJCD:/home/mjcd:/bin/bash
[13:22] <MJCD> x? lol
[13:23] <MJCD> it //was// 1000:1
[13:23] <MJCD> but as per that link before I updated that to my own group
[13:23] <MJCD> which is showing fine after a reboot in `id`
[13:23] <MJCD> uid=1000(mjcd) gid=1000(mjcd) groups=1000(mjcd),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),116(lxd)
[13:24] <rbasak> it //was// 1000:1> how did that happen? Given the bug you linked, it seems likely that you have something misconfigured related to that causing your problem.
[13:24] <MJCD> i'm really confused now though because the guides on both sides (letsencrypt/certbot and my provider) say to stop apache
[13:24] <rbasak> Does "sudo true" work?
[13:24] <MJCD> and idk it was always 1 (root) because it's the only/original user
[13:24] <rbasak> Seems to me that your problem is more fundamental than anything to do with snap or certbot.
[13:25] <MJCD> sudo works completely
[13:25] <MJCD> did the full lamp stack setup as this user
[13:25] <rbasak> Ubuntu does not by default create a user with gid 1.
[13:25] <rbasak> How did it end up like that?
[13:25] <MJCD> how would I know; but it's fixed now as per the output above
[13:25] <MJCD> I don't think I did it/can't see how I would have
[13:25] <rbasak> Whatever caused that might have misconfigured something else related too.
[13:25] <MJCD> it may be from an upgrade install
[13:26] <rbasak> I think it's unlikely to have been caused by an upgrade.
[13:26] <MJCD> what else could have been "broken" by such a change?
[13:26] <MJCD> it seems totally innocuous either way
[13:26] <MJCD> since it's meant to be run as sudo
[13:27] <MJCD> it doesn't have to be but the certonly option gives me the same error
[13:27] <MJCD> which baffles me further
[13:27] <MJCD> also as above note this error occurs when apache2 is stopped
[13:28] <MJCD> when it's running (disobeying the guides) I get a sensical, coloured highlighted error about permission denied
[13:28] <MJCD> which seems fine
[13:28] <samy1028> MJCD: is there anything in any of of your other /var/log/*?  like in auth.log or other things that might be reporting at the same time?
[13:28] <MJCD> let me take a look
[13:30] <rbasak> MJCD: do you now have a bunch of files on the system that are owned by the wrong group ID for example?
[13:30] <MJCD> rbasak: how would I easily check that
[13:30] <MJCD> again tho i'm working entirely as root
[13:30] <MJCD> and other services run as www-data
[13:30] <MJCD> so my user should be pretty irrelevant
[13:31] <MJCD> I can sudo su and do it from there
[13:31] <MJCD> same result
[13:31] <MJCD> just fwiw I am noting in my dmesg some ufw blocks
[13:32] <rbasak> MJCD: I don't think you can easily check the entire set of consequences that might have arisen from your previous misconfiguration.
[13:32] <MJCD> lol kind of a strawman argument thoe....
[13:32] <MJCD> doubly so as given the conditions above
[13:32] <MJCD> I can make an entirely new user if it makes you feel at ease
[13:33] <MJCD> it will still all be done/run as root
[13:33] <MJCD> (via sudo)
[13:33] <MJCD> and I did amend my own gid :))
[13:33] <rbasak> I would redo whatever you're trying to achieve from the beginning using a fresh VM or container - see devops principles.
[13:33] <MJCD> lol, i've done nothing but install lamp
[13:33] <MJCD> from apt
[13:34] <MJCD> totally default install
[13:34] <rbasak> Then you did you end up with a user with a gid of 1?
[13:34] <rbasak> Anyway, it should be easy to redo then?
[13:34] <MJCD> Not really it's not an instance I manage
[13:34] <MJCD> and it's kind of an involved env
[13:35] <rbasak> It's now a broken env.
[13:35] <MJCD> ie it's a few hours work, after waiting <unknown> period
[13:35] <MJCD> lol...
[13:35] <MJCD> you're stuck in a loop now
[13:35] <MJCD> again.
[13:35] <MJCD> it's ALL done as root.
[13:35] <MJCD> My current user is intangible to the issue
[13:35] <samy1028> MJCD : are you able to duplicate the environment in a new VM?
[13:35] <MJCD> samy1028: nah previously I just wasn't using snapd
[13:35] <MJCD> and now that's <the way>
[13:35] <MJCD> so am trying to implement it
[13:35] <samy1028> fyi - root can still get "broken".
[13:35] <MJCD> ofcourse it can
[13:36] <MJCD> but it's not going to give me an error that it can't de-escalate perms because "file exists"
[13:36] <rbasak> It's normal for various tools and services to "drop privs".
[13:36] <MJCD> again I can make a whole new local user if that helps put minds at ease
[13:36] <MJCD> rbasak: ofcourse
[13:36] <MJCD> thus how everything runs as www-data
[13:36] <rbasak> So your not-root needs to not be broken too.
[13:37] <MJCD> Okay new user it is
[13:39] <MJCD> okay new user
[13:39] <MJCD> `snap list` 
[13:40] <MJCD> core, lxd, snapd
[13:40] <MJCD> `sudo snap install certbot --classic`
[13:41] <MJCD> ... installed
[13:41] <MJCD> `certbot --help` => shows help info
[13:42] <MJCD> `sudo certbot --help` => "permanently dropping privs did not work: File exists"
[13:42] <MJCD> just to add as well incase it's relevant -- from dmesg
[13:42] <MJCD> `[ 1728.563701] [UFW BLOCK] IN=ens160 OUT= MAC=00:50:56:02:ea:72:00:a2:ee:75:a6:c1:08:00 SRC=80.82.64.114 DST=139.99.191.6 LEN=40 TOS=0x00 PREC=0x00 TTL=239 ID=36790 PROTO=TCP SPT=59360 DPT=2559 WINDOW=1024 RES=0x00 SYN URGP=0`
[13:44] <MJCD> and the line before that...
[13:44] <MJCD> `[ 1681.890238] audit: type=1400 audit(1653313260.929:46): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.certbot" pid=3529 comm="apparmor_parser"`
[13:47] <MJCD> I worry that it's something stupid like maybe the apache2 pid file not getting cleaned up or something
[13:47] <MJCD> because what file is it even talking about lol
[13:48] <MJCD> disabling the firewall entirely still gives the same behavior so I assume those messages are reasonably unrelated especially since it's asking for access and then saying those perms are same as current
[13:49] <MJCD> snapd is meant to make my life good forever instead it's giving me heck
[13:49] <MJCD> fwiw as well I followed all the steps to make sure there was nothing of certbot already installed as per the guide
[13:50] <MJCD> though there shouldn't have been and it didn't find/do anything
[13:53] <MJCD> I mean at a bare minimum
[13:53] <MJCD> `sudo snap run certbot certonly --standalone`
[13:53] <MJCD> that should not give any error about some file already existing
[13:55] <MJCD> okay so I made it make a log file
[13:56] <MJCD> and it's trying and failing to get /etc/letsencrypt/stuff
[13:56] <MJCD> which doesn't exist contrary to the error
[13:56] <MJCD> lol
[13:59] <MJCD> I think I might give it a go using pip >.>
[14:00] <MJCD> the linode guide is actually funnily more detailed than the official certbot docs
[14:04] <patdk-lap> Ive never been a fan of certbot, and use dehydrated instead
[14:06] <MJCD> ehh yeah I know there's options just getting the vanilla standards down pat/up to date for now
[14:06] <MJCD> so uhm
[14:07] <MJCD> the official guide lied to me and I should have checked for ubuntu specific docs
[14:07] <MJCD> because while it's probably ideal to have it under snap
[14:07] <MJCD> it appears they still just want me to do `apt install certbot` ahaha
[14:08] <MJCD> now i'm getting the much more benign `The requested apache plugin does not appear to be installed`
[14:09] <MJCD> and there we go! added sudo apt-get install python3-certbot-apache 
[14:09] <MJCD> and it's all working
[14:10] <MJCD> funny how in their attempts to make it easier (ubuntu's I mean) they actually made the official docs from the software authors not work properly
[14:12] <MJCD> as a sidenote I literally worry about what will happen when people on the same level as linus are all dead and gone
[14:13] <MJCD> because it's just going to get infinitely more fragmented; and who is to be entrusted with such a role who doesn't have a commercial interest
[14:13] <MJCD> ie Microsoft could do it with a $bigCost but nobody wants <unix> under their stewardship
[14:14] <patdk-lap> microsoft already does it
[14:14] <MJCD> not really the same tho they're contributors
[14:14] <patdk-lap> redhat has been doing it forever
[14:14] <MJCD> and redhat etc etc all still rely on the kernel
[14:14] <MJCD> bsd ofc has their own
[14:14] <patdk-lap> heh?
[14:15] <patdk-lap> maybe your confusing upstream pushes with inhouse versions
[14:15] <MJCD> the opposite
[14:15] <patdk-lap> sure they all contribute, but they also have their own
[14:15] <MJCD> the base
[14:15] <MJCD> from which all streams flow
[14:15] <patdk-lap> no
[14:15] <MJCD> ye
[14:15] <patdk-lap> that isn't how git works
[14:15] <patdk-lap> that is how cvs/svn works
[14:15] <MJCD> git is a source control tool not a kernel ;p
[14:16] <MJCD> and ofcourse it is.
[14:16] <patdk-lap> yes, but it doesn't all flow down
[14:16] <MJCD> not all, no.
[14:16] <MJCD> and then deeply customized
[14:16] <MJCD> but that's my point
[14:16] <patdk-lap> it's also why redhat NEVER updated their kernel
[14:17] <MJCD> after linus and similar people who literally give their life to provide that bases ongoing dev
[14:17] <MJCD> it's everyone for themselves
[14:17] <patdk-lap> ubuntu has the hwe thing to update but generally doesn't
[14:17] <MJCD> which will lead to hyper fragmentation
[14:17] <MJCD> which is universally bad for everyone
[14:17] <patdk-lap> there are plunty of people in positions to do it
[14:17] <MJCD> so you really NEED //SOMEONE// to take that stewardship
[14:18] <patdk-lap> the issue is the power struggle of how many people will try to do it
[14:18] <patdk-lap> and who will trust who
[14:18] <MJCD> there are, but mostly in the longer terms ie generations on generations as the OS is intended for
[14:18] <MJCD> like there's not people queueing up to do it that everyone can universally agree on
[14:18] <patdk-lap> I really don't think linux was entended to even last one generation
[14:18] <MJCD> they'd need a certain authority.
[14:19] <MJCD> which almost directly implies commercial scale
[14:19] <MJCD> and sure redhat can splinter off from the last version there is or that they choose to etc etc
[14:19] <MJCD> but again, that's fragmentation
[14:19] <MJCD> and can and will be a  nightmarish scenario
[14:19] <patdk-lap> it's already fragmentated
[14:20] <MJCD> it wont be do you know <one of three> OS? If so you're good to go it's pretty same/same!
[14:20] <patdk-lap> anything worth doing is highly fragmented, or else you can never test anything, and everyone is producing the same thing
[14:20] <MJCD> I mean who knows maybe it'll end great
[14:20] <MJCD> I mean... A lot of the concepts in 2022 are so refined for UX that that's gonna happen regardless
[14:20] <patdk-lap> and I thought we where talking kernel, or are we talking os?
[14:21] <patdk-lap> there are hundreds of linux os's
[14:21] <MJCD> We have pretty good proof of what's good/works and why
[14:21] <MJCD> yes, and they're pretty similar ;p
[14:21] <MJCD> imagine for example xorg
[14:21] <MJCD> are they then expected to conform to say, debian/ubuntu compatibility as well as redhat compatibility?
[14:21] <MJCD> and then on and on and on the list goes?
[14:22] <MJCD> as is the ecosystem is 99% about reusability
[14:22] <MJCD> compartmentalization and components
[14:22] <MJCD> modules
[14:22] <MJCD> libs
[14:22] <patdk-lap> sinse when did xorg ever do that?
[14:22] <MJCD> they don't, now
[14:22] <patdk-lap> or ever did
[14:22] <MJCD> but if they became too far apart in how they operated....
[14:22] <patdk-lap> redhat patches it to make it compatable
[14:22] <MJCD> it'd be invariable
[14:22] <patdk-lap> and ubuntu patches it to make it compatable
[14:22] <patdk-lap> and if upstream accepts
[14:22] <MJCD> lol I mean, yes and no
[14:22] <MJCD> they tweak it
[14:23] <MJCD> it's already natively compatible
[14:23] <MJCD> everything is largely the same
[14:23] <MJCD> just organized differently heh
[14:23] <patdk-lap> so your telling me xorg has to create upstart compatability and systemd compatability, and anything else
[14:23] <MJCD> but the kernel is what allows for that to happen
[14:23] <MJCD> and more importantly
[14:23] <patdk-lap> those never started upstream
[14:23] <MJCD> to continue to move forward
[14:23] <patdk-lap> no, libc
[14:23] <patdk-lap> the kernel doesn't matter there at all
[14:23] <MJCD> lol 
[14:23] <patdk-lap> it's all libc and the os
[14:24] <MJCD> > and the OS
[14:24] <MJCD> ie the kernel
[14:24] <MJCD> sigh
[14:24] <patdk-lap> the issue with linux is libc wasn't wrapped into the kernel interface
[14:24] <patdk-lap> why we have all the abi changes
[14:24] <patdk-lap> unlike freebsd
[14:24] <MJCD> anyways thanks for rubber duckying my stupid certbot issue
[14:24] <MJCD> always remember friends; obey the apt
[14:24] <patdk-lap> certbot issues, I gave up on it so long ago and dropped certbot cause of them
[14:24] <MJCD> it's working perfect now, not in a snap
[14:25] <patdk-lap> :)
[14:25] <MJCD> so I can disable snaps entirely
[14:25] <patdk-lap> ya, I went to some snaps on my desktop machine
[14:25] <MJCD> though might look into it as it seems to be some kind of like, docker alike thing?
[14:25] <MJCD> but native?
[14:25] <patdk-lap> but it's proving to be repeated crashing so going have to drop them
[14:25] <MJCD> orly?
[14:26] <patdk-lap> ya, moved to slack snap, and it's causing all kinds of pains, and chrome having issues
[14:26] <patdk-lap> mysql workbench snap just wouldn't work, permission issues with local users config files
[14:27] <patdk-lap> discord snap is like only one that hasn't given me any issues
[14:35] <patdk-lap> personally I would imagine it would look something like illumos-gate does currently
[14:35] <patdk-lap> several companies approve and signoff of each others pr's
[16:07] <yurtesen> ahasenack: do you know when you will have a possible solution for tomcat log rotation bug?
[16:56] <ahasenack> other bugs are ahead of that one at the moment
[18:06] <ahasenack> kanashiro: have you ever seen a lxd fence agent for corosync/pacemaker?
[18:06] <ahasenack> like there are ssh ones, or even libvirt
[18:06] <ahasenack> should be similar to libvirt in concept at least
[18:08] <kanashiro> ahasenack, I think there is one, let me check
[18:08] <ahasenack> I searched and only found a very old blog post about using lxc (not lxd) as a libvirt backend, and then using the libvirt fence agent
[18:09] <ahasenack> ah, I was in focal, maybe jammy+ has something
[18:10] <kanashiro> ahasenack, hum, I did not found a fence agent, there is one lxd resource agent
[18:10] <ahasenack> ah
[20:47] <giu-> hi to all