@rgonig2 and @softaculous
Does this mean that the issue has been resolved?
Plugins "defunct-missing" after v1.10.4 to v1.11 upgrade
So then should I close this thread?
ntozier If you'd like, unless you can think of any devs who might be able to provide insight into how osTicket loads plugins, and in particular what services are used to do so? I ask because my institution added me to their cPanel dev environment, and there are no issues there, which leads me to believe there must be some difference between the two environments in what osTicket needs to load and run plugins, the trick is just figuring out what...
I have an idea.
Can you:
remove the plugin.
unphar the plugin and put that directory in your /plugins folder?
Just to confirm:
Remove auth-ldap.phar from include/plugins
Unpack auth-ldap.phar
Place unpacked filed back into include/plugins
Nothing with tables.
All you need for plugins is the php-phar extension installed and enabled. This will do all the work of unpacking the phar and loading it.
Cheers.
- Edited
@KevinTheJedi Phar is bundled with PHP as pf version 5.3 and enabled by default. So there shouldn't be anything that needs to be installed. But it does need to be enabled. (ie it has to be turned off on purpose to not work... there is a command line --disable-phar that is used to shut it off.
the same name as the plugin phar had. So auth-ldap.phar would become a folder named auth-ldap.
The contents of the auth-ldap folder would look like this:
- Edited
It's been a while since I did it... I think I just wrote a quick php script to do it.
I may have been lazy and used a website to do it... but I think that I did it via script.
downloading the current phar and unpharing it results in
The other folders I have that you dont have could be from a past version of the plugin... or from me mucking around with the plugin.
Okay, then yes, in that case it appears I've got the right files as well, in /plugins/auth-ldap
I also tried updating the path in ost_plugins from plugins/auth-ldap.phar to plugins/auth-ldap, to no effect.
I feel like something is preventing it from loading. Perhaps its something like SELinux or security_mod or another security product I'm unfamiliar with.
We tried to debug this by checking osTicket code. osTickets shows (defunct — missing) message when phar class is missing or phar files does not have executable permission.
We could replicate this error message in manual installation ( i.e Without Softaculous ) when we kept non executable permission to auth-ldap.phar.
There are few things which needs to be checked :
1. Is Phar installed correctly ? You can check phar configuration in phpinfo.
2. Is auth-ldap.phar present and has executable permission ?
softaculous @ntozier so, still working though this issue with my institution cPanel admins and support. We've got the plugin working (not defunct missing, can access settings for the plugin) in our dev environment, but we're still trying to figure out how the hell we actually got there since it just turned up that way when I came back to work after the weekend.
My hunch (considering the installations at this point are identical between our dev and prod environments) is that it's a service running on the server causing this issue.
However, in attempting to debug, we found another issue which may warrant it's own request in Git. When the plugin is installed correctly, but configuration (bind details, account credentials, etc...) and a user who is set to be authenticated through the plugin attempts to login, raw user credentials are present in the stack trace error generated (only occurs PHP 7.1 and up, as lower PHP versions do not include stack trace in error logs):
- Edited
Maybe I'm missing something...what is the issue with the un-hashed passwords? That they appear in the logs? That's a PHP thing, it logs the function called and everything passed to it.
Here is an excerpt from a dev on PHP's issue tracker:
you shouldn't enable display_errors in production so this shouldn't have any security impact on your site (and secondly, an attacker shouldn't be able to use those credentials to connect to your database from remotely, but that is not in the scope of this question), but hiding the password by default would be a PITA (Pain In The Ass) for those people who are using the error reporting to track down problems like a configuration error, where the connaction fails, because for some reason a wrong password is used.
So in theory this is good as the errors aren't displayed to users, no one should be able to access your server logs, and sometimes the credentials are necessary when debugging.
Cheers.
KevinTheJedi I may be misunderstanding my institutions issue with it. I'll ask and see what I can figure out.
Updated my response just now ^