Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The sad state of sysadmin in the age of containers

vitavonni.de

Post reply on HN
Print view View original

151–160 of 466 posts

Re: The sad state of sysadmin in the age of containers

#151

Post by microtonal »

toyg wrote: post #129
microtonal wrote: post #122

Earlier quoted context omitted.

It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. But it isn't all that hard to understand a clean Unix. I have never copied or typed a command that I don't understand. One problem may be that most Unices these days is not as clean anymore as, say OpenBSD or NetBSD. E.g. the recent X stack, with D-BUS, various *Kits, etc. is qui…

> But it isn't all that hard to understand a clean Unix. I have never copied or typed a command that I don't understand. Well, good for you. I can assure you that it's not the case for almost anyone who approached Linux after the likes of Mandrake were released and/or tried to make it work on anything different from a traditional server. I'm all for trying to understand what one is doing (and I wholeheartedly agree w…

I'm all for trying to understand what one is doing (and I wholeheartedly agree with TFA's point), but the reality is that very few people in the world really understand all intricacies of one's operating system.

One of the problems (as I tried to argue) is that most Unices have become far more complex. The question is if the extra complexity is warranted on a server system, especially if bare Unix (OpenBSD serves as a good example here) was not that hard to understand.

Of course, that doesn't necessarily mean that we should look back. Another possibility would be to deploy services as unikernels (see Mirage OS) that use a small, thin, well-understood library layer on top of e.g. Xen, so that there isn't really an exploitable operating system underneath.

Re: The sad state of sysadmin in the age of containers

#152

Post by ams6110 »

marcosdumay wrote: post #124
tormeh wrote: post #92

Earlier quoted context omitted.

It's just automated copy-pasting of commands you don't understand from the internet, which is something everyone who runs Linux (and is not a wizard) does all the time. It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. Unfortunately, this has never been a priority in Unix-land as far as I've gathered.

It's not the same by any measure. When you read the script in a browser, than pastes it in a terminal, you know that "scp -r ~/.ssh u@somehost.com" isn' there.

This is why you have a strong passphrase on your ssh private key.... right?

Re: The sad state of sysadmin in the age of containers

#153

Post by fab13n »

It seems rather easy and effective, for NSA-like agencies, to hide crude exploits in complex projects. An unintended effect of Snowden's whistle blowing is that it has become easier, because it has let them know that they don't need plausible deniability requirement anymore.

Until Snowden, they were very cautious not to be caught, because, you know, what might happen if public opinion knew what a bunch of crooks they were? Now, they know that public opinion doesn't really care, and that if they're caught, they can mostly shrug it off, with politicians' complicity.

So, shoving a rather crude and detectable exploit in a messy product has become practically doable. If I were in charge of subsidies distribution for some 3-letters agency, I'd pour more money on Docker, Maven etc. than on TLS.

Re: The sad state of sysadmin in the age of containers

#154

Post by davexunit »

dschiptsov wrote: post #101

What is really ironic is that none of this "tools" solves any fundamental problem of so-called version hell and none of this containers are fundamentally different from ./configure --prefix=/xxxx && make && make -s install with or without following chroot /yyyy The big "innovation" of having so-called "virtual env" (they call it "reproducible [development] environment) for each "hello world" (a whole python/ruby/java…

I think you are conflating purely functional, reproducible environments with the (for lack of a better term) Docker way of managing containers where you just make full disk image for everything with lots of duplication. It is very possible to have the former while avoiding the latter. Both the Nix and GNU Guix projects succeed at this. I recommend taking a look at them to see if they address your concerns.

Re: The sad state of sysadmin in the age of containers

#155

Post by Lawtonfogle »

mercurial wrote: post #103
highmastdon wrote: post #53

Earlier quoted context omitted.

Same goes for 'abstraction', it hides the essence of what is happening. Therefore every abstraction is evil.

Hopefully this is sarcasm. Code without abstraction can also very efficiently hide what is happening by having a disastrous signal-to-noise ratio, combined with all the potential for errors you get when repeating the same pattern many times.

Code is abstraction. With no abstraction you have to build your systems with lots of nand gates and a clock.

Re: The sad state of sysadmin in the age of containers

#156

Post by sre_ops »

TeMPOraL wrote: post #93
TheDong wrote: post #45

Earlier quoted context omitted.

Signed packages isn't about just being signed. I could sign anything I like, but that doesn't make it any more secure for you to curl it into /bin/bash. Signatures are about who signs it, and that's not something mvn has solved at all. Mvn is a free-for-all of binary code that very well could own my system, wheras debian is a curated collection of software which the debian maintainers have signed as being compiled by…

> wheras debian is a curated collection of software which the debian maintainers have signed as being compiled by their systems with no malign influence and having met at least some bar. This comes with a huge tradeoff, and I guess it's that tradeoff that makes developers like myself opt to sometimes even pipe the cURL to bash. I almost never download any software I actually plan to use through official system reposi…

That's because that those of us who actually run real production systems with real production traffic with real production users who pay real money aren't stupid enough to run a bleeding edge code since we see how many "ooops" bugs are listed in the CHANGELOG

Re: The sad state of sysadmin in the age of containers

#157

Post by wflann »

stephenr wrote: post #121
tormeh wrote: post #92

Earlier quoted context omitted.

It's just automated copy-pasting of commands you don't understand from the internet, which is something everyone who runs Linux (and is not a wizard) does all the time. It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. Unfortunately, this has never been a priority in Unix-land as far as I've gathered.

I would argue that anyone who is reasonably comfortable in a command line would resort to `man command`, `command --help` or `command -h` before googling for usage.

I think, occasionally, it's a lot easier to grok a command through googling than reading the built-in help. A fair amount of built-in *nix documentation I have run across is mediocre or unhelpful.

Re: The sad state of sysadmin in the age of containers

#158

Post by juliangregorian »

jannic wrote: post #147
marcosdumay wrote: post #124

Earlier quoted context omitted.

It's not the same by any measure. When you read the script in a browser, than pastes it in a terminal, you know that "scp -r ~/.ssh u@somehost.com" isn' there.

No, you don't: http://thejh.net/misc/website-terminal-copy-paste

Okay, but this relies on CSS trickery. If you had navigated to a text URL this would not be a vector.

Re: The sad state of sysadmin in the age of containers

#159

Post by dschiptsov »

antientropic wrote: post #117
dschiptsov wrote: post #101

What is really ironic is that none of this "tools" solves any fundamental problem of so-called version hell and none of this containers are fundamentally different from ./configure --prefix=/xxxx && make && make -s install with or without following chroot /yyyy The big "innovation" of having so-called "virtual env" (they call it "reproducible [development] environment) for each "hello world" (a whole python/ruby/java…

I would be interested to know why you call purely functional package management "idiotic", given that one of its main goals is to solve the problem of version hell? I.e., to make it easy for a developer to specify that application X should use version V of library Y, without interfering with other applications on your system?

Very simple. There is so-called atomic operations, or transactions, which are good enough to solve the problem. Any "pure functionality" in this context is plain nonsense.

Re: The sad state of sysadmin in the age of containers

#160

Post by jkyle »

stephenr wrote: post #32
blfr wrote: post #4

This bothers me as well. Even tasks as simple as adding a repository are now being "improved" with a curl | sudo bash style setup[1]. However, installing from source with make was (and remains) a mess. It may work if you're dedicated to maintaining one application and (part of) its stack. But even then it usually leads to out of date software and tracking versions by hand. Many people have this weird aversion to doin…

I agree that the "just curl this into bash" instructions are nightmare - on any platform. I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management": This is where you have a team (either for a single project or a team at a consulting agency, etc) that is effectively all development-focused staff, possibly with some who dabble in Infrastructure/Ops. In this environment,…

> Unfortunately I was stupid enough to ddg it (duckduckgo it, as opposed to google it) and apparently this exact use-case was previously the recommended way of installing RVM[2]

Not only "previously", it's the current recommended way to install rvm. From their front page:

>> curl -sSL https://get.rvm.io | bash -s stable

[1] http://rvm.io/

Post reply on HN