Topics of Systems Administration
-
@DustinB3403 said in Topics of Systems Administration:
Understanding the role of the LAN - sure it's legacy but still extremely common.
I've not seen any other books add LAN topics to a system admin curriculum. In what way do you feel this should be approached? Other than the obvious and talking about the LAN as a dangerous place and why we need the OS level firewall.
-
Automation tools such as SALT and Ansible.
-
@scottalanmiller said in Topics of Systems Administration:
That handbook is also associated with LISA, that totally out of touch and incompetent (and not to be seen anywhere in the real world) group that claims to oversee systems administration and traditionally defined the scale of administration by the ridiculous concepts of "user account count" and "code compilation".
Like systems such as Amazon or Change.org or Facebook or Google were all "small time, low level" admin shops because they don't create millions of users at the OS level.
Not sure what you mean here. Looking at the programs over the last 10 years (the 4th edition of the book was released in 2010) LISA has been about DevOps principles, containers, security, etc. Is backed by Amazon, Facebook, Netflix, etc and a good number of the speakers are from those companies.
-
@stacksofplates said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
That handbook is also associated with LISA, that totally out of touch and incompetent (and not to be seen anywhere in the real world) group that claims to oversee systems administration and traditionally defined the scale of administration by the ridiculous concepts of "user account count" and "code compilation".
Like systems such as Amazon or Change.org or Facebook or Google were all "small time, low level" admin shops because they don't create millions of users at the OS level.
Not sure what you mean here. Looking at the programs over the last 10 years (the 4th edition of the book was released in 2010) LISA has been about DevOps principles, containers, security, etc. Is backed by Amazon, Facebook, Netflix, etc and a good number of the speakers are from those companies.
Then they've changed their tune, back when I last read it their degree of unprofessional and condescending and out of touch was through the roof and they totally made all of those companies unable to have "qualified admins" be on their staffs because of how they ran systems. A key problem with LISA is that they don't use general principles but rather momentary artifacts to define how systems should be run so that they have the potential to be wildly out of date and out of touch. That's good, I guess, that they are trying to change their tune now. But it feels a bit like CompTIA updating the A+ and trying to act like they know what's going on. LISA burned that bridge with me and seem to be a pariah of non-professionals looking to associate with other entry level people to make what they do look better.
I know I dug into their stuff when I was on Wall St. and no Wall St. firm qualified for anything but the most entry level qualification because of things that made no sense and no one that followed the LISA guidelines would have been employable in any production environment outside of like a tiny SMB where UNIX was just used for printing and such. So while they might have done an about face, it was decades after they were totally irrelevant and honestly, unethical. That's really my biggest concern, it was a completely dishonest organization trying to make a quick buck and I think they did a big to undermine our profession.
-
@scottalanmiller said in Topics of Systems Administration:
If you were writing a book on systems administration, or you wanted to read one, what topics do you feel would be best to cover? This isn't like specific to an OS particularly, but more general. If you were thinking about a book or guide to overall systems administration or engineering, what would you cover or want covered?
Examples:
- Taking Backups
- Scheduling Reboots
- The Role of the Filesystem
Big picture.
It's easy to get lost in details. I would want to delve in to what the job actually entails and how one would go about organizing it.
And then from big picture down to technical solutions and then how-to's.
-
@stacksofplates said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
That handbook is also associated with LISA, that totally out of touch and incompetent (and not to be seen anywhere in the real world) group that claims to oversee systems administration and traditionally defined the scale of administration by the ridiculous concepts of "user account count" and "code compilation".
Like systems such as Amazon or Change.org or Facebook or Google were all "small time, low level" admin shops because they don't create millions of users at the OS level.
Not sure what you mean here. Looking at the programs over the last 10 years (the 4th edition of the book was released in 2010) LISA has been about DevOps principles, containers, security, etc. Is backed by Amazon, Facebook, Netflix, etc and a good number of the speakers are from those companies.
This is weird, but Wikipedia says that they announced four years ago that LISA was going away.
And this is all that there is for a website, so seems likely...
Their last salary survey was 2011 (which I had seen in 2011.)
-
@Pete-S said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
If you were writing a book on systems administration, or you wanted to read one, what topics do you feel would be best to cover? This isn't like specific to an OS particularly, but more general. If you were thinking about a book or guide to overall systems administration or engineering, what would you cover or want covered?
Examples:
- Taking Backups
- Scheduling Reboots
- The Role of the Filesystem
Big picture.
It's easy to get lost in details. I would want to delve in to what the job actually entails and how one would go about organizing it.
And then from big picture down to technical solutions and then how-to's.
Yeah, that's my feeling. I feel like almost all books are about the weeds and little else. Very task oriented. Which is fine on its own, but you need the big picture, too.
-
Common services / applications / protocols
- DNS
- E-mail and its related protcols
- Proxy servers (forward and reverse)
- TLS
-
@EddieJennings said in Topics of Systems Administration:
Common services / applications / protocols
- DNS
- E-mail and its related protcols
- Proxy servers (forward and reverse)
- TLS
Most books cover these and I wonder about them. Why in a book on system administration, do we often get caught up in managing specific applications on top of the system? And why these? To some degree, I get it, email is used for alerting, Proxy to control access to resources, but it's unique to the UNIX world. In the Windows world, books on systems never include guides on Exchange or Proxy Server (that was its name 25 years ago, I forget the current name.) They were always separate books (and separate certifications.) But on UNIX, we often lump these extra apps into system administration. But they are anything but general tasks, lots of long time career admins don't even know what a proxy is and might never have set up email.
It's great stuff to know, but if we are approaching SA as a role, should we really teach all the application specific skills on top? And if so, why these and why not loads of databases, printers, directory servers, web servers, WordPress and so on? How do we pick which applications to teach and which to expect people to learn separately?
-
@scottalanmiller said in Topics of Systems Administration:
@EddieJennings said in Topics of Systems Administration:
Common services / applications / protocols
- DNS
- E-mail and its related protcols
- Proxy servers (forward and reverse)
- TLS
Most books cover these and I wonder about them. Why in a book on system administration, do we often get caught up in managing specific applications on top of the system? And why these?
In the experience I've had, yes, you will be managing specific applications. As far as to why those, they were the first things that came to mind.
It's great stuff to know, but if we are approaching SA as a role, should we really teach all the application specific skills on top? And if so, why these and why not loads of databases, printers, directory servers, web servers, WordPress and so on? How do we pick which applications to teach and which to expect people to learn separately?
As far s what to teach, I think the answer depends on how comprehensive of a book you want. As far as specific applications, I'd rather the box focus broader concepts and protocols. As an example, if you include E-mail in your book, I'd include information about how SMTP works, rather than a guide on Exchange.
-
@EddieJennings said in Topics of Systems Administration:
In the experience I've had, yes, you will be managing specific applications. As far as to why those, they were the first things that came to mind.
Maybe, but the problem is, only some system admins ever manage any apps (they are apps, not systems afterall) and nearly every admin has a totally different list of them. The problem I've had with most books is that they create some random list of apps and focus on them and never hit the ones that anyone I've ever met has used (and how could they, everyone uses a different list) and so feel like the topics are random and misleading and I'm not sure who they help.
Because it's more than just say "email". It's Postfix, Sendmail, Zimbra, axigen, MailCow or any number of optional email programs that are all unique and different. How, and more importantly why, do we pick just one (or two) and teach those? Any why in a system admin book, why not in a book that's for that topic?
-
@EddieJennings said in Topics of Systems Administration:
As far s what to teach, I think the answer depends on how comprehensive of a book you want. As far as specific applications, I'd rather the box focus broader concepts and protocols. As an example, if you include E-mail in your book, I'd include information about how SMTP works, rather than a guide on Exchange.
I agree that broader concepts matter. But is an SA book a good place to teach network protocols? Should a networking book or an email book do that instead?
-
@scottalanmiller said in Topics of Systems Administration:
Because it's more than just say "email". It's Postfix, Sendmail, Zimbra, axigen, MailCow or any number of optional email programs that are all unique and different. How, and more importantly why, do we pick just one (or two) and teach those?
That's why I suggest protocols, like SMTP. It's general knowledge needed for any system administrator that has to touch E-mail.
Any why in a system admin book, why not in a book that's for that topic?
Again, it depends on how comprehensive you want your book to be? Also, who's the target audience? If this is a book about Systems Administration for someone that doesn't know anything, then yes, I'd say the book ought to mention concepts behind common applications. Also it should set the expectation that further learning is required and the goal of this book is to provide some foundation knowledge so you know where to look next.
-
@scottalanmiller said in Topics of Systems Administration:
I agree that broader concepts matter. But is an SA book a good place to teach network protocols? Should a networking book or an email book do that instead?
I'm sure this will get a laugh from you, but I don't recall any of my CCNA books (even the networking fundamentals) mentioning DNS, SMTP, and other network protocols.
-
@EddieJennings said in Topics of Systems Administration:
That's why I suggest protocols, like SMTP. It's general knowledge needed for any system administrator that has to touch E-mail.
Well, it's standard knowledge for a network admin or an email admin, but not for a system admin. See my dilemma? Sure, the average system admin does non-system tasks. But once we start assuming that we are focused on the opposite of the goal, where do we draw lines?
-
@EddieJennings said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
I agree that broader concepts matter. But is an SA book a good place to teach network protocols? Should a networking book or an email book do that instead?
I'm sure this will get a laugh from you, but I don't recall any of my CCNA books (even the networking fundamentals) mentioning DNS, SMTP, and other network protocols.
I'm pretty sure that they do, lol. The Net+ definitely does. That's where that stuff really goes, definitely not in a systems book.
It would be super high level of course. Digging into SMTP makes no sense until you are a deep email expert. Even full time email admins rarely know much about SMTP beyond the very basics. For other roles to know much would be unproductive. Knowing that it's the protocol of email is really enough.
-
@scottalanmiller said in Topics of Systems Administration:
@EddieJennings said in Topics of Systems Administration:
That's why I suggest protocols, like SMTP. It's general knowledge needed for any system administrator that has to touch E-mail.
Well, it's standard knowledge for a network admin or an email admin, but not for a system admin. See my dilemma? Sure, the average system admin does non-system tasks. But once we start assuming that we are focused on the opposite of the goal, where do we draw lines?
I do see your dilemma. However, I have yet to see a system admin not be expected to have some of the aforementioned knowledge. Perhaps my new gig will be the first.
As far as drawing the lines, that's always though. I do think the answer must lie within the overall target audience and how comprehensive the information ought to be. Perhaps one line can be found by deciding if the book should appeal to the average system admin that has to do non-system tasks or the system admin that would never do non-system tasks.
-
@scottalanmiller said in Topics of Systems Administration:
@EddieJennings said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
I agree that broader concepts matter. But is an SA book a good place to teach network protocols? Should a networking book or an email book do that instead?
I'm sure this will get a laugh from you, but I don't recall any of my CCNA books (even the networking fundamentals) mentioning DNS, SMTP, and other network protocols.
I'm pretty sure that they do, lol. The Net+ definitely does. That's where that stuff really goes, definitely not in a systems book.
It would be super high level of course. Digging into SMTP makes no sense until you are a deep email expert. Even full time email admins rarely know much about SMTP beyond the very basics. For other roles to know much would be unproductive. Knowing that it's the protocol of email is really enough.
I will admit a bit of bias in my feeling of the importance of needing to know a bit about SMTP as my last two jobs have ended with me being the primary (in one case, only) E-mail administrator
-
@EddieJennings one of the dangers or factors here is that enterprise system administration (pure SA) and "small business generalist IT" often share the title of SA with almost no overlapping duties. As a small business generalist, we'd see SA tasks, along with email, web, LOB apps, networking and countless other duties. In a pure SA role, we almost never do.
So from an SMB perspective, we think of the SA as the person that, for example, manages SQL Server. But to Microsoft and IT shops that have roles, that's a DBA role. The SA simply provides the OS for the DBA to work from. The SA likely would install SQL Server, but configuration and tuning is for the DBA. Same for Exchange, the SA might install the OS and maybe even Exchange, but the Exchange Admin does all the email tuning and setup. And on and on. The roles are very discrete and the SA only does SA tasks.
In the SMB, you can pick any role (web admin, email admin, DBA, network engineer) and say that they do "all the other things", because in the SMB it's always a generalist, never one of those specific roles. That we often call all those roles SA rather than randomly another one (and network engineer gets picked next most often) is mostly just because it's the words most easily consumed by management and little else.
In my SMB experience, SA work is not even the predominant role when working on servers. It's LOB management.
-
@EddieJennings said in Topics of Systems Administration:
I do see your dilemma. However, I have yet to see a system admin not be expected to have some of the aforementioned knowledge. Perhaps my new gig will be the first.
Well, you could define SA as being a role that doesn't need that knowledge and if you see anything else, it's not SA.
SAs are expected to be bright and knowledgeable, but there's a big difference between being expected to be able to figure out everyone elses' jobs, and their jobs being part of your job.
SA is a lot like being a lawyer. Your attorney's job is not to make business decisions for you, it's to know the law. But loads and loads of lawyers (like most of them) end up business consulting because they tend to be smarter than average, have more exposure, know now to think about things better, and take a serious interest in business. It's not their role and we don't even confuse it for being so, but if we treated them like we did in IT, we'd start calling nearly every business function a "legal issue."
