245 lines
17 KiB
XML
245 lines
17 KiB
XML
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
|
|
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
|
|
<channel>
|
|
<title>Linux on Joel Beckmeyer's Blog</title>
|
|
<link>https://beckmeyer.us/tags/linux/</link>
|
|
<description>Recent content in Linux on Joel Beckmeyer's Blog</description>
|
|
<generator>Hugo -- gohugo.io</generator>
|
|
<language>en-us</language>
|
|
<managingEditor>joel@beckmeyer.us (Joel Beckmeyer)</managingEditor>
|
|
<webMaster>joel@beckmeyer.us (Joel Beckmeyer)</webMaster>
|
|
<lastBuildDate>Mon, 22 Mar 2021 11:00:00 -0400</lastBuildDate><atom:link href="https://beckmeyer.us/tags/linux/index.xml" rel="self" type="application/rss+xml" />
|
|
<item>
|
|
<title>Moving Back To OpenSSL</title>
|
|
<link>https://beckmeyer.us/posts/moving_back_to_openssl/</link>
|
|
<pubDate>Mon, 22 Mar 2021 11:00:00 -0400</pubDate>
|
|
<author>joel@beckmeyer.us (Joel Beckmeyer)</author>
|
|
<guid>https://beckmeyer.us/posts/moving_back_to_openssl/</guid>
|
|
<description><p>Void Linux <a href="https://voidlinux.org/news/2021/02/OpenSSL.html">recently announced</a>
|
|
that they were going to move back to OpenSSL after originally <a href="https://voidlinux.org/news/2014/08/LibreSSL-by-default.html">switching to
|
|
LibreSSL in 2014</a>.
|
|
It seems that there are a lot of things at play here.</p>
|
|
<p>It seems that the main focus of the recent announcement is on the maintainability
|
|
and other difficulties of not using the <em>one true SSL/TLS library</em>. To me,
|
|
this pragmatically makes sense. However, every time something like this happens
|
|
I get this lingering feeling of worry&hellip;</p>
|
|
<p>Microsoft moving their default browser from their own implementation to
|
|
Chromium, and other browsers following suit.</p>
|
|
<p>Linux distributions moving <em>en masse</em> to <strong>systemd</strong>.</p>
|
|
<p>Distributed email being slowly crushed and killed by Google with GMail.</p>
|
|
<p>And many other examples that aren&rsquo;t immediately coming to mind.</p>
|
|
<p>I think it&rsquo;s great that OpenSSL as a project has made a comeback from the
|
|
Heartbleed fiasco, and that it is apparently more actively developed nowadays,
|
|
but the fact that we are even at the point of moving back to OpenSSL due to
|
|
difficulties with building software is worrying. To me, it looks like a
|
|
symptom of software becoming too entrenched and dependent on a single piece
|
|
of software.</p>
|
|
<p>This kind of accusation coming from anyone is going to be hypocritical, since
|
|
we all depend on Linux, X11, Wayland, systemd, or some common piece of software
|
|
that we take for granted and don&rsquo;t lose sleep over. However, I think what&rsquo;s
|
|
categorically different about this one is that an alternative was adopted,
|
|
worked on, but eventually &ldquo;failed&rdquo; (at least for Void, but also possibly for
|
|
Linux as well).</p>
|
|
<p>I don&rsquo;t know what the fix for this specific issue would be. I&rsquo;m not nearly
|
|
familiar enough with SSL/TLS or how you would develop software to be agnostic
|
|
of dependencies like this. But I think in order to honor principles like
|
|
the Unix philosophy, the KISS principle, and countless others, we need to
|
|
figure out a way to be more modular for dependency issues like this.</p>
|
|
</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>OpenWRT + Unbound + adblock</title>
|
|
<link>https://beckmeyer.us/posts/openwrt_plus_unbound/</link>
|
|
<pubDate>Fri, 05 Feb 2021 19:03:15 -0500</pubDate>
|
|
<author>joel@beckmeyer.us (Joel Beckmeyer)</author>
|
|
<guid>https://beckmeyer.us/posts/openwrt_plus_unbound/</guid>
|
|
<description><p>I decided to do some work on my Linksys WRT32X running OpenWRT to make it a
|
|
little more useful.</p>
|
|
<p><a href="https://nlnetlabs.nl/projects/unbound/about/">Unbound</a> is a DNS
|
|
resolver which I like because it&rsquo;s recursive, meaning it directly queries the
|
|
root servers instead of relying on existing DNS servers run by Google,
|
|
Cloudflare, your ISP, or the like. I already have it running on several of my
|
|
servers and computers, but I figured it would be great if everything on my
|
|
network can use Unbound and be, well, <em>unbound</em> from all of those intermediary
|
|
DNS servers.</p>
|
|
<p>Luckily, OpenWRT already has Unbound packaged, and also has a useful LuCI app
|
|
that goes with it (LuCI is the graphical web interface that comes with OpenWRT).
|
|
All I had to do was install <code>luci-app-unbound</code>, which pulls in all of the
|
|
necessary dependencies to run unbound.</p>
|
|
<p><img src="https://beckmeyer.us/luci_software.png" alt="LuCI: Software"></p>
|
|
<p><img src="https://beckmeyer.us/luci_install.png" alt="LuCI: Install"></p>
|
|
<p>After that finished installing, I
|
|
refreshed LuCI/OpenWRT and went to &ldquo;Services&rdquo; on the top, and there it is!</p>
|
|
<p><img src="https://beckmeyer.us/luci_services.png" alt="LuCI: Services -&gt; Recursive DNS"></p>
|
|
<p>At this point, you&rsquo;ll have to get your hands dirty. You can either dig through
|
|
some LuCI menus or SSH in and make some edits. For reference, I&rsquo;m using
|
|
<a href="https://github.com/openwrt/packages/blob/openwrt-19.07/net/unbound/files/README.md#parallel-dnsmasq">&ldquo;Parallel dnsmasq&rdquo;</a> section from the README for unbound in the OpenWRT packages (which
|
|
has a lot of other useful information as well!). Essentially, I made the edits
|
|
to <code>/etc/config/unbound</code> and <code>/etc/config/dhcp</code> after SSH&rsquo;ing in. However, you
|
|
can make the same edits through LuCI.</p>
|
|
<p>For the <code>/etc/config/unbound</code> edits, you can make the edits to the file in
|
|
LuCI directly at &ldquo;Services -&gt; Recursive DNS -&gt; Files -&gt; Edit: UCI&rdquo;:</p>
|
|
<p><img src="https://beckmeyer.us/unbound_config.png" alt="LuCI: Edit /etc/config/unbound"></p>
|
|
<p>For the <code>/etc/config/dhcp</code> edits, you can make the edits by finding the same
|
|
fields under &ldquo;Network -&gt; DHCP and DNS&rdquo;:</p>
|
|
<p><img src="https://beckmeyer.us/dhcp_config.png" alt="LuCI: Edit DHCP and DNS Settings"></p>
|
|
<p>However, the field names are different from the lines in the config, so they
|
|
would need to be researched to determine which fields in LuCI map to which
|
|
lines in <code>/etc/config/dhcp</code>.</p>
|
|
<p>At this point (or maybe after restarting unbound and dnsmasq, which is a lot
|
|
easier using SSH and <code>/etc/init.d ... restart</code> as well), OpenWRT should now
|
|
be using unbound for resolving all DNS lookups, while dnsmasq is only used for
|
|
DHCP-DNS.</p>
|
|
<p>Bonus: you can also enable a nice status dashboard in LuCI under
|
|
&ldquo;Services -&gt; Recursive DNS -&gt; Status&rdquo;, but this requires installing several more
|
|
software packages: <code>unbound-control</code> and <code>unbound-control-setup</code>. You will also
|
|
need to change a line in <code>/etc/config/unbound</code>:</p>
|
|
<pre tabindex="0"><code>...
|
|
option unbound_control &#39;0&#39;
|
|
...
|
|
</code></pre><p>becomes</p>
|
|
<pre tabindex="0"><code>...
|
|
option unbound_control &#39;1&#39;
|
|
...
|
|
</code></pre><p>A word of warning: there is another section on &ldquo;Unbound and odhcpd&rdquo; which
|
|
tries to cut out dnsmasq completely. However, when I tried to set this up,
|
|
I got myself into a lot of trouble (had to reset OpenWRT, re-install any extra
|
|
software packages, and restore configuration from backup). It is also possible that if you mess up
|
|
the configuration for the &ldquo;Parallel dnsmasq&rdquo; method, you could end up in a
|
|
similar error state and have to start over. Please be careful when doing this
|
|
and don&rsquo;t change anything you&rsquo;re not supposed to.</p>
|
|
<p>Now, moving on to adblock, which should be <strong>much</strong> simpler to setup. First,
|
|
install <code>luci-app-adblock</code> and refresh. Navigate to &ldquo;Services -&gt; Adblock&rdquo;:</p>
|
|
<p><img src="https://beckmeyer.us/adblock.png" alt="Services -&gt; Adblock"></p>
|
|
<p>Check the settings at the bottom. The only thing you need to get going is
|
|
to go to the &ldquo;Blocklist Sources&rdquo; tab and choose your blocklists.</p>
|
|
<p><img src="https://beckmeyer.us/adblock_blocklist.png" alt="Adblock: Blacklist sources"></p>
|
|
<p>The
|
|
<a href="https://github.com/openwrt/packages/blob/master/net/adblock/files/README.md">adblock readme</a>
|
|
has some more info on what each list is. After that,
|
|
make sure &ldquo;Enabled&rdquo; is checked under the &ldquo;General Settings&rdquo; tab:</p>
|
|
<p><img src="https://beckmeyer.us/adblock_enable.png" alt="Adblock: enable"></p>
|
|
<p>and click the &ldquo;Refresh&rdquo; button above:</p>
|
|
<p><img src="https://beckmeyer.us/adblock_refresh.png" alt="Adblock: refresh"></p>
|
|
<p>Then you&rsquo;re good to go; adblock should work out of the box with unbound; cheers!</p>
|
|
<p>ADDENDUM: Another word of warning: once you&rsquo;ve setup adblock, it will download
|
|
the blocklists, merge them into a single file at <code>/var/lib/unbound/adb_list.overall</code>,
|
|
and try to restart unbound. I recommend not trying to view/interact with adblock
|
|
or unbound during this restart, which can take anywhere from 30 seconds - 2 minutes.
|
|
Just leave them alone in LuCI for a little bit&hellip;</p>
|
|
</description>
|
|
</item>
|
|
|
|
<item>
|
|
<title>Hello doas</title>
|
|
<link>https://beckmeyer.us/posts/hello_doas/</link>
|
|
<pubDate>Sat, 30 Jan 2021 15:15:55 -0500</pubDate>
|
|
<author>joel@beckmeyer.us (Joel Beckmeyer)</author>
|
|
<guid>https://beckmeyer.us/posts/hello_doas/</guid>
|
|
<description><p>Today, I switched my workstation from <code>sudo</code> to <code>doas</code>. I&rsquo;m running Void Linux,
|
|
and the process was fairly easy.</p>
|
|
<p>First, I needed to figure out how to remove <code>sudo</code> (yes, I realize I could have
|
|
installed <code>doas</code> first, then removed <code>sudo</code>, but I decided to do it the hard way.)
|
|
As it turns out, the <a href="https://docs.voidlinux.org/xbps/advanced-usage.html#ignoring-packages">advanced usage section of the XBPS manual</a> details how to use the <code>ignorepkg</code> entry in xbps.d with nothing
|
|
other than this exact use case! I created the file <code>/etc/xbps.d/20-ignorepkg-sudo.conf</code> with contents</p>
|
|
<pre tabindex="0"><code>ignorepkg=sudo
|
|
</code></pre><p>and then ran <code>sudo xbps-remove sudo</code> (an ironic command).</p>
|
|
<p>After that, because I was stupid and removed <code>sudo</code> before I had set up <code>doas</code>,
|
|
I had to use plain-old <code>su</code> to change to the root user and run <code>xi opendoas</code>. I also
|
|
configured <code>doas</code> in <code>/etc/doas.conf</code> with the following:</p>
|
|
<pre tabindex="0"><code># see doas.conf(5) for configuration details
|
|
permit nopass keepenv :admin
|
|
</code></pre><p>I ran <code>groupadd admin</code>, <code>usermod -aG admin joel</code>, and then logged out so that my
|
|
user account would see the new group perms.</p>
|
|
<p>And just like that, I can now run <code>doas xbps-install ...</code> and all of my other commands,
|
|
just substituting <code>doas</code> for <code>sudo</code>.</p>
|
|
<p>The one thing I immediately missed was <code>sudoedit</code>. Before I accidentally tried
|
|
to use <code>sudo</code> for the first time, I had already accidentally tried to run <code>sudoedit</code>
|
|
<em>at least</em> 5 times. I had to fix this. I saw a discussion on Reddit where <a href="https://www.reddit.com/r/linux/comments/l6y7nv/is_doas_a_good_alternative_to_sudo/gl4hs42?utm_source=share&amp;utm_medium=web2x&amp;context=3">one user
|
|
suggested</a> writing a script to replace the <code>sudoedit</code> functionality.
|
|
I quickly starting hacking together something like that. I started with:</p>
|
|
<pre tabindex="0"><code>#!/bin/sh
|
|
mkdir -p /tmp/doasedit
|
|
doas cp $1 /tmp/doasedit/tmp_file
|
|
$EDITOR /tmp/doasedit/tmp_file
|
|
</code></pre><p>And quickly ran into my first road-block. The script is going to have to change
|
|
the permissions of that file before the user can edit it. But if the script changes
|
|
the permissions, how can I restore it to the original location with the right
|
|
permissions? <code>cp /tmp/doasedit/tmp_file $1</code> won&rsquo;t work. I thought about just using
|
|
cat to overwrite the file contents in-place (<code>cat /tmp/doasedit/tmp_file &gt; $1</code>).
|
|
That <em>could</em> create some issues if a program has the file open. Instead, a better option
|
|
is to create two copies of the file&ndash;one for editing, and one for preserving file
|
|
attributes:</p>
|
|
<pre tabindex="0"><code>#!/bin/sh
|
|
mkdir -p /tmp/doasedit
|
|
doas cp $1 /tmp/doasedit/edit
|
|
doas chown -R $USER:$USER /tmp/doasedit/edit
|
|
doas cp $1 /tmp/doasedit/file
|
|
$EDITOR /tmp/doasedit/edit
|
|
cat /tmp/doasedit/edit | doas tee /tmp/doasedit/file 1&gt;/dev/null
|
|
doas mv -f /tmp/doasedit/file $1
|
|
rm -rf /tmp/doasedit
|
|
</code></pre><p>Of course, the issue with this is that it only works with absolute paths.
|
|
I want to make it work for relative paths as well. I&rsquo;m going to take advantage
|
|
of <code>realpath</code>, which is part of the <code>coreutils</code> package from Void. As a bonus, this
|
|
will also take care of the edge case where the given file is a symlink (IIRC,
|
|
<code>sudoedit</code> didn&rsquo;t follow symlinks, so I may be diverging here):</p>
|
|
<pre tabindex="0"><code>#!/bin/sh
|
|
mkdir -p /tmp/doasedit
|
|
srcfile=&#34;$(realpath $1)&#34;
|
|
|
|
doas cp $srcfile /tmp/doasedit/edit
|
|
doas chown -R $USER:$USER /tmp/doasedit/edit
|
|
doas cp $srcfile /tmp/doasedit/file
|
|
|
|
$EDITOR /tmp/doasedit/edit
|
|
|
|
cat /tmp/doasedit/edit | doas tee /tmp/doasedit/file 1&gt;/dev/null
|
|
doas mv -f /tmp/doasedit/file $srcfile
|
|
|
|
rm -rf /tmp/doasedit
|
|
</code></pre><p>At this point, it works&hellip;okay-ish. It can only be used in one instance currently
|
|
since I hard-coded <code>/tmp/doasedit/file</code> and <code>/tmp/doasedit/edit</code>, but that&rsquo;s easily fixed:</p>
|
|
<pre tabindex="0"><code>#!/bin/sh
|
|
|
|
destfile_pfx=&#34;$(cat /dev/urandom | tr -cd &#39;a-f0-9&#39; | head -c 32)&#34;
|
|
|
|
while [ -d &#34;/tmp/doasedit/$destfile_pfx&#34; ]; do
|
|
destfile_pfx=&#34;$(cat /dev/urandom | tr -cd &#39;a-f0-9&#39; | head -c 32)&#34;
|
|
done
|
|
|
|
mkdir -p /tmp/doasedit/$destfile_pfx
|
|
srcfile=&#34;$(realpath $1)&#34;
|
|
|
|
doas cp $srcfile /tmp/doasedit/$destfile_pfx/edit
|
|
doas chown -R $USER:$USER /tmp/doasedit/$destfile_pfx/edit
|
|
doas cp $srcfile /tmp/doasedit/$destfile_pfx/file
|
|
|
|
$EDITOR /tmp/doasedit/$destfile_pfx/edit
|
|
|
|
cat /tmp/doasedit/$destfile_pfx/edit | doas tee /tmp/doasedit/$destfile_pfx/file 1&gt;/dev/null
|
|
doas mv -f /tmp/doasedit/$destfile_pfx/file $srcfile
|
|
|
|
rm -rf /tmp/doasedit/$destfile_pfx
|
|
</code></pre><p>At this point, the only thing missing is the check to see if the file was actually
|
|
edited:</p>
|
|
<pre tabindex="0"><code>...
|
|
cat /tmp/doasedit/$destfile_pfx/edit | doas tee /tmp/doasedit/$destfile_pfx/file 1&gt;/dev/null
|
|
|
|
if cmp -s &#34;/tmp/doasedit/$destfile_pfx/file&#34; &#34;$srcfile&#34;; then
|
|
echo &#34;Skipping write; no changes.&#34;
|
|
else
|
|
doas mv -f /tmp/doasedit/$destfile_pfx/file $srcfile
|
|
fi
|
|
...
|
|
</code></pre><p>I put this in a <a href="https://github.com/AluminumTank/doasedit">repo on GitHub</a> if
|
|
anyone is interested. I know that a major
|
|
weakness of this script is the number of times it calls <code>doas</code>, which could
|
|
break flows where password is required every time <code>doas</code> is run.</p>
|
|
</description>
|
|
</item>
|
|
|
|
</channel>
|
|
</rss>
|