[flagged]
The sad state of sysadmin in the age of containers (2015)
41–50 of 324 posts
Re: The sad state of sysadmin in the age of containers (2015)
#42Ever tried to security update a container? The whole point of using a container is that you can destroy it and build a new one easily. The new one should be built using up-to-date packages with security patches applied (and tested, obvs). Using the 'pets versus cattle'[1] analogy, patching a container feels like you're treating it like a pet. You should just kill it and get a new one instead. [1] https://thenewstack.…
The whole point of having a distro with a good reputation is that you can incrementally outsource your trust to them, one package at a time. OpenSSL needs a fix? One package update per machine, and if you have lots of machines, you update that.
With VMs, you can use the same tools you use with any other machine.
With containers, you are responsible for figuring out which ones need which packages and how to re-build them. Your method is likely to be idiosyncratic, so you not only need to be your own security team, you need to be your own packaging maintainer and infrastructure maintainer.
The two extreme versions of this are the neglect model, in which you just don't care about anything, and the bleeding-edge model, where you automatically build with the latest versions of everything pulled from their origins. Both ways end up with unexpected security disasters.
Re: The sad state of sysadmin in the age of containers (2015)
#43I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…
I like using Artifactory for this, you keep a local copy of all NPM / nuget / etc dependencies hosted next to your build infrastructure.
What shocked me most about NPM is that it used to have absolutely 0 verification built in, yet it was being heavily promoted by very well known, educated and experienced tech celebs. All at a time when it was basically a hobby toy.
Re: The sad state of sysadmin in the age of containers (2015)
#44I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…
I sometimes have problem doing `./configure && make` because dependencies varies across different distro, which have some subtle differences that make it not easy as expected.
If you can do `./configure && make`, you can also do a `checkinstall` on debianesque systems, which gives you a package so you don't have to do it again.
Re: The sad state of sysadmin in the age of containers (2015)
#45Earlier quoted context omitted.
It's pretty hard to do truly declarative/immutable things with docker because the typical dockerfile starts with "apt-get update && apt-get install ...". For that use case I think nix is much better.
Linters complain when you don't pin the version, though
That's what I tried doing. The result was that the docker container didn't build anymore because at least one of the packages we used had a a patch release every other day and apt only serves the most up to date version.
Re: The sad state of sysadmin in the age of containers (2015)
#46Terrible article IMO. Hadoop is an awful mess, but it has nothing to do with Docker, which is simplistic in comparison. "Ever tried to security update a container?" Yes, I have! In fact you can maintain patch compliance in a container pretty much the same way you'd maintain a VM or bare metal Linux installation!
>Unfortunately, the build process for these packages is currently of a disastrous quality, and should only be attempted within disposable virtual machines, as it requires root permissions and will install non-packaged software. https://wiki.debian.org/Hadoop If Debian, a distro on the lower side of dramatic, calls it disastrous, it's pretty bad.
Debian is (mostly) low on the drama, but high on the expected package quality. It's not surprising they'd have problems here.
Re: The sad state of sysadmin in the age of containers (2015)
#47This all boils down to trust. `curl | sudo bash` is no different than .\install.exe. The question is about trusting the SOURCE and trusting the DISTRIBUTION channel (that HTTP download from scala-lang.org violates this). Where did you get it? from https://microsoft.com/.. . or from https://micro.soft.com/... ? Whom you trust more? The same with pre-built VM image or whatever... do you trust the party that made this i…
`curl | sudo bash` should never have become a thing in the first place. To me, it's the most "WTF?" mode of installing anything. Especially when the source is HTTP. In what world is that secure? Pity Qubes is so heavy, otherwise I'd be using it
would you feel better if your Makefile looks like this:
install:
[ $(id -u) -ne 0 ] && echo 'please run sudo make install' || curl https//my.thing | /bin/sh
Re: The sad state of sysadmin in the age of containers (2015)
#48Looked at the Debian wiki the OP linked to: >Debian currently does not include Hadoop packages. There are a number of reasons for this; in particular the Hadoop build process will load various dependencies via Maven instead of using distribution-supplied packages. Java projects like this are unfortunately not easy to package because of interdependencies; and unfortunately the Hadoop stack is full of odd dependencies…
Who still uses Hadoop anyway? https://spark.apache.org/ https://www.iguazio.com/data-science-post-hadoop/
Spark is worse because you need Scala as well as regular Java.
I've tried building it for my day job, I would rather have a colonoscopy without sedation.
It's more pleasant and dignified.
Re: The sad state of sysadmin in the age of containers (2015)
#49Standard Makefiles are really under appreciated today. They are simple and can be used with most any language, version controlled and have been around for decades.
Re: The sad state of sysadmin in the age of containers (2015)
#50I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…
I don't think it's specific to just younger devs, but there absolutely is an argument for having your own artifact repository that you can control.