Eduardo Arcusa Les' article “The Power of Tiny initrd” in the
March 2016 issue was an eye-opener for me. Everything is
in the article, with real-world examples, line-by-line configurations and
beautiful graphs. We need more articles like this. I was really entertained
to read it as someone hoping to be a Linux sysadmin in future.
—
Zongren
Eduardo Arcusa Les replies: I really appreciate your words. This was my first article, and it was done with much affection and effort. That was exactly what I wanted, real examples to show people how powerful Linux is and what may be done with it. If you have had so much fun reading it as I have enjoyed writing it, you surely will be a good sysadmin in the future. And things will be even better if you have people around you that encourage and inspire you, which is how it was for me.
Eduardo Arcusa Les' featured article titled “The Power of Tiny initrd” in the March 2016 issue was one heck of an article! He just did what I've been searching for the past several years! I mean, a server running from a RAM—that's fudging shirt!
Although he has explained his adventure in some detail, I (and I suppose many others too!) would like to know more in-depth details, such as how did he create an initrd and how to put those “changing” files outside initrd, but link them to initrd? Perhaps the author can write a blog post with the details?
Thanks for the article!
—
Ron
Eduardo Arcusa Les replies: Thanks, Ron, for your words. The truth is that it's amazing to see a server running completely in RAM, and I hope that my article has helped you in your progress to achieve it.
I didn't explain how create an initrd, but there are a lot of how-tos on the Internet to accomplish that. All you need is to create a very simple initrd to start a server with PXE and save it as base-initrd. When you need to create a new server, make a copy of the base-initrd and put only files that almost never need to be changed (for example, binaries of services or libraries that those services need).
How to put those “changing” files outside the initrd but link them to initrd is explained in the article. Those files, like configuration files of the services, need to be on another server to be edited easily without changing the whole initrd. Then when the server boots, it executes /etc/rc to copy those files with sshfs before the services start. The /etc/rc script is within the initrd; you need to edit it to copy those files that are prone to change.
I hope this helps.
I suppose it is fun for everyone to complain about utilities, and I am no different. Last winter, I discovered that about half of my trailer's outlets stopped working one brutally cold 50°F morning. (This is Florida, so we are all wimps about cold weather and have some combination of poor insulation and shitty electric heat, even the fools who bought new houses in the real-estate boom.)
The previous summer, I'd had a few brown-outages that magically seemed to heal themselves by August, so I'd forgotten all about it.
Having run extension cords to all the working outlets to keep my servers
and Raspberry Pi appliances running, I called the local electricity co-op
to ask for some help. Before I could finish a damn good cup of coffee,
there was a lineman out there poking around at the pole. He said one of the
“hot” (120V AC) wire connections was corroded and had fallen off and then
arc-welded itself back on a couple times. (I think there are two hots with
a 180-degree phase difference so you can easily make “big
appliance” 240V
AC voltage by connecting across both hots.) I had a sinking feeling he was
telling me this because he was not going to fix the problem, and I would be
stuck dealing with a handyman—or worse, a licensed contractor. However,
he got to the point, and I was pleasantly surprised: even though the
utility's policy was not to work on anything on the client-side of the
meter, it was such an easy fix that he would do it on the spot. After about
15 minutes of polishing with a wire brush, he put some conducting goop on
the wire, tightened a nut and reconnected at the pole. For the record, he
recommended I upgrade the meter, but said that there was probably no rush.
That was two years ago. I won't go into specifics, but I would like to
emphasize that this was not Duke Energy.
—
Mike "Mighty Bush" Grossman
Shawn Powers replies: Mike, I think maybe you should contact the company and tell them you'll sell the secret to “self-welding” electrical panels. Once they pay you, just spritz some salt water on the connections and tell them all they have to do is wait! (Only kidding of course, I'm glad the guy fixed it for you. I think sometimes professionals take for granted how “simple” something is for them compared to the rest of us!)
I just want to drop you a quick note about the new format. I've
been a longtime Linux Journal reader, and I have to say that's the
greatest thing since the days when you printed the magazine on paper.
Reads so much better on a tablet.
—
David
Shawn Powers replies: David, that's great to hear! I like it better too. I think we all liked the paper magazine so much, it was hard to think about what would be better than looking “how it always looked before”. It's great to hear that the new format looks better for more than just me.
I just read Kyle Rankin's article on Qubes in April's Linux Journal. I am happy to see this system get “airtime” and some explanation. I know I needed it.
When I first began to read about Qubes, I admit I was a little overwhelmed. But seeing this now, and with expectation awaiting the next articles in the series, I will probably install it on something in the near future.
So, thank you Kyle and editors.
—
Jesse
In a letter published in the April 2016 issue, Wally Olson observed that the cal command prints some “space” “underbar” “backspace” sequences around the current date. (It actually prints terminal-specific escape sequences if its output goes to a terminal; the backspace sequence is used when printing to a file or pipe.)
The point of this is to cause the current date to be highlighted.
With the Debian/Ubuntu version of the cal command (provided by the bsdmainutils package), you can turn this off with cal -h.
The version used on Red Hat behaves differently. When output is sent to a file or pipe, it doesn't do any highlighting at all.
Incidentally, there's also a difference in trailing blanks, which you
can see by typing cal | cat -A.
—
Keith Thompson
In a letter published in the March 2016 issue, Mischa Salle wrote:
strcat, strcpy, sprintf and the like are dangerous and should be avoided unless in completely straightforward cases. The standard replacements for these are strncat, strncpy and snprintf, which are all three POSIX.
A minor detail: all those functions are defined by the ISO C standard, not just by POSIX.
The strncpy function is not a “safer” version of strcpy. If the destination array is too small to hold the source string, the target is not null-terminated, meaning that any subsequent attempt to treat it as a string will cause undefined behavior.
There are rare cases where strncpy is the right solution. Replacing strcpy is not one of those cases.
I've written about strncpy here: the-flat-trantor-society.blogspot.com/2012/03/no-strncpy-is-not-safer-strcpy.html.
Furthermore, replacing the relatively unsafe unbounded string functions by bounded versions without very careful thought doesn't really solve anything. They can avoid overflowing the target array, but only by truncating the data. A contrived example: if the string sudo rm -rf /tmp/unimportant_directory is quietly truncated to, say, 13 characters, the result is sudo rm -rf /, and the consequences are likely to be worse than any buffer overflow.
You need to test whether the target array is big enough to hold the
data you want to store in it and then decide specifically what to
do if it isn't. Simple truncation is rarely the best response.
—
Keith Thompson