Latest Development FOG
-
Tom,
The issue with the multicasting I narrowed down to that if a host is registered with no image selected within the host registration section the host has issues and wont join the multicast session. If a host is registered with a different image under host registration then what is being broadcasted in the multicast it loads the script like its about to join the session and reboots. So the hosts deft have to be registered with the image selected that is being broadcasted.
Ray Z
-
Bugs Found SVN 2488
- Host has to be registered with the image being broadcasted or wont join session.
- If joining a session on multicast and username and password is entered incorrectly, you are brought back to the ipxe boot screen however upon retrying to join the session the old username and password credentials are left behind. You have to manually delete this. This should automatically be deleted when retrying to enter credentials.
- On the multicast image management screen when session starts the client count is incorrect. Currently im imaging 5 clients in a multicast right now and it says I’m doing 10.
- Active Multicast- Task Management displays session in State Queued even tho the task is started and imaging.
- Under imaging log reports the failed client hosts are being shown. However only successful images should be displayed or have failed host images in a separate report. This throws off stats.
Easy way to determine off the logs if image failed i noticed was End Date = -42 or if End Time = 0:00:00 . Maybe have that in that in the code if those variables are present discard from the imaging log .
-
SVN 2490 Should fix the registered host only working with the hosts image.
Also adds the image id to the display of the image. This should make finding the image for registration that little bit easier.
Ray:
- Yes, but this should now be corrected for.
- Should now be fixed.
- I think that’s my fault. I’m trying to ensure the client count is set, so maybe once the udp-sender commands I simply need to reset the client count to zero? I’ll give that a shot.
- It’s kind of the nature of the way multicast sessions happen. I will see what I can do, but it’s kind of dealing with the client count parameter which we have know real clue of.
- Again, kind of how it was intended. While the tasking itself failed, the fact it checked in is still valid. Hopefully once I get the quirks of the bugs taken out of the scenario, it should help you out.
-
2492 should fix the client count issue.
-
Theoretically, 2495 should fix the client count but I don’t know. This client count is compared and is what sets the stateID. If they’re equal, it should set it to in-progress.
I’ve added a sess client table that just stores the numbers. It creates the tasking based on this parameter as well if there are no associations (which there shouldn’t be).
This should allow the original clients field to be left as is. This should also then set the tasking to in progress if there’s even one host that’s checked in under this setting. It’s not 100% accurate but should give a fairly good idea.
This should address all of the issues you reported.
-
I have tried to use the code from github and found here a small issue in boths files from bin folder. Looks like that there was an merge conflict and it wasn’t corrected fully.
Example:
[url]https://github.com/mastacontrola/fogproject/blob/dev-branch/bin/.install.sh#L1[/url]Please fix and ty,
Albatros -
Tom,
Bugs Found SVN 2498
- When multicast timeout expires, imaging doesn’t start. In GUI it says task is in progress.
- Date and Time is off in the task manager view. Says image started at 1:00PM . However its 9:19AM here EST. Is there a setting im missing in general settings ?
-
[quote=“Ray Zuchowski, post: 38370, member: 24449”]Tom,
Bugs Found SVN 2498
-
When multicast timeout expires, imaging doesn’t start. In GUI it says task is in progress.
-
Date and Time is off in the task manager view. Says image started at 1:00PM . However its 9:19AM here EST. Is there a setting im missing in general settings ?[/quote]
-
I don’t know what to say about this. Isn’t that kind of expected it it times out before the host can attach?
-
check your php.ini settings. one for /etc/php5/apache/php.ini and one for /etc/php5/cli/php.ini
Edit the date.timezone setting. It should read:[code]date.timezone = America/New_York[/code]
It should NOT read[code];date.timezone = America/New_York[/code] -
-
Tom,
I thought if the session timeout expires the session is suppose to start regardless of how many clients? I had a session for 2 clients and I didn’t join the other pc because I wanted to see if the session would start if other pc didn’t join after the timeout I had specified which was 2 mins.
-
So one is in the system?
I’ve tested this multiple times without issue, so I’m sorry if I’m a bit lost.
-
Lol its fine.
I made a session for 2 clients with a timeout of 2 mins.
I joined 1 pc and waited to see if the session would start after 2 mins. I waited 5 mins and tried to join the other PC and it says no session with that name exists which is good, however the other PC that joined the session stated it was in session on the GUI but it just sits at the PartClone screen doing nothing.
-
SVN 2499 released. With this release, comes a fix for PrinterManager. I’m sorry I’m a freakin idiot sometimes.
-
SVN 2500 released. Hopefully just fixes non-group assigned old images from reporting errors when trying to download files.
-
Keep up to the good wok Tom. I hope you are getting paid for all your time somehow.
-
Tom,
Under the IPXE boot menu when you select quick image. If a host was registered prior with quick host reg and you go to run quick image it will kick back to the menu, due to the fact no image is assigned to that pc. Instead of it kicking back to a menu it should state that this host doesn’t have an image assigned to it and bring up the list of images and be able to assign that image .
Ray Z
-
Rather than assigning image from iPXE Menu would be better to just allow “quick image” to choose the image. So Quick image, if the host is registered, will allow the registered host to use any image you’ve selected?
I only say this because it should be up to the administrator to assign the image, and what better way to assign than at full reg, quick reg with auto pop on, or with the GUI? I mean, we’ve already got 3 means to assign an image.
My thought’s on allowing quick image to select which image would also allow the user to test images they’ve created without necessarily having to reassign the host.
-
I’ve added a checker to let you know if the host does not have an image set. Right now it just tells you to add one from the GUI.
-
yeah I agree that’s a better idea on quick image. I like the idea of testing. Good call. Let me know when you add that.
-
Tom,
Bugs Found in 2508
-
I setup a multicast for 3 clients with a 4 min timeout. First 2 clients joined without an issue . I went to go join the 3rd client and it said no session exists. In the Gui it say the multicast is in progress. Something is wrong with the timeout because there was no way I went over 4 min. Also the two clients that did join the session are just sitting at the part clone screen. No imaging started.
-
Killing a task doesn’t stop imaging now from the gui. Tried stopping a unicast from the gui and its still imaging the client.
-
-
For number 2:
Partclone is a fickle little thing. Once the init is started, it knows nothing about what you do on the client. Where you will notice a problem is after the image “completes” it won’t reboot the system because the tasking no longer exists.
In the GUI, the mutlicast is inprogress the moment one (or more) systems check in. I don’t have a sweet means to know when all the clients have connected, or if the timeout has already passed.
I will test the issue you’re referring about. It sounds like the mutlicast session tha twas created had the name field removed. Maybe you cancelled the tasking (or cancelled the task of another host?)
