@Albertus At this time there is no defined release date for 1.3.0 stable. The developers are working hard to get the trunk version to the stable level.

The situation is the more people we can get into the trunk version to find the bugs, the quicker the bugs can be identified and resolved. If people not upgrade waiting for the stable release the longer it will take to find the bugs. So the best situation is to get as many people as possible into the trunk stream to identify issues faster. This will make the 1.3.0 release come faster too.

Understand when I say bugs, the trunk is not unstable today. There are many updates to fog per week as the code is fine tuned for best performance. So you will need to update your fog code frequently to take advantage of the performance improvements.

Great, thanks for your feedback! I will try your suggestions and will post the results here on the forum.

@Tom-Elliott I’m breaking my install with upgrade process 😞

I’ll try to fix and would do a new installation on a different server 🙂

@Tom-Elliott Installation worked, but I’m getting

Type: 2, File:/var/www/html/fog/lib/fog/fogftp.class.php, Line:104, Message: ftp_login():Login incorrect.

This is what I see for both nodes when going into log viewer.

I checked the .fogsettings file and password in GUI under storage mgmt with no luck.

UPDATE– Nevermind I forgot to change the password for the fog user as well.

@george1421 I already do.

Just updated again. Seems to be working just fine now. Thanks!

@Tom-Elliott yessir, sorry so long to get back to you, but that was it, and client registers normally now. I guess that’s the only interface I didn’t check for in database…Loopback I guess

@Wayne-Workman
Ubuntu 14.04.2 LTS
Fog 1.2.0

@moses found the type hinting, really kind of wish the secondary bits would’ve been put in a separate posting, but all in all everything should be functional again.

@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.