Windows FOG storage node and multicasting mess

[Wayne Workman]

@fry_p said in Windows FOG storage node and multicasting mess:

I’m not so excited spinning up Hyper-V on each server 1 - due to licensing and 2- having 10+ separate virtual environments.

What licensing? Ubuntu and CentOS 7 are free. You don’t use any licenses when you have Linux VMs in Hyper-V. Look it up. One physical Windows installation allows for 2 free Windows VMs in Hyper-V on that physical box. You may install 50,000 Linux VMs in Hyper-V without using any licenses for anything.

All 14 of our storage nodes here run in Hyper-V on 14 different machines in 14 different buildings. Dedicating more hardware when you already have everything you need without additional hardware wouldn’t be my choice. Not to mention the huge safety net you get with snapshotting a VM.

[jdeguerto]

@Wayne-Workman so true and probably better aproach.

[fry_p]

@Wayne-Workman I was mistaken, I know Microsoft is usually a stickler for licensing, so I assumed the worst. That takes out one of the arguments I had. The other I am reconsidering due to the snapshot feature I didn’t think of. The only concern is space now. Each server is also the file server for each building. Can I selectively choose which images get replicated to other nodes? We have a vital few that would be necessary everywhere, but many superfluous specialized images not needed anywhere else. If you can answer that, I have a convincing case for my colleagues, plus I’d be sold on it.

[Wayne Workman]

@fry_p said in Windows FOG storage node and multicasting mess:

Can I selectively choose which images get replicated to other nodes?

Yes.

The way to do it is - you make a storage group for every storage node you have, and then assign one storage node to each of the groups. The group names in this scenario would be best if named something relevant to the location they will serve. Ours are named after the building abbreviations here. I think our storage group names even match our storage node names - but that doesn’t matter, It’s just how we kept it simple.

You’d also optionally setup the location plugin as well so that imaging across the WAN stops.

Then, you’d simply click the particular image you want to work with, click Storage Group, and then add the groups you want it shared with.

Keep the main server marked as primary in this area, Primary is indicated by the big green checkbox.

Exact same concept for snapins.

This is how ours is setup at work.

[fry_p]

@george1421 said in Windows FOG storage node and multicasting mess:

In a typical FOG image deployment the FOG server just moves files, there are no heavy cpu requirements for the FOG server. I was going to recommend a Intel NUC i3 or i5 for this setup. That coupled with a 250GB SSD would make a very nice deployment server.

Here is the compromise my colleagues have come up with. We will put it to the test with a 990. If we see big benefits, we will do as @george1421 does and have a mobile node when we have mass imaging to do. They are not keen on hyper-v still and we don’t do enough mass deployment to justify having a machine in each building (they would just sit there most of the time). We just don’t do that enough to invest time and complicate the process I am being told.

I would now like to know @george1421 's method to changing the IP easily on the node for portability. I am ignorant to how nodes work and how hard it is to change the IP, so I am open to suggestions. Thanks guys!

[Wayne Workman]

@fry_p You’d use the FOGUpdateIP script. It not only automatically reconfigures FOG with whatever IP that DHCP gives it, but it also automatically configures dnsmasq - so that no changes are necessary to DHCP in said location that you power it up in.
https://github.com/wayneworkman/FOGUpdateIP

And of course an Optiplex 990 is more than you need, it would do fine. I’ve successfully ran fog on an old tower with an IDE hdd in it with a Pentium 4 processor and 256MB of slow-as-getout RAM. It’s slower yeah but it still gave about half the speed performance with a single deployment that our awesome servers at work give for a single deployment. That’s mostly due to compression, gig network card, and the write speed limitations of the target host’s hdd.

You would likely get full performance for most things with an Optiplex 990. Remember FOG’s biggest bottleneck is the write-speeds of the target host’s hdd - most just can’t keep up.

[fry_p]

@Wayne-Workman I am now trying to replicate and I am unable to see anything on my newly set up node. When I go to look at the graph and click on it, it displays “A valid database connection could not be made”. I made sure to put in the proper sql credentials. I tried a fresh install but I think the problem is the management password in the node section of the GUI. I don’t know what that is supposed to be.

[Wayne Workman]

@fry_p The FOGUpdateIP project is designed for a full-blown FOG Server that is intended to be carried around from location to location, not for storage nodes.

[fry_p]

@Wayne-Workman Oh ok. Dang. Going back to the node, what shall I do to remedy the replication issue? I currently do not have FOGUpdateIP installed anyway. The weird thing is that Snapins are replicating fine… but no images

EDIT: New error

[10-20-16 10:00:06 am] * Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 462, Message: ftp_login(): Login incorrect., Host: 10.1.34.84, Username: fog

I think it goes back to not knowing which credentials to enter

[fry_p]

So I figured out the replication issue (not all of my passwords matched). The database issue is still there (can’t see graph or any info on it). My next question is how the node gets integrated into the system. How does a PC know to pull from that node instead of the Main Server? I am failing to understand that.

So if I have a node in a building and my main fog server at the main site, the pc looks at the main server for “instructions” because DHCP tells it to look at it during netboot. I don’t see anywhere I can specify where it should pull from. It is quite possible this intelligence built in and I’m just an idiot.

[george1421]

@fry_p The missing bit if info you need is to install the location plugin on the root / master node. Then you can associate storage nodes to location and also workstations to location that way the workstation knows who it should talk to for imaging.

[fry_p]

@george1421 I just found that deep in the forums as you posted this. I had no idea this was a thing, but it is really cool! So the last piece is my database connection. I think it may be a permissions thing. I can log into my FOG database locally on the master server with a blank password. However, on the node, I unable to connect with the same credentials. I already commented out the “Bind-Address = 127.0.0.1” in /etc/mysql/my.conf

It’s probably a stupid thing but I’m stumped.

[george1421]

@fry_p If you are using ubuntu you need to do something (sorry rhel guy) to enable remote access to the database. I know Tom posted something just recently for another forum user. Let me see if I can find it.

[fry_p]

@george1421 Again, just as you posted this, I found it in the wiki. I can now access the database from the node, I hope the graph in the GUI is soon to follow…

[george1421]

@fry_p Sorry I’m running just a little slow today.

Glad you have it worked out. The remote storage node doesn’t have its own database, it uses the Master Node’s database that is why it need remote access to the database.

[fry_p]

@george1421 I appreciate your help though. I’ll give the GUI time to catch up, or if it still doesn’t work, make another post. Thanks everyone!

[Wayne Workman]

@fry_p said in Windows FOG storage node and multicasting mess:

I’ll give the GUI time to catch up, or if it still doesn’t work, make another post.

If it’s configured correctly, it should be immediate. Did you enable the graph for the storage node? Did you assign the storage node to the correct storage group and enable it? When installing the storage node, did you input the correct fogstorage password?

[Wayne Workman]

@fry_p said in Windows FOG storage node and multicasting mess:

I would now like to know @george1421 's method to changing the IP easily on the node for portability. I am ignorant to how nodes work and how hard it is to change the IP, so I am open to suggestions.

back to this question, You’ll be relieved to know that changing a storage node’s IP configuration is very easy.

Edit /opt/fog/.fogsettings and look for the ipaddress= field and put your new IP in it’s quotes. Then just re-run the fog installer on that storage node. This will also ensure you have the latest kernel and inits and required packages on this server too because you’re running the installer.

Then in the main server’s web interface, go to Storage Management and find the storage node you need to change the IP for, and just change it’s address in there. Be weary of your browser’s auto-fill in this area, it will change the password in this area without you knowing.

[fry_p]

@Wayne-Workman said in Windows FOG storage node and multicasting mess:

If it’s configured correctly, it should be immediate. Did you enable the graph for the storage node? Did you assign the storage node to the correct storage group and enable it? When installing the storage node, did you input the correct fogstorage password?

God, I’m striking out left and right. I changed the settings in /opt/fog/.fogsettings, but didn’t re-install, expecting the changes to be instant. What a dope I am…

Thanks for the info on changing the IP of the node. That’s not too bad and you’re right, having the latest of everything every time would be good.