[raspbian] geneweb et son acolyte gwsetup

Geo Cherchetout <geo.cherchetoutsanspam@laposte.net.invalid> wrote:

pi@raspberrypi:~ $ systemctl status gwsetup
? gwsetup.service - LSB: Geneweb setup web interface
Loaded: loaded (/etc/init.d/gwsetup; generated; vendor preset: enabled)
Active: active (exited) since Thu 2019-04-11 17:14:30 CEST; 19min ago
Docs: man:systemd-sysv-generator(8)
Process: 2674 ExecStop=/etc/init.d/gwsetup stop (code=exited,
status=0/SUCCESS)
Process: 2681 ExecStart=/etc/init.d/gwsetup start (code=exited,
status=0/SUCCESS)

N'y aurait-il pas des logs de ce daemon spécifique via `journalctl -xe'
(qui résume simplement certains logs de /var/log), ou des logs
spécifiques à ce programme (p.ex. dans /var/log/genetruc/argh.log ?)

En alternative il y a toujours la possibilité de faire un

sudo -s # devenir root (s'il y a un pw root: juste su)
su - l-utilisateur-qui-tourne-habituellement-ce-service -s /bin/bash
# puis de lancer avec des options similaires à ce que fait systemd.

pour voir le message d'erreur s'il n'y a pas de logs.

On peut aussi consulter le log du kernel à tout hasard où certains
crashes peuvent être signalés: dmesg (ou sudo dmesg)

Le 12/04/2019 09:52, *Marc SCHAEFER* a écrit :

N'y aurait-il pas des logs de ce daemon spécifique via `journalctl -xe'
(qui résume simplement certains logs de /var/log), ou des logs
spécifiques à ce programme (p.ex. dans /var/log/genetruc/argh.log ?)

Je ne trouve ni geneweb.log ni gwsetup.log mais c'est peut-être parce que
j'ai mal configuré syslog-ng ou parce que /var/log/ est monté en mémoire vive ?

En revanche journalctl -xe immédiatement après avoir tenté un nouveau «
restart » de gwsetup donne ceci, je ne recopie que la fin :

-- Une nouvelle session a été créée pour l'utilisateur pi avec
-- l'identifiant (ID) c7.
--
-- Le processus maître de la session est 8700.
avril 12 14:23:04 raspberrypi sshd[8700]: lastlog_openseek: Couldn't stat
/var/log/lastlog: No such file or directory
avril 12 14:23:04 raspberrypi sshd[8700]: lastlog_openseek: Couldn't stat
/var/log/lastlog: No such file or directory
avril 12 14:23:13 raspberrypi CRON[8689]: (CRON) info (No MTA installed,
discarding output)
avril 12 14:23:13 raspberrypi CRON[8689]: pam_unix(cron:session): session
closed for user root
avril 12 14:23:19 raspberrypi sudo[8736]: pi : TTY=pts/2 ;
PWD=/home/pi ; USER=root ; COMMAND=/bin/systemctl restart gwsetup
avril 12 14:23:19 raspberrypi sudo[8736]: pam_unix(sudo:session): session
opened for user root by pi(uid=0)
avril 12 14:23:19 raspberrypi systemd[1]: Stopping LSB: Geneweb setup web
interface...
-- Subject: L'unité (unit) gwsetup.service a commencé à s'arrêter
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) gwsetup.service a commencé à s'arrêter.
avril 12 14:23:19 raspberrypi gwsetup[8742]: Stopping gwsetup server gwsetup.
avril 12 14:23:19 raspberrypi systemd[1]: Stopped LSB: Geneweb setup web
interface.
-- Subject: L'unité (unit) gwsetup.service a terminé son arrêt
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) gwsetup.service a terminé son arrêt.
avril 12 14:23:19 raspberrypi systemd[1]: Starting LSB: Geneweb setup web
interface...
-- Subject: L'unité (unit) gwsetup.service a commencé à démarrer
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) gwsetup.service a commencé à démarrer.
avril 12 14:23:19 raspberrypi gwsetup[8749]: Starting gwsetup server gwsetup.
avril 12 14:23:19 raspberrypi systemd[1]: Started LSB: Geneweb setup web
interface.
-- Subject: L'unité (unit) gwsetup.service a terminé son démarrage
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) gwsetup.service a terminé son démarrage, avec le résultat
done.
avril 12 14:23:19 raspberrypi sudo[8736]: pam_unix(sudo:session): session
closed for user root


Ça semble correct mais ça ne l'est pas réellement puisque je n'ai toujours
pas de processus gwsetup. (À la différence de ce que j'observe sur un autre
ordinateur sous debian stretch où la même version de geneweb est installée.)

En alternative il y a toujours la possibilité de faire un

sudo -s # devenir root (s'il y a un pw root: juste su)
su - l-utilisateur-qui-tourne-habituellement-ce-service -s /bin/bash
# puis de lancer avec des options similaires à ce que fait systemd.

J'arrive à devenir l'utilisateur geneweb mais je cherche en vain la commande
exacte lancée par systemd. Même sur l'autre ordinateur où gwsetup fonctionne
bien, cette commande n'apparaît dans aucun des fichiers de log que j'ai
visités ni dans dmesg. Peut-on la déduire du contenu de /etc/init.d/gwsetup
ci-dessous recopié :

$ cat gwsetup
#! /bin/sh
#
# GeneWeb Start the Gwsetup mini HTTP server.
#
### BEGIN INIT INFO
# Provides: gwsetup
# Required-Start: $network $local_fs $remote_fs geneweb
# Should-Start:
# Required-Stop: $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Should-Stop:
# Short-Description: Geneweb setup web interface
### END INIT INFO

# Do not change the values below
GENEWEBSHARE=/usr/share/geneweb
GENEWEBDB=/var/lib/geneweb
GENEWEBUSER=geneweb
DAEMON=/usr/bin/gwsetup
WRAPPER=/usr/lib/geneweb/gwsetup.wrapper
NAME=gwsetup
LOGFILE=/var/log/$NAME.log
GWSETUPONLYFILE=/etc/geneweb/gwsetup_only.txt

# Defaults
# The port which the daemon listens to
GWSETUP_PORT#16
# The default language
LNG=en
# Run Mode : if anything else than "daemon", no daemon will be
# launched automatically
RUN_MODE="Always on"
# Additionnal options
OPTIONS=""

# Reads geneweb config file (for language)
[ -r /etc/default/geneweb ] && . /etc/default/geneweb

# Reads gwsetup config file (for other settings)
[ -r /etc/default/gwsetup ] && . /etc/default/gwsetup

# Export variables so that they may be used by the wrapper script
export LNG GWSETUP_PORT LOGFILE NAME DAEMON GENEWEBDB GENEWEBDOC
GENEWEBSHARE GWSETUPONLYFILE OPTIONS

trap "" 1

test -f $DAEMON || exit 0

. /lib/lsb/init-functions

# We start (or stop) the daemon only when configured
# for running in daemon mode
if [ "$RUN_MODE" != "Always on" ]; then
exit 0
fi

start_stop()
{
case "$1" in
start)
log_begin_msg "Starting gwsetup server" "gwsetup"
if ! start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec
$WRAPPER; then
log_end_msg 1
exit 1
fi
log_end_msg 0
;;

stop)
log_begin_msg "Stopping gwsetup server" "gwsetup"
start-stop-daemon --stop --quiet --exec $DAEMON --
-gd $GENEWEBSHARE -only $GWSETUPONLYFILE
-lang$LANG -daemon
log_end_msg 0
;;

restart | force-reload)
start_stop stop
sleep 2
start_stop start
;;

*)
log_success_msg "Usage: /etc/init.d/$NAME
{start|stop|restart|force-reload}"
exit 1
;;
esac
}

start_stop "$@"

exit 0

Pardon, j'ai quand même une petite trace dans /var/log/syslog mais ça ne
m'aide pas vraiment :

pi@raspberrypi:/etc/init.d $ grep gw /var/log/syslog
Apr 12 14:23:19 raspberrypi gwsetup[8742]: Stopping gwsetup server gwsetup.
Apr 12 14:23:19 raspberrypi gwsetup[8749]: Starting gwsetup server gwsetup.

In article <q8q4s6$2oc5$1@news.gegeweb.eu> you wrote:

En revanche journalctl -xe immédiatement après avoir tenté un nouveau «
restart » de gwsetup donne ceci, je ne recopie que la fin :

Faites-voir plutôt un

- reboot de votre pi
- vérification avec ps auxw | grep gwsetup
qu'il n'est pas lancé
- systemctl gwsetup stop
- systemctl gwsetup start

ensuite regardez s'il est lancé, puis consultez à nouveau
les logs (ls -lart /var/log # t pour sort-by-time) et
le journalctl -xe.

systemctl restart fait un stop ce qui pollue les logs,
à voir.

Geo Cherchetout <geo.cherchetoutsanspam@laposte.net.invalid> wrote:

contenu de /etc/init.d/gwsetup

Avec systemd, il se pourrait que cela ne soit pas ce script qui
soit exécuté, il faudrait encore vérifier cela, p.ex. avec
systemctl status gwsetup.service

P.ex. chez moi avec bind9:
/lib/systemd/system/bind9.service
qui exécute ExecStart=/usr/sbin/named -f $OPTIONS
(et donc ignore superbement tout changement à
/etc/init.d/bind9, qui n'est là que pour la
compatibilité).

Vous pourriez modifier le script init de gwsetup,
en supposant que c'est le bon, pour:


log_begin_msg "Starting gwsetup server" "gwsetup"
if ! start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec
$WRAPPER; then
log_end_msg 1
exit 1
fi

ajouter un "echo" du genre
echo start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec $WRAPPER
et vous aurez les arguments complets (mais peut-être pas certaines
variables d'environnement).

Et éventuellement consulter le script $WRAPPER pour voir comment il
lance.

Puis ajouter les arguments de debugging nécessaires.

Le 12/04/2019 18:39, *Marc SCHAEFER* a écrit :

Faites-voir plutôt un

- reboot de votre pi
- vérification avec ps auxw | grep gwsetup
qu'il n'est pas lancé
- systemctl gwsetup stop
- systemctl gwsetup start

ensuite regardez s'il est lancé, puis consultez à nouveau
les logs (ls -lart /var/log # t pour sort-by-time) et
le journalctl -xe.

systemctl restart fait un stop ce qui pollue les logs,
à voir.

Problème résolu. J'ai constaté que gwsetup a besoin pour démarrer de trouver
un fichier /var/log/gwsetup.log et peut-être aussi geneweb.log, or ces
fichiers disparaissent chaque fois que je re-boote la bestiole depuis que
j'ai mis cette ligne dans /etc/fstab :

tmpfs /var/log tmpfs defaults,noatime,nosuid,mode55,size m 0 0

Il y a 5 minutes j'ai recréé manuellement les dits fichiers de log et
l'utilisateur pi a réussi du premier coup à faire un restart effectif. :-)

Je n'ai plus qu'à faire en sorte que gwsetup.log et geneweb.log soit recréés
automatiquement au boot. Cron doit pouvoir faire ça.

Merci pour le soutien et les petits trucs que je ne connaissais pas.

Geo Cherchetout <geo.cherchetoutsanspam@laposte.net.invalid> wrote:

j'ai mis cette ligne dans /etc/fstab :

tmpfs /var/log tmpfs defaults,noatime,nosuid,mode55,size m 0 0

Ah oui, donc /var/log est perdu à chaque redémarrage, ennuyeux.

Il y a 5 minutes j'ai recréé manuellement les dits fichiers de log et
l'utilisateur pi a réussi du premier coup à faire un restart effectif. :-)

Modifier le vrai script de démarrage de gwsetup (celui qui est référencé
par systemd) pour créer ces répertoires et fichiers avec les bons droits
avant de lancer.

Je n'ai plus qu'à faire en sorte que gwsetup.log et geneweb.log soit recréés
automatiquement au boot. Cron doit pouvoir faire ça.

Oui, avec le @reboot dans une crontab user, mais pour le système je préfère
/etc/rc.local

for i in gwsetup geneweb
do
touch /var/log/$i.log
# évt. chown ?
done

systemctl start gwsetup

Le 13/04/2019 08:58, *Marc SCHAEFER* a écrit :

Modifier le vrai script de démarrage de gwsetup (celui qui est référencé
par systemd) pour créer ces répertoires et fichiers avec les bons droits
avant de lancer.

Je viens enfin de découvrir /usr/lib/geneweb/gwsetup.wrapper. Voici ce qu'il
contient :

$ sudo cat /usr/lib/geneweb/gwsetup.wrapper
#!/bin/sh
# This is a wrapper script for starting gwsetup from the init script
# It is needed for properly set up the umask the daemon runs under
# as start-stop-daemon does not allow this and have the program
# run with /var/lib/geneweb as default directory so that created bases
# go there
umask 007
cd $GENEWEBDB
# Use a non predictable name for the temporary command output file
TEMPFILE=`tempfile`
$DAEMON -gd $GENEWEBSHARE -lang $LNG -p $GWSETUP_PORT -bindir /usr/bin -only
$GWSETUPONLYFILE -log $TEMPFILE -daemon >>/var/log/gwsetup.log 2>&1
exit $?

Supposons que je parvienne à modifier ce wrapper, ne sera-t-il pas écrasé
lors de la prochaine mise à jour du programme ?

Oui, avec le @reboot dans une crontab user, mais pour le système je préfère
/etc/rc.local

for i in gwsetup geneweb
do
touch /var/log/$i.log
# évt. chown ?
done

systemctl start gwsetup

Ça me plait bien, ça, merci beaucoup, je vais essayer de le mettre en place.

Geo Cherchetout <geo.cherchetoutsanspam@laposte.net.invalid> wrote:

Supposons que je parvienne à modifier ce wrapper, ne sera-t-il pas écrasé
lors de la prochaine mise à jour du programme ?

Chaque package Debian (et donc vraisemblablement raspbian) peut enregistrer
des fichiers de configuration dont les modifications sont gérées aux mises à
jour. Par exemple, si toi ou un script a modifié un de ces fichiers, la mise
à jour te proposera un dialogue pour corriger le problème. On peut lister les
fichiers de config ainsi (exemple pour xfig:
root@reliand:/home/schaefer# cat /var/lib/dpkg/info/xfig.conffiles
/etc/X11/app-defaults/Fig
/etc/X11/ja_JP.eucJP/app-defaults/Fig
/etc/X11/ko_KR.eucKR/app-defaults/Fig
)

Toutefois, effectivement, tout autre fichier d'un package (exécutable,
script, etc) sera écrasé sans vérification.

Mais Debian propose une deuxième solution: les diversions. Par exemple,
dans mon cas je veux que /usr/bin/soffice soit en fait remplacé par
un wrapper-script de mon cru, alors j'ai installé une diversion
de /usr/bin/soffice à /usr/bin/soffice.distrib et créé mon propre
script (ou exécutable, ou symlink) dans /usr/bin/soffice donc les
mises à jour de la distribution du package contenant ce fichier
sont maintenant faites dans le fichier qui se termine par .distrib
et plus mon wrapper-script. Voir `man dpkg-divert'

Attention toutefois, si tu utilises des diversions, de bien vérifier (par
diff p.ex.) à chaque mise à jour, en particulier de version de la distribution,
que d'éventuels patches de sécurité ne sont pas à porter à ta version de
fichier. Cf man dpkg-divert

Le 13/04/2019 08:58, *Marc SCHAEFER* a écrit :

Oui, avec le @reboot dans une crontab user, mais pour le système je préfère
/etc/rc.local

for i in gwsetup geneweb
do
touch /var/log/$i.log
# évt. chown ?
done

systemctl start gwsetup

Essayé et approuvé, merci beaucoup. :-)