Unable to create an image with multiple vlan/NICs (final copy to /image issue)
-
Hello,
After wandering the forum, I’ve seen many posts that look like the problem we are facing but I found no answer yet.
Here is our situation :- we have two vlans hosting two ADs (so with their own DHCP, DNS, etc.) : one for the staff, the other for the students,
- I set up a fog server (VM) with two NICS, one in each of these vlans, so FOG has two IP addresses (staffIP@ on eth0 and studentIP@ on eth1),
- FOG is managed through the staff vlan,
- we want to be able to manage imaging on both IP segments.
FOG 1.2.0 is installed on a Jessie VM.
Naively (and also by curiosity) I tried to upload an image from the staff vlan and an other from the student vlan.
The staff vlan imaging works flawlessly. On the student side, I was happily surprised to see the station managing to boot through pxe (so with the right IP). But that was too nice, and the NFS mount crashed with this message :- Mounting File System…mount : mounting 172.29.1.40:/images/dev/ on /images failed: connection timed out.
Well, that was with no real surprise : 172.29.1.40 is the staffIP@ of the server as 172.22.1.40 is the studentIP@.
So I tried something. I created on the same FOG server a student Storage Node with:
- 172.22.1.40 as IP,
- eth1 as NIC,
- /images as the image path,
- the same user/password as the DefaultMember Storage Node.
I attached it to a Storage group called ‘Student Group’ and then linked the station image to this ‘Student Group’.
Then the imaging seems to go without any problem :
But when I look into /images I cannot see any directory for the image, except in /images/dev where there is a directory which name is the MAC address of eth1 (student NIC on the server). This directory contains ‘d1.mbr’ and ‘d1p1.img’ files, much smaller than the original data size (the data only contains 0).It is as if it couldn’t create the final image in /images.
I also tried to create a new directory structure for the student node under /images (/images/student and /images/student/dev) but with no more success.
The .mntcheck files are created, the /images tree is 777 and the content of /etc/exports is :
/images *(rw,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=1)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=2)(i originally had rw for /images but put ro following the wiki and then put rw back)
Reading https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP, I had the idea to change the IP address in the DefaultMember Storage Node (ie set studentIP@ instead of staffIP@) the image upload works like a charm.
Unfortunately, I don’t want to manually change this IP each time an upload/download is necessary.
About this page, the screenshot (https://wiki.fogproject.org/wiki/index.php?title=File:Storage_Management_Interface_Name.png) has a lot more fields than I can see on my FOG install.Obviously my problem would come from FTP settings, but I can’t figure out which one(s).
Can you help me ?Cheers,
Erwan -
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.
