[06:46] morning [06:55] good morning [06:55] mborzecki: how was your weekend? [06:55] zyga: indoors mostly ;) [06:56] zyga: is it equally cold in waw? [06:56] me too, what a coincidence :) [06:57] I see we had a 2.44.1 [06:58] anything special on Friday? [07:00] zyga: idk, spent almost whole friday fighting console conf [07:51] re [08:03] mornings [08:04] good morning zyga and pstolowski [08:06] hey pawel, hey mvo [08:06] I'm not sure how it's around where you live [08:07] pstolowski: mvo: morning guys [08:07] but when I walked outside earlier today [08:07] it was so so incredibly quiet [08:07] I heard birds chirping and not much else [08:08] I saw maybe four cars on a wide artery that is normally stuck in traffic at this time [08:08] it's so surreal [08:16] travis very non responsive today [08:16] at least for me [08:17] zyga: yeah, travis had half-a-day of database upgrade at saturday [08:17] uh [08:17] zyga: and I no longer have the "rebuild" button [08:17] what could possibly go wrong now [08:18] I'm trying to open or restart runs [08:18] zyga: can you still restart runs? [08:20] no, I cannot get the pages to load [08:20] travis times out, gh is responding fast [08:30] PR snapd#8315 opened: tests: ensure session agent service is ready in prepare [08:34] PR snapd#8316 opened: github: add prototype workflow running unit tests [08:42] jamesh: hi, we sometimes see failures of snap-session-agent-service-control , https://api.travis-ci.org/v3/job/665599033/log.txt [08:43] looking [08:46] jamesh: seems mvo was also looking in that: https://github.com/snapcore/snapd/pull/8315 [08:46] PR #8315: tests: ensure session agent service is ready in prepare [08:48] jamesh: yeah, if you could review that PR 8315 that would be great [08:48] PR #8315: tests: ensure session agent service is ready in prepare [08:49] jamesh: it might be too simplistic [08:50] mvo: is there a systemctl invocation to wait for a unit to be started? [08:51] e.g. I wonder if we could do "systemctl --user start sockets.target"? [08:51] jamesh: maybe, this is also about socket activation so start might test less than what we tested before? [08:53] mvo: the tests expect that sockets.target has completed: i.e. systemd has created the unix domain socket and is prepared to start the session agent when someone connects to it [08:53] hey pedronis, good morning [08:53] pedronis: do you remember that A=$B; B=$C; C=foo; problem my earlier implementation of environment untangled? [08:53] I don't think this would meaningfully change what is being tested, and might get rid of the race [08:54] zyga: yes [08:54] is somebody trying to do that? [08:54] pedronis: it seems snapcraft has a bug where it would be useful, it reorders environment entires, it sorts them :| [08:54] pedronis: I filed a bug for snapcraft [08:54] it's definityl a snapcraft bug [08:54] yeah [08:55] just found this ironic [08:55] jamesh: ok, feel free to push something else to the PR or a new one, happy with a better fix :) [09:05] mvo: I don't think I can edit other peoples' PRs, so I'll create a new one [09:06] jamesh: thank you [09:19] PR core20#28 opened: Add iptables package [09:26] PR snapd#8317 opened: many: make sure ephemeral failover snapd does not open sockets [09:37] please review https://github.com/snapcore/snapd/pull/8316 [09:37] PR #8316: github: add prototype workflow running unit tests [09:39] last run was one minute and 55 seconds [09:39] for "go test" results [09:45] PR snapd#8298 closed: many: enumerate system seeds, return them on the /v2/systems API endpoint [09:46] brb [09:47] PR snapd#8318 opened: tests: ensure sockets target is ready in session agent spread tests [09:51] PR snapd#8318 closed: tests: ensure sockets target is ready in session agent spread tests [10:12] mvo: I think you closed the wrong PR ^ 8318 sees it was closed in favor of 8318 [10:12] s/sees/says/ [10:14] pedronis: oh, sorry, /me is a muppet [10:15] PR snapd#8318 opened: tests: ensure sockets target is ready in session agent spread tests [10:16] PR snapd#8315 closed: tests: ensure session agent service is ready in prepare [10:18] pedronis: hi, i pushed some changes to search v2 wrt error-list. it turned out to be slightly annoying and the change may look a bit confusing, happy to discuss [10:18] pstolowski: thx, in a meeting atm [10:27] PR snapd#8319 opened: github: run unit tests and spread via github actions [10:28] wow, github actions runner is FOSS [10:28] https://github.com/actions/runner [10:28] and can run on hosted machines [10:30] this is neat https://github.com/actions/labeler [10:30] action to put labels based on what's changed in the tree [10:39] zyga, hi, any chance https://github.com/snapcore/snapd/pull/8265 can be merged? I'd be happy to test a snapd snap with that fix [10:39] PR #8265: tests: add regression test for MAAS refresh bug [10:39] ackk: this is just a regression test, there's no fix there [10:39] the fix has been merged and is behind a feature flag, long ago [10:39] zyga, the https://trello.com/c/QjX63wGx/201-4-document-snap-downgrade ? [10:40] zyga, I'm still seeing that issue with it enabled [10:40] zyga, it happens all the time for me [10:40] install/refresh/remove [10:40] I cannot see that [10:40] actually,even when I connect interfaces [10:40] let me log in [10:40] zyga, sorry, wrong link [10:41] good morning [10:41] zyga [10:41] zyga, I meant if it's robust-mount-namespace-updates [10:41] there is way to sort this with jetty [10:41] copy/paste is a bit messed up in focal [10:41] ackk: I'm sorry, is this different from any of the earlier fixes we did recently? [10:41] zyga https://pastebin.com/W9iT0sF3 [10:42] zyga, wdym? [10:42] ackk: I'm confused [10:42] ackk: can you tell me if the thing that is failing is one of the things we inspected last week [10:42] Starting Jetty: chown: changing ownership of '/tmp/oxauth.pid': Operation not permitted [10:42] su: must be run from a terminal [10:42] alvesadrian: I'm sorry, I cannot debug things for you [10:42] zyga, https://paste.ubuntu.com/p/mjV2zR4Pcn/ is an example of failure [10:43] zyga is not a debug [10:43] am not asking for that [10:43] ackk: does this represent one of the failures we've inspected before or is a new failure? [10:43] is how or why snap is failing to run a jetty app using jetty and the app in the same yaml [10:44] zyga, I'm not sure. one question I have is, does snap-discard-ns clean up everything? I wonder if running that might cause issues with later operations [10:44] zyga where i can find snapcraft.yaml [10:44] ackk: yes it does [10:44] zyga for java server apps [10:44] ackk: it should be invoked when there are no processes around, otherwise you fracture the view, some inhabit old world, some new [10:44] alvesadrian: I don't know, did you try checking on the forum? [10:44] yes [10:44] alvesadrian: since you mentioned chown, snaps should not change ownership of files [10:44] if course i already open a ticket [10:45] ticket? [10:45] sorry a post [10:46] zyga, so, just rebooted the container, I get this: https://paste.ubuntu.com/p/NVQ34Jvwxw/ [10:46] ackk: I'm not entirely sure what rebooting a container does [10:47] does it really discard mount namespaces? [10:47] zyga https://forum.snapcraft.io/t/issues-with-different-users-chown-and-su/16129 [10:47] zyga, well, it should? I mean it's like a a machine reboot [10:47] I don't know [10:47] that's a lxd question [10:47] alvesadrian: please familiarize yourself with https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461 [10:47] i already read that [10:48] zyga, what should I check to see if the correct namespaces are set up? [10:48] i cannot find a snapcraft.yaml file as example of people bullding a java app with the tocamcat or jetty on it [10:48] great, then you should understand that you cannot chown anything to 1000 or most other values [10:48] I cannot help you beyond that, I don't even know what jetty is [10:48] that will be great for me but i cannot find it like nobody did an snap of hat [10:49] jetty==tomcat [10:49] ackk: it's hard because of startup services, [10:49] ackk: can we spin it another way? can you report a bug with reproducer? [10:49] ackk: I cannot promise I will look instantly [10:49] as we have some other fires [10:49] but I will do my best [10:49] zyga, sure I'll try [10:50] couldnt find any example of snaocraft.yal for a java app containing a tomcat on it [10:50] or a java server app to serve the app [10:50] I don't know anything about tomcat but I googled some results [10:51] did you go over the first few hits? [10:51] nothing man [10:51] being the whole weekend digging [10:51] its like nobody build it a snappy for tomcat app or java server app [10:52] forget about tomcat, just mean a java server app [10:52] nobody builds java server apps on snaps [10:53] alvesadrian: did you check out https://snapcraft.io/docs/java-applications ? [10:53] course [10:53] can you post some feedback about that to the forum [10:53] I'm sorry, I"m not the spokesperson for snapd :) [10:53] I cannot help everyone [10:53] didnt mention anything about using an external java serer as source [10:53] i know [10:54] just wondering if u know something about it [10:54] I don't know what an external java server is (is that tomcat?) [10:54] thans [10:54] external means dont using the plug of jdk [10:54] thata what i mean getting from source [10:54] download it and running [10:54] thats what i mean [10:55] what does "the plug of jdk" mean? [10:55] like a snap that fetch tomcat(java server) and run the app inside [10:55] why fetcH? [10:55] why not bundle tomcat at build time? [10:55] the pluging for the jdk framework [10:56] what u mean? [10:56] an example? [10:56] maybe I misunderstand but from what you are saying the snap package would, after being installed, download tomcat and do something with it [10:56] nope [10:57] snap has a part tomcat and anotehr part for the java app [10:57] I see [10:57] and what is the problem there? [10:57] downloading tomcat? [10:57] zyga, fwiw https://paste.ubuntu.com/p/wQpmk2mkcS/ reproduces it for me. I'm not sure whether to file a new bug or it's just a manifestation of the previous one? [10:57] i cant find an example about how to [10:57] alvesadrian: is tomcat special? is downloading it different from downloading other files? [10:57] place it and run it with the java app [10:57] nope [10:58] just a source zip file [10:58] static [10:58] alvesadrian: did you check the snapcraft documentation for parts? [10:58] it will run a daemon [10:58] there's a way to download things there [10:58] source: URL [10:58] yes [10:58] it can fetch tomcat, or whatever [10:58] so? [10:58] ackk: at this rate, I'd say please file one [10:58] even if it's a dupe [10:58] zyga, ok [10:58] it's easier for me to keep a TODO list this way [10:59] ackk: I'm sorry for the issues, it's likely that maas has found more bugs than an average snap by now :) [10:59] zyga, we like to live on the bleeding edge :) [10:59] alvesadrian: so can you download tomcat using snapcraft part or not? [10:59] yes [10:59] as a part [10:59] ok, so what's the problem again? [11:00] not tomcat specially jetty but they are similar [11:00] after download [11:00] move the java app into the webapp folder [11:00] but not cluu how to run it [11:00] with a service declaration [11:01] alvesadrian, add an app: with daemon:simple and command pointing to a script which runs tomcat? [11:01] (remember to exec in the last line of the script) [11:01] where i can get a snapcraft.yaml with an example [11:01] about how to do it? [11:02] I really think you should slow down and look at snapcraft docs [11:02] zyga, oh, so maybe I'm still hitting https://bugs.launchpad.net/snapd/+bug/1867752 actually [11:02] Bug #1867752: Unable to remove snap with content interface (with robust namespace update) [11:02] https://snapcraft.io/docs/services-and-daemons [11:02] zyga, is this available in a snapd snap? [11:02] so i need to create a service declaration to run the script that start tomcat? [11:02] alvesadrian, yes [11:02] alvesadrian: ^ please check that page [11:03] zyga thanks thats enough [11:03] ackk: this should be in edge [11:03] zyga, ok, I'll test with that, see if it solves the issue. thanks [11:03] ackk also thanks [11:03] thanks! [11:06] zyga, that seems to work, thanks! [11:10] zyga final question [11:11] SNAP_DATA SNAP_USER_DATA SNAP_COMMON [11:11] those contaiing dirs writeables [11:11] can be chown? [11:11] teh files inside fo those? [11:12] ackk also if you know this ^^^ [11:12] alvesadrian, yes those are writable. why do you need chown? [11:14] java developers are asking me [11:14] why we cannot chown to jetty or tomcat user [11:14] why it needs to run as root [11:14] where would that user live [11:14] alvesadrian, services run as "root" in the container [11:14] alvesadrian, that's a confined root user though, so it's safe [11:14] no clue why they complaing about that [11:15] iirc fchown and chown syscalls are blocked by seccomp by default [11:15] you can make them a no-op by using snapcraft-preload if you can not change the code [11:17] if your developers heavily insist to drop to a user (which is pretty much nonsense inside confinement, but some apps can not be changed) you can use https://forum.snapcraft.io/t/system-usernames/13386 [11:17] ... but need to change your app to use this username ... [11:18] ogra the problem is they want to run jetty services [11:18] with user jetty [11:18] well, and they can not run it as root ? [11:19] it is inside confinement ... switching to that user brings no benefit [11:19] ogra here is teh case [11:19] https://pastebin.com/Uwe6vF8r [11:19] ogra https://pastebin.com/Uwe6vF8r [11:19] but they *can* switch to an unprivileged user if needed ... as described in the doc i just gave you above [11:20] so make them use that and configure it in the snapcraft.yaml [11:20] or convince them to run it as root [11:21] it should be possible to run jetty as root [11:21] there are few apps that really can't be convinced to run as root (postgres being one of them) [11:21] right [11:21] ackk https://pastebin.com/Uwe6vF8r [11:22] thats an exxample of whats going on [11:22] that's a flask app though? I don't see how is it relevant [11:24] su - jetty [11:24] I also set JETTY_USER=jetty for command [11:24] well, su or sudo inside snaps dont work anyway [11:24] Jython 2.7.2rc1 (v2.7.2rc1:1fcef1abf1d6, Mar 1 2020, 16:27:06) [11:24] [OpenJDK 64-Bit Server VM (Amazon.com Inc.)] on java1.8.0_222 [11:24] Type "help", "copyright", "credits" or "license" for more information. [11:24] >>> [11:24] >>> f=open("/tmp/text.txt",'w') [11:24] >>> f.write("test") [11:24] >>> f.close() [11:24] >>> import os [11:24] >>> os.getuid() [11:24] 1000 [11:24] >>> os.system('chown 1000 /tmp/text.txt') [11:24] chown: changing ownership of '/tmp/text.txt': Operation not permitted [11:24] 1 [11:24] Even see this: [11:24] >>> os.stat("/tmp/text.txt").st_uid [11:24] and chown is blocked by seccomp [11:24] 1000 [11:25] so we need to fix rthat app code? [11:25] run jetty as root, run the commands as root ... [11:25] or use snap_daemon if possible [11:25] the snap confinement is designed to be root safe [11:26] alvesadrian, is that chown a test or actual code you have ? [11:26] right, if you really cant use root, use snap_daemon ... [11:27] code [11:27] the point is, there is no jetty user on systems you install your snap on ... and nothing in snaps that allows to create such a user [11:27] thats real code [11:28] alvesadrian, maybe unrelated but, you shouldn't really need to chown the file to the same user that created it? [11:28] am not the developer [11:28] just packaging [11:28] use snapcraft-preload to make chown a no-op then [11:29] https://github.com/sergiusens/snapcraft-preload [11:31] alvesadrian, fwiw if the service is running as root in the snap, that chown will succeed (assuming you replace 1000 with os.getuid()): https://paste.ubuntu.com/p/v88DXT45bh/ [11:32] 1000 won't as you can only chown to the same user [11:32] (and root doesn't have CAP_DAC_OVERRIDE in the snap) === Eighth_Doctor is now known as Conan_Kudo === Conan_Kudo is now known as Eighth_Doctor [12:12] PR snapd#8320 opened: Updates to login-session-observe and network-manager interfaces [12:37] pstolowski: commented, let me know [12:38] PR snapd#8312 closed: many: fix packages having mistakenly their copyright as doc [12:38] pstolowski: also ping me when is ready for re-review, I saw there bits still not addressed. thanks [12:56] pstolowski: I did a pass on #8309 [12:56] thanks for it [12:56] PR #8309: o/configcore: implement Apply method for early configuration of core [12:59] pedronis: thanks! i just replied to one of your search v2 comments [13:02] pstolowski: answered [13:03] pstolowski: I'm sure we can do something but yes touching the global helper is delicate so we can postone [13:04] pedronis: thanks. yes it's all messy and super confusing already. nb, error-list vs error_list in struct storeErrors, but that's probably historical? [13:05] pstolowski: yes, that's used in the bit that we should drop when we can [13:09] pedronis: do you think we could stay after the standup and discuss integration of snap-recovery-chooser with console-conf? [13:09] mborzecki: yes, if the standup doesn't take too long [13:10] ack [13:18] morning folks [13:19] hey ijohnson [13:20] hey cmatsuoka how was your weekend ? [13:20] confined, and yours? [13:21] haha yep same, but we did a lot of cleaning so that's nice [13:33] cmatsuoka: thats a whole new level of eating your own dogfood man [13:34] cwayne: haha indeed [13:55] ijohnson: I answerd to you comments in 8314, we cannot write a snap-failure that assumes only new snapds [15:10] jdstrand, if i added "/dev/usb/lp[0-9]* rwk," to the raw-usb interface to allow a customer to use a receipt printer (writing to the device directly, no cups or so) ... would you object that ? (raw-usb seems like the correct place, if thats wrong we'll likely need a "raw-usbprinter" interface or so) [15:12] ogra: sure, for the same reason as we allow "# Allow access to all ttyUSB devices too" [15:12] yeahm that was my rationale to pick that place :) create [15:12] s/create/great/ [15:13] * ogra glares at his fingers [15:34] mvo: #8287 is the PR for 2.44 of my initial snap-failure changes that pedronis's changes are based on top of FYI [15:34] PR #8287: tests, many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests (2.44) [15:41] ijohnson: thanks, checking it now [15:43] mvo, hey [15:43] I am creating the cloud config in this place currently system-data/var/lib/cloud/seed/nocloud-net/ [15:43] for uc20 [15:44] mvo, this right? ubuntu-seed/data/etc/cloud/cloud.cfg. [15:44] d [15:44] cachio: it depends what kind of data are you creating [15:45] is it user-data? [15:45] user-data and meta-data [15:45] yea, your place is correct [15:45] and we need more code [15:45] (I mean correct about to /data) [15:45] mvo: ^ [15:46] what we discussed last week actually [15:47] pedronis, i tried to merge #8299 but still out of sync [15:47] PR #8299: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous [15:47] I did re-login [15:47] but didnt work [15:47] on github and travis as well [15:47] pedronis, any other idea? [15:48] pedronis, cachio indeed, the current PR only supports cloud.cfg.d - I can extend the code for user-data and meta-dat [15:49] * mvo added a todo for himsef [15:49] mvo: we need to extend for seed/* at least for dangerous, for non-dangerous we need to be a bit more careful [15:49] mvo, if it is in a following pr should be nice [15:52] Hello everyone, where do the MOTU team chat? IRC? The MOTU information on the Ubuntu wiki is many years out of date (seriously!) [15:52] pedronis: yeah [15:52] cachio: yeah, put on my todo [15:52] thanks [15:53]