Are these directories shared via nfs (using the command I provided)?
and to answer your question if you cd to the /images folder then issue a
ls -la *
command that will show you file ownership and access rights.
Are these directories shared via nfs (using the command I provided)?
and to answer your question if you cd to the /images folder then issue a
ls -la *
command that will show you file ownership and access rights.
While I don’t have an answer for you, I do have a feature request out there for the exact same thing. https://forums.fogproject.org/topic/6014/create-the-concept-of-a-foreignmasterstorage-deployment-node
Right now there the only way to do this is manually or scripting via sql dump and sql import of the images and snapins tables between the deployment nodes.
You can do something similar but with storage nodes (not a master deployment node), and you will need to install the /tftpboot files on the storage node. You will need to use the location plugin and storage groups.
For clarity my bashrc file now has these settings in it because my fog installs are behind a proxy server. If your FOG server has internet access then these settings are not required.
export http_proxy=http://<proxy_server_ip>:<proxy_server_port>
export https_proxy=http://<proxy_server_ip>:<proxy_server_port>
export ftp_proxy=http://<proxy_server_ip>:<proxy_server_port>
export no_proxy="localhost"
Well I found a work around, but its not very elegant.
If I update my bashrc file to export this env variable.
export no_proxy="localhost"
… and then change the wget command in the installfog.sh script from $ipaddress to locahost the backup script works as intended.
wget --no-check-certificate -O $backupPath/fogDBbackups/fog_sql_${version}_$(date +"%Y%m%d_%I%M%S").sql "http://localhost/$webroot/management/export.php?type=sqldump"
The 5221 trunk is failing to install on a centos 6.7 box. It worked for 5201 (I think)
* Setting up SSL FOG Server...................................OK
* Restarting Apache2 for fog vhost............................OK
* Changing permissions on apache log files....................OK
* Backing up database.........................................Failed!
Digging into the install script code a bit, the issue is the sql backup script, wget and my FOG systems being behind a proxy server.
The issue is the wget command that calls the sql dump page. With my fog servers behind a proxy server, to make the install script work I had to add the proxy settings to /etc/wgetrc file as well as the bash environment variables. I guess that wget is not smart enough to know that the ip address for the fog server is local and tries to access the poxy server for the page and gets a failed connection refused. Even tweaking the IP address in the command to 127.0.0.1 gives the same results. I need to have the proxy settings in place for wget or the rest of the install script will fail.
The FOGImageReplicator is run as a service not a cron job. Look in the /etc/init.d directory for the service descriptor. (next is going to be a rhel based command) Run the chkconfig FOGImageReplicator --list to show you if the image replicator service is set to auto start. Under debian based systems chkconfig may not be installed by default.
I guess I have to just throw this out since you are starting with a new deployment.
Is there any thought of changing your OS from Ubuntu to Centos? In my test environment I’ve spun up about 10 - Centos 6.7 systems with FOG in the last 2 weeks and deployed all of the trunk images without any deployment issues. In monitoring this forum for the last few weeks the majority of the install issues appear to be with the Debian based systems. I’m not saying that one OS is better than the other, but if the goal is to test FOG, then switch OS for the test and work out the kinks with the specific OS deployment later.
Another quick command you can run from a linux command shell would be
showmount -e localhost
That should show you the nfs shares currently enabled. If the /images share is available, then check into directory file ownership and permissions.
for clarity I found those commands in <fog_trunk>/lib/common/functions.sh In case you want to update your way to an answer.
I’m just pecking in the dark here. But looking at the installer script (actually a called subfunction). This is what is going on in that area.
add-apt-repository -y ppa:ondrej/php5-5.6
if [ "$?" != 0 ]; then
apt-get update
apt-get -yq install python-software-properties
add-apt-repository -y ppa:ondrej/php5-5.6
fi
I might suggest that you try the apt commands one at a time and see what fails. Again I’m just guessing here, these commands will not do anything destructive.
I guess I’m going to have to defer to one of the developers on this one. It almost sounds like there is a bad setting in the .fogsettings file because its trying to use a resource that it doesn’t have access to.
Was this a fully functional FOG server at any time?
Interesting, (just questioning). You say you have direct internet access yet svn did not work?
SVN should work right out of the box without any changes, if you had a proxy server between your FOG server and the internet then you need to make a few adjustments. Something is up here. The first thing that the update does is tries (at this point) is to talk to your distribution repository server(s).
Sorry for the 20 questions,
What OS and version is this on?
Can you try to use subversion to checkout the current trunk?
It sounds like the installer script can’t reach the correct repositories. Have you don’t a OS update apt-get/yum ??
Just for clarity how do you have internet access on this box? Does it have direct internet access or is this box sitting behind a proxy server of some sort?
If I understand what you are saying then, in the fog settings I would set the OU to your computer’s OU, then when you setup the host change it to the proper location for that host. You can do it one by one in each host’s active directory settings, or via applying the setting to a group of computers all at once. (as you noted the group does not retain the new setting but all hosts that are members of that group have the new setting applied)
I guess I’ll have to defer to the developers on this one, sorry. This is a bit beyond what I know.
I would suggest that you get one working. Once you have one working then you can use the update group function to change all the rest to the correct OU, and finally update the defaults in the fog settings so any new systems will have the right settings.
Ok so they are not installed in the path I posted? You can pick them up from the sourceforge site or just rerun the installer again.
I have two questions for you:
The reason why I ask, I had an issue where the fog server was behind a proxy server and I applied the svn trunk update almost everything installed fine except the new fog client wouldn’t download and I couldn’t pxe boot because the boot images were missing. I found the issue that the svn installer uses curl to get the fog client and boot image files but since curl didn’t know about the proxy server settings it would just fail to get them. I had to set the environment variables to point to the proxy server then everything worked OK.
(edit) The boot files need to be in this path: /var/www/html/fog/service/ipxe and the file names are bzImage and init.xz. If they are missing FOG will display the boot menu but if you select anything the target computer will just restart (/edit)
I can tell you yes, the format needs to be in ldap format and it appears you have the right format as long as the maintenance OU exists under your main OU (like Computers do) then it should place it in the right spot. I can say from one of my installs I have (ou=Desktops,ou=Computers,ou=NYC,ou=US,dc=domain,dc=local)
Since your target computer is ending up in the Computers OU you must have the right information to join the computer to the domain so the FogCrypt part is right too.
When you make a change to the group… everything disappears. That one got me too. FOG applies the information to the host based on the group but the group doesn’t keep the settings. It would be logical for the group to retain this setting but it doesn’t, it is just used to apply the values to the host. I would go into the target host you are interested in and check the AD settings there. Make sure the proper OU settings are there, then redeploy the host again.