=== RAOF[m] is now known as RAOF
=== william is now known as g2
[04:29] <tjaalton> ahasenack: done
=== robink is now known as Guest65857
[07:12] <dupondje> https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1764819
[07:12] <ubottu> Launchpad bug 1764819 in freerdp2 (Ubuntu) "CredSSP v6 on Bionic not supported freerdp2" [Undecided,New]
[07:12] <dupondje> Might be something important to fix? The more people upgrade their windows server, the more people will have issues with freerdp connecting to it ...
[07:23] <dupondje> don't know who would be the best to guy to get this fixed :)
[07:23] <dupondje> Guess we don't want to take the cosmic version for bionic? (which is the best option I guess)
=== _hc is now known as Guest87130
=== Guest87130 is now known as _hc
[08:29] <seb128> doko, hey, you didn't reply yesterday about the new theme ... do you think it's possible to have a pre-ack so we can start shipping it? knowing we are the maintainer and commit to fixing issues raised by the review if there is any?
[10:07] <rbasak> bdmurray: SRU reviewing xfce4-terminal in the Bionic queue, I'm not sure what to do about the translation and build system noise. Is that OK?
[10:46] <infinity> rbasak: It's expected for a new upstream.
[12:22] <smb> mvo, you might be interested in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1784843
[12:22] <ubottu> Launchpad bug 1784843 in snapd (Ubuntu) "snap list: unexpected fault address 0xfffff1f0" [Undecided,New]
[12:43] <coreycb> doko: is python3.7-dbg up to speed with debug symbols? i'm getting a coredump but can't make much sense of it.
[12:45] <coreycb> doko: nm user error i think
=== Eleventh_Doctor is now known as Pharaoh_Atem
=== inaddy is now known as tinoco
[12:57] <mvo> smb: thank you, looking!
[13:25] <coreycb> doko: i may need a hand with this: https://bugs.launchpad.net/ubuntu/+source/python3.7/+bug/1784854
[13:25] <ubottu> Launchpad bug 1784854 in python3.7 (Ubuntu) "segfault in _abc__abc_instancecheck_impl at ../Modules/_abc.c:521" [Undecided,New]
[14:40] <smoser> cjwatson_ or bdmurray i'd appreciate review of https://code.launchpad.net/~smoser/software-properties/trunk.lp1667725-https-signing-key/+merge/351824 . It seems to me to be a general improvement.
[15:40] <smb> mvo, It appears this was just an unfortunate flipping of bits at some point. I did mark my bug as invalid
[15:54] <mvo> smb: thanks for the update! interesstinng
[15:55] <mvo> smb: if you still have the sd card a hash of the snapd binary and snap binary might be interessting to see if the binary on disk got corrupted
[15:56] <smb> mvo, though I have the SD card the first step I tried was a re-install of the dpkg, so that is gone
[15:57] <mvo> smb: ok, no worries. your conclusion sounds right
[16:01] <smb> mvo, After finding that I remembered dpkg --verify and found that a few more things were affected. But all of those much less obvious or likely to notice. I need to make a note to remember doing that next time
=== tyhicks is now known as Guest67790
[17:14] <xnox> Laney, what is the backing store for lxd for the armhf-on-arm64 runners? i'm trying to reproduce
[17:14] <xnox> compat_uts_machine=armv7l
[17:14] <xnox> bah
[17:14] <xnox> Unable to read extent map for '/usr/lib/systemd/tests/test-sleep': Inappropriate ioctl for device
[17:14] <xnox> Assertion 'test_fiemap(argv[0]) == 0' failed at ../src/test/test-sleep.c:94, function main(). Aborting.
[17:14] <xnox> but failing to do so, on an arm64 bare-metal instance, with lxd container.
[17:15] <xnox> so wondering what is the "backing" store for the containers on the production machines.... dir? btrfs?
[17:30] <xnox> Laney, managed to reproduce =)
[17:30] <xnox> win
[17:30] <xnox> with btrfs backend
=== alan_g is now known as alan_g|EOD
[19:23] <slangasek> stgraber: hi, so for LP: #1302192, you several years ago marked ping setuid because "there's currently no good ways to have capabilities be kept in all our images".  Is this still a concern?  This comes up because a customer has noticed /usr/bin/mtr-packet also has fscaps configured.  Should we still not be able to rely on xattr support on all our rootfs types?
[19:23] <ubottu> Launchpad bug 1302192 in iputils (Ubuntu Trusty) "capabilities not preserved on installation" [Undecided,Confirmed] https://launchpad.net/bugs/1302192
[19:28] <stgraber> slangasek: so it mostly depends on how much we care about tarballs and backward compat of squashfs
[19:28] <slangasek> stgraber: GNU tar has a --xattrs option now
[19:29] <stgraber> slangasek: recent squashfs implementations do support xattrs I believe, so as long as our build systems aren't running ancient versions of squashfs-tools that should be fine
[19:29] <slangasek> stgraber: I do see that in the existing pipeline, a newly-launched lxd container ends up without the fscaps but I haven't looked into it
[19:29] <slangasek> stgraber: I guess my question is, if I fix that, do you know of any reasons we shouldn't just require fscaps support as a baseline, and revert the iputils diff?
[19:29] <stgraber> slangasek: right but from what I remember about tarballs, it's an extension which redhat made a while back which isn't strictly compatible with the tar format, so some unpackers may crash
[19:30] <slangasek> stgraber: fair; otoh I don't think we distribute our rootfs as tarball anywhere except to a particular cloud partner?
[19:31] <stgraber> slangasek: LP build chroots are tarballs and we publish a -root.tar.xz for all cloud images on cloud-images.u.c
[19:31] <stgraber> slangasek: the ubuntu-base image on cdimage/releases is also a tarball
[19:33] <stgraber> ah, base and possibly LP chroots may be fine as they likely don't contain iputils
[19:34] <stgraber> looking into tar xattr, looks like the issue is incompatible format for xattrs between GNU tar and libarchive
[19:37] <slangasek> stgraber: and certainly, "fails to restore xattrs on unpack with certain unpackers" is a lesser bug than "fails to unpack with certain unpackers"
[19:37] <stgraber> slangasek: indeed, loosing the xattr is probably acceptable
[19:38] <stgraber> slangasek: I wish xattrs were better tracked in .deb packages though, if we had a .xattr file under /var/lib/dpkg/info/, we could trivially write a tool (cloud-init hook?) that could re-apply them all on startup, or if that fails, make all affected files setuid.
[19:39] <slangasek> stgraber: the root.tar.xz on c-i.u.c, we thought we were dropping, then we had a downstream requirement to bring it back (so it's present again in cosmic).  And it contains mtr-tiny, so is currently affected by this bug, which we either fix by adding xattrs to the tarball or by hacking mtr to not use xattrs (which would be less secure)
[19:42] <stgraber> slangasek: ok, anyway, I'm not opposed to having that delta be dropped, but this needs to be done carefuly, needs to be documented in the 18.10 announcement and we should expect a good pile of bugs as a result of it because people tend to like using tarballs/rsync with their systems and are unlikely to be passing --xattr to both of those right now.
[19:42] <slangasek> stgraber: ok, I think I'm going to post to ubuntu-devel and propose that we standardize on xattrs: yes
[19:43] <stgraber> AFAICT unsquashfs extracts xattrs by default, so that one should be fine
[19:46] <slangasek> rcj: ^^ fyi
[19:53] <rcj> slangasek: thank you
[19:55] <stgraber> slangasek: https://github.com/lxc/lxd/pull/4861 <- LXD side of this
[19:56] <slangasek> stgraber: is that sufficient to fix the fscaps on /usr/bin/mtr-packet?  i.e. the squashfs we're producing is already correct?
[19:57] <stgraber> slangasek: that only changes handling of tarballs and rsync, squashfs is supposedly unpacking xattrs by default which would suggest that your squashfs is bad?
[19:57] <slangasek> ok
[19:57] <stgraber> then again, mksquashfs says that it stores xattrs by default
[19:57] <slangasek> yeah, I will investigate
[19:58] <stgraber> how's the squashfs generated? is it directly coming off the build directory or is that getting repacked somewhere that might go through one of tar, rsync or a fs that's not capable of storing xattrs (or uses fakeroot/fakechroot which I suspect also may not know what an xattr is)
[19:58] <slangasek> it's generated by livecd-rootfs, it ought to be straight from the build dir without any intermediate tar streaming. But I'll dig
[19:59] <stgraber> and that's running as real root?
[19:59] <slangasek> # mount /var/lib/lxd/images/90203fd4cf8732375207ecbde3a1672466dbbfd72a12e39469db9ee6f51b0bbf.rootfs /mnt
[19:59] <slangasek> # getcap /mnt/usr/bin/mtr-packet
[19:59] <slangasek> /mnt/usr/bin/mtr-packet = cap_net_raw+ep
[19:59] <stgraber> oh, good, so the cap is there
[19:59] <slangasek> so the squashfs was good, but it's not visible within the container?
[19:59] <stgraber> what storage backend are you using?
[20:00] <stgraber> zfs has some restrictions on xattrs by default for example
[20:00] <slangasek> it's zfs
[20:01] <stgraber> slangasek: what does "zfs get xattr lxd/images" get you?
[20:01] <slangasek> NAME        PROPERTY  VALUE  SOURCE
[20:01] <slangasek> lxd/images  xattr     on     default
[20:02] <stgraber> ok, I usually set that to "sa" to support a larger set of attributes but I don't know that it'd cause the attr to just be stripped
[20:02] <stgraber> I wonder if it's unsquashfs' manpage lying to us
[20:02]  * stgraber tests
[20:03] <stgraber> oh, or maybe not...
[20:03] <stgraber> it may just be unpriv fscaps causing it
[20:03] <stgraber> lets see
[20:03] <slangasek> stgraber: I ran getcap on the mountpoint on the host also; it's not there
[20:04] <slangasek> $ getcap /var/lib/lxd/storage-pools/lxd/containers/caring-calf/rootfs/usr/bin/mtr-packet
[20:04] <slangasek> $
[20:04] <stgraber> ok, so unsquashfs is the likely suspect then, unless LXD changing permissions caused the kernel to strip the attr which is plausible too
[20:05] <stgraber> yup, that's it, it's the uid/gid remapping that's stripping it...
[20:05] <stgraber> stgraber@castiana:~$ lxc launch ubuntu-daily:cosmic c2 -c security.privileged=true
[20:05] <stgraber> Creating c2
[20:05] <stgraber> Starting c2
[20:05] <stgraber> stgraber@castiana:~$ lxc exec c2 -- getcap /usr/bin/mtr-packet
[20:05] <stgraber> /usr/bin/mtr-packet = cap_net_raw+ep
[20:05] <stgraber> so that's gonna be fun to fix...
[20:06] <slangasek> heh
[20:06] <slangasek> stgraber: feasible fun or infeasible fun? :)
[20:06] <slangasek> if you can't fix it, that puts a damper on a proposal to allow fscaps in packages
[20:07] <stgraber> should be feasible but I'd need to look into hallyn's work on unpriv fscaps
[20:07] <stgraber> I don'
[20:07] <slangasek> ok
[20:07] <stgraber> I can't remember if we can just set it the normal way in the xattrs or if we need to store the namespaced key
[20:07] <stgraber> I suspect we want the namespaced key so that the container user can update the binary later on but that's a bit of a blur in my head now :)
=== ilera is now known as Guest29709
[21:26] <slangasek>        --xattrs-include=PATTERN
[21:26] <slangasek>               Specify the include pattern for xattr keys.  PATTERN is a  POSIX
[21:26] <slangasek>               regular expression.
[21:26] <slangasek> LIES
[21:32] <mwhudson> is it an emacs regular expression?
[21:43] <hallyn> whzzup
[21:47] <hallyn> slangasek: I'm probably misunderstanding, but it sounds like you're expanding a tarball with xattrs in a userns, then expecting to see those from the host;  you'll only see them as xattrs from within a userns which has the same host uid mapped to root
[22:02] <slangasek> hallyn: this is lxd doing the expanding, and it winds up with fscaps disappearing from the rootfs of an unprivileged container (when viewed from either inside or outside)
=== jeblair is now known as Guest15681
[22:21] <sladen> ~
[23:07] <rbasak> infinity: did you conclude if you want to accept the nodejs openssl ABI/soname link change?
[23:07] <rbasak> bug 1779863
[23:07] <ubottu> bug 1779863 in nodejs (Ubuntu Cosmic) "Ubuntu nodejs package isn't ABI compatible with mainline nodejs." [Medium,In progress] https://launchpad.net/bugs/1779863
[23:58] <ogra> hmm, anyone familiar with journald ? ... according to the journald.conf manpage the commented values in journald.conf are the defaults ...
[23:58] <ogra> there are no size limites set in that file which makes me assume there is no upper limit for the logs ...
[23:59] <ogra> the logs are stored in /run ... which in turn is a tmpfs we mount with a fixed size (10% of the RAM it seems)
[23:59] <ogra> so that seems to be my upper limit for the logs ...