[00:53] Just tried packaging my first app for snappy (well second if you count the hello world app) and when I run it in my snappy vm I'm getting a permission denied error on /tmp/snaps. I didn't see where I'm suppose to declare this permission, is this something I can do or do I need to try to tell the app to use some fake tmp in /var/apps/myapp/? [00:55] just found this, which I think might be what I need https://developer.ubuntu.com/en/snappy/guides/security-policy/ === erkules_ is now known as erkules [08:04] Good morning all; happy Friday and happy Don’t Fry Day! 😃 [08:21] mvo: fyi, i did a hard backout of the convenience change you landed in go-example-webserver [08:21] not sure if you want to bring it back, but if so, please test that the package still works afterwards :P [08:23] asac: oh, sorry for that and thanks for fixing [08:27] mvo: i think it should have been a -n ? [08:28] mvo: it failed to start with this :) [08:28] because EOF tries to write a temp file it seems [08:29] thats confusing, once I finished my branch here I will checks whats going on, looks ok from a first glace but certainly is not :/ [08:29] mo'in [08:30] mvo: we have many bugs around tempdirs [08:31] hey Chipaca [08:31] Chipaca: meh, more? [08:32] Chipaca: or more of the same and we need to land your fix urgently? [08:32] mvo: well, that "can't create here document" or whatever the error message was is one [08:32] mvo: my fix is not necessary; merely sufficient (?) [08:32] (i kid; it's not even that, there's more work to be done to fix it still) [08:33] mvo: bash creates its tempfiles in TMPDIR [08:33] oh, meh [08:33] mvo: our systemd units are not creating their tempdirs [08:33] right, lets land your fix urgently [08:33] mvo: my fix needs work on other fronts [08:33] mvo: to be more exact: [08:34] mvo: a snappy branch to change TE?MPDIR [08:34] mvo: and a branch to ... apparmor? simpleprof something, to let things write to /tmp/ [08:34] hm, if thats the case, is there anything else we can do? something cheap that just creates the dir in the unit? [08:34] as currently it's only able to write to /tmp/snaps/yadda [08:34] right [08:34] mvo: webdm creates it itself, from its init script [08:35] mvo: it had a bug, where it wasn't setting it 01777 [08:35] so other things failed after [08:35] yeah, I noticed that, I wonder if we could generalize that until the proper fix is in place [08:35] mvo: i'm not really sure that'll work for things that aren't as privileged as webdm though [08:35] i mean, by the time that runs it's already contained, right? [08:36] even the easy fixes involve either regenerating the unit files, or telling people to do so (by de/reinstalling) [08:36] Chipaca: I think we can run pre-start unconfied [08:36] re-generating> good point [08:36] ah, that would work [08:36] so proper fix sounds like the right plan of attack [08:36] so 'tis a bit of a mess [08:37] the only problem is that, because the "right" fix touches so many packages => lots of SRUs [08:37] (yay) [08:37] well, its not *too* terrible, we could also just create /tmp/snappy/snapname in your branch [08:38] I think we actually have to :/ [08:38] because we would have to re-generate unit files/exec files otherwise that already set TMPDIR [08:38] hah, inside the private tmp? [08:38] yeah [08:38] then its just one SRU (for now) and the other can follow as needed [08:38] mvo: also the apparmor profiles [08:38] well, we still want apparmor of course [08:39] to unblock the /tmp hardcorers^Whardcoders [08:39] so that's the three packages [08:39] oh, we'd avoid snappy [08:39] Chipaca: so plan of attack: add even more private /tmp/snaps/foo to private /tmp [08:39] do new image with that and all TMPDIR honoring people are good [08:40] then do apparmor to help the hardcoders [08:40] sensible? or am I missing something and need more tea? [08:40] TEMPDIR is not set for systemd [08:40] only TMPDIR [08:41] probably a bug in and of itself [08:41] aha, meh, ok. indeed [08:41] hmmmmm [08:41] I'm in favor of landing the launcher with the dir creation right away and then tackle the rest, that should already be a huge win [08:41] so, we'd look at TEMPDIR and create it, from the unprivileged section of the launcher [08:42] yep [08:42] land that, and TEMPDIR people are good, as you say [08:42] TMPDIR* [08:42] unless you have a different opinion, you looked into this way deeper than I did, I may miss something here [08:42] well, we need to look at either TMPDIR or SNAP_somethingsomehting [08:42] * mvo nods [08:43] i'd say TMPDIR [08:43] we just create all of them :) hopefully its just one [08:43] so we can nuke the SNAP_TEMPDIR or whatever later on [08:43] aha, good point [08:43] yeah, lets do that and just use TMPDIR [08:43] it will be set to SNAP_TEMPDIR anyway IIRC [08:43] yes [08:43] and TEMPDIR is set to TMPDIR also, when it's set [08:44] mvo: if we land https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 does anything break automatically? [08:44] i mean, is that put onto images directly? [08:51] Chipaca: if we upoad it to the PPA it can land directly, or we do the full SRU dance which will take longer [08:51] mvo: i asked because we don't want it to land automatically until we do the "create /tmp/snaps" thing [08:51] mvo: which i'd rather was a follow-up branch [08:51] this one is already starting to mature [08:51] Chipaca: ok, we can simply wait with the top-approve [08:52] good point [08:52] i've got a recursive mkdir in bzr history, will fish it out and propose the mp in a bit [08:52] \o/ === kickinz1|afk is now known as kickinz1 [09:10] i lied, i have _half_ a recursive mkdir of the sort we want [09:10] anyway, doing it [09:39] mvo: like so: https://code.launchpad.net/~chipaca/ubuntu-core-launcher/mktmpdir/+merge/259908 [09:43] Chipaca: yeah === retrack is now known as Guest87705 [10:42] Chipaca: I reviewed/merged/uploaded now, once that hits the PPA I will create a test image to verify that it all works [10:42] works for real [10:42] +1 [10:44] * mvo gets lunch while waiting for the image [10:44] * Chipaca -> coffee [11:02] Chipaca: hm, do you happen to have the bugnumber for the tmp issue ? if not I can try to find it [11:02] mvo: i don't [11:03] * mvo will find it [11:03] mvo: there is one? [11:04] Chipaca: *cough* now there is https://bugs.launchpad.net/snappy/+bug/1457839 [11:04] Ubuntu bug 1457839 in Snappy "TMPDIR not availalble for snappy services" [Undecided,New] [11:04] mvo: \o/ [11:15] mvo: cmp-test needing a commit message [11:33] * Chipaca curses at dirs.go === soee_ is now known as soee [11:50] * Chipaca is stuck [11:50] * Chipaca stops for lunch [12:13] mvo: you around? [12:15] Chipaca: yes [12:15] mvo: hiya. have you an opinion around the “Part” interface? AIUI the name wasn't well-loved [12:16] Chipaca: no strong opinion either way, I don't mind the name but if there is a suggestion for a better one I'm all ears :) [12:17] mvo: well, it's moving to its own package [12:17] or to the "pkg" pacakge [12:17] aha [12:17] and am wondering whether to leave it as pkg.Part, pkg.Interface, or something else [12:18] both is fine with me [12:18] maybe interface is indeed cleaner [12:18] morning [12:18] mo'in! [12:19] mvo: did you get to the bttom of this? "[ 18.214558] FAT-fs (mmcblk0p1): IO charset iso8859-1 not found [12:19] Chipaca: are we making the interface smaller? [12:19] sergiusens: no, not yet :/ [12:19] sergiusens: the Part interface? [12:19] mvo: I'm seeing it myself now too, after upgrading [12:20] sergiusens: wasn't in my plans, no [12:20] Chipaca: yeah [12:20] trying to focus on making snappy/* smaller [12:20] sergiusens: oh, nice. and you fall into a recovery shell? [12:20] Chipaca: just move first is all? [12:20] i get distracted too easily as it is :) [12:20] sergiusens: yeah [12:20] Chipaca: should I hold off on moving frameworks to /frameworks? [12:20] sergiusens: but if you think we should split it, that might make naming it easier [12:20] sergiusens: how would you split it? [12:20] Chipaca: let me check the interface [12:21] sergiusens: having tried again to split click/snappy out and failed (too big a branch), i'm working backwards and moving the interfaces out. that is, repository and part [12:23] i can just move them without renaming them too :) but where's the fun in that [12:27] Chipaca: heh, I can't think of any better way [12:27] Chipaca: except the minor thing of calling Uninstall Remove to match the leangua franca [12:27] sergiusens: heh [12:27] Chipaca: I would move out Frameworks though as only apps depend on frameworks [12:28] so it's too specific [12:28] ok, so i'll do snappy.Part -> pkg.Part, and snappy.Repository -> repo.Repository [12:28] Chipaca: and I'd rename SetActive to Activate (used for rollback/kick and switch) [12:28] let's see how that goes [12:29] easier to rename after move anyways [12:29] sergiusens: ack [12:29] Chipaca: how about s/Part/Package/ ? [12:29] sergiusens: and then it'd be pkg.Package ? [12:29] Chipaca: pkg.Interface ? :-P [12:29] mhmm [12:30] that was my original question, more or less :) [12:30] Chipaca: then pkg.Snap [12:30] on the other hand, pkg.Package would make the docs fun to write [12:30] sergiusens: there's already *two* other things we're calling snap [12:30] Chipaca: bummer [12:30] Chipaca: maybe pkg is the wrong name as well ;-) [12:31] fo sure [12:31] i chose it myself; it's got a p=.78 of being wrong [12:31] Chipaca: and maybe we need to remove other things from snappy and keep this stuff in there [12:31] sergiusens: yeah, i'm reating this and that as symmetrical [12:31] ie moving things out of snappy as the same as moving the complement out [12:32] at some point [12:32] maybe [12:32] Chipaca: I'd remove the complement out and use snappy.[Part|Package] [12:32] Chipaca: and complicate your life with the go pkg names you need to come up with :-P [12:33] sergiusens: at some point, webdm would be talking to a thing that just knew about interfaces (Part, Repository) and the toplevel install/remove/etc methods [12:33] Chipaca: even less; the restful api [12:33] and the nitty gritty would be tucked under pkg/ (or whatever that gets renamed to) [12:33] sergiusens: ok, so the restful api would be built on * [12:33] :) [12:33] Chipaca: hangout to design? [12:34] this chumminess is mind-splitting [12:34] sergiusens: https://plus.google.com/hangouts/_/canonical.com/de-sign?authuser=1 [12:48] Chipaca: http://dave.cheney.net/2015/05/12/introducing-gb https://walledcity.com/supermighty/building-go-projects-with-gb http://getgb.io/ [12:48] sergiusens: ta muchly [12:50] sergiusens: heh :) you keep seeling gb ;) [12:55] mvo: i'm sold already :) [12:55] mvo: but i'd lost that last link [12:56] turns out, living in the uk, searching for "gb" isn't too helpful [12:56] mvo: have you read about it yet? [12:56] and wouldn't you know, "go gb" isn't much helpfuler [12:56] Chipaca: I search for gb cheney ;-) [12:57] oooh, look at him, with his fancy search terms [12:57] sergiusens: yes, well, sort of - if I understand it correctly it means our repo grows by the size of our dependencies? or is there a shorthand way, i.e. gb.txt with link-to-repo,revno pairs? [12:59] mvo: it all goes in there, yeah [13:00] mvo: advantage is, you bzr branch lp:snappy; cd snappy; gb build [13:11] Chipaca, mvo: fyi, I had filed these before: bug #1449625 and bug #1448225 [13:11] Bug #1449625: systemd and bin-path exported variables are not in sync [13:11] Bug #1448225: webdm apparmor denials [13:11] bug 1449625 in Snappy "systemd and bin-path exported variables are not in sync" [High,Triaged] https://launchpad.net/bugs/1449625 [13:11] bug 1448225 in Snappy "webdm apparmor denials" [Undecided,New] https://launchpad.net/bugs/1448225 [13:11] Chipaca, mvo: the second is your services don't have a TMPDIR bug [13:12] jdstrand: those rules aren't in the policy yet? [13:12] i missed that [13:13] so, I discussed this yesterday [13:13] ruh roh [13:13] I long time ago when setting up TMPDIR, I said that apparmor will only allow the create of the version part of the TMPDIR [13:13] everything above it must be created by something else [13:14] ah, ok [13:14] that's fine [13:14] that's in the pipeline :) [13:14] now, I happened to not agree with having a versioned TMPDIR, but that is beside the point-- that was the decision taken [13:15] jdstrand: the unshare thing does away with the version, does a mkdtemp and uses that [13:15] yes [13:15] jdstrand: although we're creating the versioned one short-term for compat [13:15] so we don't have to change everything in stable [13:16] jdstrand: creating it in the unprivileged part of the launcher, that is [13:16] just before apparmor [13:16] (so whether it's *actually* unprivileged is arguable; it depends on whether it's called as root or not) [13:17] fyi, (some of) the discussion of the current implementation happened here: https://bugs.launchpad.net/snappy/+bug/1400320 [13:17] Error: ubuntu bug 1400320 not found [13:17] jdstrand: 404 for me too :) [13:17] * jdstrand makes said bug public [13:18] jdstrand: oh, thanks, I knew there was a open one but I didn't find it :/ [13:18] yeah, it was lumped in with another (that was fixed) and kinda hidden [13:19] ok [13:19] i'm assuming the bind sidesteps overlayfs [13:19] it does [13:20] so, what is the relationship being 'rolling' and 'devel', if any? [13:20] https://developer.ubuntu.com/en/snappy/guides/channels/ only discusses 15.04 and rolling [13:22] $ ubuntu-device-flash query --list-channels --device=generic_amd64 | grep core [13:22] ubuntu-core/devel [13:22] ubuntu-core/devel-proposed [13:22] ubuntu-core/rolling/edge [13:22] ubuntu-core/15.04/stable [13:22] ubuntu-core/15.04/edge [13:22] ubuntu-core/rolling/alpha [13:22] are devel and devel-proposed just historical and we shouldn't use them? [13:22] slangasek, mvo: ^ === vrruiz is now known as rvr [13:25] jdstrand: I think they are historic, but slangasek will confirm [13:26] ok, yeah, it doesn't have tha edge, alpha, etc bits in there. that makes sense if they are historical [13:31] mvo: thanks-- I'm trying to put together some docs for the security team for testing and update procedures [13:34] jdstrand: devel (not what you see in the channel listing) is what may become the name for rolling [13:34] mvo: fyi, https://wiki.ubuntu.com/SecurityTeam/PublicationNotes#system-image_updates_.28DRAFT.29 [13:35] sergiusens: can you clarify? [13:35] rolling is not set in stone yet? [13:35] in rolling stone :) [13:35] hehe [13:36] jdstrand: I think mark wanted to go with devel instead of rolling and we went with rolling as it was already like that in the store [13:36] sergiusens: oh? so rolling may get renamed - I knew why I said "maybe" :) [13:37] hehe [13:37] jdstrand: btw, did you have a chance to look into my question about $origin? [13:38] we should rename it to trolling [13:38] ok, so ubuntu-core/devel and ubuntu-core/devel-proposed may leave, then rolling may be changed to ubuntu-core/devel/edge, ubuntu-core/devel/alpha, etc [13:38] I'll just keep an eye on it and adjust as necessary [13:38] jdstrand: as in using the layout of "$pkgtype"s/$pkgname/$origin/$version (where package type is framework, app or oem? [13:38] jdstrand: correct [13:38] sergiusens: I didn't-- where was this question? [13:38] * jdstrand hasn't gotten to his inbox yet) [13:39] jdstrand: it was over irc, so maybe no inbox to check :) [13:39] jdstrand: the question in itself is getting the policies to know about $origin to map the paths in the template I guess [13:40] I was having connection issues yesterday. I don't see it... [13:40] sergiusens: can you state the whole question? [13:40] jdstrand: it was two days ago, but no worries [13:40] sorry, I missed it [13:41] I think I see it [13:41] not the question, but can infer from backscroll [13:41] (here) [13:41] so the basic idea is you'd like to split up apps, oem snaps and frameworks [13:41] jdstrand: I'm going to start storing the origin of packages locally, initially we went with pkgname.origin for everything and slowly close to release we dropped it for frameworks and oem packages [13:42] ok, so there are two parts [13:42] jdstrand: the splitting is tangential and I guess it doesn't impact apparmor in any way [13:42] there is storing stuff in pkgtype [13:42] and also storing origin in the path [13:42] the splitting is not tangential and does affect apparmor [13:42] well, it may be tangential [13:42] but it does affect apparmor [13:43] jdstrand: right, there are two problems is what I wanted to say :-) [13:43] so we'd have to coordinate that change as well [13:43] that one is not particularly difficult or contentious [13:45] why are we adding origin back for frameworks? a quality of frameworks is they can't be forked and adding the origin to the path complicates/muddies apparmor policy and makes it difficult for apps depending on the framework to use the right path [13:45] jdstrand: we don't need it in the path [13:45] ie, /frameworks/docker.sideload vs /frameworks/docker.canonical [13:45] jdstrand: but it becomes hard to snappy switch the sideloaded version and the store one [13:45] what is owncloud supposed to use? [13:46] I'm confused. you said before you want "$pkgtype"s/$pkgname/$origin/$version" but just now said "we don't need it in the path" [13:47] jdstrand: sorry I meant the package name [13:47] jdstrand: the package name would still be docker, the path to the stored data would be different [13:47] sure [13:47] hmm [13:48] but then owncloud still doesn't know [13:48] /frameworks/docker/sideload vs /frameworks/docker/canonical [13:48] looking at https://developer.ubuntu.com/en/snappy/guides/config-command/ ... is there no way to do something like: "snappy config ubuntu-core hostname=foo" ? [13:48] jdstrand: so we need some mechanism like 'current' but for the package path [13:48] we could fix owncloud easy enough with a symlink [13:49] right [13:49] then that means that only framework policy is muddied [13:50] so, the policy itself could have: [13:50] /frameworks/docker/*/*/foo r, [13:51] but then there is still the issue of the framework policy filenames themselves (which are what reverse depends snaps use) [13:51] ie [13:51] jdstrand: two *, one for origin and the other for version? [13:51] ls /var/lib/snappy/apparmor/policygroups [13:51] docker_client [13:51] owncloud uses caps: [ docker_client ] [13:52] sergiusens: re '*', yes [13:53] sergiusens: we have to do that for testing-- ie, if kick inz1 sideloads the docker snap to test, if if has /frameworks/docker/canonical/ the sideload scenario breaks [13:53] I guess we could do: [13:53] /frameworks/docker/{canonical,sideload}/*/foo r, [13:53] that would be somewhat better [13:53] but you can see what I mean by things being muddied [13:54] assuming that was acceptable [13:54] there is still the filename in /var/lib/snappy/apparmor/policygroups [13:54] jdstrand: yeah, so the question is which is cleaner, doing this or treating sideloads as coming from the same origin (and if so, we may need to block freely sideloading for frameworks) [13:55] currently it technically isn't a problem because we aren't allowing multiple forks to be installed [13:55] but as soon as we have origin in the name, it is super slippery to say why don't we allow forks of frameworks? [13:56] I don't think we need to block freely sideloading frameworks [13:56] we are we protecting the user from his/herself? [13:56] jdstrand: I see your points; I'll give sideloading some more thought, but it's the only reason I see it usable for frameworks [13:57] s/his/him/ [13:57] jdstrand: that and something pointed out to me about symmetry directory, but that is not relevant :-) [13:58] sergiusens: so I'm not saying we *cannot* have origin in the path; I'm saying it's complicated [13:58] and it would need to be very carefully implemented and coordinated [13:59] but I've not been able to think of something that is wholly satisfying [14:00] eg, say we say the path is ok, and we assume that the policy content can be dealt with well enough, then it comes down to the path of the cap [14:00] jdstrand: sure, but if there is no use for it, I would rather not do it; we need to be able to cleanly update from 15.04 to $next in some way (won't be automatic) and have an upgrader that can translate all the changes that happened during rolling [14:00] we could install /var/lib/snappy/apparmor/policygroups/docker.canonical_client [14:01] and then tooling could be smart to know that 'caps: [docker_client]' actually means /var/lib/snappy/apparmor/policygroups/docker.canonical_client [14:01] but, then there is a disparity between what the user declares and sees on disk, and things get more complicated implementation wise [14:01] is there a snap for vim ? [14:01] om26er, no [14:02] om26er, i tried to make one once, but the restrictions back then made it rather impossible to use [14:02] ogra_, is it doable now ? [14:02] jdstrand: right, I'll table this for now [14:03] one thing we *cannot* do (based on all conversations up until now) is have apps say: "caps: [docker.canonical_client]" [14:03] we might be closer but i think you would setill need to break out of confinement [14:03] jdstrand: and see if I can play aroun a bit; and I agree, no docker.canonical_client is a hard req [14:03] that would solve almost everything (except sideloading, cause docker.sideload_client...) [14:03] *, it is a hard req [14:03] om26er, http://people.canonical.com/~ogra/snappy/snaps/ ... (not sure it still works though, thats rather old ... ) [14:04] but it is ugly, bad dev experience, etc, etc) [14:04] om26er, with that you can only edit files inside the /var/apps/vim.ogra/ dir though [14:04] sergiusens: ok, that's fine [14:04] (or /var/lib/apps ...) [14:04] jdstrand: I do have another topic... [14:04] sergiusens: I'm here to discuss more if you come up with something [14:04] jdstrand: do you know why we removed the origin from oem snaps? [14:04] ogra_, aah, heh thats pretty useful :p [14:05] heh [14:05] sergiusens: otoh, no-- I don't think that came from me. I do remember someone coming to the conclusion that "apps themselves are actually the exception, because they are the only thing that supports forks" [14:05] om26er, i guess you could add ~/bin to your PATH and just dump a vim into /home/ubuntu/bin for the moment [14:06] sergiusens: maybe something with config? (wild guess) [14:06] or hw-assign? [14:06] I can't recall [14:06] I think I only had one ear listening at the time cause I was working on 'bus-name' [14:07] om26er: fyi, there is supposed to be a 'comfy' snap at somepoint that will have all these types of tools [14:07] at some point :) [14:08] yes [14:09] jdstrand: ok, beuno was the one asking why, I'm fine with no switch/forks for oem snaps as they are special as well [14:09] jdstrand, that will be a help! [14:09] sergiusens: /me nods [14:10] sergiusens: I just don't remember [14:11] jdstrand: in the end, only "snappy apps" can be forked [14:11] yeah [14:11] and we need to figure out some clean way to sideload [14:12] ogra_, I'll try that. I am getting started so that eventually I could achieve some type of automation, including home brewed IoT ;) [14:12] simplest is to not allow a snap to be sideloaded at the same time as the one with the store [14:12] then do a symlink from pkgname -> pkgname.sideload [14:12] now, that is simple, but I've not thought it all through of course [14:13] or maybe the other way [14:13] yes, the other way is simpler [14:13] oem and frameworks don't have origin in their name [14:13] so you sideload, it still doesn't have it in the name, but then you have pkgname.sideload -> pkgname [14:14] but then, I don't know what we are trying to solve here [14:14] so best I not try to suggest an implementation :) [14:18] jdstrand: I have was to store the origin in the works that does not depend on mangling with the path [14:18] jdstrand: the only change that would affect apparmor in motion is the move of frameworks to their own dir /frameworks [14:18] sergiusens: perhaps dropping .sideload into the install directory? [14:19] or somewhere else that you could check [14:19] jdstrand: I don't want to mangle the install directory as that is the packagers area [14:19] /var/lib/snappy/sideloads/docker [14:19] that could even be a symlink to /frameworks/docker [14:19] these are obviously just otoh [14:19] jdstrand: jdstrand http://snappy.asac.ws:9001/p/dot.store [14:20] and yes, I agree not adding to install path [14:31] om26er: do you still have issues with snappy config? [14:33] sergiusens, no? might be someone else. [14:34] sergiusens, you mean me ? [14:39] ogra_: yes [14:39] sergiusens, well, is there any commandline way to use snappy config to set a value for a key ? [14:40] the doc doesnt show any [14:40] ogra_: you need to pipe/redirect in [14:40] bah, really ? [14:40] are you sure that I only have to insert the sd card on the beagle and boot to ubuntu? [14:40] now I have the serial cable, and it shows me that the board is booting in debian. [14:40] ogra_: or like this https://gist.github.com/sergiusens/8d4d2b99b2e5d87c7a50 [14:40] elopio, depends on the board (there are many beaglebones ) [14:40] elopio, some require you to hold down the S2 button to boot from SD [14:40] ogra_: beaglebone black rev C [14:41] elopio: sometimes you have to press and hold a micro switch (I had to on that model) [14:41] sergiusens, ugh, why did we make it so ugly [14:41] ogra_: I didn't design it ;-) [14:42] ogra_: I do want to improve it and want to talk to mvo about it eventually [14:42] * ogra_ would have expected something llike "snappy config key=foo" or "snappy config section:key=foo" [14:42] or some such [14:42] ogra_: that's what set is for, but for other things [14:43] ogra_: everything is a yaml is the mantra [14:43] yeah, thats awful for plain cmdline use [14:43] piping and sed'ing HERE docs around ... omg :) [14:55] ogra_: HERE? [14:56] http://tldp.org/LDP/abs/html/here-docs.html [14:56]