Fenrir

Bonsoir, La synchronisation bidirectionnelle est un sujet délicat et ne doit jamais être mise en place sans une sauvegarde automatiques des données (des 2 nas). En général on évite le multi maitre quand il s'agit de fichiers, surtout s'ils sont susceptible d'être modifiés en même temps sur les différents nœuds (risque de conflits). De base sur les Synology, il n'y a que CloudStation qui permette de faire du multi maitre, mais je le déconseille pour un usage pro. Ceci étant dit, il y a différents méthodes pour arriver à tes fins, qui dépendent de plusieurs facteurs : le débit (montant et descendant) des 2 connexion lignes la taille (unitaire et totale) des fichiers à répliquer la fréquence (temps réel, quotidienne, ...) de rafraichissement le type (bureautique, multimédia, ...) de fichiers à répliquer Si le débit (par rapport aux modifications) le permet, je ferai ceci : les données principalement modifiées par l'agence A sont sur le nas A les données principalement modifiées par l'agence B sont sur le nas B les données de A sont accessibles depuis le nas B via un partage distant les données de B sont accessibles depuis le nas A via un partage distant (les données de A sont sauvegardées sur B et vice versa) Si tu tiens vraiment à faire du bi directionnelle, le plus fiable reste d'utiliser Unison. Pour ce qui est de sécuriser la liaison, c'est le plus simple : soit tu monte un VPN site à site avec tes routeurs soit tu utilise les fonctions VPN des Syno

Salut La série DS2xx est effectivement idéale pour commencer, par contre, et ça n'engage que moi, je ne conseille pas la gamme J que je trouve trop juste en mémoire (ram) et en cpu. Au début on achète un NAS pour faire du stockage, puis très vite, la plupart des utilisateurs s'aperçoivent qu'ils peuvent faire plein d'autres trucs avec leur nas (serveur web, vpn, sauvegarde différentielle, routeur, gestion d'inventaire, blog, bibliothèque multimédia, ...) et arrivent assez vite à saturer la ram et donc à regretter de ne pas avoir acheté plus puissant dès le début. Maintenant les modèles J sont aussi nettement moins cher. Plex est disponible sur Synology Beaucoup lui préfèrent VideoStation Ça dépend de ton routeur et de ton FAI Il y a des application mobile Synology pour la plupart des fonctions, donc oui Si tu veux accéder à ton Synology depuis l’extérieur, je te recommande un routeur qui te permette de faire du nat/pat (port forwarding), tu peux aussi utiliser certains Synology comme routeur, mais je n'ai pas testé et je ne te le recommande pas.

Pas utilisé depuis plusieurs années, mais à l'époque, SSLH ne fonctionnait qu'avec certains protocole (ceux qu'il sait reconnaitre) et uniquement sur TCP.

J'avais un pb similaire avec mon 710+ au début (on aurait presque dit qu'il entrain en résonance), je l'ai résolu en ajoutant des "bandes antivibration" (du chatterton en vrai) sur les rails. Je ne sais pas si c'est ton soucis, mais tu peux essayer.

si tu veux autoriser le ping (ce qui est utile pour le debug, mais parfois dangereux pour la sécurité), il faut créer une règle dans le parefeu ->Ports : Custom -->Protocole : ICMP

n'importe ou sauf dans /dev/null je te recommande faire un partage dédié aux scripts, accessibles uniquement aux personnes "habilitées" et d'y placer tes codes, ensuite il suffit de les adresser avec le chemin complet (/volumeX/zscripts/compta/script.bsh)

tu peux aussi le faire en php, il y a des class qui n'utilise pas la fonction mail et qui gèrent l'authentification et le tls tu peux aussi installer un vrai mailer avec ipkg

Normalement les données (fichiers) ne seront pas touchées, il faudra simplement réinstaller DSM et refaire les régalges : https://www.synology.com/fr-fr/knowledgebase/tutorials/484 Par contre ce qui n'est pas de type fichier sera perdu. Mais vérifie tout de même tes sauvegardes avant

pare feu du nas ...

Si tu paramètre exactement les mêmes taches (donc que les fichiers vont au même endroit), il fera juste le delta sinon il repartira fera des doublons

+1 Pour l'envoi de mail : telnet smtp.que.tu.peux.utiliser 25 HELO nas.mondomaine MAIL FROM:moi@mon.domaine RCPT TO:toi@ton.domaine DATA From: MOI <moi@mon.domaine> To: TOI <toi@ton.domaine> Subject: le delta blabla blabla . QUIT

Si tu connais l'IP source de l'un ou l'autre des usagers et qu'elle est fixe, tu peux le faire avec une simple route statique Si ce n'est pas le cas, il va falloir faire tu snat Si l'un ou l'autre de tes box sait le faire (ce dont je doute), c'est facile : tu remplace l'ip source par l'ip du routeur Sinon il faut utiliser iptables (postrouting) sur le nas : eth0 : 192.168.1.1/24 (pas de passerelle par défaut) => pour cloudstation eth1 : 192.168.2.1/24 (passerelle par défaut 192.168.2.254) => pour le reste iptables -t nat -A POSTROUTING -p tcp --sport 6690 -m state --state ESTABLISHED,RELATED -j SNAT --to-source 192.168.1.1 Je n'ai pas testé, j'écris à la volée mais ça devrait être un truc du genre En gros ce que ça dit : -t nat : on travail dans la table de nat -A POSTROUTING : on ajoute à la chaine de postrouting (exécuté après la décision de routage) -p tcp --sport : les paquets en TCP qui viennent du port 6690 -m state --state ESTABLISHED,RELATED : qui sont liés à une connexion existante (donc pas les nouveaux paquets) -j SNAT --to-source 192.168.1.1 : on les source-nat avec l'ip 192.168.1.1 (on remplace/force l'ip de sortie) Sinon une petite appliance pfsense ça peut faire le taf

ajoute les nom, prénom, dans l'annuaire LDAP, je ne peux pas vérifier pour le moment, mais je suis presque certain qu'ils existent, peut être pas dans l'interface, mais au moins dans le schéma, tu peux utiliser un client ldap pour ça et si ce n'est pas le cas, rien ne t’empêche d'étendre le schéma De google -> syno : non Si le mdp est changé coté Google, il sera changé coté Google. Mais tu as des éléments de contournement/réponse dans mon post précédent

Ce qui importe c'est que les chaînes de caractères envoyées soient bien dans l'encodage attendu. Si ton logiciel (XBNE) envoi, par exemple, du latin-9 dans une table qui attend de l'UTF-8 et que tu affiche le tout avec un programme qui attend autre chose, alors oui tu vas avoir des cochonneries. De ce que je viens de lire, XBNE ne gère pas l'UTF-8, comme l'indique domlas, essaye de convertir tes tables en latin-1 (ou latin-9) Tu as un exemple ici (dans l'autre sens, il faut donc adapter) : https://docs.moodle.org/23/en/Converting_your_MySQL_database_to_UTF8

il me semble que le client se met à jour depuis ton nas, ton si tu ne mets pas à jour le paquet sur ton syno, le client ne devrait pas bouger, mais c'est de mémoire, je n'utilise plus cloudstation (je l'ai remplacé par rsync)

Je m'étais fait un petit mémo pour un chroot debian, sans le packet chroot syno, je te le livre en vrac (avec quelques commentaires en +), mais avec docker (encore en beta) ça ne sera bientôt plus nécessaire pour la plupart des usages : #0-Prérequis : #avoir un petit linux de dispo (de préférence la même distro et la même archi) #créer un "partage/dossier" sur le nas destiné à accueillir les chroot (dans l'exemple ça sera /volume1/chroot) #avoir un accès ssh au nas #1-sur le linux : mkdir synodebian sudo debootstrap --foreign --arch armhf wheezy synodebian sudo tar cvzpf synodebian.tar.gz synodebian scp synodebian.tar.gz root@adresse_du_nas:/volume1/chroot/ #2-sur le NAS cd /volume1/chroot/ #On décompresse le stage 1 tar xzpf synodebian.tar.gz #On créé un fichier de boot cat > /volume1/chroot/S99chrootDebian.sh << EOF CHROOT=/volume1/chroot/synodebian mount -o bind /dev $CHROOT/dev mount -o bind /proc $CHROOT/proc mount -o bind /dev/pts $CHROOT/dev/pts mount -o bind /sys $CHROOT/sys cp /etc/resolv.conf $CHROOT/etc/resolv.conf #lancement des services dans le chroot (en fonction des besoins) #chroot $CHROOT /etc/init.d/rsyslog start #chroot $CHROOT /etc/init.d/mtab.sh start #chroot $CHROOT /etc/init.d/ssh start EOF #on renomme le système echo synobian > /volume1/chroot/synodebian/etc/hostname echo '127.0.0.1 synobian' > /volume1/chroot/synodebian/etc/hosts chmod 755 /volume1/chroot/S99chrootDebian.sh #on monte le chroot /volume1/chroot/S99chrootDebian.sh #3-dans le chroot chroot /volume1/chroot/synodebian /bin/bash #stage 2 /debootstrap/debootstrap --second-stage #4-configuration d'apt dans le chroot cat > /etc/apt/sources.list << EOF deb http://ftp.fr.debian.org/debian/ wheezy main deb-src http://ftp.fr.debian.org/debian/ wheezy main deb http://security.debian.org/ wheezy/updates main deb-src http://security.debian.org/ wheezy/updates main deb http://ftp.fr.debian.org/debian/ wheezy-updates main deb-src http://ftp.fr.debian.org/debian/ wheezy-updates main EOF cat > /etc/apt/apt.conf << EOF APT::Install-Suggests "false"; APT::Install-Recommends "false"; Aptitude::Recommends-Important "false"; Aptitude::Suggests-Important "false"; EOF #on empeche les services de se lancer lors de l'installation (pour éviter les conflits de port) cat > /usr/sbin/policy-rc.d << EOF #!/bin/sh echo "All runlevel operations denied by policy" >&2 exit 101 EOF #mise à jour de la liste des paquets aptitude update #5-configuration des locales #on installe les locales aptitude install -y locales #on configure les locales (perso je choisi toujours en_US.UTF-8 UTF- #dpkg-reconfigure locales locale-gen en_US.UTF-8 #6-mise à jour et installation des paquets souhaités #on met le système à jour aptitude upgrade -y #et on installe les paquets souhaités (ici bash-completion ssh et vim) aptitude install -y bash-completion ssh vim #on configure le démon ssh pour écouter sur un port libre (ex : 2222) sed -i 's/Port 22/Port 2222/' /etc/ssh/sshd_config #on sort du chroot exit #7-dans le nas #on créé un lien pour que le chroot soirt lancé au démarrage du syno ln -s /volume1/chroot/S99chrootDebian.sh /usr/syno/etc/rc.d/S99chrootDebian.sh #on reboot le nas pour tester reboot #8-test #test #test #enjoy

je suis d'accord, 2 disques en basique c'est préférable à un raid0 (sauf besoin spécifique)

Pour les mots de passe, tu as plein de manière de la faire, en fonction de ce que tu souhaite au final, par exemple : Si tu veux que les mots de passes soient uniquement gérés via le syno, tu peux demander à dirsync de les synchroniser (ils faut que les mots de passe de tes utilisateurs soit stockés en md5 ou en sha1 dans ton annuaire, sinon ça ne marche pas), dans ce cas il faut aussi empêcher les utilisateurs de changer leurs mots de passe depuis gmail (c'est configurable dans admin.google.com) Si tu veux que les mots de passes ne soient gérer que chez Google, le syno de permet de faire de l'oauth (attention, ça ne marche qu'avec les applis web) Si tu veux qu'une fois le compte gmail créé, les utilisateurs puissent changer leurs mots de passe gmail indépendamment du syno, dans ce cas il suffit de mettre un mot de passe à la création et de ne pas les synchroniser Si tu veux faire du SAML, c'est aussi possible, mais je pense que c'est hors de ta portée + toutes les combinaisons des 3 méthodes si dessus (là c'est uniquement avec du code cousu main) Perso je te recommande de laisser les mots de passes vivre leurs vies indépendamment, c'est plus simple pour toi (presque rien à faire) et ça permet aux utilisateurs d'avoir 2 mots de passe (s'ils le souhaitent), donc de ne pas se faire péter leur accès gmail si le syno est compromis et vice versa.

Création/modification : du syno vers Google Je suppose que tu vas utiliser GoogleDirSync pour ça, attention à bien régler la conf avant d'appliquer, surtout ces 2 options : -la désactivation des comptes admin non trouvés dans l'annuaire (je ne sais plus comment c'est noté) : la première fois que j'ai joué avec il y a 5ans, je me suis coupé les pattes -la suppression ou la désactivation des comptes non trouvés dans l'annuaire : je te recommande de régler sur "désactivé" afin de ne pas supprimer les comptes en cas de pb Tu peux aussi mettre des seuils (ne pas appliquer si plus de 10% des comptes sont désactivés, ...) Au taf on utilise principalement les API via un ETL, mais il y a aussi un DirSync qui tourne toutes les 24h en complément Import : de Google vers le syno Il n'y a rien de prévu, mais tu as au moins 3 façon de faire (en fonction du nombre de comptes à importer) : quelques dizaines de comptes : créé les à la main dans le syno, c'est l'affaire que quelques minutes quelques centaines de comptes : export en csv depuis Google puis import en ldif dans le syno (ldapadd ...) plusieurs milliers : il faut sortir l'IDE et coder un peu autour des API (je te recommande d'utiliser un ETL, genre Talend)

Faut il participer aux essais cliniques ? si on ne veut pas courir de risques => non si on veut qu'il y ait des évolutions => oui Pour les logiciels/systèmes en beta, c'est la même chose (quoique peut être moins risqué ...) si on ne veut pas courir de risques => non si on veut qu'il y ait des évolutions => oui Après chacun met le curseur où il veut A titre perso j'ai installé la beta sur un nas de "backup" (il backup le nas qui fait mes backups), donc la prise de risques est faible dans mon cas et ça me permet de tester les nouvelles fonctions, de faire des remontées de bugs, ... et donc d'aider Synology à améliorer mon nas Par contre il est hors de question pour moi de l'installer sur mon nas principal et encore moins au boulot, en pratique je n'installe jamais les nouvelles versions en "prod" avant qu'il n'y ait eu au moins 1 update (des versions beta qui font sauter les droits sur des NAS à 100k€ j'en ai déjà vu)

Coquille dans mon message précédent, il fallait lire player et pas syno, j'ai édité.

J'utilise très peu le service dlna, je préfère utiliser directement VideoStation avec une ChromeCast, mais quand je m'en sert, ça marche très bien. Ça dépend aussi de ton syno player (tous les modèles n'ont pas la même puissance) Le plus simple reste d'essayer. Pour la gestion des metadatas, les syno gèrent ça plutôt efficacement. C'est parfois lent à créer, mais une fois indexé, la consultation est fluide, même avec des milliers de vidéos. edit : par player j'entends la tv, la tablette, le boitier de décodage, ...

Bienvenu, Ici c'est plutôt de Synology qu'on parle, mais tout le monde est le bienvenu. Si ce n'est pas déjà fait, pose tes questions (en donnant le maximum de détails) ici : http://www.nas-forum.com/forum/forum/116-autres-nas/

Avec ce type d'usage, le changement de disque n'est pas une solution viable. Il devrait être envisageable de ne pas garder (au moins sur ton nas) l'intégralité de tes "vidéos de famille HD". Mais si tu dois vraiment tout garder et que tu as le budget, le passage à un NAS 4 baies est le minimum et je te recommande de directement partir sur les gammes entreprise (compatible avec les unité d'expansion). DS415+ : nas 4 baies, environ 500€ DS1515+ : nas 5 baies, environ 700€ DS1815+ : nas 8 baies, environ 900€ DS2415+ : nas 12 baies, environ 1300€ Dans tous les cas en SHR Une unité d'expansion 5 baies (DX515) c'est environ 400€, en version 12 baies (DX1215) c'est proche des 1000€ Mais encore une fois, je pense que tu peux déplacer une partie de ton contenu sur du stockage capacitif moins cher (nas en raid 0, disques externes, blueray, ...). Un bon équilibre pourrait être de prendre un DS415+ (ou un DS1515+) en SHR et de passer ton DS213J en raid 0 pour y archiver le contenu le moins important. Si tu compte vraiment tout garder sur le nas, il va falloir prévoir large. Je trouve que ça fait beaucoup si c'est pour un usage personnel, mais chacun est libre de ses choix