Re: RAID on NextCloud
On 15.03.2017 00:39, Manik Taneja wrote: > hi there, > > an interesting question came up on askubuntu- > > https://askubuntu.com/questions/888404/ubuntu-core-with-raid-1?rq=1 > > is the best solution to package mdadm as a snap with core providing > an interface to /dev/md*? are there alternate solutions? We had a pretty active discussion a while back when we implemented the udisks2 interface in snapd. The outcome was that we don't want to give arbitrary snaps access to block devices and added all access for those directly into the udisks2 interface (see [0]). udisks2 offers a mediated way for all other snaps to deal with block devices and generally also allows working with RAIDs. I say generally, because this is a feature we didn't verified yet that it is working with the udisks2 snap currently in the store. If support for RAIDs in udisks2 works users should be able to mount a RAID on a directory in /media via an dbus API call. One downside is that the udisks2 interface explicitly denies plug connections as it still gives kind of privileged access to the system. Every mount done via udisks2 will appear below /media and every snap using the removable-media interface will get access to devices mounted there, regardless if it's the system partition or not. So even the plug side is a very privileged thing. That said, snaps can ask for a snap-declaration on the store side to get connections to udisks2. Another feature we support with the udisks2 snap is auto-mounting. This allows a device to say that it wants removable devices like USB storage device to be automatically mounted in /media as you know it from consumer oriented devices like the Ubuntu Desktop. Depending on how the RAID is setup this might be able to get the the RAID mounted on boot into /media. Requirements for the automounter to consider a device are currently: * Device is not a system device (meaning its not a partition on the device we're booting the system from) * Device is not already mounted * Device is a removable devices (USB, CD/DVD) For a very simple, unconfined solution you could just install the udisks2 snap (given that it detects and works well with RAID devices) and create a systemd unit in /etc/systemd/system/mount-my-raid.service [Unit] Description=Mount my RAID [Service] Exec=/snap/bin/udisks2.udisksctl mount -b /path/to/block/device [Install] WantedBy=multi-user.target Then activate it via $ sudo systemctl enable mount-my-raid.service and the RAID should be automatically mounted below /media on the next system reboot. I hope this helps. Btw. I will post this as an answer to the askubuntu.com question too. regards, Simon [0]: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/udisks2.go -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
RAID on NextCloud
hi there, an interesting question came up on askubuntu- https://askubuntu.com/questions/888404/ubuntu-core-with-raid-1?rq=1 is the best solution to package mdadm as a snap with core providing an interface to /dev/md*? are there alternate solutions? /manik -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Part 2! Request for help / ideas to debug issue
I've filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819 and https://github.com/golang/go/issues/19546 (the latter more of an FYI than a bug) On 14 March 2017 at 10:56, John Lenton wrote: > As a followup, I added a mutex around pthread_create, and around the > exec syscall, and the problem went away. This all in go's runtime; not > a huge diff but they probably don't want the overhead (and that seems > reasonable to me). > Next I'm going to try to find a kernel person to take a look at this. > > On 13 March 2017 at 23:33, Michael Hudson-Doyle > wrote: >> On 14 March 2017 at 12:21, John Lenton wrote: >> >>> On 13 March 2017 at 21:05, Michael Hudson-Doyle >>> wrote: >>> > If I add a >>> > time.Sleep(1*time.Millisecond) to a_go.go before the exec, the setuid bit >>> > is respected every time. >>> >>> on my way to bed, I'll give your response a proper read in the >>> morning, but note that my reproducer causes the issue a lot more >>> frequently than in "the real world" (snap run calling snap-confine >>> calling snap-exec), where delays are happening naturally (because the >>> programs aren't just calling exec, they actually have work to do :-p). >>> I don't have numbers for how often it happens in snappy; it's a lot >>> less frequent, but often enough to be annoying when working >>> interactively (and there are bug reports with these warnings/errors in >>> lp already). >> >> >> Oh yes, the sleep was just to allow the other threads to settle in the test >> case program. It's not a solution for the real world at all. >> >> Cheers, >> mwh >> -- >> 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: Netplan replug function is incompatible with ath9k_htc module
Thanks Loïc, I reported the bug and proposed a patch. Cheers, Nicolino Il 14/03/2017 11:29, Loïc Minier ha scritto: > Hi, > > On Tue, Mar 14, 2017 at 10:42 AM, Nicolino Curalli > wrote: > >> Our problem is testing our simple patch before open the bug report for >> netplat project: the problematic file is src/netplan. >> > (So you want to test an updated netplan binary.) > > How can we repack a core snap with different code per netplan? > You can either run netplan on Ubuntu classic, or you can simply run it by > hand on top of Ubuntu Core (e.g. from your home directory). > > How long does it take to have a patch like this to be accepted in core snap >> code? >> > It can be fast, but there are ~3-4 steps: > 1) merge proposal against netplan > 2) netplan upload to latest Ubuntu > 3) backport to LTS / PPA against which Core images are built > 4) next image build (every ~2w?) > > Cheers, > - Loïc Minier -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Part 2! Request for help / ideas to debug issue
As a followup, I added a mutex around pthread_create, and around the exec syscall, and the problem went away. This all in go's runtime; not a huge diff but they probably don't want the overhead (and that seems reasonable to me). Next I'm going to try to find a kernel person to take a look at this. On 13 March 2017 at 23:33, Michael Hudson-Doyle wrote: > On 14 March 2017 at 12:21, John Lenton wrote: > >> On 13 March 2017 at 21:05, Michael Hudson-Doyle >> wrote: >> > If I add a >> > time.Sleep(1*time.Millisecond) to a_go.go before the exec, the setuid bit >> > is respected every time. >> >> on my way to bed, I'll give your response a proper read in the >> morning, but note that my reproducer causes the issue a lot more >> frequently than in "the real world" (snap run calling snap-confine >> calling snap-exec), where delays are happening naturally (because the >> programs aren't just calling exec, they actually have work to do :-p). >> I don't have numbers for how often it happens in snappy; it's a lot >> less frequent, but often enough to be annoying when working >> interactively (and there are bug reports with these warnings/errors in >> lp already). > > > Oh yes, the sleep was just to allow the other threads to settle in the test > case program. It's not a solution for the real world at all. > > Cheers, > mwh > -- > 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: Netplan replug function is incompatible with ath9k_htc module
Hi, On Tue, Mar 14, 2017 at 10:42 AM, Nicolino Curalli wrote: > Our problem is testing our simple patch before open the bug report for > netplat project: the problematic file is src/netplan. > (So you want to test an updated netplan binary.) How can we repack a core snap with different code per netplan? > You can either run netplan on Ubuntu classic, or you can simply run it by hand on top of Ubuntu Core (e.g. from your home directory). How long does it take to have a patch like this to be accepted in core snap > code? > It can be fast, but there are ~3-4 steps: 1) merge proposal against netplan 2) netplan upload to latest Ubuntu 3) backport to LTS / PPA against which Core images are built 4) next image build (every ~2w?) Cheers, - Loïc Minier -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Netplan replug function is incompatible with ath9k_htc module
Hi all, we ( my work team and I ) are porting an allwinner H3 with wireless chip Atheros AR9271 to Ubuntu Core 16. We hit the following problem about the interaction between netplan and the ath9k_htc module, controlling the chip Atheros AR9271. If you run the following command netplan --debug apply or you use console-conf for setting the network interfaces we get the following messages : ** (generate:2261): DEBUG: Processing input file //etc/netplan/00-snapd-config.yaml.. ** (generate:2261): DEBUG: eth0: setting default backend to 1 ** (generate:2261): DEBUG: Generating output files.. ** (generate:2261): DEBUG: NetworkManager: definition eth0 is not for us (backend 1) DEBUG:netplan generated networkd configuration exists, restarting networkd DEBUG:no netplan generated NM configuration exists DEBUG:device lo operstate is unknown, not replugging DEBUG:device eth0 operstate is up, not replugging DEBUG:replug wlan0: unbinding 4-1:1.0 from /sys/bus/usb/drivers/ath9k_htc DEBUG:replug wlan0: rebinding 4-1:1.0 to /sys/bus/usb/drivers/ath9k_htc The last two row show two consecutive actions, one soon after the other: unbind and bind the usb device on usb hub. The module ath9k_htc doesn't work fine in this situation: the wireless interface disappears. Our problem can be fixed by using the same approcch used for mac80211_hwsim e mwifiex_pcie modules. We had a look at the netplan code. Our problem is testing our simple patch before open the bug report for netplat project: the problematic file is src/netplan. How can we repack a core snap with different code per netplan? How long does it take to have a patch like this to be accepted in core snap code? Cheers, Nicolino -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
