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

441–450 of 466 posts

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

#441

Post by lmm »

tokenrove wrote: post #354
lmm wrote: post #11

make is the least-auditable build tool imaginable. You don't have to obfuscate a Makefile, they come pre-obfuscated; you could put the "own me" commands right there in "plain" Make. Not to mention that it's often easier to tell whether a Java .class file is doing anything nefarious than whether a .c file is. How many sysadmins read the entire source of everything they install anyway? Maven, on the contrary, is the bi…

Who can't read a Makefile? Who can't at least read the output of make -n? It's terrifying to me that you're suggesting that people can't and don't. It's not even a security thing. I've had poorly-written Makefiles that would have blown things away thanks to an unset variable on a certain platform, for example.

> Who can't read a Makefile? Who can't at least read the output of make -n? It's terrifying to me that you're suggesting that people can't and don't.

Can I read a Makefile? Sure. But 90%+ of Makefiles these days are 12000 line automatically generated monstrosities. It's not worth my time to bother opening the Makefile in a text editor in case it isn't, and I'd be amazed if many people did.

make -n you can do I guess. But unless you're also auditing all the source code I'm not sure there's a lot of value in it.

> It's not even a security thing. I've had poorly-written Makefiles that would have blown things away thanks to an unset variable on a certain platform, for example.

Yep. Maven doesn't do that.

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

#442

Post by timq »

Anderkent wrote: post #405
stephenr wrote: post #334

Earlier quoted context omitted.

Can you give an example of what you might turn to google for (and what you'd search for) that is more productive than checking a manpage/help output?

OK, recent simple example: Google query: git display file at revision. Immediate answer (without even having to click any links, it's in the result description): `git show revision:file` Total time: 5 seconds Trying to reproduce with man and help: man git search for display, finds nothing start scrolling down notice git-show (show various types of objects); sounds like a likely candidate git show ..no output git show…

One reason to keep reading man pages is because you will likely discover new thing you did not expected. Also reading man pages help you to understand the tool philosophy/workflow, if the man page is well writen (which is often the case). This hold for any kind of documentation as well.

When I google something, I usually do not remember the answer to my question, the only thing I remember is the keyword to put in my futur query to get the same answer. You will get your answer quicker, but you wont learn much. So personally, I prefer reading man pages (when I can) than use google.

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

#443

Post by odonnellryan »

tracker1 wrote: post #339
odonnellryan wrote: post #320

Earlier quoted context omitted.

Docker is awesome, but you shouldn't be using blind base images. Use Dockerfiles, they're self-documenting.

Unless you build your own base images... odds are you will be using something someone else built. Even the host OS probably wasn't compiled by you. In general, my base images are often debian:wheezy, ubuntu:trusty or alpine:latest ... From here, a number of times I've tracked down the dockerfiles (usually in github) for a given image... for the most part, if the image is a default image, I've got a fair amount of tru…

Well, you have to trust something somewhere. Unless you're always compiling from source (which you can do with Docker), and you've read the source, etc.. but even then, you have to trust the compiler and the hardware.

Anyway, yes, you can make your own base images. But, images `should` be light enough where you can build them each iteration. I've done dev stacks where literally each `save/commit/run of a test` built the docker container from the dockerfile in the background! With the caching docker does it really doesn't add any overhead to the process.

> What is interesting is often the dockerfile simply adds a repository, and installs package X using the base os's package manager.

Yup! Pretty much. Other than some config stuff for very specific use cases (VPN, whatever.)

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

#444

Post by rockdoe »

mdellabitta wrote: post #389
rockdoe wrote: post #202

Earlier quoted context omitted.

But the problem is that the ones doing the vetting (i.e. Debian) have given up on making a vettable distribution because the build is so broken.

But Debian isn't the Debian of Hadoop. Cloudera is. Why should we assume the Debian Foundation is the sole trusted source of every type of software?

What you are saying makes no sense.

And yes, if I'm using Debian and didn't add any PPA or extra sources, then the Debian Foundation IS the sole trusted source of software. And you do that because you know hey won't fuck up the system, which (and that's the whole point of this thread) the others certainly don't.

Now Debian is telling you: we see now way to distribute this software and guarantee what you are getting or that it won't fuck up the system.

Do you think I'd consider installing that junk?

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

#445

Post by Alupis »

bandrami wrote: post #431
yoklov wrote: post #377

Earlier quoted context omitted.

C++'s runtime is small and ubiquitous. Depending on how the software is written (if it allows disabling exceptions and rtti), it might be the same size as C's runtime, which is practically (but not totally) nonexistant. I'm not an expert on Java, but my experience with it is that it's runtime is fairly huge and requires custom installation.

C++'s runtime is worse than Java's in that sense. Most JVMs can run most Java bytecode, but your libstdc++ has to be from the same version of the same compiler that your application was compiled with.

It was quite surprising for me the first time I did a little embedded work and discovered I couldn't run binaries that were compiled against glibc on my musl-libc based system, and vice-versa. I had initially thought they all just supported the same c89 spec so should work...

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

#446

Post by lmm »

acveilleux wrote: post #275
lmm wrote: post #250

Earlier quoted context omitted.

It doesn't have to be circular. The script is secured by HTTPS (and hopefully has the key embedded in the script itself?) which can then retrieve the installer and verify it using the key.

The problem is that in this scenario, the GPG key and signature serves no practical purpose. The whole security, whether GPG is invoked or not, relies on the security of the HTTPS connection alone. If the HTTPS cannot be trusted alone, then everything is lost as a compromised HTTPS connection can be used supply both a comprimised GPG key and a compromised package, or, indeed, anything at all that is legal to `| sudo…

It gives people a way to choose the level of security they care about. Those who are willing to trust HTTPS can trust HTTPS. Those who aren't can obtain the GPG key and check its signature by another mechanism (WoT) and manually verify the package signature.

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

#447

Post by mdellabitta »

rockdoe wrote: post #444
mdellabitta wrote: post #389

Earlier quoted context omitted.

But Debian isn't the Debian of Hadoop. Cloudera is. Why should we assume the Debian Foundation is the sole trusted source of every type of software?

What you are saying makes no sense. And yes, if I'm using Debian and didn't add any PPA or extra sources, then the Debian Foundation IS the sole trusted source of software. And you do that because you know hey won't fuck up the system, which (and that's the whole point of this thread) the others certainly don't. Now Debian is telling you: we see now way to distribute this software and guarantee what you are getting o…

So everyone who runs Hadoop is installing junk? Seems like plenty of other companies have been able to build businesses on it without adhering to your Debian-only rules...

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

#448

Post by Nursie »

bobbyi_settv wrote: post #323
Nursie wrote: post #269

Earlier quoted context omitted.

>> No one can tell you how to build hadoop? Well, figure it out. I get the impression that several people working on debian couldn't work this one out!

I think most people who use debian would tend to install things using debian packages, which in this case usually means adding cloudera to your apt sources list and using apt-get. It is a pretty straightforward process: http://www.cloudera.com/content/cloudera/en/documentation/cd...

Sure, I agree that debian people would want to install debian packages.

What debian users/hackers/amateur admins like me really want is packages that are first class citizens, that the debian guys have picked up, sanitised, analysed and made part of the system.

I'll take software from the debian repos every time if I can. And it's pretty damning if people who are familiar with build systems and package creation can't figure it out!

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

#449

Post by [deleted] »

Alupis wrote: post #445
bandrami wrote: post #431

Earlier quoted context omitted.

C++'s runtime is worse than Java's in that sense. Most JVMs can run most Java bytecode, but your libstdc++ has to be from the same version of the same compiler that your application was compiled with.

It was quite surprising for me the first time I did a little embedded work and discovered I couldn't run binaries that were compiled against glibc on my musl-libc based system, and vice-versa. I had initially thought they all just supported the same c89 spec so should work...

[deleted]

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

#450

Post by [deleted] »

Alupis wrote: post #445
bandrami wrote: post #431

Earlier quoted context omitted.

C++'s runtime is worse than Java's in that sense. Most JVMs can run most Java bytecode, but your libstdc++ has to be from the same version of the same compiler that your application was compiled with.

It was quite surprising for me the first time I did a little embedded work and discovered I couldn't run binaries that were compiled against glibc on my musl-libc based system, and vice-versa. I had initially thought they all just supported the same c89 spec so should work...

[deleted]
Post reply on HN