10:05 a.m.
Quanah Gibson-Mount wrote:
--On Tuesday, February 09, 2016 10:42 PM +0100 Chris
<chris2014(a)postbox.xyz> wrote:
> Nevertheless, is there a way to use rfc2307bis with dynamic
> configuration?
Sure. Use slapcat to export your config DB, remove the problem schema, and
reload with slapadd.
Ok. I thought this wasn't possible, because some attribute types are
marked as builtin in nis.schema:
# builtin
#attributetype ( 1.3.6.1.1.1.1.1 NAME 'gidNumber'
# DESC 'An integer uniquely identifying a group in an administrative
domain'
# EQUALITY integerMatch
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
- Chris
7:37 p.m.
New subject: make posixGroup auxiliary in 2.4.40
--On Wednesday, February 10, 2016 7:05 PM +0100 Chris
<chris2014(a)postbox.xyz> wrote:
# builtin
# attributetype ( 1.3.6.1.1.1.1.1 NAME 'gidNumber'
# DESC 'An integer uniquely identifying a group in an administrative
domain'
# EQUALITY integerMatch
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
Clearly slapd functions just fine when nis.schema is not present, even
though gidNumber is hard coded in. It's hard coded in for non-NIS
functions. Unless you have objects in your tree *using* other elements of
the nis.schema, it's fine to remove. Built-in items are *always* present
in slapd. Removing a schema that doesn't actually define it (such as
nis.schema) then has no effect if you're not using it.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
A division of Synacor, Inc
10:25 a.m.
New subject: make posixGroup auxiliary in 2.4.40
Quanah Gibson-Mount wrote:
--On Wednesday, February 10, 2016 7:05 PM +0100 Chris
<chris2014(a)postbox.xyz> wrote:
># builtin
># attributetype ( 1.3.6.1.1.1.1.1 NAME 'gidNumber'
># DESC 'An integer uniquely identifying a group in an
> administrative
> domain'
># EQUALITY integerMatch
># SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
Clearly slapd functions just fine when nis.schema is not present, even
though gidNumber is hard coded in. It's hard coded in for non-NIS
functions. Unless you have objects in your tree *using* other elements of
the nis.schema, it's fine to remove. Built-in items are *always* present
in slapd. Removing a schema that doesn't actually define it (such as
nis.schema) then has no effect if you're not using it.
Thank you. I will try removing it.
- Chris
2856
days inactive
2857
days old
openldap-technical@openldap.org
2 comments
2 participants
participants (2)
-
Chris -
Quanah Gibson-Mount