Tried your suggestion.

Removing the entry in ostum_plugins and lines from ostum_config where namespace=2 (originaly plugin ID in ostum_plugins) removed the entry from the UI. Attempting to reinstall produces this again:

Here's the ostum_plugins table after all this:

Table ostum_config contains no lines where namespace=plugin.3

@rgonig2

Have you checked the permissions/ownership of the phar file?

Do me a favor and run the following commands in the osTicket directory:
$ chmod -R 0644 include/plugins/
$ chown -R www-data:www-data include/plugins

Restart Apache and retest.

Cheers.

    Ran those commands:

    Working on restarting Apache... I am not in direct control of that since this is a "resold" cPanel version (i.e. only the cPanel admins at my institution are able to do that.)

    Prior to running those commands, I could view and edit the files in the included cPanel file manager no issue. It now appears I do not have permissions on those files any more.

    As a side you would want to find out what user the webserver runs as. Some web hosts use your username. Other use something else. setting it to www-data is usually safe on debian (and derivatives) but not all linux webservers run as that username. If they are owned by the same user the rest of your files are owned as it should be okay so long as the permissions are good.

    So, I am unable to restart Apache on my server because it is a resold version of cPanel, and the admins at my institution haven't given end users the ability to do so. In addition, files in /include/plugins are now completely locked, and I am unable to utilize chmod or chown to change perms/ownership.

    Any ideas? At this point I'm wondering if it might be worth to restore from the last v1.10.4 backup I have just before upgrading, and try doing the upgrade manually, as opposed to doing it through Softaculous.

      rgonig2
      I think it would be a lot cleaner if you have a good backup of your v1.10.4, then do the upgrade manually
      To find out which user you are using you can run command ls -l /pathToYourOsTicketInstallation like said @ntozier normally www-data:www-data

        I would talk to your host and tell them the problem that you are having and see if they can change the files permissions for you.

        File permissions are back. Any further suggestions?

          Clean manual upgrade (not via Softaculous) still produces this issue.

          My last ditch effort here was to:

          1) Restore to the last backup of v1.10.4 that I've got
          2) Manually delete the plugin entry in ostum_plugins table and objects in ostum_config where "namespace=plugin.2"
          3) Delete auth-ldap.phar from include/plugins
          3) Upgrade via Softaculous
          4) Re-upload auth-ldap.phar
          5) Re add plugin via UI

          Same result. Defunct missing.

          Worth noting that part of the reason for this upgrade is that my host disabled support for anything less than PHP v7.1, so I am upgrading from an osTicket version which is incompatible with the server it's on, to a version which is compatible. Is there a chance this may be the issue?

            rgonig2
            To rule out the server incompatible, why don't you set up the osTicket locally and do the upgrade, then upload to live server?
            Setup XAMPP or something similar: https://howtohelpdesk.com/install-xampp-on-windows-10/

            Then setup osTicket, like you would in your server, and restore backup v1.10.4 and upgrade
            If everything goes well then take a backup and upload to live server and restore the database

              4 days later

              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.

              Maybe nuke it from orbit.

              And manually install things.
              See if that works.

                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.

                  I just tried to install the AD plugin and had the same result rgonig2. Fresh install in cPanel environment and I have never used the AD plugin before. PHP 7.1 (7.1.26) As soon as I installed the plugin, I got defunct-missing. The only remedy was to delete the plugin from the filesystem and delete the record in the plugin table...though I don't know what else breaks when you delete the record.

                  Sadly, I can't use the AD plugin at the moment. I would really like to. My university campus frowns upon non-SSO accounts. Wish there was a plugin that used shibboleth as that would be the best option.

                    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....

                      @awstech and @rgonig2
                      When you get the error "(defunct — missing)", if you click on that what you see?
                      normally it means you don't have correct permission or that plugin is not incorrect path: /include/plugins