Fixing DNS problems on Ubuntu 16.04 (zesty)

free software,linux,ubuntu — 29. Oct 2017

Last Saturday, one of our laptops running Ubuntu 16.04 zesty suddenly couldn’t get on the Internet anymore. It connected to the router and could ping IPs, but DNS lookups failed, so no browsing was possible. After researching online, I found out that Ubuntu changed to a new type of DNS resolver (systemd-resolved) in zesty, and this causes issues for some people. It seems we were affected by this, although i have absolutely no idea why the problem surfaced when it did after working just fine for weeks after upgrading to zesty.

Anyway, here are the instructions that ultimately fixed the problem:

  1. find out the current IPs of your ISP’s DNS servers (log in to your router, check tab Internet)
  2. edit resolved.conf

    sudo nano /etc/systemd/resolved.conf

    in the section [Resolve], add the DNS server IPs

    DNS=194.11.55.96
    FallbackDNS=212.22.37.130

    then save and exit.

  3. restart the services with:
    sudo systemctl restart systemd-resolved

    sudo service network-manager restart

two small git tips

the impact of git and github in the programmer community continues to amaze me. it appears that almost all major open source projects have made the switch to git at this point. naturally, i got interested too and started using git for my latest software project. however, coming from subversion, i found it not that convenient at first. here are two small tips that helped me become more comfortable with git, effectively making it behave more like subversion.

shorter status messages
the first one is about the status command. i find the default output of git status overly verbose. luckily, there is a more concise version: git status -s (for “short”). its output looks similar to the output of what you get from subversion. run the following command to configure git to always show the short status report:

git config status.short true

commit in one command
the second tip concerns the committing of changes. the normal workflow of making changes and committing them to the repo requires only two steps with subversion (modify a file, commit), while we need three steps with git (modify file, stage (“add”), commit). it seemed unnecessary and inconvenient having to issue separate stage and commit commands for the same action that required only one step in subversion. while there may be good reasons why git keeps those two steps apart, i wished for a shortcut. and in fact, there is one. if you use commit with the -a option (for “all”), it will directly commit all changes without the need for staging them first. a typical command may look like this:

git commit -am "implemented XY"

with these two measures, i found git to be much more usable.

‘locate’ on ubuntu with an encrypted home dir

free software,geeky,linux,ubuntu — 5. Oct 2011

recently, i noticed that the locate command on my ubuntu system didn’t work as expected. it simply didn’t list files located in my $HOME dir, while it did still list files in the system directories. it took me a while to figure out that this behaviour was due to the fact that i decided to check the “encrypt home dir” option when i last (re-)installed the OS.

on second thought, it makes sense that it works that way, since the command to update locate‘s database (updatedb.mlocate on ubuntu) is run as a root cronjob, and as such it can’t access the filesystem while it’s encrypted. on the other hand, understanding this requires quite a bit of prior knowledge about how locate works, and i think it’s a bit rough to let the users figure this out all by themselves, without as much as a warning. the situation would be much improved if locate would at least spit out a warning that it can’t access the home dir, instead of the ominous silence, from which we usually conclude that no matching files exist on the disk.

after some googling, i found a good solution for this problem. this guide explains how to set up locate to store a separate, user-specific database inside the encrypted home directory. this also requires a user-specific cronjob. after following that guide, locate once again works just as expected on my system.