Posts made by george1421

That’s a bit more strong arm than I think would be needed. Typically you “whould” have an enable/disable flag for the image and just turn it on and off via a checkbox. When you delete the image definition you loose the existence that image was ever there instead of just turning it off for a bit.

@Wayne-Workman said:

I would suggest we pool our knowledge to just create some base-level scripts that will sync two DBs based on the exact same rules that the FOGImageReplicator follows. I’ve outlined these rules before in other threads.

I’m not thinking anything drastic. Its more like how pfsense sends http calls to a remote node to sync its configuration data. While its a bit deeper discussion that we should do here. The idea would be for the FOGReplicator to move the files as they do today. When all of the files in the current image directory have been moved, then make a http call to a php page the remote node (it should already know everything it needs to know to do this [i.e. no new database fields]) which adds the image information to the remote database.

@Tom-Elliott

That is pretty much what I have with the bashrc settings. The issue is that the no_proxy points to localhost and the script calls the fog server IP address [from my memory].

BUT I could use bits of what you posted with something like this. (understand I already have the exports for the http_proxy… in my bash rc)

no_proxy="<ip_add_fog_server>" ./installfog.sh -y

That would allow the installer script to run unaltered and still tell wget to no proxy for the fog server IP address. I don’t know how big an issue this is or how many fog servers are behind proxy servers. I just wanted to get it documented for others that may find this post.

I can see for beginners creating a partitions for the image is a bit daunting depending on the distribution. I’m not sure if there is an easy solution for this. I’m sure I could document it for Centos 6 without much pain, but I see the majority of the deployments here are ubuntu.

As for the vmdk stuff that is pretty easy, to add a second vmdk and mount that for just the /images. As for expanding the vmdk, I do have to look it up every time I do it, but it is also pretty easy.

I’ve got the e6440 on my network and they deploy fine with FOG.

Not related to the e5440, make sure for dhcp option 66 you enter the IP ADDRESS of the fog server not the name. Some pxe boot loaders are pretty dumb and do not do dns resolution correctly.

It sounds like you entered the right value for dhcp option 67, that should be undionly.kpxe with no path or spaces on either side.

As for the system it sounds like you have that right too. Legacy mode, secure boot off and you need to enable the legacy rom.

@Wayne-Workman said:

@slovisa After freeing up some space, you’d repair mysql. let me see if I can find some commands for that… I’ve done this before at my site when a past bug caused apache logs to grow out of control…

Just a comment here: standard practice is to move the /home /opt (and a few other) directories to something other than the root partition/filesystem. Having the /images directory in the root partition will lead to the corruption the OP has now. While I’m not shaming here, it would be good practice to move the fog /images folder to something other than the root partition, like /opt/images. In addition recommend during the OS build instructions to put the /opt directory on its own hard drive partition. (on a virtual machine I would even recommend its own vmdk file. The logic here is this is where your deployment images are, if you run out of space in the partition, you can extend the vmdk file then extend the fs to give more room for your images quick and easy.)

OK on the system history. Sometimes you don’t know unless you ask first.

As for the commands it appears that the mysql service is not running and since I’m from rhel land (redhat) I don’t know ubuntu commands very well.

A quick google-fu excersion shows me this command.
sudo /etc/init.d/mysql start

That should start the mysql service.

I need to provide a way to bock an image from being deployed, or being scheduled to be deployed. If you are working in an environment when many techs its possible that an image may be put on hold for several reasons. We need to stop that image from being deployed to the targeted hosts. The request to deploy could come from the GUI interface or via a quick image via the PXE boot menu. In either case we need to block deployment until/if the image is released for use.

One of the areas of concern is about version control. We may need to leave a previous version of an image on the fog server until the new version is fully vetted. That previous version needs to be lock/blocked/disabled from being redeployed. Because the image name is saved in the host record its important to keep the blocked image from being used. It would also be handy to have a nice message to indicate why the image is not allowed to be deployed at this time.

I can tell you through testing I know this so far.

1. You can do this mostly with a storage node and the location plugin.
2. The storage nodes don’t have the bits required for tftp to work

Some caveats to what I just said.

1. The storage nodes are storage nodes only. You can add the tftp service description for xinetd and the tftp files. But the storage node is not a fully deployment node. There is no user interface, all of the techs must access the master node to deploy images to the remote locations.
2. The storage nodes do not have a local mysql database (as far as I can see). They connect back to the master deployment node to access its database. I see this as being an issue with latency when crossing a WAN link.

I have been thinking of ways to map this out to do what ( I ) need it to do, but it would be one off and fragile at best. The best solution is to have this done natively within the program and not use any external hacks.

Well the error is telling me that the mysql service is not running.

Tell us a bit more about this system:
Is this a new install? If not how long has it been in production.?
Have you made any changes to the server since it last worked?

On to the issue if you open an command window and issue the following command.

ps -aux | grep mysql

Does it show the mysqld service running?

If not then issue the following command (sorry its in rhel syntax)

service mysqld start

or change to the /etc/init.d folder and issue

./mysqld start

To start the service will be distribution specific but the idea is to start the mysql server and see if you get the same results.

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.