This is probably still a problem. I think it’s because on upload it’s actually trying to get all the relevant data. I haven’t tested much though so maybe it is working right now?

This problem is still present, but really only affects FOG setups who allow login across actual internet sources. Typically speaking this vulnerability really only affects malicious insiders trying to bring down an org, and won’t normally pose the problem.

With that said, I’ve been working towards using mysql prepared statements but this will take quite a bit of work as much of the system was coded with the old procedural style of mysql php functions in mind.

This is still a problem, though I haven’t had much time to look at C# or learn it rather. I will attempt over the next few months at my take of recoding/working the FOG Client Scripts.

This is old, but warrants and update I suppose.

It’s been fixed for quite some time though.

[quote=“Dave_A, post: 30281, member: 24638”]Wouldn’t it be possible to add a step to the image-collection process, that grabs the partition map of the source via Linux fdisk or parted, and pushes it up as a text file with sys & rec images - then pull down and parse that file in the restore part of the script, to recreate the original map??[/quote]

Yes, that’s very possible. The problem is, the mbr is what determines the size of the disk, so after “re-mapping” the drive with the MBR data, it would be limited to the size of the original disk, which leads to the same thing you have with multi-part images.

Further, I also found most Javascript stuff broken until I cleared the cache - going through host details (ie Snapins, Hardware) didn’t work amongst other things.

Just tested tftp client frm Windows 7 in one of these HP dc7900p computers, and it worked.
After testing all this, it’s working.
Don’t ask me why or how… but it started working.
Thank you all for your support.

the latest beyond 1.0.1 may be unstable.

use 1.0.1 for production environments.

r1531 released to fix the typo, thanks for reporting.

I follow. So you would either have to do some odd multiple boot/reboot thing to set a task from the host or set tasks from the server which could then do its musical kernel dance. That’s a bit more than I have the time or knowledge for right now, but its good to know the support is out there.

I’ve followed your instructions ritchy_purple however I found that this broke group scheduled tasks. Single host scheduled tasks still ran but group ones would not as the script no longer returns a list of hosts that are members of the group.

I’ve written some more in-depth instructions and a solution (based on this thread) that gets both the Web GUI and group scheduled tasks working

[url]http://fogproject.org/forum/threads/scheduled-tasks-and-fog-0-32.10345/[/url]

Neil

ok it appears that i actually did set up an password for my SQL. I edited the config file and everything is now working as far as login

Or just tell the variable to check that it as an array, no matter what!

Yes a change of the Credentials in the Storage node fixed the issue.

Cool. FOG_LEGACY_FLAG_IN_GUI worked very nicely. It’s a good option to have. Thanks Tom.

Not sure if you’re already aware, but I’ve changed the way this get’s displayed when you “deploy” a task. It takes the task type and displays “<TASKTYPENAME> task created for [U]<HOSTNAME>[/U] with image [U]<IMAGENAME>[/U]”. Hopefully this is more descriptive as it tells you exactly what task has been “Deployed”

ok, thanks.