Bugs in FOG 0.33

[Olaf]

[quote=“Fernando Gietz, post: 3391, member: 13”]I’ve problems under Centos and the FOg daemons: FOGReplicator,FOGScheduler and FOGMulticastManager.

But FOGShceduler daemon:

[CODE]
[root@r800145 administrador]# /etc/init.d/FOGScheduler start
Iniciando FOGTaskScheduler: [ OK ]
[root@r800145 administrador]# PHP Warning: require_once(/var/www/html/fog/management/lib/Imageable.interface.php): failed to open stream: No such file or directory in /opt/fog/service/FOGTaskScheduler/FOGTaskScheduler on line 58
PHP Fatal error: require_once(): Failed opening required ‘/var/www/html/fog/management/lib/Imageable.interface.php’ (include_path=‘.:/usr/share/pear:/usr/share/php’) in /opt/fog/service/FOGTaskScheduler/FOGTaskScheduler on line 58
[/CODE]

The file [B]/var/www/html/fog/management/lib/Imageable.interface.php [/B]don’t exists[B].[/B]

[CODE][root@r800145 lib]# pwd
/var/www/html/fog/management/lib
[root@r800145 lib]# ls -la
total 20
drwxr-xr-x 5 apache apache 4096 may 4 21:47 .
drwxr-xr-x 15 apache apache 4096 may 4 21:47 …
drwxr-xr-x 5 apache apache 4096 may 4 21:47 jpgraph
drwxr-xr-x 3 apache apache 4096 may 4 21:47 ssh
drwxr-xr-x 6 apache apache 4096 may 4 21:47 .svn
[/CODE][/quote]

I can confirm this. These (mainly) class files are there when you upgrade from 0.32 to 0.33B but [B]are not there[/B] with a fresh installation. No wonder if you look at: [url]https://freeghost.svn.sourceforge.net/svnroot/freeghost/trunk/packages/web/management/lib/[/url]
[U][I][B]If it is not there to checkout, there is noting to install so it will not get installed.[/B][/I][/U]
When it is not installed there will be no runnable TaskScheduler. And without that FOG is useless.
The need for these missing files is advertised here: [url]https://freeghost.svn.sourceforge.net/svnroot/freeghost/trunk/packages/service/FOGTaskScheduler/FOGTaskScheduler[/url]
So testing 0.33 from a 0.32 upgrade might work but a fresh SVN checkout will never result in operational code!

I installed this on Debian Wheezy today (April 12th 2013).
All issues with the installer are also still there: it forces installation of Debian packages even if alternatives are available (like MariaDB instead of MySQL) and overwrites configuration files without warning.
Another issue popped up too: ftp password/fog user was not resettable. (I changed the password of the system user “fog” and also the pwd in the congig.php file for the FTPserver). It kept trying the old password. The old password was still there from the 0.32 installation but was no longer valid for some reason. So no smooth migration there. I must admit though that this is a complex kerberos/pam integrated system.

[Budgester]

So poking round the codebase for .33 from SVN.

Snapins are borked, whenever I try and add a new one I get a blank page, checking the apache logs shows…

[Thu Apr 18 18:10:19 2013] [error] [client ::1] PHP Fatal error: Call to undefined method SnapinManager::isPasswordValid() in /var/www/fog/lib/pages/SnapinManagementPage.class.php on line 230, referer: [url]http://localhost/fog/management/index.php?node=snapin&sub=add[/url]
[Thu Apr 18 18:19:31 2013] [error] [client ::1] PHP Fatal error: Call to undefined method SnapinManager::isPasswordValid() in /var/www/fog/lib/pages/SnapinManagementPage.class.php on line 230, referer: [url]http://localhost/fog/management/index.php?node=snapin&sub=add[/url]
[Thu Apr 18 18:21:51 2013] [error] [client ::1] PHP Fatal error: Call to undefined method SnapinManager::isPasswordValid() in /var/www/fog/lib/pages/SnapinManagementPage.class.php on line 230, referer: [url]http://localhost/fog/management/index.php?node=snapin&sub=add[/url]
[Thu Apr 18 18:32:49 2013] [error] [client ::1] PHP Fatal error: Call to undefined method SnapinManager::isPasswordValid() in /var/www/fog/lib/pages/SnapinManagementPage.class.php on line 230, referer: [url]http://localhost/fog/management/index.php?node=snapin&sub=add[/url]

[Budgester]

I’m also assuming the re-write includes clearing cruft from the install, to that effect I can find no reason to keep the following directories and files.

/fog/public
/fog/public/randomimage.php
/fog/public/imagepool

There is no explanation or use for these as far as I can tell and they don’t seem to be referenced from anywhere else in fog.

[Adrian Zaugg]

Please update the init scripts for dependency based booting on Debian. See [url]http://fogproject.org/forum/threads/0-32-installation-script-messes-on-debian.4084/[/url]

This haven’t been done in revision 899 yet.

Thank you.

[Tom Elliott]

Found out a few things.

The init.gz fog.man.reg script for full host registration is broken. (EDIT: Not broken just not appropriate as OSID is now based on Image rather than per system.)

This is because, your mysql database for fog removes the table from hosts hostOS. This itself isn’t a huge deal as I think your method of assigning the OSID to the image file rather than each system is more appropriate. But your scripts need to be adjusted to make this modification. fog.man.reg doesn’t need to get the host osid and should be removed. I’ve updated the file and will post it as soon as I can.

Also, under this same issue, the /var/www/html/fog/service/auto.register.php file needs to stop trying to put in the hostOS field as it will fail due to the table not existing in the first place. Removing all references for osid realosid and hostOS seems to have corrected this issue, I will post this file as well when i have more time. I’ve modified them to help out in my little way. I’ve also modified the /var/www/html/fog/management/reports/Inventory.php file to work more appropriately as well so it pulls it imageOSID rather than trying to pull information from a non-existent table which will cause failure.

I hope I’m not stepping on anyone’s shoes here and have helped out in my little way.

Also, if anyone’s interested, I’ve created my own init.gz and bzImage to work off of the most current kernels (3.10.5). The init.gz file has bash included with it as well.

EDIT:

Got the files and they are now attached.

auto.register.php should be a simple placement into {fogwebdir}/service/ , and I’m sure you could leave the original fog.man.reg file in place with osid inputs because the auto.register.php ultimately is in charge of writing the data to the database.

For nice housekeeping, the fog.man.txt just needs to be renamed (as the forums won’t allow an upload of a file ending in extension .reg) and chmod’ed as necessary within the init.gz /bin directory.

Hopefully this helps. Thank you,

[url=“/_imported_xf_attachments/0/359_auto.register.php?:”]auto.register.php[/url][url=“/_imported_xf_attachments/0/360_fog.man.txt?:”]fog.man.txt[/url]

[Tom Elliott]

Another minor issue that I’ve so far noticed is:

Reports, all of the pages will not work and it appears it’s because it has to communicate with the database. This communication is lost because the mysql_query statements within this pages look to be sending to a variable $conn that doesn’t exist for those pages. Also, as it needs to communicate with the database, the base configuration files are not existing either. My best suggestion would be to make a configuration file that stores the references needed within a file called something like base.inc.php that includes the base required files of commons/init.php commons/init.database.php. For the $conn variable, suggest an include statement of the base.inc.php so that the $conn system can be accessed even though it’s not directly defined in the file. So, basically, all main files should have an include BASEPATH . ‘commons/base.inc.php’; statement in them. This would also work for all other file that request this same information.

Found out that Pending MACs.php file the reference to class HostManager works if called like this:

$hostMan = new HostManager(); Rather than
$hostMan = $FOGCore->getClass(‘HostManager’);

Fixed and working on my side.

My base.inc.php file is:

<?php
/* This file just stores the heading information for including *

• In the FOG System. This should minimize code lines. *

•                                                         */      
  

if (!defined(‘BASEBATH’))
require_once(‘system.php’);
require_once(BASEPATH . ‘/commons/config.php’);
require_once(BASEPATH . ‘/commons/init.php’);
require_once(BASEPATH . ‘/commons/init.database.php’);
$conn = @mysql_connect( DATABASE_HOST, DATABASE_USERNAME, DATABASE_PASSWORD);
?>

and is located in commons.

Then added the line to the files needed. Though I guess in the management/index.php all you should need is the reference :

include ‘…/commons/base.inc.php’;
In the reports *.php files.
include BASEPATH . ‘/commons/base.inc.php’;

[Tom Elliott]

Fixed / found issue on management/reports/Pending MACS.php. The reference of

$hostMan = $FOGCore->getClass(‘HostManager’);

Doesn’t do anything as the class in reference is technically non existent. To fix this and get report is to change that line to:

$hostMan = new HostManager();

This seems to allow it to work Properly.

EDIT:

now we can go, more or less, back to the reference sample originally intended with a minor change.

Change the line:

$hostMan = $FOGCore->getClass(‘HostManager’);

To:

$hostMan = $this->FOGCore->getClass(‘HostManager’);

[Tom Elliott]

[quote=“Tom Elliott, post: 14110, member: 7271”]Another minor issue that I’ve so far noticed is:

Reports, all of the pages will not work and it appears it’s because it has to communicate with the database. This communication is lost because the mysql_query statements within this pages look to be sending to a variable $conn that doesn’t exist for those pages. Also, as it needs to communicate with the database, the base configuration files are not existing either. My best suggestion would be to make a configuration file that stores the references needed within a file called something like base.inc.php that includes the base required files of commons/init.php commons/init.database.php. For the $conn variable, suggest an include statement of the base.inc.php so that the $conn system can be accessed even though it’s not directly defined in the file. So, basically, all main files should have an include BASEPATH . ‘commons/base.inc.php’; statement in them. This would also work for all other file that request this same information.

Found out that Pending MACs.php file the reference to class HostManager works if called like this:

$hostMan = new HostManager(); Rather than
$hostMan = $FOGCore->getClass(‘HostManager’);

Fixed and working on my side.

My base.inc.php file is:

<?php
/* This file just stores the heading information for including *

• In the FOG System. This should minimize code lines. *
• */
  if (!defined(‘BASEBATH’))
  require_once(‘system.php’);
  require_once(BASEPATH . ‘/commons/config.php’);
  require_once(BASEPATH . ‘/commons/init.php’);
  require_once(BASEPATH . ‘/commons/init.database.php’);
  $conn = @mysql_connect( DATABASE_HOST, DATABASE_USERNAME, DATABASE_PASSWORD);
  ?>

and is located in commons.

Then added the line to the files needed. Though I guess in the management/index.php all you should need is the reference :

In the reports *.php files.
include BASEPATH . ‘/commons/base.inc.php’;[/quote]

I was/am able to remove the need of the $conn variable declaration in base.inc.php and reference the global variable for database connections within the reports directory as:
$this->conn

So a simple sed script is really useful to fix this. Also with this, the $hostMan function in Pending MACS.php can now be referenced as: $this->FOGCore->getClass(‘HostManager’);

In the {fogwebdir}/management/*.php files, place near the top:

include ‘…/commons/base.inc.php’;

In the {fogwebdir}/commons/base.inc.php file just have:

base.inc.php
<?php
/* This file just stores the heading information for including *

• In the FOG System. This should minimize code lines. *

•                                                         */      
  

if (!defined(‘BASEBATH’))
require_once(‘system.php’);
require_once(BASEPATH . ‘/commons/config.php’);
require_once(BASEPATH . ‘/commons/init.php’);
require_once(BASEPATH . ‘/commons/init.database.php’);
?>

Hopefully somebody see’s this all.

Thanks,

[Tom Elliott]

Found an issue with the Disk Usage Graph on the main page of the web interface. What happens is when the used space is equal to the total available space, the graph only show’s 50% usage.

This is due to the way, that I can tell, the jquery.flot.pie.js script interprets the information in the calcTotal and combined functions.

Attached is the modified file that seems to work appropriately. This file goes in {fogwebdir}/managment/js/

I’ve also made a few changes to {fogwebdir}/management/js/fog.dashboard.js and {fogwebdir}/status/freespace.php so that it interprets the information accurately from Available and Used space and displays in EiB thru KiB. The method it uses currently obtains the appropriate Available space, but misinterprets the Used spaced. What I mean by this is when a file system is created there is always a portion that is unavailable space. The math takes the total size of the drive and subtracts the actual free space which is not necessarily an accurate representation of what the file system actually has.

So for inventory the files I’ve changed/added for the Dashboard area are:
{fogwebdir}/management/js/fog.dashboard.js (named as fog.dashboard.txt for upload)
{fogwebdir}/management/js/jquery.flot.pie.js (named as jquery.flot.pie.txt for upload)
{fogwebdir}/status/freespace.php

[url=“/_imported_xf_attachments/0/362_fog.dashboard.txt?:”]fog.dashboard.txt[/url][url=“/_imported_xf_attachments/0/363_jquery.flot.pie.txt?:”]jquery.flot.pie.txt[/url][url=“/_imported_xf_attachments/0/364_freespace.php?:”]freespace.php[/url]

[Tom Elliott]

From the dashboard, when you click on the Disk Usage Graph, it used to give you hardware information and gives a debug message saying to use the old include style information. When you click on the old include style it requests that you login. You type your information and it just requests you to login again. However, I’ve fixed the link to actually give us a class that would be referenced.

I made adjustments (again just for the pretty factor of calculation of disk space) and created a new file.

Inventory of files changed/added are:

{fogwebdir}/lib/pages/hwinfo.class.php (created the class file)
{fogwebdir}/status/hw.php (adjusted to obtain information and calculate sizes more human readable.)

[url=“/_imported_xf_attachments/0/365_hwinfo.class.php?:”]hwinfo.class.php[/url][url=“/_imported_xf_attachments/0/366_hw.php?:”]hw.php[/url]

[Tom Elliott]

This is a bug that I can’t give any fix for. I think it’s something all systems would have an issue with.

I have a windows system with a Hybrid SSD Drive. It will attempt to upload the image, but it keeps on hanging and eventually says something to the effect of pigz not responding last 120 seconds. The system that actually holds the images dies due to a kernel panic. I think this is specific to the Hybrid Drive, but I don’t have an alternate HDD to test with, unless I build a VM, which I will do eventually. Maybe this can be a warning rather than a bug, but I don’t know where else to place this.

The reason I believe it’s due to the HDD and not an issue with the actual imaging system is because looking up similar issues for this somebody recommended doing a chkdsk on the system. I just did the 3 phase chkdsk and it would hang throughout that as well. From my experience, usually 3 phase chkdsk is generally quite fast. It appeared that the Hybrid part (the ssd if you will) makes for a relatively large buffer, but the buffer can only hold so much data on the read state. Then it pauses, pushes the data where it needs to, then starts the cycle over again. Hence the pausing. I don’t know what this would look like on the write state as I haven’t been able to create an image for my Windows system.

[Tom Elliott]

Alright,

Update to my last post.

I created a Windows 7 VM and just installed the base. I haven’t activated or anything else, just installed and uploaded image.

The issue from above seems to be fine, except I keep getting hangs off and on. That could be a problem with my network as I have many different IP’s. I live on a 10/8 rather than a XXX/24 subnet. That aside, I was able to fully upload the image file.

The problem I came across, though, is that Single Disk, Resizeable seems broken to me. It uploaded the image, but only the mbr part of the image and broke the Windows 7 system where it needs to run a chkdsk. That aside it didn’t hurt the system, just a nuisance. In either case, it didn’t download any of the other partition(s) which seems to me it should and has in the past. I’m going to compare the init.gz fog script to the one from 0.32 as that one seemed to work flawlessly. I also wan’t to fix the size information when uploading as it’s displaying 1.47 GiB available space when the image size is 7.4 GiB. It doesn’t hurt my system any as I have 4 terabytes, but could pose an issue if someone doesn’t know and pulls the plug on an image they were overwriting.

I put the image in Multiple Partition Single Disk not resizable and it seems to have uploaded just fine. Maybe I can get some help on where to look for these issues?

Thank you,

[Tom Elliott]

Under the Fog Configuration page (the ? circle icon) the Mac-List page did not operate. Even with adjusting the $FOGCore values to $this->FOGCore as needed, the page displayed, but the Delete and Update did not work. I corrected this and will attach the files.

With this, though it’s not pretty, under the Host page, I’ve added the ability to add additional macs and, with the database loaded with the mac address vendor’s, it now displays the vendor for the macs. If it can’t find the mac listed, it will give the link for the lookup vendor, though I haven’t seen how to get this working … yet.

Inventory of the files are:

{fogwebdir}/lib/pages/FOGConfigurationPage.class.php
{fogwebdir}/lib/pages/HostManagementPage.class.php

[url=“/_imported_xf_attachments/0/367_FOGConfigurationPage.class.php?:”]FOGConfigurationPage.class.php[/url][url=“/_imported_xf_attachments/0/368_HostManagementPage.class.php?:”]HostManagementPage.class.php[/url]

[Tom Elliott]

[quote=“Tom Elliott, post: 14166, member: 7271”]Under the Fog Configuration page (the ? circle icon) the Mac-List page did not operate. Even with adjusting the $FOGCore values to $this->FOGCore as needed, the page displayed, but the Delete and Update did not work. I corrected this and will attach the files.

With this, though it’s not pretty, under the Host page, I’ve added the ability to add additional macs and, with the database loaded with the mac address vendor’s, it now displays the vendor for the macs. If it can’t find the mac listed, it will give the link for the lookup vendor, though I haven’t seen how to get this working … yet.

Inventory of the files are:

{fogwebdir}/lib/pages/FOGConfigurationPage.class.php
{fogwebdir}/lib/pages/HostManagementPage.class.php[/quote]

I forgot to mention, there were quite a few files that are referenced for the mac-list information. The original link lists it as mac-list, but all other needed files (the js, the ajax file, etc… reference the sub class as maclist) so Loading Vendors was giving issue as maclist didn’t exist and the delete/update buttons on the fog configuration page didn’t work because of the same reason. I’ll past the files that I changed to make it follow mac-list.

Inventory of the files are:
{fogwebdir}/management/js/fog.about.mac-list.js (Uploaded as txt file as js not allowed. Also, had to rename this file originally as the sub is mac-list, and this was called fog.about.maclist.js)
{fogwebdir}/management/ajax/mac-getman.php (Updated the sub reference)
{fogwebdir}/management/includes/submenu.include.php (The sub was here already, but just in case)
{fogwebdir}/management/includes/about.include.php (changed filename reference of maclist to mac-list)
{fogwebdir}/management/includes/about.mac-list.include.php (changed name of file and href information)
{fogwebdir}/management/indexold.php (Fixed this file so it actually logs you in now as well. Fixed the reference to sub)

[url=“/_imported_xf_attachments/0/369_fog.about.mac-list.txt?:”]fog.about.mac-list.txt[/url][url=“/_imported_xf_attachments/0/370_mac-getman.php?:”]mac-getman.php[/url][url=“/_imported_xf_attachments/0/371_submenu.include.php?:”]submenu.include.php[/url][url=“/_imported_xf_attachments/0/372_indexold.php?:”]indexold.php[/url][url=“/_imported_xf_attachments/0/373_about.include.php?:”]about.include.php[/url][url=“/_imported_xf_attachments/0/374_about.mac-list.include.php?:”]about.mac-list.include.php[/url]

[Tom Elliott]

I think I’ve found out the issue to the single disk, resizable not operating. I believe it’s due to the start of the 2nd partition being input improperly. It is set in the init.gz /bin/fog file as part2start=105906 but in actuality, the part2start could be found by the fdisk command, hence making it operable for, basically, an windows ntfs system. fdisk -lu will output the partitions in their sector start/end positions. This might help us out a little, maybe. I’ll do some more testing before posting results.

[Tom Elliott]

so no luck so far with Single Disk, Resizeable. It feels like it’s not making/rewriting after upload a copy of the mbr. For UEFI this shouldn’t be required, but that’s a different story. 105906 is the right start point for part 2. Remember I’m nobody so I was just testing different things. Maybe force the file to copy the mbr before resize, then resize image/upload, then resize back and write mbr back?

I know that’s a lot, but the script could do it all. I just don’t know where to begin.

Thanks,

[falko]

‘I’m nobody’ don’t say that, your contributing

[Tom Elliott]

I’ve got a busy week ahead of me at work, but I’ll try to look more into this this following weeked. I’ll add the components to my init.gz fog script to rewrite the mbr after the upload and after the reload of sys.img.000 and rec.img.000 and see if this works.

[Tom Elliott]

Fixed the kernel update system. Just needed a pointed function to do the update.

First things first. Make a copy of the fog.about.kernel.js file and save it as name fog.about.kernel-update.js in {fogwebdir}/management/js

Then copy the FOGConfigurationPage.class.php file to
{fogwebdir}/lib/pages

You should now be able to update your kernel using the FOG Web GUI.

[url=“/_imported_xf_attachments/0/377_FOGConfigurationPage.class.php?:”]FOGConfigurationPage.class.php[/url]

[falko]

I need to build a .33 VM and add in your edits