[00:32] <mason> SuperLag: https://wiki.ubuntu.com/fai-in-ubuntu
[00:32] <mason> SuperLag: Ah, and https://landscape.canonical.com/
[03:05] <mike802> hey, so i have phpmyadmin up and i'm trying to connect to mysql database and i'm getting an error
[03:06] <mike802> mysqli_real_connect() connection refused
[03:06] <mike802> #2002 connection refused; the server is not responding
[03:07] <mike802> apache2 seems to be up and so does my mysql database
[03:08] <mike802> so, i checked and i can log on with mysql -u guest etc.....
[03:08] <mike802> while i can't log on with -u guest -wrong password
[03:09] <mike802> so, i think i added a guest account to my database correctly
=== havenstance_ is now known as havenstance
[04:55] <cpaelzer> good morning
[06:06] <lordievader> Good morning
[08:48] <xrandr_mac> Hi there. I am having an issue connecting a gluster node on ubuntu to a gluster server running CentOS
[08:49] <xrandr_mac> I keep getting PEER_CONNECT and PEER_DISCONNECT events in the logs
[09:25] <jamespage> coreycb: errant /usr/etc/<project> directories in python{3}-project's are nice for upgrades
[09:25] <jamespage> fixed cinder
[11:42] <coreycb> jamespage: testing py2->py3?
[11:42] <coreycb> upgrades
[13:29] <jamespage> coreycb: yeah
[13:30] <kstenerud> ahasenack: It looks like app armor isn't enabled in the test environments for strongswan
[13:31] <ahasenack> kstenerud: "test environment" is just a vm you brought up, right? The test itself isn't messing with apparmor probably
[13:31] <ahasenack> kstenerud: have you tried enabling it before running the test?
[13:35] <kstenerud> ahasenack: aa-enabled says yes, but then aa-status gives:
[13:35] <kstenerud> 1 processes are unconfined but have a profile defined.                                          │
[13:35] <kstenerud>    /usr/lib/ipsec/charon (1769)                                                                 │
[13:35] <sdeziel> kstenerud: sometimes there are races with systemd and apparmor profile loading
[13:35] <sdeziel> kstenerud: have you tried "service strongswan restart" ?
[13:38] <kstenerud> that did it :)
[13:41] <ahasenack> interesting bug
[13:45] <kstenerud> which is why the regression tests didn't catch this I guess
[13:49] <sdeziel> kstenerud: all my strongswan deployments have Apparmor enabled and I never ran into this missing /proc/$PID/fd/ read rule. I think this is very specific to the reporter's config
[13:52] <sdeziel> ahasenack: I think the way to avoid this race would be to either tell systemd to apply an Apparmor profile as part of the unit file (not really applicable for stronswan) or put a dependency so that apparmor loading is done before starting the strongswan service
[13:55] <ahasenack> sdeziel: can't an apparmor profile for a service be enabled without restarting the service? I would think that's possible
[13:57] <ahasenack> kstenerud: btw, you can update the postfix sru card, did you see the emails?
[13:58] <kstenerud> ahasenack: Is that the bug tracker email?
[13:58] <ahasenack> launchpad email, yes. I got it, as I'm subscribed to that bug
[13:58] <sdeziel> ahasenack: according to man 7 apparmor, no: "Profiles are applied to a process at exec(3) time ; an already running process cannot be confined."
[14:00] <sdeziel> killing charon would probably have it started back by systemd but that's a bit intrusive too
[14:14] <kstenerud> hmm that's weird... When I try loading the testing env on cosmic, there's no aa-profile cmd
[14:18] <kstenerud> ahasenack: I've run the tests on cosmic and they work, so the bug was fixed somewhere between 5.6.2 and 5.6.3
[14:19] <kstenerud> so this would be a backport fix to bionic, right?
[14:19] <ahasenack> kstenerud: did you see the error before?
[14:19] <kstenerud> I saw the error when running a bionic vm
[14:19] <ahasenack> kstenerud: check /etc/apparmor* when installing 5.6.3 in cosmic to see if the changed profile line is in there
[14:19] <ahasenack> it might be in an abstraction directory
[14:22] <kstenerud> ahasenack: I don't see it applied in /etc/apparmor.d
[14:22] <ahasenack> hm
[14:22] <ahasenack> what was the line again?
[14:22] <ahasenack> from the patch
[14:22] <kstenerud> +  @{PROC}/@{pid}/fd/        r,
[14:22] <kstenerud> right after    /var/lib/strongswan/*     r,
[14:23] <kstenerud> in usr.lib.ipsec.charon
[14:24] <ahasenack> did you check the abstractions directory?
[14:24] <kstenerud> yes. Didn't see anything about charon in there
[14:25] <ahasenack> it doesn't have to be about charon, it could be a generic permission, for all services to use if needed
[14:26] <ahasenack> abstractions/bash:  @{PROC}/@{pid}/mounts            r, <-- example
[14:27] <ahasenack> well, bad example
[14:27] <kstenerud> OK. I don't see anything about @{PROC}/@{pid}/fd/ except in ubuntu-browsers
[14:27] <ahasenack> abstractions/base:  @{PROC}/@{pid}/{maps,auxv,status} r, <- more interesting one (generic)
[14:28] <ahasenack> yeah
[14:28] <ahasenack> then either it's not trying to read that, or apparmor isn't applied
[14:29] <kstenerud> when I aa-status, I see that /usr/lib/ipsec/charon is in enforce mode
[14:29] <kstenerud> oh hang on. that's just profile
[14:30] <ahasenack> you can also use ps faxwZ
[14:30] <kstenerud> there we go, the process is now in enforce mode
[14:30] <ahasenack> the Z option will add a column about confinement to each row
[14:31] <kstenerud> OK, running in enforce mode the test succeeded
[14:31] <ahasenack> and you got a denied?
[14:31] <kstenerud> nope
[14:32] <kstenerud> I'll try a second run with bionic. The tests didn't even finish on that
[14:32] <ahasenack> ok
[14:32] <ahasenack> vms or containers?
[14:32] <kstenerud> vms
[14:32] <ahasenack> good
[14:33] <ahasenack> I prefer vms when dealing with apparmor
[14:38] <sdeziel> with IPsec, VMs are needed for 95% of the use cases anyway
[14:39] <ahasenack> yeah
[14:40] <coreycb> jamespage: hit the same thing with heat. fixing.
[14:40] <jamespage> coreycb: hurrah
[14:40] <kstenerud> ahasenack: Hmm strange it didn't fail this time
[14:40] <jamespage> coreycb: I might run a quick non-charm test
[14:41] <coreycb> jamespage: that's what i'm doing. just looping through all the packages and upgrading.
[14:41] <jamespage> coreycb: oh ok
[14:41]  * jamespage stands backj
[14:42] <kstenerud> ahasenack: I'm doing this to test: https://pastebin.ubuntu.com/p/w4HQchZVfH/
[14:48] <ahasenack> kstenerud: and do you see the denied message in bionic?
[14:48] <ahasenack> and the test failing?
[14:48] <kstenerud> No, not this time
[14:48] <kstenerud> Last time I did get a failed test
[14:49] <kstenerud> oh wait wtf... charon isn't in enforce mode again
[14:50] <kstenerud> oh nm. The tests shut down strongswan
[14:51] <kstenerud> So I can't trigger the bug from these tests. I might have triggered something else beause I was trying different ways to do it
[14:51] <dpb1> kstenerud: are you "taking over" that strongswan MP that we received?
[14:51] <kstenerud> yes
[14:51] <dpb1> k
[14:51] <kstenerud> But I can't trigger the bug he had, so I can't verify the fix
[14:52] <dpb1> hrmph
[14:52] <kstenerud> I did see a similar looking fix in upstream strongswan, though
[14:52] <dpb1> was there a proper bug for it?
[14:53] <dpb1> lp bug
[14:53] <kstenerud> Our bug is https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1786250
[14:53] <ubottu> Launchpad bug 1786250 in strongswan (Ubuntu) "strongswan (charon) is rejected by apparmor to read /proc/<PID>/fd" [Undecided,In progress]
[14:53] <kstenerud> Not sure if the upstream fix was from that or a private bug report to the authors
[14:54] <ahasenack> kstenerud: what is the upstream change that could be related?
[14:55] <kstenerud> oh wait no. I'm getting confused by logwatch stuff :P
[14:55] <kstenerud> So no, there's no upstream fix. This is an apparmor and strongswan issue
[14:56] <ahasenack> ok
[14:56] <ahasenack> well, I don't have a handy strongswan config to check this out more carefully
[14:56] <ahasenack> if you think you could get to one with the hints from the test, go ahead, we could use it, as I'm sure this is not the last strongswan bug we will have to handle
[14:56] <ahasenack> but beware the rabbit hole :)
[14:57] <ahasenack> and the reporter went MIA
[14:57] <ahasenack> maybe what's needed is a service restart after the vpn is established, or a reload, or some other interaction with the daemons
[14:58] <ahasenack> or a logrotate to kick in
[14:58] <ahasenack> etc
[14:58] <kstenerud> ok, I'll see what I can come up with
[14:59] <sdeziel> I think the issue is somehow related to /etc/resolv.conf handling
[15:07] <TJ-> If it would help, I'm currently working on a strongswan deployment, and might be in a position to try to reproduce the issue, if it'd help
[15:08] <TJ-> I've been kicking a Cisco 860 series that doesn't want to play nicely with L2TP/IPsec too, due apparently to only offering IKE 3des-sha1-modp1024
[15:09] <kstenerud> TJ-: Yes, I just need a setup that I can put in a repro case
[15:10] <TJ-> kstenerud: remind of the bug number again, I'm on a different PC than when it was mentioned yesterday
[15:11] <kstenerud> https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1786250
[15:11] <ubottu> Launchpad bug 1786250 in strongswan (Ubuntu) "strongswan (charon) is rejected by apparmor to read /proc/<PID>/fd" [Undecided,In progress]
[15:18] <TJ-> kstenerud: I'll spend some time on it over the weekend whilst the office here is empty, see what I can come up with. It looks like the ipsec config hasn't been provided by the user, and the 16.04>18.04 d-r-u is likely the culprit
[15:27] <kstenerud> Great! Thanks!
[15:32] <TJ-> kstenerud: so I don't waste time, in the bug and MP there's talk of not being sure when 'it' was introduced but to me it isn't entirely clear what 'it' is! Is that referring to the apparmor profile change/difference, or accessing /proc/self/fd/ ?
[15:36] <kstenerud> TJ-: It worked in xenial, broke in bionic, and the fix apparently is to add @{PROC}/@{pid}/fd/        r, to usr.lib.ipsec.charon
[15:39] <kstenerud> under /etc/apparmor.d
[15:44] <TJ-> kstenerud: yes, I understood that bit, but the 'it' referred to - was it adding the apparmor profile, or strongswan reading /proc/self/fd/ ? From what I can see from the history, /proc/self/fd/ was added in 2015 before the xenial version was released so should be in that version, but the debian/usr.lib.ipsec.charon apparmor profile was added in 2016/2017 via an import from Debian.
[15:54] <kstenerud> I think it was strongswan attempting to read /proc/self/fd/
[16:11] <TJ-> Yes, that was introduced with commit b410d7f8ff
[16:28] <TJ-> the apparmor change was introduced into Debian 5.5.1-3 via commit 9e71a10822
=== not_phunyguy is now known as phunyguy
[16:45] <kstenerud> TJ-: Which repo is that?
[16:53] <TJ-> I added Ubuntu and Debian git repos to the upstream, as remotes, and tracked the changes from those
[16:53] <TJ-> 9e71a10822 came in via Debian
[17:33] <ahasenack> I wonder why the samba apport hook doesn't offer to include /var/log/samba/log*
[17:33] <ahasenack> usually systemctl status doesn't have enough information
=== cryptodan_mobile is now known as cryptodan
=== cryptodan is now known as cryptodan_mobile