Posts made by george1421

Looking in the code this is what I see for the replicator. It uses lftp to move the files.

"lftp -e 'set ftp:list-options -a;set net:max-retries 10;set net:timeout 30; ".$limit[$i]." mirror -c -R --ignore-time ".$includeFile[$i]." -vvv --exclude 'dev/' --exclude 'ssl/' --exclude 'CA/' --delete-first ".$myItem[$i].' '.$remItem[$i]."; exit' -u ".$username[$i].','.$password[$i].' '.$ip[$i]."

The proper limit parameter for lftp is this: net:limit-rate 0:512000 where the first number is the download rate and the second number is the upload rate (in Kb/s).

Looking a bit deeper into the code I see this:

if ($limitmain > 0) $limitset = "set net:limit-total-rate 0:$limitmain;";
if ($limitsend > 0) $limitset .= "set net:limit-rate 0:$limitsend;";
$limit[] = $limitset;

I’m questioning the extra period in the second line and the format just seems a bit off.

I understand that a bit, but I come from the redhat world so it is not as foreign to me than when I use ubuntu (fwiw: I use zorin on my home computer which is ubuntu based). The ifconfig vs ip … does throw me every time I use ubuntu also.

While the worlds are a bit different FOG did install ok on Centos 7. I can say I used this wiki page [https://wiki.fogproject.org/wiki/index.php/Installation_on_CentOS_7] for the syntax to turn off selinux and to disable the firewall. All other things install the same between 6.7 and 7.

You didn’t mention if your fog server is behind a proxy server or does it have direct internet access? If it has direct internet access then there should be nothing else you need to do to make it work.

It sounds like you gave up on it because it was too different more than FOG flat didn’t work on Centos 7. We just want to ensure that there isn’t a problem with FOG running on Centos 7, because then the devs will need to dig into why.

OK, I was able to install FOG SVN 4344/Git 5235 on a newly created centos 7 server. I did forget to disable selinux at first, but I disabled it, rebooted and reran the install.sh script again. The install script completed without issue. As far as I can tell the server is up and running. I haven’t captured an image yet with it, but all of the menus and plugins respond as I expect (the authorization plugin is still broken, but that is a topic of another thread).

Where did the install fail for you?

Is your cento 7 box behind a proxy server, because there are some tweaks that need to be done first? (but same tweaks are needed for centos 6.7)

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.