[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gitlab package (was Re: Opt out style recommends)



On Apr 12, 2016 00:34, "Tollef Fog Heen" <tfheen@err.no> wrote:
>
> ]] Michael Lustfield
>
> > In this particular case, I would suggest first making letsencrypt a
> > Suggests. Then, I would suggest considering snakeoil for the https or
> > just installing with http-only and providing a documented tool for
> > moving to using letsencrypt. You and I both know that we're only
> > talking about a web server configuration... shouldn't the web server
> > be the one suggesting it? ... it doesn't because the web server
> > packages consider SSL/TLS to be its own thing entirely that shouldn't
> > be mixed in with other package deployments.
>
> The web app might well need to know whether it's being accessed over TLS
> or not.  If it is, any cookies it sets should be marked with «secure» so
> they're never sent in plaintext.

An app should know about HTTP vs. HTTPS, yes. However, that's not relevant to this discussion because an app should be finding that information via a header the web server sends it. It's one of the standard headers that nobody pays much attention to. :)

I think party of the problem here is the whole omnibus logic that wants to configure the whole environment which immediately steps on sys admin toes.

The best thing I can think of is to stick with HTTP out of the box and have another utility that handles modifying configuration.

You could have all of these prompts (http vs. https; managed certs vs. letsencrypt) be debconf questions with a post install script that reads those answers. If nothing was selected, use the default. Otherwise, do whatever else. This would provide flexibility to rerun and modify later as well. At least this would be suitable to how gitlab-omnibus likes to configure itself and it's "modules."

For admins with config management tools, they can pre-answer your debconf questions and have SSL right away if they so choose. The reconfiguration can easily be triggered via dpkg reconfigure, which tends to be a first step for extra config in Debian.

This lets you deploy gitlab out of the box in a manner that is the most likely to work on all systems and leaves the ability to configure extras to your heart's content.

Either that or I'm missing something. If I am, please teach me my lesson! :)


Reply to: