| === bigcat_ is now known as bigcat | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 06:56 |
|---|---|---|
| fgimenez | good morning | 07:17 |
| === kickinz1 is now known as kickinz1|lunch | ||
| Mikaela | "However, you can still switch channels at a later point using command line tools." from https://developer.ubuntu.com/en/snappy/guides/channels/ - how does that happen and shouldn't that page tell it? | 10:26 |
| ogra_ | Mikaela, i'm not sure that is still true ... usually the channel is defined in /etc/system-image/client.ini (or some such, writing from the top of my head) | 10:29 |
| Mikaela | having it only choosable during installation or image creation sounds a little difficult to me | 10:30 |
| ogra_ | it will definitely become easier to switch once we moved away from system-image ... | 10:31 |
| Mikaela | I see | 10:31 |
| ogra_ | ubuntu-core will just become a normal snap package | 10:31 |
| ogra_ | currently we use a mix of the phone technology and snaps ... once we fully moved to snaps a switch is easier ... | 10:32 |
| ogra_ | on the phone you would run: system-image-cli --switch=your/target/channel ... i'm not sure this works on snappy | 10:33 |
| ogra_ | dholbach, do you knwo where that line comes from ? i guess we should either provide the command how to switch channels or we should remove the line til we can | 10:37 |
| dholbach | ogra_, no idea | 10:46 |
| ogra_ | ok, on the RPi2 i have a hack that works apparently :) | 10:56 |
| ogra_ | sudo system-image-cli --switch=ubuntu-core/rolling/edge | 10:56 |
| ogra_ | sudo fw_setenv snappy_ab b | 10:56 |
| ogra_ | sudo reboot ... | 10:57 |
| ogra_ | that gets me into a rolling edge wily install | 10:57 |
| ogra_ | not sure how to manipulate the bootloader settings for grub to do the same on x86 though | 10:57 |
| Mikaela | do I understand correctly that rolling/<alpha|beta|rc> don't exist yet? I find only edge at http://cloud-images.ubuntu.com/snappy/rolling/core/ | 11:03 |
| ogra_ | rolling/alpha exists but has no images | 11:07 |
| ogra_ | http://system-image.ubuntu.com/ubuntu-core/rolling/ | 11:07 |
| Mikaela | ok | 11:07 |
| Mikaela | http://cloud-images.ubuntu.com/snappy/rolling/core/edge/current/core-edge-amd64-vagrant.box doeesn't seem to be working at the moment or at least I don't get terminal with vagrant, it gives warnings about connection timeouting after telling ssh address, username and password | 11:14 |
| ogra_ | utlemming, ^^^ any idea ? | 11:15 |
| Mikaela | https://paste.mikaela.info/view/d9157ee2 the warning repeats every few seconds | 11:17 |
| sergiusens | ogra_: Mikaela on ubuntu core it would eventually be 'snappy set [snap] channel=blah' | 11:19 |
| sergiusens | or something like that | 11:19 |
| Mikaela | ok | 11:20 |
| ogra_ | sergiusens, right, until then we should either provide a hack in the doc or remove that sentence though | 11:20 |
| ogra_ | interesting, after i force-switched my RPi to rolling/edge running snappy rollback hangs | 11:21 |
| sergiusens | ogra_: in theory, rolling/edge is not a channel | 11:21 |
| sergiusens | ogra_: the channel is edge | 11:21 |
| sergiusens | ogra_: and the release is rolling or 15.04 | 11:22 |
| sergiusens | ogra_: and switching between releases is not supported anymore | 11:22 |
| sergiusens | we have diverged | 11:22 |
| ogra_ | yeah, seems like ... | 11:22 |
| ogra_ | top shows a hanging cp process | 11:22 |
| ogra_ | serthe above seems to work fine though | 11:23 |
| ogra_ | sudo system-image-cli --switch=ubuntu-core/rolling/edge; sudo fw_setenv snappy_ab b; reboot | 11:23 |
| ogra_ | and i bet i can update it tomorrow too | 11:24 |
| ogra_ | just rollback seems to hang ... i dont get what it copies around there though | 11:24 |
| ogra_ | OH !!! | 11:27 |
| ogra_ | it actually worked, it just took ages | 11:27 |
| * ogra_ tries to reboot | 11:27 | |
| === kickinz1|lunch is now known as kickinz1 | ||
| pindonga | hi, trying to figure out why a service is not automatically starting when I install a snap package, when running systemctl start myservice I see: Failed to start myservice.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files | 11:46 |
| pindonga | any ideas where to look for the root cause? | 11:46 |
| ogra_ | well, does your package ship policykit and run it ? | 11:47 |
| ogra_ | there is definitely no such thing in the rootfs | 11:48 |
| pindonga | ogra_, hi I didn't add it explicitely no, but I didn't think it'd need it | 11:48 |
| pindonga | the binary itself runs fine, it's only when starting the systemd service that's provided by snappy that it fails | 11:48 |
| pindonga | grepping for PolicyKit brings no hits anywhere | 11:50 |
| ogra_ | well, something tries to use a dbus service it seems ... policykit usually manages permissions for that | 11:51 |
| pindonga | ogra_, nothing in the binary uses dbus | 11:53 |
| pindonga | but the binary tries to access a device | 11:53 |
| ogra_ | no, but the systemd service most likely | 11:53 |
| ogra_ | ah | 11:53 |
| pindonga | /dev/lp0 | 11:53 |
| pindonga | actually, /dev/usb/lp0 | 11:53 |
| ogra_ | did you enable that with hw-assign ? | 11:53 |
| pindonga | but I shipped an apparmor policy with it, granting access to that file | 11:53 |
| pindonga | mhh, no, but shouldn't the policy file be enough for that? | 11:54 |
| ogra_ | i dont think so | 11:54 |
| ogra_ | https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ | 11:54 |
| ogra_ | see that guide | 11:54 |
| pindonga | ack, thx | 11:55 |
| zyga | jdstrand: hey | 12:56 |
| zyga | jdstrand: I'm wondering if something I have works okay by accident | 12:56 |
| zyga | jdstrand: or by desing | 12:56 |
| zyga | jdstrand: have a look at this strace please: | 12:56 |
| zyga | jdstrand: http://paste.ubuntu.com/12061478/ | 12:56 |
| zyga | jdstrand: there's a netlink socket and a ioctl that are allowed in the default security template | 12:56 |
| zyga | jdstrand: is that by desing? | 12:56 |
| zyga | design | 12:56 |
| Mikaela | If I understood askubuntu correctly, snappy has only one reporitory and you cannot add more. Will you be able to do that in the future? Thinking it more I also started wondering about mirrors, will everything always be downloaded from one server or will there be mirrors in every country like currently? Will snappy also have something to always decided the nearest mirror such as | 13:09 |
| Mikaela | http://mirrors.ubuntu.com/mirrors.txt or http://httpredir.debian.org/ | 13:09 |
| dholbach | sergiusens, mterry: do you have links to the slides of your snappy talks? | 13:10 |
| mterry | dholbach, https://docs.google.com/presentation/d/1qT2lrZkb7KA_CLyEGsKdE8U6AeGuhe_meakAeDHL2tQ/edit | 13:11 |
| ogra_ | Mikaela, as i understand it you will be able to have sub-stores in the main store, not sure what exactly the story is for local stores currently ... the prob here is that you cant really guarantee integrity if you allow decentralized stores ... the whole model revolves around the ability to do all security checks in a centra place | 13:12 |
| ogra_ | *central | 13:12 |
| ogra_ | what you can definitely do is have a central server that uses snappy-remote to push packages to all your systems in a LAN via scripts | 13:13 |
| Mikaela | and sub-stores are mirrors or PPAs? | 13:13 |
| ogra_ | snaps are PPAs ;) | 13:14 |
| ogra_ | (kind of) | 13:14 |
| ogra_ | i would see sub-stores more like topic based things for a certain product ... i.e. i sell a home wlan router with a snappy base and that router only sees my sub-store so i cant offer very specific apps that are tailored for my device | 13:15 |
| Mikaela | it doesn't sound like a good idea that you are only locked to Ubuntu's repositories to me, it reminds me a little of OS X and Windows. Will you still be able to install packages outside of repositories? And compiling is probably always surely possible? | 13:15 |
| ogra_ | yes to both of the latter :) | 13:16 |
| Mikaela | ok | 13:16 |
| ogra_ | as i said, you can already set up a push server that installs your local snaps to all your machines | 13:16 |
| ogra_ | just by using snappy-remote and havin the ssh keys on that machine | 13:16 |
| Mikaela | but I didn't get clear answer to the mirrors, do they still exist or is everything installed from (potentially) other side of the world? | 13:16 |
| ogra_ | no, i dont think there are store mirros pülanned | 13:17 |
| Mikaela | and mirrors.ubuntu.com and httpredir.debian.org what happens if I go abroad, will nearest mirror be automatically given to me? | 13:17 |
| ogra_ | beuno, might be able to elaborate | 13:17 |
| ogra_ | but my understanding is that there wont be any mirrors | 13:18 |
| ogra_ | note that the deb based ubuntu will never go away, the old infrastructure stays as is | 13:19 |
| Mikaela | is there some other solution like p2p which was also introduced in Windows 10 from what I understood or how is the downloading handled? Some countries still have slow connectivity abroad and connection to another continent isn't like on the same continent. | 13:20 |
| Mikaela | From what I understood there will be two editions at first, the deb-based and snappy, but later users are possibly tried to be migrated to snappy? | 13:20 |
| ogra_ | i doubt the deb based install goes away ... snappy is built from debs ... enterprise customers have installs that use debs etc etc | 13:22 |
| dholbach | thanks mterry! | 13:23 |
| Mikaela | so snappy is intented towards home users and debs to enterprises? | 13:24 |
| ogra_ | and there are the flavour distros (kubunt, xubuntu, edubuntu. lubuntu and whatnot) that all rely on debs ... we wont force anyone into snappy | 13:24 |
| beuno | Mikaela, hi | 13:24 |
| Mikaela | hi | 13:24 |
| ogra_ | Mikaela, no, i wouldnt say that :) | 13:24 |
| beuno | we will, over time, add a CDN to distribute in many regions | 13:25 |
| ogra_ | enterprises will likely see the massive security advantage and maintainability of snappy ... | 13:25 |
| ogra_ | but we wont force them into it | 13:25 |
| Mikaela | oh, I see | 13:25 |
| Mikaela | more on those repositories, I can think of Virtualbox and WeeChat having their own repositories. How would those repositories work with snappy? Do they submit all new releases to the store and they appear to users some time (days?) after that? And when new software versions are released, will snappy get updates faster than the deb-based, I can think of ZNC which is very slow to be updated on Ubuntu | 13:28 |
| Mikaela | repositories? | 13:28 |
| ogra_ | days ? | 13:28 |
| ogra_ | minutes rather ;) | 13:28 |
| Mikaela | I am too used to the deb-system being a little slow, so I thought days might be more reasonable time than minutes, but sounds good :) | 13:29 |
| ogra_ | the nature of snaps is that their security policy makes store submissions and checks completely automatable | 13:29 |
| ogra_ | my snaps are usually available 10-20 mins after upload ... (same goes for my click packages on phones) | 13:29 |
| ogra_ | if you break the security and still insist your snap needs to go in, that might take time though | 13:30 |
| ogra_ | manual reviews and all | 13:30 |
| ogra_ | we are trying to design snappy in a way that all the issues we have seen with debs obver the last decare when having to deal with them get solved by design ;) | 13:31 |
| ogra_ | after all dpkg is 30 years old and shows its age :) | 13:31 |
| ogra_ | *decade | 13:31 |
| Mikaela | will there still be packages packaged by Ubuntu Packagers and will they be made from the debs causing them to be as slow to update as currently? | 13:32 |
| beuno | Mikaela, snappy doesn't ship with dpkg or apt | 13:33 |
| ogra_ | well, our rootfs is assembled from debs from the archive ... so that bit will stay | 13:33 |
| ogra_ | and it is up to the packager if he does want to use debs as input for his snap | 13:34 |
| Mikaela | So snaps can be made separately and that is possibly even encouraged? | 13:34 |
| ogra_ | yes | 13:35 |
| ogra_ | you can even use plain upstream sources and compile them statically if you feel like | 13:35 |
| Mikaela | ok. thanks, I think all my questions are answered now :) | 13:36 |
| ogra_ | snappy itself only applies some metadata to binaries ... how/where you get these binaries from is totalyl up to you | 13:36 |
| ogra_ | this is what i meant by snaps are PPAs btw ;) | 13:36 |
| ogra_ | if i want to provide a special libreoffice build today, i set up a PPA and build a binary with my patches | 13:36 |
| Mikaela | oh, so if I install package outside of store it has information where to update itself when update is available? | 13:37 |
| ogra_ | in the snappy world i put all my binaries into one snap and push it to the store as libreoffice.ogra | 13:37 |
| ogra_ | so you as user can chose to install libreoffice.canonical or you can try my package just by installing libreoffice.ogra instead | 13:37 |
| ogra_ | no mangling of sources.list, gpg key shuffling etc ... my hacked package will just be available like any other to you | 13:38 |
| ogra_ | if you install a package via snappy install on cmdline or via snappy-remote there is no upgrade path if the package isnt in the store | 13:39 |
| Mikaela | I see. So everyone can get their app to store easily? | 13:40 |
| ogra_ | yes | 13:40 |
| ogra_ | its five clicks in a webform :) | 13:40 |
| Mikaela | sounds a lot more simple than how I imagine the deb-repos and PPAs | 13:41 |
| ogra_ | for the enduser it definitely is ... for the developer the build process is not as easy currently ... at least if your brain is still thinking deb-src :) | 13:42 |
| ogra_ | for the latter part we are working on tools to make your life super easy (there is just a sprint where people are designing the further development of the snapcraft tool that will enable you to easily turn anything into a snap | 13:43 |
| Mikaela | oh, deb-src gives me another question, how will changelogs and getting build-depedencies work? | 13:43 |
| ogra_ | this is totally up to you as developer | 13:44 |
| jdstrand | zyga: apparmor doesn't currently mediate ioctls. seccomp mediates the call but we have to allow it for shell scripts. however, you still need the capability and access to the device before you can use an ioctl | 13:45 |
| ogra_ | nor sure about changelog support in the store, you ave a field to provide one but i'm not sure how it will be presented in i.e. webdm to the user | 13:45 |
| Mikaela | I mean from the user point of view. Currently there are "apt-get build-dep" and "apt-get changelog" which require deb-src lines in sources.list. Is that information stored as metadata directly | 13:45 |
| ogra_ | well, as a user you only see/get binaries | 13:46 |
| jdstrand | zyga: we only have coarse-grained mediation for netlink, and you get that (cause you need it) when you specify a network-* cap | 13:46 |
| ogra_ | the develoer can and should provide a support contact and can also point to a website ... that should then have build instructions and/or links to source etc | 13:46 |
| zyga | jdstrand: thanks! | 13:47 |
| Mikaela | I see | 13:47 |
| jdstrand | zyga: same thing applies though wrt capabilities. Ie, there are some netlink sockets that might require cap_net_admin | 13:47 |
| ogra_ | in the snappy works we rather provide the infrastructure ... the actual snaps are up to the developer | 13:47 |
| ogra_ | effectively as a developer i can have all my stuff on github and just point the urls in my snap there ... | 13:48 |
| ogra_ | uploads to the store are completely binary | 13:48 |
| Mikaela | that makes me think of yet another thing, bug reporting, does it move to whereever the developer pointed or is apport/ubuntu-bug still there reporting to launchpad? | 13:49 |
| ogra_ | also up to the developer ... i'm not sure what our plans wrt apport are and if/how much we want ti to work with snaps | 13:50 |
| ogra_ | after all the source can live anywhere ... while in the deb based distro it has to live in some archive we control | 13:51 |
| Mikaela | ok, thanks for all the explanation, now I think I undertand everything I was wondering | 13:51 |
| ogra_ | well, thaks for asking ... it is kind of hard trying to assemble a FAQ if nobody asks questions ;) | 13:52 |
| ogra_ | so just go on :) | 13:52 |
| Mikaela | :) | 13:52 |
| longsleep | ogra_: Question - is there some open source server implementation for the snappy store api or do i have to write this from scratch if i wanted my snappy installation load snaps from another place? | 14:01 |
| longsleep | right now the URL to the store is hardcoded, so i think this has not been aked much yet :) | 14:01 |
| ogra_ | you'd have to write it from scratch i think | 14:01 |
| longsleep | ok - should not be complicated - i just asked your sales guys what the plan is on that matter | 14:02 |
| ogra_ | ah, what did they tell you ? | 14:03 |
| longsleep | ogra_: just wrote the mail - so no answer yet :) | 14:03 |
| * ogra_ guesses "sub-store" :) | 14:03 | |
| sergiusens | dholbach: yeah, I tweeted them :-P | 14:04 |
| dholbach | right | 14:04 |
| longsleep | yes i guess that will be the answer - though for security devices it might not be good enough to get security updates from a entity governed by UK law | 14:04 |
| dholbach | thanks, found | 14:05 |
| dholbach | sergiusens, do you have some notes for them as well? :) | 14:05 |
| ogra_ | longsleep, werll, there beuno's mentioned CDN might come into play | 14:05 |
| ogra_ | not sure if he has taken local laws into account with the planning though :) | 14:06 |
| longsleep | ogra_: well - the problem is that in certain countries companies or even people can be forced to insert backdoors into their code / distributions - even wore they are forced by law to not tell about it | 14:07 |
| ogra_ | yeah, i get you | 14:08 |
| ogra_ | just wondering if we take that into account with our store plans | 14:08 |
| beuno | we likely won't be able to help those countries | 14:08 |
| beuno | inserting backdoors into the distribution | 14:08 |
| beuno | just like we don't today | 14:08 |
| longsleep | well i am not sure about UK laws - but i think they could force you (Canonical) already | 14:09 |
| ogra_ | beuno, well, but if you have local laws that require encryption bits to come from local servers .... | 14:09 |
| ogra_ | i think thats a valid concern | 14:09 |
| longsleep | well - i think people might want to have self controlled sources only for updates | 14:10 |
| longsleep | i think that should be possible with snappy as well eventually | 14:10 |
| sergiusens | dholbach: https://twitter.com/sergiusens/status/630061431317229568 | 14:10 |
| sergiusens | dholbach: https://twitter.com/sergiusens/status/630061036910084096 | 14:10 |
| dholbach | yep, found the slides | 14:10 |
| beuno | ogra_, sure, and we'll serve content locally as time goes by | 14:10 |
| dholbach | thanks | 14:10 |
| sergiusens | dholbach: notes are in the notes section of the slides, but they are more of a memory catalyst than anything else (as in unintelligible to anyone but me) | 14:11 |
| ogra_ | beuno, right, i think thats the answer longsleep needed ;) | 14:11 |
| dholbach | ok ok :) | 14:11 |
| longsleep | ogra_, beuno well not really, if it is the same content then this does not help. Say the master for content is compromised, then all the children are as well when they are synced up no matter where the actuall download comes from. | 14:12 |
| beuno | longsleep, yes. Just like Ubuntu works today | 14:12 |
| beuno | (and every other distro) | 14:13 |
| longsleep | beuno: no, with Ubuntu i have the choice to fetch and review all the stuff and have my machines only install and fetch stuff i previously reviewed. | 14:13 |
| longsleep | beuno: with the store i get some binary blob. There is no way to verify that it has not been modified or was not modified after it was uploaded to the store as the store is essentially under control by Canonical. | 14:15 |
| longsleep | It is fine to have it that way for most, but what i am saying is that there are users who want this level of control for themselves | 14:16 |
| beuno | longsleep, you can know it hasn't been modified after upload, as it's signed with the Canonical key | 14:17 |
| ogra_ | longsleep, so why dont you host your stuff on a secure server and have code inside your snap to pull the secrets from there then | 14:17 |
| beuno | today, you download binaries as well | 14:18 |
| sergiusens | dholbach: we need youtube to auto translate my talk :-P | 14:18 |
| ogra_ | that woulld definitely give you full control | 14:18 |
| * sergiusens wll be back in a bit | 14:18 | |
| beuno | so unless you re-compile everything, you're on the same boat | 14:18 |
| longsleep | beuno: Canonical can modify at any time and sign it again | 14:18 |
| beuno | longsleep, sure | 14:19 |
| longsleep | beuno: yes today we do not recompile everything, but some things + platches | 14:19 |
| longsleep | patches | 14:19 |
| === zyga is now known as zyga-afk | ||
| beuno | right | 14:20 |
| beuno | so snappy doesn't allow you to do that | 14:21 |
| beuno | OS updates need to be applied, unchanged | 14:21 |
| beuno | and when I say snappy, I mean using the distribution as-is | 14:21 |
| longsleep | ogra_: there is also the concern about privacy and tracking - there probably is some sort tracking in the store not everyone might be happy with either | 14:21 |
| beuno | if you would like to take it, and manage it yourself | 14:21 |
| beuno | compile it, etc | 14:21 |
| longsleep | beuno: yes what what i am resarching - if and why and under what circumstances i need a system image server or eventually build own -core snap. | 14:22 |
| longsleep | beuno: And then as a consequence also have own server providing the snap downloads. | 14:23 |
| ogra_ | system-image will go away | 14:23 |
| ogra_ | dont rely on it | 14:23 |
| ogra_ | the rootfs will be turned to snap eventually | 14:23 |
| longsleep | ogra_: yes - i have a couple of weeks more on this matter - right now system image and rootfs is the same for me | 14:24 |
| longsleep | ogra_: i wanted to ask you on this matter how u-d-f builds an image then there is no system image any more. I guess it will connect to the store somehow and download one snap and the device snap? | 14:25 |
| longsleep | or gadged snap for that matter | 14:26 |
| longsleep | ogra_, beuno: Another matter is the naming, is something which goes that far to provide own rootfs and snap server still Ubuntu Snappy or something else? | 14:26 |
| ogra_ | longsleep, thats a question for sergiuens | 14:27 |
| ogra_ | (who just left :P ) | 14:27 |
| longsleep | hehe | 14:27 |
| longsleep | just giving you guys the idea what our enterprise customers ask me about | 14:27 |
| ogra_ | well, i dont think we want to allow self built rootfses | 14:28 |
| longsleep | it goes even so far having no connection to the public internet | 14:28 |
| ogra_ | if there is something missing in customization options that should be fixed, but nobody should need to use a modified rootfs imho | 14:28 |
| longsleep | ogra_: maybe not modified, but self compiled for sure | 14:29 |
| beuno | longsleep, it can't be called Ubuntu, no | 14:29 |
| beuno | longsleep, for enterprises, we will offer landscape | 14:29 |
| beuno | as a way to manage updates to devices | 14:29 |
| beuno | self-hosted landscape, that is | 14:29 |
| beuno | but that doesn't let you override updates | 14:29 |
| beuno | just control what gets updated and when | 14:30 |
| longsleep | beuno: understood thanks | 14:30 |
| beuno | there are no plans to allow people to change the rootfs in any way | 14:30 |
| beuno | as that breaks confinement | 14:30 |
| ogra_ | longsleep, self compiled will surely work via ubuntu-device-flash ... but most likely only if you use --devloper-mode and such | 14:30 |
| ogra_ | so not really suitable for products | 14:31 |
| ogra_ | (but suitable for hacking) | 14:31 |
| longsleep | ogra_: well one can also recompile ubuntu-device-flash, have their own keying and grab the stuff from own servers | 14:31 |
| ogra_ | indeed | 14:32 |
| ogra_ | but then you would have an insecure server | 14:32 |
| ogra_ | how would you ever make sure the same tests run ? | 14:32 |
| ogra_ | or guarantee the same quality in any way | 14:33 |
| longsleep | i mean i am talking about specific use cases here - where Ubuntu snappy is used as open source software similar to what we do with normal ubuntu now. Modify it in any means thinkable and then provide services around it. | 14:33 |
| longsleep | ogra_: true, that will be all different for sure. But it does not mean that it is worse. It just gives control. | 14:33 |
| longsleep | including the power to fuck it up for sure | 14:33 |
| longsleep | So essentially i might eventually need the transactional Ubuntu provided by snappy with the same level of freedom to create my own variant on top of it. | 14:36 |
| ogra_ | you can do that today (the on top of it part) | 14:37 |
| longsleep | not when i want updates without public internet access or no third party connections | 14:37 |
| longsleep | at the moment that requires patching rootfs config, patching snappy tool and patching u-d-f. | 14:39 |
| ogra_ | i suspect it will in the future as well | 14:39 |
| longsleep | ogra_: yeah i am just starting on this - but i need to have the answers if we can use snappy or at least parts of it for our more secured environments as well | 14:40 |
| longsleep | so at the moment for that i have to run my own system-image server and snap server, create own rootfs with patched tools and config and have patched u-d-f for image building. | 14:42 |
| ogra_ | well, i guess having a local upgrade from usb key (or SD card) upgrade abiliy mmight be a good thing for that usecase | 14:42 |
| longsleep | ogra_: not if you have many devices | 14:43 |
| ogra_ | so you could give your customers an image they can just auto-flash by booting from it | 14:43 |
| ogra_ | or netbooting from it ;) | 14:43 |
| ogra_ | with a special boot mode | 14:43 |
| longsleep | ogra_: well, netbooting would do it - but not all updates should force a reboot either | 14:43 |
| longsleep | ogra_: right now customers have their own deb mirror for their specific variant on top of ubuntu | 14:44 |
| ogra_ | well, for that you can still have some push server scripted around snappy-remote | 14:44 |
| longsleep | ogra_: mhm for that one central server needs to know all the servers and must have ssh access to them | 14:44 |
| ogra_ | yes, indeed | 14:45 |
| longsleep | ogra_: very different from https access to a single ip from many locations | 14:45 |
| longsleep | ogra_: so eventually we will have something - i would prefer to have a little changes to Snappy as possible for such use cases. I will keep you posted once ideas come up. | 14:47 |
| ogra_ | yeah, and dont forget, i'm only speculating as much as you ... the only one who can give authoritative answers about actual store implementation is beuno | 14:48 |
| longsleep | sure - still it helps a lot to get some feedback from someone who is closer to source | 14:49 |
| longsleep | eventually i might add some feature requests to the bug tracker if i am more clear on what we want to do how and then | 14:50 |
| ogra_ | +1 | 14:50 |
| longsleep | Other question, snappy yaml port negotiable option, is that implemented and how do i get the port it might have chosen instead? | 14:52 |
| longsleep | docs say (there is no implementation for this yet) | 14:52 |
| beuno | longsleep, it hasn't been implemented yet | 14:53 |
| longsleep | still true i assume? | 14:53 |
| ogra_ | and i think the docs are right | 14:53 |
| ogra_ | yeah, i guess | 14:53 |
| longsleep | ok thanks - so are there ideas how it will be implemented? | 14:53 |
| longsleep | i want to add configuration to the spreed-webrtc snap and ports are one thing i want to have there | 14:54 |
| ogra_ | yeah | 14:59 |
| elopio | fgimenez: I can't ssh into 10.55.33.0 | 15:09 |
| fgimenez | elopio, maybe it's down, let me check | 15:09 |
| elopio | fgimenez: I just need the credentials. Maybe you can send them to me by mail, encrypted with my gpg key :) | 15:37 |
| fgimenez | elopio, http://10.55.60.183:8080/ seems to be working, https://code.launchpad.net/~fgimenez/snappy-tests-job/test1/+merge/267831 | 15:38 |
| fgimenez | elopio, i've just added your ssh keys there | 15:38 |
| elopio | fgimenez: cool, thanks. | 15:39 |
| elopio | fgimenez: it expanded the URL, wtf | 15:39 |
| fgimenez | elopio, you can try with MPs to snappy-jenkins-job | 15:39 |
| fgimenez | snappy-tests-job, sorry | 15:40 |
| fgimenez | elopio, all the config seems to be the same | 15:40 |
| elopio | fgimenez: I wasted my day and was so happy to have found a solution in the end. I hate computers. | 15:41 |
| fgimenez | elopio, let's see what's the difference, the user name and password for jenkins are the same as for the shared canonistack user | 15:42 |
| === chihchun is now known as chihchun_afk | ||
| fgimenez | elopio, here are the first changes for the test output https://code.launchpad.net/~fgimenez/snappy/parseable-test-output/+merge/267838, let me know what do you think | 16:08 |
| seshu | hello there. Just checking to confirm, is WebDM written in "go programming language"? | 17:47 |
| beuno | seshu, it is, yes | 17:48 |
| seshu | Thanks! beuno. | 17:49 |
| === c74d is now known as Guest91301 | ||
| * Chipaca peeks in | 19:52 | |
| Chipaca | ogra_: you probably know these things: how's a "wan ethernet" different from a "lan ethernet"? is it just different broadcast domains? asking for http://igg.me/at/2ffEJUPWerU/x/4032581 | 19:53 |
| ted | Chipaca, I'm betting they're configured differently on the routing chip. So the LAN ports are all automatically switched without hitting the CPU. | 20:33 |
| ogra_ | Chipaca, the same thing as your "uplink" port on a switch ... it can probably speak MPLS (https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching) and other shiny stuff | 21:13 |
| Chipaca | shiny! | 21:14 |
| ogra_ | technically ethernet is ethernet though ... and normal lan ports can usually run MPLS as well ... i would expect there is some kind of optimization or so | 21:17 |
| === lazyPower is now known as lp|conference-mo | ||
| === lp|conference-mo is now known as lp|conference | ||
| kyrofa | ogra_, you still around? | 22:01 |
| kyrofa | elopio, how about you? | 22:04 |
| === robert_ancell_ is now known as robert_ancell | ||
| kyrofa | ted, you still around? | 22:13 |
| elopio | kyrofa: hello | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!