First and foremost, I am an undergraduate IT student. I have been PLAYING with Linux for over 13 years, but as far as professional experience goes, I've got nearly none. Therefore, your greater body of professional experience may suggest that my approaches are redundant and unnecessary. That said, if you're JUST looking for a list of certifications, this is the order of things I would do, if I were starting over, and if school wasn't pushing me to take them in a different order. This list is based on what I've seen in job announcements, and what I've seen in competing applicant's resumes. It's probably highly redundant, and the FULL list isn't necessary... But going through the steps will introduce you to important concepts in easy-to-digest pieces, that build on each other in a meaningful way.
First... Get CompTIA A+, Network+, and Security+. Get the latest versions, as the versions I took over the last 2 years are DEFINITELY more vendor agnostic (Read: Less Microsoft-centric) than the versions I took a decade ago. I'm sure you already know a bunch of that stuff, and VERY LITTLE of it will be directly related to Linux... But that should mean they are easy to pass, and the benefit is that they give a strong foundation that many other certifications like to build on. Furthermore, many higher level certifications (Including those from both Microsoft and Red Hat) like to "Recommend" these three before continuing. Finally, from jobs I've seen, most any IT job will want to see that stack, regardless of specialization. Then get CompTIA's Linux+ certification. I have the strong understanding that this exam is very nearly identical to the LSIC-1 certification listed below, but employers (Especially those with hiring managers NOT in the IT department) REALLY seem to like seeing the full stack of CompTIA certifications. Then I'd get the full Linux Server Certification series from the Linux Professionals Institute. LSIC-1 is PROBABLY identical to the Linux+ certification above, so studying the two side-by-side is probably a good approach. From what I've seen in the job market, these are largely unknown by employers... But Red Hat puts a big emphasis on that series covering the required background for IT Professionals transitioning to Red Hat. Let me clarify that: Red Hat doesn't REQUIRE LSIC certification, but they recommend it as a foundation to build upon. It should be further noted that I have NOT personally done that series... But my background is in Linux, so I felt that my money was better spent elsewhere. Then I'd get Red Hat Certified System Administrator. It should be noted that I skipped nearly everything above and went straight to RHCSA... But have since decided that employers require too much of the above, and have started to fill in the gaps. Then the Linux Foundation's Linux Foundation Certified SysAdmin and Linux Foundation Certified System Engineer. In my experience, employers looking for this will accept RHCSA and RHCE as replacements, but the LF versions should be less distro specific. Then finally, I'd round it all out with Red Hat Certified System Engineer. This will require you to do a Red Hat "Specialization," and some of those involve scripting. And that brings us back to the issue of HOW to get good at scripting... And I understand and agree with the difficulty with coming up with scripting projects, when the more basic concepts found in common guides feel boring or below you. What I'd recommend is a different approach... Instead of following a scripting book directly, instead read the books for the certifications above, and actually do the labs in the books... For each lab, write a blog post. And for each blog post, write a script that does what you did in that post. Each lesson, go figure out how to make that script do something the previous one didn't; As an example, instead of passing options from the command line, have it prompt the user for input. Start using functions instead of procedural logic flows. Use inputs to make logic flow decisions. Once you are bored with that, figure out how to do dialog boxes in the shell (That one is SUPER COOL in my opinion... Almost no one puts that touch on their scripts, so it distinguishes your scripts from other developers). Hell, I'd do all of that in BASH/Perl for the first few months, then go back and REDO all of them in Python... As you port it over to Python, you will use more functions, and then start working with objects, then start using third party libraries to aid in speeding up development. All of this will also allow you to revisit SysAdmin lessons, and lead to discovering more efficient processes for things. Doing this does three things: 1) You learn the thing by presenting it to your blog's "Readers;" 2) You reinforce understanding by scripting it; As you work out bugs, it will help you better understand the intricacies of the process you wrote about; and 3) It gives potential employers an example of the kind of code you are capable of writing. It's like a self writing resume... It's both educational AND valuable. As an afterthought on this concept... I put "Readers" in quotes because I don't actually expect anyone to read my blog... Dropping that expectation on myself allows me to NOT worry about things like Collegiate Quality Writing, or even target audience skill levels... I just write it well enough to teach it to myself if and when I ever need it again. Maybe someone will find it interesting, but the honest truth is that it's probably MOST valuable to myself: IN a year, or 5, when I have to do something REALLY uncommon, but something I did once for a lab, then I have my own blog full of notes and scripts on how to do it. It doesn't matter if ANYONE reads my blog... If I can use even ONE script I write now down the road somewhere, then my domain name and hosting has paid for itself ;) ALL OF THAT and your existing Networking experience... And I can guarantee that you will be more qualified for the positions I'm currently applying for than I currently am, and that should feel good ;) Good luck! Tyrell Jentink http://tyrell.jentink.net On Sat, Aug 27, 2016 at 1:09 PM, Marvin Kosmal <[email protected]> wrote: > A huge part of the picture is that a Sr. Level Sys Admin doesn't need > help.. > > > Sr. Level Sys Admin is what you work your position into.. > > My Experience. > > Marvin > > > On Sat, Aug 27, 2016 at 12:54 PM, Mike C. <[email protected]> wrote: > > > > > > > Louis - Thank you for your reply. > > > > > > Your responses compel me to be a bit more clear about some things. > > > > "10) at some point, you will have to get into networking...." > > > > -- I've over 10 yrs of work experience as a Network Engineer, in which > I've > > worked with Unix on Network Management platforms and I've used Linux > > Networking tools for network troubleshooting. I've even built Linux test > > boxes and run LAN / WAN networks through those text boxes to do network > > traffic analysis. > > > > I'm doing a lot of what you said, but learning scripting languages even > as > > a former Comp. Sci. major is kind of dry and uninteresting when there's > not > > a problem to solve or project deadline to meet. Not too event mention > that > > there are drums waiting to be played, bikes waiting to be ridden and > > Network Engineer jobs a plenty. > > > > I guess what I'm having difficulty with is that to me there doesn't seem > to > > be a clear and well defined development path. > > > > For example, when I got into Network Engineering. I started out by taking > > the TCP/IP exam of the MCSE than I self-studied for Cisco Certified > Network > > Administrator and got my first job as a Network Engineer without any > > hands-on real world experience. > > > > >From there, I was able have access to training, lab time, certifications > > and projects that took me from a rank novice to a seasoned veteran in > just > > a few short years. > > > > So what I've experienced over the years is a floundering at Jr. Linux Sys > > Admin level as there's only so much I've been able to do on my own and > > there doesn't seem to be many job opportunities for a Jr. Linux Sys Admin > > to work under a Sr. Level Sys Admin and get good hands-on experience and > > mentoring. > > > > I realize it's my own personal struggle and everyone has walked their own > > path to Linux Sys Admin greatness. The path seems a lot lot harder for to > > my find than for a Network Engineer. The trail heads aren't very well > > marked and the trails not very well mapped out. > > > > Cheers, > > > > Mike > > _______________________________________________ > > PLUG mailing list > > [email protected] > > http://lists.pdxlinux.org/mailman/listinfo/plug > > > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
