Create the concept of a ForeignMasterStorage (deployment) node

[Wayne Workman]

@george1421 said:

While its clear that the current FOG trunk can do this, but right now the how is missing from this discussion.

For the sneaker net or for the setup you illustrated below?

[Tom Elliott]

The how is to enable the Location Plugin. (in the case of having fog automate the stuff for you)

[george1421]

At the risk of extending this feature request even more…

Please understand I’m not trying to be difficult, I truly want to understand if what I want to do is possible. I think we have a communication misalignment. I’m not doing a very good job explaining the situation because I keep seeing the same results (maybe that is the only answer, I don’t know).

But I’m assuming from your context that in my drawing below there is one full deployment server in that network with the rest storage nodes. Is that a correct assumption?

I understand the function of the location plugin, It allows you to assign storage groups and storage devices to a location and then you link a hosts to a location so it knows where to get and put (if necessary) an image to. I get that. I’ve been using FOG for quite a while.

The issue(s) I’m seeing here are this:

1. The storage nodes are not a fully functional deployment server. They are missing the tftpboot directory. While they do have the pxe boot kernel and file system, they alone can not provide pxe booting services for a remote site.
2. The storage nodes do not appear to have a sql server instance running so I assume they are reaching out to the master node’s database for each transaction. Historically I’ve seen this being an issue with other products as they try to reach across WAN links for transactional data.
3. There is no local web interface on the storage nodes. So all deployment techs from every site must interface with the HQ Master node. This shouldn’t be an issue since the web interface is very lite as apposed to some other flash or silverlight base management consoles.
4. While this is not a technical issue, its more of a people issue. Since you will have techs from every site interfaces with a single management node its possible for one tech to mistakenly deploy (i.e. mess up) hosts at another site since there is no built in (location awareness) in regards to their user accounts.
5. On the deployed hosts, where does the fog service connect to? Is it the local storage node or the Master node?
6. Storage nodes can only replicate with the master node. i.e. if there are two storage notes at a remote site, one storage node can not get its image files from the other storage node at that site. All images must be pulled across the WAN for each storage node.
7. Multicasting is only functional from the Master node. So in the diagram below only the HQ could use multicasting to build its clients. (edit: added based on a current unrelated thread)

The fog system is very versatile and you guys have put a LOT of effort into it since the 0.3x days. And you should be acknowledged for your efforts. Understand I’m not knocking the system that has been created or your time spent on the project.

I worked through this post, I can see that having a single master node with the rest storage nodes would work if:

1. The /tftpboot directory was included in the replication files from the master node and the tftp service setup in xinet. (actually this could be built in as part of a storage node deployment by default, by having the service and tftpboot folder setup, even if it isn’t used in every deployment. There is no down side IMO)
2. The user profile was location aware to keep them from making changes to hosts in other locations. The location awareness must have the ability to assign users who have global access for administration purposes.
3. The storage nodes would have to be aware of latency issues with slow WAN links. And/or not break completely with momentary WAN outages.

[semipro1337]

Tom, I was linked to this thread by the OP and I am in the exact same position. Wayne is 100% correct in what I need and I believe that to be what George1421 needs too.

Lets break it down simply.

1. Create image on “Master” server.
2. Replicate image to all other storage nodes in the same group.
3. Update the remote servers DB to reflect what the “Master” server just copied.

Steps 1 and 2 work fine but there doesnt appear to be a way to do step 3 automatically. This would not be such a major issue if I were able to manually create the image definition at each site, but when I try I am presented with nothing but a white screen saying “add image definition” on the top left and absolutely nothing more on the screen.

I dont want to export/import mysql DB files from the “Master” to the remote sites, I have been doing that for years with .32 and its not a very good practice. Simply updating the remote mysql tables to reflect the images that were just copied should not be a huge task for your software to perform.

Does that explain what I am and also I believe George1421 to be looking for?

[george1421]

I can tell you through testing I know this so far.

1. You can do this mostly with a storage node and the location plugin.
2. The storage nodes don’t have the bits required for tftp to work

Some caveats to what I just said.

1. The storage nodes are storage nodes only. You can add the tftp service description for xinetd and the tftp files. But the storage node is not a fully deployment node. There is no user interface, all of the techs must access the master node to deploy images to the remote locations.
2. The storage nodes do not have a local mysql database (as far as I can see). They connect back to the master deployment node to access its database. I see this as being an issue with latency when crossing a WAN link.

I have been thinking of ways to map this out to do what ( I ) need it to do, but it would be one off and fragile at best. The best solution is to have this done natively within the program and not use any external hacks.

[Wayne Workman]

@george1421 said:

The best solution is to have this done natively within the program and not use any external hacks.

Linux is the largest collection of hacks in any one spot ever lol.

So,

I’m strongly against the @Developers making such drastic code-base changes. I want to see a 1.3.0 release soon and this will not only delay the release, but most likely create a slew of bugs that need worked out… again… But they can do as they please.

The new FOG Client that is being developed by @Jbob runs on GUI or CLI only linux, just about every single distribution you can think of. It is able to deploy snapins to linux without issue, I’ve witnessed it (his nightly builds, they are not stable or in FOG Trunk currently).

I would suggest we pool our knowledge to just create some base-level scripts that will sync two DBs based on the exact same rules that the FOGImageReplicator follows. I’ve outlined these rules before in other threads.

Once the script is developed, we can make it into a sourceforge project. People can deploy the script via Snapins to the remote storage nodes themselves to update the DBs using the web interface.

[george1421]

@Wayne-Workman said:

I would suggest we pool our knowledge to just create some base-level scripts that will sync two DBs based on the exact same rules that the FOGImageReplicator follows. I’ve outlined these rules before in other threads.

I’m not thinking anything drastic. Its more like how pfsense sends http calls to a remote node to sync its configuration data. While its a bit deeper discussion that we should do here. The idea would be for the FOGReplicator to move the files as they do today. When all of the files in the current image directory have been moved, then make a http call to a php page the remote node (it should already know everything it needs to know to do this [i.e. no new database fields]) which adds the image information to the remote database.