bouks

J'ai acheté un disque Kingston, il fait un drôle de son.

Il faut utiliser DHCP.

https://www.apc.com/shop/fr/fr/tools/replacement-battery-selector?Nr=OR(sku.partNum%3AAPCRBC124)&parentCategory=Back-UPS+Pro&partNumber=BR1500G-FR&rbcQty=1&showAll=true

Non, non, il y a juste à ouvrir la trappe du logement batterie, sortir la batterie en tirant dessus, enfoncer la nouvelle à la place et refermer la trappe. Aucun outil n'est nécessaire.

@Dr.Genova Oui, tu peux acheter juste une batterie de rechange pour ton modèle d'onduleur. C'est le cas sur tous les back-ups pro il me semble.

J'ai croisé Fernand de Magellan sur le forum, il semblait ne pas avoir de problème. Désolé... j'arrive 😅

Je ne vois pas. Il faudrait aller voir dans les différents logs qui peuvent être concernés (genre auth.log ou syslog) s'il y a plus de détails. Sinon créer un ticket chez Synology. Ils pourront se connecter à ton NAS en SSH et vérifier eux-même directement. Vers la bonne machine ? 🙂

@oracle7 Si tu n'y connais rien en PHP ou à Apache, il me semble hasardeux de te conseiller des manipulations en shell. Je pense que le mieux est de créer un ticket auprès de Synology. Sinon le DirectoryIndex se paramètre normalement dans les fichiers de conf des hôtes qui sont dans /etc/apache/sites-enabled/ Je dis "normalement" parce que je n'ai jamais installé Apache sur un NAS, et Synology est libre d'implémenter autrement le paquet (original). Après ça peut venir d'autre chose, parce que c'est tout de même étonnant qu'une mise à jour de PHP change ce type de comportement d'Apache. Es-tu certain qu'il n'y avait que PHP qui a été mis à jour ?

@Jeff777 Je n'ai jamais fait de réplication, je ne peux pas te répondre rapidement. Et je t'avoue que je n'ai pas envie de me taper de la doc pour un truc qui ne me sert pas. 🙂

Normalement tu crées un répertoire squelette dans /etc/skel Mais je ne sais pas si les NAS Synology le gèrent. A tester et fais nous un retour.

Vérifie que tu as " DirectoryIndex index.php " dans la conf Apache (ou celle de ton hôte vituel). Il faut peut-être que tu fasses un alias vers le répertoire de PMA dans le fichier de conf d'Apache ou de ton hôte virtuel.

Utilise SSH. Si tu sais administrer une machine Linux, utilise une authentification par clé pour éviter de taper le mot de passe. En alternative tu peux installer le paquet sshpass sur ton PC.

Hello. Je ne suis pas expert de PHP sur NAS Synology. Voilà ce que je sais: Il est possible d'avoir des versions concurrentes de PHP qui tournent sur la même machine. C'est notamment utile quand des applications diverses ne gèrent pas les mêmes versions. C'est assez courant sur une machine qui fait du mutualisé par exemple. Il faudrait que tu vérifies les versions de Wordpress et Joomla installées et voir quelles versions de PHP elles acceptent. Voir aussi si d'autres paquets utilisent PHP. Si une application ne déclare pas de compatibilité avec PHP7, alors il y a de fortes chances qu'elle ne fonctionne plus si tu désinstalles PHP5. Donc voir la doc des applications qui tournent sur PHP. Dans tous les cas, une désinstallation de PHP ne met aucunement ton NAS en danger. Le seul risque, c'est une application web qui ne fonctionne plus (ou partiellement plus) et il suffit de réinstaller le paquet de la version concernée. Faut voir ce que disent les messages d'alerte. Et toujours avec une sauvegarde à portée. 🙂 Wordpress, Joomla, probablement Webstation. Apache, en lui-même, n'a pas besoin de PHP. MariaDB10 n'a pas besoin de PHP (mais si tu utilises phpMyAdmin, lui, il en a besoin). S'ils sont "scotchés": non. Un backup. 🙂 Oui, mais tu n'as pas fait "rechercher sur le web" ! 😡😁

Et dans "Panneau de configuration > sécurité > pare-feu" tu as quoi ?

@jeanyveso Ah ben dans ce cas c'est un problème sur le mac, pas un problème de NAS. Tu devrais aller te renseigner sur un forum Apple.

J'espère plutôt que ce modèle est bien silencieux. 🙂 Malheureusement Synology ne communique pas sur la pollution sonore de ce modèle.

FR https://fr.wikipedia.org/wiki/RAID_(informatique)#RAID_5_:_volume_agrégé_par_bandes_à_parité_répartie https://buzut.net/tirez-le-meilleur-de-vos-disques-durs-avec-raid/ https://zestedesavoir.com/billets/1828/disques-durs-special-nas-et-reconstruction-de-raid/ https://www.clubic.com/forum/t/le-raid-ami-ou-ennemi/359632 EN https://www.digistor.com.au/the-latest/Whether-RAID-5-is-still-safe-in-2019/ http://magj.github.io/raid-failure/ Non. Mais je m'appuie sur de la documentation et des calculs. Tu as peut-être cotoyé des serveurs de toutes sortes, cependant: - "pendant 30 ans", on parle d'une situation actuelle, ou récente. - "J'ai cotoyé beaucoup de serveurs de toutes sortes et j'ai aussi changé beaucoup de disks ... en datacenter", nous n'avons pas du tout les mêmes disques que ceux utilisés en datacenter. Le taux d'erreur des disques "de datacenter" sont au moins 10 fois plus bas.

Si tu regardes les caractéristiques de tes disques par exemple: Seagate IronWolf ST4000VN008 Ils ont un taux d'erreurs maximal de lecture irréparables de 10E-15. C'est à dire une erreur tous les 12To de lecture environ. Le nombre de 28% de chance de récupération s'estime comme suit: Chance de réussite de reconstruction = (1 - 10E-15)NxTx8 N = le nombre de disques T = La taille des disques en octet (4000000000000 pour toi) 8 = pour convertir la taille en bits Si tu fais le calcul, tu arrives à environ 28% de taux de réussite. Ce taux de réussite ne prend évidemment pas en compte le risque de panne concomitante de disque due à autre chose qu'à ce taux d'erreur de lecture. J'entends bien. Mais ton expérience personnelle n'est pas relevante. Tu n'as pas fait 1000 ou 10000 reconstructions pour pouvoir faire une estimation empirique du risque qui soit significative. Pas forcément car la reconstruction dure encore plus longtemps, et donc tu as encore plus de chance qu'un deuxième ou un troisième disque (du même âge et de la même série) tombe en panne lors de la reconstruction. La reconstruction ça sollicite énormément les disques. Tu as raison. Mais force est de constater que pas mal de gens qui font des demandes d'aide ici ne font pas de sauvegarde et se reposent uniquement sur le RAID. Pire que RAID5 en temps d'accès aux données et en reconstruction puisqu'elle dure plus longtemps. Et double pantalon. Parce que le risque n'est pas que la chute. Il y a aussi le risque de craquement. 😄

@niklos0 Pas trop de temps aujourd'hui mais je t'ai trouvé ça vite fait pendant le café. http://www.e-novatic.fr/tout-savoir-sur-le-stockage/ Au niveau de la continuité de service, en RAID 5, ta chance de réussite de reconstruction (qui dégrade le service pendant ce temps) avec 4 disques de 4To n'est que de 28%. Sans parler d'une panne concomitante d'un autre disque. Quand on voit pas mal d'utilisateurs sur le forum qui se contentent d'un RAID 5 comme sécurité des données, ça fait flipper. En RAID 6 c'est pire.

Hello. Pour du stockage de films et de séries il est "over-exagéré" de faire du SHR2 et du BTRFS. Tu fais surtravailler ton NAS pour rien et tu perds énormément d'espace qui pourrait servir pour de la sauvegarde. Mais pour le contenu familial c'est autre chose. Il faut donc mieux faire deux groupes de disques différents paramétrés différement, chacun pour un usage. Et un backup externe.

C'est malheureusement une croyance très répandue que de penser qu'un NAS en RAID est un système de sauvegarde de lui-même.

Tu peux tout à fait mettre un disque de 4To "dans l'éventualité de faire évoluer" ton système. C'est juste que pour l'instant tu ne pourras pas augmenter la taille de ton volume tant que tu n'auras pas mis un deuxième 4To. Au cas où... Avant de te lancer dans le changement du disque et la reconstruction du RAID, fais une sauvegarde si tu n'en as pas. 🙂

Un type qui s'appelle @Dracuula et qui poste dans un sujet "wd RED, carton ROUGE", je suis méfiant. 😄

@.Shad. Mais pour ton accès SSH, je pense que tu peux aller changer AllowTcpForwarding à "yes" dans: /etc/ssh/sshd_config ou spécifier les utilisateurs qui y ont droit avec Match (cf les dernières lignes du fichier de conf qui autorise root et admin)

Non aucune. Je pense que tu fais l'amalgame entre SSH "pur" et SFTP sans accès au shell.