Op 10-03-11 13:40, Anton Aylward schreef:
My general advice, from over 30 years of networking, is to NOT use FTP.
I've found that HTTP servers are faster, more network friendly, more sysadmin friendly, more firewall friendly and more reliable.
From the client point of view, WGet or CURL are better than an ftp client for similar reasons.
At the very least, WGet or CURL are better than an FTP client.
I'm far from clear from your description why this has to be a virtual machine. That just seems to add another layer of complexity to no clear advantage.
The classic model of a machine that downloads its firmware is old, old, old, and used TFTP not FTP. Today this is the 'net boot' of PXE that is built in to most motherboard BIOSes. The server software for this can be found though http://syslinux.zytor.com/wiki/
Check out PXE Linux, for example.
I've used this in the past to download the code for appliances that don't have their own flash memory. Its very reliable and very flexible.
Please: Avoid FTP. Its a mess, insecure and a pile of trouble. As far as I can make out there are better - easier, more reliable, more flexible, more user friendly, more firewall friendly, more network friendly, more configuration friendly, ways to do what you're trying to achieve.
Thanks for your response. Unfortunately, I don't have anything to say about the server system or the devices, our customer designed the whole system. And they don't have problems, I think it's because they are testing with a single device. As far as I can tell, they get their files with wget. This is a logfile : wget -q -O /tmp/dayzero/packages/manifest ftp://production.promo.com/dayzero/manifest About security : that network has no connection to the outside world. So nothing to worry about. The main reason for the vm : our customers regularly ask for some server, just to test devices. If I have to provide real hardware for every project, I would have a pile of machines that aren't used most of the time. B.T.W. with server I mean a machine that provides services, not server-grade hardware. Out of curiosity : why would a virtual machine add complexity ? Once installed the guest behaves like real hardware, isn't it ? Regards, Koenraad Lelong. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 3/10/2011 10:58 AM, Koenraad Lelong wrote:
Op 10-03-11 13:40, Anton Aylward schreef:
My general advice, from over 30 years of networking, is to NOT use FTP.
I've found that HTTP servers are faster, more network friendly, more sysadmin friendly, more firewall friendly and more reliable.
From the client point of view, WGet or CURL are better than an ftp client for similar reasons.
At the very least, WGet or CURL are better than an FTP client.
I'm far from clear from your description why this has to be a virtual machine. That just seems to add another layer of complexity to no clear advantage.
The classic model of a machine that downloads its firmware is old, old, old, and used TFTP not FTP. Today this is the 'net boot' of PXE that is built in to most motherboard BIOSes. The server software for this can be found though http://syslinux.zytor.com/wiki/
Check out PXE Linux, for example.
I've used this in the past to download the code for appliances that don't have their own flash memory. Its very reliable and very flexible.
Please: Avoid FTP. Its a mess, insecure and a pile of trouble. As far as I can make out there are better - easier, more reliable, more flexible, more user friendly, more firewall friendly, more network friendly, more configuration friendly, ways to do what you're trying to achieve.
Thanks for your response.
Unfortunately, I don't have anything to say about the server system or the devices, our customer designed the whole system. And they don't have problems, I think it's because they are testing with a single device. As far as I can tell, they get their files with wget. This is a logfile : wget -q -O /tmp/dayzero/packages/manifest ftp://production.promo.com/dayzero/manifest
About security : that network has no connection to the outside world. So nothing to worry about.
The main reason for the vm : our customers regularly ask for some server, just to test devices. If I have to provide real hardware for every project, I would have a pile of machines that aren't used most of the time. B.T.W. with server I mean a machine that provides services, not server-grade hardware.
Out of curiosity : why would a virtual machine add complexity ? Once installed the guest behaves like real hardware, isn't it ?
Regards,
Koenraad Lelong.
Of course using a vm adds more variables, a lot more, and is therefore impossible to be anything BUT more prone to unknown problems. That's a built-in immutable fact of logic. More variables == more opportunities for error, or more things that must all be just right in order for the whole to work. The real question is why would you think otherwise? Also you didn't mention which of the dozen or more wildly different types of "vm" you are using. They all have strengths and weaknesses. For one example, that just happens to involve vsftpd, vsftpd has a known issue with it's default configuration when used in a kernel namespace-based container (lxc), because vsftpd itself uses namespaces as a security/isolation technique by default. So if your "vm" happens to be an lxc container, you need to add isolate=NO isolate_network=NO to /etc/vsftpd.conf Except, more variables... as lxc is still developing, they already know that this problem will go away soon because they already know they are changing the thing that causes it, so, depending on the version of lxc and you kernel, If you're reading this later in some mail archive, you may NOT have to worry about this after all. I doubt you are using lxc since it's very new and has hardly any userspace convenience support yet. No nice front end apps to make it easy to create containers and start/stop them etc. But gee there could be literally ANY number of exactly similar compatibility issues with any kind of vm technology. I would still say, based on what you've described so far anyways, that you probably don't need vm's for this level of isolation. You don't need lots of hardware boxes either. vsftp and dhcpd both have a concept of virtual hosts built-in just like apache does, even further since they have built in support for chroot jails. You can have the hosts main dhcpd and vsftpd serve all requests, and yet have it look to the outside as if they were distinct machines with distinct ip addresses and hostnames and their own "root" filesystems as seen from the client side. If the clients need to do more on the host than upload/download files to an ftp account and receive dns and dhcp service, then maybe you need vm's. It may be either more work or less work to maintain such a setup depending on how you work, which I can't speak to. Certainly if you're already doing vm's then it's more work at least briefly just to figure out this other way. After that I'd say it'll be a lot easier to maintain and use and definitely a lot more efficient in terms of host resources. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Brian K. White said the following on 03/10/2011 01:37 PM:
On 3/10/2011 10:58 AM, Koenraad Lelong wrote:
Op 10-03-11 13:40, Anton Aylward schreef:
Koenraad, my reply to you was off-list. Its considered impolite to send replies to private communications back on-list -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday, March 10, 2011 01:30:15 PM Anton Aylward wrote:
Brian K. White said the following on 03/10/2011 01:37 PM:
On 3/10/2011 10:58 AM, Koenraad Lelong wrote:
Op 10-03-11 13:40, Anton Aylward schreef: Koenraad, my reply to you was off-list. Its considered impolite to send replies to private communications back on-list
Private reply on the thread can be threaded with the rest of emails and appear as list mail. It happened to me few times. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (4)
-
Anton Aylward
-
Brian K. White
-
Koenraad Lelong
-
Rajko M.