http://ssbfacilities.web.illinois.edu/info.php
Phar is enabled.
Fixed!!!!
Workaround was to unphar auth-ldap.phar, point the database to the folder, and set isphar=0. Honestly, still not entirely sure what the issue is in the first place...Dunno if the workound hints at that.
rgonig2 KevinTheJedi @ntozier in the interest of keeping this thread related to the original issue, and also solving the pw one, I've created a Git issue for further work on that: https://github.com/osTicket/osTicket/issues/4793
KevinTheJedi That quote is from a bug report for PDO which reveals the database connection information in the stack trace, which then gets logged. In that context, there's no harm having the password in the log (as long as the log is only available to the site owner and display_errors is off), since the site owner already knows the correct password for the database connection. In the auth-ldap context, the passwords of all users are being revealed to the website owner. That would be bad even if the accounts were local to osTicket, but when the accounts in question are ldap accounts that are used for access to many other services, it is not safe to allow those passwords to be revealed to the owner of the website. Stack traces are only printed to the log for unhandled exceptions. Resolving the problem should be a simple matter of implementing exception handling.
KevinTheJedi I may be misunderstanding my institutions issue with it. I'll ask and see what I can figure out.
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):
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.
Just to confirm:
Remove auth-ldap.phar from include/plugins
Unpack auth-ldap.phar
Place unpacked filed back into include/pluginsNothing with tables.
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...
ramrajone Please read the rest of the thread. I am an end user at my institution, and the server I am hosting on is provided via cPanel. As previously mentioned, I am not able to reset Apache, as this service is maintained at the institution level cPanel and institution admins. The path was not an issue.
As for the perms issue in the first place, the auth-ldap.phar file has a numerical value of 0644 and is owned by the service user.
Attempting to delete via GUI causes 500 server error.
Deleting plugin in directory has no effect, deleting relevant rows in ost_plugins and ost_config table removes plugin.
awstech I'm in the exact same situation here: Shibboleth SSO here with restrictions on local credentials.
This leads me to suspect that there is an issue not with osTicket, but with cPanel (considering we both have the same issue, and non cPanel users are not reporting the issue). Unclear what exactly the issue there might be though....
ntozier Tried by manual, again, no luck.
For what it's worth, I noticed that when I install the plugin in v1.11 (and it immediately goes "defunct-missing"), it does create an entry in the ostum_plugins table, but there are no corresponding rows with namespace=id in the ostum_config table. Dunno if that's diagnostically useful, but I'm out of literally all other ideas, especially considering it appears that no one else is having this issue.
Okay, so, back again. Even trying to install the LDAP authentication plugin on a new install of osTicket on a completely new server still produces this issue. I'm still unable to tell if the issue is cPanel, Softaculous, or something else.
Anyone have any final thoughts? This feels like a dead end at this point.
