Re: [389-users] using passwd with 389

[Nathan Kinder]

On 01/21/2014 12:29 PM, Chaudhari, Rohit K. wrote:
> Hello,
> 
> I want to be able to use the Unix "passwd" command to reset a LDAP
> user's password from the command line.  However, I keep getting an
> authentication token manipulation error whenever I try to reset the
> password using that command.  What do I need to do in the 389 DS or on
> Unix in order to get this command to work?

Why don't you use the "ldappasswd" command instead?

> 
> Thanks,
> 
> Rohit
> 
> 
> --
> 389 users mailing list
> 389-us...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
> 

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Replication error

[Nathan Kinder]

On 01/21/2014 05:16 AM, Diego Woitasen wrote:
> On Mon, Jan 20, 2014 at 9:17 PM, Diego Woitasen  wrote:
>> Hi,
>>  I have a replication error with 389DS. If I try a full resync,
>> replication works. But if I modify something after that, it fails. The
>> only lines that I see in the logs are:
>>
>> [20/Jan/2014:21:12:50 -0300] - _csngen_adjust_local_time: gen state
>> before 52ddb8ec0001:1390262479:0:29
>> [20/Jan/2014:21:12:50 -0300] - _csngen_adjust_local_time: gen state
>> after 52ddbb9f:1390263170:0:29
>> [20/Jan/2014:21:12:50 -0300] NSMMReplicationPlugin -
>> ruv_add_csn_inprogress: successfully inserted csn 52ddbb9f0063
>> into pending list
>> [20/Jan/2014:21:12:50 -0300] NSMMReplicationPlugin - Purged state
>> information from entry
>> uid=zzj,ou=People,ou=branch,ou=branches,dc=site,dc=ar up to CSN
>> 52d47e6b0063
>> [20/Jan/2014:21:12:50 -0300] NSMMReplicationPlugin - ruv_update_ruv:
>> successfully committed csn 52ddbb9f0063
>> [20/Jan/2014:21:12:50 -0300] NSMMReplicationPlugin - agmt="cn=main to
>> cmald" (ldap:389): State: stop_fatal_error -> stop_fatal_error
>>
>> Not very helpful for me. The last line shows an error, but it's not
>> very descriptive. What can I do to debug this? Or do you have a hint?
>>
>> Regards,
>>   Diego
>>
> 
> I've found the problem. Someone (may be me, not sure :) ) disabled the
> changelog!

Please file a ticket in our trac instance.  It would be nice to have the
error say that the changelog is disabled to give you a clue about what
is wrong.

-NGK
> 
> 
> 
> 

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 389 and snmp

[Nathan Kinder]

On 09/30/2013 04:56 PM, Michael R. Gettes wrote:

I have the ldap-agent working.  All I see is

snmpwalk -v 1 -c public localhost .1.3.6.1.4.1.2312
SNMPv2-SMI::enterprises.2312.6.5.1.1.389 = STRING: "389 Replica"
SNMPv2-SMI::enterprises.2312.6.5.1.2.389 = STRING: "389-Directory/1.2.11.15"
SNMPv2-SMI::enterprises.2312.6.5.1.3.389 = STRING: "Computing Services, Carnegie 
Mellon University"
SNMPv2-SMI::enterprises.2312.6.5.1.4.389 = STRING: "Pittsburgh, PA"
SNMPv2-SMI::enterprises.2312.6.5.1.5.389 = STRING: "y...@lists.andrew.cmu.edu"
SNMPv2-SMI::enterprises.2312.6.5.1.6.389 = STRING: "XXX"
This appears to only be the 'DS Entity Table', which is 
.1.3.6.1.4.1.2312.6.5.  I'm not sure why the snmpwalk is only showing 
this table, but I would try to access one of the other tables directly.  
Try the OID for the 'DS Operations Table', which is .1.3.6.1.4.1.2312.6.1.


-NGK

I get the impression I should be seeing a lot more.  I followed instructions at:
http://port389.org/wiki/Howto:SNMPMonitoring

uname -a
Linux XXX 2.6.32-358.18.1.el6.x86_64 #1 SMP Fri Aug 2 17:04:38 EDT 2013 x86_64 
x86_64 x86_64 GNU/Linux

Guidance appreciated.  Thank you!

/mrg
--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Problem after disabling anonymous binds

[Nathan Kinder]

On 06/21/2012 07:03 AM, Jeroen van Meeuwen (Kolab Systems) wrote:


Hi there,

I'm curious as to whether anyone else has experienced this problem before;

Disabling anonymous binds causes the 389-console to be unable to 
locate the entry corresponding to the user name used to login with (or 
so it seems).


In other words, disabling anonymous binds causes 389-console to be 
rendered disfunctional ;-)


I'd like to learn if this is a known problem, and/or whether there is 
a known workaround for the issue.



What version of 389-ds-base and 389-admin are you running?

Have you tried using a full DN to login from 389-console instead of 
simply a uid?


-NGK


Thank you in advance,

Kind regards,

Jeroen van Meeuwen

--

Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com

m: +44 74 2516 3817

w: http://www.kolabsys.com

pgp: 9342 BF08



--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Strange Disk IO issue

[Nathan Kinder]

On 05/16/2012 11:19 AM, Brad Schuetz wrote:


On 05/16/2012 06:16 AM, Paul Robert Marino wrote:

The exact timing of the issue is to strange is there a backup job
running at midnight. Or some other timed job that could be eating the
ram or disk IO. Possibly one that is reliant on ldap queries that
would otherwise be inocuious.



It doesn't happen at midnight, it's 24 hours from when the process was
started, so I can restart dirsrv at 3:17pm on Wednesday and at right
around 3:17pm on Thursday that server will go to 100% disk IO usage.
The default tombstone purge interval is 1 day, which seems to fit what 
you are seeing.  The tombstone reap thread will start every 24 hours to 
find tombstone entries that can be deleted.  The default retention 
period for tombstones is 1 week.  It is possible that you have a large 
number of tombstone entries that need to be deleted.  This will occur 
independently on all of your server instances.  This is controlled by 
the "nsDS5ReplicaTombstonePurgeInterval" and "nsDS5ReplicaPurgeDelay" 
attributes in your "cn=replica,cn=,cn=mapping tree,cn=config" 
entry.


You can search for "(objectclass=nstombstone)" as Directory Manager to 
see how many tombstone entries you have.


I've restarted the servers at totally random times to reproduce this
issue, and currently restart, via cron, all my ldap servers twice per
day at randomly selected times of the day to make sure that both they
are restarted before the 24 hours hits, and so that no more than 1
dirsrv process is being restarted at the same time.

Keep in mind, the ldap queries load has not changed from the setup I was
running prior to this which was running (much) older versions of the 389
server software.  In fact, as part of this system upgrade, additional
servers were added to reduce the individual load on each server.

--
Brad
--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Error updating to 389 1.2.9.9

[Nathan Kinder]

On 03/02/2012 06:32 AM, Michael R. Gettes wrote:

On Mar 2, 2012, at 9:21, Rich Megginson wrote:


On 03/01/2012 09:56 PM, Michael R. Gettes wrote:

I am in process of standing up a new directory service and will have to migrate 
many apps to the new service.  Do you believe 1.2.10.2 is stable enough for 
production use?  I would trust your assessment.  I realize the caveats of any 
recommendation you might make.

It's hard to say - we have people using 1.2.10.2 in production on EL6 and 
Fedora - but none on EL5 that I'm aware of.

So, best to stick with 1.2.9.9 for production until we get some more feedback 
on 1.2.10.2

let me see how i can try it out… not sure given how we maintain things.


That being said, I was hoping you could try it out and see if it still has the 
problem.

Perhaps it is a schema problem?

grep -i changenumber /etc/dirsrv/slapd-INST/schema/*
grep -i entryusn /etc/dirsrv/slapd-INST/schema/*

on 1.2.9.9

#grep -i changenumber *
02common.ldif:attributeTypes: ( 2.16.840.1.113730.3.1.5 NAME 'changeNumber' 
DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 
'Changelog Internet Draft' )
02common.ldif:objectClasses: ( 2.16.840.1.113730.3.2.1 NAME 'changeLogEntry' 
DESC 'LDAP changelog objectclass' SUP top MUST ( targetdn $ changeTime $ 
changenumber $ changeType ) MAY ( changes $ newrdn $ deleteoldrdn $ newsuperior 
) X-ORIGIN 'Changelog Internet Draft' )
# grep -i entryusn *
01core389.ldif.rpmnew:attributeTypes: ( 2.16.840.1.113730.3.1.2096 NAME 
'entryusn' DESC 'Netscape defined attribute type' SYNTAX 
1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE 
directoryOperation X-ORIGIN 'Netscape' )
The problem here seems to be that it is a *.rpmnew file.  This is 
causing your schema to not be updated from the upgrade.  Did you 
customize your 01core389.ldif file at some point?


Do a diff between 01core389.ldif and 01core389.ldif.rpmnew.


on 1.2.8.3

# grep -i changenumber *
02common.ldif:attributeTypes: ( 2.16.840.1.113730.3.1.5 NAME 'changeNumber' 
DESC 'Changelog attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 
'Changelog Internet Draft' )
02common.ldif:objectClasses: ( 2.16.840.1.113730.3.2.1 NAME 'changeLogEntry' 
DESC 'LDAP changelog objectclass' SUP top MUST ( targetdn $ changeTime $ 
changenumber $ changeType ) MAY ( changes $ newrdn $ deleteoldrdn $ newsuperior 
) X-ORIGIN 'Changelog Internet Draft' )
# grep -i entryusn *
#

yep, that's nothing on entryusn

/mrg


Thanks!

/mrg

On Mar 1, 2012, at 23:16, Rich Megginson wrote:


This code has changed with 389-ds-base 1.2.10.2 - any chance you could try that 
version, in epel-testing?


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] DNA configuration question

[Nathan Kinder]

On 11/08/2011 04:52 AM, cnu wrote:
> Hello,
>
> I use 389 directory server 1.2.8.1 in a master slave replication
> configuration.
> One master and five slaves.
> Now I want to configure DNA plugin. Is it sufficient to activate the
> plugin only on the master server ?
By slave, I assume you mean read-only replica?  You would not need to 
configure the
DNA plug-in on a read-only replica, as no write operations that trigger 
DNA would
occur there.  Simply configuring it on your single master is sufficient.
> thanks, br cnu
> --
> 389 users mailing list
> 389-us...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] ad nested objects sync

[Nathan Kinder]

On 09/16/2011 08:48 AM, solarflow99 wrote:



On Fri, Sep 16, 2011 at 11:01 AM, Rich Megginson > wrote:


On 09/16/2011 08:55 AM, Vasil Mikhalenya wrote:
> hi all,
>
> can windows sync agreement replicate nested objects ? like
> cn=user1,ou=location1,ou=Root,dc=domain ?
> when i specify ou=Root,dc=domain in sync agreement - it replicates
> only objects under ou=Root,dc=domain itself like
> cn=user_in_root,ou=Root,dc=domain but neither
> cn=user1,ou=location1,ou=Root,dc=domain nor
> ou=location1,ou=Root,dc=domain
>
> Is it possible at all?
No.



Try manually creating the OU subcontainers in 389.  I can't remember 
exactly how I did it, but I remember doing what you're trying to do.  
I think I had to put the users and groups OU under a common OU per 
replication agreement however.
This is correct.  The OU itself will not be replicated, but user and 
group entries will be replicated if the OU exists on both sides.


Hope this helps..


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 389-ds apparently listens only on loopback

[Nathan Kinder]

On 07/08/2011 07:26 AM, Arian Sanusi wrote:
> does that mean it listens only on IPv6?
What does 'sysctl net.ipv6.bindv6only' show on your system?

Do you have nsslapd-listenhost set in your cn=config entry? You can 
check this in /etc/dirsrv/slapd-/dse.ldif.
> [root@centos5-test ~]# netstat -tlnp
> Aktive Internetverbindungen (Nur Server)
> Proto Recv-Q Send-Q Local Address   Foreign
> Address State   PID/Program name
> tcp0  0 0.0.0.0:9830
> 0.0.0.0:*   LISTEN  2812/httpd.worker
> tcp0  0 0.0.0.0:646
> 0.0.0.0:*   LISTEN  2160/rpc.statd
> tcp0  0 0.0.0.0:111
> 0.0.0.0:*   LISTEN  2121/portmap
> tcp0  0 127.0.0.1:25
> 0.0.0.0:*   LISTEN  2431/sendmail: acce
> tcp0  0 127.0.0.1:6010
> 0.0.0.0:*   LISTEN  3982/0
> tcp0  0 :::389
> :::*LISTEN  3885/ns-slapd
> tcp0  0 :::22
> :::*LISTEN  2392/sshd
> tcp0  0 ::1:6010
> :::*LISTEN  3982/0
> tcp0  0 :::636
> :::*LISTEN  3885/ns-slapd
>
>
> [root@centos5-test ~]# iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> RH-Firewall-1-INPUT  all  --  anywhere anywhere
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
> RH-Firewall-1-INPUT  all  --  anywhere anywhere
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
>
> Chain RH-Firewall-1-INPUT (2 references)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywhere
> ACCEPT icmp --  anywhere anywhereicmp any
> ACCEPT esp  --  anywhere anywhere
> ACCEPT ah   --  anywhere anywhere
> ACCEPT udp  --  anywhere 224.0.0.251 udp dpt:mdns
> ACCEPT udp  --  anywhere anywhereudp dpt:ipp
> ACCEPT tcp  --  anywhere anywheretcp dpt:ipp
> ACCEPT all  --  anywhere anywherestate
> RELATED,ESTABLISHED
> ACCEPT tcp  --  anywhere anywherestate NEW
> tcp dpt:ssh
> REJECT all  --  anywhere anywherereject-with
> icmp-host-prohibited
>
>
> On 08.07.2011 16:19, Paul Robert Marino wrote:
>> out put from
>> 'sudo netstat -tlnp'
>> please
>> followed by the the out put of
>> 'sudo /sbin/iptables -L'
>> feel free to obscure the ip's it they are internet visible replace the
>> first 2 octets with 192.168
> --
> 389 users mailing list
> 389-us...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Building 389 console

[Nathan Kinder]

On 05/23/2011 10:56 AM, Michael Pelletier wrote:



On May 23, 2011, at 11:55 AM, Rich Megginson  wrote:


On 05/23/2011 09:51 AM, Michael Pelletier wrote:

Hello,

I have followed the instructions on 
http://directory.fedoraproject.org/wiki/BuildingConsole#Building_Directory_Server_Console_.28fedora-ds-console.29


However, when I start the 389-conole on a remote server, I can login 
fine, I click on "Administrative Server" and I get a message:

 "Failed to instantiate Server Object for Administration Server
com.netscape.management.admserv.AdminServer cannot be cast to 
com.netscape.management.client.topology.IServerObject"


Running the console in debug mode gives:
ClassLoader: 
com/netscape/management/client/topology/TopologyResourcePage.class 
found in 389-admin-1.1.jar
ClassLoader: 
com/netscape/management/client/topology/topology_en_US.properties  
NOT in 389-admin-1.1.jar
ClassLoader: 
com/netscape/management/client/topology/topology_en.properties  NOT 
in 389-admin-1.1.jar
ClassLoader: 
com/netscape/management/client/topology/topology.properties  NOT in 
389-admin-1.1.jar
ClassLoader: 
com/netscape/management/admserv/admserv_en_US.properties  NOT in 
389-admin-1.1.jar
ClassLoader: com/netscape/management/admserv/admserv_en.properties  
NOT in 389-admin-1.1.jar
ClassLoader: com/netscape/management/admserv/admserv.properties  NOT 
in 389-admin-1.1.jar

ClassLoader: :loadClass():name:java.util.Vector
ClassLoader: 
:loadClass():name:com.netscape.management.admserv.AdminServer$1
ClassLoader: 
:loadClass():loading:com.netscape.management.admserv.AdminServer$1
ClassLoader: com/netscape/management/admserv/AdminServer$1.class 
found in 389-admin-1.1.jar
ERROR ServerNode.createServerInstance: could not create 
com.netscape.management.admserv.adminser...@389-admin-1.1.jar@cn=admin-serv-ldap1,cn=389 
Administration Server,cn=Server 
Group,cn=ldap1.mcna.net,ou=mcna.net,o=NetscapeRoot
Exception: java.lang.ClassCastException: 
com.netscape.management.admserv.AdminServer cannot be cast to 
com.netscape.management.client.topology.IServerObject


Please help!!!
Not sure if regular ant install does this, but the 389-ds* and 
389-admin* jar files have to be installed in /usr/share/dirsrv/html/java


Yup I did this. It seems the jar file is missing the netscape java 
class. I think the problem is in the ant build
Take a look at your 389-console shell script that you use to launch 
Console.  Perhaps there's some problem with the classpath in there.




You can also copy them to ~/.389-console/jars

Michael
--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Importing Thunderbird AddressBook into LDAP

[Nathan Kinder]

On 05/23/2011 08:47 AM, Philip Rhoades wrote:
> Christopher,
>
>
> On 2011-05-24 01:08, Christopher Wood wrote:
>> On 23/05/11 02:06 AM, Carsten Grzemba wrote:
>>> I guess the standard schema of 389Ds do not know objectclass 
>>> mozillaAbPersonAlpha and the attribute mozillanickname
>>>
>> My 389 install (rpm via epel) has those:
>>
>> [root@cwldap-01 ~]# grep mozillaAbPersonAlpha
>> /etc/dirsrv/schema/60mozilla.ldif
>> # mozillaAbPersonAlpha
>> NAME 'mozillaAbPersonAlpha'
>> [root@cwldap-01 ~]# grep mozillaNickname /etc/dirsrv/schema/60mozilla.ldif
>> NAME ( 'mozillaNickname' 'xmozillanickname' )
>> MAY ( c $ description $ displayName $ facsimileTelephoneNumber $
>> givenName $ homePhone $ l $ mail $ mobile $ mozillaCustom1 $
>> mozillaCustom2 $ mozillaCustom3 $ mozillaCustom4 $
>> mozillaHomeCountryName $ mozillaHomeLocalityName $ mozillaHomePostalCode
>> $ mozillaHomeState $ mozillaHomeStreet $ mozillaHomeStreet2 $
>> mozillaHomeUrl $ mozillaNickname $ mozillaSecondEmail $
>> mozillaUseHtmlMail $ mozillaWorkStreet2 $ mozillaWorkUrl $ nsAIMid $ o $
>> ou $ pager $ postalCode $ postOfficeBox $ sn $ st $ street $
>> telephoneNumber $ title )
>
> Yes, I have exactly the same - now I am really confused . .
I don't think that the problem is the schema.  The problem is likely 
that the suffix use in your LDIF does not exist in your directory server.

Your example entry from your LDIF has a DN of "dn: cn=Tina 
XX,mail=txxx...@nyyy.com".  You can't import this entry unless 
you have an entry with a DN of "mail=txxx...@nyyy.com" already in 
your directory server.  It is highly unlikely that you have this as it 
is not a format that is usually used for a suffix.

I would recommend modifying your LDIF to use a more normal suffix in the 
DN of your user entries.  A more common suffix format would be something 
such as "dc=example,dc=com".  You will need to be sure this suffix 
already exist in your directory server before you can add the entries 
from your LDIF, otherwise you will get an error 32 (no such entry) when 
you attempt the adds.

-NGK

> Thanks,
>
> Phil.
>
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Building 389-ds-console-1.2.5, 389-console-1.1.6 and 389-admin-console-1.1.7 (via Git)

[Nathan Kinder]

On 05/23/2011 05:57 AM, Michael Pelletier wrote:

Can anyone help with this?



On May 22, 2011, at 12:42 AM, Michael Pelletier 
 wrote:



Hello all,

I am building my own package. I have compilied everything except 
389-ds-console-1.2.5, 389-console-1.1.6 and 389-admin-console-1.1.7


I have been running into a problem. I used git to download the 
sources. I went into the 389-ds-console directory and typed ant and I 
get:


BUILD FAILED
/usr/local/Source/389/TEMP/389-ds-console-1.25/build.xml:76: 
/usr/local/Source/389/TEMP/imports/console/389-console-1.2.5 not found


Please help.
What am I doing wrong?
You need to specify the location of the 389-console jar files.  You can 
do this by adding "-Dconsole.location=" to your ant command.


-NGK


Michael



--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Install on RHEL 6....

[Nathan Kinder]

On 02/14/2011 10:36 AM, danielg...@yaktech.com wrote:
> I have managed to get everything compiled and all packages installed, but
> when I go through the /usr/sbin/setup-ds-admin.pl script if fails with
>
> Could no start the admin server. Error: 256
> Failed to create and configure the admin server.
>
> This appeared to be a problem with the scripted not correctly creating the
> /var/log/dirserv/admin-serv directory.  When I create that before the
> install it then errors with
>
> Errot updating console.conf
>
> NMC_Status: 1
> NMC_ErrType:
> NMC_ErrInfo: Cannot open file for reaing
> Could not update the httpd engine configuration.
> Failed to create and configure the admin server
> Exiting . . .
>
> Any clues?
I believe that this is an issue with the selinux policy.  Do you see any 
AVCs in /var/log/audit/audit when you attempt to run setup-ds-admin.pl?
> Thanks.
>
>
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] How to get alternate versions of src RPM's via yum, or better yet without yum?

[Nathan Kinder]

On 11/29/2010 02:03 PM, brandon wrote:
> Is there an easier way to get the SRC RPMs without YUM?
>
> I find the YUM repo a very frustrating way of getting the software. I
> want the the src RPMs so I can rebuild them myself, but I don't want to
> get the version that is pushed via yum by default.  I have F13, which is
> pulling 389-ds-base 1.2.7.1.  I want the latest stable, 1.2.6 and its
> various dependencies.
389-ds-base-1.2.7.1 is the latest stable release.  It was pushed to the 
stable repository over the weekend on F-13.  It it currently in the 
queue to be pushed to stable for F-14.

You can see the older versions of available packages via yum by doing a 
"yum list available --showduplicates".  You can then install the version 
you want explicitly.
> Suggestions?
>
> Thanks,
>
> -Brandon
> --
> 389 users mailing list
> 389-us...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Replication from 1.2.5 to 1.2.6 failed

[Nathan Kinder]

On 10/16/2010 11:42 AM, Edward Z. Yang wrote:
> I've got a failure, and I'm able to gdb it.  However, I don't
> know what to look for.  What kind of tracing would you like to
> see?  I was going to wireshark but decrypting the Kerberos would
> be annoying.
>
If you can break in acquire_replica() on the master when it attempts to 
begin replication with the older instance, I would like to see what 
prp->repl90consumer contains.

I am guessing that this will have some garbage value since it is not 
being initialized to 0 as discussed earlier today on this list.

-NGK
> [16/Oct/2010:14:17:16 -0400] NSMMReplicationPlugin - agmt="cn=GSSAPI 
> Replication to busy-beaver.mit.edu" (busy-beaver:389): Unable to parse the 
> response to the startReplication extended operation. Replication is aborting.
>
> Edward
> --
> 389 users mailing list
> 389-us...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] synchronization state between replicas

[Nathan Kinder]

On 09/30/2010 09:49 PM, Barry Sitompul wrote:
> Hi All,
>
>
> Does 389-DS provide a tool to check the synchronization state between
> replicas to check whether or not the replicas have converged?
>
> I recall there was a tool called 'insync' that came with Sun Directory
> Servers quite some time ago. Just wondering if 389-DS has something
> similar. If not, what's the best way to check that?
>
There is a web-based monitoring tool that you can use.  For details, see 
http://directory.fedoraproject.org/wiki/AdminExpress#Monitoring_Replication_from_Admin_Express
>
> Thanks!
> Bazza
> --
> 389 users mailing list
> 389-us...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] SSHA and friends

[Nathan Kinder]

On 09/22/2010 10:45 AM, Gerrard Geldenhuis wrote:


Hi

This is probably OT but I am not having much luck with google. How can 
I create SSHA512 strings? I have been using either a php script or 
slappasswd to create SSHA password but not sure how to do SSHA512. 
openssl can create the SHA512 digest but I am not sure how to add the 
random seed bit. My question probably illuminate my lack of 
understanding of the subject.


Why are you pre-hashing passwords?  You can set the password storage 
scheme to SSHA512 in 389 and provide a cleartext userPassword value to 
the server and it will hash it for you.


Best Regards



In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.




--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] possibe selinux issue on 1.2.6

[Nathan Kinder]

On 09/22/2010 05:48 AM, smlacc1 leador wrote:
> Hi There,
>
> I just installed 1.2.6 from the epel repository onto a freshly
> installed and updated RHEL 5.5.
>
> When I use "service dirsrv-admin start", it starts, but then refuses
> to receive connections.  the /var/log/dirsrv/admin-serv/error log
> shows the process in an endless segfault/startup loop.
>
We need to see the AVC messages from /var/log/audit/audit when this occurs.

-NGK
> If i stop the service and then run "start-ds-admin", it works fine -
> no segfaults and I can log into the 389-console fine.
>
> I also tried disabling selinux, and when I do that, i can then run
> "service dirsrv-admin start" and it comes up fine.  So the issue seems
> linked to selinux and the init startup script.  I can use the
> start-ds-admin to get it going, but if the server ever reboots it int
> going to come back up properly.
>
> Selinux is on enforcing targeted if that helps.
>
> Thanks,
> Smlacc.
> --
> 389 users mailing list
> 389-us...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] superior attributes (not object classes)

[Nathan Kinder]

On 08/31/2010 08:28 PM, Brian LaMere wrote:



> Was this ever looked at again for a feature enhancement?  Is it
> already available, if I do X thing?
A feature enhancement to the schema conversion tool?  I'm not sure who
maintains that now.


well, I was simply running the schema-reload.pl 
 script; the script ran fine, it was internal 
dynamic reload task on the directory server that had a problem, per 
the error log for the slapd instance:


[31/Aug/2010:15:30:23 -0700] schemareload - Schema reload task starts 
(schema dir: default) ...
[31/Aug/2010:15:30:23 -0700] dse - The entry cn=schema in file 
/etc/dirsrv/slapd-redacted/schema/97hosting.ldif is invalid, error 
code 21 (Invalid syntax) - attribute type nocastr128: Missing parent 
attribute syntax OID

[31/Aug/2010:15:30:23 -0700] schema_reload - schema file validation failed
[31/Aug/2010:15:30:23 -0700] schemareload - Schema validation failed.

> I got it because I was using "SUP nocastr128" in an attributeType,
> after defining an attributeType of nocastr128 with the base
components
> I wanted to inherit.
So the problem is that SYNTAX is not inherited from the parent?
What version of 389-ds-base are you using?
Can you post the definitions of the parent and child attributes?

Yeah, I messed with it a bit not knowing what it was talking about; at 
first I tried to figure out why it was loading my 97hosting.ldif file 
earlier than the 00core.ldif file that had the syntax that was 
"missing," since that seemed to be what the error was saying.


As a simple example though, if I try to create an attribute with "SUP 
top" it fails; I can do that with an objectclass with no problems, but 
not with an attributetype.  Here's an extremely over-simplified example:
You can't have an attribute use an objectclass as it's superior.  An 
attribute can only use another attribute as it's superior.  The same 
restriction goes for an objectclass.  An objectclass can only use 
another objectclass as it's superior.


-NGK


---
m...@redacted:/etc/dirsrv/slapd-redacted/schema# cat 96testing.ldif
#

#
dn: cn=schema
#

#
attributeTypes: (
  2.25.184169507047331805154432216124173436187.1.2.3.9
  NAME 'testAttributeWithSup'
  DESC 'rfc2252 allows for both superior objectclasses and superior 
attributetypes'

  SUP top
  )
#

#
m...@redacted:/etc/dirsrv/slapd-redacted/schema# 
/usr/lib64/dirsrv/slapd-redacted/schema-reload.pl 
 -v -D "cn=Directory Manager" -j ../dirman.pwd

ldapmodify: started Tue Aug 31 20:12:04 2010

ldap_init( redacted.here.com , 389 )
add objectclass:
top
extensibleObject
add cn:
schema_reload_2010_8_31_20_12_4
adding new entry cn=schema_reload_2010_8_31_20_12_4, cn=schema reload 
task, cn=tasks, cn=config

modify complete

m...@redacted:/etc/dirsrv/slapd-redacted/schema# tail -4 
/var/log/dirsrv/slapd-redacted/errors
[31/Aug/2010:20:12:03 -0700] schemareload - Schema reload task starts 
(schema dir: default) ...
[31/Aug/2010:20:12:03 -0700] dse - The entry cn=schema in file 
/etc/dirsrv/slapd-redacted/schema/96testing.ldif is invalid, error 
code 21 (Invalid syntax) - attribute type testAttributeWithSup: 
Missing parent attribute syntax OID

[31/Aug/2010:20:12:03 -0700] schema_reload - schema file validation failed
[31/Aug/2010:20:12:04 -0700] schemareload - Schema validation failed.

---

Doing the same with an objectclass ("SUP top") works fine, obviously. 
 All this means is I can't define attributes that are inheritance 
types; no matter how many times I may repeat the same three lines in 
many entries, they have to be repeated; I can't just say "SUP 
nocastr128" instead.


Again, doesn't stop anything from working, I just did a global 
search/replace in vi and was done quickly.  It just looks messier, and 
was curious why it wasn't allowed to have superior attributes, or if 
there was something I was doing wrong?


Brian LaMere


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] issue getting schema - Version 1.2.x return no operational attributes

[Nathan Kinder]

On 07/29/2010 01:30 AM, Rudolf Hatheyer wrote:
> Hi,
>
> I've noticed a difference in behavior between 1.0.x and 1.2.x Version of
> FDS.
> Version 1.2.x will not return the hole schema (without specifying
> attributes objectClasses, matchingRules ).
>
This change came about from some work to make 389 more standards 
compliant.  The "objectClasses" and "attributeTypes" attributes are 
defined as operational attributes per RFC 4512.  This requires a client 
to explicitly request those attributes (see RFC 4512, section 4.4).  
Unfortunately, there is no easy way to change this behavior.

Is there no way to make ADSI/VBScript request the attributes to return 
when querying the subschema entry?  It seems like this would be a 
problem when using any server that follows the LDAPv3 standards with 
regards to subschema.
> This a problem when querying by use of VBScript (i need this ugly stuff
> in a windows login script to get specific user data from the LDAP). ADSI
> will first do a root-DSE query to determine the provided schema. If the
> server returns no schema, ADSI will allow you to query only standard
> LDAP V2 attributes (and not my special ones).
>
> Query a Server with Version 1.2.5
>
> # ./ldapsearch -h 192.168.1.202 -b cn=schema -s base "objectclass=*"
> version: 1
> dn: cn=schema
> objectClass: top
> objectClass: ldapSubentry
> objectClass: subschema
> cn: schema
>
> Specifying for instance "objectClasses" attribut in the query returns
> the wanted data:
>
> version: 1
> dn: cn=schema
> objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN
> 'RFC 45
>   12' )
> objectClasses: ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST
> aliasedObjectNam
>   e X-ORIGIN 'RFC 4512' )
> objectClasses: ( 2.5.20.1 NAME 'subschema' AUXILIARY MAY (
> dITStructureRules $
>nameForms $ dITContentRules $ objectClasses $ attributeTypes $
> matchingRule
>   s $ matchingRuleUse ) X-ORIGIN 'RFC 4512' )
> objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
> SUP top
> [...]
>
> Query a Server with Version 1.0.4
>
> version: 1
> dn: cn=schema
> objectClass: top
> objectClass: ldapSubentry
> objectClass: subschema
> cn: schema
> objectClasses: ( 2.5.6.0 NAME 'top' DESC 'Standard LDAP objectclass'
> ABSTRACT
>   MUST objectClass X-ORIGIN 'RFC 2256' )
> objectClasses: ( 2.5.6.1 NAME 'alias' DESC 'Standard LDAP objectclass'
> SUP top
>ABSTRACT MUST aliasedObjectName X-ORIGIN 'RFC 2256' )
> objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
> DESC 'LD
>   APv3 extensible object' SUP top AUXILIARY X-ORIGIN 'RFC 2252' )
>   [...]
>
>
> Is there a way to configure the 1.2.x series to get the old behavior?
>
> Regards, Rudolf
>
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Windows Sync

[Nathan Kinder]

On 07/27/2010 10:21 AM, --[ UxBoD ]-- wrote:
> Hi,
>
> We have a Windows replication agreement in place which works great; plus we 
> are using the PassSync on the Windows server itself.  The issue we have is 
> that when somebody changed their password on the Windows server it has got 
> stuck due to a Constraint Violation on previous passwords and this is 
> stopping any further password changes from that user.  Is there anyway to 
> remove that entry from a database somewhere ? I am guessing it may be 
> secmod.db on the Windows server ?
>
The password changes are not kept in secmod.db.  They changes are kept 
in the passhook.dat file in the system32 directory.  This file is 
encrypted, so there's not an easy way to remove the one problematic 
change from that file.  I believe that you could stop the Password Sync 
Service and remove passhook.dat to clear things out, but you will lose 
whatever password changes are queued up.  New changes should be sync'd 
fine at that point though.

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 'mail' attribute is now case-sensitive?

[Nathan Kinder]

On 07/23/2010 07:20 AM, Dael Maselli wrote:
> Hi,
>
> I installed a new 389 (389-ds-base-1.2.5-1.el5.x86_64) to replace the
> old FDS (fedora-ds-base-1.1.3-2.fc6.x86_64) and migrated the content.
>
> Now I realize that search behavior on 'mail' has changed, the old was
> case-insensitive and now is case-SENSITIVE.
>
> Schema definition on FDS was in 01common.ldif:
>
> attributeTypes: ( 0.9.2342.19200300.100.1.3 NAME ( 'mail'
> 'rfc822mailbox' ) DESC 'Standard LDAP attribute type' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 1274' )
>
> on 389 is in 05rfc4524.ldif:
>
> attributeTypes: ( 0.9.2342.19200300.100.1.3 NAME 'mail'
> EQUALITY caseIgnoreIA5Match
> SUBSTR caseIgnoreIA5SubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
> X-ORIGIN 'RFC 4524' )
>
>
> Is the case-sensitive the right behavior?
>
> What's the meaning of caseIgnoreIA5Match then?
> ^^
>
> Is there any method to get back the old (useful) case-insensitive behavior?
>
I believe that the fix for this is slated for 389 1.2.6.  You can get 
the current 1.2.6 release candidate from the Fedora testing repos to try 
it out.

https://bugzilla.redhat.com/show_bug.cgi?id=559315

-NGK
> Thank you.
>
> Regards,
>   Dael.
>
>
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] new 00core.ldif break other ldif

[Nathan Kinder]

On 07/23/2010 07:19 AM, Roberto Polli wrote:
> Hi all,
>
> it seems that the new 00core.ldif doesn't contain the NAME alias for the
> fields (eg. "cn" "commonName")
>
> it cause other old ldif not to work under new releases of fds.
>
> Why are the aliases have been removed?
>
I don't think that this was done intentionally.  It seems as if the 
X.500 aliases were dropped when we updated the schema to match RFC 
4519.  Please open a bug on this so we can add the X.500 aliases back in.

-NGK
> Thx+Peace,
> R.
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Announcing 389 Directory Server 1.2.6 Release Candidate 3

[Nathan Kinder]

On 07/19/2010 08:47 AM, Aaron Hagopian wrote:
Ok this time I think I have hit a legit issue with SELinux and 1.2.6 
RC3.  On my workstation to sync up my ldap server with production I 
take a ldif dump from production and load it into my system with the 
ldif2db.pl <http://ldif2db.pl> script.  For versions 1.2.5 and 
previous that ldif file could be located anywhere that was readable to 
the "nobody" user.  Since upgrading, I try to use the same command and 
get denied because of SELinux.


My real question here is what is an acceptable directory?  I thought 
for sure the /var/lib/dirsrv/slapd-/ldif/  directory would 
be acceptable but I get a "SELinux is preventing /usr/sbin/ns-slapd 
"read" access on ..." message no matter where I place the LDIF file.
How did you create the ldif file in 
"/var/lib/dirsrv/slapd-/ldif/"?  Did you move the ldif file 
there from elsewhere on your system?  That could explain why your ldif 
file has an incorrect context of "var_t".


Try creating a new file in "/var/lib/dirsrv/slapd-/ldif/" 
using 'touch', then run 'ls -lZ' to see what the SELinux context is on 
that new file.  It should be "dirsrv_var_lib_t".


-NGK


Attached is the full SELinux error.

Thanks,

Aaron


On Fri, Jul 16, 2010 at 8:49 AM, Aaron Hagopian <mailto:airhe...@gmail.com>> wrote:


As I was looking up the version number of admin I noticed that I
had only updated 389-ds* and not 389* so the 389-admin* packages
were mismatched.  Once I upgraded everything to what was in
    updates-testing no more selinux messages, sorry about the confusion.

Aaron

2010/7/15 Nathan Kinder mailto:nkin...@redhat.com>>

On 07/15/2010 09:12 AM, Aaron Hagopian wrote:

I upgraded my fedora 13 x86_64 machine to the RC3 using the
rpms in updates-testing and now I cannot start the admin
server with selinux enabled.  I am attaching the selinux
message.  It does start when I disable selinux.

What version of 389-admin are you running?

I'd also like to see the output of 'semodule -l | grep 389'
from your system.

-NGK




On Tue, Jul 6, 2010 at 2:38 PM, Rich Megginson
mailto:rmegg...@redhat.com>> wrote:

The 389 team is pleased to announce the availability of
Release
Candidate 3 of version 1.2.6.  This release has a few bug
fixes.

***We need your help!  Please help us test this
software.***  It is a
release candidate, so it may have a few glitches, but it
has been tested
for regressions and for new feature bugs.  The Fedora system
strongly encourages packages to be in Testing until
verified and pushed
to Stable.  If we don't get any feedback while the
packages are in
Testing, the packages will remain in limbo, or get pushed
to Stable.

The more testing we get, the faster we can release these
packages to
Stable.  See the Release Notes for information about how
to provide
testing feedback (or just send an email to
389-us...@lists.fedoraproject.org
<mailto:389-us...@lists.fedoraproject.org>).

The packages that need testing are:
* 389-ds-base-1.2.6.rc3 - 389-ds-base

More information
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download

=== Bugs Fixed ===
This release contains a couple of bug fixes.  The
complete list of bugs
fixed is found at the link below.  Note that bugs marked
as MODIFIED
have been fixed but are still in testing.
* Tracking bug for 1.2.6 release -

https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0

<https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0>
**  Bug 606920 - anonymous resource limit - nstimelimit -
also applied
to "cn=directory manager"
** Bug 604453 - SASL Stress and Server crash: Program
quits with the
assertion failure in PR_Poll
** Bug 605827 - In-place upgrade: upgrade dn format
should not run in
setup-ds-admin.pl <http://setup-ds-admin.pl>
** Bug 578296 - Attribute type entrydn needs to be added
when subtree
rename switch is on
** Bug 609256 - Selinux: pwdhash fails if called via
Admin Server CGI
** Bug 603942 - null deref in _ger_parse_control() for

Re: [389-users] enabling posixGroup for a group (error : attribute "uidNumber" not allowed)

[Nathan Kinder]

On 07/06/2010 10:22 AM, Daniel Maher wrote:
> On 07/06/2010 07:04 PM, Nathan Kinder wrote:
>
>
>>> To clarify then, for the uids, instead of this :
>>>
>>> dnafilter: (|(objectclass=posixAccount)(objectclass=posixGroup))
>>>
>>> It should be this :
>>>
>>> dnafilter: (objectclass=posixAccount)
>>>
>>> ?
>>>
>>>
>> Yes, that is correct.  The current setting you have causes DNA to add a
>> "uidNumber" attribute to newly created "posixAccount" and "posixGroup"
>> entries.  You only want DNA to add the "uidNumber" attribute to
>> "posixAccount" entries.
>>  
> That makes sense.  Somebody may wish to update the Howto on the
> documentation site. :)
>
I'll update the how-to.

In the upcoming 1.2.6 release, I've added support for multi-attribute 
ranges, which could be used for your use-case as well (I know we've 
discussed this on list a while back).  Basically, you would set up a 
single DNA range with multiple "dnaType" values, such as uidNumber and 
gidNumber in this case.  You would then set the "dnaFilter" to 
"(|(objectClass=posixAccount)(objectClass=posixGroup))".  With a 
multi-attribute range, you must specify the magic value for any 
attribute that you want DNA to generate a value for.  This means you 
could share a single range of values across your posixAccount and 
posixGroup entries instead of having two separate ranges.
> Thanks !
>
>
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] enabling posixGroup for a group (error : attribute "uidNumber" not allowed)

[Nathan Kinder]

On 07/06/2010 09:08 AM, Daniel Maher wrote:
> On 07/06/2010 05:31 PM, Nathan Kinder wrote:
>
>
>>> http://directory.fedoraproject.org/wiki/Howto:DNA
>>>
>
>> The way you have DNA configured will cause it to try to add a
>> "uidNumber" attribute to a posixGroup entry.  You should change the
>> "dnaFilter" attribute for your "cn=UID numbers" DNA config entry to be
>> "(objectClass=posixAccount)".
>>  
>
> To clarify then, for the uids, instead of this :
>
> dnafilter: (|(objectclass=posixAccount)(objectclass=posixGroup))
>
> It should be this :
>
> dnafilter: (objectclass=posixAccount)
>
> ?
>
Yes, that is correct.  The current setting you have causes DNA to add a 
"uidNumber" attribute to newly created "posixAccount" and "posixGroup" 
entries.  You only want DNA to add the "uidNumber" attribute to 
"posixAccount" entries.

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] enabling posixGroup for a group (error : attribute "uidNumber" not allowed)

[Nathan Kinder]

On 07/02/2010 07:22 AM, Daniel Maher wrote:
> On 07/02/2010 11:58 AM, Daniel Maher wrote:
>
>
>> I am trying to get system groups working on 389-ds via the addition of
>> "posixGroup" as a value for a given LDAP group.
>>  
>
>> However, this error appears in the log :
>>
>> [02/Jul/2010:09:43:03 +] - Entry
>> "cn=admin,ou=systemgroups,dc=domain,dc=net" -- attribute "uidNumber" not
>> allowed
>>  
> Hello,
>
> After wiping out my test instance and starting from scratch, it has
> become clear that the problem is related to the DNA plugin.  If i do NOT
> activate / configure the DNA plugin, then i can manipulate
> posixGroup-related entries as expected.  As soon as the plugin is
> activated and configured, the error noted above occurs.
>
> I followed (and *cough* wrote) this document exactly :
> http://directory.fedoraproject.org/wiki/Howto:DNA
>
> [r...@test-dma-36 dirsrv]# /usr/lib64/mozldap/ldapsearch -h localhost -p
> 389 -s base -b "" "objectclass=*" | grep vendorVersion
> vendorVersion: 389-Directory/1.2.5 B2010.012.2034
> [r...@test-dma-36 dirsrv]# cat /etc/redhat-release
> CentOS release 5.4 (Final)
> [r...@test-dma-36 dirsrv]# uname -s -r -v -i -o
> Linux 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:30:06 EDT 2010 x86_64
> GNU/Linux
>
> It would seem that this is either a fault in the configuration of the
> plugin, or a bug with the plugin itself.  Has anybody else experienced
> similar behaviour ?
>
The way you have DNA configured will cause it to try to add a 
"uidNumber" attribute to a posixGroup entry.  You should change the 
"dnaFilter" attribute for your "cn=UID numbers" DNA config entry to be 
"(objectClass=posixAccount)".

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] restarting the 389 after a reboot

[Nathan Kinder]

On 06/24/2010 03:49 PM, Steven Jones wrote:
> Steven Jones wrote:
>
>>  
> 8><-
>
>>
>> see also the configuration directory ldap url - ldapurl in
>>
>> /etc/dirsrv/admin-serv/adm.conf
>>
>>  
> 8><-
>
>> Ok, I fixed the latter by editing the adm.conf to point at
>> 636however I now have a SSL error...
>>
>> 
>>
>> [r...@vuwunicooimm001 admin-serv]# ldapsearch -x -D "cn=ldapadmin" -w
>> XXX -b o=netscaperoot "(&(nsServerID=slapd-vuwunicooimm001))"
>>
>> ldap_bind: Can't contact LDAP server (-1)
>>
>>  additional info: error:14090086:SSL
>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>>
>>  
> Why is /usr/bin/ldapsearch attempting to use SSL by default?  What's in
> your /etc/openldap/ldap.conf or ~/.ldaprc?
>
> Ok, fixed
>
> ldaps changed to ldap
>
>
>> 
>>
>>
>>
>> Ive tried using this syntax but with no joy...
>>
>>
>>
>> ldapmodify -x -D "cn=directory manager" -w password
>>
>> dn: dn of your server instance entry
>>
>> changetype: modify
>>
>> replace: nsServerSecurity
>>
>> nsServerSecurity: on
>>
>>
>>
>> so my command is,
>>
>>
>>
>> ldapmodify -x -D "cn=lpdapadmin" -w password XXX
>> dn:vuwunicooimm001.vuw.ac.nz changetype: modify replace:
>> nsServerSecurity nsServerSecurity on
>>
>>  
> ? this is all on one command line?
>
>
> Yes...
>
>
> I guess it's not clear from the
> example, but ldapmodify by default wants to read the LDIF input from
> stdin - so after you type in
>
> OK...
>
>
> $ ldapmodify -x -D "cn=lpdapadmin" -w password XXX
> it will wait for you to type in the rest on stdin, followed by a blank
> line (i.e. hit Enter twice) followed by Ctrl-C or Ctrl-D to "get out" of
> ldapmodify
>
>
> ===
> [r...@vuwunicooimm001 admin-serv]# ldapmodify -x -D "cn=lpdapadmin"
> ldap_bind: Server is unwilling to perform (53)
>  additional info: Unauthenticated binds are not allowed
> [r...@vuwunicooimm001 admin-serv]# ldapsearch -x -D "cn=ldapadmin" -w XX
> ldap_bind: No such object (32)
> [r...@vuwunicooimm001 admin-serv]#
> ===
>
> um?
>
You need to specify a password with the "-w" option to ldapmodify.  
Supplying a bind DN with no password is considered an "unauthenticated" 
bind, which is not allowed by default.

I believe the ldapsearch error is saying that the "cn=ldapadmin" entry 
does not exist.  This does not appear to be a full DN.  You can check 
what your ldap "superuser" account is by looking at your nsslapd-rootdn 
setting /etc/dirsrv/slapd-/dse.ldif.  The default is "cn=Directory 
Manager".  If you actually created a "cn=ldapadmin" user in your 
database, you need to specify the rest of the DN when binding as that user.
>
> you could also dump those commands in a file and run
> $ ldapmodify -x -D "cn=lpdapadmin" -w password XXX -f /path/to/file.ldif
>
> ===
> [r...@vuwunicooimm001 admin-serv]# ldapmodify -x -D "cn=lpdapadmin" -w 
> cvbrty542 -f file.ldif
> ldap_bind: No such object (32)
> [r...@vuwunicooimm001 admin-serv]#
> ===
>
> 8><--
>
>>  
> Is the directory server listening for TLS/SSL requests on port 636?
> That is, have you configured the directory server for TLS/SSL and have
> you confirmed that it is listening?
>
>>  
> 8><-
>
>>  
> Before you do anything else, confirm that the directory server is indeed
> listening for TLS/SSL requests on port 636.
>
>>  
> =
> [r...@vuwunicooimm001 admin-serv]# netstat -a -n |grep :636
> tcp0  0 127.0.0.1:49186 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:49185 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35428 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35429 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35430 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35424 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35425 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35426 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35427 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35412 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35413 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35414 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35415 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35408 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35409 127.0.0.1:636   
> TIME_WAIT
> tcp0  0 127.0.0.1:35410 127.0.0.1:636

Re: [389-users] errors once in the admin console

[Nathan Kinder]

On 06/15/2010 07:20 PM, Steven Jones wrote:
> Hi,
>
> I installed with, "yum -y install 389-ds"
>
> I have started the console with, /usr/bin/389-console
>
> under the Server group folder I have "Administration Server"  and "Directory 
> Server" (hostname)
>
> Clicking on either of these gives me a class load error saying,
>
> "failed to install a local copy a local copy of 389-ds-1.2.jar or one of its 
> supporting files"
>
> or,
>
> "failed to install a local copy a local copy of 389-admin-1.1.jar or one of 
> its supporting files"
>
> "Can not connect to http://(hostname):9830"
>
> When I installed the ldap system the 389.ds and 389-admin rpms were 
> installed...
>
> Any ideas please?
>
Does the server have the 389-ds-console and 389-admin-console rpms 
installed?  Those packages contain the jar files that Console is 
attempting to download from the Administration Server.
> Where are the logs kept?
>
/var/log/dirsrv
> regards
>
> Steven
>
>
>
>
>
> --
> 389 users mailing list
> 389-us...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] magic numbers (DNA) : console issues & gid assignment problem

[Nathan Kinder]

On 04/19/2010 07:03 AM, Daniel Maher wrote:
> On 04/16/2010 06:39 PM, Nathan Kinder wrote:
>
>
>> The document you are using off of the wiki is an feature design document
>> that was used while developing DNA.  Not everything mentioned in there
>> is in the plug-in.  The ability to use multiple dnaType attributes in
>> the same range is one of these things that is not implemented at this time.
>>  
> Fair enough.  I assumed that the document entitled « DNA Plugin Proposal
> » was the design document, and that « DNA Plugin » was the proper
> documentation.  :/
>
>
>> You can set up two separate ranges, one for the uidNumber attribute and
>> another for the gidNumber attribute.  While this doesn't guarantee that
>> uidNumber == gidNumber for a user, the values will indeed be the same if
>> you configure the ranges the same and always let DNA generate the values
>> for those attributes.  The main issue to deal with to ensure the values
>> are the same would be to use a different range of gidNumbers for
>> posixGroup entries.
>>  
> It should be as easy as creating two separate entries and then
> integrating them both, yes ? ex. :
>
> dn: cn=UID, cn=DNA
> ...
> dnatype: uidNumber
> dnamagicregen: 9
> dnanextvalue: 1000
> dnafilter: (objectclass=posixAccount)
> ...
>
> AND
>
> dn: cn=GID, cn=DNA
>  ...
> dnatype: gidNumber
> dnamagicregen: 9
> dnanextvalue: 1000
> dnafilter: (objectclass=posixGroup)
>  ...
>
> Or, should i be creating the two separate entries, but using the
> combined filter range (i.e.
> (|(objectclass=posixAccount)(objectclass=posixGroup)) ), as you indicate
> below ?
>
You do want two separate config entries.  One of them needs to be like 
your "cn=UID" example above.  You have a choice with the second config 
entry for groups.  You can either have one range of GID values for user 
private groups (the gidNumber attribute in posixAccount entries) and a 
separate range of GID values to be used for posixGroup entries, OR you 
can have a single range of GID values that spans across both 
posixAccount and posixGroup entries.

For the former, you would actually have 3 separate config entries.  They 
would look like your above "cn=UID" and "cn=GID" examples with the third 
entry assigning a separate range of "gidNumber" values with a filter of 
"(objectclass=posixAccount)".  Just be sure to make the range of values 
for both gidNumbers different.  You would do this by putting a cap on 
the range with the dnaMaxValue setting and setting dnaNextValue 
appropriately.

For making a range of gidNumber values span across posixAccount and 
posixGroup entries, replace the filter in your above "cn=GID" example 
with "(|(objectclass=posixAccount)(objectclass=posixGroup))".
>
>> If you don't care if your gidNumber user private groups match the user's
>> uidNumber, you can just create a single gidNumber range with a filter of
>> "(|(objectclass=posixAccount)(objectclass=posixGroup))" to have your
>> range span your user and group entries.
>>  
> Is that not what i attempted to do (and what is outlined in the spec
> doc) ? :
>
>   >>  # cat dna_conf
>   >>  dn: cn=UID and GID numbers,cn=Distributed Numeric Assignment
>   >>  Plugin,cn=plugins,cn=config
>   >>  objectClass: top
>   >>  objectClass: extensibleObject
>   >>  cn: UID and GID numbers
>   >>  dnatype: uidNumber
>   >>  dnaType: gidNumber
>   >>  dnamagicregen: 9
>   >>  dnafilter: (|(objectclass=posixAccount)(objectclass=posixGroup))
>   >>  dnascope: dc=example,dc=com
>   >>  dnanextvalue: 1000
>
> Note the dnafilter line, which contains the range you specified above.
>
Yes, but the multiple dnaType settings are the problem here.  The DNA 
plugin does not support this, so the second value (gidNumber) is not 
loaded.  What I was describing would be the above example with the 
"dnaType: uidNumber" value  removed.  This would span a range of 
gidNumber values across both posixAccount and posixGroup entries.  You 
would still need a separate range configured for uidNumber values in 
posixAccount entries.
> In any case, thanks for your commentary and input on this topic thus
> far.  In our environment, the DNA plugin is the « killer app » that we
> needed in order to get a Directory Server deployment going. :)
>
>
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] magic numbers (DNA) : console issues & gid assignment problem

[Nathan Kinder]

On 04/16/2010 03:42 AM, Daniel Maher wrote:
> On 04/15/2010 05:02 PM, Nathan Kinder wrote:
>
>
>> That's why you need to set a magic value in the DNA config and use them
>> in the Console.  For example, you could configure the value "1" to be a
>> magic value for your uidNumber and gidNumber DNA ranges.  If you then
>> add a user in Console with the value of "1" for the uidNumber and
>> gidNumber fields, DNA will generate new values from the ranges and
>> overwrite the values of "1" you specified with the generated values.
>>  
>>> In other words, via the console, there is no way to have DNA generate
>>> the uidNumber and gidNumber values when creating a new user.
>>>
>>>
>> There is a way if you use magic values.
>>  
> So there is !  Unfortunately, i have encountered further issues related
> to the DNA plugin, and in particular to console interactions with said.
>
>
> Following this reference document :
> http://directory.fedoraproject.org/wiki/DNA_Plugin
>
> The document states :
>
> dnaMagicRegen - [...] It also is not required to be a numeric value, so
> you can use anything you want. [...]
>
> This may certainly be true ; however, since the console demands a
> numeric value for the uidNumber and gidNumber fields, using a
> non-numeric value as a magic number identifier will make it impossible
> to create users via the console.
>
> Furthermore, once the user has been created (assuming numeric values
> were used), if you open the user entry in the console directly after
> creating it, the magic number will be listed instead of the actual uid
> and gid values.  Completely re-starting the console « fixes » this (does
> the console use a cache ?).  It's a minor irritation, but it could cause
> mistakes to be made.
>
Agreed.  File a bug/enhancement request  against the 389-ds-console 
component.  I think we want Console to only allow numeric values to be 
used since many people don't use DNA and we want to prevent mistakes, 
but the caching thing can indeed cause confusion.
>
> Moving on, the example configuration for activating basic DNA
> functionality states :
>
> [...] the uidNumber and gidNumber (primary group) attributes to be
> assigned by DNA, but you also want them to be the same value. In
> addition, you want DNA to assign the gidNumber attribute from the same
> range [...]
>
> Sounds perfect ; however, while the expected behaviour is a (magically)
> generated value for both the uid and gid, the actual result is that only
> the uid is magically assigned.  Consider the following :
>
> # cat dna_conf
> dn: cn=UID and GID numbers,cn=Distributed Numeric Assignment
> Plugin,cn=plugins,cn=config
> objectClass: top
> objectClass: extensibleObject
> cn: UID and GID numbers
> dnatype: uidNumber
> dnaType: gidNumber
> dnamagicregen: 9
> dnafilter: (|(objectclass=posixAccount)(objectclass=posixGroup))
> dnascope: dc=example,dc=com
> dnanextvalue: 1000
>
> # /usr/lib64/mozldap/ldapmodify -v -a -D "cn=Directory Manager" -w
> managerpass -h localhost -f dna_conf
>  ...
> adding new entry cn=UID and GID numbers,cn=Distributed Numeric
> Assignment Plugin,cn=plugins,cn=config
> modify complete
>
>
> # cat add_user
> dn: uid=testuser,ou=People, dc=example,dc=com
> changetype: add
> givenName: test
> sn: user
> uidNumber: 9
> gidNumber: 9
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetorgperson
> objectClass: posixAccount
> uid: testuser
> cn: test user
> homeDirectory: /home/testuser
> userPassword: {clear}testpass
> loginShell: /bin/bash
>
> # /usr/lib64/mozldap/ldapmodify -v -a -D "cn=Directory Manager" -w
> managerpass -h localhost -f add_user
>  ...
> adding new entry uid=testuser,ou=People, dc=example,dc=com
> modify complete
>
>
> # /usr/lib64/mozldap/ldapsearch -h localhost -b 'dc=france-ix,dc=net'
> 'uid=testuser' | egrep "(gidNumber|uidNumber)"
> gidNumber: 9
> uidNumber: 1000
>
>
> This behaviour occurs (unsurprisingly) for users added via the console
> as well.
>
The document you are using off of the wiki is an feature design document 
that was used while developing DNA.  Not everything mentioned in there 
is in the plug-in.  The ability to use multiple dnaType attributes in 
the same range is one of these things that is not implemented at this time.

You can set up two separate ranges, one for the uidNumber attribute and 
another for the gidNumber attribute.  While this doesn't guarantee that 
uidNumber == gidNumber for a user, the 

Re: [389-users] DNA plugin woes on a fresh centos-DS 8.1 install (now with a disastrous crash condition!)

[Nathan Kinder]

On 04/15/2010 12:43 AM, Daniel Maher wrote:
> On 04/14/2010 08:25 PM, Nathan Kinder wrote:
>
>
>>>> When i use the console to add a new user, it expects there to be a value
>>>> in three fields : UID Number, GID Number, and Home Directory.  The
>>>> console will not create the entry if those fields are empty.  If i
>>>>
>>>>  
>>> This raises another question : if the fields are mandatory in the
>>> console, will the DNA plug-in accept the values as entered, or will it
>>> generate new values and overwrite those specified in the console ?
>>>
>>>
>> DNA does not prevent you setting a specific value.  It will only
>> generate a value if you omit the attribute or set it to the magic value
>> that you configured.  If you set the magic value in console, it will be
>> overwritten with the DNA generated value.  I don't recall if Console
>> considers the uidNumber and gidNumber fields to be mandatory or not (the
>> schema does, but DNA runs before the schema check occurs on the server
>> side).  The magic value can be used if Console requires a value to be set.
>>  
> As i mentioned previously, the console requires there to be values in
> the uidNumber and gidNumber fields.  If there are no values, clicking «
> OK » generates an error message, and thus the entry is never created.
> If you add values, then DNA is irrelevant since you've manually entered
> said numbers.
>
That's why you need to set a magic value in the DNA config and use them 
in the Console.  For example, you could configure the value "1" to be a 
magic value for your uidNumber and gidNumber DNA ranges.  If you then 
add a user in Console with the value of "1" for the uidNumber and 
gidNumber fields, DNA will generate new values from the ranges and 
overwrite the values of "1" you specified with the generated values.
> In other words, via the console, there is no way to have DNA generate
> the uidNumber and gidNumber values when creating a new user.
>
There is a way if you use magic values.
>
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] DNA plugin woes on a fresh centos-DS 8.1 install (now with a disastrous crash condition!)

[Nathan Kinder]

On 04/14/2010 04:10 AM, Daniel Maher wrote:
> On 04/14/2010 11:45 AM, Daniel Maher wrote:
>
>
>> At ~ 09:28, i attempted to add the user entry as described above.  At ~
>> 09:29 i manually restarted the dirsrv service.  As you can see, there
>> are no long entries related to the interaction or the crash.  The access
>> log is silent on this event as well.
>>  
> I hit « reply » too soon.  This is the related log entry in
> /var/log/messages :
>
> Apr 14 09:28:46 host-119 kernel: ns-slapd[8763]: segfault at
>  rip 0036266796f0 rsp 507dfc08 error 4
>
Please file a bug on this.  Provide all pertinent details, such as 
version of 389 and detailed steps of how to reproduce the crash.  Your 
DNA configuration would also be useful in case it is related to the problem.
>
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] DNA plugin woes on a fresh centos-DS 8.1 install (now with a disastrous crash condition!)

[Nathan Kinder]

On 04/14/2010 03:02 AM, Daniel Maher wrote:
> On 04/14/2010 11:45 AM, Daniel Maher wrote:
>
>
>> When i use the console to add a new user, it expects there to be a value
>> in three fields : UID Number, GID Number, and Home Directory.  The
>> console will not create the entry if those fields are empty.  If i
>>  
> This raises another question : if the fields are mandatory in the
> console, will the DNA plug-in accept the values as entered, or will it
> generate new values and overwrite those specified in the console ?
>
DNA does not prevent you setting a specific value.  It will only 
generate a value if you omit the attribute or set it to the magic value 
that you configured.  If you set the magic value in console, it will be 
overwritten with the DNA generated value.  I don't recall if Console 
considers the uidNumber and gidNumber fields to be mandatory or not (the 
schema does, but DNA runs before the schema check occurs on the server 
side).  The magic value can be used if Console requires a value to be set.
> If it's the former, how then can the DNA plug-in be used at all ?  If
> it's the latter, is it still possible to manually specify values if the
> need arises ?
>
The above paragraph should answer all of these questions.
> (This, of course, is assuming slapd doesn't crash outright. ;) )
>
>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] DNA plugin woes on a fresh centos-DS 8.1 install

[Nathan Kinder]

On 04/13/2010 08:21 AM, Daniel Maher wrote:
> Hello,
>
> First off, my apologies if this is not an appropriate forum for asking
> questions related to the CentOS Directory Server.  The 389-users
> archives contain numerous messages related to this platform, so...
>
> The situation : fresh install of CentOS 5.4 x86_64, installed the DS via
> yum from the standard repos :
> # yum install centos-ds centos-ds-base nss_ldap
>
> The DS is up and running.  I can create groups and users, run queries,
> and so forth.  I followed the following procedure to enable the DNA plugin :
>
> Main menu of Directory Server
> TAB: Servers and Applications
>   ->->  Server Group ->  Directory Server
> TAB: Configuration
>   ->  Plug-ins ->  Distributed Numeric Assignment
> [X] Enable plug-in
> Save
>
> I then dutifully restarted DS afterwards.
>
> Finally, in the user creation menu, in the Posix User section, i checked
> Enable Posix User Attributes, but none of the fields were auto-populated.
>
> Initially, i tried adding the following ldif (i realise this is for the
> Fedora DNS, but hey, i thought it'd be worth a shot) :
> http://cvs.fedoraproject.org/viewvc/ldapserver/ldap/servers/plugins/dna/posix.ldif?view=co&root=dirsec
>
> Unsurprisingly (?), this did not work :
> ldap_add: DSA is unwilling to perform
> ldap_add: additional info: Not a valid DNA configuration entry.
>
> I read through a number of items on the subject, including the following
> notable items :
> http://www.directory.fedora.redhat.com/wiki/DNA_Plugin
> http://www.redhat.com/docs/manuals/dir-server/8.1/admin/dna.html
>
> In section 3.6.3.1 of the Red Hat document it outlines the steps to
> activate the plug-in.  Steps 1 and 2 appear to have already been
> executed by the graphical manager, as the necessary changes are present
> in the configuration file :
> /etc/dirsrv//dse.ldif
>
> I attempted to perform step 3 (with appropriate modifications to the
> dc's).  This did not work :
> adding new entry cn=Account UIDs,cn=Distributed Numeric Assignment
> Plugin,cn=plugins,cn=config
> ldap_add: DSA is unwilling to perform
> ldap_add: additional info: Not a valid DNA configuration entry.
>
> (It may be worth noting that the screenshot they include at the base of
> that page bears absolutely no resemblance to that of the actual plugin.)
>
> My questions are :
> 1. Is the expected behaviour of the DNA plug-in to auto-populate the
> Posix fields ?
>
The DNA plugin is designed to auto-populate unique numeric values, which 
can be used for the uidNumber and gidNumber attributes.  These fields 
will not be auto-populated in the Console when you are adding an entry.  
The Console application is not aware of DNA.  When you attempt to add a 
new user and click on the posix tab, you are simply building the entry 
that you want to add.  The Console then attempts to add this entry when 
you click OK.  The DNA plug-in does not create the values until the add 
is received, so you will not see these fields auto-fill in Console.  
Assuming that you are trying to have DNA generate the uidNumber values, 
you can either leave the uidNumber field blank when adding a user in 
Console, or set it to the magic value you configure for your DNA range.
> 2a. If so, how can i properly activate this functionality ?
>
It looks like you never successfully added a DNA configuration entry.  
You enabled the plug-in, but a configuration entry is necessary for DNA 
to know what you want it to do.

The config entry that you tried to add from step 3 in the documentation 
has a number of attributes related to auto-transfer of ranges between 
masters, which you may or may not want.  Are you using multi-master 
replication, and if so, do you need to automatically transfer ranges 
between the masters?  My guess is that your the entry specified by the 
dnaSharedCfgDN attribute does not exist, as Console does not create this 
automatically for you.  If a shared config DN is specified and it does 
not exist, the DNA config entry validation code will consider the config 
to be invalid.

An alternative is to just manually assign a separate range to each 
master and not worry about range transfer if you don't see yourself 
exhausting any of the ranges.  For a single master setup, you would just 
want to use a config entry like this:

dn: cn=Account UIDs,cn=Distributed Numeric Assignment 
Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: Account UIDs
dnatype: uidNumber
dnafilter: (objectclass=posixAccount)
dnascope: ou=people, dc=example,dc=com
dnaNextValue: 501

You would want to add a dnaMaxValue attribute to specify an end of the 
range if using multi-master replication.  You would then specify a 
different range on each other master by setting dnaNextValue and 
dnaMaxValue appropriately
> 2b. If not, does this functionality exist ?  And as a corollary, what is
> the DNA plug-in for, exactly ?
> 3. Should i, in fact, be attempting to use the Fedora DS offering
> inst

Re: [389-users] The same error but with the 389-console

[Nathan Kinder]

On 02/08/2010 01:05 AM, serge.ste...@fmsb.be wrote:
Error adding object 'dn: cn=celem2,ou=machines,dc=fmsb,dc=be'.  The 
error sent by the server was 'Invalid syntax. description: value #0 
invalid per syntax
'.  The object is: LDAPEntry: cn=celem2,ou=machines,dc=fmsb,dc=be; 
LDAPAttributeSet: LDAPAttribute {type='description', values=''} 
LDAPAttribute {type='objectclass', values='ieee802Device,person,top'} 
LDAPAttribute {type='macaddress', values='0013d3daff55'} LDAPAttribute 
{type='sn', values='SERVERS'} LDAPAttribute {type='cn', values='celem2'}.


When description value is set to '' 389 refused to insert the entry , 
tivoli don't refuse ? what can i do to relax the syntax ?
You can turn off syntax checking by setting nsslapd-schemacheck to "off" 
in the "cn=config" entry.


A " character is legal per the Directory String syntax (which is the 
syntax used for the description attribute).  I expect that you may have 
an escaping issue.

Serge Sterck
Chef de service informatique adjoint
Tel : (02) 506.97.15
Email: serge.ste...@fmsb.be serge.ste...@gmail.com
//

/
«Ceci est un courrier électronique à caractère professionnel. Le 
présent message comporte une information confidentielle à l'attention 
exclusive de la personne ou de l'entité à qui il est adressé ainsi que 
des autres destinataires autorisés à le recevoir. Si vous n'êtes pas 
le destinataire désigné ou autorisé, il vous est signifié que toute 
divulgation, copie, distribution ou utilisation de cette information 
est strictement interdite et peut être illégale. L'expéditeur ne peut 
être tenu pour responsable en cas de transmission incorrecte ou 
incomplète de l'information contenue dans le message ou en cas de 
retard dans sa réception. Nous déclinons toute responsabilité pour 
toute perte ou dommage causé par des virus.»


«Dit is een professionele e-mail. De informatie in dit bericht is 
vertrouwelijk en uitsluitend bestemd voor de persoon of entiteit aan 
wie het bericht is verzonden en anderen die gerechtigd zijn dit 
bericht te ontvangen. Indien u niet de geadresseerde of een 
gerechtigde bent, wordt u hierbij op gewezen dat het openbaar maken, 
kopiëren, verspreiden of gebruik maken ervan, verboden is en illegaal 
kan zijn. De verzender kan niet aansprakelijk worden geacht voor een 
onjuiste of onvolledige overbrenging van de inhoud van dit verzonden 
bericht, noch voor niet tijdige ontvangst ervan. We wijzen elke 
aansprakelijkheid af voor elk verlies of schade door software virussen 
veroorzaakt.»

/

/
///


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Distributed Numeric Assignment (DNA) Plugin Fails At 13003

[Nathan Kinder]

On 01/14/2010 02:00 AM, Fazli wrote:

Hi,

I'm currently making use of the DNA plugin to assign unique values for 
the 'uidNumber' attribute for new POSIX users, which (from what I 
understand) is the 'ideal' configuration in a large, corporate 
environment.


I decided to run a stress test by adding about twenty thousand users 
via the ldapadd command. After about the 3995th user, the server 
returned the following error for the 3996th:


adding new entry "uid=test3996,ou=People,dc=example,dc=com
ldapadd: Operation error (1)
additional info: Allocation of a new value for uidNumber failed! 
Unable to proceed.


I attempted to add the 3996th user myself through the 389 DS 
Management Console, and it returned the following error:


Cannot save to directory server:
netscape.ldap.LDAPException: error result (1); Allocation of a new 
value for uidNumber failed! Unable to proceed.; Operations error
You need to index the uidNumber attribute.  The DNA plug-in does an 
internal search using the server-side sort control to check if the next 
supposed free value has already been used.  This requires the attribute 
to be indexed for it to work properly once you pass a threshold number 
of matches (the nsslapd-idlistscanlimit setting, which is 4000 by 
default).  Since the values being sorted are integers, you should also 
be using the integerOrdering match matching rule when you define the index.


Here's an example of the index configuration entry that you would need:

dn: cn=uidnumber,cn=index,cn=userRoot,cn=ldbm database,cn=config
objectclass: top
objectclass: nsIndex
cn: uidnumber
nsSystemIndex: false
nsIndexType: eq
nsMatchingRule: integerOrderingMatch

Please see this chapter from the Red Hat Directory Server Administration 
Guide for details about creating indexes:


http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Indexes.html


These are my current DNA settings:

dn: cn=Account UIDs,cn=Distributed Numeric Assignment 
Plugin,cn=plugins,cn=config

cn: Account UIDs
dnafilter: (objectClass=posixAccount)
dnamagicregen: 0
dnamaxvalue: -1
dnanextvalue: 13003
dnarangerequesttimeout: 60
dnascope: dc=nsn,dc=com,dc=sg
dnasharedcfgdn: cn=Account UIDs,ou=Ranges,dc=nsn,dc=com,dc=sg
dnathreshold: 1
dnatype: uidNumber
objectClass: top
objectClass: extensibleObject

I find that if I delete the 3995th user, and set the 'dnanextvalue' 
attribute of the DNA configuration entry to '13002', the plugin 
doesn't throw the above exception. It just doesn't seem to be able to 
assign the 13003th uidNumber.


I've also tried restarting the server, as well as updating the 
libraries from the repositories, with the same results.


I'm running 389 DS on CentOS, kernel version 2.6.18-164.6.1.el5, if it 
helps.


Regards,
Fazli


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Auto-Increment of UserID in 389 Server?

[Nathan Kinder]

On 01/13/2010 10:19 AM, Ajeet S Raina wrote:

Andrey,
I read the link of DNA plugin but have no idea how to implement that. 
Can you please help with the steps or any tutorial hint for the same.

I appreciate your responsive help as I am not a good programmer.
You don't  need to do any programming.  The plug-in has already been 
implemented.  The page that Thorsten linked to has examples of the 
configuration entries needed to use the DNA plug-in.


-NGK

Ajeet

2010/1/13 Thorsten Scherf mailto:tsch...@redhat.com>>

On [Wed, 13.01.2010 17:19], Andrey Ivanov wrote:

as far as i know, no, it is not possible to have that
functionality
through the management console. It is one of the features
people ask
of. If you are a java programmer you could help with it :)


http://www.directory.fedora.redhat.com/wiki/DNA_Plugin

2010/1/13 Ajeet S Raina mailto:ajeetra...@gmail.com>>:

Andrey..So Nice of you for letting me know thats too
people have worked out
with:

I read the page but wonder if it can be done through
Management Console.
May I know what steps I need to follow.

Your help would be appreciated.

On Wed, Jan 13, 2010 at 2:16 AM, Andrey Ivanov
mailto:andrey.iva...@polytechnique.fr>> wrote:


Hi,

Take a look at the DNA plugin :
http://www.directory.fedora.redhat.com/wiki/DNA_Plugin

2010/1/12 Ajeet S Raina mailto:ajeetra...@gmail.com>>:
> Is it possible to auto-Increment UserID whenever a
new user is created
> rather than manually adding UserID?
>
>
> --
> 389 users mailing list
> 389-us...@lists.fedoraproject.org

>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
--
389 users mailing list
389-us...@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users




--


”It is not possible to rescue everyone who is caught in
the Windows
quicksand
  --Make sure you are on solid Linux ground before
trying.”



--
389 users mailing list
389-us...@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-us...@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-us...@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users




--


”It is not possible to rescue everyone who is caught in the Windows 
quicksand

  --Make sure you are on solid Linux ground before trying.”



--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
   


--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users