Topics created by ablohowiak

@ablohowiak Maybe play with the image settings (e.g. Image Type and Image Manager) might make those images work again. As we don’t know your settings it’s just a wild guess. But if the images worked on your 1.4.4 server they should work on 1.5.4 just as well if you get the image settings right.

@Sebastian-Roth

Your idea sounds like a good compromise. Something like delete old file on new upload checkbox that is checked by default maybe?

okay, that makes sense. I forgot that the images folder only syncs folders tied to an image in the table.

I tried your update and that fixed the file getting set to 0kb. I test when I can, as FOG has a lot of potential in my eyes and I know most if not all of you are doing this in your spare time, which means a lot. I’m hoping someday I’ll have time to learn PHP and contribute more to the project, but that’s a battle for another day.

Posted in feature request and tagged you and this post for reference.

@ablohowiak Can you please let us know what the issue was? Others might find this information helpful as well.

@tom-elliott Cool, that worked perfectly 🙂

Yes, that worked.
Thank you.

@ablohowiak said in Database Maintenance:

What tables would be useful to locate old hosts?

hosts and hostMAC

I can help with the SQL if you have questions. Whatever you come up with, we can probably add it to our existing list of maintenance commands with a little description for each one:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL

@Junkhacker I suspect the same.

Or, it could possibly be something else. Remember that time I was beating my head against the wall for a week over why the fog server was crippled? Turned out it was a broken fiber cable left laying unfixed for a week by a piece-of-trash contractor that should have been fired.

Not saying it’s a broken fiber cable but… it could be the last thing you would expect, something very wild and off the wall.

@Wayne-Workman
Hi,
Ok i understand.
Actually majority off our classroom reboot at the same time for software update in night (same time is residual effect with green fog on old version).
I will adjust power management (good amelioration in this version) for spread out this reboot.

Thanks.

I’m solving for now in that the group bad entries should he corrected for. I won’t know for sure until I get a bit more of a testbed but I still have had 0 luck in replicating since this was brought up and RC 11 was pushed out.

@Joe-Schmitt
RC11 has started out well. I did need to rerun the install and reboot the system before the client updater started working. The GUI remains responsive even after all the clients start up in the morning. After a few days I may try shortening the client communication period from 900 so the snapins run more timely.

@Wayne-Workman
We were running 1.12, up until sometime this spring. Since then we’ve been on a trunk version. The last update was from RC8.

I would say over 10k clients. I’ve turned off the client updater for now. We’ll use something else to get the legacy clients updated to version 11.

Top was showing a load average of 147 when class was in session in RC8. Often mysql would be the highest cpu utilization, but then there would be dozens and dozens of apache2 instances. With RC9 the load average doesn’t climb so high, but there’s a bit broken too.

They don’t lose storage groups going from 1.1.2 to 1.3.0 (any rc you want).

They don’t lose storage groups going from and version 1.2.0 and earlier because Storage Groups for snapins didn’t exist at all.

Trunk introduced the idea that snapins work in a similar fashion as images and because of this should be allowed to replicate and move around to different groups and nodes.

So it’s no surprise they don’t have group settings defined. This is because we don’t know (we being the FOG team) how you intend to use your snapins and think it’s safer to allow you to setup how you need it setup.

Please define your relevant storage groups and reupload the files as needed. This should fix the storage group problem for you too.

This is already resolved, but it’s completely separate of the posting. This one is specific to hosts, and has been addressed here:
https://github.com/FOGProject/fogproject/commit/aa2184d73dc6dbb5dd513effa1fbc99e72ce768b

If you look at the last item, that addresses the host snapin checkbox issue.

@Tom-Elliott Yes. Thank you.

@Tom-Elliott Thanks! this did the trick. WOL to groups is now working, but the apache log is spitting out this error now.

[Thu Aug 11 07:17:07.370532 2016] [:error] [pid 32376] [client 10.100.150.44:64341] PHP Warning: array_count_values(): Can only count STRING and INTEGER values! in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 111, referer: http://fog/fog/management/index.php?node=group&sub=edit&id=1532

@ablohowiak As a side note here, if you’re 100% new client in your environment, remove the legacy password in fog, just blank it out in the fog config defaults, and on hosts via groups. The legacy pass has security vulnerabilities.

Group snapins should properly deploy. Will be available for RC-5.

@ablohowiak I’ve updated the code already to give a 600ms wait time. I think relying on 3 characters would be good, but sometimes I find it’s useful to be able to search using a single character. The original delay was set at 300ms. It should give a fair balance I think.

If you update again, I’ve taken (I think) a cleaner approach to showing the membership list information. It should still work, but also no longer timeout. It should even be “faster” than it was before.

I’ve also heavily modified the deploy functionality from groups as well for a similar effect, but it is a little harsher on speed as it has to load the object in an iterative fashion, versus try to obtain all objects all at once.

Upgraded from v1.12 and not all storage nodes were up or had the correct id/password combination. Removing old storage and fixing credentials fixed this. In the previous version snapins did not validate the fog user.