One of the key feature of YunoHost is the ability to easily install applications which are then immediately usable. Example of applications include a blog system, a "cloud" (to host and sync files), a website, an RSS reader...
Applications can be installed and managed through the webadmin interface in Applications
or through commands of the yunohost app
category.
The application catalog and its categories can be browsed directly from the webadmin by clicking on the Install
button in the apps list, or from this documentation.
Be careful and stay reasonable on the number of installed applications. Each additional installation increases the attack surface and the risk of failure. Ideally, if you want to test, do it with another instance for example in a virtual machine.
Let's say you want to install a Custom Webapp. Before actually running the installation steps, YunoHost will usually have you fill in a form to properly set it up for you.
Among specific questions, forms usually ask you to choose a domain and a path onto which the app will be accessible.
In the context of YunoHost, it is quite common to have a single (or a few) domains on which several apps are installed in "subpaths", so that you end up with something like this:
yolo.com
├── /blog : Wordpress (a blog)
├── /cloud : Nextcloud (a cloud service)
├── /rss : TinyTiny RSS (a RSS reader)
├── /wiki : DokuWiki (a wiki)
Alternatively, you may choose to install each (or some) apps on a dedicated domain. Beyond the aesthetic, using sub-domains instead of sub-paths allows the possibility to move a service to another server more easily. Also, some applications may need an entire domain dedicated to them, for technical reasons. The disadvantage is that you have to add a new domain each time, and therefore potentially configure additional DNS records, restart the diagnostics and install a new Let's Encrypt certificate.
This might look prettier for end users, but is generally considered more complicated and less efficient in the context of YunoHost, since you need to add a new domain each time. Nevertheless, some apps might need an entire domain dedicated to them, for technical reasons.
If all apps from the previous example were installed on a separate domain, this would give something like this:
blog.yolo.com : Wordpress (a blog)
cloud.yolo.com : Nextcloud (a cloud service)
rss.yolo.com : TinyTiny RSS (a RSS reader)
wiki.yolo.com : DokuWiki (a wiki)
Many applications integrate a feature that allows you to change the URL of your application. This choice between subpath and subdomain can be reversed in some cases via a simple manipulation in the administration interface.
The installation form usually asks whether or not the app should be publically accessible. If you choose to not make it public, only users logged in YunoHost will be able to reach it.
After installation, this can be configured via the webadmin in the Groups and permissions panel, or similarly via the command-line subcategory yunohost user permission
.
Some applications need to give you instructions, URLs or credentials once they are installed. So remember to check the email of the first user account or the admin user selected before installation, if it was prompted.
Some applications support the ability to be installed several times (at different locations) ! To do so, just go another time in Applications > Install
, and select again the application to install.
Applications that allow users to register may support integration with the LDAP / Single Sign On of YunoHost, so that users who connect to the user portal can be automatically logged in all these apps.
However, some applications do not support this as it can be either not implemented in the upstream, or the package does not work on this part yet. This information is usually available on the README of the application package.
After installation, some settings handled by YunoHost can be tweaked, such as user and group permissions, application's tile and label in the SSO page, or its access URL.
You can access the app's operations page by clicking its name in the applications list.
You can also delete the application from this page.
From the command line, you can change:
yunohost app change-label <app> <new_label>
yunohost app change-url app [-d <DOMAIN>] [-p <PATH>]
You can also delete the app: yunohost app remove <app>
<app>
is to be replaced with the app's ID. If this is the first instance of the app, like Nextcloud, the ID is nextcloud
. If this is the second, then it's nextcloud__2
and so on. To list all your apps and check their ID, you can run yunohost app info
.
Some apps include a configuration panel, which features actions and settings specific for each app that they usually do not handle themselves. They can also spare you the need for altering configuration files by hand.
Configuration panels are not meant to tweak every aspects of the apps. You will surely use their own administration panels more often than YunoHost's configuration panels.
The configuration panels are accessible in the webadmin in their operations page, trough the Config panel
button.
From the command line, you can list the configuration panel settings with the following command: yunohost app config get <app>
$ yunohost app config get my_webapp
main.php_fpm_config.phpversion:
ask: PHP version
value: none
main.sftp.password:
ask: Set a password for the SFTP access
value: **************
main.sftp.with_sftp:
ask: Do you need a SFTP access?
value: yes
To change a setting, either use yunohost app config set <app>
to get prompted about all the settings, or use yunohost app config set <app> <key> -v <new_value>
to alter a specific one.
The <key>
is the setting name, for example main.sftp.with_sftp
from above.
Starting YunoHost v11.1.21.4, if you need to execute commands with the app's binary, or PHP commands, etc., you can execute the command yunohost app shell <app>
.
It will:
/var/www/<app>
)php
, so that it points to the PHP version used by the appApplications must be packaged manually by application packagers/maintainers. Apps can be integrated with YunoHost to support upgrades, backup/restore and LDAP/SSO integration among other things.
If you want to learn or contribute to app packaging, please check the contributor documentation.
Automated tests are being run regularly to test the integration and quality of all apps who were declared to be working
by packagers. The result is a level between 0 and 8, whose meaning is detailed on this page. Some tests results may also be available on this dashboard.
By default, only applications of sufficient quality are offered. When the quality of an application drops and until the problem is reolved, the app is hidden from the catalog to prevent its installation and its upgrades are put on hold.
Found errors? Think you can improve this documentation? Simply click the Edit link at the top of the page, and then the icon on Github to suggest changes.
Powered by Grav + with by Trilby Media. • Terms of Service