This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

AudioJam

Membres
  • Compteur de contenus

    18
  • Inscription

  • Dernière visite

À propos de AudioJam

  • Rang
    Initié

Profile Information

  • Gender
    Male
  • Location
    Switzerland
  1. Je n'ai pas testé pour PhotoStation, mais pour le reste la réponse est "Oui". Oui, le compte "Admin" reste au niveau du DSM. Je te conseille de créer un autre compte avec des droits "admin" dans le Directory Server...
  2. A défaut d'avoir trouvé une solution à mon problème, je me réponds afin de donner quelques informations supplémentaires. Au moins, ça pourra peut-être servir à d'autres... Pour faire mes tests, j'ai utilisé un lecteur Iomega REV 70GB USB que j'ai connecté sur mon Syno RS2211+ : 1. Une fois connecté, le lecteur REV est bien détecté par le DSM et il apparaît dans les "Informations système" 2. Mais dans les "périphériques externes", aucune trace du lecteur REV : 3. En utilisant la commande "cat /proc/scsi/scsi", voici ce que j'obtiens : Le lecteur REV est bien détecté, on peut voir qu'il obtient le nom "Host : scsi17" Mais à partir de là, je sèche... - Comment savoir à quel "dev" le "Host" "scsi17" est-il lié ??? - L'est-il d'ailleurs, ou cela signifie-t-il tout simplement que le Syno ne dispose d'aucun pilote permettant de gérer ce lecteur ? - D'après le support de Iomega (http://iomrrdtools.s...eforge.net/#usb), le lecteur utilise le format UDF (soit le même format que celui utilisé pour certains CD-ROM), il est donc supporté en natif par Linux depuis le kernel 2.6.7. La commande "uname -r" me retourne bien une version de kernel plus récente, soit la 2.6.32.12 ! Voilà, je sais bien que l'utilisation d'un lecteur REV sur un Syno ne doit pas faire partie des configurations les plus courantes; mais si quelqu'un a une idée de ce que je pourrais essayer d'explorer comme piste pour y arriver, je suis preneur. Je vous remercie par avance !
  3. Bonjour à tous, J'ai un lecteur Iomega REV 35GB USB qui est connecté sur un poste du réseau et qui utilise Cobian Backup pour faire une sauvegarde quotidenne des données du Syno (~20GB). Les disques REV (25 au total) sont ensuite externalisés pour se prémunir de différents risques (vol, incendie, innondation, etc.). Afin d'éviter d'être dépendant d'un poste pour la sauvegarde, serait-il possible d'utiliser le lecteur REV en le connectant directement sur le Syno DS1511+ (DSM 3.2-1922) ? L'idéal serait que le REV soit vu comme un simple disque USB externe et que la sauvegarde puisse être automatisée... J'ai déjà essayé de brancher le REV sur le Syno, mais il ne le voit pas dans les périphériques externes !
  4. Salut Brunchto, Pour pouvoir utiliser les comptes LDAP depuis MailStation, il faut modifier le fichier de référence de dovecot qui se trouve dans /etc/pam.d/ -> dovecot. Dans la configuration de base du Syno, ce fichier contient deux lignes : auth sufficient /lib/security/pam_unix.so account sufficient /lib/security/pam_unix.so Il faut le modifier comme suit : auth sufficient /lib/security/pam_unix.so auth sufficient /lib/security/pam_ldap.so account sufficient /lib/security/pam_unix.so account sufficient /lib/security/pam_ldap.so Tu redémarres le service MailStation (c'est peut-être même pas nécessaire !) et tu peux te connecter en utilisant le nom LDAP complet (username@ldap_domain_name genre toto@ldap.local)...
  5. Les deux solutions sont possibles ! Je te conseille néanmoins d'utiliser la deuxième solution car elle présente l'avantage de conserver toute la configuration liée aux partages et à la sécurité des répertoires. C'est également la méthode qui est préconisé par Synology pour ce type de migration. Pour la pratique, tu changes les disques les uns après les autres en t'assurant que la reconstruction du RAID est bien terminée avant de passer au suivant !!! A la fin, lorsque tous les disques auront été remplacés et le RAID reconstruit, il faudra encore étendre la partition pour bénéficier de l'espace supplémentaire à disposition...
  6. AudioJam

    Mount Bind Et Chemin R

    Je viens de tester, le seul moyen de migrer un volume "basic" vers un JBOD est de supprimer le volume de chaque disque avant de créer le JBOD. Seule la migration de "Basic" vers "RAID-1" ou vers "SHR" est possible sans destruction préalable du volume. Cette contrainte est d'ailleurs confirmée sur le forum anglais de Syno : http://forum.synology.com/enu/viewtopic.php?f=125&t=13432 ! Je reste néanmoins convaincu, au regard des tes différentes réponses, que c'est le meilleur moyen d'obtenir ce que tu veux (1 seul volume correspondant à la taille totale de tes deux disques). Il ne te reste plus qu'à sauvegarder TOUT le contenu de tes DEUX disques avant de supprimer les volumes "Basic" et de passer au "JBOD"...
  7. Si le paramètre "Local Master Browser" est activé dans "Win/Mac/NFS", il est normal que le compte guest soit activé et qu'il te soit impossible de le désactiver !!! Désactive le "Local Master Browser" et tu pourras certainement désactiver le compte Guest...
  8. AudioJam

    Mount Bind Et Chemin R

    cricx a raison pour le montage de ton répertoire avec bind. Les fichiers que tu vois sont donc tous stockés sur le volume2... Par contre, pour ce qui est de voir les deux disques comme une seule partition, le plus simple est de créer un volume JBOD avec tes deux disques. Je n'ai pas testé, mais je pense que tu peux migrer facilement le volume simple du volume1 vers un JBOD composé des deux disques et qui sera alors vu comme un volume1 de la taille totale des deux disques (je ne sais pas si c'est très clair ce que je dis ???). De plus, il est fort probable que le contenu du volume2 actuel soit perdu lors de la création du JBOD. Quoi qu'il en soit, le moyen le plus sûr de faire cette migration passe obligatoirement par la sauvegarde des données des DEUX disques avant de faire quoi que se soit !!!
  9. Cherchez plus, j'ai trouvé ! Voilà la syntaxe à utiliser en KiXtart : $SrvFullName = "ldap.test.local" ; Correspond au FQDN du Directory Server, on peut aussi utiliser l'adresse IP du Syno $LDAPRootFQDN = "dc=ldap,dc=test,dc=local" Function InLDAPGroup($LDAPGroupName) $LDAPGroupPath = "LDAP://" + $SrvFullName + ":389/cn=" + $LDAPGroupName + ",cn=groups," + $LDAPRootFQDN $LDAPUsers = GetObject($LDAPGroupPath) If @ERROR = 0 For each $Item in $LDAPUsers.memberUid If ($Item == @USERID) $InLDAPGroup = 1 Return EndIf NEXT $InLDAPGroup = 0 EndIf EndFunction InLDAPGroup("ENT-DOCS-R") ; Le nom du groupe pour lequel tester l'appartenance de l'utilisateur connecté En fait, la clé du problème se trouve dans "$LDAPUsers.memberUid", car ce paramètre est propre à la RFC utilisé par Directory Server pour sa structure LDAP. Avec AD, ce paramètre s'appelle "name" au lieu de "memberUid" ???? Si vous êtes dans un cas de figure similaire, je ne peux que vous conseiller d'utiliser un client LDAP (Softerra LDAP Browser dans mon cas) afin d'obtenir toutes les infos nécessaires. C'est en effet par ce biais que j'ai pu voir le nom des attributs utilisés.... A dispo si vous avez des questions !
  10. Merci infiniment pour ta réponse Brunchto, Au temps pour moi ! Tu as parfaitement raison pour le point 3, il faut effectivement activer l'accueil utilisateur au niveau des utilisateurs dans le LDAP client du Syno. Si j'avais bien activer le client LDAP (indispensable pour pouvoir utiliser la sécurité LDAP sur les partages du Syno), je n'avais pas remarqué le bouton "Accueil utilisateur" dans l'onglet des utilisateur LDAP !!! Encore merci, c'est parfait. Pour ta deuxième remarque, c'est tout mon problème. On trouve sur le net des exemples à foison sur la manière de se connecter à une base LDAP, quelque soit le langage de script qu'on utilise. Le problème, c'est que tous ces exemples se basent sur des commandes ADSI qui, comme leur nom l'indique, se basent sur la structure d'Active Directory. La commande << GetObject("LDAP://rootDSE") >> en particulier, qui sert à déterminer la racine d'accès de LDAP, mais qui ne fonctionne que lorsqu'un domaine est présent (???) (cf. http://technet.microsoft.com/en-us/library/ee156506.aspx). Je vais quand même essayer de creuser dans ce sens car je pense que cela devrait être faisable sans trop de problèmes (?). Il faut juste trouver les bonnes commandes et la syntaxe qui va bien ! Je posterai la syntaxe dès que cela marchera, mais si vous avez d'autres idées...
  11. Bonjour, Je suis conscient que ma question s'écarte peut-être un peu du domaine couvert par ce forum, mais au regard des compétences de certains de ses membres, il y a peut-être quelqu'un qui peut apporter une réponse à mon problème ! La situation : Mon but est de pouvoir mettre en place des NAS Synology pour remplacer les serveurs Linux (Samba) ou Windows (ADS) utilisés actuellement au sein de petites structures décentralisés (moins de 10 postes clients). Imaginez une organisation basée sur quelques sièges principaux, dans lesquels une structure client/serveur à part entière existe pour gérer les centaines de clients connectés. Ces sites sont présents dans quelques pays soigneusement sélectionnés et disposent de toutes les technologies actuelles en termes d'infrastructure et de communication. Autour de ces quelques sites principaux, orbite une multitude d'entités, allant du poste seul jusqu'aux petits centres avec quelques dizaines de postes. Tous ces sites "distants" sont actuellement équipés d'un serveur (souvent très basique) avec au moins les services Samba ou ADS pour l'authentification des utilisateurs. La plupart de ces sites se trouvent dans des zones reculées et ne disposent que de très mauvaises connexions Internet (quand il y en a une !). Il s'agit le plus souvent d'une connexion modem 56K et les coupures sont "très" fréquentes (jusqu'à 50 par jour !) et parfois très longues (des jours, voir des semaines !). Par conséquent, je ne vous fait pas un dessin, mais la maintenance du parc est juste impossible. Ajoutez à cela une disponibilité locale en matériel informatique plus que limitée et une alimentation en courant électrique pour le moins "fluctuante" et vous aurez une bonne idée des défis auxquels nous devons faire face ! Depuis quelques temps déjà, nous avons commencé à remplacer certains serveurs par des NAS Synology (des modèles de 2 à 5 baies en fonctions des besoins). Cette solution présente l'avantage d'être moins gourmande en électricité et d'être beaucoup plus simple à maintenir. De plus, la possibilité d'exporter/importer les configurations rapidement ou la facilité avec laquelle on peut remplacer les disques (reconstruction automatique du RAID) sont des caractéristiques cruciales pour garantir un fonctionnement pérenne. Mais le plus gros problème auquel nous sommes confrontés est la gestion des utilisateurs. Il faut en effet que cette gestion soit aussi flexible que possible (les utilisateurs naviguent d'un site à l'autre et doivent avoir un accès personnel sur chacun d'entre eux) tout en garantissant un minimum de sécurité (les données concernées sont souvent très, très sensibles). Depuis l'apparition de Directory Server, nous avons franchi un cap important dans la résolution de ce problème. En effet, la mise en place de Directory Server sur le NAS et l'utilisation conjointe de pGina (avec le plugin LDAPAuth) sur les postes clients, nous permet de mettre en place une authentification simple et efficace pour ces sites. Par contre, cela nous pose encore quelques problèmes au niveau des scripts de connexion. Notre environnement de test est le suivant : - Synology DS1511+ avec 3 disques 1To en RAID-5 - DSM 3.2-1922 - Directory Server 1.0-1922 - KiXtart 4.62 et KixForms 2.46 - Imprimante Laser N&B HP LaserJet 2300N (connectée en réseau et non en USB) - Switch HP ProCurve 1810-8G (8 ports Gigabit) Les scripts de connexion sont réalisés avec des commandes KiXtart, et le principe même de toute la sécurité des répertoires est basé sur l'appartenance des utilisateurs à des groupes : - Utilisateurs LDAP "Tata", "Titi" et "Toto" - Chaque utilisateur est membre d'un des groupes LDAP "ENT-DOCS-R" ou "ENT-DOCS-W" (R pour lecture et W pour écriture, selon le type d'accès autorisé) - Un partage appelé "ENT-DOCS" a été crée sur le Synology et les droits d'accès ont été définis avec les groupes LDAP "ENT-DOCS-R" en lecture et "ENT-DOCS-W" en lecture/écriture Voici donc mes questions et remarques à ce sujet (enfin !!!) : 1. Le but est d'utiliser une commande KiXtart pour vérifier l'appartenance de l'utilisateur qui se connecte à un groupe afin de connecter ou non le lecteur concerné (Si "Toto" est membre du groupe "ENT-DOCS-R" ou "ENT-DOCS-W", alors connecter le lecteur "ENT-DOCS"). Directory Server n'étant pas un domaine à part entière (comme Samba ou ADS) mais un simple annuaire LDAP, les commandes COM ou ADSI utilisées habituellement depuis KiXtart ne fonctionnent pas. En utilisant Softerra LDAP Browser (http://www.ldapbrows...dap-browser.htm), j'arrive bien à me connecter à la base LDAP et à parcourir les données de Directory Server; la structure de l'information est donc connue et je sais où chercher les données dont j'ai besoin. Par contre, je ne sais pas comment faire depuis les commandes KiXtart pour vérifier l'appartenance de l'utilisateur à un groupe donné ???? Je ne suis pas forcément attaché à KiXtart (c'est juste que c'est ce qu'on a toujours utilisé jusqu'à présent), si vous pensez que je peux arriver au même résultat avec un autre langage de script je suis prêt à faire les efforts nécessaires pour m'adapter. Il faut toutefois que le script fonctionne aussi bien avec des serveurs Windows ADS que Linux Samba... les postes clients sont majoritairement sous Windows (XP ou Seven) ! 2. Existe-t-il un moyen de gérer l'imprimante réseau depuis le Synology (franchement, je ne le crois pas) de sorte que les utilisateurs voient cette imprimante partagée depuis \\"Adresse_IP_du_Syno"\"Nom_de_partage_de_l'imprimante"; comme on peut le faire avec un serveur traditionnel ? Il faudrait donc que le Syno soit capable de stocker les fichiers de pilote pour chaque version d'OS (Linux, Win32, Win64, etc.) au moment de la création du partage de l'imprimante. L'idée étant que le script connecte automatiquement les imprimantes présentes lors de chaque connexion sans que l'utilisateur ait à soucier de quoi que se soit ! 3. C'est pas une question, juste une remarque sur une limitation actuelle; mais je ne désespère pas que cela soit corrigé dans une future version de DSM. Lorsqu'on active le service d'accueil de l'utilisateur cela fonctionne bien pour les comptes locaux du Syno, par contre, le paramètre n'est pas appliqué sur les comptes du Directory Server. Il est donc impossible d'utiliser le partage "home" comme avec un compte local ! Ce n'est pas très grave puisque l'utilisation du script de connexion me permet d'avoir une alternative parfaitement adapté pour ce problème, mais je pense qu'il serait tout de même utile de voir cette fonction implémentée dans le DSM... Merci à ceux qui auront pris la peine de lire jusqu'au bout et je donne tout ma gratitude à ceux qui auront, en plus, pris la peinde répondre ! PS : Je cherche surtout une solution pour le point 1... les 2 et 3 sont moins importants pour l'instant.
  12. Si, comme tu le dis dans ton premier message, ton disque est un WD Green, il ne faut SURTOUT PAS utiliser la MAJ wdidle3 de Western. Il s'agit d'un Firmware pour les disques de la série RE-2 et il n'est pas applicable aux autres disques de la marque... Il faut quand même pas faire n'importe quoi !!!! Plus d'infos ici : http://support.wdc.com/product/download.asp?groupid=609&sid=113&lang=fr Concernant l'utilisation de Roadkil's Disk Wipe, je pourrais le comprendre si ton but était d'effacer complètement (sous-entendu garantir que les données ne puissent être récupérées) des disques durs déjà utilisés. Mais là, tu nous dis que tes deux disques sont neufs, cela n'a donc aucun intérêt. J'ai à mon actif l'installation de pas mal de Synology, allant de l'entrée de gamme jusqu'au modèles les plus évolués en rack, et jamais je n'ai procédé de la sorte ! Il te suffitt d'installer les disques tout juste déballés dans le Synology, de l'allumer, de lancer le Synology Assistant afin d'installer le DSM (en prenant soin de télécharger au préalable la dernière version depuis le site de Synology) et enfin, de te connecter sur la console afin d'initialiser tes disques avec le "Gestionnaire de stockage" qui est inclus dans le DSM ! C'est ce dernier qui se chargera d'initialiser le RAID et de détecter les éventuels secteurs défectueux. Cette étape est obligatoire mais amplement suffisante pour initialiser correctement tes disques. Le dernier point que je n'arrive pas à comprendre, c'est ton choix (visiblement volontaire ?) de deux disques différents (marque, vitesse de transfert, de rotation,...). Si ton but était dès le départ de les utiliser en RAID-1, c'est limite aberrant comme raisonnement ???? Le principe du RAID-1 est simple, l'écriture se fait simultanément sur les deux disques. Or, croire que le disque le plus rapide prendra le dessus sur l'autre (sorte de master/slave) est une hérésie ! Bon courage !
  13. Problème réglé, la réponse à ma question se trouve ici : !
  14. Eureka !!!! Après pas mal de tests et m'être finalement résigné à repartir de zéro, j'ai trouvé l'origine du problème -> Il ne faut rien spécifier dans "User Groups" pour la configuration de LDAPAuth (onglet "User Configuration"). J'avais cru à tord que le groupe LDAP par défaut nommé "Users" devait y être spécifié. Hors, d'après la documentation de LDAPAuth : userOK0-255 (optional) LDAP Group(s) in which user must exist to be successfully authenticated. If left blank (or set to all), all may use the workstation. Comme quoi, il suffit parfois de juste bien lire la documentation !!! Afin d'être tout à fait complet et d'éviter à d'autres cette "petite" mésaventure, je vous donne les configurations à utiliser au niveau de LDAPAuth pour que cela fonctionne avec le Directory Server : 1. LDAP Server : Adresse IP ou nom DNS. Le nom DNS est à mon avis préférable mais il faut créer une entrée DNS pour la résolution du nom et la tester avec une requête ping ! 2. Use SSL : non activé ! 3. Port : 0 (c'est le paramètre par défaut, LDAPAuth utilise automatiquement le port 389 en non-SSL ou le 636 si le SSL est activé) 4. Timeout (sec) : 0 Avec LDAP Method sur "Search Mode" (c'est la méthode la plus simple) : 5. Contexts : dc=test,dc=local* Avec LDAP Method sur "MultiMap Mode" : 5. PrePend : uid= 6. Contexts : cn=users,dc=test,dc=local* Avec LDAP Method sur "Map Mode" : 5. PrePend : uid= 6. Append : cn=users,dc=test,dc=local* Dans l'onglet "User Configuration" : Admin groups : Ajouter le groupe "administrators" -> Dans ce cas, tous les utilisateurs qui sont dans ce groupe au niveau du serveur LDAP seront également dans le groupe local "Administrateurs" du poste client. Par contre, ceux qui n'en sont pas membres, seront simplement ajoutés au groupe local "Utilisateurs". Il semble par conséquent impossible d'utiliser le groupe "Utilisateurs avec pouvoir" pour les comptes LDAP !!! User groups : Laisser vide !!! -> Si vous voulez limiter l'accès à certains postes, il est possible de spécifier ici un groupe LDAP. Dans ce cas, seuls les utilisateurs appartenant au groupe spécifié auront l'autorisation de se connecter sur le poste concerné. Je n'ai pas creusé la question, mais pour que l'utilisation de ce paramètre soit vraiment viable il faudrait favoriser l'utilisation d'une variable (genre %s) plutôt qu'un nom de groupe en dur. La configuration du réseau en serait nettement simplifié et cela éviterai de configurer ce paramètre sur chaque poste client... * FQDN du Directory Server : "test.local"
  15. J'ai utilisé les paramètres suivants : LDAP Method : Search Mode LDAP Server : Adresse IP du Directory Server (Synology) ou son nom DNS (mais dans ce dernier cas, il faut s'assurer que la résolution DNS fonctionne bien !) Port : 389 (sans SSL) Contexts : dc=test,dc=local et cn=users,dc=test,dc=local (le FQDN utilisé pour le Directory Server étant "test.local" !) Concernant le message d'erreur, il apparaît au démarrage, au moment du login. Le test du plugin me donne toujours l'erreur "Plugin reported failure" !