Ubuntu Core: how the file-system works

[Luca Dionisi]

On Fri, Jan 20, 2017 at 3:36 PM, Mark Shuttleworth <mark at ubuntu.com> wrote:
> On 20/01/17 06:33, Luca Dionisi wrote:
>> Since my "thingy" is going to sport an experimental routing protocol,
>> I need
>> to change some files on the fly. For instance /etc/iproute/rt_tables. Which
>> I already see that is not writeable in my Ubuntu Core install.
>>
>> Also I am going to use some commands that I haven't yet tested on Ubuntu
>> Core. Mostly "ip" and "iptables", also in non-default network namespaces.
>> And I don't know if they need internally write-access to some file.
>>
>> Do you see anything about it that would be infeasible in a Ubuntu Core as
>> it currently stands?
>
> That all sounds like stuff we would want to be doable. There are a
> number of folks using Ubuntu Core for networking kit, so we are adding
> capabilities for that domain all the time. We just recently added
> network namespace control.
>
> Generally, you want to think about how best to express config in a way
> that easily survives upgrades. Editing something like rt_tables should
> be fine. But where you have something that multiple pieces want to edit,
> or a set of things which need to line up, we need to design a config
> item which drives those things consistently so the device can *never*
> end up in a broken state, by design. Make sense?

It certainly makes sense.

I think that, when in production, my snap will have confinement enabled so
that the user will have to hook the right capabilities from the core snap.

For now, I'd like to produce a unconfined snap for my tests.

If I understand it correctly, an unconfined app will be able in the system
to do whatever my standard user would be able to. For instance, if I
log into my ubucore16 (the name of my KVM instance) and issue:
 sudo sysctl net.ipv4.ip_forward=1
    -or-
 sudo ip address add 10.0.0.10 dev eth0
it reports success. Thus, if I run an unconfined app which tries to do the
same it will succeed. Whilst a strictly confined app would not, if it is
not hooked to a certain capability.
So far, so good?

As for particular config files, with the exception of rt_tables, my app
currently doesn't need to save or edit files that other apps would read
or modify. It doesn't need to save configurations that would have to
survive upgrades, either.

On Fri, Jan 20, 2017 at 3:54 PM, Oliver Grawert <ogra at ubuntu.com> wrote:
> my first step here would be to use the default ubuntu-core image and
> start working on a snap you can install on top of it that uses the
> existing interfaces. also take a look at the source of existing snaps
> for inspiration i.e. there is a "ufw" snap that does firewalling that
> should show how you can be able to manipulate iptables with
> thefirewall-control interface.

In my app I do network-control-related tasks by simply spawning standard
linux commands. With g_spawn_async_with_pipes.

I don't use other "interfaces" and I would prefer not to use any
particular interface that ties my program to one platform. Or do I
misunderstand what you mean by "the firewall-control interface?"

> every time you hit a roadblock you file a bug and ask for extension of
> the interface or for a new interface to be added (and indeed we also
> accept patches if you already have an idea for a solution ;) ).
> eventually you will end up with the system you desire.

Glad to see positive approach.