Uploaded Images won't move from /dev to /images

[fritoss007]

here are my exports settings :

root@FOG:/images/Sept-Iles_Only/test# cat /etc/exports
/images/Full_Synchro                        *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=1)
/images/Full_Synchro/dev                    *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=2)
/images/Sept-Iles_Only                        *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=3)
/images/Sept-Iles_Only/dev/                    *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=4)
root@FOG:/images/Sept-Iles_Only/test#

root@FOG01:~# cat /etc/exports
/images/Full_Synchro                        *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=1)
/images/FullSynchro/dev                    *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=2)
/images/Fermont_Only                        *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=3)
/images/Fermont_Only/dev                    *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=4)
root@FOG01:~#

root@FOG01:~# cat /etc/exports
/images/Full_Synchro                        *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=1)
/images/Full_Synchro/dev                    *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=2)
/images/Port-Cartier_Only                        *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=3)
/images/Port-Cartier_Only/dev                    *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=4)
root@FOG01:~#

[Wayne Workman]

@fritoss007 Lots of good information here, I understand what you’re trying to do.

1. You probably created all of these sub-directories inside of /images because you realized that you can’t have two nodes on the same machine sharing the same directory and replication still work. This is solved in FOG 1.3.0 Release Candidate, I had a setup like this at my last job where one FOG Server had two storage node definitions on it - each residing in the exact same directory, and each node being a member of a different group. This would greatly simplify your setup. Also, FOG 1.3.0 Release Candidate allows you to simply turn off replication for an image if you like (it’s a checkbox), and also allows for cross-group sharing. So you could in theory have each node in it’s own group and no other, and simply share the images you want shared from the main group to the other groups. So there are more robust ways of approaching what you want to accomplish with replication in FOG 1.3.0 release candidate. You can update all three servers to FOG 1.3.0 Release Candidate by following these instructions: https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

2. The showmount -e command error’d out on the Sept_Iles server. Try running this command on that server by itself and see what happens. It could be that RPC isn’t running.

3. Inside of /etc/exports the fsid= field should start with 0 and count upwards from there, like 0, 1, 2, 3. This is another thing (among thousands of things) that is fixed in FOG 1.3.0 RC. If you upgrade, you’ll not need to customize /etc/exports so it would become a non-issue.

4. I can probably model exactly what you would want and post screenshots of it, this would be pertaining to 1.3.0 RC though.

[Wayne Workman]

Here is how you would probably want to organize your three FOG storage nodes in FOG 1.3.0 Release Candidate. Of course you can deviate and do what you feel is best.

Below, each node is a member of it’s own group, and is the master of that group. Below, I included a picture of what image sharing between groups looks like. Below, I’ve illustrated how one individual image belonging to one of the groups can be shared with the other groups. In this setup, the “Primary Group”, the one marked as primary on the image (big green checkbox) is the node where image captures for that image would go to. From this master storage node, it’s then replicated to any other group it’s shared with to the foreign group’s master node, first. From the masters, as normal, the masters replicate to other members in their group if you should add nodes to any of these groups in the future.

I’ve highlighted areas that will be of interest to you.

\

[fritoss007]

Thanks a lot Wayne for your replies. So from what I can understand I should move to 1.3.0 ? is this version stable enough for a production environnement ?

[Wayne Workman]

@fritoss007 The current 1.3.0 release candidate has less problems than 1.2.0 has. It performs faster. It has support for things you will need support for, like nvme disks, ssd disks, flash disks, Surface Pros, and just new hardware in general. It also supports Win10. All the below stuff I mentioned about replication applies too, and that’s just one area of improvement. Everything is better. Problems with 1.3.0 are getting fewer and fewer with each release candidate I won’t say it’s perfect (it’s not), but I think it’s worth it.

[fritoss007]

Thanks Wayne I’ll think about that migration on christmas vacation…it could be the right time to do it…

any hints on migration to 1.3.0 ?

[Wayne Workman]

@fritoss007 Not really, you’re on Ubuntu 14 which typically has the least problems (for Ubuntu distros). Back up your database first via FOG Configuration -> Configuration Save -> Export.

After the upgrade, the first thing you’ll want to do is straighten out your storage groups and nodes, and then go straighten out your images (what storage groups they belong to, which are primary, etc.). You may want to do some screencaps of what groups the images are currently in.

I posted the link for how to upgrade below in an older post.

[fritoss007]

Thanks Wayne your help is really apreciated…

[Wayne Workman]

@fritoss007 These two articles may assist in helping you understand the new replication features, and the location plugin should you choose to use it.

https://wiki.fogproject.org/wiki/index.php?title=Replication
https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

[fritoss007]

Hi Wayne,

i’ve just finished my migration and everything when smooth ! thanks for your help again…

one last question…how can I mark this post as resolved ?

[Tom Elliott]

@fritoss007 Just ask and we can resolve posts.

[fritoss007]

Wayne resolved it…thanks !

[Tom Elliott]

@fritoss007 No I did, but that doesn’t matter.