[Home]

Summary:ASTERISK-13036: [patch] ERROR[23999]: res_config_ldap.c:1292 update_ldap: Couldn't modify ... Undefined attribute type
Reporter:Sébastien Cramatte (scramatte)Labels:
Date Opened:2008-11-07 11:24:13.000-0600Date Closed:2010-10-22 16:29:23
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_config_ldap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) __20080110-res_ldap.conf.patch
( 1) __20080110-res_ldap.conf-2.patch
( 2) ldap-update.txt
Description:my Asterisk return me this error on SIP register :

ERROR[23999]: res_config_ldap.c:1292 update_ldap: Couldn't modify dn:cn=200,ou=Telephony,dc=example,dc=com because Undefined attribute type

In spite of this message I can call and receive calls.

I haven't got more details ...
I've run Asterisk  with  -vvvvvvvvvvvvvvvvgc    

Comments:By: Leif Madsen (lmadsen) 2008-12-22 11:28:33.000-0600

I've reassigned this issue to Corydon76 as putnopvut mentioned on IRC that he would be willing to look at LDAP issues now. Maybe he will have some insight into how to move this issue forward. Thanks!
By: Tilghman Lesher (tilghman) 2008-12-22 22:53:16.000-0600

I'm afraid that I have zero knowledge of LDAP and the issues surrounding it, so leaving it assigned to me will get as much progress as the recent non-progress by Gavin Henry (of Suretec).
By: John Covert (jcovert) 2009-01-09 23:10:38.000-0600

Well, it looks like I am in the process of becoming an LDAP expert, since I have a client paying me to make SIP LDAP work.

What's going on here is that when a register comes in, Asterisk wants to put some info back into LDAP:
Modifying name=user1 hits: 1
ipaddr=n.n.n.54
AstAccountPort=5060
AstAccountExpirationTimestamp=1231559723
defaultuser=user1

Well, of these 5 fields, "name" is ok, and the two "Ast..." guys are ok, but neither ipaddr nor defaultuser are any good.

This is being done from chan_sip.c, which has:
 ast_update_realtime(tablename, "name", peername, "ipaddr", ipaddr,
                       "port", port, "regseconds", regseconds,
                       deprecated_username ? "username" : "defaultuser",
                       defaultuser, fc, fullcontact, syslabel, sysname, NULL);

The clue to the way to deal with this is noticing that "port" from the SIP call turned into AstAccountPort in the ldap update.  Ahah!  So we go and look at res_ldap.conf.  We surely don't want to change AstAccountHost from dynamic to the ipaddr, so I'll stick it into AstConfigCommented, and defaultuser can go into AstAccountDefaultUser.

And BINGO:  No more ugly message.  Now, right after a register, we have:

dn: cn=user1,ou=sippeers,dc=covert,dc=org
objectClass: top
objectClass: AsteriskSIPUser
cn: user1
AstAccountCallerID: User 1 <2001>
AstAccountHost: dynamic
AstAccountContext: ldapuser
name: user1
AstConfigCommented: x.x.x.54
AstAccountPort: 5060
AstAccountExpirationTimestamp: 1231562656
AstAccountDefaultUser: user1

And after an unregister, we have:

dn: cn=user1,ou=sippeers,dc=covert,dc=org
objectClass: top
objectClass: AsteriskSIPUser
cn: user1
AstAccountCallerID: User 1 <2001>
AstAccountHost: dynamic
AstAccountContext: ldapuser
name: user1
AstConfigCommented: 0.0.0.0
AstAccountPort: 0
AstAccountExpirationTimestamp: 1231562710
AstAccountDefaultUser: user1


To review how we got here, I had to make the following changes to res_ldap.conf:
1. right under [sip] change "uid" to "cn" because the schema requires cn and doesn't allow uid.
2. Near the end of this section, add
ipaddr = AstConfigCommented
defaultuser = AstAccountDefaultUser
3. Change the additional filter to be
additionalFilter=(objectClass=AsteriskSIPUser)
because what was there before didn't match the schema.

And voila!  It all works, in and out.  Missing, unfortunately, is a way to show, from the CLI, all these LDAP peers that are currently registered.

Could someone maybe commit the necessary changes to res_ldap.conf?

/john
By: Leif Madsen (lmadsen) 2009-01-10 08:27:07.000-0600

Hey John!

Thanks for the info! I have assigned this to myself and I will create a patch here shortly with the required changes. Ideally someone who uses LDAP will be able to test your suggestions just as a 2nd round of checks.

Although changing the res_ldap.conf should be a fairly safe thing to do :)

Once I attach the patch, it'd be great if you could review it to make sure I understood your note correct. Thanks!
By: Leif Madsen (lmadsen) 2009-01-10 08:58:10.000-0600

OK, I've made the requested changes.

John, and the original poster (and anyone else reading this), could you verify my changes are accurate?

Thanks!
Leif.
By: John Covert (jcovert) 2009-01-10 10:01:20.000-0600

Leif,

I noticed that there was a recent change (since the last SVN I had pulled at my client) that had made

ipaddr = AstAccountIPAddress

which is good.  It was not in what I last pulled down. So let's not change that one.  The other changes are needed.

/john
By: Leif Madsen (lmadsen) 2009-01-10 11:10:37.000-0600

John,

Done!

Does this work for you now?
By: John Covert (jcovert) 2009-01-10 11:27:36.000-0600

Yes, Leif, that works!  Thank you.

I should also write some notes in the wiki, and will do so, but am documenting it here for anyone else who wants to verify Leif's change.  Once these changes are made, this is a barebones setup to do the sip setup for a sip user or friend who registers dynamically:

dn: cn=<the SIP username>,ou=sippeers,dc=<your-domain>,dc=<your-tld>
objectClass: AsteriskSIPUser
cn: <same as above.  this is what would appear as [incoming-username]>
AstAccountCallerID: This is the CallerID Name <123456789>
AstAccountHost: dynamic
AstAccountContext: default
AstAccountRealmedPassword: {MD5}xxxxxxx

where xxxxxxx is created with

echo -n "SIPUSER:<your-domain>.<your-tld>:plaintext-password" | md5sum

and this is the "minimum" change to res_ldap.conf, in [_general]

url=ldaps://ldap.your.server    (can use either ldap or ldaps)
protocol=3
basedn="dc=<your-domain>,dc=<your-tld>"
pass=the-password-for-the-user-below
user=cn=<asterisk-administrative-username>,dc=<your-domain>,dc=<your-tld>

res_ldap.conf should be chmod 600 because it contains the plaintext ldap password to an account with WRITE access to the asterisk config.  This might be a bigger password exposure than SIP and IAX plaintext passwords. (I wonder if there should be a comment to that effect in the file, and if make samples should do it?)

The asterisk administrative user is created this way:

dn: <asterisk-administrative-username>,dc=<your-domain>,dc=<your-tld>
objectclass: organizationalRole
cn: <same as above>
userPassword: {SSHA}yyyyyyy

where yyyyyy is the output of slappasswd -s plaintext-password
By: Leif Madsen (lmadsen) 2009-01-10 12:55:23.000-0600

Thanks for the info John. That might be a good basis for a document that we could include in the doc/ directory.

What LDAP server are you currently using for testing? OpenLDAP? I think I'd like to either create (or update) a document that would explain how to setup LDAP authentication for SIP and IAX2.

I haven't taken a look, but is there already a document that explains how to get this setup, or did you simply have to go it alone?

Thanks!
By: Sébastien Cramatte (scramatte) 2009-01-11 03:11:35.000-0600

I've put in my res_ldap.conf

ipaddr = AstAccountIPAddress
defaultuser = AstAccountDefaultUser

I'm running Asterisk 1.6.0.1
It's strange because now Asterisk update my LDAP properly changing 2 attributes above but I still have the message.

The strangest is that some peers doesn't raise the message and all have the same setup and all are updated.

What can I do to help in debug this ?
By: John Covert (jcovert) 2009-01-11 10:38:28.000-0600

(Jump right to the bottom; I may have noticed your problem, but the info below should be useful for other debugging.)

Let's see what you actually have in LDAP for a few users:

ldapsearch -x -h your.server -b 'dc=<your-domain>,dc=<your-TLD>'  '(cn=<user>)'

Depending on how you have your security set up, you might also need to specify -D '<exactly-what-you-have-after-user=-in-res_ldap.conf>' -w <password>

My security setup at the moment (because I'm just testing) is:

access to attrs=AstAccountSecret,AstAccountRealmedPassword
      by anonymous auth
      by dn.base="<user-in-res_ldap.conf>" write
      by * none
access to dn.subtree="ou=sippeers,dc=covert,dc=org"
      by dn.base="<user-in-res_ldap.conf>" write
      by * read

I would probably not give the world read access in production.

The result I currently get for a not-logged-in user is:

# <user>, sippeers, <my-domain>.<my-TLD>
dn: cn=<user>,ou=sippeers,dc=<my-domain>,dc=<my-TLD>
objectClass: AsteriskSIPUser
cn: <user>
AstAccountCallerID: The Username <2001>
AstAccountHost: dynamic
AstAccountContext: <the-context>
AstAccountIPAddress: 0.0.0.0
AstAccountPort: 0
AstAccountExpirationTimestamp: 1231610206
AstAccountDefaultUser: <user>

I initially created this with just the fields shown in Note 0097430 above.  We don't see the secret in the ldapsearch output because I did the ldapsearch without the "-D" and "-w", and the additional fields not there in the initial creation (0097430) are the ones added/updated by registration and de-registration.

And after writing all of this, I noticed that you didn't mention changing "name=uid" to "name=cn" which is part of the patch.  And I'll bet that some of your peers are only in objectClass: AsteriskSIPUser (which is all that should be required for anything that Asterisk does), but others are also in some other objectClass, like maybe "top".  The output before you make any changes would still be instructive.  You can get all of the users that asterisk will see by saying '(objectClass=AsteriskSIPUser)' instead of '(cn=<user>)'.
By: John Covert (jcovert) 2009-01-11 12:40:45.000-0600

Leif,

I'm using OpenLDAP on Mac OS X.  To figure it all out, I first started just poking around in various LDAP servers with the ldapsearch utility.  Then, when it was time to really try it out with Asterisk, I needed to get my own LDAP server going.  So I just started at page 1 of http://www.openldap.org/doc/admin24/ reading and trying out the examples.  Reading every word, and trying every example.

The first glitch came when trying to use ldapadd to add my first entries.  "Failed to authenticate." After much googling (Google is your friend), I found that the Mac OS X version is built with "plaintext passwords verboten", so I determined that the "rootpw" in slapd.conf needed to be created with slappasswd and entered as {SSHA}hashedpassword as mentioned for the Asterisk Admin password up in Note 0097430.

Once I started trying to put in Asterisk entries I ran into problems with the examples at http://www.flyn.org/astldap/ .  These examples are very helpful, but they don't correspond exactly to reality; see the changes we made to res_ldap.conf for starters.  I started getting some schema errors.  There's an option "schemacheck" which needs to be off (Google again helped me find this, although the comment is "you should really fix your schema").

When I started thinking that it was now time to start thinking about access control, I discovered that there was a major change in how configuration is done beginning with OpenLDAP version 2.3, so I needed to find out for sure what version is installed on Mac OS X.  No command seemed to be available to find out, so again, Google to the rescue, where I found out that "strings slapd | grep \$OpenLDAP" would answer the question.  At this point I switched to the proper version documentation at http://www.openldap.org/doc/ and continued.

/john
By: John Covert (jcovert) 2009-01-12 00:50:42.000-0600

I just learned the hard way that upgrading from OpenLDAP 2.1 to 2.2 _may_ require recreating the entire database.  There may be a conversion tool, but at my stage, it was easier to just recreate from scratch.  This also allows me to provide to you a complete minimal database below:

# LDAPv3
# Minimum top level ldap stuff
# your-domain.tld
dn: dc=your-domain,dc=tld
objectClass: dcObject
objectClass: organization
o: The Your-domain Organization
dc: your-domain

# This will be the user for the root password in the config file
# Manager, your-domain.tld
dn: cn=Manager,dc=your-domain,dc=tld
objectClass: organizationalRole
cn: Manager

# This will be the user who goes into res_ldap.conf
# AsteriskManager, your-domain.tld
dn: cn=AsteriskManager,dc=your-domain,dc=tld
objectClass: organizationalRole
cn: AsteriskManager
userPassword: {SSHA}output of slappasswd

# This is the top of the sip entries
# sippeers, your-domain.tld
dn: ou=sippeers,dc=your-domain,dc=tld
ou: sippeers
objectClass: organizationalUnit

# Everything above this must be created by root if your security is
# set up as I described earlier
# Everything below this could be created by Asterisk Manager
# user1, sippeers, your-domain.tld
dn: cn=user1,ou=sippeers,dc=your-domain,dc=tld
objectClass: AsteriskSIPUser
cn: user1
AstAccountCallerID: User 1 <2001>
AstAccountHost: dynamic
AstAccountRealmedPassword: {MD5}use echo -n "SIPUSER:domain.tld:pwd" | md5sum
AstAccountContext: ldapuser

# user2, sippeers, your-domain.tld
dn: cn=user2,ou=sippeers,dc=your-domain,dc=tld
objectClass: AsteriskSIPUser
cn: user2
AstAccountCallerID: User 2 <2002>
AstAccountHost: dynamic
AstAccountRealmedPassword: {MD5}use echo as above
AstAccountContext: default

etc.
By: Leif Madsen (lmadsen) 2009-01-14 12:42:58.000-0600

Thanks for the info John! It might be a little bit before I can get the time to move this issue along, but I do plan on getting it updated. Most likely after I get 1.4.23 and a new 1.6.1 release out there, I'll be able to take this issue on.

Your patience is appreciated, and thanks for the thorough messages. It should help form some sort of documentation!
By: John Covert (jcovert) 2009-01-15 16:47:46.000-0600

Here's a bit more info, and I think it should be a comment in res_ldap.conf right after the place where we changed "name = uid" to "name = cn".

# We use the "cn" as the default value for name on the line above
# because objectClass=AsteriskSIPUser does not include a uid as an allowed field
# If your entry combines other objectClasses and uid is available, you may
# prefer to change the line to be name = uid, especially if your LDAP entries
# contain spaces in the cn field.
# You may also find it appropriate to use something completely different.
# This is possible by changing the line above to name = AstAccountName
By: John Covert (jcovert) 2009-01-16 10:44:35.000-0600

One more important piece of info.

Although my example has entries that are

dn: cn=user2,ou=sippeers,dc=your-domain,dc=tld

we have

sippeers => ldap,"dc=your-domain,dc=tld",sip

in extconfig.conf

there is no need to have either "cn" (or whatever is set for "name" be that uid or AstAccountName or whatever) as part of the dn.

Asterisk does its lookup as though it were doing an ldapsearch command (see man ldapsearch) with these arguments:

-b "what-is-in-quotes-in-the-sippeers => def" (&(yyyy)(xxx=peername))

xxx is what you specified in res_ldap.conf for "name=" and yyyy is what you specified in res_ldap.conf (typically (objectClass=AsteriskSIPUser))

so the DN could very well be something like

dn: cn=John Q Public,ou=people,dc=mycompany,dc=com

(in which case we'd probably use either uid, if it was defined by one of the other object classes assigned to this entry, or AstAccountName, for the sippeername)
By: Leif Madsen (lmadsen) 2009-01-26 10:28:33.000-0600

jcovert: to be clear here, I've added your note in addition to the changes we had before.

However your last note has confused me a bit, and I'm not sure what you're asking me to change ;)  Can you give me an example of what you want changed or added to res_ldap.conf.sample?

Thanks!
By: Leif Madsen (lmadsen) 2009-01-28 15:34:40.000-0600

Ping :)
By: John Covert (jcovert) 2009-01-28 16:22:20.000-0600

Let me try to more clearly state this.

LDAP is tree structured.

Each entry is at a point on the tree defined by its "dn".

For example, dn: x=a, y=b, z=c, dc=mycompany, dc=mytld

Whenever any program searches an ldap database, it specifies the starting point, or "base" within the tree at which to begin the search.

If the base is "dc=mycompany, dc=mytld", then all of the tree beginning at that point will be searched for the requested matches.

I wanted to be clear that the example, which has a portion of the tree named "ou=sippeers", does not create a relationship that restricts the search to a part of the tree.

When we specify

sippeers => ldap,"dc=mycompany,dc=mytld"

we say to search all of the tree beginning at that point.  The "ou=sippeers, dc=mycompany, dc=mytld" portion of the tree will be searched, but so would the portion "ou=foobar, dc=mycompany, dc=mytld".

We could specify

sippeers => ldap,"ou=chicago,dc=mycompany,dc=mytld"

and restrict the search to the chicago organizational unit (which might be a smart idea if we have a corporation-wide database, and only want to pick up the entries in chicago into the chicago asterisk PBX).

In addition to the base, which specifies the PORTION of the tree to be searched, when searching for a sip entry, we'll pick up entries that match the fields specified in res_ldap.conf.

There are two entries in the [sip] section which control this:

You've entered

name = cn

or

name = uid

or

name = AstAccountName

or

name = WhateverYouWant

The default res_ldap.conf contains an entry

additionalFilter=(objectClass=AstAccountSIP)

The search will look for an entry anywhere below the specified base which has a field specified by name= (cn, uid, AstAccounName, or WhateverYouWant) equal to the sip username and also matches "additionalfilter".

/john
By: John Covert (jcovert) 2009-01-28 16:23:58.000-0600

So I'd suggest adding all of the above note (except "let me be more clear" and "/john") as a comment in res_ldap.conf.
By: Leif Madsen (lmadsen) 2009-02-02 12:09:21.000-0600

OK. I've decided to get this bug closed by submitting the patch 'as-is', since that note above is quite descriptive, and goes beyond what I wanted to do with this patch.

However! The bug I have opened and assigned to me is related to this issue, which will remind me to come back and get all this great information and place it into a document that I'll write in the upcoming weeks.

Thanks!
By: Digium Subversion (svnbot) 2009-02-02 12:12:37.000-0600

Repository: asterisk
Revision: 172894

U   trunk/configs/res_ldap.conf.sample

------------------------------------------------------------------------
r172894 | lmadsen | 2009-02-02 12:12:37 -0600 (Mon, 02 Feb 2009) | 7 lines

Update the res_ldap.conf file with a better working example.

(closes issue ASTERISK-13036)
Reported by: scramatte
Patches:
     __20080110-res_ldap.conf-2.patch uploaded by blitzrage (license 10)
Tested by: jcovert
------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=172894
By: Digium Subversion (svnbot) 2009-02-02 12:13:58.000-0600

Repository: asterisk
Revision: 172895

_U  branches/1.6.1/
U   branches/1.6.1/configs/res_ldap.conf.sample

------------------------------------------------------------------------
r172895 | lmadsen | 2009-02-02 12:13:57 -0600 (Mon, 02 Feb 2009) | 15 lines

Merged revisions 172894 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r172894 | lmadsen | 2009-02-02 13:13:40 -0500 (Mon, 02 Feb 2009) | 7 lines
 
 Update the res_ldap.conf file with a better working example.
 
 (closes issue ASTERISK-13036)
 Reported by: scramatte
 Patches:
       __20080110-res_ldap.conf-2.patch uploaded by blitzrage (license 10)
 Tested by: jcovert
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=172895
By: Digium Subversion (svnbot) 2009-02-02 12:14:48.000-0600

Repository: asterisk
Revision: 172896

_U  branches/1.6.0/
U   branches/1.6.0/configs/res_ldap.conf.sample

------------------------------------------------------------------------
r172896 | lmadsen | 2009-02-02 12:14:48 -0600 (Mon, 02 Feb 2009) | 15 lines

Merged revisions 172894 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r172894 | lmadsen | 2009-02-02 13:13:40 -0500 (Mon, 02 Feb 2009) | 7 lines
 
 Update the res_ldap.conf file with a better working example.
 
 (closes issue ASTERISK-13036)
 Reported by: scramatte
 Patches:
       __20080110-res_ldap.conf-2.patch uploaded by blitzrage (license 10)
 Tested by: jcovert
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=172896
By: Gavin Henry (suretec) 2009-05-25 04:00:10

I'm re-opening this so I can track it, verify and proof read.

Thanks.
By: Sébastien Cramatte (scramatte) 2009-07-16 06:46:47

I've recheck my res_ldap.conf file and I still have the issue ...

[Jul 16 13:25:28] ERROR[2380]: res_config_ldap.c:1292 update_ldap: Couldn't modify dn:cn=1000,ou=emta,ou=Sip,ou=Telephony,ou=Services,o=mycompany,c=es because Undefined attribute type[Jul 16 13:26:41] ERROR[2380]: res_config_ldap.c:1292 update_ldap: Couldn't modify dn:cn=1000,ou=emta,ou=Sip,ou=Telephony,ou=Services,o=mycompany,c=es because Undefined attribute type
By: Gavin Henry (suretec) 2009-11-10 04:08:56.000-0600

Please retest.
By: Erik Forsén (forsen) 2010-09-06 07:47:51

Seems like one item is missing from the [sip] section in the current res_ldap.conf.sample

In order to get rid of the "Couldn't modify..." error message, I had to add a useragent mapping:

useragent = AstAccountUserAgent

Would be nice if someone could include this line in the sample config.
By: Gavin Henry (suretec) 2010-09-06 07:53:48

Will do.
By: Leif Madsen (lmadsen) 2010-10-21 07:28:35

OK I'm going through this issue a bit because I'm doing some LDAP testing and running into this very issue now. With an LDAP configuration setup and documentation to this effect going on, I'm hoping to get this issue closed out today or tomorrow.

Thanks!
By: Leif Madsen (lmadsen) 2010-10-21 07:51:48

I'm still kind of getting this error, although I'm not entirely sure why. I've gotten the ERROR line modified to tell me what it doesn't like, and it seems to be that Asterisk is for some reason trying to update the 'name' field (our cn) which seems odd to me. Perhaps I"m misunderstanding.


[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:1713 ldap_reconnect: Everything seems fine.
[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:635 substituted: substituted: string: 'ou=people,dc=shifteight,dc=org' => 'ou=people,dc=shifteight,dc=org'
[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:662 cleaned_basedn: basedn: 'ou=people,dc=shifteight,dc=org' => 'ou=people,dc=shifteight,dc=org'
[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:699 append_var_and_value_to_filter: name='name' value='RussellBryant'
[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:1311 update_ldap: LINE(1311) Modifying name=RussellBryant hits: 1
[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:1314 update_ldap: LINE(1314) AstAccountIPAddress=172.16.0.112
[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:1314 update_ldap: LINE(1314) AstAccountPort=39769
[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:1314 update_ldap: LINE(1314) AstAccountExpirationTimestamp=1287669035
[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:1314 update_ldap: LINE(1314) AstAccountDefaultUser=RussellBryant
[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:1314 update_ldap: LINE(1314) AstAccountUserAgent=Zoiper rev.6848
[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:1314 update_ldap: LINE(1314) AstAccountLastQualifyMilliseconds=0
[Oct 21 08:50:35] DEBUG[13075]: res_config_ldap.c:1314 update_ldap: LINE(1314) gecos=sip:RussellBryant@172.16.0.112:39769;rinstance=348f7e0dfbae404a;transport=UDP
[Oct 21 08:50:35] ERROR[13075]: res_config_ldap.c:1324 update_ldap: Couldn't modify 'name'='RussellBryant', dn:uid=rbryant,ou=people,dc=shifteight,dc=org because Object class violation
By: Leif Madsen (lmadsen) 2010-10-21 07:52:32

To be clear the peer is still registering in Asterisk and is able to place calls and such, but I'm getting an error back from the LDAP backend because it seems like Asterisk is trying to modify a value it shouldn't.
By: Leif Madsen (lmadsen) 2010-10-21 08:22:04

jcovert: any chance you could jump on IRC today to help me out?
By: Leif Madsen (lmadsen) 2010-10-22 07:08:05

I'm making some progress on this side. By looking at the debug logs on the slapd side, I'm noticing something about the AstAccountUserAgent field not being valid. For some reason my schema shows it, but slapd is not accepting it. I'm in the process of debugging through why that is the case.
By: Leif Madsen (lmadsen) 2010-10-22 15:49:28

Wow I figured this out finally! With the help of jcovert and Richard Genthner we finally got to the bottom of this -- the asterisk.ldif file is woefully out of date. I'll be uploading a patch shortly and closing this issue out. w00t!
By: Digium Subversion (svnbot) 2010-10-22 16:16:14

Repository: asterisk
Revision: 292786

U   branches/1.6.2/channels/chan_sip.c
U   branches/1.6.2/configs/res_ldap.conf.sample
U   branches/1.6.2/contrib/scripts/asterisk.ldif

------------------------------------------------------------------------
r292786 | lmadsen | 2010-10-22 16:16:13 -0500 (Fri, 22 Oct 2010) | 13 lines

Update the LDIF file for LDAP.
The LDIF file asterisk.ldif was quite a bit out of date from the asterisk.ldap-schema file, so I've
now updated that to be in sync. The asterisk.ldif file being out of sync was a problem on my systems
where I was doing an ldapadd to import the schema into the LDAP database, and the existing file
would cause problems and ERROR messages when registering.

Additional documention has been added based on feedback in the issue I'm closing.

(closes issue ASTERISK-13036)
Reported by: scramatte
Patches:
     ldap-update.txt uploaded by lmadsen (license 10)
Tested by: lmadsen, jcovert, suretec, rgenthner
------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=292786
By: Digium Subversion (svnbot) 2010-10-22 16:28:44

Repository: asterisk
Revision: 292787

_U  branches/1.8/
U   branches/1.8/channels/chan_sip.c
U   branches/1.8/configs/res_ldap.conf.sample
U   branches/1.8/contrib/scripts/asterisk.ldif

------------------------------------------------------------------------
r292787 | lmadsen | 2010-10-22 16:28:44 -0500 (Fri, 22 Oct 2010) | 21 lines

Merged revisions 292786 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

........
 r292786 | lmadsen | 2010-10-22 16:16:12 -0500 (Fri, 22 Oct 2010) | 13 lines
 
 Update the LDIF file for LDAP.
 The LDIF file asterisk.ldif was quite a bit out of date from the asterisk.ldap-schema file, so I've
 now updated that to be in sync. The asterisk.ldif file being out of sync was a problem on my systems
 where I was doing an ldapadd to import the schema into the LDAP database, and the existing file
 would cause problems and ERROR messages when registering.
 
 Additional documention has been added based on feedback in the issue I'm closing.
 
 (closes issue ASTERISK-13036)
 Reported by: scramatte
 Patches:
       ldap-update.txt uploaded by lmadsen (license 10)
 Tested by: lmadsen, jcovert, suretec, rgenthner
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=292787
By: Digium Subversion (svnbot) 2010-10-22 16:29:21

Repository: asterisk
Revision: 292788

_U  trunk/
U   trunk/channels/chan_sip.c
U   trunk/configs/res_ldap.conf.sample
U   trunk/contrib/scripts/asterisk.ldif

------------------------------------------------------------------------
r292788 | lmadsen | 2010-10-22 16:29:21 -0500 (Fri, 22 Oct 2010) | 28 lines

Merged revisions 292787 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r292787 | lmadsen | 2010-10-22 16:28:43 -0500 (Fri, 22 Oct 2010) | 21 lines
 
 Merged revisions 292786 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ........
   r292786 | lmadsen | 2010-10-22 16:16:12 -0500 (Fri, 22 Oct 2010) | 13 lines
   
   Update the LDIF file for LDAP.
   The LDIF file asterisk.ldif was quite a bit out of date from the asterisk.ldap-schema file, so I've
   now updated that to be in sync. The asterisk.ldif file being out of sync was a problem on my systems
   where I was doing an ldapadd to import the schema into the LDAP database, and the existing file
   would cause problems and ERROR messages when registering.
   
   Additional documention has been added based on feedback in the issue I'm closing.
   
   (closes issue ASTERISK-13036)
   Reported by: scramatte
   Patches:
         ldap-update.txt uploaded by lmadsen (license 10)
   Tested by: lmadsen, jcovert, suretec, rgenthner
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=292788