Web Service (since DSM7.0)

Description

When in install/remove package stage, worker will update/remove service and default portal setting.

When in start/stop package stage, worker will start/stop service setting.

FROM_PREINST_TO_PREUNINST

• Acquire(): sync information in user specified /var/package/${package}/target/*.json into user setting, do migrate and setup portal and service which user specify in resource file
• Release(): remove user's setting

FROM_ENABLE_TO_DISABLE

• Acquire(): copy *.json and .mustache under /var/packages/${package}/target/ into /usr/syno/etc/www/app.d/ and enable service setting.
• Release(): remove files which copied into /usr/syno/etc/www/app.d/ and disable service setting

Provider

WebStation

Timing

FROM_PREINST_TO_PREUNINST FROM_ENABLE_TO_DISABLE

Lower privilege

According to package center privilege policy, web package will get a confined privilege during installation and run time. In order to setup environment for web package, webservice worker provide a mechanism called pkg_dir_prepare to assist web package creating website root directory and setting corresponding owner, group. The detail of pkg_dir_prepare will be elaborate in pkg_dir_prepare section.

Environment Variables

None

Updatable

No

Syntax

"webservice":{
    "services": [{
        service setting 1
    },{
        service setting 2
    }...],
    "portals": [{
        default portal setting 1
    },{
        default portal setting 2
    }],
    "migrate": {
        Migration data
    },
    "pkg_dir_prepare": [{
        package directory prepare settings
    }]
}

Framework will use default value when field is not required and doesn't exist or is null.

services

Web services which are going to register, allow multiple web services to register. For more detail please see Web Service

portals

Default portal which are going to register for access portal of services and will craete UI Shortcut. Devided into server portal and alias portal.

Important: Default server portal is not allowed registered as name base portal, since you may not be able to lookup FQDN's correct IP from client side.

Example:

Alias Portal
{
    "service": "wordpress",
    "name": "wordpress",
    "app": "SYNO.SDS.WordPress",
    "type": "alias",
    "alias": "wordpress"
}
Server Portal
{
    "service": "wordpress",
    "name": "wordpress",
    "app": "SYNO.SDS.WordPress",
    "type": "server",
    "http_port": [9000],
    "https_port": [9001]
}

migrate

Migrate assist package migration from older version ( < DSM7.0 ) to newer version. Supporting two kinds of migrate setting - root and vhost.

root

"root": [{
    "old": "wordpress",
    "new": "wordpress"
}]

vhost

"vhost": [{
    "root": "wordpress",
    "service": "wordpress"
}]

pkg_dir_prepare

Webservice worker will set up website root directory under web_packages according to the information web package specified in worker config. The worker will remove the target directory under web_package between preuninst and postuninst. Make sure to backup your website root in preuninst script during upgrade.

pkg_dir_prepare example:

"pkg_dir_prepare": [{
    "source": "/var/package/WordPress/target/src",
    "target": "wordpress",
    "mode": "0755",
    "group": "http",
    "user": "WordPress"
}]

Web Service

Package could register to WebStation via WebStation webapi or Package Worker.

• Web Service support following types
  • static service
    • static web pages web services
  • nginx_php service
    • web service that useing Nginx as HTTP server and PHP as scripts, e.g. phpMyAdmin
    • Will generate PHP Profile after service registered. You can modify it in WebStation -> Script Language Settings -> PHP.
  • apache_php service
    • web service that using Apache as HTTP server adn PHP as scripts, e.g. WordPress
    • Will gengerate PHP Profile after service registerd. You can modify it in WebStation -> Script Language Settings -> PHP.
  • reverse_proxy service
    • web service depending on reverse proxy, e.g. Docker-GitLab

common field

Detail of php profile

static service

When type is static, system will serve your pacakge with nginx.

static service worker setting example:

{
        "service": "static",
        "display_name": "static service",
        "support_alias": true,
        "support_server": true,
        "type": "static",
        "root": "static_dir",
        "icon": "ui/Wordpress_{0}.png"
    }

nginx_php service

When type is nginx_php, system will serve your package with nginx. The php file will be executed by php-fpm. Php-fpm default behavior can be defined in field `php

nginx_php service worker setting example:

{
        "service": "wordpress",
        "display_name": "WordPress",
        "support_alias": true,
        "support_server": true,
        "type": "nginx_php",
        "root": "wordpress",
        "icon": "ui/Wordpress_{0}.png",
        "php": {
            "profile_name": "WordPress Profile",
            "profile_desc": "PHP Profile for WordPress",
            "backend": 6,
            "open_basedir": "/var/services/web_packages/wordpress:/tmp:/var/services/tmp",
            "extensions": [
                "mysql",
                "mysqli",
                "pdo_mysql",
                "curl",
                "gd",
                "iconv"
            ],
            "php_settings": {
                "mysql.default_socket": "/run/mysqld/mysqld10.sock",
                "mysqli.default_socket": "mysqli.default_socket",
                "pdo_mysql.default_socket": "/run/mysqld/mysqld10.sock",
                "mysql.default_port": "3307",
                "mysqli.default_port": "3307"
            }
        },
        "connect_timeout": 60,
        "read_timeout": 3600,
        "send_timeout": 60
    }

apache_php service

When type is apache_php, nginx will pass request to apache server. The php file will be executed by php-fpm. Php-fpm default behavior can be defined in field php. Compare to nginx_php, apache_php with additional filed backend to specify apache version

apache_php service worker setting example:

{
        "service": "wordpress",
        "display_name": "WordPress",
        "support_alias": true,
        "support_server": true,
        "type": "apache_php",
        "root": "wordpress",
        "backend": 2,
        "icon": "ui/Wordpress_{0}.png",
        "php": {
            "profile_name": "WordPress Profile",
            "profile_desc": "PHP Profile for WordPress",
            "backend": 6,
            "open_basedir": "/var/services/web_packages/wordpress:/tmp:/var/services/tmp",
            "extensions": [
                "mysql",
                "mysqli",
                "pdo_mysql",
                "curl",
                "gd",
                "iconv"
            ],
            "php_settings": {
                "mysql.default_socket": "/run/mysqld/mysqld10.sock",
                "mysqli.default_socket": "mysqli.default_socket",
                "pdo_mysql.default_socket": "/run/mysqld/mysqld10.sock",
                "mysql.default_port": "3307",
                "mysqli.default_port": "3307"
            }
        },
        "intercept_errors": false,
        "connect_timeout": 60,
        "read_timeout": 3600,
        "send_timeout": 60
    }

reverse_proxy service

When type is reverse_proxy, nginx will proxy request to target services

You could define proxy header to modify proxy behavior, e.g. modify host or turn on websocket. If need support of websocket, you should specify Upgrade and Connection header as shown below:

reverse_proxy service worker setting example:

{
        "service": "gitlab",
        "display_name": "Git Lab",
        "support_alias": true,
        "support_server": true,
        "type": "reverse_proxy",
        "icon": "ui/gitlab_{0}.png",
        "proxy_target": "http://gitlab:30000",
        "proxy_headers": [{
            "name": "host",
            "value": "gitlab"
        },{
            "name": "Upgrade",
            "value": "$http_upgrade"
        },{
            "name": "Connection",
            "value": "$connection_upgrade"
        }]
        "connect_timeout": 60,
        "read_timeout": 3600,
        "send_timeout": 60
    }

Custom Rule

• You could modify config via custom_rule field in json key value format. Json key is target name, json value is target config's mustache file path。
• You can reference nginx_service_template.mustache, apache22_service_template.mustache and apache24_service_template.mustache under /var/packages/WebStation/target/misc for routing rule that you can modify.
• Field {{ \@json key\@ }} in mustache template will be replaced by files specified in custom_rule
• You should consider the compatibility between server and alias, and could use {{#alias}} to seperate these two different routing rules.

Custom rule example:

"custom_rule": {
    "global_rule": "/var/packages/WordPress/target/misc/nginx_global.mustache",
    "fastcgi_rule": "/var/packages/WordPress/target/misc/nginx_fastcgi.mustache",
    "proxy_rule": "/var/packages/WordPress/target/misc/nginx_proxy.mustache",
    "apache_rule": "/var/packages/WordPress/target/misc/apache.mustache"
}

Custom rule type