[00:26] <Kilroy> where would I look to see why a drive is not mounting?
[00:27] <sarnold> try to mount it and see if there's any errors given directly, or in dmesg
[00:27] <Kilroy> it did not give any errors just won't mount
[00:28] <Kilroy> ok I get this from dmsg
[00:28] <Kilroy> Feb 16 18:28:03 sturtz.cf systemd[1]: data.mount: Unit is bound to inactive unit dev-disk-by\x2did-dm\x2duuid\x2dLVM\x2dMudyLBQKlDEZZpEagNRQt6z7Zj0uXzJMwQZCyGC8JnBSpt6pvJOY2GhQsspYD7I0.device. Stopping, too.
[00:29] <Kilroy> what does that mean?
[00:35] <Kilroy> ah
[00:35] <Kilroy> fixed it 
[00:35] <Kilroy> just had to run systemctl daemon-reload
[00:36] <sarnold> ah, nice :) I had no idea on that one
[00:37] <Kilroy> just a bit of searching (I forgot about the web) https://www.claudiokuenzler.com/blog/1124/linux-mount-not-working-systemd-unit-is-bound-to-inactive
[00:39] <sarnold> *wild*
[00:39] <Kilroy> anybody know what fliesystem type would be the best for storage?
[00:39] <Kilroy> like a cloud storage
[00:41] <sarnold> I like zfs; ext4 is kind of a default but I don't think it'll go quite as far
[00:42] <Kilroy> what about xfs
[00:42] <Kilroy> (I could not find zfs)
[00:43] <sarnold> I understand xfs is redhat's default, so it's probably got some good qualities to it, but it's less common in ubuntu-land
[00:43] <Kilroy> ok
[00:43] <sarnold> this series of blog posts is pretty old now but does a good job of introducing zfs https://pthree.org/2012/12/04/zfs-administration-part-i-vdevs/
[00:44] <Kilroy> ok thank you
[00:44] <sarnold> skip the "install" post, on ubuntu it's just apt install zfsutils-linux   :)
[00:45] <Kilroy> ok thank you
[04:28] <Kilroy> is there away to only allow one ssh key?
[05:49] <cpaelzer> good morning
[05:51] <lotuspsychje> morning cpaelzer 
[05:57] <cpaelzer> o/ lotuspsychje
[07:06] <mirespace> good morning
[07:08] <lotuspsychje> welcome mirespace 
[07:15] <oden> Hi. I'm using a Moxa Technologies Co Ltd CP-114EL (4-port RS-232/422/485 Smart PCI Express Serial Board) and want to "hard code" so that /dev/ttyS4 always is /dev/ttyS4. Right now it's /dev/ttyS7 no matter which one of the four ports I connect a device to. 
[07:17] <oden> # grep -v unknown /proc/tty/driver/serial | tail -4
[07:17] <oden> 4: uart:ST16650 mmio:0x92C00000 irq:16 tx:0 rx:0
[07:17] <oden> 5: uart:ST16650 mmio:0x92C00200 irq:16 tx:0 rx:0
[07:17] <oden> 6: uart:ST16650 mmio:0x92C00400 irq:16 tx:0 rx:0
[07:17] <oden> 7: uart:ST16650 mmio:0x92C00E00 irq:16 tx:0 rx:0 RTS|DTR
[07:19] <oden> So, if I change to the connector marked P1 (/dev/ttyS4) it does not matter in the above command.
[07:20] <oden> I don't really know what to do here.
[07:22] <oden> I mean, if I put the device in P3 I would expect "6: uart:ST16650 mmio:0x92C00E00 irq:16 tx:0 rx:0 RTS|DTR" but no.
[07:35] <oden> Ouch. Never mind this. It was operator bork
[07:36] <lotuspsychje> !yay
[09:30] <mirespace> hi lotuspsychje :)
[10:16] <odc> Hi! I have a question about the ubuntu/bin9 docker image (https://hub.docker.com/r/ubuntu/bind9). I understand it is managed by the Ubuntu Server team. This seems to be a very used image, yet it is marked as "beta". Why isn't there a "stable" version? Should I use this in production?
[10:25] <rbasak> sergiodj, athos: ^
[10:37] <frickler> odc: this seems relevant https://bugs.launchpad.net/ubuntu-docker-images/+bug/1955318
[10:43] <odc> good find frickler :)
[10:45] <odc> so I wonder why they've never selected a "stable" version. I guess bind is not used a lot these days...
[11:27]  * Walex2 likes NSD and Unbound
[11:50] <evit> Was there an update to SSH on Ubuntu 18.04 in the last few days? I recall seeing one but I don't see it in security notices...
[11:54] <andol> evit: Yes, https://launchpad.net/ubuntu/+source/openssh/1:7.6p1-4ubuntu0.6
[11:54] <andol> Not all updates are security updates.
[11:56] <andol> ...and yes, I'm too a bit confused by the date in the changelog.
[11:57] <ahasenack> good morning
[12:07] <evit> @andol, Yes, indeed. With all the supply chain attacks I was having a freak out moment. =X
[12:09] <rbasak> andol: it was prepared a long time ago, but the update wasn't issued because nobody was identified who still needed it. Until recently.
[12:09] <evit> @andol, sometimes updates to the sec notice page come in a delayed fashion too. 
[12:09] <evit> Not complaining, just sayin'
[12:12] <athos> good morning!
[12:17] <athos> odc: The process of promoting the published OCI images is still being designed. That question seems to be fit to start a discussion in the bug frickler linked here though :)
[12:33] <odc> thanks athos! Hurry up guys :p
[13:40] <lotuspsychje> GWM: could you please affect bug #1961092 rbasak tested for you, in the left upper corner so the bug gets confirmed?
[14:02] <ahasenack> does anybody here (server) use nfs-ganesha?
[14:02] <ahasenack> I was surprised to find it in main
[14:09] <ahasenack> ok, openstack uses the bit that touches cepf
[14:09] <ahasenack> ceph
[14:23] <oden> ahasenack: hello. long time no see!
[14:24] <ahasenack> hi oden!
[14:24] <ahasenack> still riding your bike in the snow? :)
[14:24] <oden> yep. can't resist :)
[17:17] <bryyce> hi lena, thanks for reviewing the mysql apport hook MP when you get time.  I've added some tips on what is good to test and consider in doing the review.
[17:18] <bryyce> lvoytek, our team's official docs on doing MP reviews is at https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/MergeProposalReview.md; it has a handy checklist
[17:19] <bryyce> lvoytek, the page with the MPs to review is https://code.launchpad.net/~canonical-server/+activereviews (worth bookmarking if you haven't already).
[18:24] <lvoytek> bryyce: Thanks! I'll get started on that soon
[19:25] <sergiodj> ahasenack: hey, any news on that winbind bug we were discussing yesterday?
[19:25] <ahasenack> no, didn't check
[19:28] <smoser> I wonder who would care to review https://github.com/smoser/talk-simplestreams/pull/13
[19:28] <smoser> philroche and Odd_Bloke were last ones to touch it.
[19:29] <sergiodj> ahasenack: is this in your TODO list, or is it something you don't plan to tackle soon?  asking because I'd then have to add it to my TODO list
[19:29] <ahasenack> it's written down
[19:30] <sergiodj> OK, thanks.  let me know if you need help
[19:31] <smoser> ahasenack  or blackboxsw  ?
[19:33] <ahasenack> maybe someone from maas?
[19:33] <ahasenack> are you saying the "stable" url now has the "daily" content?
[19:40] <ahasenack> I pinged the maas team
[19:52] <smoser> ahasenack: i think that they just started publishing daily as stable
[19:52] <smoser> i think they're probably the same filesystem under neitht
[19:53] <ahasenack> I remember back in the day noone was crazy to run "stable", all went for the daily stream
[19:54] <ahasenack> as "stable" was really never updated
[19:54] <ahasenack> but I'd think the fix for that would be to update stable, instead of calling daily == stable :)
[20:11] <blackboxsw> smoser: I'll also get a prelim review on this today. Wanted to understand the context of the url changes in general from MAAS too.
[20:20] <smoser> ahasenack: don't shoot hte messanger on that.
[21:31] <ahasenack> sergiodj: that winbind bug, it worked fine locally, but this is just a very small AD with one client connected to it, I didn't really expect otherwise
[21:31] <ahasenack> sergiodj: there is this interesting remark in the winbindd manpage, though
[21:31] <ahasenack>        SIGHUP
[21:31] <ahasenack>            Reload the smb.conf(5) file and apply any parameter changes to the running version
[21:31] <ahasenack>            of winbindd. This signal also clears any cached user and group information. The
[21:31] <ahasenack>            list of other domains trusted by winbindd is also reloaded.
[21:31] <ahasenack> so if you have a ton of users cached, that simple logrotate will clear the cache
[21:32] <ahasenack> that might explain why it's sluggish after that, and also why a restart takes a minute
[21:32] <sergiodj> interesting
[21:33] <sergiodj> well, to me it seems like a possible Incomplete/request-more-info kind of bug, but with the above as a possible cause
[21:33] <sergiodj> would you like to update the bug or should I?
[21:34] <ahasenack> I'm adding something, but this is one of those where to investigate further, a lot of time will have to be spent
[21:34] <sergiodj> (thanks for the further investigation, btw)
[21:34] <ahasenack> I can ask some bits there that are missing
[21:34] <sergiodj> +1
[21:34] <ahasenack> I'm adding a comment, take a look in a few to see what you think
[21:34] <sergiodj> will do, thanks
[21:36] <ahasenack> that being said, it's unclear if smbcontrol uses sighup
[21:36] <ahasenack> `The winbindd destination causes the message to be sent to the winbind daemon specified in the winbindd.pid file.`
[21:36] <ahasenack> time to strace
[21:37] <sergiodj> :)
[21:38] <ahasenack> 7993  openat(AT_FDCWD, "/var/run/samba/winbindd.pid", O_RDONLY|O_NONBLOCK) = 8
[21:38] <ahasenack> 7993  read(8, "5365\n", 19)             = 5
[21:38] <ahasenack> 7993  kill(5365, SIG_0)                 = 0
[21:38] <ahasenack> what's SIG_0?
[21:39] <sergiodj> SIG_0 is usually used to obtain the PID
[21:39] <sergiodj> sorry, I mean, to actually consult whether that PID is still alive
[21:40] <sergiodj> it does nothing
[21:40] <ahasenack> ok, then it's using something else
[21:40] <ahasenack> and that manpage remark doesn't apply
[21:40] <ahasenack> yeah, it opens a unix socket afterwards
[21:41] <ahasenack> but maybe internally relaod-config has the same effect
[21:42] <ahasenack> `/* React on 'smbcontrol winbindd reload-config' in the same way as on SIGHUP*/
[21:42] <ahasenack> `
[21:42] <ahasenack> ok, it's the same
[21:46] <ahasenack> ok, posted something
[21:48] <sergiodj> thanks
[21:49] <sergiodj> do you mind if I set the bug as Incomplete?