Year: 2017

Returning a Nexus 5 to ‘stock’, including re-locking bootloader

Hmm, I had a bunch to say about used phones and my history with different models, skip to about halfway down to find the actual details on returning a phone to stock.

It’s interesting to look back over my personal smartphone ownership history. All of them have been purchased ‘used’ but some were barely used, where others saw heavy use. For the most part I’ve not had any real problems with the phones, but there have been a few exceptions. My price point has generally been under $200, but I’ve scored a few at the $150 mark too.

Resale of the phones hasn’t been a strong point of mine, I usually keep them (sometimes idle on my desk) to the point where I’m getting less than half what I paid for them. Still I think I’m ahead in terms of the diversity of the phones I’ve had, and my total layout in cost.

The Nexus 4 was a great phone for me, I used it for almost 2 years before swapping to a Nexus 5. It wasn’t without problems, something went wrong with the charging circuitry (part of the motherboard) and it was destroying batteries by mis-charging them. I went through a couple aftermarket batteries before finding a donor phone that had a good motherboard.

I flipped the donor phone with now bad motherboard and ended up $20 out of pocket to fix my Nexus 4. I ran with this fixed phone for nearly another year.

In the Nexus 4 ownership phase, I ended up having Jenn switch from iOS to Android, and so I started getting 2 of the same phone. Late in 2016 the Nexus 5 (32GB) came below the $200 price point. I ended up buying 3 within the span of a couple of weeks.

Of the 3 Nexus 5’s, it turns out one of them had something wrong with it. After a little while that bad phone started to randomly reboot, and sometimes even turn itself off and refuse to power back on. You could get it back, but had to fiddle with it for some time. I ended up taking this phone and using it as my daily driver to see if I could isolate and fix the issue. It felt like it might have been the very common power button problem, but a local repair shop didn’t think it was. Instead of trying to fix it myself, I just upgraded to the Moto X Play and sold the bad Nexus 5 (with full disclosure on it’s issues) as a parts phone for $50.

Oh yeah, and that gets us to the returning to stock story..

Continue reading “Returning a Nexus 5 to ‘stock’, including re-locking bootloader”

Server Upgrade Part 5: rsyslog

Now that mail is running in a container, logwatch is a lot less interesting because log data is not visible on the host (the container has the logs). One option is to map the log files from the container into the host logs, but this might get messy. It seems like a better idea to build out an rsyslog setup to flow logs from the container into the host.

To start with I needed to understand rsyslog a bit better. Then I came across a post that does pretty much what I’m trying to accomplish, docker containers sending logs to the host with rsyslog.

Before we configure the container, we need to get our host machine accepting rsyslog input. We’ll need to turn on one of TCP or UDP remote access on the host. I’ll stick with just TCP for my initial setup.

Edit /etc/rsyslog.conf, you’ll find a comment near the top about TCP reception, uncomment the pair of lines below it

and then restart the service to pick up the new config

I’m using a firewall on the host so I’ll also have to open up the firewall so that things can see this new port. When we do firewall stuff, we should always pause and think about the security implications here.

In my case, the machine that has the port open will be behind my router, which also runs a firewall. So while we’re punching a hole in the firewall, we actually have another firewall protecting us from the big bad internet.

At this point our host machine has rsyslog running and waiting for traffic. Now let’s take a look at the mail server container and change it to flow logs to the host rsyslog.

It turns out the client is really easy, but you do have to be aware of UDP or TCP.  Inside the container – we modify our Dockerfile to create an /etc/rsyslog.d/10-rsyslog.conf file that looks like:

If you are using TCP, use both @@ – for UDP just a single @. You also need to use the actual hostname of the host machine (the one we configured with rsyslog just above). We need rebuild and restart the container to activate the rsyslog configuration.

Back on the host, we see data showing up with the container hostname in the logs. If we look on the host machine in /var/log/syslog we see rsyslogd startup from the mail container:

 

There are plenty of other log messages related to the mail container start up as well.

We could manually emit some log messages from the client inside the container, by shelling into the container and running logger.

and in /var/log/syslog on the host we see..

Logwatch should be a lot more interesting

Server Upgrade Part 4: systemd and docker containers

I’ve set the BIOS on the new server to resume running after a power failure. The OS happily comes back no problem, and docker even starts up – but none of the containers.

Apparently in docker 1.2 there is now support to restart your containers after boot, this sounds useful, but the version of docker in Ubuntu 16.04 is 1.12.1, close but not quite recent enough.

No worries, we can use systemd to sort this out. The docker documentation has some examples, but I found an article which takes a slightly different approach – one they claim is more aligned to CoreOS.

Adding our own services to systemd is simply a matter of adding a file to /etc/systemd/system/. The very first one I want to add is one to host my own registry. Now you probably don’t want to host your own registry since you could simply use the public dockerhub, or any number of other solutions. However, I’m also the type of person who hosts their own email, so of course I’m going to host my own registry.

The %n in the file is replaced with the ‘full unit name’. If we save this file as /etc/systemd/system/docker-registry.service the unit name should be docker-registry.

In a simple configuration, the local docker registry will persist data as a docker volume. I decided it was safer to map to a local file tree.

Once you’ve created the file /etc/systemd/system/docker-registry.service we need to reload the systemd daemon and start the service.

If all has gone well, docker ps should show us the new running registry (it does). Now let’s make it start every boot.

And yup, a reboot and we see the registry has started. So now we have a local registry to store our containers in, and a pattern to apply to make them services that start even after a reboot (expected or unexpected).

Pushing images to a local registry is covered in the documentation. I might later want to add a certificate to the registry, but it is not required.