Latest FOG 0.33b
-
r1066 should fix all of the above, with some expectation that menu items won’t all necessarily be translated properly yet…
-
All,
r1068 is released.
The only main change is it now includes my kernel off of my server in the kernel-update page. Hopefully this works for everybody. As I don’t have rights to push kernel updates to sourceforge, this method works. I basically took the html from the page the location is obtained.
I added, in kernel-fetcher.php, to perform SSLVERIFY_PEER as false, this way it can actually work with my files.
Hopefully you all are fine with this.
-
r1069 is released.
This one just has sorting methods to sort Published/Unpublished kernels. Unpublished, of course, being the kernels I built. I only have the latest one right now as: 3.12.6, but will be updated/maintained later on.
I’ve also automated my side of the file that generates the kernels, so when there’s a new one I can just add the file to my side of the house and presto, chango, you’ve got it on your side.
-
Here some more bug fixe for quick host registration
when option FOG_QUICKREG_AUTOPOP is enable
the host register is now ok[url=“/_imported_xf_attachments/0/470_auto.register.php?:”]auto.register.php[/url]
-
This issue should be corrected. I modified your code a little bit but it should have the same results.
r1071 released.
-
fix an issue to rename the image file through ftp when the storage group has more than 1 storage node
[url=“/_imported_xf_attachments/0/471_StorageGroup.class.php?:”]StorageGroup.class.php[/url]
-
I guess I’m a bit confused about this issue.
You’re only requesting ftp to the enabled and master nodes?
I think, before I update the function in StorageGroup, I’ll have to take a look at the FOGImageReplicator service. I’m assuming this is where your issue is.
The methods in use for the FOG Service’s (FOGScheduler, FOGMulticastManager, FOGImageReplicator) haven’t been changed (besides the minor changes I’ve made) for a long time and this could be why you’re seeing an issue.
Please try to provide more insight as I don’t think ftping and setting every node as master is a very good idea.
-
r1072 released to make auto.register.php, inventory.php, and man.hostexists.php in line, more or less, with the Pre_Stage1.php file structure/class callings.
r1073 fix image task creation on registration tasks to NOT shutdown the systems once imaged.
-
Hey everybody I have a question Does the beta support multi site yet?
-
Troye,
I have not included the location patch into the core source of the FOG system. I believe it was Lee Rowlett that created this patch (multi-site/location) but I haven’t found any of the source code. It should be easy enough to implement, though I don’t know how used it really is.
I’m willing to add it to the code base if Lee’s willing to release the code to me, so that I can make the proper adjustments where they’re needed.
-
r1074/1075
Updated the kernel update page so it’s methods are slightly neater and changed from onclick to onchange so you can actually make a choice rather than have it try submitting the form every time you click on it.
-
Ok Should I try to contact him. It seems like everything is working but the remote sites will not register to the database the local machines work fine its just the remote ones.
-
HI all,
I have downloaded and installed 0.33b on Ubuntu 12.04 LTS for the sake of testing Fog on our Dell Latitude 10 tablets. After installing and testing, the tablets are still unable to boot to the NBP file that it gets from Fog. The tablets do get an ip and pull the nbp down but does not load to it. Here’s a little background on these devices, they are using a 32bit UEFI ONLY bios and cannot be switched to legacy mode, They can pxe boot fine from Windows Deployment Services off of server 2012 as the wdsnbp file from server 2012 can be loaded by a UEFI device. Any assistance on trying to get these devices to work properly with Fog would be AWESOME.
Thanks,
-
r1077 released to try addressing Lanfeu’s issue stated above.
Rather than changing the StorageGroup.class.php file, I’ve included ftp_put and ftp_rename. If one fails, the other tries. If the both fail we know there’s some other issue.
-
the issue remain with the preview file
this file correct the issue when the storage group has more than 1 storage node
the ftp server use will be define from parameter and the copy to the second node will be done later with fogimagereplicator[url=“/_imported_xf_attachments/0/472_Post_Stage2.php?:”]Post_Stage2.php[/url]
-
While I won’t be using this adjustment, I think I see what the problem is.
When you have multiple storagenodes, it only set’s one of the ip’s to rename, but it tries to copy to the latest one, which it can’t do because the username and password are set prior.
If I bring the tasks that perform the ftp moves into the loop we should be good to go.
If you don’t mind test one more time. I’m updating as we speak.
-
More insight as to why I’m choosing this method over yours is in Host.class.php the ftp that gets sent back to the Post_Stage2.php file is always:
‘ftp=’ . $this->FOGCore->resolveHostname($this->FOGCore->getSetting(‘FOG_TFTP_HOST’))
This mean’s it’s always using the TFTP IP Address rather than the Actual Storage node. This, by itself, isn’t necessarily bad, but your method is essentially stopping the actual storage node from receiving the data.
If I bring the tasks to actually FTP the data into the Loop, it will loop the tasks by themselves and should automatically send the data to both storage nodes.
-
r1078 should correct this, but again I have no ability to test.
This new methodology should push the data to the proper node.
Basically, what was happening before all this, was it would loop through all the nodes but it wouldn’t set the ip, path, or user for each of the nodes, it only did the last node in the loop. The new method should ftp the data to each of the nodes relevant to the host.
-
Oh,
One more reason why I didn’t want to use strcmp is it requires both strings to be the same. So let’s say you set your Storage IP as fog.something.com while the TFTP information is 10.0.7.1, it would always return with a negative/positive (depending on order you check) which would basically stop any task from happening.
-
r1080 released,
More service file updates. Hopefully more streamlined approaches to things.