Does FOG work with iSCSI?

[ManofValor]

I’m not sure I quite understand this message during the FOG install/update. Am I supposed to add those two lines to the .fogsettings file, cause I don’t see them in there? If so, does it matter where it goes?

 ########################################################################################
   FOG has adjusted to using a login system to protect what can/cannot be downloaded
   We have detected that you don't have credentials defined to perform the backup
   If you would like the database to be backed up during install please define
   in your /opt/fog/.fogsettings file

   fogguiuser='usernameOfFOGGUI'
   fogguipass='passwordOfFOGGUIUser'

   You can also re-run this installer as:

   fogguiuser='usernameOfFOGGUI' fogguipass='passwordOfFOGGUIUser' ./installfog.sh -y
########################################################################################

Also, I believe I’ve got the iSCSI mounted right and ready to try an image.

# /etc/fstab
# Created by anaconda on Thu Feb 18 14:47:41 2016
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/centos00-root00 /                       ext4    defaults        1 1
UUID=31117e50-bdd0-446a-8527-e08cebd24684 /boot                   ext4    defaults        1 2
/dev/mapper/fog-opt_fog_images /opt                    ext4    defaults        1 2
/dev/mapper/centos00-swap swap                    swap    defaults        0 0
/opt/fog/images /images bind bind 0 0
/dev/sdb1 /opt/fog/images 

[root@localhost bin]# df -H
Filesystem                      Size  Used Avail Use% Mounted on
/dev/mapper/centos00-root00      22G  7.4G   13G  37% /
devtmpfs                        2.0G     0  2.0G   0% /dev
tmpfs                           2.0G  6.6M  2.0G   1% /dev/shm
tmpfs                           2.0G  9.4M  2.0G   1% /run
tmpfs                           2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/sda5                       1.1G  308M  639M  33% /boot
/dev/mapper/fog-opt_fog_images  424G  240G  163G  60% /opt
/dev/sdb1                       8.9T   95M  8.5T   1% /images
tmpfs                           397M  8.2k  397M   1% /run/user/1000
tmpfs                           397M     0  397M   0% /run/user/0

[root@localhost bin]# ls /opt/fog/images -a
.  ..  dev  lost+found  .mntcheck  postdownloadscripts
[root@localhost bin]# ls /opt/fog/images/dev -a
.  ..  .mntcheck

[Tom Elliott]

@ManofValor I think you are almost there.

Last bit, I’d do if I were you.

Make sure permissions are proper.

Run: chmod =R 777 /images

Then run her up and see how it goes.

[ManofValor]

@Tom-Elliott Awesome thanks. What about the first question, the FOG update one?

[Wayne Workman]

@ManofValor said in Does FOG work with iSCSI?:

@Tom-Elliott Awesome thanks. What about the first question, the FOG update one?

It’s not critical, but for backups to automatically happen when you re-run the installer or update, you need those fields inside of /opt/fog/.fogsettings just like it says. All you’d do is just add them, just as it says.

Also, the command Tom gave has a typo. He was probably on cellular.

It’s chmod -R 777 /images

[ManofValor]

@Wayne-Workman said in Does FOG work with iSCSI?:

It’s not critical, but for backups to automatically happen when you re-run the installer or update, you need those fields inside of /opt/fog/.fogsettings just like it says. All you’d do is just add them, just as it says.

Ok, thanks.

Also, the command Tom gave has a typo. He was probably on cellular.

It’s chmod -R 777 /images

Yeah I caught that. See I’m learning something…lol.

[ManofValor]

Also, I’m still getting this error when clicking on the FOG Configuration in fog management.

Not Found

The requested URL /static/index.html was not found on this server.

[Wayne Workman]

@ManofValor you could try blasting everything in /var/www except the html directory, and the blast everything inside of /var/www/html directory, and then re-run the installer.

[ManofValor]

@Wayne-Workman When you say blast I assume you mean delete? Just making sure its not another term or something…lol.

[Wayne Workman]

@ManofValor yes. Blast sounds so much more exciting than delete.

rm -rf NameOfFileOrDirectory

[ManofValor]

@Wayne-Workman Haha, I agree.

[ManofValor]

This post is deleted!

[ManofValor]

@Wayne-Workman Still the same error.

[Wayne Workman]

@ManofValor I have no earthy idea why that page is being requested then. If you have time to do a TeamViewer session I can try to figure out why.

[ManofValor]

@Wayne-Workman Ok, check your PM.

[ManofValor]

OK, so I started to image and got this:

Tried to Google but no luck.

[ManofValor]

Got a strange thing happening. I’m on my Win7 machine, my usual work space, when I go to FOG management and storage node the password is the same as my login. When I look at it from my FOG server it’s the usual randomly generated password. When I try to update it back to random password it won’t change. The password under .fogsettings is the random password. What am I missing?

[Quazz]

@ManofValor This is detailed on the wiki, it’s because of the browser auto fill feature. Turn it off for fog website.

[ManofValor]

@Quazz Thanks, that worked.

[Wayne Workman]

I remoted in with TeamViewer and figured out why it was redirecting to that /static/index.html page.

There were two nodes configured (incorrect in this particular scenario), one pointing to the fog server, another to the iSCSI device’s IP.

So, in FOG Configuration, it’s written to report the kernel and other info on all attached nodes. A web query was being made to that second (incorrect) storage node, and the NAS was redirecting to the aforementioned page.

Since iSCSI is a block device, and mounts like a local HDD, the secondary node was incorrect.

After deleting that incorrect node, all started working fine, and the main server which has the iSCSI device mounted as a local HDD is correctly displaying the available space on the dashboard so all should be fine now.

Tom had hinted at this, and that’s what I was looking for. Storage Management was literally the last place I looked for problems (of course). I actually ran a WireShark capture during the redirect and figured out the server was talking to the iSCSI device’'s IP via port 80, and that led me to find the issue.

[ManofValor]

So this post can be solved, everything is working. I created an image and then redeployed it. Now on to looking into sysprep. Thanks guys.