yunohost-apps / duniter_ynh Goto Github PK

j'ai installé Yunohost sur un VPS chez Scaleway et j'y est donc aussi installé Duniter_ynh.

Seulement j'ai ce message d'erreur dans les logs :
2016-09-23T10:33:36+00:00 error No UPnP gateway found: your node won't be reachable from the Internet. Use --noupnp option to avoid this message.

Une idée ? :(

voici une partie des messages au lancement d'une MAJ :

Attention : dpkg : avertissement : lors de la suppression de duniter, le répertoire « /opt » n'était pas vide, donc il n'a pas été supprimé
Traitement des actions différées (« triggers ») pour mime-support (3.58) ...
+ INSTALL_DUNITER_DEBIAN_PACKAGE
++ head -1
++ grep x64
++ cut '-d"' -f4
++ grep browser_
++ curl -s https://api.github.com/repos/duniter/duniter/releases
Attention : grep: erreur d'écriture
Attention : grep: erreur d'écriture: Relais brisé (pipe)
+ url=https://github.com/duniter/duniter/releases/download/v0.30.11/duniter-v0.30.11-linux-x64.deb
++ cut -d/ -f8
++ head -1
++ grep x64
++ grep browser_
++ curl -s https://api.github.com/repos/duniter/duniter/releases
Attention : grep: erreur d'écriture
Attention : grep: erreur d'écriture: Relais brisé (pipe)
+ version=v0.30.11
+ wget -nc --quiet https://github.com/duniter/duniter/releases/download/v0.30.11/duniter-v0.30.11-linux-x64.deb -P /tmp

Bonjour,
Il serait bien, pour une meilleure gestion des applications et une meilleure gestion des contributions, que toutes les apps rejoignent l'organisation Yunohost-Apps.
Merci,
frju365

Hello,
To manage in a better way the contributions and the Apps, we invite you to change the ownership of your app to Yunohost-Apps Organization.
Thanks,
frju365

Some home routers does not authorize the NAT on 80 and 443 ports

It would be great if we could configure other ports on installation.

Salut,

L'application ne s'installe pas correctement et n'est donc pas fonctionnelle.
Voir le dernier log d'intégration continue:
https://jenkins-ci-arm.noho.st/jenkins/job/duniter%20%28Community%29/3/console

Si l'app ne redevient pas fonctionnelle, elle sera déplacée dans les apps non fonctionnelles...

It would be nice to be able to access wraped Cesium directly from yunohost tile?
When you install Duniter, it creates a tile Duniter for the damin and it would be nice if it creates also a tile Cesium for all users.

Would it be possible to be able to activate/deactivate Cesium+ in the wrapped Cesium?
Now, I don't see how to do that? but in other Cesium, even Cesium I installed on my Yunohost, we can choose to have it or not...

If, for some reason, it isn't possible, then, the issue about a tile in yunohost for the wrapped Cesium, #44 , is not as important as being able to install directly a Cesium app from https://github.com/YunoHost-Apps/cesium_ynh to make it accessible to other users. In that case, I would not put the wrapped Cesium public.

Est-ce possible de modifier les fichiers d'installation pour être comptable avec la version 1.6.21 ?
Merci ;)

Je switche en français si ça te va 👍
J'ai pas réussi à faire fonctionner ton package YunoHost avec l'install script. On dirait que ça coince aux étapes "node --harmony" et "pm2" qui ne font rien ...

Par contre en faisant:

wget -qO- https://raw.githubusercontent.com/ucoin-io/ucoin/master/install.sh | bash
ucoind init --autoconfig
ucoind config --remoteh $domain --port $port --remotep $port --salt $salt --passwd $psswd # --cpu $cpu
ucoind sync $sync_node $sync_port
ucoind start
sudo yunohost service add ucoind --log /root/.config/ucoin/ucoin_default/ucoin.log

Ca semble marcher ... A peu près car mon "yunohost service" bugge sur "update-rc.d" et l'init script quand j'essaye de l'activer.
En tout cas la clé pour fixer mon install a été d'installer ucoind via le script bash (au lieu de compiler depuis la source) puis utiliser la commande ucoind au lieu d'ucoin.

Bizarre que ça ait marché chez toi du coup ? J'ai debian jessie aussi pourtant

Je suis toujours en couleur orange par contre dans la liste Network d'ucoin. Je ne sais pas ce que ça signifie ?

As following of #12, handle YunoHost tile.
There must be an header or a javascript conflict.
It works on extra apps like:

• integrated Cesium wallet app
• about view
• logs view

On main view, it only works on first connection on a fresh web browser.

As done on YunoHost-Apps/cesium_ynh#3.

Hi,

Your app doesn't work for the moment.
It's fail on the installation tests on our CI.
https://ci-apps.yunohost.org/jenkins/job/duniter%20(Community)/19/consoleFull

Your app will be moved at 'inprogress' status by the next week, on 15 of july.

Hi,
I didn't have npm and node installed so it created issues in the YunoHost package installation it seems:

+ cd /home/yunohost.app/ucoin
+ sudo npm install
sudo: npm: command not found
+ sudo npm install -g pm2
sudo: npm: command not found
+ sudo yunohost app checkport 8999
Success! Port 8999 is available
+ [[ ! 0 -eq 0 ]]
+ sudo yunohost firewall allow TCP 8999
+ node --harmony /home/yunohost.app/ucoin/bin/ucoind init --autoconf
install: line 40: node: command not found

It seems that "sudo apt-get install -y npm node" solved the issue.

Thanks

See https://forum.yunohost.org/t/duniter-web-interface-502-bad-gateway/3686

See https://forum.duniter.org/t/manque-de-places-ws2p-sur-le-reseau-g1/4372/2?u=inso

Since Duniter 1.3.x, cesium is no more embed.
Do we plug it by default or do we ask to plug at installation?

• This code could be removed.
• This code must be adapted.

This can lead to stuck progress bar during a sync, because the websocket of sync progress is closed too early.

I will make a PR for this.

Remove no more necessary commands prefixed with sudo.

Impossible de mettre à jour l'application...

sudo yunohost app upgrade duniter -u https://github.com/duniter/duniter_ynh
Attention : Mise à jour de l'application duniter...
Erreur : Impossible de mettre à jour duniter
Erreur : Aucune application à mettre à jour

Should installation let the choice of port and path parameters at installation?
Transmission package don't ask for a port.
This could ease installation because there is already many questions asked.

The issue with this choice, is if these parameters are ever used, uCoin app can't be installed. But, this case is rare. It will happen, if this app become multi-instance.

I don't know why uCoin node won't start:

/home/admin/.ucoin/node/bin/node /home/admin/.ucoin/node_modules/pm2/bin/pm2 start -f /home/admin/.ucoin/bin/ucoind --name ucoin_default --interpreter=/home/admin/.ucoin/node/bin/node --node-args=--harmony --log /home/admin/.config/ucoin/ucoin_default/ucoin.log --error /home/admin/.config/ucoin/ucoin_default/ucoin.err.log --merge-logs -- start --mdb ucoin_default --httplogs
[PM2] restartProcessId process id 0
[PM2] Process successfully started
┌───────────────┬────┬──────┬─────┬─────────┬─────────┬────────┬────────┬──────────┐
│ App name      │ id │ mode │ pid │ status  │ restart │ uptime │ memory │ watching │
├───────────────┼────┼──────┼─────┼─────────┼─────────┼────────┼────────┼──────────┤
│ ucoin_default │ 0  │ fork │ N/A │ errored │ 1       │ 0      │ 0 B    │ disabled │
└───────────────┴────┴──────┴─────┴─────────┴─────────┴────────┴────────┴──────────┘
 Use `pm2 show <id|name>` to get more details about an app
admin@yunohost:~$ ucoind logs
[PM2] Tailing last 20 lines for [ucoin_default] process 

ucoin_default-0 (err): path.js:435
ucoin_default-0 (err):     var path = (i >= 0) ? arguments[i] : process.cwd();
ucoin_default-0 (err):                                                  ^
ucoin_default-0 (err): Error: ENOENT, no such file or directory
ucoin_default-0 (err):     at Error (native)
ucoin_default-0 (err):     at Object.posix.resolve (path.js:435:50)
ucoin_default-0 (err):     at Function.Module._resolveLookupPaths (module.js:251:17)
ucoin_default-0 (err):     at Function.Module._resolveFilename (module.js:326:31)
ucoin_default-0 (err):     at Function.Module._load (module.js:278:25)
ucoin_default-0 (err):     at Module.require (module.js:365:17)
ucoin_default-0 (err):     at require (module.js:384:17)
ucoin_default-0 (err):     at Object.<anonymous> (/home/admin/.ucoin/bin/ucoind:15:19)
ucoin_default-0 (err):     at Module._compile (module.js:460:26)
ucoin_default-0 (err):     at Object.Module._extensions..js (module.js:478:10)

That's may be due to an environement variable or to a wrong path.

• Web-ui sources are not embedded in ARM builds.
• Manage YunoHost tile:
  • Include it in the nginx conf.
  • It's not working: #23
• Add nginx redirection from http://localhost:9220 to /path.
• Find an nginx conf proxy_pass to access the interface on /path and the API on /path/api.
• Fix duniter-ui insecure connection using reverse proxy.
• connecting it to the node via:
  • /duniter/api to access the API using HTTPS, modifying duniter-ui conf.
  • localhost.
• Restrict path installation on / for now as it's not working on subpath /path:
  • Add path check.
  • manifest: don't ask for path, precise at domain asking that it will be installed on /
  • install: set and check $path == /.
• Manage SSO access:
  • Ask admin user (a YunoHost user) at installation.
  • Grant access to /path only to the admin
  • Let public access to /path/api.
• Add information on credentials asking: let them as default if you don't have a Duniter account, it is editable with the web admin.

Install from web admin break yunohost-api as there is so much logs.

We could try do decrease log install from:

• debian package install:
  • dpkg with a quiet or silent option: it seems there is option like that.
  • > /dev/null
• sync without --nointeractive with > /dev/null
  • it's a bit a problem, as we don't know where sync is. As it's slow on ARM boards.

Use functions for sources setup and nginx configuration setup.
This functions must be stored in an other script functions.sh. Then use source functions.sh.

With current network on Test-net, an ARM board with 2 cores × 1 GHz and with the PoW set to 50% of one core, there is almost:

• one block generated per day with almost thirteen issuers nodes.
  • It's too low and taking almost all CPU usage. The node could only be used as a mirror, by passing participate to false?
• fourteen blocks generated per day, with seven issuers. It's great.

Could CPU power could be found with a Unix command?

I installed yunohost on a home server (not a rasp but a PC), and when I'm trying to install Duniter, it fails with the following error log :

++ echo https://github.com/duniter/duniter/releases/download/v1.0.1/duniter-server-v1.0.1-linux-x64.deb
++ cut -d/ -f8
+ version=v1.0.1
+ wget -nc --quiet https://github.com/duniter/duniter/releases/download/v1.0.1/duniter-server-v1.0.1-linux-x64.deb -P /tmp
+ deb=/tmp/duniter-server-v1.0.1-linux-x64.deb
+ sudo dpkg -i /tmp/duniter-server-v1.0.1-linux-x64.deb
+ sudo rm -f /tmp/duniter-server-v1.0.1-linux-x64.deb
+ sudo sed -i 's@"host".*@"host": "g1.duniter.inso.ovh",@' /opt/duniter/sources/node_modules/duniter-ui/public/cesium/config.js
+ sudo sed -i 's@"port".*@"port": "443"@' /opt/duniter/sources/node_modules/duniter-ui/public/cesium/config.js
+ sudo duniter config --ipv4 127.0.0.1 --port 10900 --remoteh g1.duniter.inso.ovh --remotep 80 --noupnp --addep 'BMAS g1.duniter.inso.ovh 443'
Attention : 2017-03-12T19:37:39+01:00 - debug: Plugging file system...
Attention : 2017-03-12T19:37:39+01:00 - debug: Loading conf...
2017-03-12T19:37:39+01:00 - warn: No configuration loaded
Attention : 2017-03-12T19:37:39+01:00 - error:  TypeError: Cannot read property 'indexOf' of undefined
Attention :     at /opt/duniter/sources/index.js:362:25
Attention :     at next (native)
Attention :     at onFulfilled (/opt/duniter/sources/node_modules/co/index.js:65:19)
Attention :     at /opt/duniter/sources/node_modules/co/index.js:54:5
Attention :     at co (/opt/duniter/sources/node_modules/co/index.js:50:10)
Attention :     at configure (/opt/duniter/sources/index.js:356:10)
Attention :     at /opt/duniter/sources/index.js:214:13
Attention :     at next (native)
Attention :     at onFulfilled (/opt/duniter/sources/node_modules/co/index.js:65:19)
Exécution du script « /var/cache/yunohost/from_file/duniter_ynh-master/scripts/remove »...

As I want to ease installation by asking less parameters, Should I let CPU choice?
If not, which CPU limit for Proof-of-work should I put? 5, 10, 20%?

Bonjour,

Je ne sais pas si avec ce paquet, il y en a un mais avec celui en HTTPS d'ici https://github.com/c-geek/duniter_ynh , il n'y a pas de favicon pour Duniter.
Il y a un favicon pour le Cesium embarqué (tout comme pour le Cesium pour Yunohost non embarqué dans Duniter, pour l'heure non développé) mais il n'y a pas le favicon de la jolie dune pour le webui de Duniter.

• This reduce download time for install and upgrade procedures and which also reduce memory usage.
• Releases files names have also changed, modifications have to be done as it could make fail scripts.
• Checks need to be done.
• Check if ARM releases use server on the name.

Adding | grep server on this two lines could solve the issue.

https://github.com/duniter/duniter/issues/538

Is this package still maintained ?
How can we help to update it ?

Credentials are displayed in plain text on logs, and If I remember well, logs are logged.
The node have to be configured via CLI or via webadmin which is using HTTPS.

• 3ecb69d
• use duniter_default database name for first instance to facilitate CLI manipulation.
• handle database name and path with --mdb $app option with every duniter command.
• handle upgrade from duniter_default database to duniter__1, duniter__2…etc
• install: needs helpers to check if debian package is installed to not install two times
• remove: remove debian package only if it's the last duniter installed app. (need to develop helper)
• upgrade:
• upgrade of duniter package for all running instances
• restart all running instances
• manifest: set the app multi_instances.

Confusing installation state when stopping upgrade script
When the upgrade script is manually stopped in the middle, debian package is removed but from YunoHost point of view it's still installed.
Then, sudo duniter stop command fail because duniter command no more exist, then because of set -e, the script fail.
Then, you stay stucked in a middle of an installed/not installed state

Hello,

I guess, with time, Duniter will update less often than Cesium.
It could be nice to be able to update the embedded Cesium from Duniter webui. The best would be that this update become automatic some day but that could wait a second time I suppose.

In that case, I don't see any interest to keep maintaining the Cesium package of Yunohost.

Regards,

Thatoo

• Fix duniter version: as duniter is now enough stable, we may fix the version number.
• Check build checksum with YunoHost 2.6 helper which set-up sources and check integrity.
  • Debian package installation need to be handled.
  • Duniter 1.3 needs to be released with https://github.com/duniter/duniter/issues/866

Today I had to release v0.91.2 as pre-release to avoid any conflict with production versions. Yet, YunoHost script functions.sh installed v0.91.2 instead of 1.1.0 which is the last release.

A l'installation de Duniter sur Yunohost, je me retrouve avec deux dossiers Duniter :
mais les modifs par l'interface web, n'affecte que le second.

admin@Yunohost:~$ sudo ls /root/.config/duniter/duniter_default/                                                                                
app.pid  conf.json  duniter.db  duniter.log  stats.json  wotb.bin                                                                               
admin@Yunohost:~$ sudo ls ~/.config/duniter/duniter_default/                                                                                    
app.pid  conf.json  duniter.db  duniter.log  stats.json  wotb.bin

This lead to not working app.

After installing, duniter command doesn't works. ssh connection need to be reestablish, to get new variable environnement. I should fix this.

And this variable environnement is only set for admin and not for root user. root should be able to manage Duniter node.

During sync, WoT take too many ram, and the package is not installed:

2016-07-13T16:47:59-04:00 - info: Downloaded 100%, Applied 92%
2016-07-13T16:47:59-04:00 - trace: New node#90
2016-07-13T16:47:59-04:00 - trace: Estelle was affected wotb_id 90
2016-07-13T16:47:59-04:00 - trace: New node#91
2016-07-13T16:47:59-04:00 - trace: taosloop was affected wotb_id 91
2016-07-13T16:48:00-04:00 - trace: New node#92
2016-07-13T16:48:00-04:00 - trace: gwenael19 was affected wotb_id 92
2016-07-13T16:48:07-04:00 - trace: Link 65 -> 90
2016-07-13T16:48:07-04:00 - trace: Link 78 -> 90
2016-07-13T16:48:07-04:00 - trace: Link 88 -> 59
2016-07-13T16:48:07-04:00 - trace: Link 20 -> 65
2016-07-13T16:48:07-04:00 - trace: Link 59 -> 88
2016-07-13T16:48:07-04:00 - trace: Link 86 -> 88
2016-07-13T16:48:07-04:00 - trace: Link 7 -> 89
2016-07-13T16:48:07-04:00 - trace: Link 87 -> 0
2016-07-13T16:48:07-04:00 - trace: Link 8 -> 87
2016-07-13T16:48:07-04:00 - trace: Link 0 -> 87
2016-07-13T16:48:07-04:00 - trace: Link 86 -> 87
2016-07-13T16:48:07-04:00 - trace: Link 20 -> 88
2016-07-13T16:48:07-04:00 - trace: Link 31 -> 91
2016-07-13T16:48:08-04:00 - trace: Link 88 -> 65
2016-07-13T16:48:08-04:00 - trace: Link 65 -> 20
2016-07-13T16:48:08-04:00 - trace: Link 78 -> 2
2016-07-13T16:48:08-04:00 - trace: Link 0 -> 91
2016-07-13T16:48:08-04:00 - trace: Link 86 -> 91
2016-07-13T16:48:08-04:00 - trace: Link 88 -> 20
2016-07-13T16:48:08-04:00 - trace: Link 65 -> 89
2016-07-13T16:48:08-04:00 - trace: Link 20 -> 91
2016-07-13T16:48:08-04:00 - trace: Link 86 -> 89
2016-07-13T16:48:08-04:00 - trace: Link 88 -> 86
2016-07-13T16:48:08-04:00 - trace: Link 65 -> 7
2016-07-13T16:48:08-04:00 - trace: Link 7 -> 92
2016-07-13T16:48:08-04:00 - trace: Link 20 -> 92
2016-07-13T16:48:08-04:00 - trace: Link 88 -> 24
2016-07-13T16:48:08-04:00 - trace: Link 65 -> 88
2016-07-13T16:48:08-04:00 - trace: Link 71 -> 92
2016-07-13T16:48:08-04:00 - trace: Link 59 -> 91
2016-07-13T16:48:08-04:00 - trace: Link 53 -> 92
2016-07-13T16:48:08-04:00 - trace: Link 86 -> 92
2016-07-13T16:48:08-04:00 - trace: Link 71 -> 89
2016-07-13T16:48:08-04:00 - trace: Link 59 -> 92
2016-07-13T16:48:09-04:00 - trace: Link 65 -> 3
2016-07-13T16:48:09-04:00 - trace: Link 71 -> 91
2016-07-13T16:48:09-04:00 - trace: Link 65 -> 11
2016-07-13T16:48:09-04:00 - trace: Link 81 -> 7
2016-07-13T16:48:10-04:00 - trace: Link 65 -> 72
2016-07-13T16:48:10-04:00 - trace: Link 81 -> 8
Warning: /usr/bin/duniter: line 42: 28640 Killed                  $NODE "$DUNITER_DIR/bin/ucoind" $*

It took almost 210 Mo when it was killed.

Without sync running, the server have 227/494 Mo used RAM ≃ 270 Mo.

The package should check there is at least 300 Mo free RAM before installing/sync.

The installation via gui fails and by terminal i get the following error:

Executing script...

• domain=xxx.xxx.xxx
• port=9201
• sync_node=metab.ucoin.io
• sync_port=9201
• salt='xxxxxx'
• pwd='xxxxxxxxx'
• sudo apt-get -y -qq install nodejs npm nodejs-legacy
  E: Package nodejs not found
  E: Package npm not found
  E: Package »nodejs-legacy« has no installation candidate
• git clone https://github.com/ucoin-io/ucoin /tmp/ucoin
  Cloning into '/tmp/ucoin'...
• sudo npm install -g /tmp/ucoin pm2
  sudo: npm: command not found
• sudo yunohost app checkport 9201
  Success! Port 9201 is available
• [[ ! 0 -eq 0 ]]
• sudo yunohost firewall allow TCP 9201
  • ucoind config --noupnp --ipv4 --remote4 --remoteh xxx.xxx.xx --port 9201 --remotep 9201 --salt 'xxxxxxxxxxx' --passwd 'xxxxxxxxxxx'
    install: line 32: ucoind: command not found
• ucoind sync metab.ucoin.io 9201
  install: line 34: ucoind: command not found
• pm2 start /usr/bin/ucoind -- start
  install: line 37: pm2: command not found

Currently the package distributed by uCoin is for 32 and 64 bits architectures.
I don't think this package works on ARM architectures because there is C and C++ dependencies which are compiled on 32 and 64 bits.
I should try if it works.
If not, we should compile and distribute ARM package on the upstream project.
I won't compile this dependencies inside the package installation because NaClb dependencies compilation fail under 512Mo RAM and won't works for Internet Cubes which have only 512Mo RAM.

Need an upgrade script.

YunoHost-Apps/cesium_ynh#2 (comment)

hello

raspberry 3
Debian 8.0 32bit (Linux 4.9.51-v7+)
yunohost manual install (https://yunohost.org/#/install_manually_fr)
yunohost 2.7.2

error during install

Attention : Error: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /opt/duniter/node_modules/sqlite3/lib/binding/node-v48-linux-arm/node_sqlite3.node)

Data retrievement and ws connections should be done with https://domain.tld/path/*.
But they are done with https://domain.tld/*.

• Can this be bypass with an nginx conf like that one?
• Do Duniter code source must be modified to handle subpath?

Extra: funny bug on Firefox 48, GitHub Inc. certificate on my domain name due to update research on api.github.com 😉

• Store $arch and retrieve it in upgrade script.
• Use variable for Nginx conf file path.
• Check the package with package_linter:
  • Add requirement key in manifest
• Use helpers
• Retrieve arguments via environment variables
• Upgrade Nginx conf in upgrade script.
• sudo rm -rf /root/.conf/duniter in remove script.

When installing Duniter from YunoHost admin panel, here are the logs I get:

2017-06-14T15:38:20+02:00 - �[31merror�[39m: No block was downloaded
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:76:26)
at errnoException (dns.js:28:10)
2017-06-14T15:38:12+02:00 - �[31merror�[39m: Error: getaddrinfo ENOTFOUND 2a01 2a01:61650
2017-06-14T15:38:12+02:00 - �[31merror�[39m: Inner hash of block#26250 from %s does not match
2017-06-14T15:38:11+02:00 - �[31merror�[39m: Inner hash of block#26250 from %s does not match
2017-06-14T15:38:08+02:00 - �[36mdebug�[39m: Upgrade database...
2017-06-14T15:38:08+02:00 - �[36mdebug�[39m: Opening SQLite database "/root/.config/duniter/duniter_default/duniter.db"...
2017-06-14T15:38:08+02:00 - �[36mdebug�[39m: Configuration saved.
2017-06-14T15:38:08+02:00 - �[36mdebug�[39m: Loading conf...
2017-06-14T15:38:08+02:00 - �[36mdebug�[39m: Plugging file system...
+ sudo duniter sync duniter.org 10901 --nointeractive
Synchronizing with duniter.org:10901. It may take a while.
+ echo 'Synchronizing with duniter.org:10901. It may take a while.'

This is super-weird. Why this "Inner hash" problem? I'm starting on a clean installation (no data, no config, no duniter).

I suggest to remove initial sync, because Duniter already proposes a synchronization on startup. This way we can let the user choose whether he prefers to sync with Ğ1Test or Ğ1.