Fenrir

Pour l'aspect NAT, je confirme que ça marche avec 2 commandes, c'est d’ailleurs ce que fait le syno quand on active le vpn echo 1 > /proc/sys/net/ipv4/ip_forward iptables -A POSTROUTING -s $LAN -j MASQUERADE C'est bien entendu à affiner, par exemple en excluant le nas comme destination (! -d $NASIP), en limitant le sens (-o eth1) Par contre il faut bien veiller à l'aspect sécurité et garder en mémoire que la moindre mise à jour (du syno ou d'un paquet touchant au réseau) ou le moindre réglage sur les fonctions réseau du syno (interfaces, vpn, dhcp, dns, ...) fera sauter les règles, transformant votre syno en porte d'accès à votre réseau local depuis Internet

Il faut mettre les commandes dans un script et copier (ou lier) ce script dans le dossier /usr/syno/etc/rc.d/ edit : tu peux aussi, lancer ce script via cron (en testant que le volume ne soit pas déjà monté)

Quand on envoi un mail, le serveur d'envoi utilise les enregistrements MX du domaine du destinataire pour déterminer les serveurs de destination. Si le mail du destinataire est en @mondomaineperso.com, les serveurs de réception seront les MX de mondomaineperso.com Donc si tu es propriétaire du domaine (et pas seulement de l'adresse mail), tu peux faire pointer les enregistrements MX de ce domaine sur ton synology (en pratique je ne le recommande pas, mais c'est un avis perso), ainsi tous les mails envoyés vers les adresses de ton domaine arriveront sur ton nas. Après tu as d'autres possibilités, qui dépendent de tes hébergeurs : par exemple Gmail (version business/education) propose de router tout ou partie des mails vers un serveur bien précis tu peux aussi jouer avec des domaines intermédiaires (en faisant des forward) ou encore te contenter de récupérer les mails sur tes différentes boites (en imap par exemple) pour les stocker sur ton syno ...

Si la méthode de magicIdea (qui est la plus simple/fiable) n'est pas possible, il faut simplement t'assurer que tu copie les fichiers en USB au bon endroit sur la destination Je te recommande d'utiliser un disque avec le même système de fichier (ext4 pour un syno) Quand j'ai besoin de faire ça, je lance d'abord une première synchro à vide ou presque (je laisse la structure des dossiers et quelques petits fichier témoins), si c'est bon, je refais le rsync complet sur le disque externe avec les mêmes paramètres (sauf l'adresse du serveur !!)

welcome

Il s'agit de TAG (auteur, titre, commentaires, ...) qui sont embarqués dans la plupart des fichiers multimédia. C'est utiliser pour bien identifier un média, dans le cas des médias tombés du camionloud, on y retrouve les tag des personnes qui ont créé le fichier Perso je les retire

pour faire court : ça permet d'avoir un produit clefs en main pour le grand public (les gens copient les photos dans /photo et pouf, elles apparaissent dans PhotoStation, idem pour la music, ...) Si tu n'utilise le Syno que comme un nas, ils ne servent pas à grand chose. Mais le Syno embarque plein d'autres fonctions (VideoStation, PhotoStation, DLNA, ...), qui, par défaut, utilisent ces partages pour fonctionner Je m'étais fais la même réflexion avec mon 1er Syno : l'utiliser uniquement comme un nas ou me servir des autres fonctions Au final j'ai choisi d’exploiter le Syno en entier, pas seulement sa fonction nas, et je ne le regrette pas (par exemple pour avoir les photos sur un grand écran et mon téléphone sans avoir à passer par un cd ou une clef usb ou ...) A noter que PhotoStation peut utiliser Flickr De plus tu ne peux pas supprimer ces partages, donc autant les utiliser, ou les laisser vide. Mais dans tous les cas ils ne sont pas gênants. A titre perso, je n'utilise pas le /photo, mais le /home/photo (comme ça chaque utilisateur gère son PhotoStation) par contre toute la musique est dans /music. Chacun son usage Oui Mais je ne te recommande pas de le faire comme ça De manière général (ce n'est pas lié au Syno), ce qui est dans home (ou /homes/user) ne doit être accessible qu'à 1 utilisateur (hors admin) Ce qui est commun à plusieurs utilisateurs doit être stocké ailleurs et accessible aux utilisateurs d'un groupe =>il ne faut pas mettre de droits sur des sous dossiers, ça devient très vite ingérable (on ne sait plus qui qui accède à quoi) ex : /homes/fenrir : n'est accessible qu'à l'utilisateur fenrir (qui peut très bien, de son propre chef, décider de rendre accessible ses photos à tout le monde via photostation) /music : est accessible à tous les membres du groupe "grp-photo" (en général on créé 2 groupes, 1 en lecture seul et 1 en lecture+écriture) Pour reprendre ton exemple, stock tes photos dans /photo et gère les droits à ce niveau Maintenant c'est ton NAS , tu peux le gérer à ta manière (puis comme c'est du Linux, tu peux faire presque tout ce que tu veux) edit : pour la manip que je propose avec Hubic, ça à peut de chose près ce qui est fait sur un Mac avec certains dossiers

J'ai fait le test, on ne peut effectivement utiliser qu'une seule fois Hubic par compte, dommage... mais il y a d'autres manières d'arriver à ce que tu veux, à condition d'accepter de mettre un peu les mains dans le cambouis et de bien comprendre ce que l'on fait En informatique, les barrières ne sont, en général, qu'un manque de connaissances (ce n'est absolument pas une critique ni péjoratif). J'aime à penser que ceux qui s'offrent un Syno (ou équivalent) ont de la curiosité et l'envi d'apprendre Voici un exemple qui marche (je l'ai testé en écrivant ce message) si tu veux jouer On monte les partages à synchroniser (music, photo, video, ...) dans un même dossier et on synchronise ce dernier avec Hubic 0-Créé un compte Hubic de test afin de ne pas toucher à tes données déjà synchronisées En Web sur le Syno 1-créé 3 partages pour tester : test, testdocuments et testimages test est un vrai faux partage que l'on va utiliser uniquement pour la synchro testdocuments représente l'un de tes partages testimages en représente un autre 2-place les bons droits dessus 3-n'active pas l'indexation sur le partage test 4-dans le partage test, créé 2 dossiers : testdocuments : on va se servir de ce dossier pour "afficher" le contenu du partage testdocuments testimages : on va se servir de ce dossier pour "afficher" le contenu du partage testimages 5-masque le partage test (Hide this shared folder in "My Network Places"), ce n'est pas obligatoire mais je te le recommande 6-copie quelques fichiers dans les partages testdocuments et testimages histoire d'avoir un peu de contenu 7-en SSH sur le Syno, entre les commandes suivantes : mount --bind /volume1/testdocuments /volume1/test/testdocuments mount --bind /volume1/testimages /volume1/test/testimages =>tu devrais voir le contenu des partages testdocuments et testimages dans les dossiers testdocuments et testimages du partage test 8-configure CloudSync pour synchroniser le partage test en entier vers Hubic Si tu as bien compris la manipulation et que ça te satisfait, tu n'as plus qu'à adapter les partages/dossiers La commande mount n'est pas persistante au reboot, si tu veux que ce montage soit permanent, il faut créé un petit script qui fasse cette action au démarrage du Syno (tu peux aussi modifier le fstab, mais ce n'est pas recommandé sur un Syno) ps : la commande pour démonter, c'est umount suivi du point de montage (par exemple : umount /volume1/test/testdocuments) pps : monter A dans B ça veut dire rendre disponible le contenu de A dans B

Je pense, mais je n'ai pas testé, que tu peux créer plusieurs profils CloudSync avec le même compte Hubic sur le Syno Ce que je ferai (sous réserve que ce soit possible) : 1-sur Hubic : création de dossiers correspondants aux partages du nas 2-sur le nas : 1 profil par partage, synchronisé avec le dossier correspondant chez Hubic Ce qui est certain par contre, c'est que Syno ne te permet pas de synchroniser tout un volume car les applis et certains paramètres du Syno sont stockés dans ce volume (tu ne peux les voir qu'en ssh), mais surtout, permettre de synchroniser tout un volume nécessiterait une gestion des droits trop complexe (n'importe quel utilisateur pourrait synchroniser tous les partages, même ceux auxquels il n'a pas accès, et donc y accéderait in fine)

merci pour l'nfo, comme j'utilise mes propres certificats je n'avais jamais fait attention à l'emprunte de celui par défaut.

il suffit de regarder comment est signé le certificat par défaut perso j'ai ma propre pki et je créé des sha256 (donc sha-2) sans soucis

Pour le mail, il faut vérifier qu'il y a bien un client mail sur le syno, sinon tu peux le faire avec un telnet. Pour le log, c'est le RM à la fin qui doit faire le ménage. Pour les stats, regarde les options de rsync, il y a tout ce qu'il faut.

à la fin de ta commande, tu peux déclencher d'autres opérations. ; & et && permettent d'enchainer des commandes commande1 ; commande2 #commande2 sera lancée quand commande1 sera terminée commande1 & commande2 #commande2 sera lancée juste après le lancement de commande1 commande1 && commande2 #commande2 sera lancée si commande1 se termine sans erreur commande1 && commande2 ; commande3 #tu peux les enchainer à volonté Mais il est plus propre et plus souple de faire un petit script #!/bin/bash fichierlog='/tmp/rsync.log' email='ton@adresse.mail' #la commande rsync avec toutes les options qui vont bien rsync ... > $fichierlog cat $fichierlog | mail -s "fini" $email rm $fichierlog Sinon, en fonction de ce que tu souhaite sauvegarder, rsync n'est pas forcement la meilleur des options. Perso je fais des archives que je sauvegarde via download station en https. J'ai fait 2 petites docs ici : http://blog.fenrir.fr/tag/sauvegarde-2/

J'ai souvent lu la même chose sur différents sites/forums, mais ils n'indiquent que trop rarement les conditions EXACTES des tests. Si le PC qui fait les tests a un lien 1Gbtis, même avec un NAS à 10Gbits tu ne dépasseras pas les 1Gbits. C'est toujours le maillon le plus faible lent qui donne le ton. Je n'ai pas testé l'aggregation avec un syno, mais j'en utilise quotidiennement au boulot et j'obtiens facilement des débits bien supérieurs à ce qu'un simple lien permet. Il y a différents type d'aggregation, le débit dépend des réglages, du matériel, de l'OS et du logiciel de copie utilisé. Par contre, dans la pratique et en conditions "home user", il est rare de pouvoir dépasser les 1Gbits/s car il faut : 1-un nas qui dispose d'au moins 2 cartes 1Gbits en 802.3ad et de disques suffisamment rapide (plus de 100Mo/s) 2-un pc qui dispose d'au moins 2 cartes 1Gbits en 802.3ad et de disques suffisamment rapide (plus de 100Mo/s) 3-le tout connecté à un switch qui gère l'agreggation et qui a un fond de panier supérieur au débit escompté 4-et d'un logiciel de copie qui gère le multiplexage Autant dire qu'on ne rencontre pas ça chez les Michu =>donc comme l'indique PiwiLAbruti, il y a peu de chances que tu en ai le besoin et que tu puisse en profiter.

les cartes réseaux du Rasp n'ont pas de PXE, donc pour faire du PXE il faut d'abord booter le rasp sur un pre-os (un syslinux par exemple) qui se chargera de récupérer l'OS ailleurs (par exemple en tftp sur un syno). mais c'est inefficace (pas assez de ram sur un rasp pour faire ça efficacement) et lent (la carte réseau ne dépote pas assez) concernant ton problème de carte, je ne sais pas comment tu t'y prends pour les flinguer :s j'ai un rasp allumé H24 depuis plus d'un an, il me sert entre autre de miroir Debian (donc lecture/écriture importante) et aucun soucis. Pour l’anecdote il est alimenté par le port usb d'un syno j'en ai un autre qui me sert à faire joujou, donc il est installé/formatté/réinstallé assez souvent, là aussi aucun problème tu as peut être un pb d'alimentation, ou alors tu retire la carte sans éteindre le rasp si tu veux limiter les écriture sur la carte, il y a plusieurs méthode non exclusives -monter les dossiers dans lesquels il y a des écriture ailleurs que sur la carte : --par exemple dans un tmpfs en ram --en faire des liens vers /dev/null (attention, toutes les applis ne le supportent pas) --sur un media externe (clef usb, nas, ...) -désactiver/supprimer les composants qui écrivent comme les logs (syslog/rsyslog/...), les mta (postfix/...), ... -désactiver la swap ou la déplacer loin de la carte (c'est con et inutile mais on peut monter la swap en ramfs) -... Tu peux aussi limiter les lectures : -noyau statique et allégé -busybox -pas de cron -pas de services non indispensable -... En bref, tout ce qui est fait dans les linux embarqué (par exemple les box internet ou les routeurs grand public on juste un peu de rom pour stocker l'os et la conf, le reste est volatile)

Le premier article date de 2009, il aurait été intéressant s'il n'avait pas fait abstraction d'un point crucial : tous les disques font des erreurs et le savent, il y a donc une partie du disque en réserve pour ré-allouer les secteurs défectueux automatiquement (pour info, c'est aussi valable sur un SSD). Le taux de panne est donc considérablement réduit (de même que les performances). Je suis aussi tombé sur l'article de clubic, même s'il n'est pas faux en soit, il est rempli de "si ceci, et si cela, dans le cas où, ...". Avec tant de suppositions, rien n'est fiable. Au jugé on doit avoir quelques milliers de DD en salle machine (certains ont plus de 10ans) et on doit en jeter/remplacer une grosse dizaine par an (parfois dès le premier démarrage). Ce n'est pas négligeable. Donc un disque unitaire n'est pas une chose super fiable. Par contre j'utilise différents raid au quotidien en usage professionnel (sur de l'emc, du netapp et du quantum), avec une volumétrie à plat (comprendre en surface brute) de plusieurs centaines de To. Je n'ai "presque" jamais vu un raid tomber en panne en 7ans. Des disques individuels oui, mais du moment qu'ils sont vite remplacés (hotspare + supervision), aucune casse. Donc un raid supervisé c'est fiable. Dans le monde professionnel, pour limiter les risques de pannes, on utilise plusieurs méthodes (disques haut de gamme, panachage de disques, hotspare, supervision proactive, contrôleurs redondés, ...). Tout ça à un cout, ce n'est donc pas pour M. ToutleMonde. Pour le grand public, il y a moins de possibilités et le matériel est souvent moins fiable (question de budget). Mais certaines bonne pratiques permettent d'éviter la plupart des problèmes : -il faut par exemple éviter d'utiliser des "contrôleurs" raid qui nécessitent d'installer un truc (s'il y a un truc à installer, c'est que le raid est géré par le soft, donc si le disque en panne contient le soft, il n'y a plus de soft pour recalculer la parité ...), comme ceux qu'on trouve dans beaucoup de carte mère de PC -à l'opposé, les raid 100% softs (même celui de windows) sont assez fiable car ils ne dépendent plus d'un contrôleur et peuvent donc être remontés sur un autre hardware, de plus ils gèrent bien mieux les secteurs défectueux que la plupart des contrôleurs matériel (y compris de gamme pro) -un disque dur doit être régulièrement testé (au moins smart, si possible test de surface). Un contrôleur raid de bonne qualité le fait de lui même, indépendamment de l'OS installé (même sans OS en pratique) -il ne faut JAMAIS mettre des données critiques sur un même raid que le système -mieux vaut plusieurs disques mono plateau de faible capacité qu'un gros disque multi-plateaux avec plein de To -l'achat d'un onduleur est souvent plus rentable que l'achat d'un gros disque A titre perso, le PC devant moi a 3 disques (1ssd système et 2 disques en raid 1 pour les données), de temps en temps (1 à 2 fois par an), j'enlève un des disques du raid et je le tests (après l'avoir remplacé par un 3ème de même taille). Si le disque passe par le test, il fera la rotation suivante, sinon j'en rachète un. Bien sur en faisant cette manip, je cours un risque (panne du disque restant le temps de la manip). C'est pour ça que mes données sont sauvegardées sur un syno et que ce dernier est sauvegardé sur un autre syno (pas au même endroit). Pour les données critiques, j'en ai une copie...ailleurs. Pour en revenir au raid, le raid1 offre à peu prêt le même niveau de protection que les raid5 et 6, l'avantage de ces derniers n'est donc pas leur fiabilité, mais le fait que l'on perde moins d'espace (n-1 ou n-2 contre 50% avec un raid1) et que les performance sont bien plus élevées. Entre le raid1 et les raid5 et 6 on trouve le raid 1+0 qui offre un bon compromis perf/redondance mais qui coute cher (4 disques mini, 50% de perte en surface). Ce qu'il faut retenir des 2 articles et du raid en général : -un disque dur c'est fragile : quand c'est allumé, on ne doit pas y toucher (utilisateurs de portables sur les genoux méfiez vous) -un disque dur c'est fiable : quand c'est utilisé avec soins, ça peut durer des années sans problèmes. Amusez vous à comparer le nombre d'heure avant une panne de disque dur avec le nombre d'heure avant de devoir changer de voiture, c'est édifiant (un indice, une voiture c'est beaucoup moins fiable) -le raid n'est pas une solution de sauvegarde -une sauvegarde au même emplacement physique que l'original n'est pas une sauvegarde -une sauvegarde non testée régulièrement n'est pas une sauvegarde -avant de créer une grappe raid, il faut s'assurer des capacités/limitations des disques mais aussi et surtout du contrôleur

le ldap et le kerberos sont OK d'après le log c'est winbind (ou au moins le call RPC) qui ne marche pas. Il y a plusieurs façon de créer un objet dans un ad, il est possible que la méthode employée par syno ne soit pas autorisée chez toi. Quelques pistes : -essaye de créer l'objet (le syno) par avance -vérifie au niveau par feu (surtout les ports 135 à 139 et 445) -essaye avec un autre nom de machine (le nom est peut être déjà pris) -essaye avec un autre compte (par défaut, un compte non admin ne peut créer que 10 machines) J'ai déjà enregistré plusieurs syno dans des ad (pas testé au travers d'un rodc par contre), normalement ça marche très bien.

c'est pas un appart ça, c'est une fnac Si je comprends bien on a : Internet | modem/routeur--TV1 et TV2 | routeur2--le syno et le switch1 (avec plein de trucs) | switch2--plein de trucs Si c'est bien ça, passe 2 liens entre les 2 switchs (de manière générale, dès qu'il est compliqué de passer un cable, ou qu'il y a d la longueur, il faut en passer au moins 2, tant qu'on peut encore), même si tu ne t'en sers pas tout de suite Pour le reste, je brancherais les syno sur le switch1, pas sur le routeur (sauf gap de gamme, un switch est nettement plus rapide qu'un routeur en commutation). Je te propose ceci (en mettant le routeur2 et le switch1 au même endroit) : Internet | modem/routeur--TV1 et TV2 | routeur2 | switch1--plein de trucs (dont le syno) || switch2--plein de trucs

Tes débits sont "normaux" pour ce modèle en cifs (partage windows), mais même mon vieux 107+ allait plus vite Avec mon 710+ j'arrive juste à saturer un lien 1gbits et même avec le 712+ je ne sature pas mon ssd. tu peux aller un peu plus vite avec du nfs ou du ftp (+10% au doigt mouillé), mais tu ne satureras pas ton ssd de même sans raid, tu pourras peut être gagner quelques mo/s, mais au prix d'une absence totale de sécurité Pour ce qui est du jumbo frame, il faut que tous les élements de la chaine le supportent (pc+switch+nas), sinon au mieux tu aurras de la fragmentation (donc débits catastrophiques), au pire rien du tout (ce qui t'es arrivé). Sous linux : ifconfig eth0 mtu 9000 Sous Windows c'est faisable avec netsh, sinon dans les propriétés de la carte réseau Pour les switchs, ça dépend des contructeurs (un switch grande surface ne sera suremment pas compatible)

Comme évoqué plus haut, tu peux relier tes switchs entre eux avec des agregats de liens ou répartir des liens sur différents switchs d'un même groupe, mais pour un usage domestique, ça commence à faire lourd. De plus, ton syno ne sera pas capable d'alimenter 4x1Gbits, de mémoire, le controleur peut sortir 2 ou 300MBs max en accès simple, avec des accès conccurentiels (accès à plusieurs en même temps, à des fichiers différents), il sera vite au max de ses capacités. Pour les câbles, ça dépend de l'environnement et des distances. En usage domestique, j'ai tendance à ne jamais prendre moins que du FTP et quand je dois tirer des câbles qui sont là pour rester, je prends du sstp si j'ai le budjet (sinon ftp). Mais dans tous les cas en 6a (le 7 n'est pas fait pour le rj45 et les prises murale GG45<->RJ45 sont trop cher, trop grosses et trop pénibles à brancher).

pour faire de l'agregation de liens, comme dit plus haut, il faut un switch compatible avec le 802.3ad donc si tu n'as que des ports 1gbits, que tu branches le syno sur 2ports, ton syno pourra causer à 2gbits avec le switch mais si tous tes clients arrivent depuis un même port (uplink) 1gbits, tu n'en profiteras pas par contre si tout le monde est sur le même switch, alors tu pourras utiliser les 2gbits du syno, ..., répartis entre les clients (avec un max de 1gbits par client, sauf s'ils ont aussi plusieurs liens le débit est toujours celui du plus petit des tuyaux entre le serveur et le client

Quand tu parle de pb de synchro, tu parle de l'heure ? Si oui, c'est normale car la double authentification ne fonctionne pas si le client ou le serveur n'ont pas la même heure Dans ce cas il suffit de remettre les 2 machines à l'heure (tu peux le faire en ssh), ça devrait de nouveau fonctionner date --set="20 Feb 2014 00:55:31" pour désactiver le double authentification, supprime le fichier /usr/syno/etc/preference/admin/google_authenticator

http://www.hacker10.com/computer-security/use-a-vpn-on-a-computer-without-admin-rights/ Sinon demande à ton service info s'ils peuvent t'installer le soft, ça ne devrait pas poser de problèmes sauf si tu as accès à des données sensibles (dans ce cas tu ne devrais même pas envisager la possibilité d'éventuellement songer à évaluer ce que tu veux faire ) Il y a plein de manière de contourner la sécurité d'un réseau, du moment qu'au moins 1 port est ouvert, on peut tout faire, c'est juste plus ou moins compliqué :

tu n'as, à priori, pas de routage à faire sur ton Windows7, le fait d'ajouter une interface avec une IP va automatiquement ajouter une route directe. Le seul problème que tu risque d'avoir c'est l'installation d'OpenVPN.

utilise simplement openvpn, pas besoin de bricoler la conf du syno, il te suffit de rediriger un des ports ouvert avec ta box tu configure le "client" vpn pour utiliser un des ports ouverts dans le proxy et tu forward ce port vers le port openvpn du synology le tunnel ssh c'est très bien mais très dangereux si mal configuré