Regarding “A Survey of Embedded Linux Packages” (LJ February 2001), thank you, thank you and thank you. I couldn't see the forest because all them damn trees were in the way. Your article really helped shed light on what the names are, who the players are and what the scope of the paradigm is.
Living in Northwestern Pennsylvania, we are kind of out of the Silicon Valley mail loop. I've been on Victor Yodaiken's RTL mailing list for two years and still didn't understand the landscape. Your article really helped.
Thanks for helping us stay current.
—Raymond C. Minich
There is an error in “The Best of Technical Support” in LJ February 2001. “ide-floppy” is not the appropriate module for ATAPI class ZIP drives. ide-floppy works for the original non-ATAPI IDE ZIP drives. The appropriate module is “ide-scsi”. This information may be found in the ZIP drive HOWTO.
This is a very serious difference. From firsthand experience, I know that using ide-floppy on an ATAPI class ZIP drive will seem to work but will invariably cause filesystem damage on the ZIP disk (unless one does read-only operations with it).
One of the examples in Mick Bauer's “101 Uses of SSH, Part II” article (LJ February 2001) gives a misleading impression of security. Listing 6 shows how FTP can be tunneled over ssh port-forwarding. If this were any other protocol (say POP3 or IMAP), things would be fine.
But FTP actually uses two connections, not just one. The primary connection (port 21) is used as a control channel, issuing commands to the server. The secondary channel is set up each time there is data to be transferred on a different and random port, if using passive mode. If you're not using passive mode, the situation gets worse. The server tries to make a connection back to you from port 20. Chances are this will be blocked stone dead by any firewall nearby.
Anyway, the ssh command will only forward the control channel and not the data channel. That is enough to protect your password but not the data that passes between the servers. This is a misleading state of affairs because the connection may well work, even though most of it goes unencrypted!
As far as I know, you cannot use FTP over SSH without implementing special “FTP watcher” routines inside ssh. This is not impossible; practically every NAT device on the market does the equivalent. An alternative might be to use the sftp command from ssh2. However, I'm not sure whether this is included in OpenSSH yet.
You're absolutely correct. While I do think there's some value in encrypting the control channel even if the data channel is not, that was a poor example, especially since I didn't point out that the data channel does in fact go in clear text. But it does work, even without an FTP-watcher: I've been using FTP over SSH in the manner described in my article for a couple of years now. SCP is still the most secure way to transfer files with OpenSSH. SFTP is cool, but only partially supported in OpenSSH (client- or dæmon-only, I can't remember which). But you can use SSH Communications' “official” SSH v.2 for free if you run it on Linux, xBSD, etc., thanks to a new “Free Use for Open Source OSes” clause in its license.
Out of all the articles I've read in LJ over the years, few have had as much impact on me as the one on vim (“That's Vimprovemnt! A BetterVi”, LJ February 2001). I often spend more time in vim than I do sleeping, and thanks to the article, I now have a few more tricks to use. Some of the most glaring features I was not aware of were the third mode (called visual), the command mode grep and split. I learned vanilla vi on Solaris, and there are a lot of features in vim I have obviously not picked up yet. That being the case, have you thought about a monthly feature on editors? Since I imagine a great deal of your readers spend a lot of time in editors such as emacs, vim, pico and the like, perhaps a regular feature is in order.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- General Relativity in Python