J'ai utilisé le démarrage automatique personnalisé vers X avec du chrome en mode kiosque (24/7) et fais ceci: https://www.youtube.com/watch?v=P9Sk9bNrzeg
J'ai défini une sauvegarde (sur Google Drive) qui a été effectuée par cron dans le dossier cron.daily - j'ai écrit le script:
#!/bin/sh
G_USER_INPUT=0
/DietPi/dietpi/dietpi-backup 1 > /mnt/rpi/backup.log && tar zcfv /mnt/rpi/backup.tar.gz /mnt/backup/dietpi-backup/ >> /mnt/rpi/backup.log && rclone copy /mnt/rpi/backup.tar.gz dysk: -L >> /mnt/rpi/backup.log && rm -r /mnt/rpi/backup.tar.gz >> /mnt/rpi/backup.log && reboot
Ce script fonctionnait bien jusqu'à la version 6.9 de DietPi lorsqu'il était exécuté à partir de cron.daily.
Le script fonctionne bien lorsque je l'exécute manuellement.
AprÚs la mise à jour vers v.6.10 et v.6.11, le script ne fonctionne pas à partir de cron.daily, mais fonctionne bien lors du démarrage manuel.
Sur backup.log, j'ai une chaßne incompréhensible de caractÚres avec une chaßne comme celle-ci: vérification de l'accÚs racine d'élévation.
De plus, ce n'est pas Ă partir de crontab.
@eljotx
Je vous remercie pour votre rapport.
G_USER_INPUT=0
devrait ĂȘtre dĂ©tectĂ© automatiquement lors des exĂ©cutions cron, donc pas nĂ©cessaire d'attribuer. Mais si vous voulez qu'il ait un effet, vous devez l'exporter, ce qui vaut bien sĂ»r la peine d'essayer:
export G_USER_INPUT=0
Sur les exécutions non interactives, le script se ferme si (prÚs de) un espace libre insuffisant est détecté sur le lecteur cible: https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-backup#L456
Mais vous dites que l'exécution manuelle fonctionne bien? En cas d'espace libre insuffisant, vous verrez l'invite whiptail qui vous donne le choix d'ignorer ou de quitter.
à propos des entrées de journal, des codes de couleur cryptiques + checking for elevation root access
sont attendus. Essayer:
cat /mnt/rpi/backup.log
pour avoir les codes couleurs actifs et donc le journal formaté. Veuillez également fournir cette sortie ici, afin que nous puissions vérifier à quel stade le problÚme s'est produit.
Le script fonctionne bien lorsque je l'exécute manuellement.
Ătrange.
Essayez d'exécuter la tùche cron et collez les résultats du journal /mnt/rpi/backup.log
NB: dietpi-backup
renvoie automatiquement rsync dans le fichier journal /var/log/dietpi-backup.log
, vous pouvez Ă©galement l'utiliser.
Donc, j'essaye d'exécuter le travail cron sans G_USER_INPUT = 0 (j'ai supprimé ceci du script) et ...
Mon fichier journal de sauvegarde de /mnt/rpi/backup.log
[90m[[0m[33m......[90m][0m Checking for (elevated) root access[0m
dietpi-backup.log est vide
Je n'ai vu aucun processus actif aprÚs le démarrage de cron.
Donc, j'ai ajouté au test d'un autre script, pour voir la sortie dans le fichier aprÚs le démarrage de cron:
#!/bin/sh
echo 'Cron works!' > /mnt/rpi/cronworks.log
mais ce script n'a pas démarré - il n'y a pas de fichier "cronworks.log" dans / mnt / rpi /
c'est Ă©trange car il y a un fichier de sortie (backup.log) de mon script avec sauvegarde (du 1er mon post), mais non de ce simple
@eljotx
D'accord, il semble y avoir au moins aussi bien une erreur avec cron. Notez que cron démarre les scripts via run-parts /etc/cron.X/script
et il y a quelques rÚgles, par exemple les scripts doivent appartenir à root (AFAIK) et plus sûr que les scripts ne sont pas autorisés à avoir des fins de fichier. Cela signifie que /etc/cron.daily/script.sh
sera ignorĂ©, le nom doit ĂȘtre /etc/cron.daily/script
place.
Cela ne devrait pas non plus ĂȘtre nĂ©cessaire, mais essayez d'utiliser #!/bin/bash
comme shebang lors de l'utilisation avec des scripts DietPi. Ceux-ci eux-mĂȘmes ont #!/bin/bash
, mais pour ĂȘtre sĂ»r, essayez de l'utiliser Ă©galement dans le script cron.
Le script avait toujours un nom "backup" (sans .sh), je change "#! / Bin / sh" en "#! / Bin / bash" dans le script aussi, et ce script appartient Ă root. Mon script "test" du dernier message fonctionne maintenant aussi.
J'ai tout essayé, mais ne fonctionne toujours pas. Je change le script pour imprimer dans le fichier journal aprÚs avoir terminé un travail et j'ai vu que le script démarre, mais la sauvegarde n'est ni commencée ni terminée (dietpi-backup.log est vide), car je ne peux pas passer au travail suivant comme tar, rclone, etc. Et aussi aprÚs avoir exécuté cron, j'ai vu le processus / usr / sbin / cron -f fonctionner et -bash - c'est normal?
Le script fonctionne toujours si je l'exécute manuellement - mais lorsque la sauvegarde est terminée, je dois cliquer sur OK et Annuler (écrans whiptail), et aprÚs cela - les travaux suivants commencent.
Je pense que ce problÚme est lié à l'utilisation de dietpi-backup pour la sauvegarde automatique démarrée par cron. Cela a fonctionné sur la version 6.9, mais n'a pas fonctionné aprÚs la réécriture de Dietpi-backup.
@eljotx
Encore une fois, juste pour ĂȘtre sĂ»r:
/DietPi/dietpi/dietpi-backup 1
est exécuté avec succÚs?G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1
fonctionne Ă©galement sans aucune erreur, affichant quelque chose comme:root@VM-Jessie:~# G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1
[ OK ] Root access verified.
[ OK ] DietPi-Drive_Manager | RootFS R/W access verified.
[ OK ] DietPi-Backup | Checking for pre-req APT packages: rsync
[ INFO ] DietPi-Backup | Flagged for installation: rsync
[ OK ] DietPi-Backup | APT installation for: rsync, please wait...
Selecting previously unselected package rsync.
(Reading database ... 36227 files and directories currently installed.)
Preparing to unpack .../rsync_3.1.1-3+deb8u1_amd64.deb ...
Unpacking rsync (3.1.1-3+deb8u1) ...
Processing triggers for systemd (215-17+deb8u7) ...
Setting up rsync (3.1.1-3+deb8u1) ...
Processing triggers for systemd (215-17+deb8u7) ...
[ OK ] DietPi-Backup | G_AGI: rsync
DietPi-Backup
âââââââââââââââââââââââââââââââââââââââââââââââââââââ
Mode: Backup
[ OK ] DietPi-Backup | DietPi-Userdata validation: /mnt/dietpi_userdata
[ SUB1 ] DietPi-Services > stop
[ OK ] DietPi-Services | occ maintenance:mode --on
[ OK ] DietPi-Services | stop : cron
[ OK ] DietPi-Services | stop : sonarr
[ OK ] DietPi-Services | stop : lighttpd
[ OK ] DietPi-Services | stop : php5-fpm
[ OK ] DietPi-Services | stop : mysql
[ SUB1 ] DietPi-Services > stop
[ OK ] DietPi-Services | stop : cron
[ OK ] DietPi-Services | stop : sonarr
[ OK ] DietPi-Services | stop : lighttpd
[ OK ] DietPi-Services | stop : php5-fpm
[ OK ] DietPi-Services | stop : mysql
[ INFO ] DietPi-Backup | Backing up to: /mnt/dietpi-backup
[ OK ] DietPi-Backup | Free space check: path=/mnt/dietpi-backup/data | available=5695 MB | required=1861 MB
[ OK ] DietPi-Backup | rsync -aH --delete --delete-excluded --exclude-from=/tmp/.dietpi-backup_filter_inc_exc -v --log-file=/var/log/dietpi-backup.log / /mnt/dietpi-backup/data/
[ INFO ] DietPi-Backup | Backup Completed:
Backup was saved to:
- /mnt/dietpi-backup
- Log file: /var/log/dietpi-backup.log
[ SUB1 ] DietPi-Services > start
[ OK ] DietPi-Services | start : mysql
[ OK ] DietPi-Services | start : php5-fpm
[ OK ] DietPi-Services | start : lighttpd
[ OK ] DietPi-Services | start : sonarr
[ OK ] DietPi-Services | start : cron
[ SUB2 ] DietPi-Process_tool > Apply
[ OK ] DietPi-Process_tool | Completed
[ OK ] DietPi-Services | occ maintenance:mode --off
/DietPi/dietpi/dietpi-backup 1 > /mnt/rpi/backup.log && tar zcfv /mnt/rpi/backup.tar.gz /mnt/backup/dietpi-backup/ >> /mnt/rpi/backup.log && rclone copy /mnt/rpi/backup.tar.gz dysk: -L >> /mnt/rpi/backup.log && rm -r /mnt/rpi/backup.tar.gz >> /mnt/rpi/backup.log && reboot
fonctionne également, montrant que tout a été exécuté et terminé en /mnt/rpi/backup.log
?
run-parts --test /etc/cron.daily
répertorie votre script (s'il est quotidien, sinon ajustez)/usr/sbin/cron -f
+ -bash
est attendu oui, car il démarre un environnement bash à cause de #!/bin/bash
.Si tout ce qui précÚde est vrai, pouvez-vous essayer de démarrer manuellement les run-parts et voir s'il s'exécute comme prévu:
~/testdir/backup
run-parts ~/testdir
J'ai testé comme vous le montrez et sur chaque question: oui, tout fonctionne quand je le lance manuellement.
Je l'ai testé avec la commande run-parts, mais cela fonctionne toujours - quand je le fais manuellement.
Mon script est listé aprÚs utilisation run-parts --test /etc/cron.daily
Si j'ajoute G_USER_INPUTS = 0 et démarre le script manuellement, dois-je voir les écrans (whiptail) avec des informations sur le journal, etc.? Parce que je le vois toujours.
@eljotx
G_USER_INPUTS=0
désactive simplement l'affichage des menus de whiptail. Les informations sont simplement affichées sous forme de messages du terminal et les questions reçoivent une réponse "non" (annulation en cas de vérification d'espace libre insuffisant, pas de vue du journal).
Pour le forcer pour le script, vous devez soit l'exporter avant d'exécuter le script:
#!/bin/bash
export G_USER_INPUTS=0
/DietPi/dietpi/dietpi-backup 1
ou plus facile, donnez-le directement: G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1
Je viens de reconnaßtre que vous avez utilisé G_USER_INPUT=0
ci-dessus sans S
, il doit ĂȘtre G_USER_INPUTS=0
avec S
.
Mais si ce n'est pas la variable est exportĂ©e, les scripts dĂ©termineront si les entrĂ©es utilisateur peuvent ĂȘtre effectuĂ©es ou non. Dans les exĂ©cutions d'unitĂ©s cron et par exemple systemd, tous les scripts DietPi doivent automatiquement dĂ©terminer et affecter G_USER_INPUTS=0
.
Vous pouvez vérifier que notre méthode fonctionne, en ajoutant au début de votre tùche cron (ou une tùche de test):
[[ -t 0 ]] && echo 'This environments allows user inputs' > /mnt/rpi/inputs.log || echo 'This environment does not allow user inputs' > /mnt/rpi/inputs.log
Lors de l'exécution manuelle du script, il doit indiquer que les entrées utilisateur sont autorisées (les menus whiptail s'affichent), s'il est démarré via cron, alors il ne devrait pas, et aucun menu whiptail ne doit bloquer le script.
Je teste d'abord G_USER_INPUTS=0
et si je lance le script manuellement, je consigne:
This environments allows user inputs
sinon si commencer par cron:
This environment does not allow user inputs
Ensuite, j'essaye de changer mon script en ceci:
#!/bin/bash
export G_USER_INPUTS=0
date > /mnt/rpi/backup.log && /DietPi/dietpi/dietpi-backup 1 && (echo "Backup: DONE. " >> /mnt/rpi/backup.log && tar zcfv /mnt/rpi/backup.tar.gz /mnt/backup/dietpi-backup/ && echo "Tar backup: DONE. " >> /mnt/rpi/backup.log && rclone copy /mnt/rpi/backup.tar.gz dysk: && echo "Copy to GDrive: DONE. " >> /mnt/rpi/backup.log && rm -r /mnt/rpi/backup.tar.gz && echo "Remove tar: DONE." >> /mnt/rpi/backup.log && reboot) || echo "Backup failed!" >> /mnt/rpi/backup.log
et dietpi-backup.log est toujours vide, mais backup.log:
lorsque cron a démarré et démarre automatiquement ce script:
pon, 9 lip 2018, 18:54:01 CEST
Backup failed!
quand j'ai démarré le script manuellement:
pon, 9 lip 2018, 18:58:40 CEST
Backup: DONE.
Tar backup: DONE.
Copy to GDrive: DONE.
Remove tar: DONE.
C'est trĂšs ennuyeux ... ensuite, mon script n'a que:
#!/bin/bash
export G_USER_INPUTS=0
/DietPi/dietpi/dietpi-backup 1
et ne fonctionne toujours pas si ce script est lancé par cron.
Le problÚme est toujours avec dietpi-backup lancé par cron à partir de la v6.10. Je pense que c'est un problÚme avec les changements que vous avez apportés à la v6.10 dans le script dietpi-backup.
dietpi-backup.log est toujours vide
@eljotx
Merci pour vos efforts de test.
Je vais passer en revue notre changé. Je n'ai aucune idée pour l'instant. Au moins d'aprÚs vos tests, le script ne se bloque pas (whiptail / G_USER_INPUTS n'est pas le problÚme), mais échoue.
Fait quelques propres tests:
[......] Checking for (elevated) root access
AprÚs avoir commenté la vérification de l'utilisateur root, dans dietpi-backup
, son exécution via cron conduit à :
[FAILED] RootFS is currently Read Only, unable to continue.
Mais:
root@VM-Jessie:~# G_CHECK_ROOTFS_RW
[ OK ] Root access verified.
[ OK ] DietPi-Drive_Manager | RootFS R/W access verified.
@eljotx
tput
est le problĂšme:
tput: No value for $TERM and no -T specified
Correction: https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090
Ce patch corrige également un autre problÚme: "run_ntpd 1" exécuté par cron tous les jours ou toutes les heures ne synchronise pas l'heure (l'horodatage de / var / lib / systemd / clock ne change pas).
@kmakisara
Jep vous avez raison, cela a du sens.
Juste pour Ă©viter la modification manuelle du script pour appliquer le correctif, tous ceux qui ont le mĂȘme problĂšme devraient faire: wget https://raw.githubusercontent.com/Fourdee/DietPi/82ac7b32d32dca9db4fdb824c7ead80174844090/dietpi/func/dietpi-globals -O /DietPi/dietpi/func/dietpi-globals
Je pense que certaines de nos questions ouvertes sont liées à cela. Si run_ntpd
dans cron.hourly Ă©choue, dietpi-logclear
ne sera pas appelé par la suite, ce qui entraßnera le remplissage de / var / log: https://github.com/Fourdee/DietPi/issues/ 1920
Je me demande simplement pourquoi ce problÚme est apparu en premier avec la v6.10 +, car nous utilisions déjà tput
auparavant dans nos tĂąches cron.
Peut-ĂȘtre que quelqu'un peut trouver le changement qui a causĂ© les problĂšmes, afin que nous sachions comment mieux nous en occuper Ă l'avenir:
tput cuu
et tput cols
sont appelés dans les deux cas, ainsi que tput ed
sur chaque autre notification DietPi lors de la suppression de l'animation de traitement.Autres tests Ă ce sujet:
root@VM-Stretch:/tmp# cat /etc/cron.minutely/test
#!/bin/bash
echo "$TERM" &> /tmp/cron.test
tput ed &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root@VM-Stretch:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
$TERM
sur cron est défini sur dumb
tput
prĂ©tend qu'il n'y a aucune valeur pour la variable, mĂȘme si elle est invalide.root@VM-Stretch:/tmp# TERM='dumb' tput cols
237
root@VM-Stretch:/tmp# export TERM='dumb' tput cols
root@VM-Stretch:/tmp# export TERM='dumb' tput cols && echo continue
continue
Comme $ TERM invalide ne conduit Ă aucune erreur (ne conduit simplement Ă aucune sortie de sortie), l'erreur de sortie cron semble ĂȘtre liĂ©e Ă l'absence de -T
, [[ -t 0 ]]
entraĂźne un faux. Peut-ĂȘtre que cela s'est comportĂ© diffĂ©remment avant. DerniĂšre mise ncurses-bin
jour de http://ftp.de.debian.org/debian/pool/main/n/ncurses/
Nous avons déjà eu des problÚmes avec des terminaux non interactifs / invalides, alors quittez maintenant les scripts dietpi- *, si $ TERM vide ou ' unknown
' est trouvé: https://github.com/Fourdee/DietPi/blob/ testing / dietpi / func / dietpi-globals # L30 -L35
tput
respectivement d'autres commandes nécessitant un terminal valide.Test sur v6.9:
root<strong i="6">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish
La mise à jour APT ne contient pas de cron et / ou ncurses (réduction par des packages non liés testés):
apt-get dist-upgrade
et redĂ©marrage, cron n'arrĂȘte pas l'exĂ©cution aprĂšs une erreur de tput:root<strong i="15">@DietPi</strong>:/tmp# cat /etc/cron.minutely/test
#!/bin/bash
echo "$TERM" &> /tmp/cron.test
[[ -t 0 ]] && echo 'interactive' &>> /tmp/cron.test
tput ed &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root<strong i="16">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish
dietpi-update
au maĂźtre v6.11: Veeery Ă©trange, toujours pas de problĂšme ...root<strong i="22">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish
root<strong i="27">@DietPi</strong>:/tmp# cat /etc/cron.minutely/test
#!/bin/bash
echo "$TERM" &> /tmp/cron.test
[[ -t 0 ]] && echo 'interactive' &>> /tmp/cron.test
tput ed &>> /tmp/cron.test
/DietPi/dietpi/dietpi-backup 1 &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root<strong i="28">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
[......] Checking for (elevated) root accesstput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 266: ( 38 + 6 ) / : syntax error: operand expected (error token is "/ ")
finish
dietpi-globals
v6.9:root<strong i="34">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
Checking for (elevated) root accesstput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 308: ((: lines=(38+6)/ : syntax error: operand expected (error token is "/ ")
tput: No value for $TERM and no -T specified
[ OK ] Root access verified.
DietPi-Run_ntpd | systemctl restart systemd-timesyncdtput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 308: ((: lines=(38+6)/ : syntax error: operand expected (error token is "/ ")
[.. ] tput: No value for $TERM and no -T specified
[ OK ] DietPi-Run_ntpd | systemctl restart systemd-timesyncd
[ INFO ] DietPi-Run_ntpd | NTPD: Waiting for completion of systemd-timesyncd (1/60)
[ OK ] DietPi-Run_ntpd | NTPD: systemd-timesyncd synced
[ OK ] NTPD: time sync | Completed
finish
- D'accord, c'est lié aux changements globaux, mais puisque tput
a Ă©chouĂ© et Ă©choue, pourquoi nos scripts se terminent-ils maintenant et ne se sont pas arrĂȘtĂ©s sur la v6.9?
Changement connexe identifié: https://github.com/Fourdee/DietPi/blob/master/dietpi/func/dietpi-globals#L266
local lines=$(( (${#input_string}+6)/$(tput cols) ))
mÚne à la sortie complÚte du script, tandis que (précédent)
local lines
(( lines=(${#input_string}+6)/$(tput cols) ))
a montré l'erreur, mais a permis au script de continuer (voir ci-dessus).
Fix https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090 fonctionne et est Ă©galement la solution la plus propre, car tput
sera complÚtement ignoré dans les shells non interactifs. Mais pour éviter les pannes, nous devons revenir à la méthode précédente pour déclarer la variable d'abord, puis attribuer une valeur ensuite dans l'environnement arithmétique: Commit done https://github.com/Fourdee/DietPi/commit/0f18aa4dc0af8ab910a0173dce8849d5b53c30b0
@eljotx @kmakisara
Pour nettoyer une offre, j'ai ouvert un nouveau problÚme, essayez d'appliquer le correctif mentionné ici et faites un rapport, s'il résout tous les problÚmes: https://github.com/Fourdee/DietPi/issues/1923
Je clÎturerai ce numéro en faveur du nouveau.
Je pourrais réussir ssh dans ma v6.13 mais cela se bloquerait juste aprÚs.
La commande "tput cols" sortait tput: terminal inconnu "rxvt-256color" , résultant en une valeur vide sur la ligne 328 de dietpi-login, ce qui le bloquait pour toujours aprÚs avoir lu avec succÚs la base de données au démarrage initial.
L'exportation de TERM = xterm, un horrible hack, semble avoir corrigé le script de connexion et peut maintenant commencer l'installation.
Si ce n'est pas la bonne section, soyez patient, car je ne sais pas vraiment comment utiliser les problĂšmes de github; J'ai trouvĂ© ce fil aprĂšs des heures de recherche inutile sur Google pour une erreur, si vous le dĂ©placez, laissez peut-ĂȘtre un reste sur les erreurs rxvt-256color, au cas oĂč quelqu'un aurait le mĂȘme problĂšme.
Meilleures salutations!
@wuhei
Salut,
Merci pour le rapport et la solution đ
Quel client SSH utilisez-vous?
@Quatre
J'ouvrais un autre numéro pour cela. Identifié le problÚme: https://github.com/Fourdee/DietPi/issues/2034
@wuhei
AprĂšs vous ĂȘtre connectĂ© Ă SSH, essayez: export TERM='xterm-256color'
âŹ: Ah, c'est essentiellement ce que vous avez dĂ©jĂ dĂ©couvert đ.
Si cela fonctionne, vous pouvez ajouter un script Ă /etc/profile.d/
contenant quelque chose comme:
[[ $SSH_TTY ]] && [[ $TERM =~ 256 ]] && export TERM='xterm-256color'
xterm-256color
, qui est pris en charge par DietPi.Une alternative serait d'installer un package contenant plus de définitions de terminal: G_AGI ncurses-term
@Fourdee OpenSSH_7.7p1, OpenSSL 1.1.0h sur Arch Linux
@MichaIng merci heureux d'avoir pu aider par hasard!
Gardez à l'esprit que je suis un mauvais administrateur systÚme et en suivant cet article de Tom Ryder, j'ai découvert que j'avais une configuration de "déclaration" de terminal assez mal configurée.
En fin de compte, ce qui a résolu le problÚme pour moi était
Je n'ai pas pu scp le fichier terminfo sur mon pi, parce que scp n'est pas installĂ© (peut-ĂȘtre envisager de l'installer avec le serveur dropbear?), Donc je l'ai tĂ©lĂ©chargĂ© sur un serveur que je possĂšde et je ne l'ai juste pas rĂ©cupĂ©rĂ© du pi.
Heureux d'avoir pu aider, applaudissements et encore désolé pour le désordre - Rock on!
@wuhei
Jep, définir $ TERM dans /root/.bashrc
fonctionne bien sûr aussi, l'ajouter à /etc/profile[.d/] le résout à l'échelle du systÚme pour tous les utilisateurs, ce que nous préférerions avec DietPi.
L'article que vous avez liĂ© est plutĂŽt sympa, expliquant trĂšs bien tout et les possibilitĂ©s đ. Vous avez donc essentiellement installĂ© manuellement le type de terminal requis. L'article mentionne Ă©galement le package ncurses-term
comme option pour installer un large éventail de définitions de terminaux. Mais pour garder DietPi mince, je ne suis pas trop désireux de pré-installer ce package pour des cas aussi rares. Au lieu de cela, optez pour la solution bashrc / profile; Il est également possible de vérifier simplement la prise en charge du terminal avant d'appliquer le correctif lors de la connexion SSH.
Pour tester avec le client PuTTY: PuTTY> Connection
> Data
> Terminal-type string
Ă propos de l'installation de SCP: Il existe plusieurs autres protocoles de transfert de fichiers, FTP, SFTP ou lecteurs rĂ©seau NFS, SMB, pour transfĂ©rer des fichiers. Je ne ferais pas de prĂ©-installation, mais je laisserais le choix Ă l'utilisateur de savoir comment obtenir des fichiers du client au serveur. ClĂ© USB, lecteur externe bien sĂ»r est Ă©galement possible ou simplement copier-coller dans le terminal SSH au cas oĂč. Mais de toute façon, comme solution gĂ©nĂ©rale, j'irais avec l'une des deux mĂ©thodes mentionnĂ©es ci-dessus.
Commentaire le plus utile
@Fourdee OpenSSH_7.7p1, OpenSSL 1.1.0h sur Arch Linux
@MichaIng merci heureux d'avoir pu aider par hasard!
Gardez à l'esprit que je suis un mauvais administrateur systÚme et en suivant cet article de Tom Ryder, j'ai découvert que j'avais une configuration de "déclaration" de terminal assez mal configurée.
En fin de compte, ce qui a résolu le problÚme pour moi était
Je n'ai pas pu scp le fichier terminfo sur mon pi, parce que scp n'est pas installĂ© (peut-ĂȘtre envisager de l'installer avec le serveur dropbear?), Donc je l'ai tĂ©lĂ©chargĂ© sur un serveur que je possĂšde et je ne l'ai juste pas rĂ©cupĂ©rĂ© du pi.
Heureux d'avoir pu aider, applaudissements et encore désolé pour le désordre - Rock on!