![\"\"](\"https:\/\/lowtek.ca\/roo\/wp-content\/uploads\/2021\/07\/clapper-take2.png\")
<\/p>\n<\/p>\n
My past two posts have been the hardware setup<\/a> and pi-hole deployment<\/a>. You rarely get things right the first time and this is no exception.<\/p>\n I’ve already added an update to the first post about my nullmailer configuration. I had forgotten to modify You may also want to go look at \/ clean out the Once corrected, I started to get a bunch of emails. They were two different errors both triggered by visiting the pi-hole web interface<\/p>\n The first issue is a bit curious. Let’s start by looking at the Then if we look at the static configuration that was created by the pi-hole install in Decoding the interaction here. The pi-hole setup script believes that we should have a static IP and it also has assigned the pi-hole to use DNS servers that are the same DNS servers that I specified as my custom entries for upstream resolution.<\/p>\n This feels like the pi-hole install script intentionally makes the pi-hole host machine not able to do local DNS resolutions. I wonder if all pi-hole installations have this challenge. I asked on the forum,<\/a> – and after a long discussion I came to agree that I fell into a trap.<\/p>\n A properly configured linux machine will have the name from As my network has IPv6 as well, the pi-hole also gets an IPv6 DNS entry. Since the static configuration doesn’t specify an upstream IPv6 DNS – the ULA<\/a> for the pi-hole leaks into the configuration. This is a\u00a0 potentially scary DNS recursion problem, but it doesn’t seem to be getting used to forward the lookup of ‘myhost’ to the pi-hole so I’m going to ignore this for now.<\/p>\n And easy fix is to go modify Where This will fix the first problem, and it seems the second problem was also caused by the same unable to resolve myhost. I think this is exactly what this post<\/a> was describing when it was seeing the error messages. This is another thread<\/a> and different solution to a similar problem.<\/p>\n Satisfied I’d solved that mystery, along the way I’d also created a list of things to ‘fix’<\/p>\n The rest of this post is just details on these 6 changes.<\/p>\n <\/p>\n 1. Ditch rsyslog remote<\/strong><\/p>\n I setup rsyslog because I wanted to get logwatch to run over my logs and avoid yet another daily automated email arriving. Unfortunately logwatch combined with rsyslog wasn’t giving me any separation of what was happening where. On one hand, seeing all of the sudo actions in one place is useful, but not knowing where they happened was a problem.<\/p>\n Rsyslog appears to only be forwarding logs sent through the system (auth, kern, mail, syslog) which is useful – but all of the other log files such as Turning this off is as easy as removing the configuration file I had added to 2. Run logwatch locally<\/strong><\/p>\n Just install it.<\/p>\n Now we’ll get nightly reports in email via nullmailer.<\/p>\n 3. Run fluent-bit locally<\/strong><\/p>\n While fluent-bit does document installing the agent on the Raspberry Pi<\/a>, these instructions are for the Raspbian distribution only.<\/p>\n I’m using Ubuntu, so need to follow the instructions for Ubuntu<\/a>. Thankfully there is an arm architecture build of the agent.<\/p>\n Now that the agent is installed, we need to modify the The default file just adds some CPU metrics. We’re going to remove those and replace with the following<\/p>\n The input section uses the tail plugin. This watches files and forwards as log data any new data appended to those file patterns. The Tag helps match up INPUT and OUTPUT sections, as you can have multiple of each and they don’t all have to connect. The Path_Key is used to pass along a useful label to the Loki backend, labels are a Loki concept.<\/p>\n This of course assumes we have an instances of Grafana Loki running (as I do). There are plenty of other log destinations you could choose.\u00a0 Fluent-bit supports many output plugins<\/a>, heck we could have even targeted rsyslog<\/a>.<\/p>\n Once the config file is ready:<\/p>\n \u00a04. Password-less sudo<\/strong><\/p>\n Simply add the following to the end of the \/etc\/sudoers file<\/p>\n The ‘safe’ way to do this is visudo<\/a> because it provides some checking to ensure you don’t lock yourself out.<\/p>\n 5. SSH key only access<\/strong><\/p>\n This is a two part process. We need to create a ssh key and install it to allow key based ssh. The GitHub doc<\/a> on this is actually pretty good.<\/p>\n Once you’ve got a key pair (private\/public) copy the contents of the public (.pub) file into the The private key belongs in the .ssh\/ directory of the client machine (your laptop). Details on this will vary.<\/p>\n It’s a good idea to confirm that the key is working – plenty of ways to do this, but Now we go and change\u00a0 \/etc<\/span>\/ssh<\/span>\/sshd_config to disable passwords.<\/span><\/p>\n To test this, temporarily move your key such that ssh can’t find it – you should get rejected. Attempts to connect without the key will show<\/p>\n 6. Add mosh<\/strong><\/p>\n Mosh<\/a> is a great enhancement to your ssh experience. It provides a persistent shell connection even with intermittent networks. What this means is that when you close your laptop and it goes to sleep, you don’t have to reconnect that ssh session.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" My past two posts have been the hardware setup and pi-hole deployment. You rarely get things right the first time and this is no exception. I’ve already added an update to the first post about my nullmailer configuration. I had forgotten to modify \/etc\/mailname and thus a lot of the automated email was failing. I … Continue reading “Pi-hole Ubuntu Server (take 2)”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,12,20],"tags":[],"class_list":["post-1839","post","type-post","status-publish","format-standard","hentry","category-computing","category-how-to","category-pi-hole"],"_links":{"self":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1839","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/comments?post=1839"}],"version-history":[{"count":6,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1839\/revisions"}],"predecessor-version":[{"id":1847,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1839\/revisions\/1847"}],"wp:attachment":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/media?parent=1839"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/categories?post=1839"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/tags?post=1839"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\/etc\/mailname<\/code> and thus a lot of the automated email was failing. I happened to notice this because my newly deployed pi-hole was getting a lot of reverse name lookups for my main router, which were triggered by the email system writing the error.<\/p>\n\/var\/spool\/nullmailer\/failed<\/code> directory, it likely has a bunch of emails that were not sent.<\/p>\nmyhost : Jul \u00a04 08:14:10 : www-data : unable to resolve host myhost\r\nmyhost : Jul \u00a04 08:14:10 : www-data : problem with defaults entries ; TTY=unknown ; PWD=\/var\/www\/html\/admin ; USER=root ;<\/pre>\n
\/etc\/resolv.conf<\/code> file which is a generated file based on the DHCP configuration.<\/p>\n# Generated by dhcpcd from eth0.dhcp, eth0.ra\r\n# \/etc\/resolv.conf.head can replace this line\r\nnameserver 149.112.121.30\r\nnameserver 149.112.122.30\r\nnameserver fea4:decf:1667::8\r\n# \/etc\/resolv.conf.tail can replace this line<\/pre>\n
\/etc\/dhcpcd.conf<\/span><\/code><\/p>\ninterface eth0\r\n static ip_address=192.168.1.1\/24\r\n static routers=192.168.1.10\r\n static domain_name_servers=149.112.121.30 149.112.122.30<\/pre>\n
\/etc\/hostname<\/code> also reflected in \/etc\/hosts<\/code> (as I have done). My setup was working fine because the DNS service on my OpenWRT<\/a> router was covering up this gap. While it’s nice that it just worked, the machine should really be able to resolve its own name without relying on DNS.<\/p>\n\/etc\/hosts<\/code><\/p>\n127.0.0.1 localhost myhost\r\n\r\n# The following lines are desirable for IPv6 capable hosts\r\n::1 ip6-localhost ip6-loopback\r\nfe00::0 ip6-localnet\r\nff00::0 ip6-mcastprefix\r\nff02::1 ip6-allnodes\r\nff02::2 ip6-allrouters\r\nff02::3 ip6-allhosts<\/pre>\n
myhost<\/code> is whatever appears in \/etc\/hostname<\/code>.<\/p>\n\n
\/var\/log\/pihole.log<\/code> were not being transported.<\/p>\n\/etc\/rsyslog.d<\/code><\/p>\nsudo apt install logwatch<\/pre>\n
# Add the key\r\ncurl https:\/\/packages.fluentbit.io\/fluentbit.key | sudo apt-key add -\r\n\r\n# Add the Ubuntu source list - create a file in \/etc\/apt\/sources.list.d\r\necho \"deb https:\/\/packages.fluentbit.io\/ubuntu\/focal focal main\" > \/etc\/apt\/sources.list.d\/fluent-bit.list \r\n\r\n# Update apt\r\nsudo apt update\r\n\r\n# Install td-agent-bit\r\nsudo apt install td-agent-bit<\/pre>\n
\/etc\/td-agent-bit\/td-agent-bit.conf<\/code> configuration file.<\/p>\n# We leave the top part of the agent config file alone\r\n# The bit we will replace are the INPUT and OUTPUT sections\r\n\r\n[INPUT]\r\n # tail all host logs\r\n name tail\r\n Path \/var\/log\/*.log,\/var\/log\/*\/*.log,\/var\/log\/syslog,\/var\/log\/lastlog,\/var\/log\/faillog\r\n Tag host.*\r\n Path_Key filename\r\n\r\n[OUTPUT]\r\n Name loki\r\n Host 192.168.1.35\r\n Match host*\r\n Labels host=myhost, $filename<\/pre>\n
# enable the service\r\nsudo systemctl enable td-agent-bit.service\r\n\r\n# start the agent\r\nsudo systemctl start td-agent-bit.service\r\n\r\n# check that things are all ok\r\nsudo systemctl status td-agent-bit.service<\/pre>\n
# no password sudo for user myid\r\nmyid ALL=(ALL) NOPASSWD:ALL<\/pre>\n
.ssh\/authorized_keys<\/code> file on your pi-hole.<\/p>\nssh -v<\/code> is a good way to check.<\/p>\n\n# Change to no to disable tunnelled clear text passwords\r\nPasswordAuthentication no<\/pre>\n<\/div>\n
Also don’t forget to restart sshd so the changes take affect<\/div>\n<\/div>\n\nsudo systemctl restart sshd.service<\/pre>\n
ssh user@myhost\r\nuser@myhost: Permission denied (publickey).<\/pre>\n<\/div>\n
# Install mosh - you will not regret this\r\nsudo apt install mosh<\/pre>\n