@Wayne-Workman said:

What options do you have available in the NetApp? You also need FTP permissions for it to work right.

I was just trying nfs for the fire in storage mode uses nfs, but I will see if I have this feature and put the result.
Thank you

@danilopinotti said:

in the installation, i’ve set the Fog to use the eth1 interface, and even then, the default storage was set to eth0.

Tom got that fixed in the trunk.

@Hanz Seems as though there are a few hosts with competing clients…that is the newer version installed and then the older is getting installed via gpo.

@Wayne-Workman
i didn’t change it. it was always resizeable.

@Wayne-Workman Thank you, Wayne. That really does clear things up. It sounds like the easiest thing to do (short of upgrading to trunk) is what I’ve been doing. Do a round of image updates and assign them to default. Clear ‘is master’ from all other storage nodes and move them to default group. Watch the logs for the sync to complete, move them back to their respective groups, recheck ‘is master’ on SNs since I only have a single SN per group. I only update these images a few times per year so that’s really not that painful. I could manage rsync scripts or a manual process but I’d rather let FOG do it especially if 1.3.0 will be along sometime in the not too distant future. Much appreciated!

@tgeyer What separate config would that be?

@george1421 said:

We do have a list of required ports that JBob put together.

Those are in the forums, but I’ve added them to the Wiki a while back, here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_security

While I said multicasting would not work, I should clarify that multicasting will only work on one interface of your consolidated FOG server.

I’m thinking that if he maintains separate Storage Groups per interface, and make each one a master, it would work. images can be shared across storage groups. But all replication only happens from the original storage group to the others, and not the other way around.

I still don’t understand why the OP is even doing what he’s doing though. Albeit I’ve not given this thread hardly any thought.

@Tom-Elliott I updated before testing again, yes, still this issue. Don’t know if it’s related but something similar happens with the debug options.

@Tom-Elliott You are fired.

@wlainey said:

nce I realized that SELinux had not been configured properly by using ‘setenforce 0’ everything starting working fine.

You’ll need to set it permanently to permissive as well - you would edit /etc/selinux/config to do that. If you don’t, it’ll stop working again at the next reboot.

Moving thread to solved.

A lot faster now 👍

Thanks for your help.
Regards

@Sebastian-Roth Yes, because he found a boot file that worked, and because we gave him instructions on how to make both work at the same time.

although wasteful, this command should fix it:

cd /;rm -rf /opt/svn;mkdir /opt/svn;cd /opt/svn;setenforce 0;systemctl restart firewalld;for service in http https tftp ftp mysql nfs mountd rpc-bind proxy-dhcp samba; do firewall-cmd --permanent --zone=public --add-service=$service; done;systemctl restart firewalld.service;systemctl enable firewalld;yum install svn -y;svn co https://svn.code.sf.net/p/freeghost/code/trunk;cd trunk/bin;./installfog.sh

Also - you can permanently disable SELinux by editing the /etc/selinux/config file.

@Tom-Elliott added a bit to the wiki about this. https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#MySQL_credentials_for_FOG_Main_and_Storage_Nodes

@Wayne-Workman said:

Well if they don’t, they will. Today is a snow day so I get to dive in again tomorrow.

No worries, stay warm and safe.

Thanks for all your help. I hope so as well.

@Scott-Adams And there is another thread where we got past the “No Network Interface Found” issue I think. Try adding has_usb_nic=1 the host’s kernel parameter (host settings)! But it depends on the USB NIC used. We have pretty much every USB NIC driver included in the kernel but I guess there are devices out there for which the kernel does not have a driver (yet). Just give it a try and let us know.

And please see exactly which USB NIC you have. Read through this interesting discussion on Surface 3. The first couple if posts (page 3) we talk a lot about the two different MS surface adapters and the NIC chip they have.

As well make sure to update to the very latest trunk version. There have been a lot of fixes!!

Edit: Re-reading the surface3 posts I remembered that we needed to add the PCI IDs for the MS USB NICs to the kernel. As far as I know those should work if you upgrade to the latest trunk!

@Wayne-Workman said:

I’d estimate that 5 to 10 percent of imaging issues encountered are due to a bad HDD.

Yeah right! We’ve seen this “quiet often” lately… Good to know that it wasn’t FOG doing something wrong.

So all issues here seam fixed now… solving this!

@Junkhacker This fixed it for me. I changed my exit from the default (Sanboot style) to ‘GRUB Style’. ‘exit style’ didn’t work either. Oddly, this FOG server is a new install post development (in the ‘IT service’ prep sense). During dev on the old test server we didn’t have this issue. Not sure what changed.