Only bumped 64/32 bits to v1.8.3, since the ARM
Debian package requires YnH/Debian v11, and
I don't want people to prematurely upgrade their
instance to YnH/Debian v11 in order to update
Duniter to v1.8.3 in order to be able to continue
on the hard-fork
Test upgrade from v1.8.2~ynh2
I thought there were an issue to apply because of the already
existing and auto-generated BMAS endpoint
In reality, it wasn’t applied because of the issue from previous commit:
conf not applied in the right config directory
Remove autogenerated endpoint
I thought specifying 'duniter'’s $HOME to
/home/yunohost.app/duniter to be enough
The config actually went into:
/home/yunohost.app/duniter/.config/duniter_default/
Specify '--home $datadir', so the configuration goes into
/home/yunohost.app/duniter/duniter_default/
Update documentation accordingly with \$HOME to make
the already a long and relative complex command shorter
\# Protect webadmin
Modify 'main' permission group to protect the webadmin to the admin
Create 'apis' permission publicly accessible to make BMA and WS2P APIs
accessible to whole Internet and set --auth_header=false
\# Nginx misconfiguration
BMA is exposed on port 10901
The webadmin on port 9220
this explains why BMA was not accessible
because it was redirected to the webadmin
Was probably done to solve following problem with the CI
\# Move BMA to /bma and webadmin to root path '/'
Move the WebAdmin from '/webadmin' to '/' root path
Move BMA from '/' to '/bma/' path
In order to have passing access test on the root path with the CI
BMA returns a 502 HTTP error since no synchronization have been performed
therefore there is nothing to be displayed
Cesium and Silkaj support connection to BMA endpoint with a path in
\## TODOs in Duniter v1
There is no synchronization possible to duniter_ynh BMA api,
since Duniter doesn’t support specifying a path to 'sync' command
Can’t define a custom BMAS endpoint with /bma path in
The endpoint doesn’t stay, it seems its overwritten by the fact that when
specifying port 443, BMAS endpoint get created and overwrites this one
ynh_exec_as duniter duniter config --addep "BMAS $domain 443 /bma"
This is not as important as having a correct WS2P endpoint defined
for inter-node connection
Nice to have for BMA endpoint discovery
\# Clean Nginx config
Define once by moving WS, and SSOwat panel support to the common part
Remove /modules path, not really used anymore
Replace 127.0.0.1 by localhost
as well with shell in order to be able to run duniter with systemd
So, the configuration get saved in (/home/yunohost.app/duniter) $datadir
with which the service will run with
The consequence of this was at least a broken BMA access due to the
absense of configuration
Run Duniter with 'duniter' user to apply the configuration
to get the config file with correct permissions, using
"ynh_exec_as duniter", an equivalent of su - duniter -c "$cmd"
Upgrade from the state before the refactoring
from 1.8.1~ynh0 to 1.8.2~ynh1
Move Duniter home directory to the YunoHost App path
Check if the destination exists, meaning it’s not running < 1.8.1~ynh1
then run the datadir move
Package_check: Add upgrade check from commit before the refactoring
Fix: Remove admin permission deletion which prevent initial installation
Check if the admin and apis permissions do not exist before creating them.
Better cmds for legacy permission cleaning
Requires YnH v4.1 which implements this new permission system
Use ynh_permission_create helper
Set Duniter admin interface accessible to the selected admin
BMA is set as accessible to visitors by default
Remove / −> /webui redirection, since this change adds a tile to the admin
Remove deprecated permission system settings
Re-enable the web admin since it is protected again
Rename f() name
