The Lessons Hardest Learned
A short time ago, I was on my favorite IRC channel when a friend of mine (we'll call him Joe) asked me to help him install Java and Flash on his system. We had worked through a few Linux problems before, and I was willing to help.
Together, we got Java enabled. I then helped him get Flash downloaded, and we began the instructions to untar and install Flash. Right about then, someone else popped into the channel and began to help us out as well. This new participant (let's call him Frank) was a person I have long recognized as having far more Linux skills than I, so his advice was welcomed.
A few commands into the session, our guru, Frank, typed out this command: passwd -l root. This was meant, of course, to be a joke.
Joe dutifully typed in the command and echoed back a very chilling word in IRC, success. At the time, Frank and I both assumed that Joe was returning the kidding, and we thought nothing else about it.
The horror of this fiasco sank in about 20 minutes later when we asked Joe to su so he could copy a file. He told us that his system would not accept root's password, so Frank led Joe through a series of commands to ascertain some information about Joe's system. Evidently, Joe had set up his user account with root privileges. A while later I wandered off, unable to contribute any further to the recovery efforts.
There is a three-fold purpose to this story. For newcomers to Linux, some cardinal rules should be elaborated upon. For the experts of the world, a few nuggets of wisdom can be gleaned here as well. First of all, root and user accounts should be kept separate for a reason. Root is all powerful and is meant to be used in certain situations only. Had Joe's user account not been root privileged, the passwd command would have failed and this would be just another funny story. Root can do anything it wants to your system, and if you aren't sure exactly what the results of your actions will be, then neither root nor you should be doing those actions.
My experience has been that Windows power-users have the hardest time overcoming the belief that their user account should be able to do anything it wants. After all, to run Windows, you need that kind of access, right? Please avoid the temptation to elevate your user account's privileges. I personally learned this the hard way. I had a root-level user account on my first install. I had to reinstall Linux after doing a chmod -R 777 accidently while in the / directory.
The second purpose of this story is to reinforce that no matter how well you know someone, no matter how much you trust your resource--whatever or whomever that may be--never simply do as your told. Take the opportunity to learn more about Linux by checking the man pages on the commands you are given. Make doubly sure to research each of the options in that command. I'm sure Joe would have questioned Frank more closely after a quick passwd --help. Often, command --help displays a summary of the command and its options, and issuing the command man command typically yields even more information.
Finally, never make the mistake of assuming that the person you are helping has a certain level of knowledge. Frank was innocently playing around and inadvertently caused harm to Joe's system. I, too, assumed that Joe knew better. I was equally culpable (and if you read this, Joe, I am very sorry about this), in that I didn't call attention to the joke. True, Joe had been using Linux for some time now, but Frank and I should not have been messing around like that. We were there to help and, instead, had the opposite effect.
Always take the time to explain what the commands you are giving out should do. Similarly, encourage the new Linux user to check the man pages and make sure they know what the expected output should be. Always strive to help; after all, we're a community.
Now that I've finished relating this tale, I'm going to go off and find out what happened to Joe's system. And apologize.
Epilogue: Frank called Joe on the telephone and helped Joe manually edit the root password back to what it was. System saved!
Special thanks to Joe and Frank for allowing me to relate this tale.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Reply to comment | Linux Journal
1 hour 4 min ago
- Reply to comment | Linux Journal
5 hours 4 min ago
- Yeah, user namespaces are
6 hours 20 min ago
- Cari Uang
9 hours 51 min ago
- user namespaces
12 hours 45 min ago
13 hours 11 min ago
- One advantage with VMs
15 hours 39 min ago
- about info
16 hours 12 min ago
16 hours 13 min ago
16 hours 14 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?