I haven’t tried the nucs yet with the svn trunk yet, but I did have an issue with them using 1.2.0. They were getting stuck at the ipxe initializing devices. It was having a problem configuring the realtek nic.

I was tried to boot legacy mode (since uefi did not work well with 1.2.0). If I remember correctly I had to update the bios to the latest version. Then on the NUCs I was using in the advanced bios setting there was a compatibility mode. On the one I was using there was linux, win7, win8. I had to set the bios to legacy boot, I think enable legacy roms, and select win7 mode. Save and exit the bios, then POWER IT OFF. If I did not power it off after making the changes it will continue to get stuck at the ipxe initializing devices. By accident I powered it off and then after that it started working. I should have another one in about 2 weeks where I can try them again to see if they are any better with the svn trunk version.

No promises, but I’m spinning up a centos 7 server right now for FOG. I’ve been meaning to do this anyway. My preferred server is Centos 6.7, because it just works well with FOG.

I’ll let you know how it goes.

@Wayne-Workman

Right now what the OP is saying is a bit conflicting in my mind. So we need to get to a known good place with the SVN trunk. I can say, absolutely that FOG SVN trunk works on Centos 6.7 with 0 alternations or messing around. Follow the documented install instructions (even on the svn trunk) and it will work, period. Understand that I’m not saying that Centos 7 (rhel7) is not a viable candidate. Personally I don’t have quite enough experience with Centos 7 to say absolutely there will be no issue. It appears that the OP is having issues that could or could not be related to the OS, or the way the FOG interacts with the OS. To go to a known good state I recommended Centos 6.7 on alternate hardware. If it works there and not on the main system then we can start to pick the OS apart. If FOG acts exactly the same between the production system and this test system on a known stable OS then we have more justification to point to something in the FOG SVN trunk is amiss.

Also for 6.7 its still a viable option since LTS ends in 2020 with full system updates ending in summer 2017 (it kind of parallels the question of Win7 vs Win10, what do you install today?). The answer will be different if you ask me the same question next July. FWIW: LTS for Centos 7 ends in 2024.

While this recommendation isn’t fog specific, I think I would take this approach.

You have 1.2.0 working right? If so leave that system in place for a short time. It is working and the school can deploy.

Take a new machine (desktop with a dual core and 4GB of ram). Install Centos 6.7 on that system. Its in the redhat family so you should not have much of a learning curve switching from fedora to centos. Do a minimal centos install. Just be aware that there is no gui with the minimal install so you will have to use putty and/or the console for configuration. Ensure you update the computer to the latest patches using yum. Then download and install the latest svn trunk directly onto the system. Do no upgrade from 1.2.0 go directly to the svn trunk. This will ensure there are no remaining older bits on the system. Then just follow the installation instructions for centos. Document your steps, step by step so you can create an installation manual and have a history of changes. Once you get this second “clean” system built are you are sure it is configured correctly, change the dhcp options to point to this new server. If something goes wrong with the new server then just change the dhcp setting back to the working 1.2.0 build.

Once you have the svn trunk version perfected then resetup the main server. I can tell you that installing fog on Centos works and works well. Centos isn’t leading edge like fedora, but for servers you want stability over a fancy gui or latest hardware support.

Again this is only my opinion and how I would approach the problem.

I found this bug report for 14.04 of ubuntu.

https://bugs.launchpad.net/ubuntu/+source/php-apcu/+bug/1422484

In a nutshell the fix seems to be:

sudo apt-get purge php5-apcu
sudo service apache2 restart

Not a FOG issue more about ubuntu.

@Wayne-Workman Sorry I thought that was a recent solution to add that link back in.

Thinking a bit more the 404 is page not found error (which lead me back to the files not being where expected).

The /var/log/httpd/error_log or /var/log/httpd/error.log should show the root issue either way like Tom suggested.

If I remember right on Ubuntu (sorry redhat person here), you needed to make a symbolic link between
/var/www/fog and /var/www/html/fog since the files are not where its expected.

The reason why I asked about he proxy server is I ran into the same problem, documented here: https://forums.fogproject.org/topic/6062/svn-5221-failing-to-install-on-fog-server-using-proxy-server

The line you added to wgetrc may or may not work [no_proxy=localhost,127.0.0.0/8,192.168.39.243]. I ended up exporting those statements in bashrc. It may not matter where the command is put.

This is what I put at the end of the bashrc file.
export http_proxy=http://192.168.1.110:3128
export https_proxy=http://192.168.1.110:3128
export ftp_proxy=http://192.168.1.110:3128
export no_proxy=“192.168.1.88”

The issue (not really a problem, just the way it works) is the install scripts uses wget to connect back to the IP address of the FOG server to dump the database data. wget gets a little confused and tries to contact the proxy server to contact the FOG server. At least in my environment this fails causing the backup to fail.

Lets get some basic info to start.

What is the server OS?

Does the server have direct internet access or is it behind a proxy server?

@Sebastian-Roth Sorry I assumed login == working kit.

I decided this AM to break down my POC setup and rebuild it. Yesterday I attempted to learn objected oriented php programming to add a function to FOG and promptly whacked my install. I’m in the process of rebuilding it with a consistent build across all nodes. It appears that Tom was able to fix the LDAP part. I will test that once I get the environment resetup. Thank you for your assistance.

Just for clarity: You’ve downloaded the trunk build either from git or subversion, right?

You have current release of fog 1.2.0 running without issue, correct?

You’ve run the bin/installfog.sh script and it completed without errors, correct?

If you have done all of that, but are getting an apache error in error.log (or error_log) you might want to post the exact error here.

The latest SVN loads ok and the management console opens without issue. Great job!!

I did notice an issue with the plugin, selecting create new access control menu item give me the access control search page instead of add new access control. No error is thrown in the apache error log.

The apache access_log shows this entry:

GET /fog/management/js/jquery.disableSelection.js?ver=31 HTTP/1.1" 304 - “http://10.12.1.88/fog/management/index.php?node=accesscontrol&sub=add”

After I upgraded to 5257 two plugins are now throwing errors when accessing the management console.

PHP Fatal error: Call to a member function isValid() on null in /var/www/html/fog/lib/plugins/accesscontrol/hooks/RemoveMenuItems.hook.php on line 14

PHP Fatal error: Call to undefined function AddLocationMenuItem() in /var/www/html/fog/lib/plugins/ldap/hooks/AddLDAPMenuItem.hook.php on line 24

@Sebastian-Roth I agree, it seems a bit confusing to have two different version numbers. Hopefully there is a way to resync the numbers.

On the fog console page there is a cloud, what are the numbers on the lower right?

The reason why I ask is that svn 4304 is somewhat old (in svn terms). I think the current SVN is in the 523x range. IF you are running 4304 there have been many great improvements since the svn you installed.

These following lines are probably what the @Developers need to look into.

PHP Warning:  array_merge(): Argument #1 is not an array in /var/www/html/fog/lib/pages/FOGConfigurationPage.class.php on line 633, referer: http://localhost/fog/management/index.php?node=about
PHP Warning:  preg_grep() expects parameter 2 to be array, null given in /var/www/html/fog/lib/pages/FOGConfigurationPage.class.php on line 635, referer: http://localhost/fog/management/index.php?node=about
PHP Warning:  fopen(ftp://...@10.101.1.250): failed to open stream: operation failed in /var/www/html/fog/status/logtoview.php on line 5, referer: http://localhost/fog/management/index.php?node=about&sub=log

I have a similar request to what I understand you want to do.

https://forums.fogproject.org/topic/6014/create-the-concept-of-a-foreignmasterstorage-deployment-node

You can get pretty close by using the location plugin by installing a deployment fog server in each location. Then from a master deployment server you can move files to the site deployment server via the normal storage node replication. This is not a typical setup but I can get the images deployed to the sites this way. The only issue is getting the database entries from the master deployment server onto the site’s deployment server database. I can do this by scripting, but its not built into the logic as of yet.

I would take a look at the apache log file. It sounds like you came across a bug. tail the contents of /var/log/httpd/error_log and post the last few lines here. That may give us a better idea to the source of the issue.

When I installed the access control plugin and then activated it the page turned white with no response for a minute (probably longer since I did not want to wait).

In the http error log there was this error.

PHP Fatal error:  Call to a member function isValid() on null in /var/www/html/fog/lib/plugins/accesscontrol/hooks/RemoveMenuItems.hook.php on line 13, referer: http://10.12.1.88/fog/management/index.php?node=plugin&sub=install&run=bd6bf52053b1ddb064bd3c493bfc47ef&plug_name=accesscontrol&install=bd6bf52053b1ddb064bd3c493bfc47ef&plug_name=accesscontrol

Refreshing the management page created this error.

PHP Fatal error:  Call to a member function isValid() on null in /var/www/html/fog/lib/plugins/accesscontrol/hooks/RemoveMenuItems.hook.php on line 13

I seem to remember this same issue when I upgraded from a svn trunk to the next svn trunk sometime in the past.

The previous posts dealt with adding a new disk using the traditional partitions. Most linux distributions today use LVM to manage the disks. With LVM one could create a new vmdk, create a partiton on it, add it to the volume group, and then extend the logical volume to the new size, and then run the resize2fs command and be done with it.

But that really doesn’t fix the issue in that the /images and /opt/fog/snapins are still mounted on the root file system. All the above will do is delay the OS getting whacked for some period of more time. The right answer is to create a new disk/partition LVM or physical and then use the mount point method outlined below to mount the new disk over the /images directory. This way we are sure that the OS will never fill up with captured host images.