Hi Andrew Andrew Wong <[email protected]> writes:
> On 6/26/25 6:47a, Sébastien Gendre wrote:
>> The first step would be to define a Guix package.
>> But what about a PHP web app that ask you to remove an `install.php'
>> file from its source directory after the first run and who store the
>> data as files in a sub-folder of their source code ? I remember a forum
>> written like that (can't remember the name, it was an hold school forum
>> and a free software).
>
> I also suspect these kinds of web apps would work by providing the
> upstream snapshot of their "working directory" in a store item, and
> then having a service that copies that working directory to the proper
> place.
It's a good idea. Also, depending of what the "install.php" script do,
maybe the web-app service type could do the same by itself. Like that,
instead of accessing the "install.php" from a browser to configure the
web app, sys-admin could use the config of the web app service type.
>> But what about the integration with the database or other softwares ?
>> Does the new web app service type need to extend the service type of the
>> database ? Or do we use the web app service configuration to tell which
>> database to use and how to connect to it ? Same questions for the
>> reverse proxy, the cache software, etc.
>
> Regarding databases and other interactions, I feel like your intuition
> is in the right place. I would reason that it makes sense to extend
> the target service, since configuration is required in both the client
> and host service (I'd imagine a database service would need
> configuration for each "client" program using it). Can extensions be
> parameterized, or are they static for a given service-type? Perhaps
> service-types can be generated from a procedure? I'm imagining a
> "freshrss-configuration" field that accepts a service-type as its
> #:database argument.
I was thinking about it this morning, but maybe we can have 2 service
types:
* One that only configure and run an instance of the web app
* One that run and configure all the software stack, database included
The first service type, example `freshrss-service-type', would only
extend `account-service-type' to create a user account to run FreshRSS
and `shepherd-root-service-type' to add a shepherd service that will run
the instance of FreshRSS.
Then, a sys admin is free to run the database on the system she or he
want. It will just need to use the `freshrss-config' to indicate how to
connect to the database.
The second service type, example `freshrss-fullstack-type', would extend
`freshrss-sercive-type' to run FreshRSS, but also
`postgresql-service-type' to run the database, `nginx-service-type' as a
revers-proxy and `certbot-service-type' to get certificates from Let's
Encrypt. All extended service types would be configured by
`freshrss-fullstack-type' to work together.
Then, a sys admin only need to add an instance of
`freshrss-fullstack-type' in her or his operating system config, with
minimum config like the domain name used, then reconfigure the system
and voilà.
Or, instead of 2 service types, only the first one and an example of
operating system config with all the needed services to have a full
stack. This example could be put in a Guix Channel and a sys admin could
inherit it in her or his own system config.
But I'm not enough experimented with Guix System to tell if it's a good
idea, or not.
>> The extension of other service types for the database, the cache, etc,
>> is the most easy to use for the admin sys. But it will not permit to
>> have the web app on one host, the database on another, etc.
>
> Perhaps there could be a "remote-database-connection" service?
If you can configure the web app to tell it which database to connect
to, it should work with local and remote connection.
>> And what about when the web app ask to run a script on first run, or to
>> manually create a database: What would be the best way to integrate it
>> in Guix System ?
>
> I would guess these would work as "oneshot" services that check if a
> configuration action was done, and does it if necessary. This is the
> category of services that, e.g. configures your shell and environment
> variables.
It's a good idea. After a check on the documentation, Guix provide a
`postgresql-role-service-type' to create a role with it's own database.
Maybe it could be a good start.
It just miss the possibility to define the template of the database
entirely from the service config. For now, you can only define the
template by giving it's name. And the template need to be already known
by the database.
Or maybe the template need to be provided by a package ? So, when the
package is installed, a sys admin just need to use
`postgresql-role-service-type' to create a role for the web app and
choose the corresponding template to have the needed database.
>> For running the web app instance, the best way is to create a Shepherd
>> service ? But what about running multiple instances on the same
>> machine ? Do the new web app service type need to manage it itself ? Or
>> do we ask admin sys to run one instance per system and use system
>> containers to have multiple instances in the same machine ?
>
> Perhaps the "term-tty{1,2,3...}" services can be of reference here.
I wonder if the most easy way to run multiple instances of the same
service, for now, is either:
* Run multiple Guix system in container, one for each instance
* Using `oci-container-service-type' to run each instance in an app
container
With the second solution, the sys admin would need to install Docker and
loose the ability to use the configuration mechanism of Guix (like
a `freshrss-config').
signature.asc
Description: PGP signature
