Fenrir

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

tu devais avoir un autre problème qui a rempli ta partition système, la mise à jour a été le déclencheur, mais probablement pas la cause comme pour faire la mise à jour le syno reboot, tous les services ont été relancé et ceux qui avaient besoin d'écrire dans cette partition système n'ont pas pu démarrer en tout cas, content que tout soit rentré dans l'ordre sur ton syno

white.spirit a bien résumé : dans un premier temps, fais ce qui te semble le plus raisonnable et maitrisable, tu verras plus tard, à l'usage, si tu dois faire évoluer ton installation. pour le raid, je reste campé sur ma position car je pars du principe qu'une copie au même endroit physique (entre les 2 disques de ton futur syno) n'est pas une sauvegarde : une sauvegarde doit, au minimum, être sur un périphérique différent et si possible situé ailleurs (voisin, amis, famille, ...) mais c'est surement mon mode parano couplé à de la déformation professionnelle qui parle à ma connaissance, rien de prévu, mais c'est toujours faisable avec plus ou moins de bidouille tu devrais demander une subvention à Synology perso je suis resté plus modeste pour le rythme des renouvellements (4 syno perso + 3 nas home made + un lacie en 14-15 ans) 2001 ou 2002 : premier nas "home made" (une suse de mémoire) 2004 ou 2005 : doublé par un autre nas fait maison (une debian avec 3 raid 6 et 2 raid0, je vous laisse compter les disques) 2006 : achat de mon premier nas tout fait (mon 1er et dernier Lacie) et mise au rancard de mon 1er nas home-made 2006 : achat d'un ds101j (300Go) pour remplacer le Lacie déjà mort, le nas debian est définitivement arrêté (à cause du bruit et de la conso électrique) 2007 : achat d'un ds107+ (1To) pour remplacer le home-made, le ds101j ne sert plus qu'aux sauvegardes 2008 ou 2009 : nouveau nas home made, mais sur une base FreeNAS (je regrette encore le ZFS, peut être qu'un jour syno le proposera ...) 2010: achat d'un ds710+ (2*2To) pour remplacer le ds101j (qui depuis prend la poussière dans un placard), le ds107+ ne sert plus qu'aux sauvegardes, le FreeNAS est arrêté 2012 : achat d'un ds712+ (2*3To) pour remplacer le ds107+ (donné à ma frangine), le ds710+ reste le nas principal 201x : achat probable d'un nouveau syno, mais je n'ai pas encore décidé lequel (mais ça sera un 2 baies ou un 5 baies) ni quand (mais pas avant la fin du support du 710+)

je rajouterai juste une ligne à ton script juste histoire de pouvoir relancer le find sans qu'il repasse sur les fichiers déjà converti mv $1 $1.done et je remplacerai -name par -iname pour ne pas être sensible à la casse

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

si si, en raid, de plus ça limite (sans l’interdire) le besoin d'avoir un second nas rapidement Avec 2 disques, si tu en réserve 1 pour la copie (qui ne sera pas de la sauvegarde car sur le même nas), tu vas perdre la moitié de l'espace comme en raid 1, sauf que : si c'est le disque source qui tombe en panne, tu vas devoir refaire tous tes réglages (droits, répartitions des données, ...) voir l'accès au nas (le premier volume est utilisé par syno pour se stocker lui même : son os, les paramètres, les utilisateurs, les paquets, ...) si c'est le second disque qui flanche, tu devras recréer le volume, refaire les réglages, tout transférer Alors qu'en raid, quelque soit le disque qui tombera en panne, ça n'aura aucun impact et dès que tu auras remplacé le disque défectueux, le syno refera la copie tout seul comme un grand Maintenant si tu souhaite avoir plusieurs versions des mêmes données, tu peux utiliser TimeBackup ou CloudStation (cf fin de mon post) Pour ton usage, il n'y a pas d’intérêt à segmenter le nas en différents volumes (sauf pour Time Backup), créé simplement différents partages (avec des droits différents si besoin), ça t'évitera dans 6lois de te dire : "zut, j'ai un volume de 500Go presque vide et un volume de 10Go au taquet, il faut tout migrer/retailler/refaire/..." Maintenant c'est peut être une question de terminologie : disque : unité de base groupe de disques : agrégat de disque => plusieurs disques sont vues comme un seul grappe de raid : agrégat de disques et/ou de groupes de disques => plusieurs (groupe de) disques sont vues comme un seul un volume : segment d'un disque/groupe de disque/grappe de raid : c'est l'équivalent d'une partition un partage : dossier avec ses propres règles d'accès (sécurité, protocole réseau, ...) qui est stocké sur un volume l'usage le plus courant est : 1 disque => 1 volume 2 disques => 1 raid 1 (ou shr) contenant 1 volume 3 disques ou plus : là on commence à jouer (raid 5, raid1+disque simple, ...) cf réponse de white.spirit C'est le cas chez moi depuis une grosse dizaine d'années, un nas "principal" et un nas qui sert de backup au premier, quand le nas principal sera trop vieux, le secondaire deviendra principal et j’achèterai probablement un nouveau nas qui sera secondaire, ... Mais comme indiqué par white.spirit, pas de précipitation, prends le temps de bien évaluer tes besoins Je ne peux que dire oui 1 volume et plusieurs partages avec des droits différents c'est une bonne pratique assez courante mais qui se heurte souvent à 2 limitations : sécurité de l'accès aux données : cette limitation est facile à lever on montant un vpn entre les 2 nas (le syno peut faire serveur et client vpn, donc rien de difficile) temps de transfert : à moins d'avoir une superbe bande passante (sur les 2 connexions internet) ou un petit volume de données à sauvegarder, le temps de transfert risque d'être très important (entre 2 lignes ADSL, ça peut se compter en mois s'il faut transférer des To de données) Demande une autorisation écrite, car si tu sauvegarde des données importantes et que tu te fais cambrioler ... Personnellement, je recommanderai à ton patron d'acheter un vrai service de sauvegarde (par exemple hubic) Ce n'est pas à toi d'assurer la sauvegarde des données de ton entreprise, surtout sur tes fonds propres, mais ce n'est que mon avis ---------------- Petite précision sur les sauvegardes Un usage courant des "sauvegardes" est le rattrapage de fausses manip : "oups, j'ai supprimé un truc super important" Dans le cas d'une sauvegarde classique, on se connecte au machin qui s'en occupe (dans ton cas ça pourrait être le syno de maman) et on repêche le truc AVANT la sauvegarde suivante Avec une sauvegarde un peu plus réfléchi, on ajoute du "versionning" (on sauvegarde le N dernières versions du truc en question) et on repêche le truc avant la fin de la rotation Mais avant d'aller à la pêche dans les sauvegardes, on peut faire du simple versionning, Synology propose 2 paquets qui savent le faire : Time Backup (c'est l'équivalent de Time Machine sur Mac) : le syno copie régulièrement tout ce qui change dans certains partages sur un autre volume/nas/disque externe CloudStation (dropbox like) : ça ne sert pas à ça à l'origine, mais ça peut très bien remplir cette fonction, sans devoir créer un autre volume et avec une granularité très fine (dossier) Ça consomme un peu de place et de ressource cpu, mais ça peut rendre service

Tu peux modifier directement les infos des films dans VideoStation A un moment j'avai testé l'export des metadatas, ça m'a aussi créé une volée de fichiers vsmeta, je les ai tous supprimé

1-si tu veux de la fiabilité sans faire de raid, il faut faire plusieurs copies ... donc avoir d'autres systèmes de stockage ... que tu pourrais attacher au syno de backup pour augmenter sa taille Dit autrement : Admettons que sur le 1815 tes données soient réparties comme suit : /volume2/homes : les documents perso /volume2/boulot : les documents du travail /volume2/softs : les logiciels /volume1/photos : les photos /volume1/video : les videos /volume1/music : la musique Tout n'a pas le même niveau d'importance (selon moi), donc tout n'a pas nécessairement besoin d'être sauvegardé à la même fréquence ni sur des supports de même fiabilité Sur le 409, tu peux fais ceci : 2 volumes : 3*1.5 en shr (soit 3To) + 1*1.5To tu branches un de tes disques externes dessus en permanence (on va dire qu'il fait 1To) =>tu as maintenant 5.5To de dispo pour tes backups, dans 3 zones distinctes, il ne te reste plus qu'à les sauvegarder dans les destinations qui vont bien 3To en raid sur le syno : pour les données importantes 1.5 sans raid sur le syno : pour les données moins critiques (par exemple ce qui vient d'iTunes) 1To en externe que tu peux utiliser de 2 manières : nouvelle destination de sauvegarde pour le 1815 : pour des données moins critiques destination de sauvegarde pour le 409 (il sauvegarde une partie de la sauvegarde du 1815) : pour les données super critiques Il y a plein d'autres possibilités, par exemple faire 3 volumes sur le 409 (2*1.5 en raid 1 + 1.5 + 1.5), brancher un disque externe directement sur le 1815, ... 2-obligé mais possible, alors qu'en disque plat, il faut recopier toutes les données avant Encore une fois, l'avantage du raid (au moins en shr), c'est que tu pourras remplacer progressivement les disques du 409 par des plus gros sans devoir déplacer les backups 3-je n'ai pas de réponse plus précise, il faudrait regarder les specs en détails (taille/vitesse du cache, nombre de plateaux, marge d'erreur, vitesse de bus, températures, ...) tout ce que je peux dire c'est qu'à l'usage, un disque qui ne stock que des flux vidéos travail moins qu'un disque qui stocks des datas diverses et variées 4-un script c'est juste un enchaînement de commandes entre lesquelles ont peut ajouter de la logique exemple copié/collé depuis ubuntu-fr : #!/bin/bash REPERTOIRE_SOURCE="/home/" REPERTOIRE_DESTINATION="/sauvegarde/SauvHomeLieu/" # Détecter la présence du volume de destination et interrompre l'opération si nécessaire if [ ! -e "$REPERTOIRE_DESTINATION" ] then echo "Attention, le disque de sauvegarde n'est pas présent" exit fi rsync -av --del --stats --filter "- .thumbnails/" --filter "- .Trash/" --filter "- *.tmp" --filter "- *.iso" --filter "- lost+found/" --filter "- .cache/" --filter "- .beagle/" $REPERTOIRE_SOURCE "$REPERTOIRE_DESTINATION" echo "La commande de sauvegarde a terminé son travail..." echo "Vérifiez dans le terminal s'il n'y a pas eu d'erreur !" Pas très utile dans ton cas, mais c'est pour illustrer Pour faire un checksum : cksum <nom du fichier> exemple pour un dossier complet : find /volume1/homes/fenrir/Docs/ -type f -exec cksum {} ; > /volume1/homes/fenrir/cksum.Docs.log

Bonjour et bonne année, 1 - c'est juste une question de fiabilité, si tu es en raid sur ton backup, il devient plus fiable, à toi de voir entre espace disque et fiabilité des backups un raid pour du backup ça marche très bien (au moins aussi bien que sans raid) un autre avantage du raid (selon le mode), c'est de pouvoir agrandir dynamiquement (sans devoir tout recopier) la destination en remplaçant les disques maintenant tu n'es peut être pas obligé de TOUT sauvegarder : sur mes nas j'ai plusieurs dossiers/partages, seuls ceux qui sont importants sont sauvegardés 2-c'est vrai, mais ni plus ni moins qu'en raid 1 3-je n'ai pas de détails, mais sur le site de WD ils indiquent que les purple ne sont pas indiqués pour un NAS, peut-être qu'ils ont des optimisations au niveau des contrôleurs d'IO adaptés aux flux vidéos mais qu'ils sont moins bon pour travailler avec de la data 4-rsync est la référence pour ce genre de chose, tu peux aussi utiliser la sauvegarde synology (c'est aussi rsync) qui offre quelques conforts d'usage (détection du nas, configuration simple, ...) Pour le type de sauvegarde, il en existe 3 types (pour faire simple) : complète : suppression de ce qui a été supprimé dans la source + copie de tout ce qui a été créé/modifié dans la source différentielle : même principe que c mais vers une nouvelle destination et depuis la dernière sauvegarde complète incrémentale : même chose que d mais depuis la dernière sauvegarde c, d ou i Dans tous les cas, seul ce qui a changé et traité A noter que rsync ne fait que des sauvegardes complètes, on peut faire du différentiel et de incrémental avec, mais il faut jouer avec les options et des liens hard. Je ne sais pas de quel type de données il s'agit, mais pour un usage particulier je recommande des sauvegardes complètes sans historique (version unique) et d'en faire une autre copie de temps en temps sur un média externe Pour un usage pro, si les données bougent peu en volume, le différentiel est le bon choix, sinon l'incrémental Et dans tous les cas, il faut tester ses sauvegardes de temps en temps, une sauvegarde non testée n'est pas une sauvegarde. Maintenant si tu veux jouer, fais 2 petits scripts planifiés : sur la source : script qui fait des checksum des données à sauvegarder et qui lance la sauvegarde sur le destination : script qui vérifie les données grâce aux checksum et qui gère la rotation des sauvegardes (en faisant attention aux liens hard si tu as fait du différentiel ou de l'incrémental) Et si veux aller plus loin, regarde comment gérer la dé-duplication en mode fichier Si tu veux aller encore plus loin, regarde la dé-duplication en mode bloc (ce n'est pas faisable sur un syno, du moins temps qu'ils restent en ext4)

C'est pour ça que tout le monde ici te recommande de faire l'encodage depuis un PC Handbrake dispose d'une file de conversion, dans laquelle tu peux placer toutes tes vidéos, ensuite il n'y a plus qu'à le laisser tourner. Tu peux aussi l'utiliser en ligne de commandes : https://trac.handbrake.fr/wiki/CLIGuide J'ai converti l'ensemble de mes vidéos (même ordre de grandeur que toi) avec Handbrake en ligne de commandes. J'ai juste fait un petit script d'une dizaine de lignes : déplacement des 50 premiers fichiers du nas vers un disque local, dans un dossier 01-TODO (en excluant les fichiers déjà en .m4v ou .mkv) pour chaque fichier du dossier 01-TODO conversion avec Handbrake déplacement de l'original dans un dossier 02-DONE déplacement du nouveau fichier dans un dossier 03-NEW une fois les 100 terminés (dossier 00-TODO vide), le script recommence avec les 100 suivants Mon PC à bossé comme ça quelques jours (la facture EDF est là pour le prouver :s). De mon coté, de temps en temps et à la main : vérification manuelle de la qualité (décalage de son par exemple) des fichiers dans 03-NEW suppression des fichiers OK dans 01-DONE déplacement des fichiers OK de 03-NEW vers le nas déplacement des fichiers KO (pb de son par exemple) dans 04-KO traitement des fichiers du dossier 04-KO Depuis, dès que j'ai une nouvelle vidéo qui n'est pas en h264, je la converti avant de la copier sur le nas Joyeux Noël et bonnes fêtes de fin d'année

Un conteneur (avi, mkv, m4v, mp4, ...), c'est juste une boite dans laquelle on peut ranger plus ou moins de trucs Les différents éléments de cette boite sont encodés via un codec (compresseur/décompresseur) Ces codecs respectent différentes normes (h264, xvid, aac, mp3...). Un conteneur MKV peut par exemple contenir une piste vidéo encodée en h264 et sa piste son encodée en AAC, et plein d'autres choses (d'autres pistes son, des images, des tags, ...). Les périphériques de lecture (TV, iBidule, Android, Chromecast ...) ne savent décompresser à la volée que certains codecs (principalement le h264), ton synology le sait, il ne tente donc pas de t'envoyer les vidéos qui ne sont pas dans ces formats sans les avoir transcodées avant, ce qui bouffe du cpu et donc limite les possibilités de lecture (sans parler de la dégradation de qualité). Si tu ne veux pas être embêté, converti tes vidéos en h264 (conteneur m4v ou mkv, au choix) avec des pistes son en aac. Je viens de faire un petit test sur un DS710+, 20fps pour une vidéo en 350*280, donc par extrapolation, ça fait 50h pour convertir une vidéo en 720p de 2h Sur mon PC, je suis à 250fps en 720p, soit 30minutes pour 2h

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 ...