Object Class Problem
by Jose Manuel Lopez
Hi,
I had extract ldif file from openldap-2.0.27. When I try charge ldif
into openldap-2.2.23 I obtain error: no structural object class provided.
Have you any idea about it? I am using the same schema of 2.0.27.
Thank You.
16 years, 11 months
slapd replication fails
by chechu chechu
hi¡¡
I can't get the replication in the slave server...I did "slapcat -v -l
LDAP-transfer-LDIF.txt" in the master and "slapadd -v -l
LDAP-transfer-LDIF.txt" in the slave, i started the master and later de
slave server...i added an user in the master but it didn't replicate it
to slave. I started from the begining and i did the same and "scp
-r /var/lib/ldap slave_server:/var/lib" and it fail again...i don know
what to do..., my conf files are:
slapd.conf from master:
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.
#######################################################################
# Global Directives:
# Features to permit
#allow bind_v2
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/samba.schema
#include /etc/ldap/schema/autofs.schema
#include /etc/ldap/schema/krb5-kdc.schema
#include /etc/ldap/schema/unixtng.schema
#include /etc/ldap/schema/krb5-kdc.schema
# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck on
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid
# List of arguments that were passed to the server
argsfile /var/run/slapd.args
# Read slapd.conf(5) for possible values
loglevel 0
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_ldbm
sasl-realm IRONMAN.ES
sasl-host shogun.ironman.es
#################TLS/SSL####################
# Certificado firmado de una entidad certificadora y
# el certificado del servidor
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile /etc/ldap/ssl/server.pem
TLSCertificateFile /etc/ldap/ssl/server.pem
TLSCertificateKeyFile /etc/ldap/ssl/server.pem
# Si desea que el cliente necesite autentificaci�,
# descomente la siguiente l�ea
#TLSVerifyClient demand
# ... si no, descomente esta otra
TLSVerifyClient never
#######################################################################
# Specific Backend Directives for ldbm:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend ldbm
#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend <other>
#######################################################################
# Specific Directives for database #1, of type ldbm:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database ldbm
# The base of your directory in database #1
suffix "dc=ironman,dc=es"
rootdn "cn=admin,dc=ironman,dc=es"
rootpw secret
#########REPLICA#############
replica host=shinobi.ironman.es:389
#replica uri=ldap://shinobi.ironman.es:636
binddn="cn=replicauser,dc=ironman,dc=es"
bindmethod=simple
credentials=replica
replogfile /var/lib/ldap/openldap-master-replog
##############################
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"
# Indexing options for database #1
# Requerido por OpenLDAP
index objectclass eq
index default sub
index cn pres,sub,eq
index sn pres,sub,eq
# Requerido para soportar pdb_getsampwnam
index uid pres,sub,eq
# Requerido para soportar pdb_getsambapwrid()
index displayName pres,sub,eq
# Descomente las siguientes l�eas si est�almacenando entradas
# posixAccount y posixGroup en el directorio
index uidNumber eq
index gidNumber eq
index memberUid eq
# Samba 3.*
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
# Include the access lists
include /etc/ldap/slapd.access
# Save the time that the entry gets modified, for database #1
lastmod on
# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
#access to attrs=userPassword
# by dn="cn=admin,dc=ironman,dc=es" write
# by anonymous auth
# by self write
# by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
#access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
#access to *
# by dn="cn=admin,dc=ironman,dc=es" write
# by * read
# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
# by dn="cn=admin,dc=ironman,dc=es" write
# by dnattr=owner write
#######################################################################
# Specific Directives for database #2, of type 'other' (can be ldbm
too):
# Database specific directives apply to this databasse until another
# 'database' directive occurs
#database <other>
# The base of your directory for database #2
#suffix "dc=debian,dc=org"
slapd.conf from slave:
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.
#######################################################################
# Global Directives:
# Features to permit
#allow bind_v2
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/samba.schema
#include /etc/ldap/schema/autofs.schema
#include /etc/ldap/schema/krb5-kdc.schema
#include /etc/ldap/schema/unixtng.schema
#include /etc/ldap/schema/krb5-kdc.schema
# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck on
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid
# List of arguments that were passed to the server
argsfile /var/run/slapd.args
# Read slapd.conf(5) for possible values
loglevel 0
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_ldbm
sasl-realm IRONMAN.ES
sasl-host shogun.ironman.es
#################TLS/SSL####################
# Certificado firmado de una entidad certificadora y
# el certificado del servidor
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile /etc/ldap/ssl/server.pem
TLSCertificateFile /etc/ldap/ssl/server.pem
TLSCertificateKeyFile /etc/ldap/ssl/server.pem
# Si desea que el cliente necesite autentificaci�,
# descomente la siguiente l�ea
#TLSVerifyClient demand
# ... si no, descomente esta otra
TLSVerifyClient never
#######################################################################
# Specific Backend Directives for ldbm:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend ldbm
#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend <other>
#######################################################################
# Specific Directives for database #1, of type ldbm:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database ldbm
# The base of your directory in database #1
suffix "dc=ironman,dc=es"
rootdn "cn=admin,dc=ironman,dc=es"
rootpw secret
#########REPLICA#############
updatedn "cn=replicauser,dc=ironman,dc=es"
updateref ldap://shogun.ironman.es:389
##############################
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"
# Indexing options for database #1
# Requerido por OpenLDAP
index objectclass eq
index default sub
index cn pres,sub,eq
index sn pres,sub,eq
# Requerido para soportar pdb_getsampwnam
index uid pres,sub,eq
# Requerido para soportar pdb_getsambapwrid()
index displayName pres,sub,eq
# Descomente las siguientes l�eas si est�almacenando entradas
# posixAccount y posixGroup en el directorio
index uidNumber eq
index gidNumber eq
index memberUid eq
# Samba 3.*
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
# Include the access lists
include /etc/ldap/slapd.access
# Save the time that the entry gets modified, for database #1
lastmod on
# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
#access to attrs=userPassword
# by dn="cn=admin,dc=ironman,dc=es" write
# by anonymous auth
# by self write
# by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
#access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
#access to *
# by dn="cn=admin,dc=ironman,dc=es" write
# by * read
# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
# by dn="cn=admin,dc=ironman,dc=es" write
# by dnattr=owner write
#######################################################################
# Specific Directives for database #2, of type 'other' (can be ldbm
too):
# Database specific directives apply to this databasse until another
# 'database' directive occurs
#database <other>
# The base of your directory for database #2
#suffix "dc=debian,dc=org"
slapd.access access list:
access to * by * write
# These access lines apply to database #1 only
access to attrs=userPassword
by dn="cn=admin,dc=atc,dc=unican,dc=es" write
by anonymous auth
by self write
by * none
# allow the "ldap admin dn" access, but deny everyone else
# (Samba related)
access to attrs=sambaLMPassword,sambaNTPassword
by dn="cn=admin,dc=ironman,dc=es" write
by self write
by * auth
by * none
# For Netscape Roaming support, each user gets a roaming profile for
# which they have write access to
#access to dn=".*,ou=Roaming,dc=.*"
# by dn="<YOUR ADMIN DN>" write
# by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
# by dnattr=owner write
# by * none
# Some things should be editable by the owner, and viewable by anyone...
#access to attrs=cn,givenName,sn,krbName,krb5PrincipalName,gecos
# by dn="cn=admin,dc=ironman,dc=es" write
# by dn="uid=ldapadm.+\+realm=IRONMAN.ES" write
# by self write
# by users read
#access to attrs=loginShell,gecos
# by dn="cn=admin,dc=ironman,dc=es" write
# by dn="uid=ldapadm.+\+realm=IRONMAN.ES" write
# by self write
# by * read
# Since we're using {KERBEROS}<PRINCIPAL>, we can't allow the user
# to change the password. They have to use the Kerberos 'kpasswd' to
# do this... But the admin can change (if need be).
# Please see krb5 userPassword attribute
#access to attrs=userPassword
# by dn="cn=admin,dc=ironman,dc=es" write
# by dn="uid=ldapadm.+\+realm=IRONMAN.ES" write
# by anonymous auth
# by * none
# The mail and mailAlternateAddress should only be readable if you
# authenticate!
#access to attrs=mail,mailAlternateAddress,mailHost
# by dn="<YOUR ADMIN DN>" write
# by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
# by users read
# by * none
# Should not be readable to anyone, and only editable by admin...
#access to attr=mailQuota,trustModel,accessTo
# by dn="<YOUR ADMIN DN>" write
# by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
# by self read
# by * none
# The admin dn has full write access
#access to *
# by dn="cn=admin,dc=ironman,dc=es" write
# by dn="uid=ldapadm.+\+realm=IRONMAN.ES" write
# by * read
access to dn.base=""
by * read
access to dn.base="cn=monitor"
by * read
access to *
by dn.base="cn=replicauser,dc=ironman,dc=es" write
by * break
16 years, 11 months
Install CA Certificate
by Aaron Smith
Where do I need to put a CA certificate so that Openldap can find it
properly? I have openldap version 2.3.27 that was compiled using
openssl support on a Solaris 10 machine. Trying to do secure LDAP
transactions with ldapsearch results in
SSL initialization failed: error -8192 (An I/O error occurred during
security authorization.)
Trying to do raw ssl connects (using openssl s_client -connect) fail
saying it can't find the local issuer certificate, but if I include the
-Cafile option to tell it exactly where the CA cert is, then it works
fine. My ldap.conf has the following entries, and I have double and
triple checked the paths and file names:
TLS_REQCERT never
TLS_CACERT /etc/sfw/openssl/certs/cacert.pem
TLS_CACERTDIR /etc/sfw/openssl/certs
--------------------------------------------------------------------
Aaron Smith Aaron.Smith(a)kzoo.edu
System Administrator (269) 337-7496
Kalamazoo College
16 years, 11 months
Data fragmentation- fixes?
by matthew sporleder
I have a unique situation relating to my conversion from 2.1 to 2.3.
What I did:
slapcat -c -f 2.1.slapd.conf
remove entryCSN
slapadd -c -q -f 2.3.slapd.conf
This worked well, but I got a few errors about duplicate data. It
turns out that my 2.1 database had multiple entries of some
near-the-top data.
ex:
dn: dc=com
dc: com
objectClass: dcObject
objectClass: organization
o: Example Org
structuralObjectClass: organization
entryUUID: 0ac313d0-4aba-1099-9dd8-f266f9337e15
creatorsName: cn=Manager,dc=example,dc=com
modifiersName: cn=Manager,dc=example,dc=com
createTimestamp: 20030720064923Z
modifyTimestamp: 20030720064923Z
<100 lines later>
dn: ou=SITE1,ou=people,dc=example,dc=com
ou: SITE1
objectClass: top
objectClass: organizationalunit
structuralObjectClass: organizationalunit
entryUUID: 80a3eee6-2c61-1028-8468-973a8421431b
creatorsName: cn=Manager,dc=example,dc=com
createTimestamp: 20040427064022Z
modifiersName: cn=Manager,dc=example,dc=com
modifyTimestamp: 20040427064022Z
<millions of lines later>
dn: ou=SITE1,ou=people,dc=example,dc=com
ou: SITE1
objectClass: top
objectClass: organizationalunit
structuralObjectClass: organizationalunit
entryUUID: c41ed3f6-2c62-1028-8418-82cea5fe7b2c
creatorsName: cn=Manager,dc=example,dc=com
createTimestamp: 20040427064925Z
modifiersName: cn=Manager,dc=example,dc=com
modifyTimestamp: 20040427064925Z
dn: cn=someuser,ou=SITE1,ou=people,dc=exmaple,dc=com
etc: bar
dn: cn=someotheruser,ou=SITE1,ou=people,dc=exmaple,dc=com
etc: foo
Now, during my slapadd, the FIRST definition of SITE1 was added, but
it's really far away from all of its data. (the second one gave an
error, so at least we have more correct data) The rest of my SITEn's
are really close to their data, so searches based in
ou=SITEn,ou=people,dc=exmaple,dc=com for objectclass=* return very
quickly with top-level info and everything under it. For SITE1,
however, there's a -long- gap.
I tried to reindex, and now I can find the top-level definition
quickly, but the rest of the data is still slow to find (it appears to
be searching for everything). Is there a way to get the data
re-ordered so it's closer to where its children without slapcat,
reorder manually, and slapadd? (would that even work?)
(By the way, this only hurts searches like the one described above,
looking for actual people works the same throughout the dataset.)
16 years, 11 months
slapd-relay and slapo-rwm questions
by Quanah Gibson-Mount
So, I've been playing with slapo-relay and slapd-rwm to try and make it so
that I can meet the expectations of different email clients that query my
directory. This has led to a few questions:
(1) If your root is "dc=example,dc=com", and the entries you are interested
in rewriting are in "cn=people,dc=example,dc=com" and the suffix you want
to use virtually is "cn=outlook,dc=example,dc=com", how do you configure
this? My attempts at doing this gave me the following error:
<suffix> namingContext "cn=outlook,dc=example,dc=com" already served by a
preceding hdb database serving namingContext "dc=example,dc=com"
I understand quite well that "cn=outlook,dc=example,dc=com" is served by
dc=stanford,dc=edu, and so what? It doesn't actually exist in that
database, and I want to make it appear to exist.
(2) How do you get it to map the entry DN results to the new base? With
"cn=people,dc=stanford,dc=edu" being mapped to
"cn=outlook,dc=example,dc=com", the entries DNs returned all show
"cn=people,dc=stanford,dc=edu" instead of "cn=outlook,dc=example,dc=com":
ldapsearch -LLL -x -h ldap-dev1 -b "cn=outlook,dc=example,dc=com"
"cn=quanah*"
dn: suRegID=85e49978f61311d2ae662436000baa77,cn=people,dc=stanford,dc=edu
(3) How do you map attributes to attribute names that don't exist in your
schema? Since this is really about what gets displayed back to the client,
I don't see why there is a requirement that the mapped-to attribute name
must exist in your schema.
For example:
map attribute displayName mail
works but
map attribute displayName display-name
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 11 months
ldap_add_ext_s and Error 17
by Wyatt Neal
greetings,
i've been trying to load a pkcs12 file stored in a character buffer into the
ldap server(2.3). i've made sure that i'm passing LDAP_MOD_BVALUES as well
as a LDAPMod stuct that contains the berval stuct with the binary pkcs12
data in it. i've read that i either have to do some combination of base64
encoding and utf8 encoding to the data before i can submit it (tried every
possible combo of plain, base64, and utf8 to no avail); however, ever time i
perform the actual ldap_add_ext_s, i receive an error 17 about inappropriate
characters in the attributes . looking throught the archives, this was
something that happend back in 2.0 and i guess indicated that the attribute
name(userPKCS12) was incorrect? i've been hamming on this for about four
days now and i've had no luck. can someone please tell me how i can stop
breaking this?
thanks,
wyatt
16 years, 11 months
ldapadd: peroblems with an very weird error (invalid format)
by Sergio Shevtsov
Hello. For evryone.
I try to mount my ldap directory. but i get an weird error. ldapadd: invalid format (line 2) entry: "dc=terminalquequen,dc=com,dc=ar"
i follow all rules on creation of ldif file, but my ldap fails.
i'm using debian sarge (stable) aptitude install by default ldap-2.2.23-8
may slapd.conf is
$ cat /etc/ldap/slapd.conf
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.
#######################################################################
# Global Directives:
# Features to permit
#allow bind_v2
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck on
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid
# List of arguments that were passed to the server
argsfile /var/run/slapd.args
# Read slapd.conf(5) for possible values
loglevel 0
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_bdb
#moduleload back_ldbm
#######################################################################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend bdb
checkpoint 512 30
##################################################
###### CONFIGURACION BD ELEVADOR
##################################################
##################################################
database bdb
directory /var/lib/ldap/agenda
suffix "ou=agenda,dc=terminalquequen,dc=com,dc=ar"
rootdn "cn=admin,ou=agenda,dc=terminalquequen,dc=com,dc=ar"
rootpw {SSHA}xxxxxxxxxxxxxxxxxx
lastmod on
index objectClass eq
index cn,sn,email eq,pres,sub
# a que/por quien/y como
access to *
by dn="cn=admin,ou=agenda,dc=terminalquequen,dc=com,dc=ar" write
by anonymous auth
by * read
##################################################
###### FIN CONFIGURACION ELEVADOR
##################################################
##################################################
#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend <other>
#######################################################################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database bdb
# The base of your directory in database #1
suffix "dc=terminalquequen,dc=com,dc=ar"
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"
# Indexing options for database #1
index objectClass eq
index mail,sn,cn,uid eq,sub,pres
# Save the time that the entry gets modified, for database #1
lastmod on
# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword
by dn="cn=admin,dc=terminalquequen,dc=com,dc=ar" write
by anonymous auth
by self write
by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=admin,dc=terminalquequen,dc=com,dc=ar" write
by * read
# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
# by dn="cn=admin,dc=terminalquequen,dc=com,dc=ar" write
# by dnattr=owner write
#######################################################################
# Specific Directives for database #2, of type 'other' (can be bdb too):
# Database specific directives apply to this databasse until another
# 'database' directive occurs
#database <other>
# The base of your directory for database #2
#suffix "dc=debian,dc=org"
MY LDIF file
$ cat inicio.ldif
dn: dc=terminalquequen,dc=com,dc=ar
objectClass top
objectClass dcObject
objectClass organization
dc: terminalquequen
o: TerminalQuequenSA
description: Elevador de granos
dn: ou=agenda,dc=terminalquequen,dc=com,dc=ar
objectClass organizationalUnit
ou: agenda
and i get a weird error executing this command
$ ldapadd -x -W -D "cn=admin,dc=terminalquequen,dc=com,dc=ar" -f inicio.ldif -d 2048
Enter LDAP Password:xxxxx
request 1 done
ldif_parse_line: missing ':' after
ldapadd: invalid format (line 2) entry: "dc=terminalquequen,dc=com,dc=ar"
$ ldapadd -x -W -D "cn=admin,dc=terminalquequen,dc=com,dc=ar" -f inicio.ldif -d 1
ldap_create
Enter LDAP Password: xxxxxx
ldap_bind_s
ldap_simple_bind_s
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:389
ldap_new_socket: 4
ldap_prepare_socket: 4
ldap_connect_to_host: Trying 127.0.0.1:389
ldap_connect_timeout: fd: 4 tm: -1 async: 0
ldap_ndelay_on: 4
ldap_is_sock_ready: 4
ldap_ndelay_off: 4
ldap_open_defconn: successful
ldap_send_server_request
ber_flush: 62 bytes to sd 4
ldap_result msgid 1
ldap_chkResponseList for msgid=1, all=1
ldap_chkResponseList returns NULL
wait4msg (infinite timeout), msgid 1
wait4msg continue, msgid 1, all 1
** Connections:
* host: localhost port: 389 (default)
refcnt: 2 status: Connected
last used: Tue Oct 10 20:52:46 2006
** Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
** Response Queue:
Empty
ldap_chkResponseList for msgid=1, all=1
ldap_chkResponseList returns NULL
ldap_int_select
read1msg: msgid 1, all 1
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
ldap_read: message type bind msgid 1, original id 1
ber_scanf fmt ({iaa) ber:
read1msg: 0 new referrals
read1msg: mark request completed, id = 1
request 1 done
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_free_connection
ldap_free_connection: refcnt 1
ldap_parse_result
ber_scanf fmt ({iaa) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldapadd: invalid format (line 2) entry: "dc=terminalquequen,dc=com,dc=ar"
ldap_free_connection
ldap_send_unbind
ber_flush: 7 bytes to sd 4
ldap_free_connection: actually freed
$ ldapadd -x -W -D "cn=admin,dc=terminalquequen,dc=com,dc=ar" -f inicio.ldif -d 2048 -S error
Enter LDAP Password:
request 1 done
ldif_parse_line: missing ':' after
ldapadd: invalid format (line 2) entry: "dc=terminalquequen,dc=com,dc=ar"
$ cat error
# Error: Bad parameter to an ldap routine (-9)
dn: dc=terminalquequen,dc=com,dc=ar
objectClass top
objectClass dcObject
objectClass organization
dc: terminalquequen
o: TerminalQuequenSA
description: Elevador de granos
Any help will apreciate. Thanks for you time.
---------------------------------
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
Probalo ya!
16 years, 11 months
RE: Problem in configuring SSL with openldap
by Aaron Richton
Please keep your replies on the mailing list.
Two examples of Solaris OpenSSL builds that linked with OpenLDAP can be
found at:
Quanah's OpenSSL build page at
http://www.stanford.edu/services/directory/openldap/configuration/openssl...
Rutgers OpenSSL spec file at
http://cvs.rutgers.edu/cgi-bin/viewcvs.cgi/*checkout*/SPECS/openssl.spec
I note that they both have the word "shared" in various places, which you
do not mention.
OpenSSL is not provided by the OpenLDAP Project; please direct further
discussion to a relevant OpenSSL list until you're sure that it built
correctly. You should come back to openldap-software if OpenLDAP autoconf
fails to recognize the (properly built and installed) libraries.
On Thu, 12 Oct 2006, Monica_Rana wrote:
> Hi Aaron,
>
> I had followed the below mentioned steps for installing openssl:
> 1. $ ./config
> 2. $ make
> 3. $ make test
> 4. $ make install.
>
> All the options ran without any errors.
> Do I need to do anything extra?
>
> In my /usr/local/ssl/lib/, libcrypto.so does not exist. The following
> file exists at the mentioned path
>
> # pwd
> /usr/local/ssl/lib
> # ls
> engines libcrypto.a libssl.a pkgconfig
>
>
> Regards,
> Monica Rana
>
> -----Original Message-----
> From: Aaron Richton [mailto:richton@nbcs.rutgers.edu]
> Sent: Thursday, October 12, 2006 4:59 PM
> To: Monica_Rana
> Cc: Phillip; openldap-software(a)openldap.org
> Subject: RE: Problem in configuring SSL with openldap
>
> I see that RSA stuff, but I'm not sure if that's as fatal as your
> failure to link in libdl on the previous attempt (:19590). Your build
> seems to be picking up a libcrypto.a; on my Solaris systems, ldd
> /usr/local/ssl/lib/libcrypto.so shows a dependency on libdl.so.1.
> Towards this end I'd:
>
> (a) make sure that openssl was compiled into shared objects, e.g.
> /usr/local/ssl/lib/libcrypto.so exists
> (b) make sure that it was compiled reasonably; at a minimum, that ldd
> /usr/local/ssl/lib/libcrypto.so comes out clean without any "file not
> found"
> (c) include RPATH in your LDFLAGS, e.g. "-L/usr/local/ssl/lib
> -R/usr/local/ssl/lib -L/usr/local/db4/lib -R/usr/local/db4/lib" instead.
>
> See if any or all of that helps...
>
> On Thu, 12 Oct 2006, Monica_Rana wrote:
>
>> Phillip,
>>
>> I have checked the include and lib path. But seeing at the config
>> logs, it seems that the problem is with RSAglue/rsaref. I am new to
>> openLDAP and openSSL. So am not able to actually decode the logs.
>>
>> Regards,
>> Monica Rana
>>
>> -----Original Message-----
>> From: Phillip [mailto:phuang@plasmon.cn]
>> Sent: Thursday, October 12, 2006 1:07 PM
>> To: Monica_Rana
>> Cc: openldap-software(a)openldap.org
>> Subject: Re: Problem in configuring SSL with openldap
>>
>> Monica,
>>
>> Maybe you've take a mistake in setting "env", just try:
>>
>> env CPPFLAGS="-I/usr/local/include -I/usr/local/ssl/include -
>> I/usr/local/db4/include" LDFLAGS="-L/usr/local/ssl/lib -
>> L/usr/local/db4/lib" ./configure --with-tls --with-cyrus-sasl
>> --enable- wrappers --enable-crypt --enable-bdb
>>
>> You'd better verify the "include" and "lib" path for SSL and DB.
>>
>> Regards,
>> Phillip
>>
>>
>>
>>
>>
>> On Thu, 2006-10-12 at 12:18 +0530, Monica_Rana wrote:
>>> Hi All,
>>>
>>> I have the following installed on solaris 8.
>>> openLDAP 2.3.27
>>> openSSL 0.9.8b.
>>>
>>> when i try to configure using the command env
>>> CPPFLAGS="-I/usr/local/include -I/usr/local/include/ssl -
>>> I/usr/local/include/db4"
>>> LDFLAGS="-L/usr/local/ssl/lib -L/usr/local/lib/db4"
>>> ./configure --with-tls --with-cyrus-sasl --enable-wrappers --
>>> enable-crypt --enable-bdb it throws the error checking for
>>> openssl/ssl.h... yes checking for SSL_library_init in -lssl... no
>>> checking for ssl3_accept in -lssl... no checking OpenSSL library
>>> version (CRL checking capability)... yes
>>> configure: error: Could not locate TLS/SSL package.
>>>
>>> Please let me know what could be the possible reson behind. PFA the
>>> config.log file.
>>>
>>> Regards,
>>> Monica Rana
>>> **************** CAUTION - Disclaimer ***************** This e-mail
>>> contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for
>>> the use of the addressee(s). If you are not the intended recipient,
>>> please notify the sender by e-mail and delete the original message.
>>> Further, you are not to copy, disclose, or distribute this e- mail or
>
>>> its contents to any other person and any such actions are unlawful.
>>> This e-mail may contain viruses. Infosys has taken every reasonable
>>> precaution to minimize this risk, but is not liable for any damage
>>> you
>>
>>> may sustain as a result of any virus in this e-mail. You should carry
>
>>> out your own virus checks before opening the e-mail or attachment.
>>> Infosys reserves the right to monitor and review the content of all
>>> messages sent to or from this e-mail address. Messages sent to or
>>> from
>>
>>> this e-mail address may be stored on the Infosys e- mail system.
>>> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>>>
>>
>>
>>
>
16 years, 11 months
RE: Problem in configuring SSL with openldap
by Monica_Rana
Hi Sameer,
I have followed the below mentioned steps:
1. $ ./config
2. $ make
3. $ make test
4. $ make install.
All the options ran without any errors.
Do I need to do anything extra?
Regards,
Monica Rana
-----Original Message-----
From: Sameer N Ingole [mailto:strike@proscrutiny.com]
Sent: Thursday, October 12, 2006 2:34 PM
To: openldap-software(a)openldap.org
Cc: Monica_Rana
Subject: Re: Problem in configuring SSL with openldap
Did you custom compile Openssl?
Did you install development libraries for Openssl?
I suspect absence of development libraries is causing this problem.
Also read http://www.columbia.edu/~ariel/ssleay/rsaref.html
Regards,
Sameer Ingole.
http://weblogic.noroot.org/gallery2/
Monica_Rana wrote:
> Phillip,
>
> I have checked the include and lib path. But seeing at the config
> logs, it seems that the problem is with RSAglue/rsaref. I am new to
> openLDAP and openSSL. So am not able to actually decode the logs.
>
> Regards,
> Monica Rana
>
> -----Original Message-----
> From: Phillip [mailto:phuang@plasmon.cn]
> Sent: Thursday, October 12, 2006 1:07 PM
> To: Monica_Rana
> Cc: openldap-software(a)openldap.org
> Subject: Re: Problem in configuring SSL with openldap
>
> Monica,
>
> Maybe you've take a mistake in setting "env", just try:
>
> env CPPFLAGS="-I/usr/local/include -I/usr/local/ssl/include -
> I/usr/local/db4/include" LDFLAGS="-L/usr/local/ssl/lib -
> L/usr/local/db4/lib" ./configure --with-tls --with-cyrus-sasl
> --enable- wrappers --enable-crypt --enable-bdb
>
> You'd better verify the "include" and "lib" path for SSL and DB.
>
> Regards,
> Phillip
>
>
>
>
>
> On Thu, 2006-10-12 at 12:18 +0530, Monica_Rana wrote:
>
>> Hi All,
>>
>> I have the following installed on solaris 8.
>> openLDAP 2.3.27
>> openSSL 0.9.8b.
>>
>> when i try to configure using the command env
>> CPPFLAGS="-I/usr/local/include -I/usr/local/include/ssl -
>> I/usr/local/include/db4"
>> LDFLAGS="-L/usr/local/ssl/lib -L/usr/local/lib/db4"
>> ./configure --with-tls --with-cyrus-sasl --enable-wrappers --
>> enable-crypt --enable-bdb it throws the error checking for
>> openssl/ssl.h... yes checking for SSL_library_init in -lssl... no
>> checking for ssl3_accept in -lssl... no checking OpenSSL library
>> version (CRL checking capability)... yes
>> configure: error: Could not locate TLS/SSL package.
>>
>> Please let me know what could be the possible reson behind. PFA the
>> config.log file.
>>
>> Regards,
>> Monica Rana
>>
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
16 years, 11 months
RE: Problem in configuring SSL with openldap
by Monica_Rana
Phillip,
I have checked the include and lib path. But seeing at the config logs,
it seems that the problem is with RSAglue/rsaref. I am new to openLDAP
and openSSL. So am not able to actually decode the logs.
Regards,
Monica Rana
-----Original Message-----
From: Phillip [mailto:phuang@plasmon.cn]
Sent: Thursday, October 12, 2006 1:07 PM
To: Monica_Rana
Cc: openldap-software(a)openldap.org
Subject: Re: Problem in configuring SSL with openldap
Monica,
Maybe you've take a mistake in setting "env", just try:
env CPPFLAGS="-I/usr/local/include -I/usr/local/ssl/include -
I/usr/local/db4/include" LDFLAGS="-L/usr/local/ssl/lib -
L/usr/local/db4/lib" ./configure --with-tls --with-cyrus-sasl --enable-
wrappers --enable-crypt --enable-bdb
You'd better verify the "include" and "lib" path for SSL and DB.
Regards,
Phillip
On Thu, 2006-10-12 at 12:18 +0530, Monica_Rana wrote:
> Hi All,
>
> I have the following installed on solaris 8.
> openLDAP 2.3.27
> openSSL 0.9.8b.
>
> when i try to configure using the command env
> CPPFLAGS="-I/usr/local/include -I/usr/local/include/ssl -
> I/usr/local/include/db4"
> LDFLAGS="-L/usr/local/ssl/lib -L/usr/local/lib/db4"
> ./configure --with-tls --with-cyrus-sasl --enable-wrappers --
> enable-crypt --enable-bdb it throws the error checking for
> openssl/ssl.h... yes checking for SSL_library_init in -lssl... no
> checking for ssl3_accept in -lssl... no checking OpenSSL library
> version (CRL checking capability)... yes
> configure: error: Could not locate TLS/SSL package.
>
> Please let me know what could be the possible reson behind. PFA the
> config.log file.
>
> Regards,
> Monica Rana
> **************** CAUTION - Disclaimer ***************** This e-mail
> contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for
> the use of the addressee(s). If you are not the intended recipient,
> please notify the sender by e-mail and delete the original message.
> Further, you are not to copy, disclose, or distribute this e- mail or
> its contents to any other person and any such actions are unlawful.
> This e-mail may contain viruses. Infosys has taken every reasonable
> precaution to minimize this risk, but is not liable for any damage you
> may sustain as a result of any virus in this e-mail. You should carry
> out your own virus checks before opening the e-mail or attachment.
> Infosys reserves the right to monitor and review the content of all
> messages sent to or from this e-mail address. Messages sent to or from
> this e-mail address may be stored on the Infosys e- mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>
16 years, 11 months
