Nick Howitt wrote:

That is a bit horrible as it is really a 7.4 package. All will be fine when the installation falls back to the community repos after 30d or after Home/Business is released at 7.4. The problem is for new installations only and potentially people coming to try out Community.

Please make your voice heard at the next tech meeting Nick. In version 6, we had clearly defined product and release trees:

- community

   - 6.7.0

   - 6.8.0

   - 6.9.0

- professional

   - 6.7.0

   - 6.8.0

   - 6.9.0

From a software release point of view, this workflow works great. However, in ClearOS 7, the repo system was changed and now there's only one product and one release tree (!)

 - clearos

   - 7

All 3 products (Community, Home, and Business) and both versions (7.3 and 7.4) have to squeeze into this version 7 repo architecture. There are a lot of tricks to get things working and it's... not ideal.

Hi Ben. I hear what you say, but when an installation fails from initial DVD installation, that bothers me as it smacks of a quality control issue. I managed to fix it - but I was a software engineer .. I struggle to see what problems - and therefore lack of confidence - this would give to less qualified persons!

Hi Ben,
That is a bit horrible as it is really a 7.4 package. All will be fine when the installation falls back to the community repos after 30d or after Home/Business is released at 7.4. The problem is for new installations only and potentially people coming to try out Community.

There is also a report of it hitting Home as well which surprised me as I thought that was on verified repos only.

Make sure you have 2.4.2-1 of the package app-dashboard.

yum --enablerepo=clearos-updates upgrade app-dashboard

B.

I'm in the same boat; (Community edition - new install). Have installed/reinstalled app-events and app-dashboard .. no change!

Here's the error ...

[Mon Oct 23 11:40:04.833161 2017] [:error] [pid 9851] [client xxx:50449] PHP Fatal error:  Call to a member function get_registered_widgets() on a non-object in /usr/clearos/apps/dashboard/controllers/placeholder.php on line 74, referer: https://xxx:81/app/software_updates

I'm in this very same situation since yesterday on all the new installations that I perform. This wasn't happening until Friday.

Is there any problem with the dashboard packages?

And the problem is fixed! Many thanks Ben. Hope perhaps this thread will be of assistance to someone else if a similar problem arises.

Hi Gordon,

The issue was identified and resolved...it's a bug..but it comes from a very strange usability issue. You had app-events-core package...this package provides libraries, language files, packaging metadata etc. However, you didn't have the 'UI' RPM that corresponds to it...app-events.

Running:

yum install app-events

Brought in the necessary controller that your dashboard was trying to access.

It's a bug in that, I check for the package installation to determine what widgets are available...but I'm checking for the deploy/info.php file to determine whether a dashboard widget is available. At some point, you deleted the 'Events' app, however, deleting via Webconfig only deletes the UI package (app-events) since the app-events-core is required as a dependency to a whole host of other core apps (since these apps may use "Events" libraries to create events).

So..the fix in your case was to install app-events app.

The bug report, which I'll file, is not to depend solely on the deploy/info.php file to determine dashboard widget availability.

Thanks for remote access.

Ben

Ticket has been submitted, thank you

I tried logging into the webconfig interface from Internet Explorer and got an HTTP 500 error, never showed in the other two browers on a different OS. This indicates a server error of some sort but is quite broad. One suggestion was that a file permission was wrong. I looked at all the apps in the framework->cache directory and all were set to -rw--r--r status. Making changes on the app-dashboard to 777 permissions and restarting weconfig made no difference. Doing the same with with some of the webconfig aps caused an inability to complete the login process, so I restored all of them to what was the default. Any thoughts about permissions being the problem?

Ben, just saw your message and I will proceed with your suggestion for help. Thank you!

Hi Gordon,

This type of issue is difficult for you and Nick to troubleshoot back and forth over forum posts.

It very well could be a bug, although I've not heard of it before. If you're interested, create a support ticket and put my name in your ticket along with the 'dashboard issue' note. On the ticket, select the remote access 'help type' field selected (you'll be giving me remote SSH access to your server temporarily).

I'll fix it and post the solution back here (or fix an upstream bug if that's what it is).

Of course, I wouldn't charge you for this ticket.

Cheers,

B.

Thank you Nick for the suggestions. I am running a paid version but without paid support. Here's what I did: restarted webconfig. No change. Reinstalled all the dashboard modules. Restarted Webconfig. No change. Reinstalled all the webconfig modules and restarted the webconfig service. No change. Rebooted the server. No change. I'm starting to think that the only solution for this problem is a server reinstall. I'm coming up on renewal time, and will see if I can get the question asked before I spring for another year of paid service. Someone questioned hardware in a response, I don't think it is a hardware problem, the server runs on a recent model Dell with an I5 and 8 gig memory, plenty of hard drive space. Also, before I forget, just to make sure it wasn't the browser throwing rocks, I tried logging in from Safari instead of Firefox, with the same results. Going to switch over to a Windoze box and try Explorer as well, just for fun, but I don't think that will be the answer either. Thanks to all who have responded so far. Still digging.

You could try reinstalling the modules with "yum reinstall app-dashboard*" and you can do the same with the webconfig. I'd suggest after either that you do a "service webconfig restart".

You could also raise a ticket as you have a paid-for version, but if you don't have a support package there is no guaranteed turnround time.

Just getting back to this. My system is up to date with YUM UPGRADE, shows no packages to be updated. Running the tail command in a terminal window on Mac OS while logged into the server as root and refreshing the dashboard page gets no results. The tail command lists several references to the mail server and nothing else. Is it possible to reinstall the app-dashboard.noarch and app-dashboard-core modules using Yum to fix this problem? Or would the entire webconfig module need to be reinstalled. Thanks

Gordon

( and to Tony -- the Buehler reference comes from an old movie where the teacher was asking for his class to respond, and calling on Mr. Buehler when no one else did, i.e. a joke on my part.)

We need better diagnostic info, and assurance that the hardware is OK. You might not have instigated this - but your system could have corrupted itself... My 7.2 doesn't suffer from this - but then it is the Community Edition. I don't know all the differences...
For instance, are the files, or at least some of them, from the packages still there, but the rpm database just doesn't have an entry any more? Seems likely...

Since the system normally runs so well, I rarely log on.

Not the best idea - makes it so much harder to relate the time the problem started with a possible cause. Leave it too long and the logs showing the problem could be rotated out and gone for ever... I had this happen when in hospital, By the time I was out the logs I wanted were gone. I now save three months worth.

Software... examples to try
rpm database corrupted?
# rpm --rebuilddb
missing files from package(s)
# rpm -V -a > /tmp/rpm_interity.log # then analyse /tmp/rpm_interity.log

Hardware - for instance...
Memory problem? - run a memory stress test http://www.memtest.org/
How are your disks - looked at the smart data?

Has power been lost and the system therefore not shutdown properly at some point?

I don't understand the reference to "Buehler????" . A search of the forums doesn't provide a hit...

Anyone? Buehler???? Come on folks, somebody has to have some clue about this problem. As far as not being able to see the mail server, I finally decided to make sure the pop and imap server packages were still installed. They were not, and the greylisting application had disappearded as well. I didn't uninstall them, and the mail server has continued to run, so now I am really at a loss. Guess I will have to refer this to tech support, since it appears to be a flaw of some variety and not something that I have done. If both of those services disappeared, I guess the dashboard ap has done so as well.

Not what I am saying. When I log in via port 81, I am taken to a blank screen. It should display the dashboard, but does not. This is the address string: https://192.168.1.1:81/app/dashboard.
If I delete /app/dashboard and reload it takes me to this screen -- https://192.168.1.1:81/app/base/ -- which is visible. So the web interface is working to some extent, but the dashboard page is not visible. I tried your suggestion, ran yum upgrade and end message was no packages updated.

Using the tail command, all I see is a series of server mailfilter messages similar to this one: "Mar 17 16:46:56 server mailfilter: successfully completed (sender=onlineeducation@ldn1j.top, recipients=marianne@wa4rts.net, client_address=127.0.0.1, id=<1066320998071106610239988486136295@araicng.ldn1j.top>" Refreshing the dashboard field does not create an entry.

And, as I mentioned, there is no reference to my imap or pop servers on the messages screen. This all seems to be a result of the version 7 upgrade, version 6 pro didn't do any of these things. There is no mail report in the reports menu, which is what I was originally looking for. I can go and check the mail logs in a terminal, but I am pretty sure they should be part of the reports. It is as though my mail server is not a part of the system, but it is running fine. Weird.

Thanks for the help!

Gordon

Are you saying Webconfig (on port 81) seems borked?

First, try:

yum upgrade

From the CLI as root...make sure you're up to date.

Next, refresh the dashboad page while tailing the system log file:

tail -f /var/log/system

You'll likely find a stack trace...post that, and we'll see what we can do.

B.