[phpldapadmin] [ phpldapadmin-Bugs-3411598 ] Call to a member function getMustAttrNames
SourceForge.net <[email protected]> Thu, 01 Dec 2011 03:52:40 -0800
| Newsgroups | gmane.comp.ldap.davedap |
|---|---|
| Message-ID | <[email protected]> |
Bugs item #3411598, was opened at 2011-09-19 12:54
Message generated for change (Comment added) made by towerlexa
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=498546&aid=3411598&group_id=61828
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.2.x
>Status: Closed
>Resolution: Works For Me
Priority: 7
Private: No
Submitted By: towerlexa (towerlexa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Call to a member function getMustAttrNames
Initial Comment:
1. phpLDAPadmin => 1.2.1.1
2. Your LDAP server =>
@(#) $OpenLDAP: slapd 2.4.21 (Jun 2 2011 19:41:11) $
buildd@palmer:/build/buildd/openldap-2.4.21/debian/build/servers/slapd
3. Your web server
Apache/2.2.14 (Ubuntu) DAV/2 SVN/1.6.6 mod_fastcgi/2.4.6 PHP/5.3.2-1ubuntu4.9 with Suhosin-Patch configured -- resuming normal operations
4. PHP
5. Your operating system
Ubuntu 10.04 LTS
I got the following error message, while i'am trying to use phpldapadmin:
[quote]Fatal error: Call to a member function getMustAttrNames() on a non-object in /all_home_data/apache/htdocs/phpldapadmin/lib/Template.php on line 1548[/quote]
in this case phpldapadmin is still unuseable.
----------------------------------------------------------------------
>Comment By: towerlexa (towerlexa)
Date: 2011-12-01 03:52
Message:
i assume, that my settings for the frontend ACL are solving this problem.
- for olcDatabase={-1}frontend,cn=config
{0}to dn.base="" by * read
{1}to dn.base="cn=Subschema" by * read
{2}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage by * break
----------------------------------------------------------------------
Comment By: towerlexa (towerlexa)
Date: 2011-10-27 11:15
Message:
Hi @All,
i'am really very confused. I updated today to the new release 1.2.2 but
belonging to this issue there is no new behavior.
May you please give me any advise what i could to additional to my last
updates? I've created a set of new log files and attached it to this
Bugreport.
Any kind of help is very appreciated
greetings towerlexa
----------------------------------------------------------------------
Comment By: towerlexa (towerlexa)
Date: 2011-10-15 12:00
Message:
Hi @ All,
i'sorry, for writing again, but is there any thing i could do for helping
to resolve this Bug?
Unfortunately i'am not able to write inside the php Code.
Thank you very much.
----------------------------------------------------------------------
Comment By: towerlexa (towerlexa)
Date: 2011-10-08 12:40
Message:
Hi Deon,
aditionally to last mail from yesterday, i added the Line in Section 9
below:
Am 07.10.2011 22:43, schrieb Axel Birndt:
>
>
> Am 07.10.2011 00:24, schrieb Deon George:
>> On 07/10/11 05:12, Axel Birndt wrote:
>>> i tried your hints from the wiki entry and now i think i have one
more
>>> (and another) problem:
>
> I checked the content of my ldapserver with the ldapvi editor. But i
> don't find any entrys with the subschemaSub* entry.
>
>> Did you check your ACL's?
>
> Yes, this are my ACL's
> 9 olcDatabase={1}hdb,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcHdbConfig
> olcDatabase: {1}hdb
> olcDbDirectory: /var/lib/ldap
> olcSuffix: dc=ldapserver,dc=de
> olcAccess: {0}to attrs=userPassword,shadowLastChange by
> dn="cn=uuuuuu,dc=ldapserver,dc=ro" write by anonymous auth by self write
> by * none
> olcAccess: {1}to dn.base="" by * read
> ---olcAccess: {2}to dn.base="cn=subschema" by * read---
> olcAccess: {3}to * by dn="cn=uuuuuu,dc=ldapserver,dc=de" write by * read
Now and after i've configured the ACL like described above i executed the
*ldapsearch -xh 127.0.0.1 -b '' -s base subschemaSubentry*
command once more.
The result is the same as i described at the 6th of october!
If i try to call a page in the phpldapadmin i got the same failure as
before:
Fatal error: Call to a member function getMustAttrNames() on a non-object
in /all_home_data/apache/htdocs/phpldapadmin/lib/Template.php on line 1548
i created to files with the log output, but i don't attached it to this
mails, because it is to big for that.
Here are the two links:
http://www.blaufotograph.de/phpldapadmin/slapd.log_08.10.2011
http://www.blaufotograph.de/phpldapadmin/pla_debug.log_08.10.2011
from the getSchemaObjectClass i got only this two occurences from this
Method(?).
[0,000] Attribute(0133-005): Attribute::getName: Entered
(NOARGS|objectclass)
[0,000] Attribute(0878-005): .Attribute::real_attr_name: Entered
(NOARGS|objectclass)
[0,000] Attribute(0143-005): .Attribute::getValues: Entered
(NOARGS|a:3:{i:0;s:7:"account";i:1;s:20:"simpleSecurityObject";i:2;s:3:"top";})
[0,000] ds_ldap(1484-025): ldap::getSchemaObjectClass: Entered
(account)
[0,000] ds_ldap(1547-025): ldap::SchemaObjectClasses: Entered (|)
[0,000] functions(0876-001): get_cached_item: Entered
(1|schema|objectclasses)
[0,000] functions(0886-001): get_cached_item: Returning ()
[0,000] ds_ldap(1254-025): ldap::getRawSchema: Entered
(|objectclasses|)
[0,000] ds_ldap(0131-017): ldap::connect: Entered ()
[0,000] ds(0457-017): DS::getMethod: Entered ()
[0,000] ds_ldap(1268-025): ldap::getRawSchema: Returning CACHED ()
[0,000] ds_ldap(1586-025): ldap::SchemaObjectClasses: Returning ()
[0,000] ds_ldap(1496-025): ldap::getSchemaObjectClass: Returning
()
In my opinion, it could be, that the ACL from above isn't correct at all!
But i don't know how to do it better.
Sorry.
Maybe you could see something in all this character salad ;-)
I would be happy if you have some time to have a look at all of this.
Thanks in advance.
----------------------------------------------------------------------
Comment By: Deon George (wurley)
Date: 2011-10-05 21:01
Message:
Make sure PLA has access to your schema - as described on the wiki:
http://phpldapadmin.sourceforge.net/wiki/index.php/FAQ#I_cannot_view_the_schema.2C_or_I_get_the_message_.22Our_attempts_to_find_your_SCHEMA_for_.27objectclasses.27_have_FAILED..22
If it has, then set up debugging - level 25 should be OK. This will
generate a very big log file (and PLA will be quite slow). Look through the
log and see what is being returned by the function getSchemaObjectClass()
and the activity around that function. (That function should be returning
an ObjectClass Object.)
It might also be helpful to have openldap in debugging mode - "-d 256" is
often very useful.
----------------------------------------------------------------------
Comment By: towerlexa (towerlexa)
Date: 2011-10-02 12:24
Message:
Hi @All,
i would like to ask someone for any assistance belonging this problem?
Any help is very appreciated
Thanks an greetings
towerlexa aka Axel Birndt
----------------------------------------------------------------------
Comment By: towerlexa (towerlexa)
Date: 2011-09-19 12:55
Message:
Of course I've searched in the bug list, but i doesn't find a match for my
issue.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=498546&aid=3411598&group_id=61828
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
______________________________________
phpLDAPadmin development mailing list.
To unsbuscribe: https://lists.sourceforge.net/lists/listinfo/phpldapadmin-devel
http://phpldapadmin.sourceforge.net/