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
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
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
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.
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
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
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
