From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Allan Webber Subject: Re: Service refactoring Date: Fri, 25 Sep 2015 17:50:36 -0500 Message-ID: <87mvwartuq.fsf@dustycloud.org> References: <87a8t3mc2v.fsf@netris.org> <87d1xyk45i.fsf@igalia.com> <87vbbn44zi.fsf_-_@gnu.org> <87a8shp05k.fsf@gnu.org> <87r3lsrxqp.fsf@igalia.com> <877fnjn4nd.fsf@gnu.org> <87r3lomfgs.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zfbup-00087Y-Uv for guix-devel@gnu.org; Fri, 25 Sep 2015 18:56:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zfbul-0003O3-NX for guix-devel@gnu.org; Fri, 25 Sep 2015 18:56:31 -0400 In-reply-to: <87r3lomfgs.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel Ludovic Court=C3=A8s writes: > "Thompson, David" skribis: > >> On Mon, Sep 21, 2015 at 12:00 PM, Ludovic Court=C3=A8s = wrote: >>> Andy Wingo skribis: >>> >>>> On Sun 20 Sep 2015 15:42, ludo@gnu.org (Ludovic Court=C3=A8s) writes= : >>>> >>>>> I=E2=80=99m quite happy with the result, but comments are welcome! = I=E2=80=99ll convert >>>>> some more services to see how it goes. >>>> >>>> Neat! Sounds great. One question: there are some services like col= ord >>>> or geoclue that don't need to be managed by DMD, but are just declar= ed >>>> as services so that their users are created, there /var/foo director= ies >>>> are created, etc. The can be started by D-Bus as needed. Does the = new >>>> design support services of this kind? >>> >>> Yes it does. >>> >>> =E2=80=98colord=E2=80=99 will =E2=80=9Cextend=E2=80=9D the D-Bus serv= ice by giving it its package object >>> (thus its .service files), it will extend the activation service by >>> providing it #~(mkdir "/var/foo"), and it will extend the account >>> service by passing it its user accounts/groups. >> >> I'm picturing an enhanced 'nginx-service' that is able to accept site >> configuration files from other services (say, a MediaGoblin service) >> and it sounds like a great feature. > > Yes, that=E2=80=99s the idea. You've already heard me say it elsewhere, but I'm suuuuuuper excited about this. I've already written about it on the pumpiverse, so for posterity, here's that link: https://identi.ca/cwebber/note/vNnKxmgtQBOO2W82r0ZgwA Glad to see mediagoblin-service being used as an example too :) >> Now, is the following scenario possible?: 'mediagoblin-service' can >> extend both 'apache-service' and 'nginx-service', and when the system >> configuration is realized, the web service the user has chosen is >> extended. > > If it makes sense, there could be a single =E2=80=98web-service-type=E2= =80=99 that both > Apache httpd and NGINX would implement. The MediaGoblin service would > extend them by providing something like a vhost specification I suppose= ? I think that's right. > Now, perhaps we would need separate =E2=80=98httpd-service-type=E2=80=99= and > =E2=80=98nginx-service-type=E2=80=99 if httpd and NGINX happen to be ex= tensible in > different ways. I don=E2=80=99t really know these tools, but it would = be good > to see how we would do it. WDYT? > > Ludo=E2=80=99. So, nginx and apache have pretty drastically different config file types. However, most of the things users want I think are compatible with both. We probably want a "minimal" service that just accepts whatever config files for apache and nginx, and just lets the user specify that whole manually. We can have more advanced procedures for building up a config file by translating our world-of-s-expressions or whatever schemey types into the config file format... but given "just how much" you can do with nginx and apache that is just so wildly different between the two, we probably want something that provides an abastract representation of what most web applications need, some sort of "medium common denominator" (I don't think we need to shoot for lowest here!). That way we can have a general way of letting applications specify what they need from their web server, but also allow a sysadmin to go "full on manual" if they need to with the config file formats. Dave / Ludo: Does that fit with what you two are thinking as well? - cwebb