Adding Storage Node - init.xz issue
-
@gjo Storage nodes are read only copies of the master node. So what is in the /images directory on the storage node should be an exact copy of what is on the master node. There is nothing to read in, because they are only a copy.
So let me ask you what is the beginning of your question. Why do you want to load the image files from /images on the storage node into the web ui? I think you have a deeper question than what you ask.
-
@george1421 True, it is a storage node. It doesn’t have the role to put the image on the WebUI.
Because what I’m trying to do, it’s to divide two groups in my company with different images in the two groups, and the users of one group can only access the images in his group.
There’s no possibility to have the images on my Storage Node, not only in /images/ but in the web interface?
-
@gjo The only way to do what you want is to have two different full fog servers. That way the two groups are isolated with their images.
BUT there is an unsupported configuration that might help you. On the current master node, manually add the second FOG server as a storage node. So this will be for the second group a full FOG server so it has its own database and different image files, but it will be a storage node to the first fog server. This means the fog replicator will copy the images from the master node to the remote fog server as if it was a storage node. The only thing that will not happen is the remote fog server will not know what images are in it’s /images directory. You will either need to copy values from the master fog server and manually add them to the remote fog server, or simply recreate the manual entries on the remote fog server. This way you can have common images between both groups as well as group specific images. You then would control what images are copied over to the remote fog server by the replication checkbox in the image definition on the master FOG server. The FOG replication will only copy over images that have the replication enabled on them.
-
@george1421 I understand where you are coming from but there is no point having two different full fog server.
Probably if you want to do a backup probably yes. But by installing my two storage nodes it has generated two WebUI so I don’t see myself, having a lot of WebUI.
I want to replicate everything but in different storage nodes, if it’s possible? Yes I saw that I can uncheck the replication of a image.
-
@gjo FOG isn’t really designed to split the replication images within a storage group.
Now on your master node, your images are stored in /images directory. You might be able to add another storage master node to the FOG server and create a second storage group, with the storage node. That might work. Let me see if I can work out a path on my dev box to what I’m thinking. We might need the location plugin so everything goes in the right bucket though.
-
@gjo OK lets try this, it should work, but I don’t know the consequences of doing this because I just glued it together.
- Create a new location to store your images (not /images, but like /images2)
- Create a new storage group for the remote site.
- Create a new storage node. Copy all of the settings exactly from the defualt storage node, except the image path, ftp path, and storage group. For the storage group select the storage group you created in step 2.
This will create a partitioned FOG server. Two definitions point back to the same physical server with to storage groups where its the master of each storage group. Now move the remote storage node over to the new storage group you just created, this will be a slave node in this second storage group.
So right now you have 2 storage groups default and newstorage group. Each storage group has a master node with different image paths. Your /images is full of images and your /images2 has nothing. If your remote site has images in /images directory you will need to move the images content over to the /images2 path, then update the image definition in the web ui to tell that the files are now in /images2.
Understand there are more fog support directories that need to be copied over from /image to /images2 like the entire contents of the /images/dev directory as well as any subdirectories in /images directory except for the actual images directory. Also be aware there is a hidden file in both /images and /images/dev that need to be copied over. Also make sure the permissions on /Images2 match /images. There is quite a bit of steps in this part of cloning /images to /images2 directory but it can be done.
Now that you have this complete setup fully programmed. When you want to make an image for the remote site, you simply create the image definition like you always do, but then you select the second storage group to place the files in. The remote storage node will see the files and copy them over.
-
@george1421 Thank you
things are getting more clear by what you are saying.I’m not using Location, I’m currently using Sites. Is it a big issue if I’m working with Location?
-
@george1421 Let me try it! Thank you, I will give you are feedback soon.
-
@gjo said in Adding Storage Node - init.xz issue:
I’m not using Location, I’m currently using Sites. Is it a big issue if I’m working with Location?
I’m not sure if its a language issue here or just terminology.
In the general term location and site are interchangeable.
In the terms of FOG, there is a Location plugin. This plugin is used to assign a storage node (master or slave) to a specific location (department, site, or world). Then when you register new computers with FOG you assign the computers to a location so the computers know how to find the nearest storage node. If you don’t use the location plugin the target computers will use the master node even if its sitting right next to a storage node.
-
@george1421 I can’t explain but it’s working the way I want, I didn’t not do yet what you said I should do.
I just simply but the configuration by default and now it’s working, I’m still observing the behaviour.
-
@george1421 Let me try if it will create a conflict by using Location instead of Sites
