Alright, well I already addressed the “file not found” type problem in the RC’s thanks to this. So at least there’s that.

Quick design as I see it in my head:

SRO is “main” server.
MHB is the “slave” server.

SRO Should have a Storage group containing information about both the Main (SRO) and Slave (MHB).

The “Master” node in the “Main” server will be the SRO Node. MHB will just be a part of the group.

All images associated on SRO will only need to be on the SRO Storage Group (this will cause the SRO Server replicate its images to MHB). All that’s needed here is the IP of the MHB and the FOG linux user and password.

The MHB Server will have it’s own group. It also has its own Database.

The MHB Server will also contain its own Node as master. There should not be any need for any other storage nodes on the MHB Server.

The SRO Server should have the Image definitions exported which can then be uploaded to the MHB Server. No need for a database dump as the only group either server will ever have should only be with ID 1 (if nothing has been changed otherwise of course).

This should be all that’s required. When the client machines attempt booting from the MHB network, they should ONLY request the information from the MHB Server and node.

@sbenson So:

SRO side Needs:

Master (SRO-FOG-01)
Slave (MHB-FOG-01)

MHB Side Needs:
Master (MHB-FOG-01)

@sbenson It’s kind of intentional to ensure a “clean state”.

The very basic model of a “windows storage node” would be:

FTP with fog user/password to the location of the /images equivalent on the windows side.
NFS exposed for the /images side.

The basic structure on the Windows server would require:
/images/.mntcheck (blank file)
/images/dev/.mntcheck

I’d also recommend creating the postdownload and postinit scripts:
/images/postdownloadscripts/fog.postdownload
/images/dev/postinitscripts/fog.postinit

The /images should be in “CHMOD 777” (Read, write, execute for everybody)

The basic contents of fog.postdownload should contain:

#!/bin/sh
## This file serves as a starting point to call your custom postimaging scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post download scripts are
#. ${postdownpath}<SCRIPTNAME>

The basic contents of fog.postinit should contain:

#!/bin/bash
## This file serves as a starting point to call your custom pre-imaging/post init loading scripts.
## <SCRIPTNAME> should be changed to the script you're planning to use.
## Syntax of post init scripts are
#. ${postinitpath}<SCRIPTNAME>

This will allow customization of your stuff, but you will not “see” this server on the dashboard.

Basic node information:

IP Address of the Windows Server
The path as shared
The ftppath as shared (likely the same as the original)
The fog ftp username
The fog ftp password

The snapins and ssl paths will be required but won’t truly exist so set these to fake paths if you want.

@Joe-Gill said in Authentication Error:

5/16/2017 3:48 PM Middleware::Response Error multiple hosts returned for list of mac addresses

The quoted text is the problem, which means it doesn’t know which host to associate with.

I don’t know that the DB is necessarily “dirty” persay, but most likely one of the mac’s being passed is associated to more than one host. (This is bad and technically dirty I suppose, but can happen for more reasons than “corrupt” database though much less likely now than in the past.)

@Joe-Gill Does your mysql root user have a password?

@Rayco I don’t know how you created the menu, but maybe this can help:
http://ipxe.org/howto/winpe

Whats output of:

sha512sum /var/www/fog/service/ipxe/init{,_32}.xz
sha512sum /var/www/fog/service/ipxe/bzImage{,32}

They should be:

90744197466056e6c216ae071f6397e0eb1908b15a17ca92d16d88720784bab638673cac83423c766170a2ffa59e06737c171426ffd77aff57c85abfbd4a1dff  /var/www/fog/service/ipxe/init.xz

d1d4ff715da92cd23bf10ea9e8e24913d0da974ac1bc805e9afaae7ae0e9a41fc6577d097b157ced0af1e05400052d3e782bc6abb616f1b7069c8fef037ea062  /var/www/fog/service/ipxe/init_32.xz

c75abc75be06a219920c5c29809436ba66f9d1b5f56af757ee8a28393620e83d0b44f3f8bb582b4e8ad01c4c3e247fde99916d06ff3374631ac3453e042dc3f8  /var/www/fog/service/ipxe/bzImage

0e465ea8c7607377d5f023c5be9838392ba3ef3ab0c793125cde4d5d1cf40c60dc17518be7d6c71ef65e8b261a3d0fce3fa380f6e07bbcaa0fbf59bd72d59b4f  /var/www/fog/service/ipxe/bzImage32

What bootfile are you using to boot from? We often see this error if you’re using pxelinux.0.

For what it’s worth, I think I know why this isn’t working right.

For this image (and possibly others) you should see something in the “Image Manager”.

Based on what I’m seeing (so far) the compression type element is missing from your Image management page?

It should look similar to:

Why is this important when in the past it wasn’t? Because we have zstd, pigz, and uncompressed modes now. In the past, it only assumed partclone with gzip IF the type was not partimage. The check was basically:

case $format in
    1)
        pigz -dc </tmp/pigz1 | partimage restore ${target} stdin -f3 -b 2>/tmp/status.fog
        ;;
    *)
        pigz -dc </tmp/pigz1 | partclone.restore --ignore_crc -O ${target} -N -f 1
        ;;
esac

In the new method, it uses:

case $format in
    [5-6])
         zstdmt -dc </tmp/pigz1 | partclone.restore -n "Storage Location $storage, Image name $img" --ignore_crc -O ${target} -Nf 1
        ;;
    [3-4])
        cat </tmp/pigz1 | partclone.restore -n "Storage Location $storage, Image name $img" --ignore_crc -O ${target} -Nf 1
        ;;
    1)
        pigz -dc </tmp/pigz1 | partimage restore ${target} stdin -f3 -b 2>/tmp/status.
        ;;
    0|2)
        pigz -dc </tmp/pigz1 | partclone.restore -n "Storage Location $storage, Image name $img" --ignore_crc -O ${target} -N -f 1
        ;;
esac

Notice there is no *) line? My guess is the image is not sending the format code when the tasking begins. This should occur automatically if you run an update.

If you’re rerunnign the 1.4.0 installer, please remove the binaries1.4.0.zip file from the installer root:
(eg. from bin folder run rm ../binaries1.4.0.zip THen run the installer.

@VijayBomble images in the GUI must be defined. They are not automatically populated.

@wanderson Those “last insert ID” errors are almost always fixed because:

https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

That said, when updating, you probably need to refresh the page (after ensuring the DB is usable).

@x23piracy It’s not on THAT host. It’s from a common mac from other systems that are sending a MAC that IS on that host.

@x23piracy IT HAS NOTHING TO DO WITH it4313

It has to do when a mac address that IS registered to it4313, but being presented from the other systems.

Goto:
FOG Configuration Page->FOG Settings->General Settings->FOG_WEB_ROOT

Change from WEB_ROOT to /fog/, boom presto success.

I would suggest updating first. It’s been a while, but I believe there was a bug with this that I’m pretty sure has been corrected for.

The part that’s important, however, it’s not restarting to change the hostname. It’s restarting because it thinks there’s a task for it to complete.

That /opt/fog/.fogsettings file, pelase edit the snmysqlpass line to make it match what you “know” what it is. THen rerun the installer. Apparently it got changed at some point in time.

@UWPVIOLATOR I’m sorry I’m not 100% on the way the client does the hashing. I know we do test things, but it would seem maybe it can’t write to the same point on the client machine and is coming up with a sha512 hash of 0 byte file? (No I don’t expect you to have the answer).

@Wayne-Workman We ran through manual hashes and the fog server hash is correct. I haven’t seen a client hash fail except under relatively certain circumstances.

I’m just guessing, but maybe antivirus is quarantining/removing the file before it is able to be checked. Maybe there’s a content blocker not allowing the file to pass to the client?