Fenrir

Ça ne le dérange pas plus que ça normalement du moment que ces listes ne sont pas déclarées dans sa conf, c'était juste une suggestion pour mettre un exemple fonctionnel. En passant, quelques remarques sur le script /usr/local/squidguard/bin/update_db.sh : même soucis avec le wget le bloc if de la ligne 29 empêche le rsync s'il y a un soucis if [ ! $? -eq 0 ] ; then echo "An non-Adblock list was detected" exit 1 fi sed -e "${ADBLOCK_PATTERNS}" "${LIST_FILE_PATH}" >> "${FILTER_ADBLOCK_DIR}/expressions" ###=> if [ $? -eq 0 ] ; then sed -e "${ADBLOCK_PATTERNS}" "${LIST_FILE_PATH}" >> "${FILTER_ADBLOCK_DIR}/expressions" else echo "A non-Adblock list was detected" fi le rsync, -a est équivalent à -rlptgoD, donc les options rpogt sont en double et le -v c'est pour verbose rsync -a ${RSYNC_DIR} .

crontab toutes les minutes, ta supervision laisse 10 secondes au serveur pour répondre et cette mise à jour ne touchait pas le serveur web => rien d'anormal ;)

Un petit tour sur le site officiel ou dans la doc et tu aurais trouvé Installe CloudStation Drive sur le pc et tu auras ce que tu demandes normalement

@gaetan.cambier Un petit bug (qui en explique plusieurs) => pas de limites pour wget Les sites miroirs où tu récupères les listes (en particulier celles d'adblock) ne sont pas toujours joignables (notamment en IPv6). comme tu n'as pas spécifié de limites à wget, il essaye indéfiniment de récupérer les fichiers (comportement par défaut) =>ça bloque le process d’installation : =>il ne télécharge pas les autres fichiers (db squidguard) =>squid ne se lance pas après son installation (car il attend les process précédents) =>le gestionnaire de paquet reste en "Installing" Une suggestion de correction serait : ajouter --timeout=10 aux instructions wget incorporer une micro liste par défaut (un fichier d'une ligne suffit) dans le package afin d'éviter d'avoir une DB vide en cas de soucis de téléchargement Pour le point 2, tu peux mettre une url invalide (exemple.org), ce qui permettrait d'ajouter un exemple/test fonctionnel dans la conf de squidguard sans gêner personne.

c'est noté, merci pour le test

ça ne veut pas dire que les disques sont vraiment ok fais le test pour être fixé

via les partage réseau c'est le plus simple, sinon tu as des actions possibles en faisant clique droit sur un dossier dans filestation Pour rappel il y a une documentation intégrée dans DSM, je t'invites à la consulter

Si tu as laissé les réglages par défaut, le syno l'a peut être installé tout seul Dans tous les cas, c'est dans Panneau de configuration->Mise à jour C'est peut être aussi une mise à jour de paquets (-> Centre de paquets)

Nouvelle version, c'est l'occasion de tester l'upgrade, un volontaire ? (si j'ai le temps et que j'y pense je le ferais demain à chaud au taf) https://www.synology.com/fr-fr/releaseNote/DS712+ (2016/04/14) Improved the stability when connecting via AFP protocol. Fixed a security vulnerability regarding Samba file service (CVE-2016-2118, also known as Badlock). Fixed an issue where a false-alarm warning about unexpected file changes occurs when saving files in Office Excel 2003. Fixed an issue where Docker DSM might be terminated even when valid licenses are imported. Fixed multiple issues that might cause iSCSI service to hang under heavy loading and performing Vmware VAAI commands. Fixed an issue in which the configuration change of VLAN could result in abnormal functionality of certain packages. e.g. Surveillance Station Fixed an issue where the DSM welcome title and message will be reset to default if users set it to blank. Note: This update does not require system reboot.

Il suffit de suivre les "pastilles rouges". Sur le panneau de conf, tu dois avoir une pastille avec un 1 ... jusqu'à l’écran de mise à jour qui se nomme curieusement "mise à jour" ...

Certains services empêchent la mise en veille, même chose si un périphérique réseau est connecté (une TV par exemple).

Si c'était vraiment le cas, tu ne pourrais pas le savoir (il ne démarrerait pas, le système est installé sur le disque). Si tu y accèdes encore (DSM), commence par vérifier le gestionnaire de stockage (tu peux nous faire des captures). Pour la suite, il faut le faire en SSH (si ne sait pas comment faire, une petite recherche te donneras les infos) Connecte toi en ssh sur le nas et entre les commandes suivantes : df -h mount Pendant que tu y es, tu peux vérifier la présence (ou l'absence, temporaire j'espère) de tes fichiers en regardant dans /volume1 (ls /volume1/).

Si ton nas a vraiment un soucis, tu peux demander aux 2 à la fois, tu verras lequel te propose la meilleurs solution. Mais commence par faire le test de carte mère, c'est peut être tout simplement un DD qui a un soucis (dans ce cas c'est DD qu'il faudra renvoyer).

With DSM 6.0, you can define Triggered Task for boot/shutdown right in DSM (Task Scheduler)

Il faut faire un test de carte mère (tu trouveras la doc sur le site de syno). Vu ce que tu décris et l'age de ton nas (il est très récent), je pense qu'un petit message au support s'impose => RMA à mon avis

Dans ce cas ton service informatique devrait te proposer une solution de stockage qui fonctionne ... (et si tu as besoin du nas, tu pourra monter ce dossier dans le nas pour y copier des trucs)

Pour faire ça en masse, vous pouvez utiliser un ETL (talend DI par exemple, c'est gratuit)

2 possibilités sans passer par le compte invité : comme dit précédentment, login/pass bidon affiché au tableau, pas besoin de créer un compte par élève/prof Si tu as un AD, tu peux y connecter ton nas et profiter de l'authentification AD

je parlais du chiffrement SSH rsync est très très bien documenté, c'est aussi ce qu'utilise le syno dans la plupart des ses opérations de backup De plus le faire "à la main" permet une souplesse bien plus grande que ce que l'interface DSM propose

Sans parler de fiabilité (HyperBackuo vient de sortir, donc c'est l'inconnue), il est préférable de scinder les backup pour une raison toute simple : la granularité sauvegarder un gros dossier +si on fait de la déduplication, ça peut être rentable (les syno n'en font pas à ma connaissance) +c'est rapide à mettre en place -c'est long : si ça coupe il faut parfois tout reprendre -idem pour les restauration -seul l'admin peut (ou devrait pouvoir) s'en servir -tous les fichiers subissent la même politique : garder un historique chiffré de ses photos de famille c'est justifié, faire la même chose avec ses films (achetés légalement n'est ce pas) ça ne sert pas à grand chose -si on manque d'espace ... on manque d'espace -si les données sont chiffrées, un bloc corrompu peut entrainer la perte de toutes les données sauvegarder par "petits" bouts : -on perd en déduplication (les syno n'en font pas à ma connaissance) -un peu plus long mettre en place +les sauvegardes sont plus rapides (moins de diff à faire d'un coup) +idem pour les restauration +on peut déléguer les accès pour certaines parties +on peut avoir des politiques de sauvegardes différentes selon les besoin et la criticité des données +si on manque de place, on a juste à déplacer un bout de la sauvegarde ailleurs (autre nas par exemple), sans toucher au reste +si les données sont chiffrées, un bloc corrompu entrainer la perte des données touchées par ce bloc => c'est un avis personnel (saupoudré de quelques années d’expérience) Après tu fais comme tu veux

pour ne pas se faire attraper par un radar, il suffit de ne pas dépasser la limite ou de bien connaitre leurs emplacements => moins de chance de se faire flasher, mais tout autant de chance créer des dommages aux autres Oui, mais payer 50€ par an à un inconnu pour lui donner la possibilité technique d'aller farfouiller dans mes affaires, ça ne me semble pas être une bonne opération (cherche mes réponses dans d'autres sujets similaire sur le forum pour plus de détails). Ou alors tu as sacrément confiance (perso je me méfie plus des mafias que de l'hadopi ...). Pour moins du double, tu as 1 an d'abonnement amazon, canalplay ou netflix et si c'est de la musique que tu cherches, c'est gratuit (en échange quelques pubs de ta vie privée). ------------- les entreprises qui sont payés par l'hadopi (avec nos impôts) obéissent aux lois de l'offre et de la demande : elles surveillent en priorité les produits des grosses entreprises, surtout quand les produits viennent de sortir elles regardent quasi exclusivement les réseaux P2P elles utilisent des techno simplistes (pas forcement par méconnaissance technique, simplement parce que faire les choses bien, ça coute cher) elles ne peuvent pratiquement rien si elles doivent contacter une juridiction étrangère ... il suffit d'être moins gourmand et plus malin pour rester discret : ne pas se jeter sur le premier cam filmé avec un iphone de travers lors de la sortie d'une grosse production => la patience est une vertu elles ne les connaissent pas tous (loin s'en faut) => l'autoroute n'est pas toujours le meilleur des chemin elles sont assez facilement identifiables c'est là que tor, les proxy, les vpn, les amis, entrent en jeu ...

Peut le niveau de chiffrement qui commence à être très différent (4.2 vs 6.0 ça fait un bel écart). Tu peux essayer de jouer la dessus (dans les paramètres, on peut régler le niveau de chiffrement de ssh, mais je ne sais pas si c'est uniquement le serveur ou le serveur et le client) En rsync direct (vrai rsync, pas via ssh) ça devrait encore marcher sans soucis (pour info c'est une ligne de commande à entrer dans le planificateur des taches)

De Windows, en fonction de l’historique des postes (conf, mises à jour, softs installés, ...), les partages invités ne fonctionnent pas toujours. Il n'y a pas de méthode miracle pour corriger le pb à coup sûr dans tous les cas, trop de paramètres à prendre en compte. Il faut y aller au feeling, on peut commencer par comparer les conf des différentes machines (état du compte invité par exemple, mais aussi paramètres réseau, antivirus, firewall, version des mise à jour, ...). Par contre, un point important : autoriser le partage invité (guest) créé une ÉNORME brèche dans la sécurité d'un équipement (nas, pc, ...), je ne vais pas rentrer dans les détails, mais en version courte, ça permet d'avoir déjà un pied dans le pc sans avoir à "casser" l'authentification, on peut donc directement attaquer les failles locales. Les virus/vers historiques comme sasser, blaster, ... passaient par là et des plus récent s'en servent toujours. En pratique il vaut mieux le couper et dans ton cas, il est plus fiable et plus sécurisé de créer un compte basique, même si le login/password (public/public par exemple) doit être affiché sur tous les murs. De plus avec un vrai compte, tu pourras donner un accès au nas via l'interface web ou les appli mobile.

l'un, l'autre, les 2 Si c'est bien un soucis de chiffrement (c'est une hypothèse), il faut simplement que les 2 (client et serveur) s'entendent sur une méthode commune Autre possibilité, un soucis de firewall et/ou de nat et/ou d'ip => dans ce cas c'est difficile de t'aider, il faudrait passer en revu tous les éléments de la chaine : as tu un autre NAT vers ton nas qui fonctionne depuis ton serveur ? si oui, vérifie que les 2 règles (ssh et l'autre) sont identiques (sauf le port bien sur) si non, essaye de créer une règle pour un autre protocole en TCP (http c'est le plus simple) et test de puis ton serveur avec un wget/curl/telnet Tu peux aussi tester depuis une autre adresse internet (un autre serveur, un ami, un voisin, un smartphone ...) avec un autre client ssh

Il peut s'agir d'un soucis au niveau du chiffrement, trop ou pas assez fort (ou avec une méthode non supportée). On peut faire quelques ajustement dans DSM pour ça (dans les paramètres). Tu peux aussi le régler coté client ssh sur ton serveur. chez moi (enfin depuis internet vers mon nas en DSM 6.0) ça fonctionne sans soucis (je viens de tester)