Merge branch 'YunoHost:master' into patch-1

This commit is contained in:
slowphil 2021-05-26 23:01:44 +02:00
commit 6588a18706
6 changed files with 20 additions and 114 deletions

View file

@ -66,60 +66,13 @@ systemctl restart ssh
### Modifier le port SSH
Pour éviter des tentatives de connexion SSH par des robots qui scannent tout Internet pour tenter des connexions SSH avec tout serveur accessible, on peut modifier le port SSH.
**Sur votre serveur**, éditez le fichier de configuration SSH, pour modifier le port SSH.
C'est géré par un paramètre système, qui se charge de configurer les services SSH et Fail2Ban.
```bash
nano /etc/ssh/sshd_config
sudo yunohost settings set security.ssh.port -v <votre_numero_de_port_ssh>
```
**Recherchez la ligne « Port »** et remplacez le numéro du port (par défaut 22) par un autre numéro non utilisé
```bash
Port 22 # à remplacer par exemple par 9777
```
**Ouvrez le port** choisi dans le parefeu (vous pouvez utiliser l'option `-6` pour interdire la connexion via ipv4)
```bash
yunohost firewall allow TCP <votre_numero_de_port_ssh>
```
Sauvegardez et relancez le démon SSH.
```bash
systemctl restart ssh
```
Ensuite redémarrez le firewall iptables et fermez lancien port dans iptables.
```bash
yunohost firewall reload
yunohost firewall disallow TCP <votre numéro de port> # port par défaut 22
```
Il convient également de donner à `fail2ban` le nouveau port SSH à bloquer en cas de bannissement d'une adresse IP.
Pour cela il suffit de créer le fichier de configuration `my_ssh_port.conf` avec
```bash
nano /etc/fail2ban/jail.d/my_ssh_port.conf
```
et de le compléter ainsi :
```ini
[sshd]
port = <votre_numero_de_port_ssh>
```
Il reste enfin à relancer `fail2ban` pour prendre en compte la nouvelle configuration
```bash
systemctl restart fail2ban
```
**Pour les prochaines connexions SSH**, il faudra ajouter loption `-p` suivie du numéro de port SSH.
**Lors de la prochaine connexion SSH**, vous devrez ajouter le paramètre `-p` suivi du port SSH.
**Exemple**:

View file

@ -57,57 +57,10 @@ systemctl restart ssh
### Modify the SSH port
To prevent SSH connection attempts by robots that scan the Internet for any server with SSH enabled, you can change the SSH port.
**On your server**, edit the ssh configuration file, in order to modify the SSH port.
This is handled by a system setting, which takes care of updating the SSH and Fail2Ban configuration.
```bash
nano /etc/ssh/sshd_config
```
**Search the line "Port" and replace** port number (by default 22) by another unused number
```bash
# What ports, IPs and protocols we listen for
Port 22 # to replace by 9777 for example
```
**Open the port** in the firewall (you can use `-6` option to deny ipv4 connection)
```bash
yunohost firewall allow TCP 9777
```
Save and restart the SSH daemon. Switch over to the new port by restarting SSH.
```bash
systemctl restart ssh
```
Then restart the iptables firewall and close the old port in iptables.
```bash
yunohost firewall reload
yunohost firewall disallow TCP <your_old_ssh_port_number> # port by default 22
```
You also need to give `fail2ban` the new SSH port.
To do that you need to create the configuration file `my_ssh_port.conf` with the command
```bash
nano /etc/fail2ban/jail.d/my_ssh_port.conf
```
and you can then fill it in with
```ini
[sshd]
port = <your_ssh_port>
[sshd-ddos]
port = <your_ssh_port>
```
Finally you have to restart `fail2ban` in order to apply the new configuration
```bash
systemctl restart fail2ban
sudo yunohost settings set security.ssh.port -v <new_ssh_port_number>
```
**For the next SSH connections**, you need to add the `-p` option followed by the SSH port number.

View file

@ -43,7 +43,7 @@ Copy the [DNS zones](/dns_config), except for the NS fields, from the [registrar
#### 3. Switch the management of your domain name to the dynamic DNS server
This step consists in declaring to your [registrar](#registrar) that the DNS service will now be managed by the DynDNS service provider.
For this, fisrt declare in the NS field(s) the IP address provided by the DynDNS service.
For this, first declare in the NS field(s) the IP address provided by the DynDNS service.
Then, remove any other item in the [DNS zones](/dns_config) (except the previous NS fields), from the [registrar](#registrar).

View file

@ -39,7 +39,6 @@ You can [contribute to this list by adding something you'd like to be packaged](
| [Caliopen](https://www.caliopen.org) | A unified inteface for all your private communications | | [Package Draft](https://github.com/YunoHost-Apps/caliopen_ynh) |
| [cgit](https://git.zx2c4.com/cgit/about) | | | |
| [CheckUp](https://sourcegraph.github.io/checkup) | | [Upstream](https://github.com/sourcegraph/checkup) | |
| chtickynotes | Note manager | | [Package Draft](https://github.com/YunoHost-Apps/chtickynotes_ynh) |
| [Citadel-suite](https://www.citadel.org) | Groupware platform | | |
| [Cockpit](https://cockpit-project.org/) | | | [Package Draft](https://github.com/YunoHost-Apps/cockpit_ynh) |
| coin | Member dashboard for non profit ISP | [Upstream](https://code.ffdn.org/FFDN/coin/) | [Package Draft](https://github.com/YunoHost-Apps/coin_ynh) |
@ -158,7 +157,6 @@ You can [contribute to this list by adding something you'd like to be packaged](
| [Megaglest](https://megaglest.org/) | realtime stategy game | [Upstream](https://megaglest.org/linux-packages.html) | |
| [Metabase](https://www.metabase.com/) | analytics dashboard | [Upstream](https://github.com/metabase/metabase) | |
| microblog.pub | | [Upstream](https://github.com/tsileo/microblog.pub) | |
| miniflux | Minimal RSS reader | | [Package Draft](https://github.com/mat-mo/miniflux_ynh) |
| [Mirakel](https://mirakel.azapps.de/taskwarrior.html) | | [Upstream](https://github.com/GothenburgBitFactory/taskwarrior) | |
| modernpaste | A modern, feature-rich Pastebin alternative | [Upstream](https://github.com/LINKIWI/modern-paste) | [Package Draft](https://github.com/YunoHost-Apps/modernpaste_ynh) |
| [Modoboa](https://modoboa.org) | | [Upstream](https://github.com/modoboa/) | |

View file

@ -55,8 +55,8 @@ fi
#### Additional features from 4.1
- Label customization : this is the name displayed to end users in the user portal. You can provide a default label (for example app.admin maybe be labelled 'Admin interface'). The label may be changed later by the admin after installation.
- Enabling/disabling tile : this toggles wether or not an app is shown in the user portal (if the user has the corresponding permission). The corresponding option is called `show_tile` which may be `True` or `False`. A single app may have multiple tiles in the SSO. The url of each tile corresponds to the `url` parameter of the permission.
- Multiple url support: a permission may have additional urls associated to it. This give the possiblity to protect many url with the same permission - in particular for tricky use case (for example several pieces of admin interfaces spread over different subpaths).
- Enabling/disabling tile : this toggles wether or not an app is shown in the user portal (if the user has the corresponding permission). The corresponding option is called `show_tile` which may be `True` or `False`. A single app may have multiple tiles in the SSO. The URL of each tile corresponds to the `url` parameter of the permission.
- Multiple URL support: a permission may have additional urls associated to it. This give the possiblity to protect many url with the same permission - in particular for tricky use case (for example several pieces of admin interfaces spread over different subpaths).
- Protecting permission: As a packager, you may choose to "protect" a permission if you believe that it's not relevant for the admin to add/remove this permission to/from the visitors group. For example, this is the case for the API permission of Nextcloud, which in the vast majority of cases should be kept publicly because mobile client won't go through the SSO. Note that when using the helper `ynh_permission_update`, it's still possible to add/remove the `visitor` group of this permission.
- Disabling auth header: some app authentification mecanism do not appreciate that SSOwat injects the Authorization header (which is an essential mecanism for single sign-on). You can now choose to disable the auth header injection from SSOwat to fix this (instead of the previous hack of using `skipped_uris`)

View file

@ -7,9 +7,9 @@ routes:
default: '/packaging_apps_start'
---
This documentation is here is to provide all the basic concepts and vocabulary needed to understand app packaging. eg: shell, parsing, system administration...
This documentation is here to provide all the basic concepts and vocabulary needed to understand app packaging. eg: shell, parsing, system administration...
We will detail what is a YunoHost application package, how it works, how to make your own package and how to find help if you need it.
We will detail what a YunoHost application package is, how it works, how to make your own package and how to find help if you need it.
## What is a YunoHost application package
@ -19,7 +19,7 @@ To be able to do that, we need to remember that YunoHost at its core is a server
If you have ever installed a web application manually, you already know that the process is in reality far more complex, usually involving a lot of steps and discipline.
This is what application packaging is, a series of scripts that automate the installation of a web application and its configuration in order to provide the final user with a few clicks installation process.
This is what application packaging is: a series of scripts that automate the installation of a web application and its configuration in order to provide the final user with a few clicks installation process.
### How it works
@ -31,12 +31,14 @@ From the final user perspective, it is as simple as it can be:
4. Application is ready to use
There is more to see backstage:
First, when the application is selected, YunoHost will retrieve the corresponding package from github. eg: [Custom Webapp](https://github.com/YunoHost-Apps/my_webapp_ynh).
Then, YunoHost will read the manifest.json file to know what questions to ask the user through the form.
These seamingly trivial questions are very important. Usually you would need to ask for the domain on which to install, the path to access, the user that will be designated administrator and the default language for the application.
These seemingly trivial questions are very important. Usually you would need to ask for the domain on which to install, the path to access, the user that will be designated administrator and the default language for the application.
These are critical to configure appropriately the web application during the installation process. To do so, YunoHost will retrieve the answers given by the user and send them to the installation script located in the package "*scripts*" folder.
These are critical to appropriately configure the web application during the installation process. To do so, YunoHost will retrieve the answers given by the user and send them to the installation script located in the package "*scripts*" folder.
The install script will handle the user answers to complete the process as you would have done manually.
@ -54,9 +56,9 @@ You can ony interact with your server through the command line as it does not pr
Package scripts are therefore a series of bash commands as if you had typed them directly in the ssh console.
To know what you can write in a bash script, you should start reading this [simple tutorial](https://debian-facile.org/doc:programmation:shells:debuter-avec-les-scripts-shell-bash) or this [more advanced one](http://aral.iut-rodez.fr/fr/sanchis/enseignement/bash/index.html).
To learn what you can write in a bash script, you should start reading this [simple tutorial](https://debian-facile.org/doc:programmation:shells:debuter-avec-les-scripts-shell-bash) or this [more advanced one](http://aral.iut-rodez.fr/fr/sanchis/enseignement/bash/index.html).
### Ok, I'm good! Where do I start?
### Okay, I'm good! Where do I start?
Before starting the packaging process, you need to successfully install the application. The script will only perform what you instruct it to do.