YunoHost/moulinette
1
0
Fork 0
mirror of https://github.com/YunoHost/moulinette.git synced 2024-09-03 20:06:31 +02:00
Code Issues Projects Releases Packages Wiki Activity

Improve doc

Browse source
This commit is contained in:
Josué Tille 2019-01-28 10:02:13 +01:00
parent 3d9920d9a5
commit 5a7a4b65eb
No known key found for this signature in database
GPG key ID: D5E068C6DFA8681D
1 changed files with 16 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
doc/ldap.rst
View file

@ -314,6 +314,8 @@ According to :file:`ldapvi` this is the domain schema (on YunoHost 2.7):
Adding data in LDAP Adding data in LDAP
=================== ===================
If you add an object linked to user, group or permission you need run the function `permission_sync_to_user` to keep integrity of permission in LDAP.
Adding stuff in LDAP seems pretty simple, according to existing code it looks like this: Adding stuff in LDAP seems pretty simple, according to existing code it looks like this:
:: ::
@ -330,7 +332,7 @@ They weird stuff is the path you need to create. This looks like that for domain
# user # user
auth.add('uid=%s,ou=users' % username, attr_dict) auth.add('uid=%s,ou=users' % username, attr_dict)
You need to respect the expected attributes. Refer to the schemas for that. You need to respect the expected attributes. Refer to the schema for that.
:file:`auth.add` seems to return something false when it failed (None probably) :file:`auth.add` seems to return something false when it failed (None probably)
so you need to check it's return code. so you need to check it's return code.
@ -378,6 +380,8 @@ Here is how it's done for a new domain:
Updating LDAP data Updating LDAP data
================== ==================
If you add an object linked to user, group or permission you need run the function `permission_sync_to_user` to keep integrity of permission in LDAP.
Update a user from LDAP looks like a simplified version of searching. The syntax is the following one: Update a user from LDAP looks like a simplified version of searching. The syntax is the following one:
:: ::
@ -410,8 +414,8 @@ Refer to the user schema to know which attributes you can modify.
Validate uniqueness Validate uniqueness
=================== ===================
There is a method to validate the uniquess of some entry that is used during There is a method to validate the uniqueness of some entry that is used during
user creation. It's usefull by example to be sure that we have no conflict about email between each user. user creation. It's useful by example to be sure that we have no conflict about email between each user.
Here is how it's used (I don't understand why a path is not provided): Here is how it's used (I don't understand why a path is not provided):
@ -443,6 +447,8 @@ Like the last function `validate_uniqueness` but give instead of rising an error
Remove entries from LDAP Remove entries from LDAP
======================== ========================
If you add an object linked to user, group or permission you need run the function `permission_sync_to_user` to keep integrity of permission in LDAP.
Remove entries from LDAP is very simple, quite close to adding stuff except you don't need to specify the attributes dict, you just need to entrie path: Remove entries from LDAP is very simple, quite close to adding stuff except you don't need to specify the attributes dict, you just need to entrie path:
:: ::
@ -469,7 +475,7 @@ Here how it looks like for domain and user:
LDAP architecture in Yunohost LDAP architecture in Yunohost
============================= =============================
In Yunohost to be able to manage the user and the permession we use 3 parts: In Yunohost to be able to manage the user and the permission we use 3 parts:
* User object * User object
* Permission object * Permission object
@ -479,13 +485,15 @@ We can see the interaction between these object as this following:
.. image:: Yunohost_LDAP_documentation/LDAP_Liaison_logique_entre_objets.png .. image:: Yunohost_LDAP_documentation/LDAP_Liaison_logique_entre_objets.png
As you can see there are link between these 3 objets. As you can see there are link between these 3 objets:
* The first link is between the user and the group. It define which user is in which group. Note that all user has a group with his name. Note that in all yunohost instance you have a group named `all_users`. In this group you will find all Yunohost users. * The first link is between the user and the group. It define which user is in which group. Note that all user has a group with his name. Note that in all Yunohost instance you have a group named `all_users`. In this group you will find all Yunohost users.
* The second link is between the permission and the groups. This link is defined by the administrator. By default all permission are linked to the group `all_users`, so all user will be allowed to access to this permission. * The second link is between the permission and the groups. This link is defined by the administrator. By default all permission are linked to the group `all_users`, so all user will be allowed to access to this permission.
* The third link between the User and the Permission is more technical. It give the possibility to the application to get a list of all user allowed to access to. This link is dynamically generated by core. The function `permission_sync_to_user` in the module `permission` do this work. * The third link between the User and the Permission is more technical. It give the possibility to the application to get a list of all user allowed to access to. This link is dynamically generated by core. The function `permission_sync_to_user` in the module `permission` do this work.
To be able to have an attribute in both is of theses 3 link we use the `memberOf` overlay in LDAP. This foolwing line define the configuration to have these 3 link dynamically updated : The option `force` of the function `permission_sync_to_user` is used when you add the data to LDAP with `slapadd`. `slapadd` update the LDAP database without the LDAP demon process. The advantage of this is that you can bypass the integrity check (like the link between the object by the memberOf overlay). The disadvantage is that the the memberOf overlay wont update anything so if you don't fix the integrity after after to run `slapadd`, the permission in LDAP might be corrupted. Running the function permission_sync_to_user` with the option `force` will do this work to fix all integrity error.
To be able to have an attribute in both is of theses 3 link we use the `memberOf` overlay in LDAP. This following line define the configuration to have these 3 link dynamically updated :
:: ::
# Link user <-> group # Link user <-> group
@ -535,6 +543,7 @@ To have a complete integration of LDAP in your application you need to configure
Port: 389 Port: 389
Base DN: dc=yunohost,dc=org Base DN: dc=yunohost,dc=org
User DN: ou=users,dc=yunohost,dc=org User DN: ou=users,dc=yunohost,dc=org
Group DN: ou=groups,dc=yunohost,dc=org
fiter : (&(objectClass=posixAccount)(permission=cn=YOUR_APP.main,ou=permission,dc=yunohost,dc=org)) fiter : (&(objectClass=posixAccount)(permission=cn=YOUR_APP.main,ou=permission,dc=yunohost,dc=org))
LDAP Username: uid LDAP Username: uid
LDAP Email Address: mail LDAP Email Address: mail