Fenrir

je fais le test et je repost ici dans quelques minutes ... c'est installé où est le problème ? 1-j'ai activé web station et les extentions php nécessaires 2-j'ai dézippé owncloud dans le dossier web 3-via l'interface du syno, j'ai donné les droits d'écriture à http sur le partage web 4-http://monnas/owncloud 5-login+password en utilisant une base sqlite 6-ça fonctionne (en web et avec le client lourd owncloud)

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.

Par défaut CloudStation fait du versionning très agressif (10 ou 32 versions par défaut, j'ai un doute). Donc si tu mets 100Go dans le cloudstation, en quelques heures (en fonctions des actions), tu peux vite avoir 1To de pris Pour régler le problème, essaye de limiter le nombre de version à 1 (c'est le minimum) et/ou de ne pas mettre trop de données dans le CloudStation. Je l'utilise depuis sa sortie avec environ 2Go de documents (des documents de travail, pas de film ou truc du genre) et ça marche très bien en usage "raisonnnable". Il consomme tout de même 3Go en plus des 2Go de données malgré un versionning à 1, donc ça deborde On va dire que ce n'est pas (encore esperons) fait pour gérer des gros volumes.

je plussois

Normalement ce dossier ne se rempli que si tu utilise DownloadStation Commence par vérifier qu'il n'y a rien qui traine dans l'appli via l'interface Pour supprimer le contenu à la main, il faut : 1-activer le ssh (paramètres->terminal) 2-se connecter en ssh au syno (sous windows tu peux utiliser putty, pour les autres OS c'est en stanrd depuis un terminal) : login "root" et le password du compte admin 3-il faut aller dans le dossier (X à remplacer par le n° de volume, probablement 1 chez toi) : cd /volumeX/@download/ 4-lister le contenu : find . 5-Voir ce qui prends de la place : du -sh * 6-S'il n'y a rien d'important et que tu es certain d'être dans le bon dossier : rm -rf truc_a_supprimer 7-Si tu es vraiment certain de toi (la commande suivante supprime TOUT ce qu'il y a dans le dossier où tu es) : rm -rf *

le webdav du syno n'a aucun rapport avec celui d'owncloud (qui gère son propre webdav avec Sabre). Si tu as ce message c'est problablement lié à la configuration du serveur web. Je n'ai pas testé sur un syno par contre A noter que parfois on a cette erreur quand OC n'arrive pas à communiquer avec lui-même (pb de firewall en général), mais ce n'est pas nécessairement bloquant pour son fonctionnement.

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

On s'est fait botté le c*l par les gallois Non, même si ça implique d'avoir un minimum confiance en l'hébergeur. OVH, tout comme Iliad et quelques autres, présentent mêmes quelques avantages par rapport à amazon(aws/ec2)/google (apps/compute engine)/ms (azure), ... : ils sont français et leurs datacenter sont (pour les principaux) en france =>soumis aux lois françaises (même si avec la LPM ont est mal barré, c'est toujours moins pire que dans certains pays) =>moins de problèmes de latence et de peering car physiquement plus proche qu'un datacenter en Irlande ou dans le Delaware Le fait que ton disque soit chiffré est toujours un plus (par contre ça va être plus compliqué de le redemarrer à distance ) mais attention à mettre un frein au mode parano. Si tu en es là, n'oubli pas les antirootkit, grsec, selinux, ... en gros, tu vas probablement passer plus de temps à sécuriser ta passerelle que tu ne vas l'utiliser. Je ne dis pas que c'est mal, je le fais de temps en temps pour garder la main, mais il faut savoir rester raisonnable. A titre perso (et pro aussi), quand j'ai besoin de confidentialité (qui est un aspect de la sécurité), j'héberge moi même, dans un placard (ou un datacenter), dont je suis le seul (avec mes collègues pour le mode pro) à avoir les clefs. Pour le reste je me contente la plupart du temps de sécuriser les com et les accès logiques, pour l'accès physique, je fais confiance, sinon on ne s'en sort plus. Pour ça que "simple" était entre guillemets, mais ça reste moins compliqué à mettre en place coté serveur. Pour les clients lambda, j'ai 2 réponses faciles : 1-accéder à des données sensibles depuis un poste qu'on ne maitrise pas est un hérésie (keylogger, vers, ...) 2-la plupart des systèmes intergent plusieurs clients vpn en standard (à commencer par ipsec) et il existe de nombreux vpn "click & connect" (qui s'installent à chaud, voir de manière volatile) Mais je suis d'accord, un reverse proxy est plus confortable si on ne souhaite accéder qu'à des services compatibles (donc pas de cifs/nfs par exemple). Après, comme dit avant, il faut trouver un équilibre entre le confort, la sécurité et la paranoïa.

tu complique pour rien oubli le reverse proxy Etape 1 a-installe une passerelle bien sécurisée b-ajoute lui un serveur openvpn c-créé un compte pour ton client (login+pass+certificat) d-configure ton client pour passer par ce vpn pour aller vers le syno (voir vers le reste du monde pendant que tu y es, si le débit est suffisant) Etape 2 : même chose coté syno a-sécurité b-serveur openvpn c-compte pour la passerelle d-client sur la passerelle Etape 3 le reste c'est juste du routage (sur la passerelle) pour que ce qui arrive via le vpn1 soit routé dans le vpn2 ou alors tu remplace l'étape2 par la 1 en remplaçant client par syno (pas certain que ça soit possible sur le syno par contre) ps : je fais trop de fautes, il est l'heure d'aller au dodo bonne nuit

pas nécessairement, trop tard pour détailler, mais il y a plein de façon de faire oui et non le vpn est effectivement là pour sécuriser le canal de com, mais il permet aussi de faire l'identification fiable du client c'est comme l'https et le login/password du site de ta banque sans l'un ou l'autre, c'est tout de suite moins sécurisé -pas de login/password (pas d'identification) et tout le monde peut accéder à ton compte -pas de https (canal sécurisé) et toutes les grandes oreilles peuvent connaitre ton login/password le vpn c'est juste un moyen "simple" de faire le 2 d'un coup

pour la connexion local, normalement le problème ne se pose pas quand le client se connecte, s'il peut directement contacter le syno il ne passe pas par le net, mais par le lan maintenant pour la méthode de détection, je ne sais pas exactement, mais comme il se connecte à la passerelle puis au syno juste après, je suppose que synology voit que le client et le nas ont la même ip publique et donne donc l'instruction au client de se connecter directement edit : pour faire la même chose à la main, il suffit de ne pas lancer le vpn quand on est dans le lan, ou de bien régler le vpn pour ne l'utiliser que quand on veut aller sur l'ip de la passerelle.

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

je viens de faire une petite capture, c'est simple : client -> passerelle synology (dans mon cas c'est passé par un serveur en angleterre "ukr6.synology.com"), de là les données sont passées dans un tuyau openvpn monté entre cette passerelle et mon syno via le port 443 1-quand on active quickconnect, synology nous créé une entrée DNS (quickconnectID.payeleplusproche.quickconnect.to) ET monte un vpn (en utilisant le process synorelayd) entre le syno et une passerelle 2-quand le client utilise quickconnect pour joindre le syno, il passe simplement par cette passerelle Donc par rapport à mon message précédent, entre avoir sa propre passerelle et savoir que son syno est accessible directement depuis un serveur tiers, mon choix est vite fait ...

Le fait de passer par une passerelle ne remet pas en cause la sécurité, ça déporte juste le problème. Si vous regardez la manière dont synology créé ses règles iptables (iptables -L -v -n), c'est assez permissif et peu optimisé. Dans mon cas j'ai plus confiance dans la sécurité d'une passerelle que j'installe moi même que dans celle d'un syno, mais c'est aussi une partie de mon métier ..., pour quelqu'un qui ne connais pas, il vaut peut être mieux se contenter de ce que propose le syno. C'est aussi pour ça que j'avai écrit je parlai d'un vpn entre le client et la passerelle et éventuellement un vpn entre la passerelle et le syno. après si la passerelle est un gruyère, c'est presque pire que de laisser les ports de sa box ouverts aux quatres vents mais si j'ai bien compris la demande initiale, il s'agit de ne pas exposer l'IP de la box Donc je reformulle avec un peu plus de détails 1-passerelle installée et configurée pour n'accèpter QUE des connexions fiables (authentifiées par vpn et/ou clef ssh, si possible avec OTP sur pam) 2-syno configuré pour n'accèpter les connexions Internet que si elle proviennent de la passerelle et/ou du vpn 3-vpn entre le client et la passerelle 4-vpn entre la passerelle et le syno

si tu as un accès SSH, il suffit de supprimer le fichier /usr/syno/etc/preference/admin/google_authenticator sinon, reset

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

ce lien semble fonctionner depuis chez moi : http://dinydiskstation.synology.me/photo il est fort probable qu'il ne fonctionne pas depuis ton lan si ton routeur ne supporte pas le loopback (accès à l'adresse wan depuis le lan) essaye en modifiant ton fichier host (sur ton ordi, pas sur le nas) pour ajouter (remplace 1.2.3.4 par l'ip du nas) 1.2.3.4 dinydiskstation.synology.me en passant, tu laisses tout ouvert comme ça depuis Internet ? tu devrais utiliser le vpn

Merci pour l'info, je me coucherai moins bête La dernière fois que j'avai regardé (il y a environ 10 ans ) ce n'était pas possible

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é

une idée comme ça en passant, utilise ton dédié comme passerelle vers le nas client-->cloud-->dédié seule l'ip du dédiée sera "connue" tu peux faire la même chose avec un ou deux vpn ex : nas-->cloud et client-->cloud (ton client et ton nas se "rencontre" sur le cloud) avec 1 ou 2 liens vpn Pour QuickConnect, je pense que c'est un pseudo vpn (type gre, mais je n'ai pas regardé, un petit tcpdump de donnera l'info) avec un serveur qui fait passerelle (nas--->serveur synology<--client)

je ne crois pas que ça soit possible, mais si c'est pour n'indexer que les avi, pourquoi mets tu les rush dans le même dossier ?