Trying to package /kbin for YunoHost, can you please check my repo?

I’m currently trying to package /kbin and I already have a preliminary version over here. However, I’m stuck in a few implementation details, namely:

  • Several items (the custom entries in the .env file, installing Composer, configuring Redis, using Doctrine to configure the database, installing Yarn and Supervisor, and the initial configuration of user and password) require a certain amount of manual intervention which I still haven’t figured how to script myself. In particular, I’m trying to follow the way that Flarum uses to package Composer, but it’s still work in progress.
  • The Nginx configuration recommended by the developer uses a sub-folder “/public”, whereas the default Nginx template expects the application to run directly from root (or to reconfigure it, but the documentation doesn’t quite explain how to do so!)

Can somebody with enough experience on the building process help me with those issues?

1 Like

For reference, we have an introduction to packaging in our documentation: Introduction to packaging | Yunohost Documentation

It would be nice to have a tad more specific questions. :wink:

Configuration files are automagically populated with variables from the install or upgrade scripts if you use the ynh_add_config helper.

For example, the server name for production on that line could be SERVER_NAME="__DOMAIN__", which would be replaced by the value of $domain, which is asked by the app installation form.

So far you have:

ynh_install_composer --phpversion="8.2"
ynh_install_nodejs --nodejs_version="16"
ynh_install_extra_app_dependencies --repo="deb stable main" --package="yarn" --key=""

I would replace 8.2 with $phpversion. Its value is automatically populated in packaging v2 if you put php8.2-xxx dependencies in the manifest like you did.

I would replace 16 by $nodejs_version and put its definition in scripts/

ynh_use_nodejs is already called by ynh_install_nodejs. :wink: Behold, your new sacred text: App helpers | Yunohost Documentation (have a look to the “Dude, show me the code!” links too, if you are curious).

Regarding yarn, I would follow its latest recommended installation method:

#ynh_use_nodejs (implied)
corepack enable
corepack prepare yarn@stable --activate

I don’t know them enough to help you right now. Let us know if you have specific questions. Bear in mind Redis is optional for /kbin.

Don’t. Translate these instructions into systemd instructions.

For reference, said NGINX conf. I would adapt it into somethin YunoHost can handle (apps cannot set their own server block). The following code is untested, but should give you a good first start.

location / {

    alias __INSTALL_DIR__/public/ ;

    try_files $uri $uri/ /index.php$is_args$args;

    location ~ ^/index\.php(/|$) {
        default_type application/x-httpd-php;
        fastcgi_pass unix:/var/run/php/php__PHPVERSION__-fpm-__APP__.sock;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
# Two lines below are untested, I never know what to put there.
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
        # Prevents URIs that include the front controller. This will 404:
        # http://domain.tld/index.php/some-path
        # Remove the internal directive to allow URIs like this

    # bypass thumbs cache image files
    location ~ ^/media/cache/resolve {
      expires 1M;
      access_log off;
      add_header Cache-Control "public";
      try_files $uri $uri/ /index.php?$query_string;
    location ~* .(js|webp|jpg|jpeg|gif|png|css|tgz|gz|rar|bz2|doc|pdf|ppt|tar|wav|bmp|rtf|swf|ico|flv|txt|woff|woff2|svg)$ {
        expires 30d;
        add_header Pragma "public";
        add_header Cache-Control "public";

   # return 404 for all other php files not matching the front controller
   # this prevents access to other php files you don't want to be accessible.
   location ~ \.php$ {
     return 404;
   client_max_body_size 10M;

Thank you very much for the guidance! And believe me, I’ve been combing the App Helpers documentation high and low - it’s just that I’m unsure of what does each part of the application do. I’ll also try to parameterize as much as possible, as you suggested.

1 Like

Packaging can be a lengthy and confusing process for a newcomer, thanks to you for being curious and willing to package /kbin. :wink:

I best learned how to package by stealing code heavily looking at what other packages were doing. Feel free to poke around the YunoHost-Apps organization on Github with recent apps for proper packaging practices.

Down the line, I would encourage you to transfer your repository to that org, we have a nice Continuous Integration (aka automated tests) for apps. If you code in a testing branch, open a PR to merge into master. In that PR, add a new comment !testme for the CI to start.


Could you try to package Tildes for ynh? Tildes / tildes · GitLab

I could try eventually! It would come handy for forums that do not need federation for whatever reason. But first things first!

1 Like

Just uploaded a few more changes. I’m still missing a few things, such as the Supervisor systemd configuration (it seems to require two separate services and I’m not sure how to parse them in a single systemd.service file such that YunoHost can compile them with its standard handler), the whole Mercure installation, and the admin management (in particular fetching the corresponding email address).

You can depoy multiple systemd services files with YunoHost: synapse_ynh/scripts/install at f1bc3d1f6a2362d2ebe4a432f3d09d2841187088 · YunoHost-Apps/synapse_ynh · GitHub

1 Like

Holy moly you’re in a roll Titus! I’ll make sure to upload those changes later today, so I can finally FINALLY start testing in my home server.

1 Like

Very few things left to do on my side:

  • Configuring keys for JWT authentication and HCaptcha plugins in the .env file (are they required to begin with?)
  • Add the new systemd configs as dependencies for the main app service
  • Actually install and configure Mercure, which seems like a fully manual procedure
  • Ensure that the changes work properly for the upgrade / backup / remove scripts, which is its own can of worms
1 Like

Any news with tildes? Will you do it?