gaetan.cambier

Met le port container en443 et le port externe sur un autre port non utilisé

https://registry.hub.docker.com/u/sjourdan/airtime-docker/ Si tu lis, il redirigé le port 443, la gars a modifier le port par défaut ;)

bon dans : docker --> conteneur tu selectionne ton conteneur airtime tu va dans le menu en faut action --> arreter ensuite tu va dans le menu en haut modifier une fenetre apparait, et c'est la en bas tu ajoute : 9876 9876 TCP ps à la creation du conteneur, c'est à l'etape 1 également

Si c'est en smb la connections, ça pourrait être le verrouillage opportuniste le problème.

dans les paramètre du conteneur airtime dans docker, tu doit declarer le port (9876) comme etant publiquement accessible

en fait, pour un raid 5 de 6 disk, on a une panne toute les 6,002.81 années pour un raid6 de 12 disk, c'est toutes les 143,719.81 années source : http://www.servethehome.com/raid-calculator/raid-reliability-calculator-simple-mttdl-model/

si c'est surveillance station, on peux facilement recuperer un flux via les api proposées

statistiquement, 4 disk en raid5 est moin résistant que 8 disk en raid6 de plus, je suis pas persuadé que le 2* raid 5 soit + rapide vu que le raid6 aura + de disques qd au temps de demarrage des disque, la limite fixée par mdadm (raid logiciel) est de 30 secondes donc la, il y a pas de probleme pour les vibration, c'est sur qu'en augmentant le nombre de disk, ca vibre +, maintenant, faut faire la difference entre les disk sur leur caractéristique réelle, et pas les baratins commercieux

si tu as docker sur ton nas, ca peux se faire simplement : https://registry.hub.docker.com/u/sjourdan/airtime-docker/ autrement, faut cross-compiler airtime et toute ses dependance avec spksrc https://github.com/SynoCommunity/spksrc

pour finir, j'ai profiter d'une coupure de 3h de courant pour ensuite faire les mise à jours a part le radius a reconfigurer et un message comme quoi l'ups est deconnecter (mais ok en ligne de commande), tout semble fonctionner

Bon, vu le premier commentaire, suis pas sur d'enfin passer en 5.2

Version : 5.2-5565 Update 2 (2015/06/09) Important Information A thorough investigation has been done, and it is confirmed that DSM and its related packages are not impacted by the LogJam vulnerability because of the way Synology implements OpenSSL in our system. Fixed Issues Improved the stability of SHR expansion.Improved the stability of SMB transfer when the system is being accessed by an excessive number of clients.Fixed multiple kernel vulnerabilities (CVE-2014-3122, CVE-2014-3153, CVE-2014-0196, and CVE-2014-4699).Fixed an issue where CPU usage could remain high when widget is enabled.Fixed an issue where LDAP users could fail to log in to DSM.Fixed an issue where files could not be downloaded via Windows' terminal.Fixed an issue where system cannot enter hibernation.Fixed an issue where some folders with non-English names would become inaccessible via SMB.Fixed an issue where volumes/iSCSI LUN cannot be displayed after the Synology High Availability system resumes from safe mode with UPS connected.

​c'est fou le support sur ce site, depuis le 16 mai, on constatera qu'il y a pas de reponse en rapport avec le titre de ce post de la part de l'admin ...

Aurait tu ouvert le port 53 sur ton routeur ?

faut utiliser sfdisk

Oui, en ouvrant en ticket syno, il serai encore capable de dire que c'est les paquet tiers la cause :s Illégal instruction: ça a sûrement été mal compiler

A la fois, le réseau fonctionnerait pas, elle posterait même pas de message ici

en gros, il a pas trouvé de partition raid sur les disque c pas bon, c sur :s

ls -R /volume1/ > listing.log

de rien. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 est par defaut maintenant pour tous les client qui l'accepte a ce jour, c'est un criptage sans faiblesse connrue c'est bizarre en effet que synology refuse explicitement les suite en aesgcm, c'est à ce jour les + sur avec le chacha20_poly1305 de google mais ce dernier n'est pas supporté par nos syno en standard

oui, fait un copier coller, c'est + sur en fait la commande signifie que toute ligne commancant par "SSLCipherSuite " va etre remplacé par "SSLCipherSuite EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3 DES:!MD5" dans le fichier "/etc/httpd/conf/extra/httpd-ssl.conf-cipher"

j'attendait ta reponse ici, et pas en privé, j'ai mis du temps à la voir bon, le problème viens du sed : fenir est surement encore en dsm 5.1 et comme la ligne a changé entre les 2 version, forcement ca a pas fonctionne voici une ligne + générique qui en plus devient tenir dans le temps si jamais il fallais la retapper : sed -i 's/SSLCipherSuite .*/SSLCipherSuite EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3 DES:!MD5/g' /etc/httpd/conf/extra/httpd-ssl.conf-cipher ensuite, tu redemmare apache : synoservicecfg --restart httpd-user

panneau de config --> service web --> hote virtuel tu met 2 ligne dedans : web www.domain.tld http web www.domain.tld https 443 et c'est réglé

j'ai le resultat : pour faire claire, la commande sed est surement pas passée en ssh, tu peux lancer cette commande : grep SSLCipherSuite /etc/httpd/conf/extra/httpd-ssl.conf-cipher et tu me copie le retour de la commande (en sélectionnant, ca copie automatiquement) au passage, peux-tu me donner aussi le retour de cette commande : openssl ciphers CHACHA20 edit : c'est qd meme bizare : le sha256/384 a priorité sur le sha en theorie mais il avec les simulation, on a le sha qui est pris dans certain cas en tls 1.2 :s edit2 : bon, c'est les suite gcm qui sont tout simplement absente, ca redevient logique

toujour aucune modification des millier de titre tronque ... et aucune repose claire sur le problème