Git 8147 Enabling Plugins Breaks the Menu
Running Version: 8147
SVN Revision: 5701
When I check “FOG_PLUGINSYS_ENABLED” and save, the ipxe menu changes.
My goal is to re-enable the Capone plugin because everyone misses it. To be safe, I’ve enabled plugins, installed Capone and set associations just to see if the menu would go back to good and it doesn’t.
@Wayne-Workman I suspect all is already fixed in the working area. You can create the log, and if you can see when/where/how the change happened, it certainly will help. I’m 98% sure it’s a specific set of actions necessary though, which is why I can’t seem to replicate it.
I’m certain it has nothing to do with the location plugin, just in case you were going to try with and without the plugin installed.
@Tom-Elliott Ok - how about - I write a logging thingy that will check if the keys are blank or not, and log times and dates.
I’ll do that, and when it happens again, I’ll know when it happened and I’ll be able to see what was going on at that time.
@Wayne-Workman Then I’d have still been able to replicate. There’s nothing in the bootmenu file that’s updating the global settings. (Either by use of setSetting method or updating the Service class).
In plugin class there’s the setSetting to update the plugin location (to always ensure it’s looking at …/lib/plugins) but it is only impacting a single field. Nothing to service at all.
In the plugin page There’s two new entries created/updated but this is only relevant to the Capone plugin. The insert of the new items is handled directly within the CaponeManager class, and the updating is handled only to the dmi and image association.
[root@mastaweb fog]# grep -rl 'setSetting' . ./lib/fog/plugin.class.php ./lib/fog/group.class.php ./lib/fog/fogbase.class.php ./lib/fog/host.class.php ./lib/fog/service.class.php ./lib/pages/imagemanagementpage.class.php ./lib/pages/pluginmanagementpage.class.php ./lib/reg-task/registration.class.php
These are all the files that actually us the setSetting method. This updates the global settings (FOG Settings on config page).
[root@mastaweb fog]# grep -rl "getClass('Service" . ./lib/fog/hookmanager.class.php ./lib/fog/fogbase.class.php ./lib/pages/fogconfigurationpage.class.php ./lib/pages/serviceconfigurationpage.class.php ./lib/pages/groupmanagementpage.class.php ./lib/pages/hostmanagementpage.class.php ./lib/plugins/capone/class/caponemanager.class.php ./service/donate.php ./service/servicemodule-active.php
These are all the files that modify the “setSetting” by means of the Service class. This particular output just displays if the class is called.
lib/fog/hookmanager.class.php: This is definitely not the issue.
lib/fog/fogbase.class.php: This is definitely not the issue.
$serviceEn = self::getSubObjectIDs('Service',array('name'=>array_values($services)),'value',false,'AND','name',false,false);This is not updating any values.
Line 543: Whole method is getSetting. This is just getting the setting information. No writing.
Line 547: Whole method is setSetting. This actually writes data. Only based on the key that’s sent and the value. If either key or value are blank, the whole method will cause a Fatal Error. No update is performed on fatal error.
lib/pages/fogconfigurationpage.class.php: Most likely where things are going awry.
Line 139: Gets the list of services to see. No writing. – This is definitely not the issue.
Line 208: Saves new info to the DB, only impacts the keys as defined in $ServicesToEdit. – This is definitely not the issue.
Line 507: Just gets the setting categories (no writing). – This is definitely not the issue.
Line 510: Gets the fields under the category listing for that iteration. No writing. – This is definitely not the issue.
Line 752: Loops through all the Services to write later on. This is most likely the issue. The problem, though, is the way it updates the data. There are numerous checks. First one is it checks that the item it’s working on actually needs to be updated in the first place. If it needs an update (which ultimately means something changed previously) it will perform the next level of checks. For the next RC I’ve changed the updater from “update” to “set” so it should only impact the item it’s working on to begin with. – Most likely the issue, and hopefully is completely fixed in RC update channel. (Not RC 1).
lib/pages/serviceconfigurationpage.class.php: Unlikely the issue | Fairly certain this is not
Line 265: Updates if the module selected is to be on or off and updates defaults. Only interacts with the specific item. Updated to use a single call rather than an array shift in RC.
lib/pages/groupmanagementpage.class.php: Definitely not the issue
Line 399, it’s used to get the information of the service and print it to screen. No update/write there.
Line 419, used to get info of the service and print to screen. No update/write there.
Line 587, used to get the values of the global setting in case it’s not defined in the group during edit. Info is then passed to the host where it’s updated directly to the main item. Yes a write, but not updating multiple fields accidentally. Only impacts its particular element to all hosts. At this point, however, it’s only for lookup, as writing goes to a totally separate table.
lib/pages/hostmanagementpage.class.php: Definitely not the issue
Line 484, same as line 399 of groupmanagementpage.class.php No write/update.
Line 504, same as line 419 of groupmanagementpage.class.php No write/update.
Modules/services are passed to a separate table.
lib/plugins/capone/class/caponemanager.class.php: Definitely not the issue
Line 16: Inserts FOG_PLUGIN_CAPONE_DMI (not a multi update write)
Line 22: Inserts FOG_PLUGIN_CAPONE_REGEX (not a multi update write)
Line 28: Inserts FOG_PLUGIN_CAPONE_SHUTDOWN (not a multi update write)
Line 41: Deletes the entries created in 16, 22, and 28.
service/donate.php: Definitely not the issue.
Line 9, used to find setting, no write.
service/servicemodule-active.php: Definitely not the issue.
Line 3, Passed to a Module (not the Service itself) and only used to ensure services are enabled (usually at host AND global levels).
@Tom-Elliott We have the location plugin setup and configured, I didn’t do anything special.
In fact, the only time I even visit this settings area is to correct this problem, which has been twice now I think.
All I did was update the main, and then update the storage nodes after that. We’re not removing any plugins, we’re not adding any plugins. Things are setup just the way we want.
It’s just a gut feeling, but I don’t think the update is breaking it. I tend to think that something in FOG Settings somewhere is writing values to the boot menu settings when it shouldn’t - just a guess.
@Wayne-Workman I need exact steps to replicate. I have not had ANY success following anything anybody has stated to replicate this.
For all I know, somebody actually did clear all the fields. I’m not saying there isn’t a problem, all I am saying is I need a way to replicate exactly how to reproduce.
Wayne Workman last edited by Wayne Workman
@Tom-Elliott This isn’t yet resolved, it happened here.
I only just now realized that our boot menu configuration on our big fog server had been completely cleared, we went from a not-too-old trunk version to 1.3.0 RC1.
I’m manually setting them back with what you posted as the defaults a while back.
I updated a few days ago to Git 8450 and it works as expected now so I can’t reproduce the problem I encounter before.
I can add details about my installation : was a fresh install of Git 8xxx on june 20th, I don’t remember which version it was exactly (if someone tells me where to look for to find the previous version?). Then I imported hosts, groups and images from csv files and I’ve just set my common parameters like they were on my old server.
A bit later, I booted a computer from PXE and saw the blue screen so I checked my installation and saw the “PXE Boot Menu” was empty so I filled it up. Then I rebooted my computer and it was ok except for the keyboard layout. I changed it in “general settings” and once I came back to the “PXE Boot Menu”, everything had disappear!
I know it’s not much but I hope it will help you.
@Cavender what about on the most current? If you update the fields back to the default values and retry what broke it before, does it still clear the values out.
@Tom-Elliott I saw this on a clean install of 14.04, fresh git of 8147 (latest at the time of install) and a fresh database:
Everything is up and running great -> enable plugins and save -> the menu config is cleared and everything still works though the boot menu is now classic blue background, white text and red selection bar.
Can somebody give me exact details on what I can try to do to replicate this?
Also, please try deleting the /var/www/fog and /var/www/html/fog directories and reinstalling FOG. This issue you are reporting might be old information impeding functionality of the main system.
If you have custom data you may need, please backup the appropriate files as necessary.
@Sebastian-Roth Unfortunately I’m not.
@Developers Is anyone able to replicate this issue?
I registered to add more informations to this bug. I recently build a new fog server and I encountered this bug. I didn’t know what to do to make the background image back to what it was with my previous server and I found this thread!
I upgraded this morning to version 8405 and this bug is still there.
What it does is wiping out all the informations in “iPXE Boot Menu”. I added all the details in this menu after seeing this thread and as my keymap wasn’t working, I decided to try the fr-latin1 instead of fr-latin9. As soon as I saved the general setting, it cleared the “iPXE Boot Menu” informations.
By the way, my keymap still doesn’t work! I can’t swap the keyboard to the French language.
Just updated from 8215 to 8359 and the boot menu settings stayed this time.
Great! Thank you both!
Just updated from 8215 to 8359 and the boot menu settings stayed this time.
Strange. Here’s the database. This one is new so there’s not a lot going on yet though it is the one I’m having the issue with. 0_1467239575603_fog_backup_20160629_222957.sql
The same thing also happens whenever I change the web UI password.
I still cannot replicate for the life of me, can you get a dump of your DB so maybe I can replicate and more directly see what’s going on?
Menu Background File is:
Main Colors defaults are:
So enabling plugins clears both the menu background file and the advanced menu. Manually replacing these after plugins are enabled and saving does maintain both menus with plugins enabled. If I look to verify that plugins are still enabled (and they are), and just for giggles click “save changes” at “Plugin System” the menus are cleared again.
Menu Background File is:
Ah, I didn’t test re-inputting the menu after enabling plugins to see if it would hold. I’ll do that now and let you know what I find.