Capone and Multicasting not possible?
-
So you didn’t upgrade before when I asked you to?
-
To fix
Open MySQL preferably in phpmyadmin
Or from terminal
mysql -u root [ -p only if you set sql password ][code]
Update fog.pxeMenu set pxeName=‘fog.multijoin’ where pxeID=‘7’;[/code] -
By the way, I haven’t edit the files you mentioned. This simply happened by me selecting “All Hosts” for fot.multijoin.
-
[quote=“Tom Elliott, post: 39021, member: 7271”]So you didn’t upgrade before when I asked you to?[/quote]
Tom,
I upgraded yesterday morning before I made all my posts. I’ve been on 2637 all this time.
-
After that is fixed update svn on server by cd location/of/svn/download
Run
[code]svn up
cd bin
sudo ./installfog.sh[/code] -
This post is deleted! -
This post is deleted! -
Got 2643 running. I am able to join the session with unregistered hosts. Multicasting isn’t working though. I will try a different switch.
-
Turns out it IS working, it’s just that if the other hosts join AFTER the multicast session has started, they won’t get imaged. I guess that’s the way a session works, by specifying how many hosts you will image with the same image. The third host waits indefinitely to get imaged but it never happens.
Unfortunately this will not work for me. I think Unicast or pre-registering hosts will be my only options.
-
Tom,
Let me ask you something. A different group from the company is using another PXE server for their deployments, “Frisbee” I believe it is. In their server, when a host joins the image process after it has started, it will begin from the current stage, and then at the end it will fill out what was initially missed.
Does Fog have the same functionality?
-
No it doesn’t, nor would I know how to tell what segments have or haven’t been copied.
-
I think Capone and a decent Gigabit switch should be OK. I will limit my imaging to 8 hosts at a time. Thanks, Tom. I’ll make sure to get you a six pack of beer.
-
I’m looking up frisbee software to see if I can use any of their source code to help you out, but don’t expect any miracles.
Capone is quite capable of doing what you need, even if it doesn’t support multicast.
I really don’t want to try playing with multicast on the capone side as it’s one of my (personally) most hated features (multicast that is)
-
I will also talk to the Software guys about their server and how it actually performs that function that I explained (ie. starting from the current multicast stage, and then finishing up on the second loop). It’s a nice little feature to have.
Say you have 30 hosts to image, and initially 5 come on simultaneously.
Image multicast Loop #1: Image Host 1, 2, 3, 4 , 5
Half way through, hosts 6-14 join, and they only have 50% of the image (the second half).
Image multicast Loop #2: Image Host 6,14
Half way through this loop, the rest of the hosts join
Image multicast loop #3: Image the remaining hosts.Now, this is assuming they all join simultaneously. Which might not happen. With the wait of 1 minute, you might get as many as you can at the same time.
The problem now is that if a host joined after the multicast session it will remain there idling indefinitely.
-
I understand, but let me try explaining what happens in our system which could lead to potential troubleshooting ideas.
FOG Is an imaging solution designed to take an image from a system and put that image back onto other systems. (We all know this but I think it’s good to re-clarify sometimes.) This is all wrapped together by a Web based GUI to control the process(s).
The way it works, from a very basic level.
Take an image from a (registered) system.
Register a new system.
Register that system.
Assign that new system an image.
Perform imaging task as needed.
In the case of “bypass” or “capone”
It works as such:
Take an image from a (registered) system.)
(in capone methods)
get the dmi valued item and test against database, if they match, get the image associated for that match (or present option incase multiple images match the value needed.)
(in bypass methods)
image the system using the selected image association information.You’ll notice in both of those methods, the downloading system doesn’t have registering.
In the new case of multicast session joining (registered or not) this is not in play at all.
Basically, you create the session. There’s no knowledge of the system. As PHP/HTML is limited in what it can access and start, we create what’s known as subshells. These subshells call the system and invoke the start of the required broadcasts on a loop system (which is also a php script).
It’s because of this that you’re seeing the hanging.
Basically, when it starts the multicast broadcast, the server starts the program udp-sender, but it’s in what I call a “chained” command system.
So on the server after the session has started, you might see a command running in the likes of:
udp-sender max-clients blah filename.img blah port blah;udp-sender max-clients blah filename2.img blah port blah; more blah possibly here
All in one line.
What these chained commands do is:
run the first command, once that’s all done (regardless of failure or success), run the second command, once all done (regardless of failure or success) run this command, and so on until all the commands are complete.Using this model works, and works well, but there’s no real way under the processes of udp to know what client is where and when it received a specific subset of data. The closest we have is the progress of the tasking (registered hosts only) which only tell us how far partclone is in the process not which udp packet it’s receiving.
Hopefully this helps understanding of what’s going on and why things might hang.
Probably would be helpful to explain how the client get’s the data also, to understand why the hanging is more than likely occurring.
When the client boots, it’s given a series of kernel arguments some of which we can call on in our scripts as variables to know what’s going on and what needs to run. The variables these clients get are things like the image, format, type, partition, if multicast is to be used, and the port mc is needing.
The client then boots, runs through partition layout setup, and after partitions are done, it sets up the udp-receiver to get the data. It has no clue what’s happening and isn’t the reason for the failure…directly. All it does is make the connection to the udp-sender on the server. Once it connects it waits until the sender is sending the command. partclone may be in a “waiting state” because of this because the sender potentially hasn’t started the tasking yet.
Where the problem lies, is partclone is just waiting. If the previous command has run, the client has no clue, so it’s potentially possible for /dev/sda1 to try receiving the data of /dev/sda2.
However, what’s hanging is partclone can’t actually do anything with the data as it’s waiting for the data to populate for the particular partition. This is kind of a good thing, though a PITA I’ll admit.
Now hopefully it helps explain things a little bit?
-
Thanks for the explanation, Tom. Makes much more sense now. So yes, implementing that functionality from Frisbee would be a complicated mod.
-
We use capone all day long, and we can image 20/30 computers at the same time with 10Go images, in 3 min !!!
(always sorry for bad sentences) ^^
-
[quote=“TheKoR, post: 39052, member: 24285”]We use capone all day long, and we can image 20/30 computers at the same time with 10Go images, in 3 min !!!
(always sorry for bad sentences) ^^[/quote]
Can I ask about your setup? Are the images stored on the same location as your Fog Server? What switches are you using?
-
server : Lenovo S20 Thinkstation, 8GB, dual GB ethernet card (loadbalancing) Ubuntu 12.04 - Fog 1.2.0
one raid1 160 GB velociraptor Fog system
second raid1 3TB 7200tr/min StorageSwitch : All 4806W + 2 AT-GS924GB all connected with fiber link
-
[quote=“Tom Elliott, post: 38999, member: 7271”]I’m afraid you’re stuck being afraid for now?
I’m not trying to sound rude or crude, but some of these things are set in such a manner for some semblance of security. You could play with the source code to have it work for you.
First you’d needed to edit the FOGConfigurationPage ‘disabled’ part on pxe setting function. You’d make line 278 of the file /var/www/fog/lib/pages/FOGConfigurationPage.class.php from:
[php]‘disabled’ => $menuid ? ‘readonly=“true”’ : ‘’,[/php]
TO:
[php]‘disaabled’ => ‘’,[/php]Then you’d edit BootMenu.class.php to move the $_REQUEST[‘sessionJoin’] settings on lines: 572 and 573 to right under line 159.
Then you edit on the GUI side (fog.multijoin) and remove the lines stating:
[code]login[/code]
[code]param username ${username}[/code]
[code]param password ${password}[/code]That should remove authentication from the mix. That said, I’d highly recommend against it.[/quote]
[LEFT]I am newbie[/LEFT]
Help Please To be changed so that the multicast launch a task not ask password and session
[LEFT]
[/LEFT]
