nsView problem

[Procunier, Greg]

Hello,

I have tried creating test directory similar to the example given from
Red Hat in this image:

http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/images/virv
iew3.png

The goal was to have a nsViewFilter reach into the global user bucket
(ou=People,dc=mgt,dc=ont,dc=srv) and populate a lower level branch with
relevant user information
(ou=People,ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv).

This does not work at all; the nsViewFilter only works if that filter is
on the same level as the objects it needs to search which is
contradictory to the image Red hat has pushed out.

I was under the impression that container structures (such as
organization units or organizations) with nsViewFilter attributes recurs
the root of the directory to create their abstractions.  If that were
the case then the Red Hat image would be correct.  As it is right now it
does not seem to be the case.

I am using Red Hat Directory server 8.2 (redhat-ds-8.2.0-2) on RHEL5.

I am hoping I am doing something terribly wrong and some one can point
it out for me.

--- SNIP (test.ldif) ---

dn: dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: domain
dc: mgt

dn: ou=People,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: People

dn: uid=doe_john,ou=People,dc=mgt,dc=ont,dc=srv
objectClass: posixAccount
objectClass: top
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: organizationalPerson
objectClass: person
gidNumber: 65534
givenName: John
sn: Doe
displayName: John Doe
uid: doe_john
homeDirectory: /home/domain_users/doe_john
gecos: Test User 1
loginShell: /bin/bash
shadowFlag: 0
shadowMin: 0
shadowMax: 99999
shadowWarning: 0
shadowInactive: 99999
shadowLastChange: 12011
shadowExpire: 99999
cn: John Doe
uidNumber: 48465

dn: uid=doe_jane,ou=People,dc=mgt,dc=ont,dc=srv
objectClass: posixAccount
objectClass: top
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: organizationalPerson
objectClass: person
gidNumber: 65534
givenName: Jane
sn: Doe
displayName: doe_jane
uid: doe_jane
homeDirectory: /home/domain_users/doe_jane
gecos: Test User 2
loginShell: /bin/bash
shadowFlag: 0
shadowMin: 0
shadowMax: 99999
shadowWarning: 0
shadowInactive: 99999
shadowLastChange: 12011
shadowExpire: 99999
cn: doe_jane
uidNumber: 31388

dn: ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: Projects

dn: ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: A

dn: ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: B

dn: ou=People,ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=48465)

dn: ou=People,ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=31388)

-- SNIP (ldapsearch output) --

[root@directory]# ldapsearch -b ou=Projects,dc=mgt,dc=ont,dc=srv -x
objectclass=*
# extended LDIF
#
# LDAPv3
# base <ou=Projects,dc=mgt,dc=ont,dc=srv> with scope subtree
# filter: objectclass=*
# requesting: ALL
#

# Projects, mgt.ont.srv
dn: ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: Projects

# A, Projects, mgt.ont.srv
dn: ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: A

# B, Projects, mgt.ont.srv
dn: ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: B

# People, A, Projects, mgt.ont.srv
dn: ou=People,ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=48465)

# People, B, Projects, mgt.ont.srv
dn: ou=People,ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=31388)

# search result
search: 2
result: 0 Success

# numResponses: 6
# numEntries: 5

-- SNIP --

[Procunier, Greg]

Surely someone has seen this problem or could at the very least point me
in the right direction ?

-----Original Message-----
From: Procunier, Greg 
Sent: Thursday, September 23, 2010 3:00 PM
To: '[e-mail]'
Subject: nsView problem
Importance: High

Hello,

I have tried creating test directory similar to the example given from
Red Hat in this image:

http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/images/virv
iew3.png

The goal was to have a nsViewFilter reach into the global user bucket
(ou=People,dc=mgt,dc=ont,dc=srv) and populate a lower level branch with
relevant user information
(ou=People,ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv).

This does not work at all; the nsViewFilter only works if that filter is
on the same level as the objects it needs to search which is
contradictory to the image Red hat has pushed out.

I was under the impression that container structures (such as
organization units or organizations) with nsViewFilter attributes recurs
the root of the directory to create their abstractions.  If that were
the case then the Red Hat image would be correct.  As it is right now it
does not seem to be the case.

I am using Red Hat Directory server 8.2 (redhat-ds-8.2.0-2) on RHEL5.

I am hoping I am doing something terribly wrong and some one can point
it out for me.

--- SNIP (test.ldif) ---

dn: dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: domain
dc: mgt

dn: ou=People,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: People

dn: uid=doe_john,ou=People,dc=mgt,dc=ont,dc=srv
objectClass: posixAccount
objectClass: top
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: organizationalPerson
objectClass: person
gidNumber: 65534
givenName: John
sn: Doe
displayName: John Doe
uid: doe_john
homeDirectory: /home/domain_users/doe_john
gecos: Test User 1
loginShell: /bin/bash
shadowFlag: 0
shadowMin: 0
shadowMax: 99999
shadowWarning: 0
shadowInactive: 99999
shadowLastChange: 12011
shadowExpire: 99999
cn: John Doe
uidNumber: 48465

dn: uid=doe_jane,ou=People,dc=mgt,dc=ont,dc=srv
objectClass: posixAccount
objectClass: top
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: organizationalPerson
objectClass: person
gidNumber: 65534
givenName: Jane
sn: Doe
displayName: doe_jane
uid: doe_jane
homeDirectory: /home/domain_users/doe_jane
gecos: Test User 2
loginShell: /bin/bash
shadowFlag: 0
shadowMin: 0
shadowMax: 99999
shadowWarning: 0
shadowInactive: 99999
shadowLastChange: 12011
shadowExpire: 99999
cn: doe_jane
uidNumber: 31388

dn: ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: Projects

dn: ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: A

dn: ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: B

dn: ou=People,ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=48465)

dn: ou=People,ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=31388)

-- SNIP (ldapsearch output) --

[root@directory]# ldapsearch -b ou=Projects,dc=mgt,dc=ont,dc=srv -x
objectclass=*
# extended LDIF
#
# LDAPv3
# base <ou=Projects,dc=mgt,dc=ont,dc=srv> with scope subtree
# filter: objectclass=*
# requesting: ALL
#

# Projects, mgt.ont.srv
dn: ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: Projects

# A, Projects, mgt.ont.srv
dn: ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: A

# B, Projects, mgt.ont.srv
dn: ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
ou: B

# People, A, Projects, mgt.ont.srv
dn: ou=People,ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=48465)

# People, B, Projects, mgt.ont.srv
dn: ou=People,ou=B,ou=Projects,dc=mgt,dc=ont,dc=srv
objectClass: top
objectClass: organizationalUnit
objectClass: nsView
ou: People
nsViewFilter: (uidNumber=31388)

# search result
search: 2
result: 0 Success

# numResponses: 6
# numEntries: 5

-- SNIP --

[Noriko Hosoi]

Hello,

I tweaked your sample ldif file:
1) turned ou=Projects to an nsView object and removed ou=people under 
ou=A and B,
2) added another entry uid=tuser.

Here's the search result:
$ ldapsearch -x ... -b "ou=A,ou=projects,dc=mgt,dc=ont,dc=srv" 
"(uidnumber=*)" dn uidnumber
# doe_john, People, mgt.ont.srv
dn: uid=doe_john,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 48465

$ ldapsearch -x ... -b "ou=B,ou=projects,dc=mgt,dc=ont,dc=srv" 
"(uidnumber=*)" dn uidnumber
# doe_jane, People, mgt.ont.srv
dn: uid=doe_jane,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 31388

$ ldapsearch -x ... -b "ou=C,ou=projects,dc=mgt,dc=ont,dc=srv" 
"(uidnumber=*)" dn uidnumber
# tuser, sub, People, mgt.ont.srv
dn: uid=tuser,ou=sub,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 31389

$ ldapsearch -x ... -b "ou=projects,dc=mgt,dc=ont,dc=srv" 
"(uidnumber=*)" dn uidnumber
# doe_john, People, mgt.ont.srv
dn: uid=doe_john,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 48465

# doe_jane, People, mgt.ont.srv
dn: uid=doe_jane,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 31388

# tuser, sub, People, mgt.ont.srv
dn: uid=tuser,ou=sub,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 31389

$ ldapsearch -x ... -b "ou=projects,dc=mgt,dc=ont,dc=srv" 
"(uidnumber=31388)" dn uidnumber
# doe_jane, People, mgt.ont.srv
dn: uid=doe_jane,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 31388

Does this fulfill your requirement?
--noriko

On 09/30/2010 03:05 PM, Procunier, Greg wrote:
> Surely someone has seen this problem or could at the very least point me
> in the right direction ?
>
> -----Original Message-----
> From: Procunier, Greg
> Sent: Thursday, September 23, 2010 3:00 PM
> To: '[e-mail]'
> Subject: nsView problem
> Importance: High
>
> Hello,
>
> I have tried creating test directory similar to the example given from
> Red Hat in this image:
>
> http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/images/virv
> iew3.png
>
> The goal was to have a nsViewFilter reach into the global user bucket
> (ou=People,dc=mgt,dc=ont,dc=srv) and populate a lower level branch with
> relevant user information
> (ou=People,ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv).
>
> This does not work at all; the nsViewFilter only works if that filter is
> on the same level as the objects it needs to search which is
> contradictory to the image Red hat has pushed out.
>
> I was under the impression that container structures (such as
> organization units or organizations) with nsViewFilter attributes recurs
> the root of the directory to create their abstractions.  If that were
> the case then the Red Hat image would be correct.  As it is right now it
> does not seem to be the case.
>
> I am using Red Hat Directory server 8.2 (redhat-ds-8.2.0-2) on RHEL5.
>
> I am hoping I am doing something terribly wrong and some one can point
> it out for me.

[Procunier, Greg]

I see, all parent containers need to have the nsView objectclass if you want to recurs that far up.

Very interesting, thank you so much.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Noriko Hosoi
Sent: Thursday, September 30, 2010 7:56 PM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] nsView problem

Hello,

I tweaked your sample ldif file:
1) turned ou=Projects to an nsView object and removed ou=people under ou=A and B,
2) added another entry uid=tuser.

Here's the search result:
$ ldapsearch -x ... -b "ou=A,ou=projects,dc=mgt,dc=ont,dc=srv" 
"(uidnumber=*)" dn uidnumber
# doe_john, People, mgt.ont.srv
dn: uid=doe_john,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 48465

$ ldapsearch -x ... -b "ou=B,ou=projects,dc=mgt,dc=ont,dc=srv" 
"(uidnumber=*)" dn uidnumber
# doe_jane, People, mgt.ont.srv
dn: uid=doe_jane,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 31388

$ ldapsearch -x ... -b "ou=C,ou=projects,dc=mgt,dc=ont,dc=srv" 
"(uidnumber=*)" dn uidnumber
# tuser, sub, People, mgt.ont.srv
dn: uid=tuser,ou=sub,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 31389

$ ldapsearch -x ... -b "ou=projects,dc=mgt,dc=ont,dc=srv" 
"(uidnumber=*)" dn uidnumber
# doe_john, People, mgt.ont.srv
dn: uid=doe_john,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 48465

# doe_jane, People, mgt.ont.srv
dn: uid=doe_jane,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 31388

# tuser, sub, People, mgt.ont.srv
dn: uid=tuser,ou=sub,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 31389

$ ldapsearch -x ... -b "ou=projects,dc=mgt,dc=ont,dc=srv" 
"(uidnumber=31388)" dn uidnumber
# doe_jane, People, mgt.ont.srv
dn: uid=doe_jane,ou=People,dc=mgt,dc=ont,dc=srv
uidnumber: 31388

Does this fulfill your requirement?
--noriko

On 09/30/2010 03:05 PM, Procunier, Greg wrote:
> Surely someone has seen this problem or could at the very least point 
> me in the right direction ?
>
> -----Original Message-----
> From: Procunier, Greg
> Sent: Thursday, September 23, 2010 3:00 PM
> To: '[e-mail]'
> Subject: nsView problem
> Importance: High
>
> Hello,
>
> I have tried creating test directory similar to the example given from 
> Red Hat in this image:
>
> http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/images/vi
> rv
> iew3.png
>
> The goal was to have a nsViewFilter reach into the global user bucket
> (ou=People,dc=mgt,dc=ont,dc=srv) and populate a lower level branch 
> with relevant user information 
> (ou=People,ou=A,ou=Projects,dc=mgt,dc=ont,dc=srv).
>
> This does not work at all; the nsViewFilter only works if that filter 
> is on the same level as the objects it needs to search which is 
> contradictory to the image Red hat has pushed out.
>
> I was under the impression that container structures (such as 
> organization units or organizations) with nsViewFilter attributes 
> recurs the root of the directory to create their abstractions.  If 
> that were the case then the Red Hat image would be correct.  As it is 
> right now it does not seem to be the case.
>
> I am using Red Hat Directory server 8.2 (redhat-ds-8.2.0-2) on RHEL5.
>
> I am hoping I am doing something terribly wrong and some one can point 
> it out for me.