Le Coin des développeurs

De Mediase3
Aller à : Navigation, rechercher

Sommaire

Documents ou ressources utiles :

Fonctionnement du SVN

Cette page explique le mode de fonctionnement de notre svn, les branches, les tags..... Un clic ici pour avoir tout le détail

Création d'un dépôt

Procédure pour créer un dépôt local permettant de tester en temps réel des changements sans risque d'erreur ou de fausse manip. On peut le faire sans risque sur un serveur en production, car tout se fait sous un compte utilisateur normal

on utilise reprepro :

apt-get install reprepro devscripts dpkg-sig subversion

Attention, il manque surement d'autres paquets, à compléter...

commandes en root

on crée éventuellement un compte reprepro, ou alors on prend son compte perso du se3, afin d'eviter de bosser en root!

adduser reprepro

on fait un dossier pour le dépôt :

mkdir -p /var/se3/repos/apt/debian/conf
chown -R reprepro /var/se3/repos/apt/debian

on ajoute dans le sources.list :

deb file:/var/se3/repos/apt/debian lenny se3XP

Et c'est bon, le dépôt local est prêt !


Ensuite on quitte root, ce n'est plus utile

sous un compte normal

Si ce n'est pas déjà fait, on se crée une clé gpg, pour pouvoir signer les paquets officiels par la suite. Voir la doc LCS on crée un fichier /var/se3/repos/apt/debian/conf/distributions :

Origin: se3
Label: SambaEdu3
Codename: lenny
Architectures: source i386 amd64
Components: se3 se3testing se3XP
Description: Apt repository for se3 oldstable
Origin: se3
Label: SambaEdu3
Codename: squeeze
Architectures: source i386 amd64
Components: se3 se3testing se3XP
Description: Apt repository for se3 stable
Origin: se3
Label: SambaEdu3
Codename: wheezy
Architectures: source i386 amd64
Components: se3 se3testing se3XP
Description: Apt repository for se3 future


on valide le dépôt :

reprepro -b /var/se3/repos/apt/debian createsymlinks 


On récupère les maintscripts :

mkdir maintscripts
svn co https://svn.tice.ac-caen.fr/svn/SambaEdu3/maintscripts maintscripts
cd maintscripts
./build_se3packs_reprepro.sh 
usage: ./build_se3packs_reprepro.sh -b branche -a archi -d distrib -v version [-n maj] [-u] [-fs] [package]
      -b :  choix de la branche (se3testing|se3XP)
      -a :  choix de l'architecture (i386|amd64)
      -d :  choix de la distrib (lenny|squeeze|wheezy)
      -v :  choix de la version (2.1|2.2)
      -n :  majnb pour se3master
      -u :  met a jour automatiquement (implique -f et -s) le depot
      -f :  force la mise a jour même si cette version est deja sur le depot
      -s :  upload des fichiers
      -l :  mise a jour automatique en local
      -e :  mail correspondant a la signature

mettre a jour les chemins qui sont dans ./build_se3.conf

Le script va mettre à jour les sources pour la branche demandée dans svn/, compiler le paquet dans debs/, et générer un script update-repo_xxxx.sh dans debs/. Ensuite il met à jour le dépôt local (-l) ou distant (-u).

Attention, pour l'instant l'option distante n'est pas encore opérationnelle pour publier des paquets officiels. En revanche elle permet de compiler des paquets et de les pousser vers un serveur de tests par exemple. Dans ce cas il faut modifier les chemins dans le fichier ./build_se3.conf

Si l'archi n'est pas passée, c'est l'archi de la machine utilisée pour faire les paquets qui est choisie. Mais on peut la forcer si on veut, au risque d'avoir des erreurs si les libs de dev ne sont pas présentes ( mais en pratique pour le moment peu de paquets ont des binaires en c ). Pas testé !!!!

Exemples :

Ensuite, il suffit de faire :

./build_se3packs_reprepro.sh  -l -v 2.2 -b se3XP -d lenny  se3-clonage

pour faire se3-clonage se3XP

./build_se3packs_reprepro.sh  -l -v 2.1 -b se3testing -d lenny -n 135

pour tout faire en se3testing

./build_se3packs_reprepro.sh  -l -v 2.2 -b se3XP -d squeeze -a i386 -e machin@se3.org -n 140
./build_se3packs_reprepro.sh  -l -v 2.2 -b se3XP -d squeeze -a amd64 -n 140 -e machin@se3.org

pour creer un dépôt complet squeeze signé

Remarque :

Si on modifie directement les sources dans ./svn/, on peut tester le paquet avant d'avoir commité les changements. Cela peut être bien utile en phase de développement. On pourrait d'ailleurs envisager d'automatiser le test dans un IDE.

Scripts de fonctions bash utiles

deux scripts situés dans /usr/share/se3/includes permettent de simplifier grandement les accès ou création à mysql table param. Il suffit de les appeler dans le script bash pour utiliser ensuite leurs fonctions tout comme on pourrait le faire en php.

Voir ici le détail du mode de fonctionnement

Ressources version 2.x

Clés de registre imposées par logonpy (se3GPO.py)

La liste est détaillée en page annexe

Avoir une icône pour la corbeille réseau (olikin) ( FAIT denis )

descriptif accessible pour info en page annexe

Gestion de la base des registres

  • le groupe optimisation et sécurité ne doit plus comporter de clés "vitales", celles-ci étant passées en dur.
  • il faut réparer l'import de .reg qui ne fonctionne pas : on devrait pouvoir générer directement un groupe de clés à partir d'un .reg (Actuellement c'est l'enfer, il faut faire valeur par valeur !)
  • il faut un mécanisme de configuration initial indépendant des GPO pour pouvoir déployer direct et définitivement un (gros) .reg de configuration pour des groupes d'utilisateurs. C'est indispensable au fonctionnement de certains logiciels !
  • il faut un parser pour pouvoir directement importer les .adm ou .admx officiels de M$ !!! ce n'est pas bien compliqué à faire, mais cela serait super utile.

Déploiement de clés logicielles par wpkg (FAIT)

Souvent, certains logiciels (SolidWorks, Autocad...) ont besoin d'un ensemble de paramétrages bien spécifiques dans HKCU\Software. Or il n'existe pas de moyens simple de le faire avec SE3 et wpkg.

Une solution pourrait être de permettre de fournir un .reg dans le paquet wpkg (user.reg). Ceux ci sont :

  • copiés dans netlogon, sous le nom appli.reg lors de l'import du XML wpkg,
  • modifiés (remplacement de Hkey_Current_User par Hkey_Users\$SID ) et concaténés si besoin dans le répertoire gpo machine/$computer/user.reg par logonpy au login sur le poste ( on met un témoin home/profiles/$user/.$appli.lck pour ne le faire qu'une fois ),
  • ajouté au registre par un job CPAU adminse3 lancé par le logon.bat si besoin.

De cette façon on rend la configuration des préférences utilisateurs des logiciels très simple à faire depuis wpkg, tout en conservant un niveau de sécurité suffisant et sans charge serveur supplémentaire.

Impact :

  • modifier le script d'import des XML wpkg pour permettre la copie des .reg dans netlogon,
  • modifier logonpy-gpo.sh pour le mécanisme d'upload vers le client (non, on le laisse dans netlogon/machine/$computer)
  • modifier logon.bat par défaut dans base pour inclure le test de la présence du .reg et le lancement du job cpau (fait par se3logon.py)
  • faire générer le job cpau par le paquet logonpy ( fait)

Il reste à modifier la page d'import des xml wpkg pour qu'elle copie un .reg éventuel dans le netlogon. Pour l'instant il faut le copier à la main. le ficiher doit être en regedit4 uniquement.

Contrairement aux GPO, cette configuration du registre est permanente, donc attention, ne pas mettre de clés Policies !

L'ajout au registre est fait si besoin par un job cpau lancé par le script de logon. Aucun changement n'est nécessaire sur les clients, en revanche il faut refaire le paquet se3-logonpy.

Pour appliquer à la main le changement, il faut lancer /usr/share/se3/sbin/update-logonpy.sh


Importer les .admx

Le schéma admx est dispo ici :

http://go.microsoft.com/fwlink/?LinkId=86094


le générateur de code php ici :

https://github.com/moyarada/XSD-to-PHP

Cela semble fonctionner... Je vais mettre les fichiers classes php générés.


Question des priorités

Actuellement pour générer les stratégies on parcourt les groupes (templates), et on ajoute les cles au fur et à mesure. Problème en cas de groupesde même type, on n'a aucune garantie d'orde d'application. De plus, le code logonpy et interface php est assez incompréhensible ( requetes sql dans des boucles, comparaisons de tableaux...)

Une solution simple serait d'affecter une priorité à chaque groupe lors de l'attribution des clés : on écrit celle-ci dans un champ de la table restrictions, et donc un simple

SELECT ....  FROM corresp,restrictions WHERE (groupe=xxx or groupe=yyyy.....) GROUP BY priorite

génerera une table ordonnée et sans doublons

Donc

  • on ajoute un champ priorite dans la table restrictions
  • on donne des priorités ( en ^2 ) par défaut aux type de templates :
    base 0 
    groupes principaux (profs eleves adminstratifs) 1
    groupes d'utilisateurs (Classes, sous-groupes....) 2-1999 ( affectation à partir de 1000 )
    parcs de machines 2000-9999 ( affectation à partir de 5000 )
    machine 10000
    utilisateur 20000
    utilisateur@@machine 30000
    utilisateur@@Parcs 40000
    groupes@@machine 50000
    groupes@@parcs 60000
    overfill
    imposées 65535
  • on met dans la page attribution des templates un truc pour pouvoir monter/descendre les templates du même type


Correspondances entre les formats :

  • SE3

table se3db.corresp :

Intitule ->


Installation auto AIK

Cela devrait marcher !

  • modif atftp pour reecriture backslash :

/etc/defaut/atftpd :

ajouter -m /tftpboot/tftpd.remap aux options

fichier /tftpboot/tftpd.remap

gr \\ /


http://technet.microsoft.com/en-us/library/dd799257%28WS.10%29.aspx

  • DL de AIK : récup wget de l'iso ( voir unattended pour urls)
  • montage de l'iso sur /var/se3/unattended/install/aik :
mount /var/se3/unattended/install/updates/common/fra/aik.iso /var/se3/unattended/install/aik -o loop
  • lancer y:\aik\cdsetup.exe depuis un poste Windows ( ou essayer avec wine ?)
  • lancer y:\scripts\aik.bat
  • copier c:\pxe dans /tftpboot
  • personnaliser l'image pxe :
  • on utilisera WSIM
    • n° de série
    • postinstall qui lance rejointse3.exe
  • pages php pour choisir XP32, Seven32, Seven64 au reboot.

Modifs bdr

HKLM\System\CCS\Services\LanmanWorkstation\Parameters
DWORD  DomainCompatibilityMode = 1
DWORD  DNSNameResolutionRequired = 0
HKLM\System\CCS\Services\Netlogon\Parameters
DWORD  RequireSignOnSeal = 0
DWORD  RequireStrongKey = 0
Qui plus est, abaisser le pare-feu windows, sinon, rien au login.

Samba 4 (SE4)

Notes concernant la faisabilité du passage de SE3 en contrôleur AD samba4.

Base de travail

une distrib Debian Wheezy fraîchement installée avec SE3 branche trunk à jour, et un annuaire complet d'un lycée de façon à avoir une vraie base d'utilisateur à migrer. Une ou deux machines XP et Seven sont mises au domaine.

howto s4

https://wiki.samba.org/index.php/Samba4/HOWTO#Step_1:_Download_Samba4

Howto migration

https://wiki.samba.org/index.php/Samba4/HOWTO#Migrating_an_Existing_Samba3_Domain_to_Samba4

Questions :

comment interagit-on avec l'annuaire intégré samba4 : requetes ldap classiques, utilisation des outils samba-tools, libs python samba4 ?


http://en.gentoo-wiki.com/wiki/Samba4_as_Active_Directory_Server#Example_for_application_specific_auth_plugin:_Apache

https://wiki.samba.org/index.php/Samba4/Winbind

Structure de l'annuaire

En fait il possible de conserver un schéma contenant les attributs Posix ( uid, unixhomedirectory...), et donc on devrait pouvoir continuer à utiliser tel quel les applis extérieures type LCS sans changement. Avec toutefois une nuance de taille : en AD, les utilisateurs, groupes et machines ne sont pas rangés dans des branches, ils peuvent être n'importe où, c'est même le principe des GPO : on déplace les objets vers un OU, et il hérite des GPO de celui-ci.

Dans l'absolu, cela veut dire qu'une requête ldapsearch -b ou=people,dc=truc "(uid=toto)" devrait être ldapsearch "(&(objectclass=user)(uid=toto))"

Mais on peut ruser : en pratique, rien n'empêche de créer les OU des gpo dans OU=people : les utilisateurs resteront donc bien toujours dans ou=people, et une recherche avec SCOPE_SUBTREE aboutira toujours.

Il faudra en revanche écrire l'attribut uid, car les outils samba4 ne le font pas par défaut ( modif à proposer upstream).

En revanche pour les groupes c'est plus problématique : on ne peut pas créer OU séparés, car c'est justement le principe de pouvoir mettre des groupes dans des OU, comme les utilisateurs. Les groupes AD peuvent contenir des groupes, il faut donc tenir compte de cela au niveau de l'interface : garde-t-on la structure actuelle des classes, ou fait-on des changements  ? Moins on change, mieux c'est...

donc $groupsRdn =peopleRdn

Pour les GPO, si un groupe doit avoir une config particulière, le plus simple est de créer une OU avec une GPO, puis de mettre dedans le groupe

exemple : on veut que les BTS aient une GPO spécifique

- on crée ou=BTS,ou=People,
    - on met dedans tous les groupes classes des BTS
    ou
    - on crée un groupe BTS et on met dedans tous les groupes classes de BTS

on veut en plus que les BTS_CIM1 et 2 aient un paramétrage de Solidworks :

- on crée ou=SW_CIM,ou=BTS,ou=People, et la GPO associée,
- on déplace Classe_CIM1 et Classe_CIM2 dedans

plus compliqué : on veut en plus une config particulière pour tous les élèves de CPI2 et CIM2 : on ne peut pas déplacer CIM2, il est déjà dans un groupe :

- on va donc créer un nouveau groupe, contenant Classe_CIM2 et Classe_CPI2, 
- on crée ou=CIMCPI2,ou=People, on met le groupe CIMCPI2 dedans,

généralisation : on crée une OU et un groupe à chaque fois que l'on a une nouvelle GPO, afin de ne pas devoir bouger les groupes et utilisateurs existants ?

Filtres ldap

Pour la consultation ldap, la meilleure solution serait de rendre les filtres ldap de se3 utilisables aussi bien en AD qu'en se3. Ceci permettrait une migration en douceur.

  • pour les utilisateurs :
(|(&(objectclass=person)(uid=toto))(&(objectclass=user)(cn=toto))
  • pour les groupes :
(|(&(objectclass=posixgroup)(cn=groupe))(&(objectclass=group)(cn=groupe)) 
  • pour les machines :

Pour l'ecriture, on utilise samba-tool


Pour les droits (ou=rights) :

on peut garder une ou distincte, fille de people, qui contiendra les groupes cn=se3_is_admin et compagnie. Pas de pb, les requètes ldap restent les mêmes. on a donc : $rightsRdn=ou=rights,ou=people

pour les machines  : idem, on peut faire ce que l'on veut, et donc en particulier créer les parcs sous ou=computers. En revanche, la structure des parcs devient hiérarchique, une machine ne pouvant appartenir qu'à une ou, il faut les ranger de façon arborescente :

ou=computers-+-ou=parcs-+-ou=physique+-salle201
             |          |            +-salle203
             |          +-ou=maths---+-salle101
             |                       +-salle110
             +-cn=machinesansparc

ou alors structure à plat, auquel cas il faut créer un groupe par parc.

migration

Etape 1 : préparation de l'annuaire

L'annuaire samba4 a une structure différente  :

utilisateurs: uid devient cn. C'est le gros changement. branche : ou=People -> cn=Users dn : uid=,ou=People,dc -> cn=,cn=Users,dc uid : prenom.nom -> cn cn : Prenom Non -> displayName

groupes : les groupes sont dans la même gbranche que les utilisateurs : pas de différences notables, ils peuvent être imbriqués ( un groupe peut être membre d'un autre groupe ). Conséquence, un groupe ne peut pas avoir le nom d'un utilisateur !

branche : ou=Groups -> cn=Users memberUid -> member

machines : un seul enregistrement cn=poste,ou=Computers,dc=... Voir si on peut avoir les @mac et @IP pour dhcp ?

imprimantes : pas testé.

rights : les groupes deviennent des ou, idem pour les parcs cn=truc_is_admin -> ou=truc

Script de migration

  • script préparatoire
    • réallouer les doublons sambaSID
    • générer les ldifs pour ou=Rights compatibles avec nouvelle structure
    • génerer les ldifs pour ou=Parcs compatibles avec la nouvelle structure : mettre les machines correspondantes dans ou=sallexxx,ou=Parcs,dc=...
    • génerer les ldifs pour ou=Restrictions : analyser la table restrictions pour rechercher les groupes et users avec des restrictions, et créer une ou correspondante.
    • générer les ldifs pour ou=Templates : analyser les dossiers dans netlogon, et créer les ou correspondant aux templates
    • générer les ldifs correspondant aux imprimantes et les ajouter aux ou correspondant aux parcs.
  • migration avec l'outil samba4
  • import des ldifs générés précédemment
    • import des GPO avec logonpy ?


on compile Samba4 à partir du git on lance le script de migration on configure bind9+dlz

On laisse le serveur de fichiers en samba3.

Tests

Voici mes premières constatations :

- la migration de l'annuaire passe bien, à condition d'avoir supprimé les doublons des SID, et les enregistrements invalides. On récupère bien les utilisateurs, les groupes, et les machines. En revanche les OU parcs, imprimantes et droits ne sont pas importés c'est logique car ce ne sont pas des objets samba. Il faudra donc prévoir un script maison pour cela.

- la structure de l'annuaire change :

   le dn utilisateur : uid=toto,ou=People,dc=truc,dc=org -> cn=toto,cn=Users,dc=truc,dc=org
   le dn groupe: cn=bidule,ou=Groups,dc=truc,dc=org -> cn=bidule,cn=Users,dc=truc,dc=org
   les membres sont tous en member=cn=toto,cn=Users,dc=truc,dc=org
   le dn machine: uid=xptest$,ou=Computers,dc=truc,dc=org -> cn=xptest,cn=Computers,dc=truc,dc=org

pour les ou :

  cn=parc1,ou=parcs,dc=truc,dc=org -> ou=parc1,ou=parcs,dc=truc,dc=org

- l'annuaire n'est plus accessible en bind anonyme, il faut s'authentifier. On n'utilise plus openldap mais le serveur intégré à samba4

- pour authentifier un utilisateur depuis l'annuaire il faut utiliser kerberos

- samba4 intègre une conf automatique de bind9, et donc un service dns dynamique pour le domaine.

- samba4 n'est pas pour le moment destiné à fournir le service de serveur de ficihers. c'est s3fs qui s'en charge, pour le moment il y a des soucis d'ACLs, mais cela devrait rentrer dans l'ordre assez vite. Il faudra probablement régénérer toutes les ACLS, car le mapping des utilisateurs change (les UID/GID fournis par winbind ne sont plus ceux que fournissait samba3/ldap)

Il y a donc plusieurs points à régler :

- authentification de l'interface se3 : Il faut utiliser le SSO kerberos, le module apache existe, c'est pas bien compliqué, c'est même une sacrée simplification par rapport au mécanisme existant !

- adaptation au nouveau schéma ldap : pas mal de code est impacté, mais mes premiers essais en faisant du remplacement brutal s/uid/cn/g fonctionnent presque ! En faisant cela proprement dans un IDE on doit pouvoir s'en sortir. On change les peoplerdn, grouprdn, etc... dans la table des parametres.

- gestion des utilisateurs : il faut utiliser samba-tool pour gérer des utilisateurs/groupes, en remplacement des scripts perl actuels. Plutôt une simplification, on n'a plus à gérer l'utilisateur unix.

- gestion des parcs : il faut modifier le code des pages pour créer les OU, qui reprennent exactement les mêmes fonctionnalités, mais en AD. En gros les parcs deviennent des OU, ainsi que les groupes ayant des templates. Migration à prévoir ! Dans un premier temps on peut utiliser l'outil microsoft de gestino des domaines AD.

- gestion des droits : soit on fait des groupes, soit on fait des OU. Les groupes permettent d'avoir des permissions sur des fichiers et des droits sur le domaine (administrateur...), les OU de déployer des stratégies. A priori, c'est plutôt des groupes donc. A noter que l'imbrication est autorisée : on peut mettre le groupe profs dans le groupe sovajon_is_admin, par exemple.

- scripts de logon : on est en ActiveDirectory, donc toutes les bidouilles actuelles ne sont plus nécessaires, on se borne à poser les scripts utiles au bon endroit (dans sysvol ?). Une solution consiste à provisionner les templates actuels dans des ou, cela peut être automatisé, on copie les scripts aux bons endroits dans Sysvol

- GPO : samba-tool gpo permet de créer des GPO, on peut donc scripter le passage depuis l'existant sans pb, puis il suffit de générer les .pol avec logonpy et de les mettre dans sysvol ! On peut donc garder tout l'existant, mais en l'utilisant en vraies gpo. Rien n'empêche d'utiliser les outils microsoft en +

- wpkg : pas d'impact à part la mise à jour des requêtes ldap sur les parcs.

- les imprimantes : voir comment on fait pour les stocker dans AD, je n'ai pas regardé.

- dhcp : grosse inconnue, vu que l'on a maintenant un dns dynamique, est-ce encore nécessaire de gérer les réservations ? Il n'y a pas de champ adresse ip et mac dans le cn=poste, mais on peut peut-être l'ajouter, si le schéma est compatible. A voir. En revanche il faut ajouter se3 comme serveur dns.

- mise au domaine : grosse simplification, plus besoin de clés particulières. un simple vbs fait l'affaire, et pour les postes déjà au domaine c'est automatique


correspondances :

ou=People et ou=machines : a conserver ou=groups : conserver les groupes samba (eleves, classes, equipes) ou=rights, parcs : chaque groupe devient une ou (principe d'AD).

Analyser les modifs à apporter aux scripts de logon sur le serveur samba3 ( imprimantes, mkhome... )

libnss

La résolution des uid ne se fait plus en ldap mais avec winbind :

Installing and configuring

The current installation process put the library libnss_winbind.so in <PATH_TO_SAMBA>/lib (ie. /usr/local/samba/lib). Use a current checkout as described in Samba4/HOWTO.

# ln -s /usr/local/samba/lib/libnss_winbind.so.2 /lib/libnss_winbind.so
# ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2

You need to instruct the system to use the nss winbind library when searching for users or groups. For this add the keywork winbind to the stanza passwd and group in /etc/nsswitch.conf.

It should look like:

passwd:          compat winbind
group:           compat winbind
shadow:          files
...

il faut également ajouter

       winbindd socket directory = /tmp/.winbindd

dans le smb.conf


Authentification de l'interface

On peut utiliser en priorité le module kerberos d'apache (voir plus haut) : avantage, on a une vraie SSO pour les postes windows. En secours, on s'authentifie en ldap



Assuming you got Samba4/DNS (bind9.81+) and Kerberos up and running, let's start by setting up the web server.

Install apache2 + mod_auth_kerb

   Ubuntu/Debian
   # apt-get install apache2 libapache2-mod-auth-kerb
   # a2enmod ssl auth_kerb

Setup a minimal ssl-secured site

We need to setup a vhost which will host our secured intranet site. NOTE: You don't need to use a secured site to get this example working, but in production environments it's highly suggested to use one for security reasons. A minimal configuration might look like this:

file: /etc/apache2/sites-available/default-ssl

<IfModule mod_ssl.c> <VirtualHost _default_:443>

   ServerAdmin webmaster@localhost
   DocumentRoot /var/www
   <Directory />
       Options FollowSymLinks
       AllowOverride None
   </Directory>
   <Directory /var/www/>
       Options Indexes FollowSymLinks MultiViews
       AllowOverride None
       Order allow,deny
       allow from all
   </Directory>
   #########################################################
   # add a private directory using kerberos authentication #
   #########################################################
   <Directory /var/www/private>
       AuthType Kerberos
        AuthName "Intranet Login"
       KrbMethodNegotiate on
       KrbMethodK5Passwd on
       KrbVerifyKDC on
       KrbSaveCredentials off
       # our keytab
        Krb5Keytab  /etc/apache2/http.keytab
        # specify your realm (upper case - like the krb5.conf)
        KrbAuthRealms YOUR.REALM
        Require valid-user
     </Directory>
     # rest of file
     ...

Add the private directory to the filesystem

   # mkdir /var/www/private

Enable the ssl site

   # a2ensite default-ssl

Next step is to create a user - a service account which will silently authenticate the currently logged in AD user (you) . To create the user account, we will use the remote server administration tools provided by Windows. If you followed the HOWTO http://wiki.samba.org/index.php/Samba4/HOWTO#Step_1:_Installing_Windows_Remote_Administration_Tools_onto_Windows, you should already have them.

Fire up the Active Directory Users and Computers snap-in and open the predefined Users-folder. If you take a closer look at it's content, you'll notice samba's DNS account in there, which is named 'dns-<hostname of dc>' - let's stick to this unwritten convention and name the new account 'http-<hostname of dc>'. Choose a proper password and tick the 'Account never expires'-option. The password is required later on, so don't forget it.

Now that the account is created successfully, switch back to Linux-commandline.

Our account needs a proper service principal name (SPN). Samba4 provides a tool named 'ldbedit' to modify AD data. To add a proper SPN to the service account type in the following command:

   # ldbedit -H /usr/local/samba/private/sam.ldb

"(samaccountname=http-<hostname of dc>)" -e <your favourite editor>

This will open up the specified account for manipulation. the '-e' option lets you specify an editor to use (nano in my case). Just add the required SPN

   servicePrincipalName: HTTP/yourdomain.tld

and save the file.

In my case, the entry looks like this:

...
sAMAccountName: http-server-vm
sAMAccountType: 805306368
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=testnet,DC=dom
userAccountControl: 590336
description: HTTP Service Account for server-vm
servicePrincipalName: HTTP/testnet.dom
whenChanged: 20120624120002.0Z
...

Now we're ready to go on.

Back at Windows, refresh the content or reopen the Active Directory Users and Computers snap-in. The properties of the service account now show an additional tab named 'Delegation'. Tick the second option 'Trust User on delegation of all services (Kerberos only)' - I don't know the exact description, because I got the german version.

Now the service account is allowed the request authentication- and service tickets for other user, which is what we want.

Next, we have to create a keytab for our account - this is the first point of a common pitfall. For keytab-creation Samba provides the 'ktpass.sh' shell script, which (by default) is located at /usr/src/samba-master/source4/scripting/bin/. However, it doesn't work from this path, as Matthieu Patou wrote on http://samba.2283325.n4.nabble.com/samba4-keytab-management-tp2478287p2478297.html. You have to copy it to samba/bin/ - for example:

   # cp /usr/src/samba-master/source4/scripting/bin/ktpass.sh /usr/local/samba/bin/

Create the keytab

   # kinit http-<hostname of dc>
   This will initialize the service account (Now you should remember the given password) 
   # ktpass.sh --out /etc/apache2/http.keytab --princ HTTP/yourdomain.tld --pass '*'
   Retype the password again - now ktpass should answer with 'Keytab file

/etc/apache2/http.keytab created with success'

   # chown www-data:www-data /etc/apache2/http.keytab
   # chmod 0400 /etc/apache2/http.keytab
   This will change the owner of the keytab to www-data (the default user, apache2 runs at) and make it readable only by this user - we want security, right?

Finally, it's time to restart the web server for changes to take effect. The last part is the client side setup - the browsers. Let's begin with firefox.

Firefox needs to know the trustworthy uri(s) to use negotiation. We simply need to set the appropriate configuration value and it will work out of the box.

Start firefox and go to the url 'about:config' - you'll get a warning, but don't panic, we will be careful - I promise

Type 'negotiate' into the search field Now modify the entry 'network.negotiate-auth.trusted-uris' and type in your domain name (e.g. testnet.dom).

You may get a warning, if you're using a self-signed certificate (like me) - just add an exception and the page will load. That's it! Open https://yourdomain.tld/private/ and you're in - fully authenticated as user@YOUR.REALM

On Internet Explorer, you have to add your site to the local intranet security zone to enable negotiation support. The certificate will be treated as insecure and IE will complain about that. Well, to be honest, I haven't found a proper way to install and trust it permanently, so I'll leave this up to you.

You may take a look at Samba's debug log (start it with -i -M single -d3) to watch the whole authentication process. For convinience, here's my output:

Kerberos: TGS-REQ Administrator@TESTNET.DOM from
ipv4:192.168.178.133:1088for HTTP/testnet.dom@TESTNET.DOM[renewable, forwardable]
Kerberos: TGS-REQ authtime: 2012-06-28T18:28:22 starttime:
2012-06-28T18:28:22 endtime: 2012-06-29T04:28:22 renew till:
2012-07-05T18:28:22

If you see something like this, it works.

Feel free to add this to the wiki.

Cheers, Enrico

Compatibilité LCS

Les scripts d'import de l'annuaire sont communs, donc la modif portera sur les 2 systèmes. Doit-on conserver les 2 en synchro ? ou changer l'annuaire LCS (gros boulot!)?

Implémentation des fonctions

Actuellement c'est un peu le bazar, du php, dup perl, du python, du shell, et surtout des manipulations ldap un peu partout et pas seulement dans de des includes. Résultat le changement d'annuaire a pas mal d'impact un peu partout... Néanmoins on devrait pouvoir s'en sortir. La question est de savoir si on essaie de nettoyer tout cela : par ordre décroissant d'ambition, cela donne :

  • on repart sur un modèle objet propre MVC, smarty, templates...
  • on réorganise le code php pour repasser tous le ldap en includes
  • on search and replace sauvagement dans l'existant.

En pratique, quasiment tout le bourrinage ldap peut se faire avec samba-tool, ou directement à partir des libs python. Donc 80% des scripts n'ont plus de raison d'être... quasiment tout le perl dans scripts peut être remplacé par un samba-tool : exemple

Ajouter un utilisateur :

samba-tool user add toto.machin
samba-tool group addmember Classe_truc toto.machin
samba-tool group listmember Classe_truc

Evolutions futures

Paquet debian ?

Mode multi maitre ?

Editeur des GPO intégré en remplacement des pages clients windows de SE3 ?

Synchronisation "cloud"

L'excellent Seafile permet d'avoir un un équivalent libre et auto-hébergé de Dropbox et Gdrive. De plus les compte se synchronisent automatiquement sur l'annuaire de SE3. En revanche dans l'établissement, un problème se pose : il n'est pas possible de proposer de façon simple aux utilisateurs un accès aux bibliothèques synchronisées via un partage Samba. Le problème est général, ni Dropbox ni Gdrive ne le permettent, seul Owncloud propose un solution, mais elle semble tenir très mal la charge.

Enoncé du besoin

- Un utilisateur doit pouvoir créer une bibliothèque Seafile correspondant à un dossier sur un partage du se3 (home, classes...) - Si la bibliothèque est partagée avec d'autres utilisateurs dans Seafile, elle doit également leur être accessible sur Se3 (ACLS), soit de façon individuelle, soit via un groupe.

Architecture

- Le serveur seafile est placé en DMZ, et est accessible en https. - Le client de synchro (win/mac/linux) est installé sur les postes perso et communique en https avec le serveur. - Le client seaf-cli est installé sur le se3 et communique en https pour synchroniser les fichiers sur se3

Workflow

solution 1 : utilisation du client sur les stations de travail

L'utilisateur crée un bibliothèque dans le client seafile et l'associe à un dossier sur se3 : dans ce cas le client détecte que c'est un partage réseau et ne fait pas de synchro automatique (mais il est possible de la forcer manuellement). Un script samba preexec analyse au logon la conf du client, et lance seaf-cli pour faire la synchro côté serveur. Pour les acls, il faut aller lire les propriétés de partages en https sur seafile (curl...) créer les groupes si besoin et fixer les acls.

solution 2 : création via l'interface se3

- L'utilisateur choisit un dossier, les membres éventuels et/ou les groupes avec qui partager, - La page php configure seafile via l'API web, fixe les acls et configure seaf-cli soit sous l'identité de le l'utilisateur, soit sous www-se3 (mais avec le token seafile de l'utilisateur) - seaf-cli tourne en tant que service www-se3

questions

La solution 2 semble plus propre, et surtout est totalement transparente pour l'utilisateur. En revanche si seaf-cli synchronise avec le token de l'utilisateur, cela veut dire qu'il faut récupérer le mot de passe pour créer le token. A part le faire taper et le passer en clair à seafile, je ne vois pas de solution... Si on fait toute la conf seafile et seaf-cli via un compte unique, pas de problème, mais dans ce cas c'est ce compte qui sera propriétaire de la bibliothèque.


Modification de seaf-daemon

Actuellement seaf-daemon ne met pas les bonnes permissions : il faut utiliser ma version patchée, disponible sur github.

Ave la modif, il possible de lancer le daemon en root et de lui passer le nom des utilisateurs, et donc d'avoir les bons propriétaires et acls sur les dossiers synchronisés.

ZFS

ZFS est un système de fichier très évolué qui permet en gros de remplacer le raid, lvm, et le système de fichiers par un ensemble coherent et optimisé.

SE3 est maintenant complètement compatible !

Matériel

Aucun intérêt pour un "petit" serveur avec 1 ou 2 disques, à part les snapshots (shadow copy windows) ! En revanche, pour un "gros" serveur, les rapports coût/performance/fiabilité sont extrêmement avantageux : il est possible à moindre coût, avec des disques SATA NAS de base et sans carte raid d'obtenir des performances et une sécurité bien meilleure qu'en RAID5 hardware !

Les exigences minimales sont pour un serveur avec 4To de données :

  • 16 Go de mémoire ECC minimum;
  • 6 disques SATA NAS de base (1To ou +), si possible en hotplug
  • un disque SSD de 256Go, ou mieux une carte PCIexpress
  • PAS de carte RAID, si besoin une simple carte SATA ou HBA en plus fait l'affaire.

Plus il y a de disques, mieux c'est ! si on a une baie externe, il vaut mieux mettre une douzaine de 500 Go plutôt que 6 x1To...

installation

Pour faire simple, on installera le système sur une partition ext3 classique, pour ne pas s'embêter mettre un ssd de 30 Go à 40€ ! mais n'importe quel disque fera l'affaire. Il est tout à fait possible de migrer un se3 existant, il suffit d'arrêter tous les services, de démonter /home et /var/se3, puis d'installer et configurer ZFS

ZfsOnLinux

Il faut ajouter les sources du paquet, puis l'installer :

apt-get install lsb-release
wget http://archive.zfsonlinux.org/debian/pool/main/z/zfsonlinux/zfsonlinux_6_all.deb
dpkg -i zfsonlinux_6_all.deb
wget http://zfsonlinux.org/4D5843EA.asc -O - | apt-key add -

puis ensuite on installe...

apt-get update
apt-get install debian-zfs

Normalement ensuite

zpool -v

doit renvoyer une info sur zfs

Création du pool

On fait du raidz2, qui est en gros l'équivalent d'un RAID6. Ce qui veut dire que 2 disques peuvent tomber en panne. C'est le meilleur compromis pour être tranquille...

Si on a un seul paquet de disques de perfs équivalentes, on fait un seul pool. Si on a des paquets de disques différents, on les regroupera dans des pools différents. On peut ensuite agrandir un pool en faisant l'équivalent d'un RAID0...

Par exemple voici ma config :

# zpool list -v
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
data0  1,36T   779G   613G         -    52%    55%  1.00x  ONLINE  -
 raidz2  1,36T   779G   613G         -    52%    55%
   wwn-0x5000c5000f3fca33      -      -      -         -      -      -
   wwn-0x5000c5000f3ffbef      -      -      -         -      -      -
   wwn-0x5000c50012dd7287      -      -      -         -      -      -
   wwn-0x5000c50012ddfb6f      -      -      -         -      -      -
   wwn-0x5000c50012dee903      -      -      -         -      -      -
data1  4,53T  1,92T  2,61T         -    23%    42%  1.00x  ONLINE  -
 raidz2  2,27T  1,58T   700G         -    38%    69%
   ata-ST500NM0003-9ZM172_Z1W406ZJ      -      -      -         -      -      -
   scsi-SATA_ST3500514NS_9WJ055D3      -      -      -         -      -      -
   scsi-SATA_ST3500514NS_9WJ057YX      -      -      -         -      -      -
   scsi-SATA_ST3500514NS_9WJ05FYQ      -      -      -         -      -      -
   scsi-SATA_ST3500514NS_9WJ05G2H      -      -      -         -      -      -
 raidz2  2,27T   346G  1,93T         -     8%    14%
   scsi-SATA_ST3500514NS_9WJ051XJ      -      -      -         -      -      -
   scsi-SATA_ST3500514NS_9WJ055WD      -      -      -         -      -      -
   scsi-SATA_ST3500514NS_9WJ05769      -      -      -         -      -      -
   scsi-SATA_ST3500514NS_9WJ0576F      -      -      -         -      -      -
   scsi-SATA_ST3500514NS_9WJ05GJG      -      -      -         -      -      -

J'ai 2 pools, qui correspondent à des type de disques différents (SAS et SATA). Dans le deuxième, j'ai mis 2 raidz2 de 5 disques en parallèle, ce qui me permet d'améliorer les perfs. L'optimal est de grouper les disques par paquets de 5-8, donc après tout dépend de la config...

pour créer la config c'est tout simple : on repère l'uid des disques qui nous intéresse :

ls -l /dev/disk/by-id/

/dev/disk/by-id/scsi-SATA_ST3500514NS_9WJ051XJ
/dev/disk/by-id/scsi-SATA_ST3500514NS_9WJ055D3
/dev/disk/by-id/scsi-SATA_ST3500514NS_9WJ055WD
/dev/disk/by-id/scsi-SATA_ST3500514NS_9WJ05769

et ensuite on crée le pool :

zpool -f create -o ashift=12 data0 raidz2 scsi-SATA_ST3500514NS_9WJ051XJ scsi-SATA_ST3500514NS_9WJ055D3 scsi-SATA_ST3500514NS_9WJ055WD scsi-SATA_ST3500514NS_9WJ05769

par exemple pour un raidz2 à 4 disques

montage des disques

ZFS ne crée pas de partitions, mais des volumes Zvol. Donc pas besoin de se compliquer la vie ! Le montage est fait automatiquement par zfs, il faud donc penser à supprimer /home et /var/se3 dans /etc/fstab

zfs create data0/se3home 
zfs create data0/var/se3 
zfs set mountpoint=/home data0/se3home
zfs set mountpoint=/var/se3 data0/varse3

Et c'est fini ! on notera qu'il n'y a pas besoin de donner une taille de partition.

En revanche il est fortement conseillé d'activer la compression des données : l'impact cpu est faible, et on gagne 30% d'espace de stockage et de meilleures perfs !

zfs set compression=lz4 data0

Optimisation

On a un disque SSD de 256 Go, on va s'en servir de cache L2ARC : cela veut dire que zfs va avec des algorithmes sophistiqués mettre en cache sur le SSD toutes les données fréquemment utilisées. L'effet est garanti : les accès aux fichiers depuis les clients deviennent ultra-rapides !

zfs -f add data0 scsi-SATA_Kingston_SHPM2250026B7253006A69

pour optimiser le fonctionnement avec samba, il faut passer les options :

zfs set xattr=sa data0
zfs set relatime=off data0
zfs set atime=off data0
zfs set acltype=posixacl data0

C'est l'équivalent des options passées au montage dans fstab

migration des données

Rien de spécial, restaurer les données avec rsync depuis le backup...

Redémarrer les services se3, rafraîchir les quotas en lançant

/usr/share/se3/scripts/quota_fixer_mysql.sh Toutlemonde Toutespartitions actu

mise en place des instantanés

Une des fonctionnalités les plus intéressantes est la possibilité de faire de façon instantanée et à coût nul des snapshots (shadow copy) qui seront directement visibles depuis les clients windows dans l'explorateur ( menu contextuel du bouton de droite ).

suivre les indications ici :

https://github.com/zfsonlinux/zfs-auto-snapshot/wiki/Samba

Outils personnels
Espaces de noms

Variantes
Actions
Navigation
Support
Téléchargements
Développement
Outils logiciels
Boîte à outils