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? 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."
-
@EddieJennings said in Topics of Systems Administration:
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.
Well there are two options.... targeting people wanting to learn about system administration, or targeting people who want to learn something that isn't system administration, but want it to be called system administration, and aren't looking in the right place.
Think about it in terms of any other topic. We ask "What do you need to know to do X" and the answer is "Well that depends if you want them to do X or Y?"
Well, that they wanted X was the sole premise, how does Y come into play, ever?
Topic: "How to ride a bicycle"
But then: "Maybe we should teach driving a car and boat safety primarily."What?
-
@scottalanmiller said in Topics of Systems Administration:
@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.)
https://www.usenix.org/conferences/byname/5
There's one scheduled for next year.
-
@scottalanmiller said in Topics of Systems Administration:
@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.
This might be one of the lines for which you're looking. Perhaps specify in the book, that if you're working in a SMB, this book of pure system administration isn't intended for you.
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.
This I understand. In my last gig, we were organized like that for our database needs. We (Systems Team) provided the VMs for the DBAs to do what they needed to do for SQL Server. We also had a dedicated networking and telecom team. But for Systems Team, we were all SMB generalists that had to function as "SMEs" for certain applications -- like Exchange for me.
-
@EddieJennings said in Topics of Systems Administration:
@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
I have a similar, but opposite bias. Back in the 90s I read like every major book on SA you can imagine. They all covered pretty much the same stuff. And then, in a career where I've worked in everything from SMB to three Fortune 10s, in academia, have taught both university and professional classes (I was the SA teacher for IBM and Lockheed), have overseen hundreds of high price admins.... never once in decades of experience have I encountered any role that in any way resembled what every book and reference touted as "what SAs do."
They all seem to have worked in a tiny subsection of 1980s or 1990s SMBs, done just one or two essentially similar tasks, and just assumed that the entire field was what they saw without the slightest general experience. I assume that somewhere there was a professor who never managed to get a job in the field and a number of their students kept regurgitating the same false info.
And it would vary from minor (they all taught Sendmail, but Postfix is what almost all real world deployments were) to major (they all taught GUIs and printers, but find a UNIX shop that uses either, anywhere.) And it was giant percentages of the books, like 60-80%, focused on tasks I've never seen anywhere, in any industry, at any size, at any point in time - and almost all are ones I couldn't imagine having any scale.
And, of course, it all comes at the expense of learning the basics and actual material. I assume because it's easy to teach Sendmail basics and hard to teach real SA concepts. One is just copying common commands, the other is explaining difficult ideas. It has felt like they've always been a crutch, a way to cheap out on teaching what matters but make books long and daunting with little effort.
-
@scottalanmiller you are asking a group consisting of almost only SMB focused people.
To them, there is no such thing as this mythical System Admin that you continually talk about.
The responses above prove that.
Do most of them know the technical difference? Sure. Any that didn't when they started reading ML, would have had it beat in to them by now.
But that doesn't mean a damned thing to them, because there is no such thing as a "Systems Administrator" that is actually an administrator of systems.
-
@stacksofplates said in Topics of Systems Administration:
@scottalanmiller said in Topics of Systems Administration:
@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.)
https://www.usenix.org/conferences/byname/5
There's one scheduled for next year.
LISA was an organization. The conference is a later thing that shares a name. I'm referencing the LISA organization that appears to no longer exist.
-
@EddieJennings said in Topics of Systems Administration:
This I understand. In my last gig, we were organized like that for our database needs. We (Systems Team) provided the VMs for the DBAs to do what they needed to do for SQL Server. We also had a dedicated networking and telecom team. But for Systems Team, we were all SMB generalists that had to function as "SMEs" for certain applications -- like Exchange for me.
Right, so it wasn't a systems team. There was telecom, DBA, networking, and generalists. Nothing wrong with that, but it's important to understand what it is.
The payscales of generalists and SAs are wildly different, as are their daily tasks.
-
@JaredBusch said in Topics of Systems Administration:
But that doesn't mean a damned thing to them, because there is no such thing as a "Systems Administrator" that is actually an administrator of systems.
Even in the SMB (under 20 people even) we have customers that use real SA. Where SA and App teams are separate companies. One is pure Windows Server, the other is pure application and they call each other to coordinate. The app team has only a light knowledge of Windows, not enough to run it in production. And the Windows team knows extremely little about the workings of the application.
I see this commonly in manufacturing, for example. And in medical as well.
