RE: prefix_map module add operation fails to modify schema - Samba

This is a discussion on RE: prefix_map module add operation fails to modify schema - Samba ; Hi metze, The approach we have implemented aims to emulate Windows behavior, where the Schema cache is updated after modification upon receipt of a schemaUpdateNow request. Initially we intended to implement a much simpler solution, but at SambaXP after some ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: RE: prefix_map module add operation fails to modify schema

  1. RE: prefix_map module add operation fails to modify schema


    Hi metze,

    The approach we have implemented aims to emulate Windows behavior, where the Schema cache is updated after modification upon receipt of a schemaUpdateNow request. Initially we intended to implement a much simpler solution, but at SambaXP after some discussion with abartlet decided that
    Windows behavior should be incorporated in samba.

    If we do not support the schemaUpdateNow request, a lot of DEA will not be able to be installed.
    I agree that we can go with your implementation and it's much simpler than what I've done. If there are no other comments I'll implement it right away.

    Regards,
    Anatoliy



    -----Original Message-----
    From: Stefan (metze) Metzmacher [mailto:metze@samba.org]
    Sent: Monday, June 30, 2008 18:43
    To: AnatoliyAtanasov
    Cc: samba-technical@lists.samba.org; abartlet@samba.org
    Subject: Re: prefix_map module add operation fails to modify schema

    Hi Anatoliy,

    > I have implemented a module to update the prefixMap schema attribute in the ldb.
    > This is needed when we receive add request for an object class or attribute with id that doesn't have mapping in the prefixMap.
    > There is a problem with the code; I couldn't make the ldb_modify function to actually apply the new prefixMap in the schema.
    > The returned value is 0, and after I restart the smbd and read the prefixMap in prefix_map_init function, the added id is

    missing.

    A few things:

    - The coding style doesn't match the rest of samba, please read
    samba4/prog_guide.txt

    - Your approach is a bit to complicated

    Can you try to work based on the attached patch,
    apply it with 'git am' on top of origin/v4-0-test

    metze


  2. Re: prefix_map module add operation fails to modify schema

    Anatoliy Atanasov schrieb:
    > Hi metze,
    >
    > The approach we have implemented aims to emulate Windows behavior, where the Schema cache is updated after modification upon receipt of a schemaUpdateNow request. Initially we intended to implement a much simpler solution, but at SambaXP after some discussion with abartlet decided that
    > Windows behavior should be incorporated in samba.
    >
    > If we do not support the schemaUpdateNow request, a lot of DEA will notbe able to be installed.
    > I agree that we can go with your implementation and it's much simpler than what I've done. If there are no other comments I'll implement it right away.


    The schemaUpdateNow, is the correct way and it's fine to do it based on
    my patch, the dsdb_create_prefix_mapping should just update the on disk
    prefixMap. The schema reload will then also load the new mappings.

    metze


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.7 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFIafhgm70gjA5TCD8RAgmYAJ92cptpk4FQZYT4t32v+5 FUYoRSWQCgx3Rt
    XhQJO/hdCI6/v36yxZtHNjU=
    =Rbyr
    -----END PGP SIGNATURE-----


  3. RE: prefix_map module add operation fails to modify schema

    On Tue, 2008-07-01 at 12:19 +0300, Anatoliy Atanasov wrote:
    > Hi metze,
    >
    > The approach we have implemented aims to emulate Windows behavior, where the Schema cache is updated after modification upon receipt of a schemaUpdateNow request. Initially we intended to implement a much simpler solution, but at SambaXP after some discussion with abartlet decided that
    > Windows behavior should be incorporated in samba.
    >
    > If we do not support the schemaUpdateNow request, a lot of DEA will not be able to be installed.
    > I agree that we can go with your implementation and it's much simpler than what I've done. If there are no other comments I'll implement it right away.


    What is the conflict here?

    To support existing clients, just ensure you don't error on
    schemaUpdateNow. All that needs to happen is to have updated the schema
    by the time that returns - it will happen on a timer anyway, so if it
    happen to already have occurred (because it is actually done real-time)
    what is the harm?

    schemaUpdateNow should be used to trigger all the other users of the
    schema to reload. (Possibly easier if the LDAP server remains a single
    process).

    Andrew Bartlett

    --
    Andrew Bartlett
    http://samba.org/~abartlet/
    Authentication Developer, Samba Team http://samba.org
    Samba Developer, Red Hat Inc.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBIafmWz4A8Wyi0NrsRAnrwAJ9O+rx0eIvZ0k/bCYa7pqPXMCxpMQCgjxVQ
    9lukX2Cx7U7LtEnezokZHEI=
    =/xjw
    -----END PGP SIGNATURE-----


+ Reply to Thread