Uh... I've built Hadoop from source, it is not that bad.
I've also built it from source, admittedly back in 2012. It wasn't that bad, either! My concerns were building an AMI image, not "packaging" it in a more traditional sense.
The sad state of sysadmin in the age of containers (2015)
161–170 of 324 posts
Re: The sad state of sysadmin in the age of containers (2015)
#162Earlier quoted context omitted.
Don't turn it into an ageist thing, unless you are particularly old, there will be plenty of older developers that also don't understand this. It largely comes from understanding _why_ reproducibility is a good thing, and there are _lots_ of open source maintainers that understand this that are likely "younger than you". The vast majority of developers though focus on other things, that SQL injection attacks are stil…
It is way bigger then security, and hits upon quality of life and reliability. Without a deterministic build I don't know what I check in actually works across environment, or if the deployment artifact works.
Without a deterministic build I don't know what I check in actually works across environment, or if the deployment artifact works.
Actually that's mostly a given in JS land.
Many bright minds worked hard for it to be this level of idiot-proof.
Re: The sad state of sysadmin in the age of containers (2015)
#163I 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…
> without relying on any third-party servers being available and without pulling in dependencies that might have changed. There are two different issues here: 1. Not pulling in changed dependencies. This is what "lock files" are for: To limit builds to known version of every dependency. npm was terrible about this for a long time. Most other language package managers are better. 2. Not relying on third party servers…
> npm was terrible about this for a long time.
That's putting it lightly. To me "terrible" would mean they just didn't support it, "batshit insane" means they supported lock files but ignored them every time you ran npm install.
My favorite comment from this stackoverflow post: https://stackoverflow.com/questions/45022048/why-does-npm-in...
"Why would you expect something called package lock to lock the packages? Package lock is analogous to how, when you put any key into a door lock, the lock reshapes itself to match whatever key was put in, then opens the door. Now if you'll excuse me, I'm late for a tea party with a rabbit."
Re: The sad state of sysadmin in the age of containers (2015)
#164Earlier quoted context omitted.
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.
Last time I tried to use Artifactory for it's caching it barely worked. Would randomly 404 when a package was not in it's cache yet and you'd end up retrying a CI build for a while until everything was there.
At work I'm running ~2000 builds a day across 14 repos, mix of c# and php.
We're proxying several hundred NPM, composer and nuget packages on 2 artifactory containers running in high availability.
It was a rocky start but about 2 months in everything was pretty stable.
If you're still apposed to artifactory you could try sonatype nexus
Re: The sad state of sysadmin in the age of containers (2015)
#165Earlier quoted context omitted.
Not so obviously as you might think. But, if they are going to do it, they should clearly do it well
Right, but my experience is that Java (and a few others) have succeeded in this space. I actually wish that I could use maven to install system software rather than having to rely on something like apt.
I am intrigued by the experiences you have had which lead you to precisely the reverse conclusion to mine.
Re: The sad state of sysadmin in the age of containers (2015)
#166You've got to look at this in a context where platform package managers like apt are simultaneously 1) platform-specific 2) jealous, insisting that every language has to conform to their way of doing things and 3) fundamentally not very good, having very limited ability to do things like install packages for a single user or install multiple versions of the same package. Platform package managers like maven have been…
Language-specific package managers are also "jealous" as you put it. They insist that every platform conform to their way of doing things. They're also promiscuous, in the sense that most have really poor dependency management ("let's build the internet today just in case") and practically no security. The computing world would be a better place if the people forcing their language-specific idioms on the rest of the world had instead spent their time improving the platform package managers that already existed at the time.
Re: The sad state of sysadmin in the age of containers (2015)
#167I 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 know you're taking some flack for making it about age, but I do think there's some merit there. I'm 34. I feel like I'm in the middle in terms of software developer / sysadmin age. Lots of bright minds came before me and there are lots of bright minds out there right now in their early 20s. A key difference is I can remember a time when network connectivity was flaky. When it was hardly a given. Even when it was av…
I'm 36 and recently was assigned to mentor a new employee in his 20s. We had a moment of miscommunication when I asked him to use git to clone a local repository. He was confused when he couldn't find it on github.com (what I'd sent him was a path to our private network share). I had to explain that, yes you can use the github.com client if you want, but "git" is different from "github". I honestly couldn't tell if he understood the difference.
Now I'm losing sleep worrying if there's any way he can accidentally add a github.com remote to our private repo and push to it. I would be blamed, and I'd have to explain to managers older in turn than me what both git and github are.
Re: The sad state of sysadmin in the age of containers (2015)
#168Earlier quoted context omitted.
If you can build on your distro of choice, you can rely on the same security audit and process. Keep track of the packages you link against and include in your image, and just rebuild your images when a new security update comes along. Then you replace the running one.
See that "keep track" bit? It's expensive unless you build a tool to do it for you -- which is what I said previously.
Pulling the list of security updates is trivial. And during development you'll know what you depend on. Comparing the two in a script is trivial.
But regardless, with containers, it should be a setup where you can rebuild your images daily with all the latest security fixes. Or whenever there is a fix you deem important.
Re: The sad state of sysadmin in the age of containers (2015)
#169This 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…
Trust, but verify.
> `curl | sudo bash` is no different than .\install.exe
.\install.exe runs a binary you already have. If it's windows, you can see if it's a signed binary, and it will prompt you for admin access. If it's not signed, you can compare a signature of it to one you got from a secure source.
`curl | sudo bash` downloads the file from a remote source. The URL isn't listed here; was it http? In that case, now a MITM can modify the file before you run it. If it's HTTPS, that's better, but you still haven't compared it to a signature of the original file, meaning it could have been modified on the download site. And hopefully you're one of the seemingly few users that turn on password prompting for sudo access (and hopefully running it in a new terminal, to avoid an earlier sudo's session...)
So they are different. And containers and VMs are the same: if you can compare checksums before running them, or build them from source, you have confidence that they came from a source you trust. Dockerfiles in particular make rebuilding even more trivial than with source Linux packages, so there's not much reason to fret.
Re: The sad state of sysadmin in the age of containers (2015)
#170Earlier quoted context omitted.
There’s a pretty straightforward solution to this problem which is to run your own NPM server even if it’s only a caching proxy. For some orgs, the uptime provided by the third party servers is sufficient.
Having been at 3 companies that did this, I can say with certainty that our caching proxies (artifactory in all of them) were much more likely to go down than the public repos were.
Yes, but at least in that case you have the fallback of the public repos.