Latest FOG 0.33b
-
Please see attached for 2 files which resolve ( I hope ), the problems with capone.
they are
/fog/management/plugins/run.php
and
/fog/service/capone.php[url=“/_imported_xf_attachments/0/517_run.zip?:”]run.zip[/url]
-
tom,
is there a problem with how long the pc name can be?
-
Can be 15 characters long. It auto truncates to 15. It also checks that the hostname doesn’t already exist why?
-
because I have a computer named scanningstation and when I do that and submit a task it messes up the database I had to restore maybe three times now because of it I am trying to figure out what actually triggers it. I am not sure if it is because I am trying to enter the pc manually or if its something else.
-
jbsclm,
It appears that the FOG_NFS_DATADIR is removed from the database in this current version. My guess is it’s expected to get the information of this from the storage node class file. More dynamic I suppose but easy to miss. I’m sorry I missed it while coding, I didn’t know it wasn’t in the database anymore.
I’ve just modified the capone.php service file to use the Capone class and obtain the information relevant to how this worked.
-
r1140 released.
Should fix run.php and capone.php only in the proper order now.
Hopefully this helps you out jbsclm. Please test it, there’s a lot of differences.
-
Finally got around to installing 0.33b in a Ubuntu 13.10 VM and found a small quirk to the install script. When you get to the point where it prompts the user to create a mysql root password, the script tells the user that setting the password isn’t mandatory, but if you leave it blank, it goes forward a step, and keeps coming back to the password prompt step. Obviously it’s not advisable to not use a password, but you may want to update the script text stating it’s mandatory, or allow a blank password
-
That’s the mysql installation, not FOG. It asks three times.
-
it does warn that if you set a password… you need to set it in one of the config files so fog will actually work… it is the users choice to have a password or not.
-
I’m currently rewriting the fog script. I’ve broken it into three smaller, and I think, more manageable scripts.
fog.checkin (performs the checkin and variable assignments.
fog.download (performs the download tasks)
fog.upload (performs the upload tasks)
fog (just deals with passing the tasking. appropriately.)I’m still testing but things seem to be a little bit better from my perspective. Still have to test dd, mpa, mps upload and all downloads, but just giving a heads up as to what I’m doing lately.
-
[quote=“VincentJ, post: 21914, member: 8935”]it does warn that if you set a password… you need to set it in one of the config files so fog will actually work… it is the users choice to have a password or not.[/quote]
I had seen that part, I had just never done a mysql install before so I wasn’t aware that that part of the mysql install routine was to ask 3 times to set a root password. I assumed it was a small error in the script :oops: . No big deal - lesson learned. I have the VM up and running, all is well. Looking forward to seeing what else is to come in the future of FOG
-
My latest test with 0.33b r1140
After entering a host and selecting a Hardware Inventory, the inventory seems to get right upto the end and then after it starts trying to update the host database it gets ‘Invalid MAC Address’. The MAC is correct.
I was unable to kill the task to do another because the inventory didnt complete and when i try to enter the tasks page i get the following error displayed twice.
FOG DEBUG: Host Database Load Failed: ID 0, Error: Row not found
The List All Hosts page seems to have lost the hostname of the PC I inventoried, and only displays the MAC address. Can’t edit or destroy the host either.
PC rename is working during imaging in Windows 7 Enterprise 64 bit.
Host registration via the boot menu works.Getting much closer to a production deployable system.
-
Hi Tom.
Running new install of r1141 on Ubuntu LTS 12.04 to test capone, but image upload seems to be doing a raw upload rather that an ntfs one.
Attached are pxelinux.cfg files and screenshots from r1126 and r1141 clients
r1126 works OK, r1141 uploads as raw.John
[url=“/_imported_xf_attachments/0/520_boottest_r1141.zip?:”]boottest_r1141.zip[/url]
-
I’m working on a fix for this issue as I’m well aware of it already. My fix is basically rewritting the fog scripts and adding an upload and download script, to separate the code base slightly for easier management. I’m still testing it.
In the mean-time, Find the lines that deal with setting the fstype variable in the FOG Scripts, and make sure they’re using double quotes rather than single quotes, I don’t think Shell scripts like single quotes to identify strings the same way php does, which may be what’s causing the issue.
Does your system have multiple MAC’s? You can check what’s being sent to the inventory.php service file from your access log file. Chances are, I’m only guessing, is it’s sending the data as something like:
inventory.php?mac=00:01:ab:2c:3f:1b%7C00:01:ab:ac:af:ff which would explain why it’s not liking the MAC Format. -
It’s VMs with one NIC, will check tomorrow
-
r1143 released.
With it comes a notice:
[B]FOG SCRIPTS ARE IN ALPHA/BETA TESTING ONCE AGAIN.[/B]init.gz is perfectly fine by itself but I’ve rewritten the main fog script. Three new files (besides fog.bkup2 which is the original fog script) are included to help me with managing what goes wrong where.
fog.checkin performs checkin tasks for download, upload, and multicast. I Have test this and it works for download/upload, haven’t yet tested with multicast checkin, though it should work as it’s a part of the download checkin anyway.
fog.upload, I’ve tested single disk resize and single disk multi-part functions. It should work as well. I’ve also dabbled, a little bit, with the raw upload at it too seems to work fine.
fog.download, I’ve tested single disk resize download and a minor single disk multi-part test. Don’t know if mps (single disk multi-part) is working properly though I haven’t seen any major issues thus far. I’ve not tested anything dealing with multicast yet.
As a side note, it appears the fstype is working as expected now, though I haven’t had a proper chance to verify this is the case.
As I test various things and notice issues, as always, I’ll update and figure out a fix. If you haven’t noticed by now, I’m working in a progressive aggressive pattern now. I find an element that is “broken/borked” and work it out until I have a fix in place.
-
Hey Tom,
I am having the same issue a VincentJ the machine only has one nic and it only happens when I send the command to to do a hardware inventory from the fog advance snapin module. If I do a full inventory from the machine it self everything works fine the machine also only has one nic installed and its a physical machine not vm.
-
fog.download found an issue with multicast. I stored the command in a variable and needed to eval it first.
r1144 released as a fix for multicast download. MPS is working now. Haven’t fully tested SDR. MPA isn’t tested either as it’s usually taken care of and only has one extra step but is basically the same as MPS.
-
r1145 released.
Fixes an issue where if the state of the multicast task is in-progress, it will kill the task, but not remove it. We don’t want that, so this has been corrected. If it’s complete, or canceled, the task gets killed properly.
-
I’m guessing this mac thing is to be expected. The inventory.php file uses the base64_decode for the MAC Address. It appears the bas64 command being sent for one of these jobs is not working properly. I don’t know why yet though. Maybe because it’s expecting something else for the mac address?
