/srv/irclogs.ubuntu.com/2015/10/07/#snappy.txt

=== Ursinha_ is now known as Ursinha
=== chihchun_afk is now known as chihchun
dholbachgood morning07:14
dfletchmorning08:34
dfletchcan one have apt parallel to snappy?08:34
JamesTaitGood morning all; happy Wednesday, and happy Frappe Day! 😃08:50
clobranogood morning08:56
clobranoChipaca: hello, I came back on Bug #1496319 :)09:02
ubottubug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/149631909:02
clobranoChipaca: problem was adding custom Udev string as hw-assign parameter. Is there a way to check whether Udev is tested enough for this?09:04
soffoklHi all, we are still trying to execute Snappy on parallella board. Based on porting guilde, we have take beagebone rootof and our own kernel. After some configuring u-boot, we have managed to load system.09:05
soffoklBut after that we failed to login by “ubuntu/ubuntu”, because of system after first boot sets /var/lib/extrausers/shadow like ubuntu:!$6$tOIJ…09:05
soffoklAfter removing “!” we can successfully login into system. But mount command shows that root mounted in “rw” mode. And seems like not all mount points mounted properly.09:06
soffoklogra2, ogra_ : you are our last chance :)09:10
Chipacalool: you around?09:15
Chipacamwhudson: did you see pitti's reply on bug 1487010?09:16
ubottubug 1487010 in golang (Ubuntu) "please upload new package to reenable go's race detector on wily" [Undecided,In progress] https://launchpad.net/bugs/148701009:16
loolChipaca: yup09:16
Chipacaclobrano: i'd ask security people09:16
Chipacalool: you've ported snappy to some odd places :)09:16
Chipacalool: any hints for soffokl here?09:16
clobranoChipaca: thanks09:16
loolsoffokl: are you using our initrd snippets?09:17
loolsoffokl: http://kernel.ubuntu.com/git/rtg/snappy-tools.git/ has a tool to create the device tarball from kernel .debs09:18
Chipacaclobrano: most of 'em are at something like utc-5 though09:18
* clobrano checking UTC-509:19
clobranoChipaca: it's not a problem, I can wait :)09:19
ogra_soffokl, and you used ubuntu-device-flash to create this image ?09:25
Chipacaan ogra!09:25
* Chipaca faints09:25
ogra_well, inofficial still :)09:25
Chipaca:)09:25
ogra_(but bored as hell)09:26
soffokllool, we have tried to use beagleboneblack initrd, but then our kernel failed to load.09:26
ogra_then youur kernel is likely missing bits that snappy needs09:26
loolsoffokl: you need to have the right modules and options, either builtin modules or in the initrd09:27
ogra_nah09:27
ogra_you shouldnt need modules09:27
loologra_: either builtin or as modules  :-)09:28
ogra_if you use the same config we use on the beagle or on the rpi images you will have everything you need to mount the readonly root and the overlays09:28
soffoklogra_, yes, we have created image with "sudo ubuntu-device-flash core 15.04 -o my-snappy.img --size 4 --channel edge --oem beagleblack --enable-ssh --device-part=./device.tar.xz"09:28
ogra_i have booted both with module-less initrds09:28
biezpalogra_, which config you mean?09:29
ogra_soffokl, well, you need to create your onwn oem snap ... with the right bootloader, vmlinuz and initrd09:29
ogra_biezpal, the kernel config :)09:29
biezpalogra_, where can we get the "correct" kernel config?09:30
biezpalwe are using our own kernel for parallella and seems like it doesn't have required for snappy bits..09:32
ogra_ppisati, ^^ doo you have a link for biezpal09:32
ppisatibiezpal: kernel version?09:33
ppisati3.10, 3.14 or 3.18?09:33
ogra_or perhaps 4.2 ?09:34
ogra_:)09:34
ppisati*drums*09:34
ppisati4.2 would be awesome09:34
biezpalppisati, 4.2.0  :D09:34
ogra_soffokl, note that a readonly root is normal ... only a few selected bits are writable via bind mounted dirs and files, that is what the initrd is needed for09:35
ogra_(it sets up the bind-mount-farm)09:35
ppisatibiezpal: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_packaging09:36
ppisatibiezpal: look at the UBUNT: [Config] commits09:36
ppisatibiezpal: they all touch files in09:36
soffoklogra_, thanks, we are keep reading about oem snap09:36
ppisatibiezpal: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/tree/arch/arm/configs/snappy?h=snappy_packaging09:37
ppisatibiezpal: cherry-picks these commits09:37
ppisatibiezpal: then09:37
ppisatibiezpal: $ ARCH=arm ./scripts/kconfig/merge_config.sh arch/arm/configs/YOURCONFIG_defconfig arch/arm/configs/snappy/*.config09:37
ppisatibiezpal: and you should get a config able to boot snappy09:38
ogra_soffokl, note that we switched to use a uboot.env file for the environment, but the old uEnv.txt and snappy-system.txt stuff should still work to get something to do a first boot (just rollback and update wont, but thhats a second step for porting)09:38
biezpalppisati, ok, thanks for helping..09:40
longsleepyesterday i tried updating one of my test boxes to stable 6, it failed with the message that ubuntu-core was sideloaded. Is that expected?10:17
longsleepogra_: Hey, are you using predictable network interface names with rpi2 image? If so, how did you enable it, kernel parameter only?10:23
ogra_longsleep, i'm actually suppressing them via kernel cmdline option corrently10:23
ogra_net.ifnames=010:24
ogra_that keeps the old naming scheme10:25
longsleepogra_: Ah - but that is the default in ubuntu isnt it?10:25
ogra_not sure if we use it elsewhere10:25
longsleepogra_: net.ifnames=1 is working to some level for me, but i was wondering if the interfaces should still be eth0 and wlan010:26
ogra_well.... snappy config ubuntu-core defaults to eth0 currently10:26
longsleepright, but aside from that, i was kind of expecting crazy interface names with that change10:27
ogra_yeah10:27
ogra_depends on your HW10:27
longsleepmhm ok, USB wifi is getting wlan0 names, works fine as long as you do not replace the USB device with another one10:28
ogra_http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/10:29
ogra_seems you are lucky and fall inot category 5 on that 1-5 list10:29
longsleepmhm10:30
longsleepthis means the hardware does not provie 1, 2 or 3 or i am doing something wrong10:31
ogra_right ... or you have a udev rule in place already10:31
longsleepi did at least expect it to use 310:31
longsleepogra_: why do you not use it on the rpi2? just because ubuntu-core defaulting to eth0?10:32
ogra_yeah, and i get a really weird name based on the mac address (4)10:32
longsleepoh10:32
longsleepyeah 4 would be bad10:32
ogra_(which i shouldnt according to that doc)10:33
longsleepwell, maybe it is enabled in the systemd build somwhere10:33
ogra_iirc Chipaca said all that works fine in rolling ... never tried that10:33
ogra_i added this hack to rpi specifically for 15.04 images10:34
Chipacammh?10:34
Chipacai was probably lying, whatever it was10:34
Chipaca's a good bet10:34
ogra_lol10:34
longsleepanyways, i am basically fine with getting 5 - but i have some issues when an active USB wifi is removed and replaced, something is not released then and then10:34
longsleepmhm, from my testing setting the kernel parameter to 0 is the same as the default behavior without the parameter10:35
longsleep(stable channel though)10:35
ogra_funny10:35
ogra_is that on a first boot ?10:36
longsleepyes10:36
ogra_(wont work on subsequent ones since the udev rule exists)10:36
longsleepwhen i remove the udev rule and reboot without the parameter it creates it again10:37
longsleepsame is when booting with 0 as value10:37
longsleepwhen booting with 1, the udev rule is not created10:37
ogra_yeah10:38
ogra_but your kernel simply provides the old naming10:38
Chipacais this about the creation of the file for the first ethernet card?10:40
longsleepogra_: oh, so this thing depends on the kernel as well, i thought it would be systemd only10:40
ogra_well, that is what the wikipage says10:40
longsleepChipaca: it is about the interface names and the udev rule stores all ethernet devices ever connected to the host10:41
* longsleep checks the wiki again10:41
ogra_5. Classic, unpredictable kernel-native ethX naming (example: eth0)10:41
ogra_kernel-native10:41
Chipacaah10:41
Chipacabut i had nothing to do with that :)10:42
Chipacaall i did touching that was creation of the first-boot file for the first ethernet device10:42
soffoklogra_, we are successfully loaded with initrd, thanks again :)10:42
longsleepogra_: right, but any kernel should be the same right?10:42
Chipacawhich just looks for eth* and en*10:42
ogra_i'm pretty sure you worked on a snappy specific bug for it :)10:42
ogra_right10:42
longsleepChipaca: what file is that?10:42
ogra_soffokl, \o/10:42
Chipacalongsleep: /etc/networ/interfaces.d/{ethname}10:42
longsleepChipaca: ah, well you should probably extend this to also support wl*10:43
ogra_in the course where we discussed that bug it turned out that rolling and 15.04 behaved differently10:43
ogra_which led me to use the kernel cmdline option on rpi stable10:43
longsleepi see10:44
longsleepmhm funny that i do not seem to be required to use the cmdline option though10:44
ogra_i agree abouth the wl* thing though10:44
Chipacalongsleep: wl is wifi, sin't it?10:44
longsleepChipaca: yeah10:44
ogra_yep10:44
Chipacaisn't that more complicated?10:45
ogra_buut if you are unluckly it could also be wifi010:45
ogra_:P10:45
* ogra_ has seen such devices before10:45
longsleepreally10:45
longsleepoh my10:45
* Chipaca <- il ne sais rien10:45
Chipacasait*10:45
ogra_rm -fr ....10:45
longsleeplol10:45
* ogra_ removes the french10:45
Chipaca:D10:46
Chipacaor, D:10:46
Chipacalet me get our friends out of france first!10:46
ogra_heh10:46
longsleepwifi is more complicated true, i am currently providing wpa config in /etc/writable/wpa_supplicant.conf10:46
longsleepdid not find any better writable mount to put it10:46
ogra_there might be a network-manager framework at some point in the future10:47
ogra_that should make it easier to just supply a snappy confg yaml for your setup10:47
Chipacalongsleep: you can't configure it via the interfaces.d thing in config?10:47
ogra_only to a certain extend10:48
longsleepChipaca: not if you want to be able to configure multiple networks10:48
ogra_wifi config works fine via /e/n/i ... but not for the higher level encryptions10:48
Chipacalongsleep: i don't think multiple networks blocks this10:48
ogra_i.e. enterprise WPA and such10:48
Chipacaogra_: yeah, those always tripped me up :)10:48
longsleepChipaca: what is not blocked by multiple networks?10:49
ogra_normal personal WPA2 works fine via the file10:49
longsleeponly for a single ssid10:49
ogra_i never tried multiple :)10:49
longsleepif you want roaming or have it auto pick the stronges signal it will not10:49
Chipacaah10:50
longsleep=t10:50
Chipacaso, let's call it "basic support"10:50
Chipaca:)10:50
ogra_and my WIFI APs here can properly use ESSID for roaming10:50
longsleephehe all right10:50
ogra_(using the same SSID for all and have them send roaming info to the client about strenght etc)10:51
longsleepogra_: mhm so you say i should avoid using a wpa config file mhm - not sure - then i need a way to store multiple ssid/password combinations some place else and apply them from some place else10:51
ogra_but thats sadly an AP feature you dont find in the home user HW10:51
longsleepright, and only works for a single logical network10:52
ogra_yeah10:52
* longsleep thinks wpa-confi option is the way to go for everyone10:52
ogra_nah10:52
longsleepsnappy even shipts wpa_passphrase to create it10:52
longsleep:)10:52
longsleep-t10:52
ogra_nmcli via snappy config from your oem snap is the way to go10:52
longsleepnmcli oh my10:53
* longsleep was hoping to avoid that10:53
ogra_once there is a NM framework we ship by default10:53
ogra_NM offers evereything we need for GSM, LAN and WLAN10:54
ogra_and whatever else10:54
longsleepdoes NM also offer link detection? I added a new comment to https://bugs.launchpad.net/snappy/+bug/1498631/comments/10 yesterday, as dhcp is running forever even if there is no link on eth010:54
ubottuLaunchpad bug 1498631 in Snappy "Snappy waits 2 minutes while booting if eth0 is not connected" [High,In progress]10:54
ogra_yes, it should10:54
longsleepNow the waiting is fixed with the release from yesterday but the dhcp keeps running and running10:55
ogra_(plug a cable into your laptop ... it will DTRT)10:55
longsleepoh, i did some brief research about ifplugd and and did not like it very much10:55
ogra_is that dhclient ?10:55
longsleepyes dhcclient is started for eth010:55
longsleepno matter if plugged or not10:56
ogra_that should have a timeout option we can add i think10:56
longsleepmhm but what when you plug it after that timeout was reached?10:56
ogra_i think -1 ...10:56
longsleepthat is there10:56
ogra_but that will only make it try once10:56
ogra_oh10:57
ogra_it should try only once for the duration of the timeout that was defined in dhclient.conf10:58
longsleepmhm it does have some kind of interval10:58
ogra_(RaspberryPi2)ubuntu@localhost:~$ grep ^time /etc/dhcp/dhclient.conf10:59
ogra_timeout 300;10:59
ogra_so it should stop after 5min10:59
longsleepNo working leases in persistent database - sleeping.10:59
longsleepand after some time it will try again10:59
longsleepok maybe i was not patient enough10:59
longsleepnope its not me11:00
longsleepit just started again11:00
longsleepogra_: 10:54:53 sleeping11:01
longsleepogra_: 11:00:33 DHCPDISCOVER11:01
ogra_uhm11:01
longsleepi did nothing with that device in the meantime11:01
longsleepjust journalctl11:01
ogra_pitti, any idea why that happens ? "dhclient -1 <iface>" should not make it restart, no ?11:02
ogra_or i'm reading the manpage wrong ... sounds like a bug11:02
longsleepogra_: well then i am reading the manpage wrong as well11:03
longsleepogra_: exit with code 2 :)11:03
ogra_right11:03
dakerhi, anyone with some snappy/Ubuntu Core presentations ?11:03
longsleepi am out for lunch now, i will dig more on this later11:04
ogra_daker, i know sergiuens held a talk, but i dont know where his slides are ... (and he is off until tomorrow)11:04
dakerogra_: ok, i will ask him tomorrow11:05
Chipacahttp://summit.ubuntu.com/ubuconla-2015/meeting/22539/hola-snappy/11:05
Chipacaogra_: ^ that one?11:06
ogra_oh, right11:06
ogra_you might need to pipe it through skype though to get it in a sane language11:07
ogra_*g*11:07
dakerChipaca: thanks11:07
svijdaker: depending on your language, here's another one in not-english: https://speakerdeck.com/svij/snappy-ubuntu-core11:08
dakersvij: thanks!11:08
ogra_ppisati, err ... why do we default to "powersave" in the kernel config, thats really bad ... (first: that makes booting slow, second: we have a userspace job that forces it to ondemand after boot)12:09
ogra_can we please set this back to performance by default so the boot doesnt get slowed down =12:10
ogra_?12:10
ogra_(we can discuss making the usespace job configurable to then default to powersave after boot or some such)12:11
* Chipaca goes to lunch, while pondering the genius of http://bennyhillthis.com/12:19
longsleepogra_: so the dhclient is still trying to get an address for the not connected eth0, so i think we can say that it does not stop12:30
ogra_longsleep, right, i think thats a bug .... seems pitti didnt see my ping above :)12:32
pittiogra_: I didn't get to it yet; sorry, being flood-pinged12:32
ogra_i would expect it to stop doing that if -1 is used and a timeout is set in dhclient.conf12:32
longsleepok let me add it to the tracker then12:32
ogra_perhaps something external restarts dhclient and doesnt respect "exit 2" though12:33
longsleepogra_: no, the pid of that dhclient did not change since 2 hours12:33
ogra_wow12:34
ogra_yeah, then it sounds like dhclient doesnt even exit12:34
pittiI didn't follow scrollback, but -1 doesn't (seem to) be "try once and immediately exit", just "try once" (as documented)12:34
pittiso it might stay around until it actually succeeds?12:34
longsleepyet it stays around and flodding logs all 5 minutes with DHCPDISCOVER on eth0 lines12:35
longsleeps/yet/yes12:35
ogra_pitti, well, the manpage says it does try once for the duration of the timeout thats defined in dhclient.conf12:36
pittiso that sounds like a bug then12:36
ogra_and then it does an "exit 2"12:36
longsleeplet me add a new bug separate from 149863112:37
* pitti runs "sudo dhclient -1 -v -i lxcbr0" (which can't succeed) and lets that sit for 5 mins12:37
* pitti gets grumpy, changes timeout to 30s and re-runs12:38
longsleephehe12:38
pittiwhat kind of ridiculous default is "5 mins" anyway12:38
pittiwe live in an impatient world :)12:39
pitti5 mins == broken12:39
pittiNo DHCPOFFERS received.12:39
pittiand exits with 0 (!) after 30 s12:39
longsleepMaybe its only with a lease file?12:39
longsleepAfter No DHCPOFFERS received it logs No working leases in persistent database - sleeping.12:39
pittiI do have a /var/lib/dhcp/dhclient.leases12:39
pittiright, I get the same12:40
longsleepmhm12:40
pitti      Old leases are kept around in case the DHCP server is unavailable when  dhclient12:40
pitti       is  first  invoked  (generally during the initial system boot process).  In that12:40
pitti       event, old leases from the dhclient.leases file which have not yet  expired  are12:40
pitti       tested,  and if they are determined to be valid, they are used until either they12:40
pitti       expire or the DHCP server becomes available.12:40
ppisatiogra_: powersave is our default on every kernel/arch12:40
pittiso that sounds plausible12:40
ppisatiogra_: how much do we gain in boot time going to performance?12:40
longsleepmine does not exit - the pidfile got created at 10:25 utc and it still has that pid12:41
pittilongsleep: so does it log that it's re-using old leases then?12:41
longsleeppitti: no there are no leases12:41
longsleep(lease file is empty)12:41
longsleepits the first boot actually, and it never had a link on eth012:41
ogra_ppisati, a few seconds !12:42
ogra_ppisati, who decided to drop performance in our main kernels ?!?12:43
ogra_thats an essential boot speed bit12:43
ogra_(worked out around lucid by keybuk)12:43
ppisatiogra_: let me check12:43
pittiCONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y12:44
ogra_phew !12:44
pittiwe still have that in wily's amd64 kernel at least12:44
pittiis that different on other kernels?12:44
ogra_seems like12:44
ogra_well, in snappy kernels12:44
pittiand /etc/init.d/ondemand should change it to something else after 1 min12:44
ogra_yeah12:44
ogra_we want full CPU and IO throughput until we are booted12:45
ogra_and after that switch to ondemand12:45
ogra_if we want to switch to something else in snappy thats fine, but only after booting please12:45
pittiFWIW, needing something like /etc/init.d/ondemand seems silly; I'd have thought the kernel's default scheduler would be clever enough by now12:45
pittiI mean, even with ondemand/powersave it should go to full CPU if there's load; doesn't it?12:46
ppisatipitti: yep12:46
ppisatipitti: it just tries to go down quicker12:46
pittippisati: right, I'm not advocating to keep "performance" all the time; I'm just asking why "ondemand" all the time is worse12:47
pittiif there is demand (and there obviously is during boot) it should certainly be as fast?12:47
ppisatiogra_: i was wrong, the default is still PERFORMANCE12:48
ogra_i think keybuk found that it takes a bit to scale up12:48
ogra_ppisati, good12:48
ppisatiogra_: tough in that rpi2 kernel was powersave12:49
ppisatiogra_: let me check another thing12:49
ogra_pitti, so you run without full performance for a second or two during boot12:49
Chipacajdstrand: ping12:49
ppisatihere it is12:49
ppisatiarch/arm/configs/bcm2709_defconfig:CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y12:49
ogra_which costs precious CPU throughput at a point where you dont want to lose it12:50
ppisatiogra_: that was the default governor from the rpi config12:50
ogra_ppisati, oh, please change that asap12:50
ogra_we want ondemand after boot and performance during boot12:50
ppisatiogra_: let me check 4.212:50
ogra_now i understand why it boots so sluggish12:50
ppisatiogra_: and i'll push a a new kernel for 3.1912:50
Chipacajdstrand: https://code.launchpad.net/~chipaca/snappy/auth/+merge/27368312:50
ogra_ppisati, why ? we dont use 3.19 anywhere anymore :)12:51
ogra_snappy is 4.2 everywhere since last image12:51
ppisatiogra_: i'm still using it :)12:51
Chipacajdstrand: marked "work in progress" because i still need to add code that uses it, but that's the crypto bits done for your guys to take a look12:51
longsleepppisati, ogra_ : Added the dhcp issue as bug #150368012:51
ubottubug 1503680 in Snappy "dhclient for eth0 does never exit and retries dhcp foerever" [Undecided,New] https://launchpad.net/bugs/150368012:51
Chipacaoh, drat, prerequisites12:52
ogra_and in snappy we run cloud-init during boot *before* the ondemand governor is used ... and cloud-init is python ... which is ultra slow on ARM in itself12:52
ogra_longsleep, thanks !12:52
Chipacajdstrand: https://code.launchpad.net/~chipaca/snappy/auth/+merge/273684 <- fixed prereq's12:52
ppisatiCPU_FREQ_DEFAULT_GOV_PERFORMANCE=y is the default on 4.2 rpi2 too12:56
ppisatiso it was just a 3.19 thing12:56
ppisatiogra_: when you were referring to slowness, did it apply to 4.2 too?12:57
ppisatiogra_: because it's correct there12:57
ogra_ppisati, i didnt measure it recently ... in my initial images it was really slow (1-2min to boot) .... with the last image i mostly booted remote12:58
ogra_i have to prepare a new rpi image this week (nobody told me we'd release a new stable one this week, i thought that was planned for teh 17th)12:58
ogra_i'll do some stopwatching :)12:59
ppisatiogra_: cool12:59
longsleepany reason why opencryptoki is in ubuntu-core stable? I just added bug #150368113:00
ubottubug 1503681 in Snappy "opencryptoki.service fails to start" [Undecided,New] https://launchpad.net/bugs/150368113:00
ogra_longsleep, weird, thats fixed13:01
* ogra_ wonders if mvo did test on all ARM arches before doing that rushed release yesterday :/13:01
longsleepmhm the image i created yesterday has it installed13:02
ogra_longsleep, its a duplicate in any case, let me find the bug13:02
ogra_https://bugs.launchpad.net/snappy/+bug/150002013:02
ubottuLaunchpad bug 1500020 in Snappy "/var/lib/opencryptoki needs to be in /etc/system-image/writable-paths" [Undecided,New]13:02
longsleeplet me compare it13:03
ogra_ah, and i didnt milestone it so that mvo could have found it because asac didnt create a milestone13:03
jdstrandChipaca: ok, I added it to the card13:03
ogra_i fixed it in wily13:03
mvoogra_: I ran on bbb and did not touch raspi13:03
jdstrands/to the/to a/13:03
Chipacajdstrand: g'morning :)13:03
jdstrandChipaca: hi!13:03
mvoogra_: oh, in a meeting right now, but I can check right after that13:03
ogra_mvo, right, but there are plenty bugfixes missing seemingly ... i asked asac for a milestone and he missed creating one during the sprint13:03
ogra_so the open bugs are all not milestoned13:04
jdstrandChipaca: it will likely be a couple of days-- sarnold is swamped with other reviews13:04
jdstrandChipaca: hey, do you know who implemented socket* and listen-stream?13:04
ogra_mvo, but therer are some regressions due to stuff that was added for amd6413:04
Chipacajdstrand: the chipacacentric worldview is disappointed13:04
Chipacajdstrand: mvo iirc13:05
jdstrandok thanks13:05
jdstrandmvo: I know you're in a meeting. after the meeting when its convenient, can you ping me re socket* and list-stream?13:05
jdstrandlisten*13:05
longsleepogra_: i see, well the comment says that the writable path should be added, it has not been added for ubuntu-core 6 - at least the one i got13:06
ogra_longsleep, yeah, thats broken13:06
longsleepogra_: ubuntu-core 6 has 0.6.15 of ubuntu-core-config - thats why - fixed in 0.6.2913:07
ogra_longsleep, thats correct, as i said there is a bunch of regressions that werent fixed13:07
ogra_(and vivid has 0.6.15, which is correct too)13:08
longsleepok good, so how can i close 1503681 as duplicate13:08
longsleepah found it13:09
ogra_longsleep, done13:09
longsleepok thanks :)13:09
mvoogra_: do you have bugs already for the regressions?13:17
mvojdstrand: ok, I will ping you13:17
ogra_mvo, i have to dig them up, bug 1500020 is definitely one13:17
ubottubug 1500020 in Snappy "/var/lib/opencryptoki needs to be in /etc/system-image/writable-paths" [Undecided,New] https://launchpad.net/bugs/150002013:17
ogra_i had three, i think i closed two of them already13:18
ogra_all regessions from the last additions of packages for the amd64 images13:18
ogra_we definitely need to improve our milestone process for bugs ... perhaps just create ten in advance in LP or so so that doesnt get forgotten13:19
mvojdstrand: back13:36
jdstrandmvo: hi!13:36
mvoogra_: yeah, this time the sprint made the timing really awkward13:37
jdstrandmvo: I am writing up some documentation and noticed the new socket* and listen-stream directives for services. can you give me a two sentence summary of the feature?13:37
jdstrand(just so we are on the same page-- I think I know what's going on from the docs, but I have followup questions)13:38
mvojdstrand: hm, it allows socket activated daemons with snappy13:38
mvojdstrand: the patch comes from kickinz1 for docker13:39
jdstrandI see13:39
mvojdstrand: I think its somewhat documented in meta.md13:39
jdstrandmvo: listen-stream says "The full path of the stream socket". is this a named socket?13:39
* jdstrand was looking at https://developer.ubuntu.com/en/snappy/guides/package-metadata/13:39
mvouh, its poorly documented in docs/meta.md - but at least its mentioned13:40
mvojdstrand: it can be both a path or a abstract socket with @foo13:41
mvojdstrand: or a port (haven't tested that though)13:41
jdstrandmvo: are there any checks to make sure that a named path falls within the app-specific directories? does the abstract socket use namespacing? (eg, if pkgname is foo, check that abstract matches @foo_...)13:42
mvojdstrand: its essentially what SYSTEMD.SOCKET(5) is doing13:42
mvojdstrand: no checks currently, no13:42
jdstrandok, so I can make some review tools checks for those13:42
jdstrandbasically, I'll say its ok if it matches the app-specific TMPDIR or SNAP_APP_DATA_PATH13:43
jdstrandand I'll do what I suggested for the abstract socket13:43
jdstrandmvo: does that sound reasonable?13:43
mvojdstrand: yes!13:43
mvojdstrand: thanks a lot!13:43
jdstrandok13:43
jdstrandnow, for the bit that really concerns me: socket-user and socket-group13:44
jdstrandwe don't assign UIDs or GIDs13:44
jdstrandhow are these supposed to work?13:44
mvojdstrand: welllllll they work for docker because there is  a docker user on the image, but they don't work for anything else right now13:45
jdstrandright13:45
jdstrandok13:45
mvoso maybe we should not expose that option while there is no way to add users ?13:45
jdstrandmvo: so I will just flag those if they are specified at all. when we support UID and GID per-snap (I was thinking this would be opt-in), we can check that it matches that13:46
mvomakes sense13:46
jdstrandmvo: clearly docker needs it. it is probably a doc change13:46
jdstrandeither don't expose it in the doc at all, or mention that it will flag a manual review13:47
jdstrandmvo: how about I add a bug for the review tools and add a snappy task to update the docs so there is a little more information?13:48
jdstrandmvo: and I'll submit an MP for that13:48
mvojdstrand: +113:48
jdstrandok. it won't be until the end of the week/next week13:49
jdstrandmvo: thanks for walking me through this13:49
mvothats fine! thank you!13:49
jdstrandmvo: can listen-stream to a relative path or just absolute path?13:52
mvojdstrand: I think it has to be absolute (which makes it interessting)13:54
jdstrandI can use current/13:54
* mvo nods13:56
jdstrandmvo: btw, it seems that snappy build still doesn't run the tools by default14:03
jdstrandmvo: I thought we agreed they should? note, I think the tools ppa needs to have a review tools upload for the recent 'architectures' changes14:03
mvojdstrand: let me check that, I was sure my branch got merged14:04
jdstrandmvo: maybe it is my local snappy that is out of date...14:05
mvojdstrand: no, you are right14:05
mvojdstrand: let me chase that14:05
jdstrandok, I'll work to get the updated review tools into the ppa. again, it'll be a couple days (doc writing)14:06
mvook14:07
=== rickspencer3_ is now known as rickspencer3
Chipacaelopio: mvo: https://en.m.wiktionary.org/wiki/husk15:16
Chipacaanyway, i suck at names, so i'm all ears15:21
elopioChipaca: call them "meta", that fixes everything :)15:44
Chipacameta.15:44
elopioI'm ok with husks actually (after the explanation of course). I would call that peel, but what do I know?15:45
Chipacaelopio: thinking about it, hollejo is not the right word. Hollejo is the white thing under the orange skin and before the "gajos", for example15:47
Chipacaelopio: you know what chala (as in "humita en chala") is? that's a husk15:48
Chipacathe outer, leafy covering of corn is the husk15:48
Chipacaand you remove a husk by husking, which would've made it more confusing in code so i called it 'load' :-p15:49
elopioumm, yes. I think my mother calls hollejos the calluses in the fingers. I'm sure I've heard that somewhere, but not entirely sure where.15:49
elopiono, chala makes it worst. I've only heard chala rasta. I think they are from argentina. Not sure either.15:49
Chipacahttps://upload.wikimedia.org/wikipedia/commons/1/13/Humitas_en_chala_tipicas_de_Argentina8.JPG15:50
Chipacammmmmmmmm15:50
Chipacanow i want some15:50
elopioChipaca: you should write a husker interface, and propose it for golang upstream. I'm sure you'll be famous.15:50
* Chipaca mumbles incoherently and gets back to work15:51
elopioI think we call the "chalas of the corn" just "hojas".15:53
elopioand humita is something like tamal de elote.15:53
* elopio goes for breakfast.15:53
mvoChipaca, elopio I still like something about lighweightThing, that makes it realtively easy to parse (although its a bit long :/15:54
* mvo gets dinner15:54
Chipacayep, long, is why i said maybe just use lightweight15:54
Chipacaelopio: re-review https://code.launchpad.net/~chipaca/snappy/systemimage-exported-consts/+merge/273479 if you get a moment please15:55
elopioexuvia15:56
elopioI doubt we can fix it, but I'm sure we can make it worst :) https://en.wikipedia.org/wiki/Exuvia#/media/File:Euscorpion_exuvia_2.jpg15:56
Chipacaexuvia works for me, but i thought it was a bit offbeat :)15:57
Chipacalove magicicada exuviae stuck to trees15:57
elopioChipaca: approve, needs commit message.15:57
Chipacaon it15:58
Chipacamvo: wrt https://code.launchpad.net/~chipaca/snappy/removed-pkg/+merge/273481, renamed it to RemoteManifestPath, want to take another look?16:08
Chipacamvo: otherwise i'll top-approve :)16:08
Chipacaelopio: i didn't know exuviae is also another word for booty. +1 to exuvia.16:19
elopioI didn't know that either. I've learned so much today!16:20
matiasbhi there! quick question, if I'd want to get some review outcome for a snap package (uploaded to store, triggered manual review during auto-review), who should I ping?16:25
elopiomatiasb: I don't understand. You want to cause your snap to trigger a manual review?16:27
matiasbelopio, nop, I submitted a package (a real one!), but it requires manual review, so I'm waiting for it (for a few days now)16:28
elopiomatiasb: ah, generally it's Sergio who reviews them.16:29
elopiohe's back tomorrow.16:29
matiasbelopio, ah, ok, thanks :)16:29
elopiobeuno: can you give me permissions to look at the review queue?16:30
beunoelopio, they are rarely handed out. What for?16:40
elopiobeuno: is there a staging I can look at? I just want to understand the process, and do some exploratory tests with snaps that require manual review.16:42
beunoelopio, they are the same ACL list. The process is: run the security scripts (lp:click-reviewer-tools), if they fail they get rejected. You can re-request a manual review, and someone clicks a button16:48
elopiobeuno: ok, that works. matiasb is your source public? I would like to see the click-reviewer-tools failure in your branch.16:49
beunoelopio, click-reviewer-tools is public, the rest isn't16:50
matiasbelopio, I packaged transmission, so sources are public; re the errors, I can share a paste with them, but they are related to the fact that I had to tweak the default security profile16:51
elopiomatiasb: w00t for transmission.16:51
elopiomatiasb: yes, please paste the error. I'm just curious. I've just reviewed a branch with a test for the reviewer-tools and want to learn more about it to add more tests.16:53
matiasbelopio, http://paste.ubuntu.com/12706117/16:53
elopiothank you.16:53
matiasbelopio, np, it doesn't say much, it complains I'm changing the sec profile :)16:54
matiasbI couldn't find another way to work around that16:55
Chipacamatiasb: wrt tweaking security profile, that's usually a "talk with jdstrand"16:58
Chipacamatiasb: and he, too, can do manual reviews, specifically for this scenario :)16:59
matiasbChipaca, got it, thx; so, when jdstrand is around to take a look... :)17:02
Chipacamvo: so, for when you return: 1. leave husk/Husk; 2. exuvia/Exuvia; 3. package lightweight, type PartList17:02
Chipacamvo: husk.Byname -> lightweight.PartListByName, husks.All -> lightweight.AllPartLists17:04
Chipacamvo: all others end up waaay too long imho :)17:04
=== chihchun is now known as chihchun_afk
jdstrandChipaca, matiasb: fyi, unless the app comes from a trusted vendor, we don't allow security-override or security-policy in the public store (a private store could allow it). having the source open is great, but the snap may not have been built from that source17:19
jdstrandmatiasb: how extensive are the policy edits? perhaps they are bugs in the templated policy?17:19
Chipacajdstrand: dude, we don't do "bugs".17:20
Chipacathey're miscomprehended teenager features17:20
matiasbjdstrand, understood; I had to add a few extras to the default templates, as specified in the comment there, happy to workaround if possible17:20
jdstrandmatiasb: looking at what you put in the review, we could allow /proc/sys/kernel/random/uuid17:22
jdstrandmatiasb: we can't allow mounts (info leak)17:22
jdstrandmatiasb: and quotactl is potentially dangerous too. you should probably patch transmission to not need mounts and quatactl17:23
matiasbjdstrand, ack, got it; I'll take a look and check if that's possible17:24
nessitajdstrand, silly question, how would transmission workaround usage of quotactl since it needs to know if there is free space in disk to keep (or not) downloading torrents?17:24
matiasbjdstrand, so I guess I will let you know if I can fix that, thanks17:25
nessitaah, perhaps free disk space can be checked with other libraries17:26
Chipacanessita: because snappy doesn't (yet? evar?) support quotas, just checking df is probably enough17:27
ogra_would df work ?17:27
ogra_(i guess it also needs access to /proc/mounts)17:28
jdstrandmatiasb: the simplest would be to not perform that check at all. perhaps there is an actual alternative solution.17:28
nessitaChipaca, got it, thanks17:29
ogra_(i mean, perhaps something like "df ." doesnt need it, never tired)17:29
matiasbjdstrand, probably, didn't review the sources in detail, but I guess it should be possible to work something out17:29
Chipacaogra_: df . does need it :(17:30
ogra_ah, sad17:30
Chipaca[101896.479363] audit: type=1400 audit(1444238994.246:13): apparmor="DENIED" operation="open" profile="hello-world.canonical_env_1.0.18" name="/bin/df" pid=1531 comm="env" requested_mask="r" denied_mask="r" fsuid=1000 ouid=017:30
ogra_that is actually quite a drawback, i can imagine a lot usecases where apps would want to know the free space in SNAP_APP_DATA_DIR17:31
Chipacamaybe there's a way to allow just that?17:31
ogra_i doubt any available tool can do that without /proc/mounts or at least without accessing info about the underlying disk SNAP_APP_DATA_DIR lives in17:32
ogra_i could be wrong though17:32
jdstrandLog: apparmor="DENIED" operation="open" profile="hello-world.canonical_sh_1.0.18" name="/proc/3814/mounts" pid=3814 comm="df" requested_mask="r" denied_mask="r" fsuid=0 ouid=017:33
ogra_yeah17:33
jdstrandwe need an out of process service17:33
jdstrandthen we could allow talking to it17:33
ogra_snappy freespace17:33
jdstranddf isn't in the policy now cause it needs /proc/*/mounts17:33
jdstrandwell, not snappy17:34
ogra_"SNAP_APP_DATA_DIR has 1254MB free"17:34
jdstrandapps can't use snappy :)17:34
ogra_oh, indeed17:34
jdstrandsnapd maybe17:34
jdstrandanyhoo, something our of process17:34
jdstrandout*17:35
jdstrandogra_: hey, I have a couple of questions while I have you17:35
* jdstrand pulls them up17:35
ogra_note that i'm not officially here :P ... but shoot17:35
jdstrandthese are actually community type questions17:36
jdstrandogra_: but please don't let me distract you from life :)17:36
ogra_well, i'm on sick leave til tomorrow ... but pretty bored so just ask17:36
Chipacajdstrand: that's ogra's way of saying, you've just got to make your questions more interesting that his alternatives17:38
jdstrandogra_: do you know if there is a way or if we plan to enable via snappy config ubuntu-core to setup remove logging? ie, tell rsyslogd to send its logs to another syslog server? /etc/rsyslog.d is not a writable-path and systemd's journal doesn't do rfc syslog17:38
jdstrandfor me personally, making /etc/rsyslog.d a writable-path would be sufficient17:38
ogra_lets do that theen17:38
jdstrandbut it sounds mildly interesting as an ubuntu-core config option17:38
jdstrandok, I'll file a bug17:38
ogra_sounds like something thats helpful in IoT cases and such17:38
ogra_(and the fix is easy enough)17:39
jdstrandogra_: next question. I tried to setup a static ip via snappy config ubuntu-core, and was successful. however, I didn't know how to setup the resolver. is that possible?17:39
ogra_there are /e/n/i options (dns-servers ?) you should be able to use17:40
* ogra_ checks his static snappy server 17:40
jdstrandoh, dns-servers are in there? I read the man page, I must've missed it17:40
ogra_(amd64)ogra@aleph2:~$ grep dns /etc/network/interfaces.d/eth017:41
ogra_dns-nameservers 8.8.8.817:41
jdstrandyeah, man interfaces doesn't have it17:41
ogra_yeah, seems to work here17:41
jdstrandok, awesome :) that probably needs a doc update for snappy config...17:41
jdstrandI'll file a bug on that too17:41
ogra_well, thats not snappy specific ... i think it is resolvconf that uses it17:41
jdstrandright17:42
jdstrandbut my point it, it wasn't in 'man interfaces' either17:42
jdstrandso I had no way to discover it17:42
ogra_right, if we added it we should have patched the manpage17:42
ogra_ah, wait17:43
jdstrandcause it wasn't there or a snappy example. there is a snappy example for static ip (which I used), but it doesn't include dns-nameservers17:43
ogra_man resolvconf has it17:43
jdstrandwhich meant I got an ip address great, but couldn't do much17:43
ogra_yeah17:43
ogra_we should add it to the example17:43
jdstrandI'll file a bug17:43
ogra_thx17:43
jdstrandnext question: is there a way to setup the ntp servers?17:44
ogra_hmm17:44
jdstrandthey seem to try to reach out to the pool ones17:44
jdstrandwith no way to point to an internal one17:44
jdstrands/internal/another/17:44
* ogra_ reads /etc/network/if-up.d/ntpdate17:44
* jdstrand doesn't have that file on latest snappy stable17:45
ogra_/etc/default/ntpdate17:46
ogra_oh ?17:46
ogra_do we already have timedated ?17:46
jdstrandI don't have /etc/default/ntpdate either17:46
jdstrandsystemd+   488  0.0  0.0 100276  2532 ?        Ssl  Oct06   0:01 /lib/systemd/systemd-timesyncd17:46
jdstrandis that the same thing?17:47
ogra_no, thats the new thing17:47
ogra_which i dont know much about yet17:47
ogra_ah17:47
ogra_it has a -H <host> option17:47
ogra_now i'm not sure where to configure it ...17:48
jdstrandI guess that is /etc/systemd/timesyncd.conf17:48
jdstrandhttp://www.freedesktop.org/software/systemd/man/timesyncd.conf.html17:48
jdstrandbut it is not a writable-path17:48
ogra_so we need to add that one too17:48
jdstrandok, I'll file a bug for that too17:48
ogra_yeah, seems you can just set NTP=17:49
ogra_pointing to a server17:49
jdstrandthe last is sshd_config. it *is* a writable path. I'm just curious if there are plans to do more with it via snappy config17:49
ogra_that i dont know :)17:50
ogra_wouldnt be hard to add i guess17:50
jdstrandwell, I'm not trying to create more work17:50
ogra_it is riteable because cloud-init generates the keys in that dir17:50
jdstrandeven though I did. though just barely :)17:50
ogra_well, useful work ... everything you asked about is valid :)17:51
jdstrandcool and thanks-- this was quite helpful17:51
ogra_:)17:51
* Chipaca adds df to the rest api17:51
jdstrandogra_: hope you feel better and try not to be too bored :)17:51
ogra_i'm fine, i had drilled some screw anchors into my jaw last thu ... recovery is in the last stages17:52
* Chipaca watches the rest api get in a race with systemd for what's left of posix17:52
ogra_we should fork systemd to systemd-posix17:53
ogra_;)17:53
ogra_seems forking is in fashion currently17:53
* ogra_ just saw the news about mjg5917:53
* ogra_ goes back to icepack->cheek18:00
Chipacajdstrand: ogra_21:15
Chipaca(amd64)ubuntu@localhost:~$ hello-world.env21:15
Chipaca/writable has 368392 blocks of 4096 bytes available (~93.390998%)21:15
Chipacajdstrand: ogra_: http://pastebin.ubuntu.com/12709065/21:16
Chipacaoh, also matiasb ^21:16
matiasbnice!21:17
matiasbChipaca, how can I use that?21:17
* matiasb looks the pastebin21:17
Chipacamatiasb: gcc -D_GNU_SOURCE -Wextra -Werror -o /tmp/fakedf /tmp/fakedf.c21:17
matiasbChipaca, awesome, will try it when I get a few21:18
Chipacamatiasb: then, fakedf $SNAPP_APP_DATA_PATH21:18
Chipacaor fakedf $SNAP_APP_USER_DATA_PATH21:19
Chipacas/SNAPP/SNAP/ soz21:19
Chipacaand apparently that's enough :)21:19
Chipacamatiasb: also python has statvfs which is the same call, if you're doing python21:19
matiasbChipaca, this is for transmission, so C should be21:20
Chipacamatiasb: and man 3 statvfs for the fields in the struct if you need some other info21:20
matiasbChipaca, perfect, thx!21:21
Chipacanp21:21
Chipacamaybe we should ship this :)21:21
Chipacahah! we already do21:37
Chipaca/usr/bin/stat21:37
Chipacajdstrand: ogra_: (dunno if you're still interested in this, but) e.g. “/usr/bin/stat -f -c "%a * %s" /writable/”21:41
jdstrandChipaca: oh, nice! :)21:43
Chipacamegabytes: echo $(($(/usr/bin/stat -f -c '%a * %s/1024/1024' /writable/)))21:43
* jdstrand add a note to update snappy-security to recommend that21:43
* Chipaca stops21:43

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!