Live data from Hacker News

The sad state of sysadmin in the age of containers (2015)

vitavonni.de

411–420 of 435 posts

Re: The sad state of sysadmin in the age of containers (2015)

#411
post #409

Earlier quoted context omitted.

> I have indeed made Docker images containing exactly one file To anyone reading this, you need some magic compiler flags in both Rust and GoLang to make sure it's a statically compiled binary (doesn't dynamically link against GNU lib-c). But yes, this is super neat. I also like how it reads in the docker file: FROM scratch ...

Ah yeah, without CGO_ENABLED=0, you'll get a very cryptic error when the ELF binfmt can't find the linker binary... Never tried it with Rust, but I look to using Rust in the future, so I guess I better find out what the flags are for Rust. Sidenote: It's often useful to have ca certs and timezone info. At that point it's probably not a bad idea to just use Alpine and apk add those things.

By default, Rust compiles all Rust code statically, but the standard library depends on a libc. If you want to use MUSL, you can. If you bind to C libraries, you may need to configure it or not, it depends on how the wrapper is written.

Re: The sad state of sysadmin in the age of containers (2015)

#412

Earlier quoted context omitted.

Moreover, who is going to write the next protocols we need? This isn't a field that is done inventing. Not even remotely close.

OP was talking about a future where developers become obsolete because machines take over the development sector. Do you think writing protocols will be something humans will do better than machines?

Yes. Machines might come up with something that's 'good enough' though.

Re: The sad state of sysadmin in the age of containers (2015)

#413

Earlier quoted context omitted.

Well, you're right, I'm not a sysadmin. I pervasively automate, which often sidelines sysadmins, when it doesn't make them redundant. I write code and I don't touch production machines except in extremity, neither of which apply to most (though by no means all) of the people I know who want to call themselves a sysadmin. Anyway, the core mission of anybody touching the stack is to enable the business to achieve its g…

It's not that sysadmins cannot do the work you are rightfully proud of. If there are two basic things that differentiates your statements from those of a traditional sysadmin it is these. 1. Design. 2. Discipline. Where these two values are dispensable long term devops and the new world shine through. I've worked in both worlds and the only mistake is assuming one size fits all.

In general you seem like an absurd sort of creature. Neither here nor there. Bragging about your facility and business velocity. Everything you claim to do sysadmins were doing in 98 and with equal velocity and adequate coverage.

There were guys like this that were there before and helped everyone along: https://www.computerhope.com/people/don_libes.htm

Re: The sad state of sysadmin in the age of containers (2015)

#414
post #67

I do often think about how, by using large JS packages, it's very feasible that in the daisy chain of NPM dependencies, somebody's managed to slip in malware. I'm not sure what to do about it other than just not using NPM at all!

Checkout from npm retire and auditjs (there's also more non free options). You'll likely get some false positives (such as, who would host jQuery on a public/untrusted cdn? or why would you even pass user input into that?), but if a real malware actually showed up, you can find out as part of your CI process. Using the lockfile provided by yarn/npm is also a good way to reduce accidental unnecessary package updates.

Re: The sad state of sysadmin in the age of containers (2015)

#415
post #305

Earlier quoted context omitted.

> Well, teach your sysadmin to use the system configuration tester when they edit a system configuration file. Wrong. Teach your sysadmin not to overload a single service with different functions (debugging channel, user-facing shell service, running remote commands, file upload, and config distribution channel), especially not the one that should not be used in batch mode, without human supervision. When you write a…

Are you advocating running multiple sshd instances in this case?

Good heavens, no! You'd only have two different instances of the same service that is difficult to work correctly with.

For serving as a debugging channel and user-facing shell access, SSH is fine (though I've never seen it managed properly in the presence of nodes being installed and reinstalled all the time). But for everything else (unattended):

* you don't want commands execution, port forwarding, or VPN in your file server

* you don't want remote shell in your daemon that runs parametrized procedures -- but you do want it not to break on quoting the arguments and call results (try passing shell wildcards through SSH)

* you don't want port forwarding and remote shell in config distribution channel; in fact, you want config distribution channel itself to be reconfigured as little as possible, so it should be a totally separate thing that has no other purpose whatsoever

* you don't want to maintain a human-user-like account ($HOME, shell, etc.) for any of the above, since they likely will never see a proper account on the server side; you want each of the services to have a dedicated UID in /etc/passwd, own configuration in /etc/$service, own data directory, and that's it

Each of the tasks above has a daemon that is much better at them than SSH. The only redeeming quality of SSH is that it's there already, but it becomes irrelevant when the server's expected life time gets longer than a few days.

Re: The sad state of sysadmin in the age of containers (2015)

#416
post #311

Earlier quoted context omitted.

> it's based on a kind of maths called "promise theory" Promise theory is not math, despite its name. It doesn't predict anything, it doesn't explain any phenomena. It's an architectural approach. Brilliant, led to a really great software (CFEngine), but it's not "maths".

Basic concepts of promise theory (10 minute video by Mark Burgess who came up with it): https://www.youtube.com/watch?v=2TPsB5WuZgk 2014 introductory article: https://www.linuxjournal.com/content/promise-theory—what-it Basic book on the subject: https://www.amazon.com/Thinking-Promises-Designing-Systems-C... It's not "maths" like arithmentic but it's "maths" like graph theory: Promise Theory, in the context of inform…

> It's not "maths" like arithmentic but it's "maths" like graph theory

It's less like graph theory and more like inversion of control: an architecture, not a set of theorems and their proofs. Even Burgess' own book you mentioned is nothing like a mathematical handbook.

I'm a great fan of Mark Burgess and his promise theory, but calling it a mathematical theory or a mathematical domain is simply incorrect.

Re: The sad state of sysadmin in the age of containers (2015)

#417

Earlier quoted context omitted.

Yes. The host will run 100% CPU to handle the hundreds of SSH connections. I've been re configuring 300 to 800 hosts many times a day, never had a problem. I think it would take a few thousands hosts for the performance to be noticeably slow and I am really not sure that other tools or systems could take it much better.

I know our SREs once screwed the config for sshd, and considered themselves very lucky that they had puppet on the machines and could push a fixed configuration (if they had used exclusively ansible, that'd be the end of it - no way to connect or to deploy new configuration) [edit] To clarify - ansible is great, and we use it. Just saying that, as everything, it still has (sometimes subtle) downsides in various scena…

There's nothing stopping you from having a sshd instance dedicated for use just by ansible, on a different port/different network, on every node. Now if that's simpler or more complex I don't know.

But "have two ways in" is a basic principle of sys admin (typically via traditional network and some out of band console access).

Re: The sad state of sysadmin in the age of containers (2015)

#418
post #346

I think the entire statosphere of DevOps is just about dead on the whole in 2018 .. in retro, after working with things like Docker .. and more specific industry variations beyond the Amazon tech, it makes no sense to dwell on the security / control of a dedicated systems admin professional since the tools are all outside the local domain anyway. The rest from VoIP to IoT to container services are managed whole-sale…

I'm not convinced there was ever a need for sysadmins, especially from the point of view of programmers. Programmers have always been able to do that work themselves. It's just that they don't want to. They think it's boring, or perhaps even beneath them. It's a bit like tax preparation. I don't think that's really changed all that much, even today, even if it's now programming against the AWS API, judging by the num…

> I'm not convinced there was ever a need for sysadmins, especially from the point of view of programmers. Programmers have always been able to do that work themselves.

> It's just that they don't want to. They think it's boring, or perhaps even beneath them. It's a bit like tax preparation.

I'll half agree here, and half not. I'm coming at this as a programmer who has historically done ops as well, currently doing more ops than dev.

There's parts of it that programmers don't want to manage, like Apache configuration, provisioning and sizing VMs appropriately, etc. That's the boring stuff, and I totally get it. I don't like managing most of that stuff either, and have got everything set up with service discovery to handle a good chunk of the configuration, and Terraform for managing resources instead of having to click through the Azure Portal, and Nomad for scheduling tasks in the clusters. Groovy.

There's also the parts that the developers seem to have no clue about. They're very happy with all of these abstractions, but there's a lot of layers underneath. They think in terms of making HTTP requests; when those don't work, it's up to me to figure out that their library is keeping a pool of HTTP connections open, and the Azure load balancer silently drops those connections out of the NAT table after 4 minutes of idle time (without sending FIN or RST packets to either side, natch). When the app gets terminated because it's exceeded its cgroup memory limit, I'm the one helping them adjust their JVM heap size. And when their requests take too long, I'm there helping them look through their query logs to figure out what's happening.

All of these cases have happened in recent memory, and it's never been a matter of "this is boring and/or beneath me", it's been a matter of "HALP! I HAVE NO IDEA WTF IS HAPPENING"

Edit: so yes, I agree with you in the sense that I'm a developer who generally speaking doesn't need a sysadmin. I installed Linux for the first time when I was 12 years old, 22 years ago :), and I didn't have a sysadmin then. In those 22 years, I've seen a lot of weird shit happen, and most of the people I've worked with don't seem to be well equipped to dive 3 abstraction layers deeper than they're used to to figure out what's wrong.

Re: The sad state of sysadmin in the age of containers (2015)

#419

Earlier quoted context omitted.

It's not that sysadmins cannot do the work you are rightfully proud of. If there are two basic things that differentiates your statements from those of a traditional sysadmin it is these. 1. Design. 2. Discipline. Where these two values are dispensable long term devops and the new world shine through. I've worked in both worlds and the only mistake is assuming one size fits all.

In general you seem like an absurd sort of creature. Neither here nor there. Bragging about your facility and business velocity. Everything you claim to do sysadmins were doing in 98 and with equal velocity and adequate coverage. There were guys like this that were there before and helped everyone along: https://www.computerhope.com/people/don_libes.htm

At the risk of being too "meta", although I agree with what I believe is your point about good sysadmins having been advancing automation (and otherwise keeping business needs in mind), I worry that you're distracting a reader from that point by what reads as an ad-hominem attack in your first sentence.

I'm still not certain what point you were trying to make with "neithere here nor there", however.

Re: The sad state of sysadmin in the age of containers (2015)

#420
post #407
post #72

Earlier quoted context omitted.

We have 47 half-built over-complicated build systems, because writing build systems is hard. Writing correct Makefiles is also really hard, and good luck debugging them. Make is simple and beautiful for small, self-contained projects without many dependencies, but it does not scale well (and even then it's tricky, see [0][1]). Having 47 different build tools with their own flaws is certainly bad, but they exist becau…

See these discussions, too: * https://news.ycombinator.com/item?id=15060146 * https://news.ycombinator.com/item?id=15060146

Did you mean to paste two different discussions? Those are identical.
Post reply on HN