lumbercis wrote: » Hi all, I have an entire book dedicated to it (O'Reilly's "Sed&Awk") but I don't want to spend too much time becoming a sed and awk guru if the exam will only expect basic operations.
Forsaken_GA wrote: » Please understand that what I'm about to say isn't meant to be as harsh as it sounds. This is a lousy attitude. You should never be studying to pass an exam, you should be studying to acquire the knowledge. If you only learn enough to pass the exam, and then get into a job where you can't function if more advanced is required, you devalue the certification. This goes for all exams. In particular to working in the unix world, sed and awk will be some of the best friends you have once you start administering live production servers. If you intend to make a career of this, learn them in and out and it will pay off for you down the road. Let me give you some practical, albeit simple examples. awk is extremely useful for formatting log output. In particular, it's always been a favorite of mine to pull open a window, tail an apache log file, awking to display only the result code and the referrer. Then, as I start making access changes, I can immediately see if the expected result code is popping up (ie, if I'm blocking hotlinkers, I can immediately tell if the rule is effective, because the result codes go from 200 to 403) Last week, it was discovered that some fool had added a configuration directive to the wrong file. On about 300 servers. So I whipped up a little script to grep that directive out of the original file, append it to the correct file, then sed the directive out of the original file. Add in a for loop to login to each server and run that script, and it took about 10 minutes to correct. Doing it all by hand would have been a full day thing. And that's really just child's play. sed and awk can basically take any text file and manipulate it in any way you wish. you just have to learn enough to make it so. The side education you get in regex as a course of learning sed and awk is also nothing to sneeze at.
UnixGuy wrote: » I already went deep with some topics such as LVM, RAID...but I don't think I'll go very deep with sed & awk right now.
Forsaken_GA wrote: » Oh, the irony of someone with the handle of Unixguy downplaying the usefulness of sed and awk hehe...
Chris:/* wrote: » @UnixGuy I would not say the RHCE objectives are vague just not specific for the test. They do that because they want people at a certain aptitude to take the test and pass. This also encourages people to take the expensive class.
UnixGuy wrote: » I don't think RHCE objectives are clear enough either, because as the OP said, you can find huge books talking about sed,awk, regex, ...etc...and he is right. It's natural that one would be strong in some areas and weak in some other areas. At the end of the day, it's just a test and a learning experience.
NightShade03 wrote: » It also leaves the exam open to a more free form approach. For example they prob won't tell you to implement Sendmail because it isn't an objective, but they might ask you to implement something that provides SMTP functionality. Makes it easier for those that have experience with different technologies if you ask me.
Chris:/* wrote: » @NightShade03 Absolutely and I believe it is why the certification holds so much respect because of the level of knowledge and adaptability the candidate must have.
Forsaken_GA wrote: » I would never consider letting someone without those basics get anywhere near my production boxes
varelg wrote: » I'd consider this certification only if it's employer- mandated and paid for. Learning experience? Yeah, but so is just reading the RH book given at the RH classes. In that retrospect Microsoft is more open than Red Hat: anyone can buy MS exam guides. Why should RH guide be any different, because it holds the secret spell?
lumbercis wrote: » @Forsaken, I appreciate your insight and agree with you for the most part. But I would bet that if you look back on how YOU became an expert at sed and awk (and sysadmin in general) you will not have (before you even had a job in IT) picked a singular task, studied it exclusively until you had complete command, then moved on the next discrete skill, studied it exclusively until you were an expert....etc. No one becomes an expert like that.
They gather basic skills, then gain most of their actual expertise from using that skill in an appropriate production context to solve real problems. That's all I am suggesting. I certainly never meant to imply that I or anyone should skip sed and awk skills entirely since it wasn't on the test.
Forsaken_GA wrote: » ... I'm of the bent that if something is worth learning, it's worth learning well, so if I encounter something I need to study in the midst of a project, I study it until I'm as much of an expert as I'm going to be. This usually involves a healthy amount of labbing so that I don't make rookie mistakes in production. Trust me, you are not going to gain basic skills as a linux admin, and then all of a sudden rollout a multi-city mysql master-master replication setup over WAN links. You are going to do an awful lot of focused study, and you will hopefully do some lab mock deployments. If you're smart, your studies will include not just how to do it, but how to troubleshoot it and how to fix it when it breaks (because if there is one constant in IT, it is that it *will* break)..
Forsaken_GA wrote: » If you're smart, your studies will include not just how to do it, but how to troubleshoot it and how to fix it when it breaks (because if there is one constant in IT, it is that it *will* break).
Chris:/* wrote: » The best way to learn to troubleshoot Linux is to make it your primary OS. Everything you normally do in Windows or Mac OS you should attempt to do in Linux instead. You will inject problems and break stuff on your own. You can then attempt to trace problems and resolve them. This is why the RHCE exam is so tough because many people believe they can walk in with little practical real world experience and pass it. If you do not use Red Hat, CentOS or Fedora regularly you will not be able to quickly find the answer to a problem on the test.
Bl8ckr0uter wrote: » Studying troubleshooting can be hard though.
Forsaken_GA wrote: » That's why I would encourage folks to break things in their lab in order to learn how to fix them. If you're not a natural troubleshooter, you do not want your first exposure to a problem to be at 3am after you've been woken out of a sound sleep