phpldapadmin: Incompatible with PHP 5.3

Thanks. I installed debian sid in a virtual machine to manage my ubuntu ldap server.

Perfect! although a little more complicated than I expected

Is it possible to bump this before lucid release? It completely breaks PHPLDAPAdmin.

Any fix for Lucid Lynx?

This nabble thread seems to address the issue - a patch was created and submitted for this issue (I think).

Perhaps we just need a newer version packaged?

http://old.nabble.com/-Bug-54261--phpldapadmin,-NEW:-phpldapadmin:-homepage-buggy-td25736546.html

I can confirm this error. The two ways of addressing this would be to replace all the deprecated functions, or ignore the errors. The new upstream version (in Debian testing) has the errors fixed. Since eregi() and others are not deprecated until php 6, I think we can ignore the errors as a short term fix. Maverick should obtain the new version from Debian.

If the release managers would prefer to fix these functions, let me know.

Patch to ignore deprecated. Login seems to work, can someone please confirm that this works. I have had a user report that they cant see the attributes of objects (a user in this case).

I did not apply your patch, but used the one from the other thread I linked to. it looks to do the same thing though. After applying the patch I can now login. However trying to view the details of any user in my LDAP tree returns replaces the details frame with another error frame - I've attached a screenshot.

Hello,

I found a patch that is quite easy to apply:

1. Open /usr/share/phpldapadmin/lib/common.php
2. Find the following lines and change variable in brakes as shown.

Current:
=======
# We are now ready for error reporting.
error_reporting(E_ALL);

Working:
=======
# We are now ready for error reporting.
error_reporting(E_ALL & ~E_DEPERCATED);

Enjoy!

And does it work for you beyond login?

I can login with 1.1.0.7, but I can't see any object.

Besides, there's a new version of phpldapadmin (1.2.0.5), why do you want to patch an old and buggy version when you can use the new one?

I tried phpldapadmin-1.2.0.5 in the www directory, it works width PHP 5.3.
(Unfortunately, slapd was broken in the update process and I had to reinstall it).

From the comments so far, the attached patch doesnt actually seem to work. Is it actually working for anyone? I am going to investigate patching the deprecated calls. Moving to 1.2 may be an option as it is in Debian. Will try speak to someone at UDS.

SRU Request to fix this package.

I've had a look at patching the calls, and replaced all of them. There are now LDAP errors. Too much has changed and would like to SRU this package as due to php 5.3 incompatibility it is currently not working on Lucid.

I've uploaded a working merge from Debian into Maverick. If we could use the same version for Lucid that would be great.

So right now the fix is available only for Maverick?

Do you have an ETA of when we can expect 1.2.x for Lucid?

Thanks

Taking a bit longer as most members are at UDS. Build log of Maverick version attached.

1.2.0.5-1ubuntu1.10.04.1 build in the ubuntu-security-proposed ppa and pushed to lucid-proposed.

Added verification-needed. Please test and report positive or negative results here. Thanks!

Caveat: this is my first encounter with phpldapadmin, so I do not know exactly what to expect.

I just tried with with a clean jaunty (server installation), using the first sections of http://www.opinsys.fi/setting-up-openldap-on-ubuntu-10-04-alpha2 to set up the initial ldap database (I could not log in otherwise).
Basic web access (with firefox 3.6.3) works: the previous error messages are gone.

Compared to the interface I see for instance here: http://www.youtube.com/watch?v=DM_UQVVVtoY
I am missing all the attributes of an object listed on the right-hand side. Whatever I do create (with lots of attributes), after I have created it, refreshed and selected the new object in the left tree, the only thing presented in the right side is the general menu and the name of the object. No attributes.

If I "Export" such an object to ldif format, it is empty, even with an object created by one of the scripts from the 'HowTo' page mentioned above.
My attempt to follow the instructions configuring LDAT for a Zarafa installation failed (http://www.zarafa.com/wiki/index.php/ZCP_on_Ubuntu_8.04_LTS#OpenLDAP)

Regards

Hartmut: Thanks for your input, although you mention the Jaunty version (1.1.0.5-6ubuntu3) - is this correct? This bug is specifically related to Lucid and the testing of the proposed fix in Lucid proposed. If this is against Jaunty, please file a seperate bug for your issue.

To the subscribers of this bug, if you would like this fix in Lucid updates, please test and report back here!

Sorry, not familiar with how to test this. Do I need to add a specific PPA?

Kirk: Please see https://wiki.ubuntu.com/Testing/EnableProposed for information about enabling -proposed. Thanks!

1.2.0.5-1ubuntu1.10.04 seems to work for me, though I had to

- purge phpldapadmin 1.1.x before installing 1.2.0.5 from proposed
- edit /etc/phpldapadmin/config.php on line 283 to my base dn (can't remember I had to do this once before on ubuntus phpldapadmin)

Thx!

Correction for #19: I tested on a fresh Lucid 32bit, NOT on jaunty. That was a typo.

1.2.0.5-1ubuntu1.10.04.1

Works for me.

I had to recreate the config file from scratch but I can confirm that it appears to be working as per normal.

To confirm distro and arch for #25

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04 LTS"

Linux 2.6.32-22-server #33-Ubuntu SMP Wed Apr 28 14:34:48 UTC 2010 x86_64 GNU/Linux

I've upgraded via the PPA.
It failed right off the bat, stating something was wrong with the config.php file
I renamed the file, and ran dpkg-reconfigure phpldapadmin.
I answered the questions to mimic my previous (existing) installation.

Once this was all complete I was able to login. I can see my data tree on the left. However when I click on an entry to see its details, an error page was displayed in the right frame stating it could not find my schema at all. I tried clicking a second entry, and much less error was displayed, but the error still states the following:

Our attempts to find your SCHEMA have failed (objectclasses)
Error: Please contact the phpLDAPadmin developers and let them know:

    * Which LDAP server you are running, including which version
    * What OS it is running on
    * Which version of PHP
    * As well as a link to some documentation that describes how to obtain the SCHEMA information

We'll then add support for your LDAP server in an upcoming release.
error Error
Could not retrieve schema from My LDAP Server.

This could happen for several reasons, the most probable of which are:

    * The server does not fully support the LDAP protocol.
    * Your version of PHP does not correctly perform the query.
    * phpLDAPadmin doesn't know how to fetch the schema for your server.
    * Or lastly, your LDAP server doesnt provide this information.

Perhaps this is my lack of knowledge of how to properly setup something here - happy to be told to go read a specific doc or something if that is the case. But so far I do not think this bug is resolved for me.

I upgraded to 1.2.0.5-1ubuntu1.10.04.1, then reconfigured as in #23. I'm now in exactly the same situation as #27. The package is currently unusable with PHP 5.3.

I'm in the same situation as #27: upgraded phpldapadmin to 1.2.0.5-1ubuntu1.10.04.1, removed /etc/phpldapadmin/config.php, ran dpkg-reconfigure phpldapadmin and got the same result.

My LDAP server was upgraded from Ubuntu 9.10, could that be part of the problem? The phpldapadmin FAQ suggests that it might be due to the fact that it needs read access to the subschema's. Has there been a change in the LDAP ACLs when upgrading to Lucid?

works for me

althought I have to say the template system is anoying.

I have the bug with Ubuntu 10.04 64 bits upgraded from Ubuntu 9.10 bits. So, I install Ubuntu 10.04 32 bits in a virtualbox computer and no error messages. It is the same version 1.1.0.7 from Ubuntu repository. Very strange

@Zahari

I Applied the changes. Worked like a Charm!

used the proposed package as in #22, and had errors, but then realized that the phpLDAPAdmin config file completely changed, so I merged my old config into the new .example config file @see http://phpldapadmin.sourceforge.net/wiki/index.php/Config

I specified my server 'name', 'host', and 'base' and everything seemed operational, but navigating into the tree caused all kinds of errors, and it seems that I need to reload my schema "templates" .

I tried to ensure that anonymous read access is granted in my server, but I actually don't get any schema result following the FAQ
http://phpldapadmin.sourceforge.net/wiki/index.php/FAQ#Your_schema_doesnt_provide_anonymous_read_access

This problem still exists; any ETA on a fix?

I've gotten rid of the debugging messages and can now see my tree, but trying to browse my tree results in:

Our attempts to find your SCHEMA for "objectclasses" have FAILED.

Hi Guys,

There has been alot of reports that this doesn't work, and also some that says it does.

From my personal experience it does, but its not a direct in place upgrade. This moves from 1.1.0.7 to 1.2.0.5. As Greg mentioned it requires a new config file. So dont expect it to work with the old file.

If you have merged / replaced your config file and are still having issues. Please say so. I would like to get this published in updates.

I haven't done anything since replying in #27, and will confirm that this still does not fix the problem. The tree view works now, but trying to view any object in the tree fails with errors.

I've completely replaced my config.php file, and I'm still having the problem described in #34: I can see my tree, but trying to browse it results in:

Our attempts to find your SCHEMA have failed (objectclasses)

I can't find a summary anywhere of the changes in config.php from 1.1.0.7 to 1.2.0.5, but I uninstalled 1.1.0.7, removed /etc/phpldapadmin, installed 1.2.0.5, and customized the config.php that was installed. Looking back in the version control history for config.php, it seems that the style for configuring servers has changed from

$i=0;
$ldapservers = new LDAPServers;
$ldapservers->SetValue($i,'server','base',array('dc=example,dc=com'));

to

$servers = new Datastore();
$servers->setValue('server','base',array('dc=example,dc=com'));

I have the 2nd style in config.php, and I still have this problem.

OK, this bug is apparently related to #427842. http://ubuntuforums.org/showpost.php?p=9230305&postcount=2 posts the following suggested fix: Create fixRootDSE.ldif containing the following:

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: to dn.base="" by * read
olcAccess: to dn.base="cn=subschema" by * read

Then run

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f fixRootDSE.ldif

I did this and it has at least partially solved the problem. The "Our attempts to find your SCHEMA have failed" messages have now gone away.

What I'm left with now is apparently a template problem: every time I try to view a tree object, I get prompted to "Select a template to edit the entry". Also, when I view the root node I still get a long list of "Automatically removed objectClass from template", "Automatically removed attribute from template", etc. Is this just an upgrade to 1.2 issue?

I don't seem to be able to run ldapmodify using sudo - the above command returns an insufficient access message.

kirk@freedom:/tmp$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f fixRootDSE.ldif
[sudo] password for kirk:
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={-1}frontend,cn=config"
ldap_modify: Insufficient access (50)

Followed Andrew Schulman's suggestions in post #38 and got the same results: After loading the ldif file the message "Our attempts to find your SCHEMA have failed" has disappeared, but viewing an item in the tree gives the long list as he describes. Furthermore, all my entries appear to be empty. I cannot edit any of the attributes (like name, password, etc.): they all seem to be removed. Using the both the command line tools and the LDAP Account Manager web interface (http://packages.ubuntu.com/lucid/ldap-account-manager) I verified that the details are still present in the LDAP tree (and using LDAP for authentication also still works). Incidentally, LDAP Account Manager also has problems modifying the LDAP tree, so this could mean it's not phpLDAPadmin that is the culprit here).

My machine is also an upgrade from Ubuntu 9.10.

I tried a few other tools to look and and modify my LDAP data - none of them can view and change properly. I tried:

Luma was able to connect and browse tree, but object properties would throw errors about server schema problems

EDSAdmin could also see the names, but looking at the properties of any person showed a blank page (which might be how EDSAdmin indicates an error?)

GQ LDAP client seems to have problems connecting to the server, and I cannot see any data at all.

So Lennart might be on to something here - is this perhaps not a bug in phpldapadmin, but rather openldap? PHPLDAPAdmin seems to suffer just like these other clients do.

In the mean time I have also tried another LDAP admin tool. I used Apache's Directory Studio (http://directory.apache.org/studio/) and that seems to work fine.

I also found out that my problems with the LDAP Account Manager were due to a misconfiguration on my part (I had turned on SSH key management in the user interface, but that requires a change in the LDAP schema's that I hadn't applied). Now I am able to use LAM to edit my LDAP. It did need Andrew Schulman's fix in reply #38 to get this working though.

I will try to set up a new LDAP server from scratch using Ubuntu 10.04 in the near future to see if my problems are related to the upgrade from Ubuntu 9.10.

From the Debian bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578981

"Would you please try to remove your /etc/phpldapadmin/config.php and run
dpkg-reconfigure phpldapadmin, or otherwise manually upgrade your config
file?

I'm sorry, but no automatic upgrade can be performed for the configuration
file, which changed between the releases; the best I can do is to document
such a change in README.Debian and/or NEWS.Debian.

Best regards,
Fabio"

--

For those still experiences issues, can you try the above suggestion.

As per comment #27, this is how I arrived at the state I'm in - where the tree is visible but the details of the objects throw errors.

Is there value in my trying it again? I've changed nothing since I last ran the command. It looks like comment #37 also has already run this command.

Indeed, per comment #37 that is what I've already done and I still have the template problem.

This bug was fixed in the package phpldapadmin - 1.2.0.5-1ubuntu1.10.04.1

---------------
phpldapadmin (1.2.0.5-1ubuntu1.10.04.1) lucid-proposed; urgency=low

  * New upstream release
    - Fix compatibility with PHP 5.3 (LP: #551269)
    - Fix error on renaming a CN (LP: #384157)
  * SECURITY UPDATE: Input passed via the "cmd" parameter to cmd.php is not
    properly verified before being used to include files. This can be
    exploited to include arbitrary files from local resources. (LP: #511189)
    - Fixed by upstream release
    - CVE-2009-4427
 -- Stefan Lesicnik <email address hidden> Fri, 14 May 2010 18:48:40 +0200

To be clear - I have version 1.2.0.5-1ubuntu1.10.04.1 installed, and the bug is not fixed.

I'm not sure why this was marked as fixed - the proposed fix in this bug report does not work. Can it please be re-opened?

Looking back at this now, I think the original problem (incompatibility with PHP 5.3) has been fixed. What's left is a mixed bag of problems caused by the change to PLA 1.2:

  1. PLA now needs read access to dn.base="" and dn.base="cn=subschema"
  2. PLA now requires everyone to customize the default templates for modifying or creating objects, if they don't want to have to select which template to use every time they want to view or create an object.
  3. PLA now spews errors by default whenever it can't find a template object or attribute in the LDAP schema.

Item 1 is addressed in #38, and items 2 and 3 are addressed in the PLA FAQ (http://phpldapadmin.sourceforge.net/wiki/index.php/FAQ#Template_FAQs).

All of these things add up to a gigantic pain in the ass for us poor unsuspecting PLA users, but not a PHP 5.3 incompatibility - rather a 1.2 upgrade problem. I think we should look for or open separate bugs for them.

Found in another forum post: the solution to problem 2 in #49 is just to remove or move aside inetOrgPerson.xml and posixGroup.xml in /etc/phpldapadmin/templates/modification. PLA will then just use the default template to view objects. These files can be reinstated if a custom editing template is wanted, and probably their <regex> tags adjusted to choose which template should be used by default to modify people, groups, etc.

I haven't tried this with the creation templates but I assume that a similar process holds.

The real bug here is that all of this changed in PLA 1.2 and none of it was documented or set up with reasonable defaults for us poor users.

Hi Andrew,

Thanks for your info. I consider this bug re php 5.3 closed. You are welcome to open other bugs regarding specific issues you are having. As the comments on this bug suggest, upstream has no upgrade 1.1 to 1.2 and many things have changed. Please follow the upstream documentation on the new setup.

Click on this message to recover images

Less bucks for Brand Watch here.Brand chronometers from Switzerland are too pricy, but people look with respect on their owners. Purchase elite watch copy and get all privileges of belonging to elite without paying thousands of dollars.
Learn more...http://tranh.ru

We hope you found this message to be useful. However, if you'd rather not receive future e-mails of this sort from us, please opt-out here .

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit us.