Letters

Cloud Computing Basics Article

Thank you very much for the article “Cloud Computing Basics—Platform as a Service (PaaS)” from Mitesh Soni in the February 2014 issue of Linux Journal.

I'm a PhD student, and my work is about security models for PaaS, so this text was very useful reading.


Jose Luis Faria

Ideal Backups with zbackup—Data Integrity?

I very much enjoyed David Barton's article “Ideal Backups with zbackup” in the November 2014 issue.

One of the main concerns I have (which is mentioned in the article) is how to mitigate data corruption to which the deduplicated data store of a zbackup is particularly vulnerable.

The author hints that the filesystem snapshots can be used to help but is not really explicit as to his methods. I was wondering if he would be willing provide some more detail on that point.

I could envision snapshotting the backup volume every once in a while to basically do a “full” backup, but these snapshots would have to be replicated to other machines for it to really be worthwhile. Is this what the author was hinting at, or is there another technique I'm missing here?

Another partial solution, as the author suggests, might be to rsync --ignore-existing (and also maybe -c) the zbackup data store when replicating it offsite. This would prevent a corrupted store from being blindly over written across offsite media. Combined with regular restoration tests, this might be sufficient for some workflows.

Any further insight that I might be missing would be much appreciated.


Chris Wills

Dr Hjkl Feedback

As a Vim fanatic myself, I was excited to see Kyle Rankin's article Dr Hjkl in the December 2014 issue. But I was shocked after reading it. All the command-line shortcuts you listed are actually bash/readline Emacs shortcuts (gasp)! Try adding the following to ~/.inputrc:

set editing-mode vi

Now a lot of your Vim favorites—^, $, w, f and so on—work verbatim! So all the Vim muscle memory you've acquired is directly applicable in Bash.

What's more, .inputrc is actually a config file for the GNU readline library, not Bash. Bash is only one of the many consumers of readline—you'll have the same vi keybindings in gdb, pdb, database shells and may other CLI applications.

The only caveat is that Bash won't show you when you're in insert vs. normal mode like Vim will. I tend to press Esc (or Ctrl-[) when in doubt.

Also, if you happen to be on OS X, be aware that some BSD applications use the editline library instead of readline, so you'll want to echo "bind -v" >> ~/.editrc.

Thanks to you and all the LJ team for all the great articles!


Chris

Regarding find, xargs and Spaces

In Dave Taylor's article “Power Shell History and the find Command” in the December 2014 issue, he wrote: “Next time, I'll talk about the find|xargs command pipe pair and the substantial problem with files and directories that contain spaces.”

There is another, in my view even more severe, problem with typical uses of “find | xargs”. The xargs command (except in the xargs -0 case) parses for matching single and double quotes. So if an incoming filename contains an odd number of such characters, the xargs command will fail.

For example, in an empty test directory, execute the following commands:

touch a 'b"c' d
find . -print | xargs ls -ltd

The result will be the following error and failure with exit by xargs:

xargs: unmatched double quote; by default quotes are \
special to xargs unless you use the -0 option

Both the space issue, and this quote issue, make the typical use of this otherwise quite useful pipe unacceptable in production shell scripts, in my view, and likely present a serious security risk, if a root-enabled script uses “find | xargs” over a portion of the filesystem space in which non-root tasks can create files (almost anywhere).

Sometime ago, I wrote a small wrapper for xargs that has served me well, and that always invokes xargs with the -0 (minus zero, for nul separator) argument, the only safe and reliable form of xargs.

In my view, the initial xargs command-line interface options and design (dating back to at least Western Electric's UNIX System V, January 1983, the oldest UNIX manual I still possess) are irreparably flawed and should never be used in production code. The only safe xargs option, -0, was added later in the history of xargs, and it is not in the System V variant.

You can find a copy of my “x.c” program at pauljackson.us/x.c available under the GPLv2 license. It might be worth recommending to your readers.

The x command compiled from “x.c” is used exactly like xargs, except that the incoming filename stream from find must be newline-separated, the natural find default. Instead of saying

find ... | xargs ...

rather say:

find ... | x ...

So, for example, the test case above that failed using xargs works fine using x.

My x command does still have the same limitations as the underlying xargs command regarding multibyte language locales for filenames, plus the problem with not correctly handling the nul to newline conversion. It is useful only in single-byte ASCII-like locales, so far as I know.


Paul Jackson

Dave Taylor replies: Thanks for your thoughtful note. I am always aware of the lurking horror of weird characters in filenames, but there's a balance because part of what makes the shell a great learning environment for scripting and programming is that it's simple and straightforward. Many shell scripts could be more robust and bulletproof if written as C programs or Perl scripts, and in some instances, that's critical. In other instances, however, simplicity and an understanding of how Linux works, and the UNIX underpinnings, is more important.

And really, how often do you find filenames in your Linux system that have a single or double quote as part of the filename?

Paul Jackson replies: I have lots of such filenames on my Linux disks, as they include some Windows filesystems, which run inside VirtualBox emulators.

But the more important fact is that xargs in any form, except the xargs -0 form (minus zero, for nul-separated) is dangerous in any root-enabled script, if fed paths from a find command over any portion of a filesystem that non-root processes can write, as they can construct, deliberately, filenames that will be incorrectly parsed by xargs.

Readers' Choice Awards Request

As I read through the Readers' Choice Awards 2014 (in the December 2014 issue), I was looking for and hoping to see a category for best IDE, since many, or most readers probably also are programmers. Would you consider Best IDE as a category in the future?


Joe Farkas

Absolutely. In our attempt to streamline the categories, “Best IDE” ended up on the cutting-room floor. If it's something folks still are interested in, we can certainly add it back next year. Thanks for the feedback, and if you think there are other categories we should be including, please send e-mail to info@linuxjournal.com.—Shawn Powers

Linux Journal App on Kindle Fire HDX 8.9" Tablet

I found how to increase the text size of the articles in the Linux Journal app on my Kindle Fire HDX 8.9" tablet, but how can I increase the text size of the table of contents?


Mike

I don't actually have a Kindle Fire, but if the font size doesn't increase on the table of contents using the same method to increase the font size elsewhere, maybe it's not supported in the device. I think it would be worth contacting Amazon's tech support to find out.—Shawn Powers

Index to Past Articles?

Your back issues contain a vast wealth of information, much of which is still relevant. Do you ever publish an index to past articles?


John

The annual DVD (see lj.mybigcommerce.com/linux-journal-archive-dvd-1994-2014) contains every issue ever published, and as such is fairly popular for that very reason. It's a convenient way to read the archived information as well, since looking at back issues isn't quite the same as browsing through a new one.—Shawn Powers