Latest Development FOG
-
[quote=“need2, post: 37606, member: 21891”][CODE]svn co https://svn.code.sf.net/p/freeghost/code/trunk <where ever you want to save the downloaded code>[/CODE][/quote]
Thank you… i want a do over… on this week… let it be friday night again.
-
SVN 2408 released.
This has many mods and should fix many separate issues, if not all that have been occurring. In earlier svn releases.
-
SVN 2418 released.
With this comes, after a slight break, the Client Ignore and Image Ignore checkboxes should work. I know the client works, but haven’t quite fully tested the imageIgnore option though from all appearances it should.
-
2419 released.
The problem with the prior approach, while it worked, it reported the host as invalid, which is not necessarily true. So now bootmenu handles for the tasking portion if there is a task for the host.
Services are handled appropriated from what I can tell as well.
-
SVN 2426 released.
With this comes a new plugin for WOL Broadcast Address management.
The idea of this is to allow for people who don’t have access to adjust their networks to send across their relevant broadcast networks.
It’s not perfectly ideal, but the way it works when in use is to send to all of the networks in the list. It also maintains the sending of WOL packets to the main broadcast address of 255.255.255.255. Hopefully this helps you all out.
-
SVN 2429 has bandwidth graph functionality back. It is no longer reliant on the selector.
It will display all nodes and display the colors related to those nodes. There are labels to help you stay knowledgeable on what’s what.
-
SVN 2441 released.
This comes with a new db schema change.
The change is to include a “success” table of the files people use to boot with. Later will come a “report” to be able to give us more a clue.
The idea of this, until ipxe.kpxe/kkpxe can determine if it can use it’s native drivers and switch to undi if it can’t, a method to later on programmatically code what file to load depending on the finding of the success/fail table.
My hope is to get a central location where the local table can be uploaded so we have a more broad knowledge of exactly what systems work with what files. Particularly, which systems operate best with ipxe.pxe and which require the use of undionly.kpxe or undionly.kkpxe.
This isn’t something that’s going to happen overnight. The table has been created and it uploads once the system boots into the bootmenu. If it can get to the boot menu, it’s a pretty safe bet the boot file works.
The table structure is:
id (the inserted item for reference later on)
product (what the product of the system is)
manufacturer (what the manufacturer of the system is)
mac (only used as a stability thing, isn’t really required I don’t think but could be useful to determine nic manufacturer)
file (the file that is being booted from. This is picked up at boot time through the Option 67/filename setting of your dhcp server)- NOTE * The reason for the file using the filename. I’m going to be making requests on an off about which file to use. Rather than simply changing the file name to undionly.kpxe as I’ve requested in the past, I’m going to start making requests to change the filename/option 67 so we have a more accurate filename to compare against.
success (if the system boots to the file it’s successful)
failure (it it doesn’t boot it’s a failure. I don’t know how to make this work though, maybe assume all failures and set to success if it gets to the menu?)
Hopefully this makes sense and we as a community can build a better functioning product.
Also, this particular table can be used to report back to the iPXE team so they can maybe help with programmatically making this happen without the FOG team having to do it directly? Also, it will help them with updating their supported systems and maybe fix unknown drivers and so forth.
So as the community contributes (without you having to do anything specific) we’re not only helping ourselves, but the good guys over at iPXE.
There’s a few other items in this release, but this I think deserved the most mention. The other things that have been added are:
HookManager received, once again, the getEvents method is back. It was removed for performance reasons. I brought it back, but it will only be used for the HookDebugger hook as it needs to know what events exist in order to operate. This should affect many, but for those trying to create their own hooks and or plugins it can be useful.
Changed methodology of picking up the ob_start(‘ob_gzhandler’) and ob_end_clean() to use ob_end_flush(). This function pushes the data without clearing what was sent which cause issues with hooks in general. The hooks system is enabled before the content and page is setup, so there’s no data to work with. It needs the data to be available to hook into it after it’s been loaded. Under ob_end_clean, it works most of the time, but where the data isn’t really parsed it can’t operate. ob_end_flush pushes the cache back to the browser but also allows the data sent to be worked against with the relevant hooks.
Through playing with many database systems, you can setup what’s known as persistent connections. To enable persistent connections, simply add the characters p: before the ip of the host (e.g. p:localhost, p:192.168.100.15) to your Config.class.php file. This isn’t really an added feature just something I thought to note. To help with handling multiple queries and such, I also added the ability to kill the opened thread and properly close the links in the db. This shouldn’t hurt or improve anything more than simple memory management on your server. This is how I found out about the persistent connections and just though noting it would be useful here as well.
The Hooks that come with FOG natively work more properly. SubMenuData can properly be hooked now. Just view the SubMenuData.hook.php (new one) to see what’s changed and how to operate with the submenu data.
This same method works for the plugins as well. You can completely hook in the requires of your plugin for pages and such without having to code the main source for things to function.
- NOTE * The reason for the file using the filename. I’m going to be making requests on an off about which file to use. Rather than simply changing the file name to undionly.kpxe as I’ve requested in the past, I’m going to start making requests to change the filename/option 67 so we have a more accurate filename to compare against.
-
The changes in HookManager.class.php give problems
[Mon Oct 20 13:28:54 2014] [error] [client 158.227.4.135] PHP Warning: array_push() expects parameter 1 to be array, null given in /var/www/html/fog/lib/fog/HookManager.class.php on line 67, referer: [url]http://fog1.ehu.es/fog/management/index.php[/url]
[Mon Oct 20 13:28:54 2014] [error] [client 158.227.4.135] PHP Warning: in_array() expects parameter 2 to be array, null given in /var/www/html/fog/lib/fog/HookManager.class.php on line 66, referer: [url]http://fog1.ehu.es/fog/management/index.php[/url]The WEBUI is KO
-
For more info
[url=“/_imported_xf_attachments/1/1440_Error_HookManager.png?:”]Error_HookManager.png[/url]
-
This should be corrected for in 2442, thank you.
-
How far out are you guys for the latest general release of 1.3 ? Looking forward to this UEFI imaging . Have a ton of tablets that need to get imaged.
-
[quote=“Ray Zuchowski, post: 38053, member: 24449”]How far out are you guys for the latest general release of 1.3 ? Looking forward to this UEFI imaging . Have a ton of tablets that need to get imaged.[/quote]
I don’t know how much longer, but the current SVN should be stable enough if you’re just willing to test it out. More testing also helps us get a closer date for release too. It helps us ensure we can find and correct the bugs that we may have overlooked or implemented unknowingly.
-
Tom is there anyway you guys can add on the imaging report a count for how many computers were imaged ? For example if I select dates 9-12-2014- to present at the bottom of the report it will say current machines imaged . Only work around I was able to do was export it as a csv file and go by cell numbers.
-
Updated to newest version avail and I still get this error every time I restart fogservice to get pc to change name and join the domain.
Current OS- Ubuntu 14.04LTS currently have several small issues with os but fog has been working like a champ until recently.
Current FOG REV-2450 installed and updated today from version 2227. installed fogclient as well and still no joy, rebooted and same.**** this is from the fog.log file on the local machine trying to join domain****
HostnameChanger Attempting to connect to fog server…
10/21/2014 3:13 PM FOG::HostnameChanger Module is active…
10/21/2014 3:13 PM FOG::HostnameChanger Index was outside the bounds of the array.
10/21/2014 3:13 PM FOG::HostnameChanger at FOG.HostNameChanger.changeHostName() -
@Bill Rice
The issue you’re seeing is because of the HostnameChanger.cs file in the fog client is not taking in consideration of the product key.
If you uninstall the client you installed from the SVN and use the installer from the 0.32, 1.0.0, 1.0.1, 1.1.0, 1.1.1, or 1.2.0 you should be fine. The one in SVN was a test build and it recompiled with an improper file. We’re rewriting the service which is why I have not reverted the file yet as it will be complete changed here shortly.
-
SVN 2454 released.
What this release brings is a more proper check to get the start sector of the image you’re trying to deploy.
Basically, 1.2.0 brought in the greatness that is linux resizable, but it made assumptions to the chunk size and start sector of the disk. It assumed all disks started at 2048. I found this out a while ago in reference to Vista/XP images, and made corrections for that, but it did not take in consideration a Windows 7/Windows 8 image that might, for some reason, start at sector 63. This broke these particular types of images.
This should now be corrected for in this release.
Further more, as there are a few changes, it also addresses some issues in the way the MAC’s are parsed. I May have to remove the tasking check in BootMenu.class.php but that’s because it should now be checked by the HostManager.class.php file.
I’m sure there may be better methods for this checking, but basically the method/function: getHostByMacAddresses had the potential to return multiple hosts if you use the ignore MAC stuff. Why? Well, let’s just use the USB nic example we’ve tried making a work around for.
Let’s say you have 10 USB nics, and those nic’s are only used to image systems that don’t have a built in nic besides wireless.
So you set the system to image and all goes fine, but when it completes, the image boots to the client and starts the FOG Service checks.
Under the “problem” we had, you may have put the WIFI address as a separate host so when it connected it would rename, join to domain, or what have you. So now, you potentially, have two nics on the same system trying to request information.
Where the problem lies is the getHostByMacAddresses function. It was getting both of the macs and returning both of the registered systems. The BootMenu system only cares about imaging tasks so it was able to work. Seeing as bootmenu can’t see the wireless nic, all is fine and the proper host is returned. But, once it booted to windows, it knows of both nics and passes it to the corresponding service files. The function was returning the error: Multiple Hosts with this mac address, which is correct. So to fix, I basically added checks in this field. If the Host that’s found is Valid and is in a tasking AND is Not imageIgnored, all is returned properly otherwise fail out as if the host doesn’t exist.
If the Host does not have a tasking, it then checks that the received MAC is not on the clientIgnored list. I’m starting to think all this jabber about it there may be potential issues in booting the host if there isn’t a tasking, but the client is rebooted. I’ll test as I believe I did make these checks too.
Thank you,
-
SVN 2455 released.
Properly fixes legacy resizable images but existing with the d1.original.partitions file.
While the fixes from above are correct, one of the methods I overlooked was checking for the sys.img.000 file. Basically if sys.img.000 existed, it preset the file information to what was assumed. This still happens, but only if the d1.original.partitions file does not exist, which really should only come from 0.32 (partimage) or I believe 1.1.2 and all between before the new resizable linux stuff was implemented.
-
ok updated to the latest and greatest
here is what the fog log shows now.
10/22/2014 6:47 AM FOG::HostnameChanger Module is active…
10/22/2014 6:47 AM FOG::HostnameChanger Index was outside the bounds of the array.
10/22/2014 6:47 AM FOG::HostnameChanger at FOG.HostNameChanger.changeHostName()
10/22/2014 6:47 AM FOG::GUIWatcher Message found, attempting to notify GUI!
10/22/2014 6:47 AM FOG::GUIWatcher The system cannot find message text for message number 0x%1 in the message file for %2
10/22/2014 6:47 AM FOG::GUIWatcher at System.Windows.Forms.Form.UpdateLayered()
at System.Windows.Forms.Form.set_Opacity(Double value)
at FOG.AbstractFOGService.attemptPushToGUI()
at FOG.GUIWatcher.startWatching()Tom, you recommend I switch back to the client updater for the 1.2 fog revision and use that?
or have you repaired this one and I should try to install the client updater for the newest revision? has that file changed as well? -
I have since utilized the service from release 1.20 and it seems to be working now as you suggested.
I hope that it will be fixed when the new release is done.
Thanks for your assistance and great work on a Farly superior software package for imaging. -
I have reverted the installer in svn for the fogservice.zip file to that of the 1.2.0 release file. This way anybody else that uses the svn to install shouldn’t continue having the problems.
