Posts made by Tom Elliott

r1109 released. Should add progress information for surfacetest as well as perform checkin on the task. I’ll work on implementing more checkins. The one I can’t is the memtest task as it never loads anything where you have a console.

During testing, it seems like badblocks is being checked. I performed the same tasks that are performed on the system during this particular task and killed the task just to see if I’d get any info.
Don’t forget, this surface test performs the surface test from each block on the system, so I expect that it would take it a while to perform. I didn’t write the program, but it looks like there is a progress indicator. I’ll add that to the fog.surfacetest script. and post in a moment.

Hopefully this two items (from a tasking standpoint) will work for you now.

I’m not seeing an issue with Snapins. What revision are you on? What steps can I do to get the same results?

Fixed the memtest issue. It’s due to the fact the ramdisk option is being set. Remember, none of the task associations were setup so something where missed. I just corrected the memdisk issue by, basically, keeping the append options off. I’ll post the revision shortly.

I imagine this same issue is what we’re seeing on surface checks, and possibly, other task types as well. I’ll have to dedicate time to each one to get each one working properly.

Multicast Tasks, Works. Seemingly it works properly now. Will try to add element to kill/recreate task if another host with the same image tries to startup. However I haven’t a clear plan on how to implement that, so may have to wait for a little.

Services (FOG Settings) settings are now called by class based methods over the old MySQL style requests. It’s still sql based, but uses the classes as I imagine is supposed to be the intent.

ClientServiceManager uses more classed based methods.

Snapin Deploy works, only from host/group deploy for now. Will work on Task Host/Group deploy elements, may just remove the snapin parts from them entirely. They work, but either one or the other will always deploy all snapins associated with the particular host.

WakeOnLan works.

Host Performs much of the image/task needs now. I think this is appropriate as it’s ultimately the hosts doing the tasks anyway.

Service scripts (fogwebdir/service) now falls more in line with class based elements as well. Less need to call database. Not all scripts are done yet, but still working as I can. blame.php, man.hostexists.php, auto.register.php, oslisting.php, imagelisting.php, Post_Wipe.php, usercleanup-users.php, updates.php, inventory.php, auto.delete.php, PrinterManager.php, snapins.file.php, dircleanup-dirs.php, displaymanager.php, hostname.php, hostlookupbymac.php, av.php, debug.php, alo-bg.php, Post_Stage2.php, progress.php, Pre_Stage1.php, mc_checkin.php, Post_Stage3.php, and capone.php that I can find.

Groups have ability to add hosts, Hosts can join to groups.

Configuration Save (export/import) features. This basically just saves the fog database, as I don’t imagine much else needs to be stored. That’s not to day I shouldn’t, at the least, work on getting the fogwebdir/commons/config.php .fogsettings and /opt/fog/service/etc/config.php, but I don’t know the best route for that yet. SORRY!

Capone now uses more refined methods. Basically the same as the old, but uses classes where possible.

That’s all I can think of for now. What else is needed?

That doesn’t make sense to me. I haven’t had any issues running memtest on my systems. I use it to quickly restart my VM’s as they’re running from virtualbox. it’s quicker to (from the menu) choose memtest then right when it starts, press escape to restart for. I’ve never seen that error. That said, it makes me wonder how old your memtest kernel is as it shouldn’t be creating a ramdisk anyway, that I’m aware of. memtest is it’s own utility to my understanding.

You say you got hostname changer to work, was there any steps for this or did it just start working?

I’ve tested, slightly, with testdisk surface test, but not much. It appeared to work fine to me, so I just let be. I’ll do more testing.

I think its about time to do another write up of the things I’ve fixed/added/modified so we have a working inventory of what’s been performed. It will take a little while as I don’t remember everything that I’ve done since the beginning. I’ll be working off of a sort of TODO list and if there’s anything I’ve missed so far, please let me know.

Thank you,

Denis and all,

You’re very welcome. Just test and let me know of any issues you run into, I’ll try to fix them when I can.

As a side note, I think all should be aware of, besides the whole port randomization thing all of the multicast jobs, and as I find them, other imaging/non-imaging tasks (wake on lan, snapin deployment, etc…) will be performed by the Host.class.php file. I am using this as it’s already designed to handle the deployment of tasks, why not use it to create my tasks as I imagine they were intended.

As I delved into these pretty head strong on the idea, I also am starting to wonder if the reason 0.32 had issues isn’t similar to the cause of the issues I was running into, but able to fix.

All perfectly understandable. I don’t expect you to go to work on a saturday, but if you work at home on your own systems, you might come up with a workable procedure for yourself when you finally do get back to work.

I have a motorola Surfboard Modem on my network and have yet to have any issues pxe booting. It listens for tftp yes, but only from the isp, not my network as the specifics it’s looking for is unavailable on my network.

All,

Just a heads up on the UDP Port created. I’ve changed it to get the setting from the web GUI, You can set it, but I’ve added another feature to the class files that randomly generates a new port number (even) between 2 and 65534 (port 0 is invalid, port 65535 is invalid) so, while you can manually specify a port number, it also automatically/randomly sets a new port number after a multicast task is created. This way you can create multiple multicast jobs without worry if the port is already in use. That’s not to say it couldn’t recreate the same port, but it’s a fairly wide range so it’s unlikely to create a port that already exists.

@Denis,

The latest fog should have Multicast Tasks working appropriately now. r1106 should allow all of this to work, create, start, cleanup, and what not.

r1106 released. Fixes an issue where an individual host multicast task creates two jobs.

r1105 released. Doesn’t fix the pid issue yet, but has capone using class based methods. @jbscim, I kept osID field in capone, but it doesn’t reference off of hostOS, it references off of images.osID. All other changes (-i removed from fog.capone) updated init.gz and buildroot script, have been implemented.

It’s possible, I’m assuming your home server you’re using Debian 7 as well?

Found an issue in the MulticastTask in that it never stores or gets the PID of the process being created. Maybe somebody can help?

I can probably make that all happen for you.

The only issue I forsee with it is the deleting of the fog database (if you’re doing a full install of course)

I’ve tried a few more things. Have the current kernel in the same location. Yes it’s smaller, but it’s based on KS rather than Core, which I think was causing your issues. Hopefully this time it’ll work. All I can do is keep trying until we figure out the root of the issue.

Awesome then. I’m sorry about all the hassle.

r1103 released.

Fixed the links in the TaskManagementPage so they, seemingly, work properly now.

Multicast now works, as far as I can tell, properly. Groups, Host, and from the Task page.

Will work on updating Capone to use the classes I’ve created.

Hmmmrph,

Going to look up specs to see what I need to add.