ha ne sois pas insultant envers les développeurs hein
ton erreur ssh indique un problème de clés SSH, peux-tu te connecter, la prochaine fois que tu a cette erreur, en debug: ssh -vvv usefr@ip pour avoir plus d’infos sur ce problème ? Quelle version debian as-tu ? quelle config SSH ? peut-être une simple mise-à-jour du système (apt update et apt upgrade je sais plus dans quel ordre) suffira à corriger le problème… Sinon, investiguer dans la conf SSH:
# ssh -V
# cat /etc/ssh/sshd_config
Le fichier .htaccess était sans doute une mauvaise piste, en effet s’il y a un pb sur l’accès SSL -TLS tout ça la ça impacte autant la connexion SSH que HTTPS.
Ha, oui, comment te connecte-tu sur ton jeedom ? Peux-tu y accéder en HTTP simple sur son IP dans le secure la prochaine fois qu’il plante ainsi ?
Effectivement, c’est une très bonne remarque ! Le souci sur le .htaccess n’est peut-être qu’un effet de bord d’un souci sur l’accès SSL - TLS !
J’y accède par deux moyens :
Son IP sur réseau locale (depuis mon réseau local donc)
Mon nom de domaine ovh
Je ne me rappelle plus si j’ai également le forbidden via l’IP locale, il faut que je vérifier lors de la prochaine erreur ! Encore une bonne piste !!
Qu’entends-tu par :
Peux-tu y accéder en HTTP simple sur son IP dans le secure
Merci beaucoup pour vos réponses et votre aide ! C’est très appréciable !!
Et en plus, j’apprends plein plein plein de choses !!
Bonsoir,
apt update doit être réalisé avant apt upgrade.
apt upgrade seul… attend une réponse, donc cela ne doit rien faire chez vous.
La bonne commande est donc : sudo apt update && sudo apt upgrade -y
apt-get est déprécié (il faut utiliser apt maintenant)
dist-upgrade ne doit pas fonctionner chez vous, sinon pour ne seriez pas en version 9.x il me semble, mais en version 10.
Merci @Fabrice ! J’ai mis à jour mon script avec la bonne commande !
$ sudo apt dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Cela semble fonctionner correctement, mais je me trompe peut-être (sûrement d’ailleurs, mes commandes n’étaient déjà pas bonnes )…
C’est le cas si /etc/apt/sources.list est modifié avec la liste des dépôts de buster.
Sinon cela met à jour la version de stretch (par exemple 9.8 vers 9.9).
Oui j’ai lu, c’est aussi pas recommandé pour les environnements stables, car cela mets à jour les dépendances.
Je serai @HakunA, je supprimerai cette ligne du script. Qui à mon avis attend aussi un retour.
@Fabrice je viens de comprendre ce que tu entendais par « attend un retour », c’est en fait « demande une saisie à l’utilisateur » (dans le cas présent Y/N pour valider).
Et je te confirme que cela fonctionne très bien dans un script. J’aurais peut-être pu/du préciser que je ne passe pas par Jeedom pour exécuter ce script.
Question bonus (@pifou tu me recommandes de migrer vers Buster) : L’upgrade de Stretch vers Buster est-il « safe » ?
Il y a encore quelques temps il était vivement et fortement conseillé de partir d’une clean install de Buster plutôt que d’upgrader depuis Stretch.
Est-ce toujours le cas ?
Merci.
P.S : toujours pas de 403 forbidden depuis mardi.
EDIT
Ah, bah il suffit de dire
J’ai pas eu de 403 forbidden depuis mardi
Pour en avoir !
Accès Jeedom via HTTPS => KO
Forbidden
You don’t have permission to access this resource.Server unable to read htaccess file, denying access to be safe
Accès Jeedom via HTTP => KO
Forbidden
You don’t have permission to access this resource.Server unable to read htaccess file, denying access to be safe
L’accès via HTTP de mon autre ressource (ha-bridge) tournant sur mon RPI ==> KO
ERR_CONNECTION_REFUSED
Accès en SSH => KO
$ ssh -vvv hakuna@192.168.X.X
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/Hakuna/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.X.X is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.X.X [192.168.X.X] port 22.
debug1: Connection established.
debug1: identity file /Users/Hakuna/.ssh/id_rsa type 0
debug1: identity file /Users/Hakuna/.ssh/id_rsa-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_dsa type -1
debug1: identity file /Users/Hakuna/.ssh/id_dsa-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_ecdsa type -1
debug1: identity file /Users/Hakuna/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_ed25519 type -1
debug1: identity file /Users/Hakuna/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_xmss type -1
debug1: identity file /Users/Hakuna/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
kex_exchange_identification: read: Connection reset by peer
D’autres pistes à explorer avant que je fasse un hard reboot ?
Pour ceux qui on un SSD sur le Raspberry Pi
Alors, il ne faut plus utiliser : dtoverlay=sdtweak,poll_once
Mais : dtparam=sd_poll_once
(le fil est mis à jour vers le bas)
=> Si l’ancienne commande marche chez vous, c’est que votre distribution Pi n’est pas à jour !
Enfin, pour vos problèmes d’accès, je comprends que votre Pi sert à autre chose que Jeedom, ce qu’il ne faut pas faire.
=> Surtout s’il y un lien avec les accès au réseau
Hébergez cette ressource ailleurs et vous devriez retrouver un système stable.
@Fabrice pour l’info, je vais tester avec la nouvelle commande (dtparam=sd_poll_once)!
Hier soir j’ai désactiver l’autre ressource (ha-bridge) qui tourne sur mon pi, mais j’ai tout de même eu une 403 en plein milieu de la nuit…
J’ai trouvé quelque chose d’étrange dans /var/log/syslog :
Dec 31 01:47:01 raspberrypi CRON[16703]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Dec 31 01:47:01 raspberrypi CRON[16704]: (pi) CMD (su --shell=/bin/bash - www-data -c '/usr/bin/php /var/www/html/jeedom/core/php/jeeCron.php' >> /dev/null 2>&1)
Dec 31 01:47:01 raspberrypi CRON[16707]: (root) CMD (su --shell=/bin/bash - www-data -c '/usr/bin/php /var/www/html/jeedom/core/php/jeeCron.php' >> /dev/null 2>&1)
Dec 31 01:47:01 raspberrypi systemd[1]: Started Session c848 of user www-data.
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@$
Dec 31 01:17:05 raspberrypi fake-hwclock[96]: Thu 31 Dec 00:17:01 UTC 2020
Dec 31 01:17:05 raspberrypi systemd[1]: Started Create Static Device Nodes in /dev.
Dec 31 01:17:05 raspberrypi systemd[1]: Starting udev Kernel Device Manager...
Dec 31 01:17:05 raspberrypi systemd-fsck[133]: e2fsck 1.43.4 (31-Jan-2017)
Dec 31 01:17:05 raspberrypi systemd-fsck[133]: rootfs: clean, 864540/3853696 files, 4083018/15579648 blocks
Dec 31 01:17:05 raspberrypi systemd[1]: Started File System Check on Root Device.
Dec 31 01:17:05 raspberrypi systemd[1]: Starting Remount Root and Kernel File Systems...
Dec 31 01:17:05 raspberrypi systemd[1]: Started udev Kernel Device Manager.
Dec 31 01:17:05 raspberrypi systemd[1]: Started Set the console keyboard layout.
Dec 31 01:17:05 raspberrypi systemd[1]: Started Remount Root and Kernel File Systems.
Dec 31 01:17:05 raspberrypi systemd[1]: Starting Flush Journal to Persistent Storage...
Dec 31 01:17:05 raspberrypi systemd[1]: Starting Load/Save Random Seed...
Dec 31 01:17:05 raspberrypi systemd[1]: Reached target Local File Systems (Pre).
Dec 31 01:17:05 raspberrypi systemd[1]: tmp-jeedom.mount: Directory /tmp/jeedom to mount over is not empty, mounting anyway.
Dec 31 01:17:05 raspberrypi systemd[1]: Mounting /tmp/jeedom...
Dec 31 01:17:05 raspberrypi systemd[1]: Starting udev Coldplug all Devices...
Dec 31 01:17:05 raspberrypi systemd[1]: Mounted /tmp/jeedom.
Dec 31 01:17:05 raspberrypi systemd[1]: Started Load/Save Random Seed.
Dec 31 01:17:05 raspberrypi mtp-probe: checking bus 1, device 8: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.4"
Dec 31 01:17:05 raspberrypi systemd[1]: Started udev Coldplug all Devices.
Dec 31 01:17:05 raspberrypi mtp-probe: checking bus 1, device 3: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1"
Dec 31 01:17:05 raspberrypi systemd[1]: Starting Show Plymouth Boot Screen...
Dec 31 01:17:05 raspberrypi mtp-probe: bus: 1, device: 8 was not an MTP device
Dec 31 01:17:05 raspberrypi systemd[1]: Started Show Plymouth Boot Screen.
Dec 31 01:17:05 raspberrypi mtp-probe: checking bus 1, device 6: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.2"
Dec 31 01:17:05 raspberrypi systemd[1]: Reached target Encrypted Volumes.
Dec 31 01:17:05 raspberrypi mtp-probe: bus: 1, device: 6 was not an MTP device
Dec 31 01:17:05 raspberrypi systemd[1]: Reached target Paths.
Dec 31 01:17:05 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Dec 31 01:17:05 raspberrypi kernel: [ 0.000000] Linux version 4.19.66-v7+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1253 SMP Thu Aug 15 11:49:46 BST 2019
L’heure passe de 1h47 à 1h17
Le system semble déclencher un reboot
Après la ligne Dec 31 01:18:02 raspberrypi systemd[1907]: Startup finished in 188ms.
Je constate des logs sur ntpd puis, absolument plus aucun signe de vie jusqu’au hard reboot que j’ai du faire ce matin en constatant la 403 :
Dec 31 01:18:02 raspberrypi systemd[1907]: Startup finished in 188ms.
Dec 31 01:18:02 raspberrypi systemd[1]: Started User Manager for UID 33.
Dec 31 01:18:14 raspberrypi ntpd[546]: Soliciting pool server 212.83.145.32
Dec 31 01:18:14 raspberrypi ntpd[546]: Soliciting pool server 212.83.158.83
Dec 31 01:18:14 raspberrypi ntpd[546]: Soliciting pool server 162.159.200.123
Dec 31 01:18:15 raspberrypi ntpd[546]: Soliciting pool server 54.36.60.132
Dec 31 01:18:15 raspberrypi ntpd[546]: Soliciting pool server 212.85.158.10
Dec 31 01:18:15 raspberrypi ntpd[546]: Soliciting pool server 129.250.35.250
Dec 31 01:18:16 raspberrypi ntpd[546]: Soliciting pool server 51.15.182.163
Dec 31 01:18:16 raspberrypi ntpd[546]: Soliciting pool server 129.250.35.251
Dec 31 01:18:16 raspberrypi ntpd[546]: Soliciting pool server 51.158.147.92
Dec 31 01:18:17 raspberrypi ntpd[546]: Soliciting pool server 62.210.206.214
Dec 31 01:18:17 raspberrypi ntpd[546]: Soliciting pool server 188.165.224.178
Dec 31 01:18:17 raspberrypi ntpd[546]: Soliciting pool server 212.51.181.242
Dec 31 01:18:18 raspberrypi ntpd[546]: Soliciting pool server 82.64.95.3
Dec 31 01:18:19 raspberrypi ntpd[546]: Soliciting pool server 51.158.67.116
Dec 31 01:18:19 raspberrypi systemd[1]: Stopping LSB: Start NTP daemon...
Dec 31 01:18:19 raspberrypi ntpd[546]: ntpd exiting on signal 15 (Terminated)
Dec 31 01:18:19 raspberrypi ntpd[546]: 212.83.158.83 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 162.159.200.123 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 129.250.35.250 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 54.36.60.132 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 212.85.158.10 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 51.15.182.163 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 129.250.35.251 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 51.158.147.92 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 188.165.224.178 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 212.51.181.242 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 62.210.206.214 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 82.64.95.3 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 51.158.67.116 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntp[2874]: Stopping NTP server: ntpd.
Dec 31 01:18:19 raspberrypi systemd[1]: Stopped LSB: Start NTP daemon.
Dec 31 05:57:29 raspberrypi systemd[1]: Time has been changed
Dec 31 05:57:29 raspberrypi ntpdate[2899]: step time server 51.15.182.163 offset 16742.537738 sec
Dec 31 05:57:29 raspberrypi systemd[1907]: Time has been changed
Je me demande donc :
Qu’est-ce qui explique ce changement d’heure système si soudain ?
D’où proviennent les ^@ qui sont affichés PILE au moment du changement d’heure ?
Que dois-je chercher dans les logs afin d’avoir une piste sur la raison du reboot ?
Merci !
C’est une piste intéressante, je vais voir ce que je trouve, et poster ici les divers manipulations .
En parallèle, j’ai constaté ce midi que l’alimentation secteur de mon boitier SSD est une 0.7A. Je l’ai remplacée par une plus puissante, afin d’écarter cette piste, car j’avais trouvé quelques personnes avec le souci similaire sur leur apache, ils ont tous résolu le problème en changeant l’alimentation (du pi ou du SSD). Ceci dit, ils avaient des under-voltage dans les logs, ce qui n’est pas mon cas.
En avance : Bonne année !
EDIT
Les actions effectuées :
hakuna@raspberrypi:~ $ sudo systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
└─disable-with-time-daemon.conf
Active: inactive (dead)
Condition: start condition failed at Thu 2020-12-31 17:49:43 CET; 1min 12s ago
Docs: man:systemd-timesyncd.service(8)
J’ai donc fait :
apt purge ntp
Puis j’ai modifié /etc/systemd/timesyncd.conf
pour mettre :
[Time]
NTP=time.cloudflare.com
Pour finalement :
hakuna@raspberrypi:~ $ systemctl restart systemd-timesyncd.service
pi@raspberrypi:~ $ sudo systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
└─disable-with-time-daemon.conf
Active: active (running) since Thu 2020-12-31 17:51:16 CET; 2min 46s ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 1220 (systemd-timesyn)
Status: "Synchronized to time server 162.159.200.123:123 (time.cloudflare.com)."
Tasks: 2 (limit: 4915)
CGroup: /system.slice/systemd-timesyncd.service
└─1220 /lib/systemd/systemd-timesyncd
Dec 31 17:51:16 raspberrypi systemd[1]: Starting Network Time Synchronization...
Dec 31 17:51:16 raspberrypi systemd[1]: Started Network Time Synchronization.
Dec 31 17:51:16 raspberrypi systemd-timesyncd[1220]: Synchronized to time server 162.159.200.123:123 (time.cloudflare.com).
En espérant que ça + le changement d’alimentation permettra de résoudre définitivement ce souci (c’est ma femme qui va être contente)
J’ai le même problème depuis 3 jours, mon jeedom n’est plus accessible quasiment à la même heure la nuit vers 00h30.
J’ai un Raspberry Pi 4 model b avec une alimentation officielle de 3A + SSD alimenté par le Raspberry et deux rallonges USB pour la clé Zwave et Deconz. *
Savez-vous comment je peux solutionner ce problème ?
J’ai lu sur d’autre sujet en mettant un hub USB auto alimenté ou alors en changeant le SSD par un M2 ?
Ce type de boitier n’est pas recommandé, ni ce type de disque en fait.
Pour les Raspberry, il faut utiliser un disque SSD de type mSATA (très faible consommation).
C’est le boîtier que j’avais. Il ne permet pas d’avoir une alimentation dédiée au SSD. @Fabrice apporte une partie de la réponse.
Deux scénarios possibles :
tu souhaites que ton raspberry alimente ton SSD. Dans ce cas, tu dois acheter un mSATA.
tu souhaites utiliser un SSD. Dans ce cas, tu dois acheter un boîtier avec une alimentation secteur dédiée (au hasard (en prenant soin d’avoir une alimentation qui délivre au moins 1A !)
Oui je pense que je vais passer sur un msata ou un m2 vous me conseillez quoi comme boitier et marque de ssd pour que tout soit intégré dans le même boitier que le Raspberry ?
, je teste ça dés que j’ai à nouveau l’erreur !
, je peux te l’envoyer en MP si tu le souhaites.
! J’ai mis à jour mon script avec la bonne commande !
)…
