I figured it out. I am pretty new to linux administration. On the storage server there was an entry in the etc/hosts.deny file that looked like this:
ALL:ALL EXCEPT 127.0.0.1:DENY
Annoyingly there is an entry in the hosts.allow file that allows ssh from anywhere. After commenting out this entry, the ftp connected perfectly from all locations needed. Thank you for your time on this.
The image that you posted of the listed imaged size from Image Management shows 2 sizes. The first being the size of the computers HDD that you are taking the image from. The second is the size of the image in the location listed in the Image Management T440-Master Record that you put up. The problem may be an FTP Issue, here are some steps to troubleshoot that. If after taking an image, there is a folder in the /images/dev/ directory with an image file, it may be a security issue on the server for the fog user.
I have run into an issue where the user account that I used for fog was denied access to login to the server and that prevented it from moving the image once the ftp was complete. I have entries in the file: /security/access.conf:
+ : root,fog : ALL
- : ALL : ALL
Without that entry, the fog user is unable to move the image file to the appropriate spot after imaging.
I am on Trunk 1.5.2 installed on a Debian server. Trying to get a multicast session setup and having an interesting issue. I create the Session for my Windows 7 x64 Image for multicast. I set the session name, client count and timeout and click start. The session shows under Current Sessions for a moment or 2 and then disappears. No active multicasting tasks shown. In the multicast.log it shows the following:
[05-11-18 12:00:39 pm] | Task (10) Batch6 is new!
[05-11-18 12:00:39 pm] | Task (10) /images/Win7x64 image file found.
[05-11-18 12:00:39 pm] | Task (10) Batch6 12 clients found.
[05-11-18 12:00:39 pm] | Task (10) Batch6 sending on base port: 57468.
[05-11-18 12:00:39 pm] | Command: /usr/local/sbin/udp-sender --interface eth0 --min-receivers 12 --max-wait 600 --portbase 57468 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/Win7x64/d1p1.img;/usr/local/sbin/udp-sender --interface eth0 --min-receivers 12 --max-wait 10 --portbase 57468 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/Win7x64/d1p2.img;
[05-11-18 12:00:39 pm] | Task (10) Batch6 has started!
[05-11-18 12:00:39 pm] | Cleaning 1 task as they have been removed
[05-11-18 12:00:39 pm] | Task (10) Batch6 is being cleaned.
[05-11-18 12:00:39 pm] | Task (10) Batch6 has been completed.
No clients imaged since I didn’t have any time to initiate a connection. Any help would be appreciated.
P.S. The multicast Session names appear to not be able to be reused, Is this just for the day or does this function always need a unique session name?
Is this something that is included in Trunk? I am using 1.2.0 and cannot see the storage group for the snapin record like I could see for the images. The snapins were not replicated to the storage node on my network.
The locations plugin documentation is non existant. I see no threads on this forum or any other saying that the location plugin is applying to snapins. The best I found was a thread that said to create a script that would call a file off of a local samba share. This of course would be a pain if we needed to add another location.
Thank you for your help.
I have been searching across the forum and asking moderators to point me in the right direction. Can you tell me how to do it? I don’t see the snapins on the storage node.
I would like to see the location plugin applied to snapins. It is not acceptable for us to transmit the snapin files over the WAN. Thank you for all your hard work.
Hello All,
I am attempting to use the fog locations plugin to make multiple storage nodes on the network image independently of the main node. I have the imaging piece working. The main node passes the images to the storage node. The storage node performs the imaging. This seems to work great. I need to get the snap ins going now. I currently have a number of snap ins that I use, Mostly for drivers, and I cannot have them transferring over the WAN links. What is the prefered method for getting the locations plugin to do the dirty for snap ins too? Move the snapins to /images to let the Image Transfer replicate them? Any input would be of great help. Thank you much.
The image that you posted of the listed imaged size from Image Management shows 2 sizes. The first being the size of the computers HDD that you are taking the image from. The second is the size of the image in the location listed in the Image Management T440-Master Record that you put up. The problem may be an FTP Issue, here are some steps to troubleshoot that. If after taking an image, there is a folder in the /images/dev/ directory with an image file, it may be a security issue on the server for the fog user.
I have run into an issue where the user account that I used for fog was denied access to login to the server and that prevented it from moving the image once the ftp was complete. I have entries in the file: /security/access.conf:
+ : root,fog : ALL
- : ALL : ALL
Without that entry, the fog user is unable to move the image file to the appropriate spot after imaging.
I figured it out. I am pretty new to linux administration. On the storage server there was an entry in the etc/hosts.deny file that looked like this:
ALL:ALL EXCEPT 127.0.0.1:DENY
Annoyingly there is an entry in the hosts.allow file that allows ssh from anywhere. After commenting out this entry, the ftp connected perfectly from all locations needed. Thank you for your time on this.
Sorry for not being concise. I created a Debian testing server on the same sub net. I was able to ping the storage server from the testing server. From the testing server, I attempted to ftp to the storage fog server but failed with the 421 Service not available.
You can FTP into the storage node from the storage node, but can’t FTP in from the main FOG server to the storage node?
That is correct. I can ftp to the localhost but I cannot ftp from outside.
And you said you turned off the firewall, and still get the same results?
I did turn the firewall rules off and tried. No go.
Could you go to the subnet where the storage node is located, and from a computer within that subnet, try to FTP into the storage node?
I created a local Debian Test server, installed lftp, tried to connect, and it still failed.
If you can, this points to a network config issue… which would be really be strange.
If you can not, then I’m doubting that the firewall is really off for the storage node.
I have no ip conflict. This subnet is brand new. The fog server is the first server in there.
I am attempting to create a storage node on another sub net across a wan. The servers are Debian 8. So far the installation seems to have gone well. The storage node install was configured via this article for multiple tftp servers. I also setup the locations plugin to split the sub nets so that the storage node and master have control of its own sub net. I can successfully image a client on the master network. I am having issues with the storage replication. When I check the Replication log on the master I see.
[07-04-15 12:09:27 am] * Starting Image Replication.
[07-04-15 12:09:27 am] * We are group ID: #1
[07-04-15 12:09:27 am] * We have node ID: #1
[07-04-15 12:09:27 am] * Found: 1 other member(s).
[07-04-15 12:09:27 am]
[07-04-15 12:09:27 am] * My root: /images
[07-04-15 12:09:27 am] * Starting Sync.
[07-04-15 12:09:27 am] * Syncing: TMFog
[07-04-15 12:09:58 am] * SubProcess -> mirror: Fatal error: max-retries exceeded
[07-04-15 12:09:58 am] * SubProcess ->
[07-04-15 12:09:58 am] * SubProcess -> Complete
This leads me to believe that the ftp on the storage node is broken. I try and ftp to the storage node and this is what I get:
---- Connecting to 172.16.101.30 (172.16.101.30) port 21
<--- 421 Service not available.
---> FEAT
---- Closing control socket
I can connect via ftp on the local host.
root@TMFog:/etc/init.d# lftp localhost -u fog
Password:
lftp fog@localhost:~> dir
drwxr-xr-x 2 1000 1000 4096 Jul 04 00:00 test
lftp fog@localhost:~>
Really Stumped here.
there is a firewall in the mix but I disabled all the rules and then tried to ftp to the server from the firewall and got the same result. There are not any updates to the /va/log/messages log file for these connections, is it writing them somewhere else? Any suggestions would be appreciated. Thank you.