Re: Slow snap build on Ubuntu Core device

[Luther Goh Lu Feng]

Based on the screenshot, your download speed for the packages seems to be very 
slow. Perhaps you want to use a faster mirror.


Maybe you can try netselect-apt as mentioned here[1]. HTH. Thanks.


-- Luther

[1] https://www.unixmen.com/find-fastest-mirror-debian-derivatives/




On Tuesday, January 10, 2017 11:41 PM, Alan Pope  
wrote:
On 10 January 2017 at 15:28, XiaoGuo Liu  wrote:
> Currently, I am try to build armhf snap on Raspberry Pi device. I find that
> the build process is extremely slow, and sometimes, it shows that it will
> take more than 1 hour to get it down. I cannot set up the VPN on the device
> for now. May I know whether there is any way to change the source of the
> download on the board?
>

For archive packages being slow (as you have) I use apt-cacher-ng on
my laptop. It caches the debs making snapcraft builds much faster.

https://www.unix-ag.uni-kl.de/~bloch/acng/

Alternatively, push it to launchpad and build there?

https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way

Cheers,
-- 
Alan Pope
Community Manager

Canonical - Ubuntu Engineering and Services
+44 (0) 7973 620 164
alan.p...@canonical.com
http://ubuntu.com/


-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: opengl on ubuntu core 16 on artik 10?

[Liming Wang]

On Thu, Jan 05, 2017 at 11:05:56AM -0800, Dan Kegel wrote:
>On Thu, Jan 5, 2017 at 10:50 AM, Zygmunt Krynicki
> wrote:
>>> has anyone tried artik 10 with ubuntu core 16,
>>> and what's the story with opengl there?
>>
>> I don't have access to that hardware so I don't know personally. If the
>> kernel and userspace contain the relevant code it should be OK in devmode.
>> For confinement it is possible that some of those bits will try to access
>> something that is not permitted by the base set of rules.
>>
>> Do you have any test code you can try?
>
>First off, let me say that I'm an opengl novice, I know very little about it.
>
>https://github.com/ubuntu/snappy-playpen/tree/master/hellogl
>runs a trivial opengl app, but probably with the default
>opengl, which might not be the platform's high-performance opengl.
>
>https://github.com/penk/oxide-eglfs-snap/tree/rpi2 is a real
>app that bundles the raspberry pi's high-performance opengl
>userspace driver into the snap;
>that's the kind of thing I'm looking for.
>
>I would be impressed if someone did a single snap that
>did high performance opengl on both Pi 3 and Artik 10.
>Seems unlikely.
Hi Dan,

Yes, the ubuntu core 16 release[1] of artik10 has no support of
graphics/opengl. And there was also no any experience of running opengl
application on ubuntu core 16 of artik10.

But that's not to say we can't support it. Actually, in artik10 linux
kernel[1], there's an experimental mali driver in
drivers/gpu/arm/midgard directory and also there was unofficial
userspace opengl support in samsung's forum[3]. To support them, there's some 
work to do.

>
>I have a Pi but not an Artik myself, just looking around at
>the other hardware Ubuntu Core supports.

Did you run the oxide-eglfs-snap example on Pi? If so, do you still need
other platform to run opengl on ubuntu core?

Best Regards,
Liming Wang

1. https://developer.ubuntu.com/core/get-started/artik-5-10
2. https://github.com/SamsungARTIK/linux-artik.git
3.
https://developer.artik.io/forums/t/how-i-install-mali-midgard-in-user-space-for-using-x11/594
>
>-- 
>Snapcraft mailing list
>Snapcraft@lists.snapcraft.io
>Modify settings or unsubscribe at: 
>https://lists.ubuntu.com/mailman/listinfo/snapcraft

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: opengl on ubuntu core 16 on artik 10?

[Dan Kegel]

> Did you run the oxide-eglfs-snap example on Pi? If so, do you still need
> other platform to run opengl on ubuntu core?

Thank you for the links!

The Pi is awesome as a starting point for users, but is underpowered
for some of our applications.
It's attractive to have a faster/fatter alternative that can run the
same snaps (ok, the opengl difference would need some finesse, but it
seems doable and writing a demo showing how to do it sounds like a
fun project).

And having a 2GB pi-compatible arm system would reduce latency for
continuous integration try builds...

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Interface management in the context of snap in a classical Debian install

[Jamie Strandboge]

On Tue, 2017-01-10 at 03:32 +, Luther Goh Lu Feng wrote:
> Bumping this up again since I didnt seem to have received a reply. Was my
> question sufficiently clear?
> 

Sorry no one responded sooner.

At this time, snapd on Debian[0] puts all snaps in devmode so there are far
fewer restrictions place on the snap than on systems where confinement is
enforced. On Debian, snaps will be able to access all files in the core snap, a
few bind mounted directories from the system (like /run) and various IPC
mechanisms. As such, your golang web service should be able to access services
provided by debs via network IPC (eg, if influxdb opened a port on the loopback
interface), DBus, abstract UNIX domain sockets, anonymous sockets, and named
sockets if the named socket is in one of the system bind mounted directories
(eg, /run/influxdb).

On systems with full confinement, snaps run in a sandbox[1][2] that is
configured by snappy interfaces[3]. This sandbox controls how the snaps interact
with the system and other snaps. On these systems, your golang web service would
not be able to access services provided by debs by default. Some interfaces are
intended to work on traditional (aka, 'classic') systems so if there is an
interface implemented in snapd for a particular service provided as a deb, then
connecting that interface for the snap would give the snap access to that system
service (eg, network-manager, ofono, etc). There is no interface for influxdb at
the moment, so your snap would not be able to access any of its files or non-
network IPC mechanisms. If influxdb listened on a network port (eg, on
loopback), then your snap would be able to access this port if the 'network'
interface was connected.

[0]https://github.com/snapcore/snapd/wiki/Distributions#debian
[1]http://snapcraft.io/docs/reference/confinement
[2]https://github.com/snapcore/snapd/wiki/Security
[3]https://github.com/snapcore/snapd/wiki/Interfaces

> 
> -- Luther
> 
> 
> 
> On Tuesday, January 3, 2017 4:39 PM, Luther Goh Lu Feng 
> wrote:
> I am considering the scenario where snap is installed in a classical Debian
> install. I intend to package my golang web service in a snap. The web service
> may have some dependencies that are present in the debian repository, but not
> available as a snap. Examples could be a database like influxdb, or a reverse
> proxy like nginx.
> 
> My question is: how will the snap be interfacing with non snap software in the
> context of interfaces[1]? Is there an example? 
> 
> I understand that it will be more ideal if the dependencies are also snaps,
> but this may not be possible in the near future. Please advise implications
> and other alternative implementations. Thanks.
> 
> 
> -- Luther
> [1] http://snapcraft.io/docs/core/interfaces
> 
-- 
Jamie Strandboge | http://www.canonical.com



signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: opengl on ubuntu core 16 on artik 10?

[Liming Wang]

On Tue, Jan 10, 2017 at 08:36:33AM -0800, Dan Kegel wrote:
>> Did you run the oxide-eglfs-snap example on Pi? If so, do you still need
>> other platform to run opengl on ubuntu core?
>
>Thank you for the links!
>
>The Pi is awesome as a starting point for users, but is underpowered
>for some of our applications.
>It's attractive to have a faster/fatter alternative that can run the
>same snaps (ok, the opengl difference would need some finesse, but it
>seems doable and writing a demo showing how to do it sounds like a
>fun project).
>
>And having a 2GB pi-compatible arm system would reduce latency for
>continuous integration try builds...

We did support hikey board in snappy 15.04, but also without opengl.
But I think hikey is a suitable platform if we continue to support ubuntu
core 16 on it. Because there are lots of resources for this hardware.
I heard someone is doing the job to support ubuntu core 16 on hikey, but
I don't know what's the progress now.

Best Regards,
Liming Wang
>
>-- 
>Snapcraft mailing list
>Snapcraft@lists.snapcraft.io
>Modify settings or unsubscribe at: 
>https://lists.ubuntu.com/mailman/listinfo/snapcraft

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

To handle the absolute path in compiling time

[Jin Hsieh]

Hello All,

We are trying to snap up a mail server,
by referring to the design of a popular solution,
there are several services need to be packaged as parts.

The major one is the postfix,
it uses an install script to deploy the built binary,
libraries and the configuration files,
the problem here is it assigns an absolute path when installing:
https://github.com/jindallo/postfix/blob/master/postfix-install#L446
it's a trouble in snap world since my goal is pushing them into $SNAP
properly,
however, in the Build phase of my parts it does not know the path $SNAP.

I tried to deploy it by stage-packages directly but no luck for such the
complicated service,
the configuration path is hardcoded on the pre-compiled binary.
https://github.com/jindallo/iredmail-snap/blob/master/snapcraft.yaml
Besides give the postfix source a hack to do getenv for $SNAP in compiling,
do you guys have any idea or any tricks on this to make it works could
share with us?

Many thanks.

BR.
Jin
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: opengl on ubuntu core 16 on artik 10?

[Kevin Gunn]

On Tue, Jan 10, 2017 at 12:04 PM, Dan Kegel  wrote:

> Hi Kevin,
> having a preview of the mir stack is attractive.
> Would that mean snaps that use opengl would not need to carry the
> boards' opengl library?
>

correct, the snaps rely on the gl drivers provided by the system.


>
> dragonboard would do for undemanding apps, but it's only 1GB and 30fps HD
> video.
> Is there a 2GB RAM + faster GPU board that can do 60fps HD video and
> use same snaps?
>

as for embedded type boards, not that we've currently worked on directly.
but any board having open kms/drm graphics should easily work - so any
intel boards would/should work easily.
perhaps someone else from the community could speak up if they've played
with something meeting your description.


>
> On Tue, Jan 10, 2017 at 9:35 AM, Kevin Gunn 
> wrote:
> > Hey Dan -
> > I'm not certain what your use case is, but seems your open to considering
> > other hw.
> > In which case, I might point out we've done a little bit with our ubuntu
> > graphics stack on top of dragonboard with quite a bit of ease. There's a
> > variety of Qt examples [1], webbrowser [2] and even kodi [3].
> > If you try these out and have any issues please do let me know.
> >
> > br,kg
> >
> > [1] https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
> > [2] https://plus.google.com/+KevinGunnCanonical/posts/KPfVvfTU3f6
> > [3] https://plus.google.com/+KevinGunnCanonical/posts/3SDJjqCz3S9
> >
> >
> > On Tue, Jan 10, 2017 at 10:36 AM, Dan Kegel  wrote:
> >>
> >> > Did you run the oxide-eglfs-snap example on Pi? If so, do you still
> need
> >> > other platform to run opengl on ubuntu core?
> >>
> >> Thank you for the links!
> >>
> >> The Pi is awesome as a starting point for users, but is underpowered
> >> for some of our applications.
> >> It's attractive to have a faster/fatter alternative that can run the
> >> same snaps (ok, the opengl difference would need some finesse, but it
> >> seems doable and writing a demo showing how to do it sounds like a
> >> fun project).
> >>
> >> And having a 2GB pi-compatible arm system would reduce latency for
> >> continuous integration try builds...
> >>
> >> --
> >> Snapcraft mailing list
> >> Snapcraft@lists.snapcraft.io
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/snapcraft
> >
> >
> >
> > --
> > Snapcraft mailing list
> > Snapcraft@lists.snapcraft.io
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/snapcraft
> >
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: snapd 2.20 release available in {xenial,yakkety}-updates

[Christian Ehrhardt]

On Fri, Jan 6, 2017 at 10:48 AM, Michael Vogt 
wrote:

> > Can you say a few words about classic confinement?  I didn't see doc...
>
> Thanks for this reminder, I should have included the link that David
> provided to http://snapcraft.io/docs/reference/confinement
>
> In a nutshell classic make it very easy to provide snaps for
> traditional (classic) distributions like Ubuntu 16.04. It is currently
> not quite as polished as we would like it to be (we are actively
> working on fixing that!) but I think its a really nice feature.


Even being subscribed I missed the importance of this when it came around a
few days ago.
Since now there is also this insights post about it - it might be worth to
"ping" the thread once more.
See:
https://insights.ubuntu.com/2017/01/09/how-to-snap-introducing-classic-confinement/


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Issue with ubuntu OS snap first time boot.

[Gustavo Niemeyer]

Hi Ajay,

That means the communication with the local snapd daemon failed abruptly,
which is unusual.

Can you tell us a bit more about the environment this is running on, and
which image it is?

Do you have access to the underlying filesystem somehow (is it an SD card?
VM?), in which case can you send us the /var/log content?

Thanks, and sorry you're having trouble there.



On Tue, Jan 10, 2017 at 3:35 PM, Ajay Pandey 
wrote:

> Hi All,
>
>
>
> We are facing issue with the Ubuntu OS snap first time boot console-conf.
>
>
>
> We have generated the id_rsa.pub key and put it in the launchpad.net as
> well as the login.ubuntu.com profiles.
>
>
>
> Please find below the error that we are getting:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Profile setup
> Enter an email address from your account in the store.
>  Email address:x...@gmail.com
> (example)   If you do not have an
> account, visit https://login.ubuntu.com 
> to create one.
>   Creating user failed:
>   error: while creating user: cannot communicate with server:
> Post   http://localhost/v2/create-user
> : EOF
>
>  Contacting
> store...  [
> Done   ][ Cancel ]
>   40 %*
> 
> 
> * eInfochips Business Disclaimer:
> This e-mail message and all attachments transmitted with it are intended
> solely for the use of the addressee and may contain legally privileged and
> confidential information. If the reader of this message is not the intended
> recipient, or an employee or agent responsible for delivering this message
> to the intended recipient, you are hereby notified that any dissemination,
> distribution, copying, or other use of this message or its attachments is
> strictly prohibited. If you have received this message in error, please
> notify the sender immediately by replying to this message and please delete
> it from your computer. Any views expressed in this message are those of the
> individual sender unless otherwise stated. Company has taken enough
> precautions to prevent the spread of viruses. However the company accepts
> no liability for any damage caused by any virus transmitted by this email.
> 
> 
> *
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>
>


-- 

gustavo @ http://niemeyer.net
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Manual update of snap/snapd and core/ubuntu-core

[Jamie Bennett]

Hi Jenny,

On 09/01/17 at 10:28am, Jenny Murphy wrote:
> Hi,
>  My query is related to a few of the recent discussions regarding versions,
> releases and updates/
> 
> I currently have a Snappy Ubuntu system as follows :
> 
> snap --version gives the following result :
>  snap2.18.1
>  snapd   2.18.1
>  series  16
> 
> more /etc/lsb-release yeilds :
> DISTRIB_ID="Ubuntu Core"
> DISTRIB_RELEASE=16
> DISTRIB_DESCRIPTION="Ubuntu Core 16
> 
> And finally snap list yields :
> core 16.04.1641  canonical  --
> 
> I don't see to be  getting any automatic updates which I don't mind about
> as long as I could manually update.
> 
> So just a few questions :
> 
> 1. How can I update snap and snapd

What happens when you type:

$ snap info core

Also, what happens when you type:

$ snap refresh

> 2. Is snap the front end to snapd ? Do they get updated together?

Yes.

> 3. Can I update snapd and not update ubuntu-core and core.

On an Ubuntu Core system snapd is integral to the device, on a classic system
snapd is an add-on package so in the former case the system and snapd are
updated together.

> 4. Should ubuntu-core and core be updated together also? From the previous
> reply on this topic, it seems core is the framework and ubuntu-core is the
> filesystem or is it vice versa?

ubuntu-core is the old name for core. We renamed this to better reflect that
other cores could be available that are not Ubuntu based. Do you have both of
these installed on your system? In fact, can you give us a full output of:

$ snap list

> I know there are a lot of questions here but it is just a little bit
> unclear to me at the moment. Maybe there are also some other users in the
> same position.
> 
> 
> Thanks,
> Jenny
> 
> 
> 
> *Jenny Murphy*
> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland*
> jenny.mur...@episensor.com   t | +353 (0) 61
> 512 511  w | http://www.episensor.com

> -- 
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/snapcraft


-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: To handle the absolute path in compiling time

[Michael Hall]

You can use /snap//current/ instead of $SNAP. At least from
inside the snap's runtime environment that should always point to the
current install base. It's not ideal, but it's at least a predictable
path you know at build time.


Michael Hall
mhall...@ubuntu.com

On 01/10/2017 12:16 PM, Jin Hsieh wrote:
> Hello All, 
> 
> We are trying to snap up a mail server, 
> by referring to the design of a popular solution, 
> there are several services need to be packaged as parts.
> 
> The major one is the postfix, 
> it uses an install script to deploy the built binary, 
> libraries and the configuration files, 
> the problem here is it assigns an absolute path when installing:
> https://github.com/jindallo/postfix/blob/master/postfix-install#L446
> it's a trouble in snap world since my goal is pushing them into $SNAP
> properly, 
> however, in the Build phase of my parts it does not know the path $SNAP.
> 
> I tried to deploy it by stage-packages directly but no luck for such the
> complicated service, 
> the configuration path is hardcoded on the pre-compiled binary.
> https://github.com/jindallo/iredmail-snap/blob/master/snapcraft.yaml
> Besides give the postfix source a hack to do getenv for $SNAP in compiling, 
> do you guys have any idea or any tricks on this to make it works could
> share with us?
> 
> Many thanks.
> 
> BR.
> Jin
> 
> 

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Slow snap build on Ubuntu Core device

[Alan Pope]

On 10 January 2017 at 15:28, XiaoGuo Liu  wrote:
> Currently, I am try to build armhf snap on Raspberry Pi device. I find that
> the build process is extremely slow, and sometimes, it shows that it will
> take more than 1 hour to get it down. I cannot set up the VPN on the device
> for now. May I know whether there is any way to change the source of the
> download on the board?
>

For archive packages being slow (as you have) I use apt-cacher-ng on
my laptop. It caches the debs making snapcraft builds much faster.

https://www.unix-ag.uni-kl.de/~bloch/acng/

Alternatively, push it to launchpad and build there?

https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way

Cheers,
-- 
Alan Pope
Community Manager

Canonical - Ubuntu Engineering and Services
+44 (0) 7973 620 164
alan.p...@canonical.com
http://ubuntu.com/

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: snapd and semaphores

[Jamie Strandboge]

On Wed, 2017-01-04 at 13:39 +0100, Olivier Tilloy wrote:
> 
> Here is the bug report: https://launchpad.net/bugs/1653955

Thanks! The fix is in master and will bi in snapd 2.21.

-- 
Jamie Strandboge | http://www.canonical.com



signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Issue with ubuntu OS snap first time boot.

[Ajay Pandey]

Hi All,

We are facing issue with the Ubuntu OS snap first time boot console-conf.

We have generated the id_rsa.pub key and put it in the launchpad.net as well as 
the login.ubuntu.com profiles.

Please find below the error that we are getting:

Profile setup

Enter an email address from your account in the store.

 Email address:x...@gmail.com(example)

If you do not have an account, visit https://login.ubuntu.com
to create one.

  Creating user failed:
error: while creating user: cannot communicate with server: Post
  http://localhost/v2/create-user: EOF

   Contacting store...

   [ Done   ]
   [ Cancel ]



  40 %
*
 eInfochips Business Disclaimer: This e-mail message and all attachments 
transmitted with it are intended solely for the use of the addressee and may 
contain legally privileged and confidential information. If the reader of this 
message is not the intended recipient, or an employee or agent responsible for 
delivering this message to the intended recipient, you are hereby notified that 
any dissemination, distribution, copying, or other use of this message or its 
attachments is strictly prohibited. If you have received this message in error, 
please notify the sender immediately by replying to this message and please 
delete it from your computer. Any views expressed in this message are those of 
the individual sender unless otherwise stated. Company has taken enough 
precautions to prevent the spread of viruses. However the company accepts no 
liability for any damage caused by any virus transmitted by this email. 
*
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: netplan and post-up/pre-down scripts

[Martin Pitt]

Hello Mike,

Mike Pontillo [2017-01-06 10:12 -0800]:
>Recently, I was working on a project that led me to become frustrated
> with the current state of `systemd` and `ifupdown` (e.g.
> /etc/network/interfaces or /e/n/i) in Xenial. I remembered that
> `netplan`[1] was under development, so I added the PPA for Xenial

Note that netplan is in xenial-updates, so no PPA needed.

>Let me explain my use case: when an interface goes up or down, I want to
> be able to do event-driven things with the network configuration, such as
> add or remove routes, run a DHCP client, etc.

These two and more are already supported by networkd and NM (i. e. both of
netplan's current backends) and also in the netplan YAML itself of course. OOI,
what is your particular use case?

> My first attempt to make this happen was to add `post-up` and `pre-down`
> scripts to do this. However, this had a fatal flaw for my application:
> `ifupdown` doesn't separate the concept of operational status from the
> concept of administrative status.  (That is, in `ifupdown`, an interface is
> "up" if the admin says it is up.  Link up or link down does not seem to
> matter; it's strictly an /administrative/ status[3].)

The ifup@.service (more or less) deals with hotplugging, so normally as an
admin you would not explicitly "ifup" any interface (unless you mark them as
"manual", but then you are on your own anyway). So I fail to see the problem
here -- for "auto" and "allow-hotplug" interfaces this should just work?

> Looking at the `netplan` spec[4], I don't see a way to achieve that
> functionality

Correct. NetworkManager calls /etc/network/if-up.d/ when an interface is up
(same as ifupdown), but networkd doesn't, and it's not planned upstream to do
that. It could be done by monitoring networkd's D-Bus signals and reacting to
it, but so far there hasn't been a pressing use case for this. Many existing
if-up.d/ scripts are workarounds for software which aren't written with the
idea of network hotplugging in mind (e. g. not using IP_FREEBIND), and many
others aren't necessary or even actively detrimental with NM/networkd as they
are essentially ifupdown implementation of bridges or similar, so they must not
be called with NM/networkd.

> I know that many people are using the script-callout functionality in /e/n/i
> to achieve what they need to achieve

Actually, /etc/network/if-up.d/ has been the much more popular approach AFAIK.

> In an ideal world, I think `netplan` would be able to model my use case
> out-of-the-box.[5] But since we can't expect to model everyone's use case,
> it seems like custom scripting functionality is a hard requirement, though
> perhaps one that could have tricky cross-platform implications.

If you need this, then I suggest to use the NM backend, which gives you
/etc/network/if-up.d/. We will never use NM in confined scenarios like the
initramfs, so that should be reasonably safe. OTOH netplan itself (with
networkd) was meant to work in initrd and other early-boot scenarios where
arbitrary script callouts are not supportable.

If you have something particular that needs to be set/done when an interface
goes up, I suggest filing a bug -- maybe that functionality even already exists
in networkd/NM and just needs to be wired up to YAML?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: snapd and semaphores

[Olivier Tilloy]

On Tue, Jan 10, 2017 at 2:41 PM, Jamie Strandboge  wrote:
> On Wed, 2017-01-04 at 13:39 +0100, Olivier Tilloy wrote:
>>
>> Here is the bug report: https://launchpad.net/bugs/1653955
>
> Thanks! The fix is in master and will bi in snapd 2.21.

Excellent, thanks Jamie for your prompt response!

 Olivier

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: netplan and post-up/pre-down scripts

[Mike Pontillo]

Hi Martin,

Thanks for the reply.

>Let me explain my use case: when an interface goes up or down, I want
> to
> > be able to do event-driven things with the network configuration, such as
> > add or remove routes, run a DHCP client, etc.
>
> These two and more are already supported by networkd and NM (i. e. both of
> netplan's current backends) and also in the netplan YAML itself of course.
> OOI,
> what is your particular use case?
>

I had two test cases, which I first tried implementing using 'auto' and
'dhcp' interfaces in ifupdown, then in netplan.

Physical setup: two interfaces, intended to be used for routing. One to be
used for a WAN interface, the other to be used for a LAN interface.

Logical setup: each physical interface has an attached bridge, each
containing just that one port. For example:

Physical: eth0 ---> Bridge: wan0
Physical: eth1 ---> Bridge: lan0

I configured it this way because I wanted a no-hassle way to attach LXD
containers and/or VMs to a physical network.[1]

Now, this may have a lot to do with the fact that I'm using the bridge; the
behavior I'm describing may be very different for a "pure physical"
interface. But with this setup, I see 5-minute timeouts at boot when I:

 - Declare an 'auto' interface in 'ifupdown' which is disconnected at
system boot.
 - Declare a 'dhcp' interface in 'ifupdown' which is disconnected at system
boot.

I've seen similar 5-minute timeouts occur in the field with bond interfaces
whose physical links are not [all?] available.

After the system booted, I then tried more tests, such as checking if
routes and addresses were added or removed when I disconnected the physical
link. I was also testing a redundant setup with interfaces on the same
network, and a route metric in place for shortest-path selection. So I
expected the higher-metric route to be used when the lower-metric
interface's link went down. However, the behavior I saw was that the routes
via the downed interface were marked "linkdown" in the "ip route" output,
but route lookups still selected the "linkdown" route rather than switching
to the higher-metric route to the same destination. (So the only option is
to remove them from the kernel upon link down. Note, I don't want to
configure a bond; this is for "someone accidentally, or maybe on purpose,
plugged the WAN port into the LAN, or bridged the networks"; you want
traffic to keep flowing in that case, and return to normal when it's fixed.)

I would have to go back and test more to confirm, but I suspect some of
these issues have to do with the bridge. The behavior I want is for the
*bridge* to, for example, release its DHCP address, or delete its routes,
if the *underlying* physical interface goes down, and bring up the DHCP
client and/or static routes if the link comes back up. That way, any
running containers correctly see "no route to host" ICMP messages, rather
than trying to route packets to an interface whose underlying link is down.

I ended up having to write the configuration in 'ifudown' with "auto" and
"manual" on all the interfaces, and write a separate script (called from
post-up and pre-down callouts) to monitor link status, so that I could take
action on the corresponding bridge when the underlying link goes up or down.



> > My first attempt to make this happen was to add `post-up` and `pre-down`
> > scripts to do this. However, this had a fatal flaw for my application:
> > `ifupdown` doesn't separate the concept of operational status from the
> > concept of administrative status.  (That is, in `ifupdown`, an interface
> is
> > "up" if the admin says it is up.  Link up or link down does not seem to
> > matter; it's strictly an /administrative/ status[3].)
>
> The ifup@.service (more or less) deals with hotplugging, so normally as an
> admin you would not explicitly "ifup" any interface (unless you mark them
> as
> "manual", but then you are on your own anyway). So I fail to see the
> problem
> here -- for "auto" and "allow-hotplug" interfaces this should just work?
>

I have not used allow-hotplug, to be honest. The documentation isn't clear
on how exactly it works; I'm not sure what exactly triggers the hotplug
event. This might solve part of the issue, in that I want to allow booting
the system even if the link is down. (Is this the officially-supported way
[across all backends] to get rid of the 5-minute timeout I love to hate?)
But I also want to be able to take action on link down. So I'll have to
look into it more.[2]

If you need this, then I suggest to use the NM backend, which gives you
> /etc/network/if-up.d/. We will never use NM in confined scenarios like the
> initramfs, so that should be reasonably safe. OTOH netplan itself (with
> networkd) was meant to work in initrd and other early-boot scenarios where
> arbitrary script callouts are not supportable.


Again, this is for a router, so NetworkManager doesn't seem like a good
option. For the record, I'm fine with the early-boot limitation. I