Tuesday 30 October 2018

Working with DNS settings in systemd-resolved in Ubuntu

In troubleshooting some DNS name resolution issues I started to get more familiar with systemd-resolved in Ubuntu. Specifically if you look at the traditional /etc/resolv.conf file it says something like this:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
Hah hah! Subtly clever for any old hands in networking because "53" is the standard DNS port so 127.0.0.53 is a little clue to look for something specific.

Go ahead though - run "systemd-resolve --status", it doesn't require root, and it shows you a lot of info (the IPs of name servers have been change to protect the innocent...)
localadmin@ca-yvr-adm2:~$ systemd-resolve --status
Global
         DNS Servers: 10.1.1.11
                      10.2.2.12
          DNS Domain: sub.example.com
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      <snip>
                      local

Link 1 (eno1)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

The config file is easily found in "/etc/systemd/resolved.conf" and it's quite short and simple and it should look familiar if you have used other systemd configurations before. The configuration out-of-the-box will be blank with all options commented out. I wanted to add additional search domains to the Domains line, in the same space-delimited way you would traditionally do the search line in your resolve.conf.
[Resolve]
#DNS=
#FallbackDNS=
Domains=sub.example.com example.com example.local
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

Restart the same as you would any other systemd tool, and then re-check your resolved status
sudo systemctl restart systemd-resolved.service 
systemd-resolve --status

OR check your /etc/resolve.conf file because if your only change is to modify the search domains, it also appears there for the resolver to work normally.
Global
         DNS Servers: 10.1.1.11
                      10.2.2.12
          DNS Domain: sub.example.com example.com example.local
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      <snip>
                      local

Normally you would be done... Here's a couple bonus tricks that may arise.

You can modify DNS settings by interface - furthermore this is handy for testing DNS changes and reverting before making the change in the config file. Check out systemd-resolve --help 

The multicast service may conflict with a .local domain. The symptom I had was that I could resolve a short name like "pc" but could not resolve an FQDN like "pc.example.local". If you are using .local and finding odd DNS resolution results, edit your nsswitch.conf  and move "dns" earlier than the mdns (keep it after "files" though to avoid breaking your hosts file).

I've tried to make this a quick and useful blurb on how to use systemd-resolved and get pointed in the right direction because the documentation available wasn't simple for simple cases - there is certainly a lot of tuning you can do with the resolver tools.

Ciao

Wednesday 3 October 2018

Archiving Files (E.g. Deleting Stuff) is My Super Power!

This week one of the things I was working on was archiving a lot of files on a file in order to prune it down ahead of migrating that share to a new location.

In particular this share while only ~100GB has > 3M files on it! Any basic operations like checking folder sizes, applying ACLs, etc are very slow on xM files. Looking at the share with WinDirStat I found that there's a large number of folders each with 20-50K files in each. Furthermore the majority of these files were old (years) and not actively used so we decided to Archive (e.g. Delete) the contents of these folders.

I started by using 7-Zip and there's an option on the Add to Archive screen to "Delete files after compression":


And that's pretty good! ... But not if you've got hundreds of folders to process.

Instead, with a bit of PowerShell, we invoke 7-Zip from a script and use the -sdel switch to remove files after they've been archived. This PS we used to simply to stuff each sub-folder into an archive.

Get-ChildItem . -Directory |  ForEach-Object  {
 $Archive = $_.Name + ".zip"
 $Folder = $_.Name + "\"
 &"C:\Program Files\7-Zip\7z.exe" a $Archive $Folder -sdel
}
Pow!

Thursday 16 August 2018

Let's Encrypt on Blogger

I can't say I fiddle too much with the settings in Blogger, it's kinda "set it and forget it" stuff BUT sometime I think recently the team made it so you can enable SSL certs for custom domains on Blogger and it signs up a cert for you and everything.

https://support.google.com/blogger/answer/6284029?hl=en

In short it's so stupid simple just go do it and do it now

  1. Go to basic settings 
  2. Change HTTPS to Yes
  3. Are we done yet? Why yes, yes we are.

Optionally once the cert has generated (it's not instant) you can also turn on redirect to SSL which again, why not? It's just the next tick box


This is how security should work; it works and its easy. I guess it could be on by default and pushed out but really, just click "security activate!"

Ciao

Popular Posts