@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.
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.
I would recommend that you create this new disk on its own vmdk without any additional partitions. Because there are some linux magic tricks we can do to grow this new disk if we ever run out of space in out /images folder again. Understand this time we will not crash the FOG server since all of our images are NOT on the root partition that the OS uses.
These next steps should only be taken by a seasoned linux professional, because there is a risk that if done wrong you can loose all of your host images. I’m not going to give all of the steps because if you are a linux professional you will know what to do. So step one and two of this next part is make a full system backup and make a second full system backup. I should also note that these steps only work for FOG servers running on a virtual machine. The physical guys can’t expand a hard drive larger that it was made as.
fdisk /dev/sdb1e2fsck -f /dev/sdb1resize2fs /dev/sdb1mount -a command.We need to unmount the new hard drive from the /mnt/test mount mount point with this command
umount /mnt/test
Run the df -h command to ensure that sdb1 has been unmounted.
Then clean up the test folder (not needed anymore) with rmdir /mnt/test
Now we need to mount our new hard drive over the /images folder. We can do this with the following command
mount -t ext4 /dev/sdb1 /images
Change to the /images folder and you should see all of your host image files.
At this point we are almost done. If we were to reboot the FOG server this manual mount command would not be active after the reboot. So lets make this change permanent.
You will need to edit the fstab in /etc Insert the following line info fstab at the bottom.
/dev/sdb1 /images ext4 defaults 0 1
Now lets unmount the images folder with all of the host image files.
umount /images
If you show the files in the /images folder it should be blank.
ls -la /images
Now lets mount the /images folder again using the following command
mount -a
Us the df -h command to show that we’ve mounted /dev/sdb1 on /images.
Reboot your fog server and use the df command to make sure your images are remounted over the /images folder.
We know that the new disk is /dev/sdb so use fdisk to create a new partition on the blank disk. If you have questions about fdisk google it.
fdisk /dev/sdb
Create a <n>ew
<p>artition
numbere <1>
<default>
<default>
<w>rite the changes to disk
<q>uit fdisk
Next we need to format the new partition with our linux file system.
mkfs.ext4 /dev/sdb1
With the new disk formatted we need to connect it to our really full FOG server. If your fog server is 100% full you may have a problem with the next command you may need to find and delete an unwanted log file from somewhere to make a little room to create a new directory.
For this step we will create a mount point to connect our new hard drive to
mkdir /mnt/test
Now we’ll attach our new disk to that mount point
mount -t ext4 /dev/sdb1 /mnt/test
if you run the lsblk command again you should now see that sdb has a partition sdb1 <note this instruction probably should appear before the we formatted the filesystem just for the flow of the document>
The command df -h will show both the root file system and the new hard drive mounted on the /mnt/test mount point.
Now we need to move the host image files from the /images directory onto our new empty hard drive.
mv /images/* /mnt/test
After a bit of churning your host image files will be moved to the new disk.
After all of your image files are safely on the new disk we need to unmount the current mount point and remount the new disk over the /images directory.
My recommendation would be for the developers to move the /images folder to another location like /opt/fog/images so that it is along side the snapins folder, so this could be done with one action. With that said, there are ways to get the file system back without loosing or deleting the images stored on the FOG server. This “fix” involves some advanced linux understanding but it isn’t that difficult to do.
First of all if you have your FOG server running in a virtual machine these steps will be easy since you will need to create a new (additional) virtual disk and attach it to your virtual machine. This will create two hard drives attached to your FOG server. If you have a physical FOG server you will need to had a second physical hard drive to make this work.
(the rest of this will assume you have FOG running on a virtual machine) With that second hard drive (vmdk) added to your FOG server run the following command
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 298.1G 0 disk
├─sda1 8:1 0 294.3G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 3.8G 0 part [SWAP]
sdb 9:0 0 100.0G 0 disk
As you can see above there are now 2 hard drives attached to this FOG server. There is /dev/sda that’s about 300G and /dev/sdb that is 100G in size.
We are going to take that 100G (new) vmdk file and put a partition and file system on it and then finally mount it on a temp location so we can copy the files in /images to it and off the root file system (which is currently 100% full).
This is more of a discussion than a help request.
We had an issue where we ran out of disk space on one of our test environment FOG servers. The problem started when we uploaded more host images than we had space on the FOG server. Searching the FOG server we saw that the host images are stored in /images and the snapins are stored in /opt/fog/snapins. Both of these folders exist on the root file system. Coming from old school unix we would typically create the /opt and /home not on the root file system because these directories typically grow the most. And on the older unix file systems if you fill the file system the OS crashes very badly.
(note for any of this thread to be understandable you need to read from the bottom of this thread to the top since the later posts appear first)