| === RAOF[m] is now known as RAOF | ||
| === william is now known as g2 | ||
| tjaalton | ahasenack: done | 04:29 |
|---|---|---|
| === robink is now known as Guest65857 | ||
| 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:12 |
| 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) | 07:23 |
| === _hc is now known as Guest87130 | ||
| === Guest87130 is now known as _hc | ||
| 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? | 08:29 |
| 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:07 |
| infinity | rbasak: It's expected for a new upstream. | 10:46 |
| 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:22 |
| 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:43 |
| coreycb | doko: nm user error i think | 12:45 |
| === Eleventh_Doctor is now known as Pharaoh_Atem | ||
| === inaddy is now known as tinoco | ||
| mvo | smb: thank you, looking! | 12:57 |
| 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] | 13:25 |
| 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. | 14:40 |
| smb | mvo, It appears this was just an unfortunate flipping of bits at some point. I did mark my bug as invalid | 15:40 |
| mvo | smb: thanks for the update! interesstinng | 15:54 |
| 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:55 |
| 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:56 |
| mvo | smb: ok, no worries. your conclusion sounds right | 15:57 |
| 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 | 16:01 |
| === tyhicks is now known as Guest67790 | ||
| 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:14 |
| xnox | so wondering what is the "backing" store for the containers on the production machines.... dir? btrfs? | 17:15 |
| xnox | Laney, managed to reproduce =) | 17:30 |
| xnox | win | 17:30 |
| xnox | with btrfs backend | 17:30 |
| === alan_g is now known as alan_g|EOD | ||
| 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:23 |
| 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:28 |
| 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:29 |
| slangasek | stgraber: fair; otoh I don't think we distribute our rootfs as tarball anywhere except to a particular cloud partner? | 19:30 |
| 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:31 |
| stgraber | ah, base and possibly LP chroots may be fine as they likely don't contain iputils | 19:33 |
| stgraber | looking into tar xattr, looks like the issue is incompatible format for xattrs between GNU tar and libarchive | 19:34 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:42 |
| stgraber | AFAICT unsquashfs extracts xattrs by default, so that one should be fine | 19:43 |
| slangasek | rcj: ^^ fyi | 19:46 |
| rcj | slangasek: thank you | 19:53 |
| stgraber | slangasek: https://github.com/lxc/lxd/pull/4861 <- LXD side of this | 19:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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? | 19:59 |
| stgraber | zfs has some restrictions on xattrs by default for example | 20:00 |
| slangasek | it's zfs | 20:00 |
| 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:01 |
| 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:02 | |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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 :) | 20:07 |
| === ilera is now known as Guest29709 | ||
| 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:26 |
| mwhudson | is it an emacs regular expression? | 21:32 |
| hallyn | whzzup | 21:43 |
| 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 | 21:47 |
| 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) | 22:02 |
| === jeblair is now known as Guest15681 | ||
| sladen | ~ | 22:21 |
| 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:07 |
| 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:58 |
| 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 ... | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!