Ubuntu system image

Bug #1278589
Comment #3

Comment 3 for bug 1278589

Revision history for this message

Barry Warsaw (barry) wrote on 2014-02-25:

channel.ini should be thought of as an override for client.ini, although at the moment, only the [system] settings can be overridden. It would be a trivial change to allow it to also override the [service] section. So for the moment, let's treat client.ini and channel.ini as essentially equivalent. In fact, in that case, [service]use_https would always default to yes/true/1 but channel.ini could override that to no/false/0.

I still like being explicit about whether to use https or not, rather than implying it from the port settings. I guess one advantage of stgraber's suggestion though is that you could run a server *only* over https and never hit http. Is that a valid use case? One confusion (and the source of my hesitancy) about allowing *_port=0 to mean "disable" is that in some cases, I've seen *_port=0 to mean "use the default port".

The other implication in the irc discussion is whether system-image should auto-detect whether https is available, or perhaps there should be a flag in channels.json. There's a bootstrapping problem with that though (and in fact with setting this in channels.ini too), in that several https-only steps have to be performed before you can trustfully download the channels.json file (e.g. the blacklist is downloaded over https). Worse, setting this in channel.ini means you'd have to do at least one update to end up with a channel.ini file, since that is not laid down with the initial flashing.

We do also have a settings facility, so you could imagine having a system-settings ui panel that allowed you to turn off https (or alternatively http). This would call into the existing SetSetting() D-Bus API, flipping the appropriate flags, which would be consulted when the configuration object is created. This would be safe from bootstrapping issues, would require an explicit action on the part of the user (something I'd prefer), and would not require access to a read-only file system. It would of course mean that there'd be a ui component to this change.

(Aside: how are we actually going to do configuration of services and apps when we can't write to /etc? ;)

channel.ini should be thought of as an override for client.ini, although at the moment, only the [system] settings can be overridden.  It would be a trivial change to allow it to also override the [service] section.  So for the moment, let's treat client.ini and channel.ini as essentially equivalent.  In fact, in that case, [service]use_https would always default to yes/true/1 but channel.ini could override that to no/false/0.

I still like being explicit about whether to use https or not, rather than implying it from the port settings.  I guess one advantage of stgraber's suggestion though is that you could run a server *only* over https and never hit http.  Is that a valid use case?  One confusion (and the source of my hesitancy) about allowing *_port=0 to mean "disable" is that in some cases, I've seen *_port=0 to mean "use the default port".

The other implication in the irc discussion is whether system-image should auto-detect whether https is available, or perhaps there should be a flag in channels.json.  There's a bootstrapping problem with that though (and in fact with setting this in channels.ini too), in that several https-only steps have to be performed before you can trustfully download the channels.json file (e.g. the blacklist is downloaded over https).  Worse, setting this in channel.ini means you'd have to do at least one update to end up with a channel.ini file, since that is not laid down with the initial flashing.

We do also have a settings facility, so you could imagine having a system-settings ui panel that allowed you to turn off https (or alternatively http).  This would call into the existing SetSetting() D-Bus API, flipping the appropriate flags, which would be consulted when the configuration object is created.  This would be safe from bootstrapping issues, would require an explicit action on the part of the user (something I'd prefer), and would not require access to a read-only file system.  It would of course mean that there'd be a ui component to this change.

(Aside: how are we actually going to do configuration of services and apps when we can't write to /etc? ;)