Latest FOG 0.33b
-
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.
-
Thanks for all of your work Tom, I know we keep telling you, but I feel if we don’t take rounds you will stop updating
Speaking of update, I’m going to go update my 0.33b server
-
Many thanks for all the good work.
I’m testing capone on 0.33b, on Fedora 20 and getting the attached error.
I suspect the busybox version of base64 doesn’t support the same options as the gnu one, and am trying to rebuild init.gz once I’ve edited it, however it fails after starting the kernel.
I’ve tried uncompressing and re compressing init.gz without any changes and that also fails.what I’ve tried is
rename init.gz to init.xz
xz -d init.xz
xz -z -9 init
rename init.xz to init.gz
The file size before is 8022184, afterwards 8022188, and it doesn’t work
I’m on a recent release,
What am I doing wrong?[url=“/_imported_xf_attachments/0/474_boottest.png?:”]boottest.png[/url]
-
It looks like you don’t have base64 installed on your version of init.gz. I haven’t run into these issues on mine. Is there specific method you’re trying to add for the options? It looks like you’ve removed the base64 from busybox and I don’t see base64 as a target package under buildroot’s menuconfig.
What issues are you having with the busybox version specifically?
-
Hey tom I have a question I am trying to build a VM using hyper v and I am running into two distanct issues one being that none of the vm’s are finishing the host
inventory it stops at the sending to inventoey . so it does add it to fog so I just restart the machine then it picks up the image task and images the VM when lt finishes it does not boot to the os it boots back into the fog tftp and says no active task found for hostname any ideas on how to fix this -
What revision are you on? I had a typo, and am working on correcting another one I found.
r1081 is the latest, and in about 2 minutes we’ll be on r1082.