Running NTP inside docker
Note to self on running NTP in Docker
NTP needs to be able to set the kernel time. You have three options:
- Run it with the `–privileged` flag
- Run it with CAPTIME set
- Run it as an isolated orphan zone (this is difficult)
If you're not a developer, it's fine not to use virtualenv
It's actually OK to not use virtualenv
Despite what you may read, there is absolutely no reason for a systems administrator to use virtualenv to install a utility written in Python.
Virtualenv is for developers
Virtualenv is for people writing, not using, Python programs. Want nikola? apt-get install nikola. Want ansible? yum install ansible. There's no need to create an isolated environment for these applications if you're just going to use them, only if you're building with them.
But won't I miss out on the newest version of py-foo?
Yes! You are fortunate that you will. It probably is broken. The good people at Debian and Fedora and Arch and Gentoo and… go to a lot of effort to make a collection of software (including Python utilities) that isn't broken, and if you insist on using virtualenv, you're only going to duplicate that labor.
Now, if you're a programmer, and you are using Python to make software, virtualenv can be great. You can develop against multiple versions of Python and the Python packages that seem to spew forth from pypi like so many meth-addled chipmunks.
Admins have a responsibility to manage stacks
So, really, that's what it comes down to: it's your job to manage stacks, so you need to do that.
And they still can't admit LibreOffice exists
Apache finally mentions abandoning OpenOffice
What they simultaneously fail to mention is the existence of LibreOffice or any possibility of handing over their trademark to them.
Some choice quotes from their last board meeting:
The buildbot for Windows binaries has not been successful since 2015-07-28.
Proof of concept for digital signing of Windows builds was achieved in 2014. Signing is not in production.
Nano has gone back to GNU
We dreamt we were tigers
They have also (finally) made Shift + Cursor select, and it works on 1x1 (?) terminals.
Nano isn't really something I use much (though it's the default $EDITOR on Debian, IIRC, so I'll often use it to visudo and set $EDITOR to something else). I wonder if in practice the re-homing to GNU will make much of a difference in terms of resources.
Trying OpenBSD 6.0
OpenBSD 6.0 is out
OpenBSD 6.0 is out. I had been following -current recently and liked a lot of what I saw so I gave it a try.
XHCI support is much better; 5.9 actually hadn't been installable on my laptop because its USB wasn't recognized (also because its eMMC disk wasn't recognized). ACPI support is signifcantly better. But the biggest news seems to be that WX is enforced by default (this wasn't the case in current a few weeks ago). It will be very interesting to see how that affects things.
What I like
Just a list of small things I like about OpenBSD as it is now:
- Good EFI support
- Volume hotkeys work both on the console and in X11
- It ships with nvi and pdksh
- OpenSMTPD is great
- OpenHTTPD is also great, and will be even better when they get SNI working
What I didn't like
It's interesting the little foibles that will keep you from using a system. In my case, what I didn't like was the fact that the installer hung on makedev. So I had to install the boot system myself. Small irritation, but I doubt I'll use it after this.
The Dropbox SNAFU
Nearly 70 million password hashes and emails were exposed
It's not good. (BTW, Silicon Republic, his name is "Troy Hunt", not "Troy Hunter".)
The issue here is not just the size of the breach, which is historic, but also the length of time it went either undetected or unannounced: four years. For four years these email addresses and hashed passwords have been floating around God knows where. SilRep claims (I can find no sourcing) that in 2012 Dropbox sideband contacted a group of users with credentials exposed in other breaches, but did not reveal the extent of the problem (if they in fact knew).
Motherboard (second link) broke the story after obtaining a portion of the payload from a contact in the (ahem) "database trading community". This came just days after Dropbox forced a mass password change for presumably similar reasons. The question remains open whether somebody had been sitting on these out in the darkweb somewhere, or whether Motherboard was motivated to go find something after Dropbox made its announcement.
The salt is apparently safe for the SHA1s
Hunt confirms the breach. He also adds that the passwords were unequally protected. Roughly half were salted and hashed with SHA1; the rest were salted and hashed with bcrypt. The bcrypt salts were exposed, and the SHA1 salts were not (at least not in the material Motherboard and Hunt got their hands on). As he points out, a salted SHA1 without the salt available (and, hopefully, also without it being predictable) is not terribly useful to an attacker. That said, an email address is always useful, so there's that.
This seems to have been because of password reuse
And now for the fun part: blame. That's right: a DropBox employee reused a password that he had used on… LinkedIn. On the plus side, DropBox claims it now requires password managers and 2FA on all internal systems (you do too, right?).
Starting a new job next week
I'm starting the blog over
So, as a bit of housekeeping, I intend for the scope of this blog to be whatever thoughts I come up with on systems administration at my new job. I have had a pendulum over the years between "put everything into one blog" and "break out different blogs for different subjects", and it's swung more to the latter right now.
I would like to update this regularly
I'm putting this out there to try to help me commit to this: I want to update this daily. I'm using orgmode both to keep day-to-day notes and to write this blog (with some help from nikola) which I hope will help me keep this integrated into my workflow.
On that note, I'm doing a half-hearted "live in emacs" challenge to myself. The new workplace uses hipchat (and of course email) so I'll be testing the various ways emacs can integrate those activities. For hipchat I'll be looking at both jabber.el and ERC with the IRC gateway. For email I've gotten used to gnus, but I may just use fetchmail and rmail for work email for better notifications (gnus's lack of good notifications is a problem I keep trying to fix).
I will probably destroy it eventually
As always, don't expect anything on a blog of mine to stay up for any particular amount of time.
My new job is Linux-heavy
On to the employment news! I'll be starting on the 6th at a tech company in Reston. I'm looking forward to it for several reasons. It's employment, firstly. Secondly, a friend of mine works nearby. And finally the work itself seems interesting: it's largely management of Linux servers.
It's a good step
This is a good career step for me because I was worried about being dragged back in to the vortex of managing Windows systems. This is an established company with a pretty good reputation in the field, so this will be a step up. It's largely an engineering firm, which also interests me.
It's also a commute
Now, the downside: it's in Reston (actually I think technically in Herndon). We're going to have to get a car, realistically, but until then I can do the Metro-to-bus dance which should take about an hour or a little more each direction. C'est la vie.
The servers are apparently mostly CentOS, which is fine. It's mostly 5 and 6, which means systemd won't quite have reared its ugly head yet (obviously that will change pretty quickly, most likely).
And it's a lot of Python
And, in other good news, this is a shop that has pretty much entirely avoided PHP and Ruby. Also Perl, which is a shame because I prefer it to Python. But, this is a good chance to dust off my Python which has lain, python-like, in slumber for a few years.
The founder and I talked about Forth and Lisp in the interview, which was also a good sign. I'm a very firm believer in language-agnostic hiring (there's very little to actually learn about any programming language). So, yeah, some Flask is in my future.
It's also a lot of virtualization and containers
It's 2016, so this shouldn't be surprising. The engineers produce turnkey servers for clients, and that involves a lot of virtualization for testing and development. So it's a lot of docker and a lot of Xen or KVM.
I'm not happy with the state of containers right now
I'll be talking about this more, but I'm not happy with the state of containers right now. Docker doesn't have any specific problems with its engineering (at least no more than anything else does), but it leads to some bad habits, like 4 different versions of Python being used in the same project. Docker makes that less painful, but is that a good thing?
As I said in my interview, "Docker is the best-available tourniquet for the self-inflicted wound of poor stack management". But it's hard to avoid.
But the state of virtualization is good
In better news, I like the state of full virtualization right now. Xen is still my favorite (and fortunately it's the default in CentOS), but KVM is really improving. And, better news, there doesn't seem to be any ESXi in this job (not that I particularly dislike ESXi, but this is a good chance to expand to other things).