CDuv a écrit 15 commentaires

Comme expliqué, j'ai déjà fait ce genre de couplage Samba-LDAP : c'est toujours assez compliqué.

Sans demander un système "clickdrome", le schéma LDAP pour Samba n'est pas des plus évident et mes expériences (sur des versions dépassées de nos jours) ressemblaient surtout à « Triturer l'annuaire LDAP dans tous les sens pour que Samba soit content » : laissant l'impression qu'il manquait un liant entre LDAP et Samba.

Mais je vois que les premiers avis convergent vers du Samba+LDAP, traduisant l'absence d'alternative à LDAP comme délégué à l'authentification.

Si Samba4 intègre tous les morceaux de manière cohérente permettant de faire ça : je vais tester cette solution.

Merci pour le lien vers le journal : il était très très intéressant.

Ce ce que j'y ait lu, Samba4 + quelques synchro vers un autre LDAP pour éviter de tout laisser en ligne serait l'outil adapté vu que j'ai un parc contenant du Windows (sinon j'opterais pour du FreeIPA je pense)

J'avais déjà utilisé FreeNAS sans LDAP il y a longtemps pour un autre projet et ça fonctionnait bien, puis j'avais testé son "concurrent" Debian : OpenMediaVault qui fonctionnait aussi très bien, mais là encore sans LDAP.

TrueNAS Core est dans ma liste "A tester" surtout qu'il annonce un support (natif) LDAP / AD (ce que ne fait pas OpenMediaVault).

Merci de ton retour.

Par ta réponse je présume qu'il n'existe rien de mieux qu'un annuaire LDAP comme référentiel externe utilisable par Samba (là où en web on aurait OAuth/OpenID par exemple).

J'avais effectivement lu que Samba 4 intégrait un annuaire LDAP.

Donc la complexité de coupler Samba et LDAP est "cachée" par le fait qu'il soit intégré.

Mais dans cet annuaire interne est-il exploitable en dehors de Samba ?

J'ai d'autres outils (web notamment, en PHP ou via modules Apache) qui utilisent un annuaire LDAP comme référentiel d'utilisateur.
Si on peut synchroniser l'annuaire de Samba4 avec un annuaire OpenLDAP "classique" qui serait lu par les applications ça éviterait une double saisie…

Comme expliqué je n'ai que faire de la partie ActiveDirectory (mais c'est un plus à considérer).

Erreur de copier/coller, la commande pour activer le VG est : vgchange -a y

J'ai déjà pu recopier une bonne partie des fichiers, le reste est en cours. Vu que ça semble bien se présenter, je me demande si le disque à vraiment un problème. Ca pourrait aussi bien venir de mon contrôleur SATA / carte mère.

Je pense tout recopier et faire un test avancé du disque pour vérifier son état avant de le déclarer défectueux et engager une prise en charge SAV…

# vgs
VG #PV #LV #SN Attr VSize VFree

Library 1 1 0 wz--n- 2.73t 746.52g

Tentative de forcer la création des /dev/xxx correspondants :

# vgscan --mknodes
Reading all physical volumes. This may take a while…
Found volume group "Library" using metadata type lvm2

Mais /dev/mapper restait vide

Après un coup de vgchange -/dev/mappera y mon LV est monté dans l'explorateur de fichiers :)

Plus qu'à récupérer le maximum de fichiers…

Je me rends compte que lvdisplay m'indique "LV Status NOT available"
Sous entendu LVM a vent de l'existence d'un LV mais il ne le retrouve pas sur le disque ?

J'aurais cru qu'il afficherait au moins le fait que les 2.73 TiB de mon disque sont de "type" LVM.

Le chemin "/dev/Library/MainLibrary" n'existe pas, c'est pourtant bien le "LV Path".

mount: special device /dev/Library/MainLibrary does not exist

J'ai tenté de faire des (pv|vg|lv)scan : "/dev/Library/MainLibrary" reste inexistant.
Je ne trouve pas de "device-mapper" dans /dev (de mémoire il me semble qu'il y avait ça sous Debian pour les volumes LVM.

Le seul truc nommé "Library" est /etc/lvm/backup/Library :

# find . -name "Library"
./etc/lvm/backup/Library

Vu que je suis sur un Ubuntu live USB il me manque peut-être 2/3 trucs d'auto-détection auquel je n'aurais pas penser ?

Dans l'idée je risque d'utiliser un logiciel de Domotique pour certains aspect et notamment le déclenchement des commandes via smartphone ou autres. Mais, à part si je trouve un framework/outil assez simple pour rajouter une couche REST/SOAP au processus de communication entre l'ordinateur A (qui envoi la commande) et l'ordinateur B (qui fait des choses en recevant la commande) le SSH restera le plus simple (voir mon commentaire du 24/09/14 à 17:35).

En écrivant mon post je me suis rendu compte que le vrai frein à l'utilisation simplissime de SSH était le fait que les commandes tournent parfois en root. Mais si j'arrive à régler ce soucis et limiter au maximum les commandes que peut exécuter l'ordinateur A sur l'ordinateur B via SSH devrait pouvoir coller.

Qu'est-ce qu'une authentification "biclé" ?

Pour un besoin assez similaire (j'utilise cwRsync v5.3.0 sur du Windows 7 64-bits) je me suis rendu compte que les variables d'environnement %HOMEDRIVE% et %HOMEPATH% n'étaient pas définie (étaient vides) lorsque mon script était exécuté via le planificateur de tâche alors qu'elles l'étaient lorsque lancé manuellement.
En revanche %USERPROFILE% l'est dans les 2 cas et contient une bonne valeur ("C:\Users\username").

La raison pour laquelle j'ai besoin de ce chemin c'est qu'il faut définir la variable %HOME% pour cwRsync (d'après le fichier "CWRSYNC.CMD" fourni avec cwRsync).
Voici donc comment je fais en PowerShell :

# Environment variables, as described in CWRSYNC.CMD :
$cwrsyncDirPath = Join-Path -Path $env:ProgramFiles -ChildPath 'cwRsync 5.3.0 Free'
$env:cwrsynchome = $cwrsyncDirPath
$env:home = '/cygdrive/' + $env:userprofile.Replace(':\', '/').Replace('\', '/')

J'espère que ça pourra t'aider.

C'est bien ce vers quoi je pensais que j'allais m'orienter.
Mais comment ne pas monter en permanence tous les FTP distants ?
Est-il possible d'exécuter un script (qui fera les mount ftpfs) au moment d'une tentative d'accès ? Ou alors comme hook dans le serveur FTP ?

Je précise une chose : je n'ai pas la main sur le(s) serveur(s) FTP qui seront accessible par ce système.
Mon seul lien est la connexion FTP qu'il m'est possible d'ouvrir avec les accès qui m'ont été donnés par les administrateurs respectifs de chaque serveur.

Parce qu'elle doit aller sur beaucoup beaucoup de serveurs FTP différents, alors retenir un simple label est plus simple qu'un triplet host/login/password.

Autre raison : la sécurité, les mots de passes d'accès aux serveurs FTP ne sont pas sur une machine cliente (à l'OS pouvant aller de Mac à GNU/Linux en passant par Windows) et peu sécurisés vu que FileZilla ne chiffre pas ces informations dans ces fichiers XML de profil.
Ils sont en revanche tous sur un serveur unique, à l'environnement contrôlé.

Bonus : Alice n'ayant plus du tout connaissance de ces identifiants FTP elle ne sera pas tenté d'aller les revendre à un concurrent.

J'ai simplifié la chose mais il est bien sûr possible d'envisager qu'Alice ne connecte pas à ftp://ftpproxy.societe.com/abc mais a ftp://alice:pwd@ftpproxy.societe.com/abc. Ainsi le méchant Bob ne pourras pas y aller (sauf s'il a lui aussi un compte).