Unable to create an image with multiple vlan/NICs (final copy to /image issue)
-
You likely filled in the wrong credentials for the student storage node. (the fog ftp password at the working storage node by clicking on the reveal password thingy)
It is not the same as the webGUI login. (maybe you know this, but a lot of people get confused by the different credentials being used) It is automatically generated by FOG upon install.
Seeing as you have not modified the credentials of the working node, this seems like the most likely scenario, please check and confirm/deny this.
I am guessing you are on FOG 1.2, in regards to your question about the storage interface options. The image is of the newest version, which is continuously being updated. You can search the wiki for installing trunk if you’re interested in that (many people here use it in production environments).
-
Additional info:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP -
Thanks for the quick reply Quazz.
Actually the credentials I use for the student node are the same as the DefaulMember node created by FOG which works just fine but on the staff network.
The machine I try to upload passed all FTP tests mentioned in the wiki page. Even tried in ‘/images/dev’.I’m not really enthusiastic using trunk version more because of custom (I use Jessie, not testing
). But I will seriously consider this option if I don’t manage it.Thanks again !
-
Thanks Wayne, that’s the page I mentionned in the original post.
It helped me to understand a lot better the mechanics but not to solve my problem, yet. I dive into it again… -
@Erwan I just read through more of your first post.
What you did in this particular scenario is half right. Yes, you should make a secondary storage node on the same server using the same directory - but only a different IP address.
However, you should have put it in the same group as the other storage node. When replication starts, it will see that the files match themselves (lol) and won’t do anything else.
-
@Erwan You mentioned in your post that when you changed only the IP of the teacher node it worked. Does this mean you did not alter the interface?
-
@Wayne-Workman Oh, ok. I’ll try it right now…
@Quazz Each time I specified an IP, I also modified the interface accordingly.
-
@Erwan All of this points to the credentials under your student node being incorrect. Seeing as everything else works exactly as expected and the principle works with the default node, it’s the only option left, really.
Try entering it again manually and see if that resolves it.
-
@Wayne-Workman I tried your solution but with no better result. I may have misunderstood your explanation.
I put the Student Storage Node (StudentIP@/eth1) in the ‘default’ group which already contains a node named ‘DefaultMember’ with StaffIP@/eth0.
I had the first error I encountered (Mounting File System…mount : mounting 172.29.1.40:/images/dev/ on /images failed: connection timed out). It doesn’t take into account the Student Node settings and take the default one. -
@Erwan The /images/dev directory is only used for uploads, uploads always go to the master node, always.
So, you can uncheck the master node checkbox on the one, and check it on the other, then it should work.
Or, you can do your uploads on the vlan that the master node is on.
-
@Quazz I share your doubts.
Unfortunately even after manually changing both credentials, I still have the image in /images/dev not copied to /images.
Before that I went back to the Student Node (with StudentIP@/eth1) into Student Group.Very weird. The weirdest is that I made the manual FTP tests twice from this same client with no issue.
I have to leave now, I’ll try to check logs to find out.
Thanks for your help @Quazz and @Wayne-Workman.
-
No luck with the tests.
I tried changing the credentials to root for testing with the same issue.
No trace in logs.@wayne-workman I didn’t see your post, sorry for not answering until now. I will try your suggestion. But I’m afraid it doesn’t fit our needs. Actually switching the master option from one node to another will, in way, lock FOG imaging on a vlan or another. That could be troubling for users and forbid simultaneous imaging on both vans. Am I wrong ?
In your opinion, could trunk answer this need ?
-
@Erwan It sounds like what you need is two different storage groups, with each node in a different group.
If I understood Tom correctly, the trunk version of FOG can replicate images between different storage groups, allowing image captures in different locations to be replicated to the master node of the other group (which then replicates it to the nodes in its group).
It sounds like that’s what you need for your situation.
-
@Erwan said in Unable to create an image with multiple vlan/NICs (final copy to /image issue):
Actually switching the master option from one node to another will, in way, lock FOG imaging on a vlan or another.
Not so, the master node is simply the one used with uploads, and the one that does any multicasting. Switching it allows uploads from the other vlan, as you were trying to do.
I think you need a storage node per vlan as @Quazz suggested. It’d simplify this. Trunk isn’t the “answer”, but you’d like it and it’s more simple, more robust, higher performing, supports more hardware, etc.
