[09:22] <doko> jamespage, coreycb: there are some oslo related autopkg failures in proposed ...
[09:22] <jamespage> doko: yes on my list for today - I'm just shoving a load of py3 enablement into a PPA for testing and I'll switch onto those
[09:23] <jamespage> one of them had me baffled so need to dig in a big
=== Son_Goku is now known as Conan_Kudo
=== Conan_Kudo is now known as Son_Goku
=== Spads_ is now known as Spads
[13:04] <rbasak> mvo: around? /snap/bin isn't in PATH in a non-interactive shell, eg. via ssh. So for example "ssh <host> lxc profile set default ..." fails. AFAICT, snapd packaging only drops in /etc/profile.d/apps-bin-path.sh which only affects login shells. For non-login shells, only /etc/environment applies. Is this intended, and/or any suggestions on fixing it?
[13:04] <rbasak> It feels like a wart when using snaps on servers.
[13:07] <rbasak> bug 1771858 seems relevant
[13:07] <ubottu> bug 1771858 in snapd (Ubuntu Cosmic) "/snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH" [Undecided,Confirmed] https://launchpad.net/bugs/1771858
[13:11] <ogra_> xnox, is that a black/white rainbow you added to your email address ?
[13:12] <xnox> ogra_, full bleed colors here, on recent bionic, with all the emojis installed.
[13:12] <xnox> ogra_, if you see black/white it means emoji support is borked.
[13:12] <ogra_> ah, i live in the past ... (cant really let unity go)
[13:12] <ogra_> (16.04 here)
[13:13] <xnox> e.g. launchpad.net/~xnox renders correctly on e.g. android phone
[13:13] <xnox> ogra_, mostly did it to see how much stuff is broken. doko & bdmurray reported that thunderbird is broken.
[13:14] <xnox> ogra_, and i see some breakage in some web-browsers too. Imho, if one cannot see colored emojis right, it's not a desktop worth having anymore.
[13:14] <ogra_> they are just holding it wrong :P
[13:15] <rbasak> mvo: I filed bug 1777445.
[13:15] <ubottu> bug 1777445 in snapd (Ubuntu) "/snap/bin isn't in PATH in a non-interactive shell, eg. via ssh" [Undecided,New] https://launchpad.net/bugs/1777445
[13:15] <xnox> ogra_, can you open launchpad.net/~xnox in firefox and check if that is colorful or black & white?
[13:16] <ogra_> xnox, FF renders it fine on xenial
[13:17] <ogra_> rbasak, there is also https://bugs.launchpad.net/snappy/+bug/1659719
[13:17] <ubottu> Launchpad bug 1659719 in livecd-rootfs (Ubuntu) "ssh can't call a binary from a snap without the full path" [Medium,Fix committed]
[13:18] <ogra_> (which made us add it to /etc/environment in core images)
[13:19] <rbasak> ogra_: ah. That's exactly the bug I just filed. But no bug against the snapd package? I can dupe and add that task.
[13:21] <ogra_> rbasak, well, i only wanted you to be aware, perhaps yours is better (newer, not so rotten ... and better title)
[13:22] <ogra_> when i brought up /etc/environment recently with the core team i was told thats too ubuntu specific and the generators will eventually solve it in 18.04#
[13:24] <rbasak> xnox: ^ do you know if the generators will solve it in the ssh non-interactive case? Does ssh involve systemd in that case?
[13:25] <rbasak> ogra_: I agree it's Ubuntu-specific - hence the task on the snapd packaging in Ubuntu. mvo's problem :-P
[13:26] <rbasak> I don't know of a good way of solving this though, if systemd generators won't work.
[13:26] <rbasak> /etc/environment isn't .d-ized.
[13:26] <xnox> rbasak, so there are user-environment-generators as well as system-environment-generators, reading openssh code, i was hoping that it may solve this, if the sshd's environment PATH= variable is correct. But testing here locally I do not believe that to be the case.
[13:26] <rbasak> xnox: AFAICT, ssh is using PAM and pam_env which reads from /etc/environment only.
[13:27] <xnox> rbasak, i believe that user-environment-generators are executed by user-session systemd and children, therefore by pam_systmed (logind).... but not sure if all that works in practice.
[13:27] <xnox> rbasak, hm. i thought you are hitting this because pam is not used / full login shell is not setup....
[13:28] <rbasak> I could be wrong
[13:28] <xnox> rbasak, cause if pam is running /etc/profile.d/* would be process, and /snap/bin should be in $PATH
[13:28] <xnox> (not "is runing" but "was used")
[13:30] <xnox> rbasak, i see that openssh has _PATH_STDPATH too.... which is fixed.... and in some cases appears to be used.
[13:30] <rbasak> systemd-logind does show a new session when I run ssh non-interactively
[13:30] <rbasak> pam_unix(sshd:session): session opened (etc)
[13:30] <xnox> can't tell if that is customizable, and if it is used by shells when used non-interactively
[13:30] <xnox> hmmm.
[13:30] <xnox> rbasak, you can try dropping:
[13:30] <xnox> #!/bin/sh
[13:30] <xnox> PATH=$PATH:/snap/bin
[13:31] <xnox> as an executable binary into /usr/lib/systemd/user-environment-generators/ and reboot; retest?
[13:31]  * xnox doesn't want to drop my user session here =)
[13:31] <xnox> i guess i can try this in lxd container
[13:31] <rbasak> Trying
[13:31] <rbasak> I'm using a VM
[13:32] <rbasak> No effect
[13:33] <rbasak> Hang on. If that's an executable, how will systemd ever see what it set?
[13:33] <rbasak> Should it be echoing something?
[13:33] <xnox> hmmm
[13:33] <xnox> yes it should be an echo
[13:34] <xnox> good point, me fails at typing
[13:34] <rbasak> Still nothing
[13:36] <xnox> /* read $HOME/.ssh/environment. */
[13:37] <mvo> rbasak: aha, thank you. we where looking into providing a systemd environment generator
[13:38] <mvo> rbasak: aha, I see you discussed this, sorry in a meeting, I will read backlog
[13:38] <xnox> mvo, well, but that's to fix something else. which looks like will not fix the usability issue over non-interactive ssh.
[13:44] <mvo> xnox: meh, yeah, just read backlog, this looks tricky
=== Elimin8r is now known as Elimin8er
[16:28] <cjwatson> rbasak,xnox,ogra_: Having to ever touch /etc/environment would be pretty poor.  I wonder if a good approach might be to provide a pam_snap session module which would add itself to PATH in the environment, and plug that in via /usr/share/pam-configs/ ?  You'd want to discuss that sort of thing with slangasek though.
[16:30] <cjwatson> In fact let me suggest that in the bug
[16:31] <Laney> There's an /etc/environment.d generator thing
[16:32] <cjwatson> Maybe, but generating /etc/environment is terrible
[16:32] <Laney> I think it reads /etc/environment and then runs all of the generators to update those variables
[16:32] <cjwatson> Well, that isn't going to work with the pam_env config as-is
[16:33] <cjwatson> And I'm not sure it would be particularly straightforward to make it do so, absent ... a PAM module
[16:33] <cjwatson> /etc/environment was AIUI always meant for admin overrides and I think it's a fundamental misunderstanding for people to try to use it as the baseline for distro configuration
[16:34] <Laney> Fine if it doesn't work for some reason, I'm just saying that editing /etc/enviornment is not the configuration mechanism you'd use.
[16:34] <Laney> You can also use /usr/lib/environment.d/ (environment.d(5))
[16:34] <cjwatson> It just seems like a fundamental category error
[16:35] <cjwatson> This is about PAM-using service session behaviour so it belongs in a PAM module IMO
[16:41] <Laney> I think the idea is you get a systemd --user from pam_systemd which ought to run these generators.
[16:41] <Laney> Annyway.
[16:43] <slangasek> cjwatson: I would much prefer to put it in /etc/environment than add more moving parts at runtime
[16:44] <slangasek> "meant for admin overrides" - I don't know that this is historically accurate
[16:45] <cjwatson> Hasn't it been widely advertised as something to be edited by admins?
[16:46] <cjwatson> I get severe twitches when people propose mixing admin-editable things and stuff that the distro fiddles with
[16:46] <slangasek> well, yes it's user-editable
[16:46] <slangasek> but we don't have a non-config-file default environment
[16:47] <cjwatson> Laney: But the context of this bug is individual commands started by ssh in place of a full-fledged user session, and AIUI those don't involve systemd --user
[16:49] <cjwatson> sshd execs those commands directly using execve()
[16:49] <cjwatson> So the PAM environment needs to be right or it won't work; a systemd generator cannot help, unless I suppose something like pam_systemd ran it and stuffed the answer back into the PAM environment
[16:50] <cjwatson> (I assume that would be a bad idea for other reasons, but don't really know)
[16:51] <rbasak> cjwatson: do you consider PAM as the solution then for both the interactive and non-interactive cases?
[16:51] <rbasak> Or just non-interactive?
[16:56] <cjwatson> rbasak: I don't know if I care if more than one thing handles it in the interactive case
[16:56] <rbasak> OK. That's what I was wondering :)
[16:58] <cjwatson> If slangasek prefers to hack /etc/environment (presumably in libpam-modules, since I see that has similar hacks today), then I won't stand in the way of that; that would be sufficient
[17:44] <xnox> cjwatson, slangasek - i dislike modifying distro to fit around snapd; I would prefer for snapd to ship a new pam module and activate that on all distros to inject /snap/bin -> as that would work across all distros.
[17:51] <smoser> is there a known issue with keyserver.ubuntu.com over the past few days ?
[17:52] <teward> smoser: IS would probably be where that question has to go, they run the keyserver.  Laney mentioned something about that in #launchpad a couple hours ago as well, maybe follow up with IS?
[17:53] <smoser> teward: yeah. i am doing that too, just wanted to avoid the higher escalation if it was known.
[19:16] <smoser> slangasek: aroudn ?
=== gurmble is now known as grumble
=== Guest35696 is now known as herb
[21:15] <slangasek> smoser: off today, sorry
[21:16] <slangasek> xnox: "modifying the distro to fit around snapd" - snapd is an integral part of our Ubuntu platform, and we shouldn't have to add extra pam modules to have the path correct.  A PAM module may make sense for other distros for whom snapd is optional
[21:23] <smoser> slangasek: no worries. thanks for responding. i followed up on your locale mp
[21:32] <slangasek> smoser: ack. the idea of putting this in base-files is not unappealing to me :)
[21:35] <smoser> i'm interesetd in the justification of "cloud-init should do it but it should not be in ubuntu proper"
[21:35] <smoser> (and /me is really afk now)
[21:38] <slangasek> smoser: yeah, I don't have any justification for cloud-init continuing to own it, I was just trying to fix the code where it is - but having taken a step back, I do think it would be a good idea to move this elsewhere, so that e.g. we DTRT even on non-cloudinit systems