@@ -2,493 +2,547 @@
#+HUGO_SECTION: posts
#+HUGO_AUTO_SET_LASTMOD: t
#+HUGO_FRONT_MATTER_FORMAT: yaml
+#+ORG-HUGO-EXTERNAL-FILE-EXTENSIONS-ALLOWED-FOR-COPYING: nil
* Meta :@Meta:
* Technology :@Technology:
-** TODO Audacity and the telemetry pull request :Open__source__culture:Audio__editing:Music:Drama:
+** DONE (Ab)using mesh networks for easy remote support :Mesh__networking:Open__source:Remote__support:
+CLOSED: [2021-11-01 Mon 02:51]
:PROPERTIES:
-:EXPORT_FILE_NAME: audacity-and-the-telemetry-pull-request
+:EXPORT_FILE_NAME: abusing-mesh-networks-for-easy-remote-support
:EXPORT_HUGO_CUSTOM_FRONT_MATTER: :toc true
:END:
+One of the things many of us struggle with when setting friends and
+family up with Linux is remote support. Commercial solutions like
+[[https://www.realvnc.com/][RealVNC]] and [[https://rustdesk.com/][RustDesk]] do exist and function very well, but are often more
+expensive than we would like for answering the odd "I can't get Facebook
+open!" support call. I've been on the lookout for suitable alternatives
+for a couple years but nothing has been satisfying. Because of this, I
+have held off on setting others up with any Linux distribution, even the
+particularly user-friendly options such as [[https://linuxmint.com/][Linux Mint]] and [[https://elementary.io/][elementary OS;]]
+if I'm going drop someone in an unfamiliar environment, I want to be
+able to help with any issue within a couple hours, not days and
+/certainly/ not weeks.
-Five days ago at the time of writing, [[https://github.com/crsib][Dmitry Vedenko]] opened a Pull
-Request (PR) in [[https://github.com/audacity/audacity/pull/835][Audacity's GitHub repository]] entitled [[https://github.com/audacity/audacity/pull/835][/Basic telemetry
-for the Audacity/.]] About two days later, all hell broke loose. That PR
-now has over 3.3 thousand downvotes and more than one thousand comments
-from nearly 400 individuals. I started reading the posts shortly after
-they began and kept up with them over the following days, reading every
-single new post. I recognise that few people are going to feel like
-wading through over 1k comments so this is my attempt to provide a
-summary of the PR itself using the community's code reviews along with a
-summary of the various opinions conveyed in the comments.
+[[https://linuxunplugged.com/421][Episode 421 of LINUX Unplugged]] gave me an awesome idea to use [[https://github.com/slackhq/nebula][Nebula,]] a
+networking tool created by Slack, [[https://libvnc.github.io/][X11vnc,]] a very minimal VNC server, and
+[[https://remmina.org/][Remmina,]] a libre remote access tool available in pretty much every Linux
+distribution, to set up a scalable, secure, and simple setup reminiscent
+of products like RealVNC.
-When I reference comments, I'll provide a footnote that includes a link
-to the comment and a link to a screenshot just in case it's removed or
-edited in the future.
+*** Nebula
+The first part of our stack is Nebula, the tool that creates a network
+between all of our devices. With traditional VPNs, you have a client
+with a persistent connection to a central VPN server and other clients
+can communicate with the first by going through that central server.
+This works wonderfully in most situations, but there are a lot of
+latency and bandwidth restrictions that would make remote support an
+unpleasant experience. Instead of this model, what we want is a /mesh/
+network, where each client can connect directly to one another /without/
+going through a central system and slowing things down. This is where
+Nebula comes in.
-*** Audacity's acquisition
+In Nebula's terminology, clients are referred to as /nodes/ and central
+servers are referred to as /lighthouses/, so those are the terms I'll use
+going forward.
-I haven't been able to find /much/ information in this area so forgive me
-if I'm scant on details.
+Mesh networks are usually only possible when dealing with devices that
+have static IP addresses. Each node has to know /how/ to connect with the
+other nodes; John can't meet up with Bob when Bob moves every other day
+without notifying anyone of his new address. This wouldn't be a problem
+if Bob phoned Jill and told her where he was moving; John would call
+Jill, Jill would tell him where Bob is, and the two would be able to
+find each other
-On 30 April, a company called [[https://mu.se/][Muse Group]] acquired [[https://www.audacityteam.org/][Audacity.]] According to
-[[https://mu.se][their website]], Muse is the parent company behind many musical
-applications and tools. It was founded by Eugeny Naidenov just days
-before it acquired Audacity. Before all of this, Eugeny Naidenov founded
-[[https://www.ultimate-guitar.com/][Ultimate Guitar]] (UG) in 1998. The service grew rather quickly and now
-has over 300 million users. UG acquired [[https://deanzelinsky.com/][Dean Zelinsky Guitars]] in 2012,
-[[http://agilepartners.com/][Agile Partners]] in 2013, [[https://musescore.org/][MuseScore]] in 2017, and [[http://trycrescendo.com/][Crescendo]] in 2018. Muse
-Group was established in 2021 and it seems as if all of the services UG
-acquired were (or will be) transferred to Muse Group, as well as UG
-itself. Immediately following its establishment, Muse not only acquired
-Audacity but also [[https://www.staffpad.net/][StaffPad.]]
+With Nebula, nodes are Bob and John and Jill is a lighthouse. Each node
+connects to a lighthouse and the lighthouse tells the nodes how to
+connect with one another when they ask. It /facilitates/ the P2P
+connection then /backs out of the way/ so the two nodes can communicate
+directly with each other.
-I say 30 April because that's when Muse published their [[https://mu.se/newsroom/tpost/6dhedma301-muse-group-acquires-audacity-expanding-c][press release]]
-and when Martin Keary (Tantacrul) published a video entitled [[https://www.youtube.com/watch?v=RMWNvwLiXIQ][/I’m now in
-charge of Audacity. Seriously./]] According to his comment,[fn:17] Martin
-will help with proposing Audacity's roadmap and many of its future
-features as well as working with the community. This has been his role
-with MuseScore since he joined that project and he will be continuing it
-here.
+It allows any node to connect with any other node on any network from
+anywhere in the world, as long as one lighthouse is accessible that
+knows the connection details for both peers.
-~-----BEGIN PERSONAL OPINION-----~
+**** Getting started
+The /best/ resource is [[https://github.com/slackhq/nebula][the official documentation,]] but I'll describe the
+process here as well.
-Looking at [[https://www.martinkeary.com/][his website,]] I also suspect he will play a large role in
-redesigning Audacity's interface. Considering that he was instrumental
-in designing [[https://www.martinkeary.com/#/ubuntu-touch-os/][the best mobile interface I've ever had the absolute
-pleasure of experiencing,]] I have high hopes that this is the case.
+After [[https://github.com/slackhq/nebula#1-the-nebula-binaries-or-distribution-packages-for-your-specific-platform-specifically-youll-need-nebula-cert-and-the-specific-nebula-binary-for-each-platform-you-use][installing the required packages,]] make sure you have a VPS with a
+static IP address to use as a lighthouse. If you want something dirt
+cheap, I would recommend one of the small plans from [[https://buyvm.net][BuyVM.]] I do have a
+[[https://my.frantech.ca/aff.php?aff=3783][referral link]] if you want them to kick me a few dollars for your
+purchase. [[https://www.hetzner.com/cloud][Hetzner]] (referral: ~ckGrk4J45WdN~) or [[https://www.netcup.eu/][netcup]] (referral:
+~36nc15758387844~) would also be very good options; I've used them all and
+am very comfortable recommending them.
-~------END PERSONAL OPINION------~
+**** Creating a Certificate Authority
+After picking a device with a static IP address, it needs to be set up
+as a lighthouse. This is done by first creating a Certificate Authority
+(CA) that will be used for signing keys and certificates that allow our
+other devices into the network. The ~.key~ file produced by the following
+command is incredibly sensitive; with it, anyone can authorise a new
+device and give it access to your network. Store it in a safe,
+preferably encrypted location.
-*** Telemetry implementation
-**** Implementation Basics
+#+BEGIN_SRC bash
+ nebula-cert ca -name "nebula.example.com"
+#+END_SRC
-A few days after the acquisition, a PR was opened that adds /Basic
-telemetry for the Audacity/. This implementation collects "application
-opened" events and sends those to Yandex to estimate the number of
-Audacity users. It also collects session start and end events, errors
-for debugging, file used for import and export, OS and Audacity
-versions, and the use of effects, generators, and analysis tools so they
-can prioritise future improvements. Sending this data would be optional
-and the user would be presented with a dialogue the first time they
-launch the application after installation or after they update to the
-including release. This description was mostly copied directly from [[https://github.com/audacity/audacity/pull/835#issue-629891447][the
-PR description itself.]]
+I'll explain why we used a Fully-Qualified Domain Name (FQDN) as the
+CA's name in a later section. If you have your own domain, feel free to
+use that instead; it doesn't really matter what domain is used as long
+as the format is valid.
-**** Frontend Implementation
-This is fairly straightforward and a pretty standard UI for prompting
-users to consent to analytics and crash logging. This section is
-included because the community has strong opinions regarding the
-language used and its design, but that will be discussed later. The
-screenshot below is copied directly from the PR.
+**** Generating lighthouse credentials
+Now that we have the CA's ~.crt~ and ~.key~ files, we can create and sign
+keys and certificates for the lighthouse.
-[[/assets/pngs/audacity-pr/consentdialogue.png]]
+#+BEGIN_SRC bash
+ nebula-cert sign -name "buyvm.lh.nebula.example.com" -ip "192.168.100.1/24"
+#+END_SRC
-**** Backend Implementation
-Many of the code reviews include the reviewer's personal opinion so I
-will summarise the comment, provide the code block in question, and link
-directly to the comment in a footnote.[fn:9]
+Here, we're using a FQDN for the same reason as we did in the CA. You
+can use whatever naming scheme you like, I just prefer
+~<vps-host>.lh.nebula...~ for my lighthouses. The IP address can be on any
+of the following private IP ranges, I just happened to use ~192.168.100.X~
+for my network.
-#+BEGIN_SRC c
- if (!inputFile.Write (wxString::FromUTF8 (ClientID + "\n")))
- return false;
-#+END_SRC
-[[https://github.com/crsib/audacity/blob/c9264d2478fe2af82aeb6e2a0295b00b3a27ce53/libraries/lib-telemetry/TelemetryManager.cpp#L199-L200][Lines 199-200 of TelemetryManager.cpp]] save the user's unique client ID
-to a file.[fn:8] This allows the analytics tool (in this case, Google
-Analytics) to aggregate data produced by a single user.
+| IP Range | Number of addresses |
+|-------------------------------+---------------------|
+| 10.0.0.0 – 10.255.255.255 | 16 777 216 |
+| 172.16.0.0 – 172.31.255.255 | 10 48 576 |
+| 192.168.0.0 – 192.168.255.255 | 65 536 |
-#+BEGIN_SRC c
- def_vars()
+**** Creating a config file
+The next step is creating our lighthouse's config file. The reference
+config can be found in [[https://github.com/slackhq/nebula/blob/master/examples/config.yml][Nebula's repo.]] We only need to change a few of
+the lines for the lighthouse to work properly. If I don't mention a
+specific section here, I've left the default values.
- set( CURL_DIR "${_INTDIR}/libcurl" )
- set( CURL_TAG "curl-7_76_0")
-#+END_SRC
-[[https://github.com/crsib/audacity/blob/c9264d2478fe2af82aeb6e2a0295b00b3a27ce53/cmake-proxies/libcurl/CMakeLists.txt#L3-L6][Lines 3-6 of CMakeLists.txt]] "vendor in" libcurl.[fn:10] This is when an
-application directly includes sources for a utility rather than making
-use utilities provided by the system itself.
+The section below is where we'll define certificates and keys. ~ca.crt~
+will remain ~ca.crt~ when we copy it over but I like to leave the node's
+cert and key files named as they were when generated; this makes it easy
+to identify nodes by their configs. Once we copy everything over to the
+server, we'll add the proper paths to the ~cert~ and ~key~ fields.
-#+BEGIN_SRC c
- ExternalProject_Add(curl
- PREFIX "${CURL_DIR}"
- INSTALL_DIR "${CURL_DIR}"
- GIT_REPOSITORY https://github.com/curl/curl
- GIT_TAG ${CURL_TAG}
- GIT_SHALLOW Yes
- CMAKE_CACHE_ARGS ${CURL_CMAKE_ARGS}
- )
+#+BEGIN_SRC yaml
+ pki:
+ ca: /etc/nebula/ca.crt
+ cert: /etc/nebula/
+ key: /etc/nebula/
#+END_SRC
-[[https://github.com/crsib/audacity/blob/c9264d2478fe2af82aeb6e2a0295b00b3a27ce53/cmake-proxies/libcurl/CMakeLists.txt#L29-L36][Lines 29-36 of CMakeLists.txt]] add curl as a remote dependency.[fn:11]
-This means that the machine building Audacity from its source code has
-to download curl during that build.
-#+BEGIN_SRC c
- S.Id (wxID_NO).AddButton (rejectButtonTitle);
- S.Id (wxID_YES).AddButton (acceptButtonTitle)->SetDefault ();
+The next section is for identifying and mapping your lighthouses. This
+needs to be present in /all/ of the configs on /all/ nodes, otherwise they
+won't know how to reach the lighthouses and will never actually join the
+network. Make sure you replace ~XX.XX.XX.XX~ with whatever your VPS's
+public IP address is. If you've used a different private network range,
+those changes need to be reflected here as well.
+
+#+BEGIN_SRC yaml
+ static_host_map:
+ "192.168.100.1": ["XX.XX.XX.XX:4242"]
#+END_SRC
-[[https://github.com/crsib/audacity/blob/c9264d2478fe2af82aeb6e2a0295b00b3a27ce53/src/telemetry/TelemetryDialog.cpp#L93-L94][Lines 93-94 of TelemetryDialog.cpp]] add buttons to the dialogue asking
-the user whether they consent to data collection.[fn:12] ~SetDefault~
-focuses the button indicating that the user does consent. This means
-that if the user doesn't really look at the dialogue and presses
-Spacebar or Enter, or if they do so accidentally by simply bumping the
-key, they unintentionally consent to data collection. If the user
-desires, this can later be changed in the settings menu. However, if
-they weren't aware what they were consenting to /or that they did
-consent/, they won't know to go back and opt out.
-There are other problems with the code that include [[https://github.com/audacity/audacity/pull/835#discussion_r628816050][simple mistakes,]]
-[[https://github.https://github.com/audacity/audacity/pull/835#discussion_r628774985][styling that's inconsistent with the rest of the project,]] [[https://github.com/audacity/audacity/pull/835#discussion_r628500849][unhandled
-return values resulting in skewed data,]] [[https://github.com/audacity/audacity/pull/835#discussion_r628792423][use of inappropriate functions,]]
-and [[https://github.com/audacity/audacity/pull/835#discussion_r628818054][spelling errors in the comments.]] I believe these are less important
-than those above so they won't be discussed.
+Below, we're specifying how the node should behave. It is a lighthouse,
+it should answer DNS requests, the DNS server should listen on all
+interfaces on port 53, it sends its IP address to lighthouses every 60
+seconds (this option doesn't actually have any effect when ~am_lighthouse~
+is set to ~true~ though), and this lighthouse should not send reports to
+other lighthouses. The bit about DNS will be discussed later.
-*** Community opinions
-There were many strong opinions regarding both the frontend and backend
-implementations of this PR, from the wording of the dialogue and
-highlighting the consent button to devices running something other than
-Windows and macOS not being able to send telemetry and thus skewing the
-data that /was/ collected.
+#+BEGIN_SRC yaml
+ lighthouse:
+ am_lighthouse: true
+ serve_dns: true
+ dns:
+ host: 0.0.0.0
+ port: 53
+ interval: 60
+ hosts:
+#+END_SRC
-**** Opinions on the frontend
+The next bit is about [[https://en.wikipedia.org/wiki/Hole_punching_%28networking%29][hole punching]], also called /NAT punching/, /NAT
+busting/, and a few other variations. Make sure you read the comments for
+better explanations than I'll give here. ~punch: true~ enables hole
+punching. I also like to enable ~respond~ just in case nodes are on
+particularly troublesome networks; because we're using this as a support
+system, we have no idea what networks our nodes will actually be
+connected to. We want to make sure devices are available no matter where
+they are.
-Really, the only frontend here is the consent dialogue. However, there
-are /many/ comments about it, the most common of which is probably that
-the wording is not only too vague[fn:13] but also inaccurate.[fn:14] The
-assertion that Google Analytics are not anonymous and any data sent can
-be trivially de-anonymised (or de-pseudonymised) is repeated many times
-over. Below are a few links to comments stating such. I searched for the
-term /"anonymous"/, copied relevant links, and stopped when my scrollbar
-reached halfway down the page.
-
-- [[https://github.com/audacity/audacity/pull/835#discussion_r628156527][r628156527]]
-- [[https://github.com/audacity/audacity/pull/835#issuecomment-833969780][833969780]]
-- [[https://github.com/audacity/audacity/pull/835#issuecomment-833969933][833969933]]
-- [[https://github.com/audacity/audacity/pull/835#discussion_r627995927][r627995927]]
-- [[https://github.com/audacity/audacity/pull/835#issuecomment-834358022][834358022]]
-- [[https://github.com/audacity/audacity/pull/835#issuecomment-834377549][834377549]]
-- [[https://github.com/audacity/audacity/pull/835#issuecomment-834382007][834382007]]
-- [[https://github.com/audacity/audacity/pull/835#issuecomment-834385463][834385463]]
-- [[https://github.com/audacity/audacity/pull/835#issuecomment-834405825][834405825]]
-- [[https://github.com/audacity/audacity/pull/835#issuecomment-834531779][834531779]]
-- [[https://github.com/audacity/audacity/pull/835#issuecomment-834546874][834546874]]
-- [[https://github.com/audacity/audacity/pull/835#issuecomment-834638000][834638000]]
+#+BEGIN_SRC yaml
+ punchy:
+ punch: true
+ respond: true
+ delay: 1s
+#+END_SRC
-The next most pervasive comment is regarding the consent buttons at the
-bottom of the dialogue where users opt in or out.[fn:15] Many individuals call
-this design a /dark pattern/. Harry Brignull, a UX specialist focusing on
-deceptive interface practises, describes dark patterns as [[https://www.darkpatterns.org/][/tricks used
-in websites and apps that make you do things that you didn't mean to/.]]
-The dark pattern in this situation is the opt-in button being
-highlighted. Many community members assert that users will see the big
-blue button and click it without actually reading the dialogue's
-contents. They just want to record their audio and this window is a
-distraction that prevents them from doing so; it needs to get out of the
-way and the quickest way to dismiss it is clicking that blue button.
-Below is a list of some comments criticising this design.
+~cipher~ is a big one. The value /must/ be identical on /all/ nodes /and/
+lighthouses. ~chachapoly~ is more compatible so it's used by default. The
+devices /I/ want to connect to are all x86 Linux, so I can switch to ~aes~
+and benefit from [[https://www.reddit.com/r/networking/comments/iksyuu/comment/g3ra5cv/?utm_source=share&utm_medium=web2x&context=3][a small performance boost.]] Unless you know /for sure/
+that you won't need to work with /anything/ else, I recommend leaving it
+set to ~chachapoly~.
- - [[https://github.com/audacity/audacity/pull/835#issuecomment-834286641][834286641]]
- - [[https://github.com/audacity/audacity/pull/835#issuecomment-834358022][834358022]]
- - [[https://github.com/audacity/audacity/pull/835#issuecomment-834399813][834399813]]
- - [[https://github.com/audacity/audacity/pull/835#issuecomment-834479968][834479968]]
- - [[https://github.com/audacity/audacity/pull/835#issuecomment-835250737][835250737]]
- - [[https://github.com/audacity/audacity/pull/835#issuecomment-835253882][835253882]]
- - [[https://github.com/audacity/audacity/pull/835#issuecomment-835291066][835291066]]
- - [[https://github.com/audacity/audacity/pull/835#issuecomment-835445481][835445481]]
+#+BEGIN_SRC yaml
+ cipher: chachapoly
+#+END_SRC
-Another issue that was brought up by a couple of individuals was the
-lack of a privacy policy.[fn:16] The consent dialogue links to one, but, at the
-time of writing, one does not exist at [[https://www.audacityteam.org/contact/privacy-policy/][the provided URL.]] I have [[https://web.archive.org/web/20210510012924/https://www.audacityteam.org/contact/privacy-policy/][archived
-the state of the page]] in case that changes in the future.
+The last bit I modify is the firewall section. I leave most everything
+default but /remove/ the bits after ~port: 443~. I don't /need/ the ~laptop~ and
+~home~ groups (groups will be explained later) to access port ~443~ on this
+node, so I shouldn't include the statement. If you have different needs,
+take a look at the comment explaining how the firewall portion works and
+make those changes.
-**** Opinions on the backend
+Again, I /remove/ the following bit from the config.
-#+BEGIN_SRC c
- if (!inputFile.Write (wxString::FromUTF8 (ClientID + "\n")))
- return false;
+#+BEGIN_SRC yaml
+ - port: 443
+ proto: tcp
+ groups:
+ - laptop
+ - home
#+END_SRC
-The issue many individuals take with this snippet is saving the
-~ClientID~. Say an individual has an odd file that causes Audacity to
-crash any time they try to open it. Say they attempt to open it a
-hundred times. Without giving the client a unique ID, it could look like
-there are 100 people having an issue opening a file instead of just the
-one. However, by virtue of each installation having an entirely unique
-ID, this telemetry /is not anonymous/. Anonymity would be sending
-statistics in such a way that connecting those failed attempts to a
-single user would be impossible. At best, this implementation is
-/pseudonymous/ because the client is given a random ID, you don't have to
-sign in with an account or something.
+**** Setting the lighthouse up
+We've got the config, the certificates, and the keys. Now we're ready to
+actually set it up. After SSHing into the server, grab the [[https://github.com/slackhq/nebula/releases/latest][latest
+release of Nebula for your platform,]] unpack it, make the ~nebula~ binary
+executable, then move it to ~/usr/local/bin~ (or some other location
+fitting for your platform).
-#+BEGIN_SRC c
- def_vars()
+#+BEGIN_SRC bash
+ wget https://github.com/slackhq/nebula/releases/download/vX.X.X/nebula-PLATFORM-ARCH.tar.gz
+ tar -xvf nebula-*
+ chmod +x nebula
+ mv nebula /usr/local/bin/
+ rm nebula-*
+#+END_SRC
- set( CURL_DIR "${_INTDIR}/libcurl" )
- set( CURL_TAG "curl-7_76_0")
+Now we need a place to store our config file, keys, and certificates.
+
+#+BEGIN_SRC bash
+ mkdir /etc/nebula/
#+END_SRC
-Timothe Litt's comment gives a good description of why "vendoring in"
-libcurl is a bad idea[fn:19] and Tyler True's comment gives a good
-overview of the pros and cons of doing so.[fn:18] Many people take issue
-with this /specifically/ because it's libcurl. Security flaws in it are
-/very/ common and Audacity's copy would need to be /manually/ kept up to
-date with every upstream release to ensure none of its vulnerabilities
-can be leveraged to compromise users. If the Audacity team was going to
-stay on top of all of the security fixes, they would need to release a
-new version every week or so.
+The next step is copying the config, keys, and certificates to the
+server. I use ~rsync~ but you can use whatever you're comfortable with.
+The following four files need to be uploaded to the server.
-#+BEGIN_SRC c
- ExternalProject_Add(curl
- PREFIX "${CURL_DIR}"
- INSTALL_DIR "${CURL_DIR}"
- GIT_REPOSITORY https://github.com/curl/curl
- GIT_TAG ${CURL_TAG}
- GIT_SHALLOW Yes
- CMAKE_CACHE_ARGS ${CURL_CMAKE_ARGS}
- )
+- ~config.yml~
+- ~ca.crt~
+- ~buyvm.lh.nebula.example.com.crt~
+- ~buyvm.lh.nebula.example.com.key~
+
+With ~rsync~, that would look something like this. Make sure ~rsync~ is also
+installed on the VPS before attempting to run the commands though;
+you'll get an error otherwise.
+
+#+BEGIN_SRC bash
+ rsync -avmzz ca.crt user@example.com:
+ rsync -avmzz config.yml user@example.com:
+ rsync -avmzz buyvm.lh.* user@example.com:
#+END_SRC
-The problem with downloading curl at build-time is that it's simply
-disallowed for many Linux- and BSD-based operation systems. When a
-distribution builds an application from source, its build dependencies
-are often downloaded ahead of time and, as a security measure, the build
-machine is cut off from the internet to prevent any interference.
-Because this is disallowed, the build will fail and the application
-won't be available on those operation systems.
-Note, however, that these build machines would have the option to
-disable telemetry at build-time. This means the machine wouldn't attempt
-to download curl from GitHub and the build would succeed but, again,
-telemetry would be disabled for anyone not on Windows or macOS. This
-defeats the whole purpose of adding telemetry in the first place.
+SSH back into the server and move everything to ~/etc/nebula/~.
-#+BEGIN_SRC c
- S.Id (wxID_NO).AddButton (rejectButtonTitle);
- S.Id (wxID_YES).AddButton (acceptButtonTitle)->SetDefault ();
+#+BEGIN_SRC bash
+ mv ca.crt /etc/nebula/
+ mv config.yml /etc/nebula/
+ mv buyvm.lh* /etc/nebula/
#+END_SRC
-There was a lot of feedback about the decision to highlight the consent
-button but that was mentioned up in the frontend section; I won't rehash
-it here.
+Edit the config file and ensure the ~pki:~ section looks something like
+this, modified to match your hostnames of course.
-**** Broader and particularly well-structured comments
-These are simply some comments I feel deserve particular attention.
+#+BEGIN_SRC yaml
+ pki:
+ ca: /etc/nebula/ca.crt
+ cert: /etc/nebula/buyvm.lh.nebula.example.com.crt
+ key: /etc/nebula/buyvm.lh.nebula.example.com.key
+#+END_SRC
-From SndChaser...
-- [[https://github.com/audacity/audacity/pull/835#issuecomment-834037351][834037351]]
--
+Run the following command to make sure everything works properly.
-*** The Audacity team's response
+#+BEGIN_SRC bash
+ nebula -config /etc/nebula/config.yml
+#+END_SRC
+The last step is daemonizing Nebula so it runs every time the server
+boots. If you're on a machine using systemd, dropping the following
+snippet into ~/etc/systemd/system/nebula.service~ should be sufficient. If
+you're using something else, check the [[https://github.com/slackhq/nebula/tree/master/examples/][the examples directory]] for more
+options.
------------------
+#+BEGIN_SRC text
+ [Unit]
+ Description=nebula
+ Wants=basic.target
+ After=basic.target network.target
+ Before=sshd.service
-*** The privacy policy modification
+ [Service]
+ SyslogIdentifier=nebula
+ ExecReload=/bin/kill -HUP $MAINPID
+ ExecStart=/usr/local/bin/nebula -config /etc/nebula/config.yml
+ Restart=always
-https://github.com/audacity/audacity/issues/1213#issuecomment-875274890
+ [Install]
+ WantedBy=multi-user.target
+#+END_SRC
-** TODO Catchy title about Supernote being "the new paper" :Supernote:Writing:Productivity:Organisation:
-:PROPERTIES:
-:EXPORT_FILE_NAME: something-about-supernote
-:EXPORT_HUGO_CUSTOM_FRONT_MATTER: :toc true
-:END:
+We're almost done!
-I like writing things down. I like the feel of the pen (preferably a
-fountain pen) gliding smoothly over the paper, that nice solid feeling
-of the tip against the table, seeing the ink dry as it flows from the
-nib, accidentally swiping my hand through it before it's finished and
-smearing a bit of ink across the page, then cursing under my breath as I
-dab it up with a handkerchief or a napkin or something else nearby. I
-also love that writing things by hand [[https://journals.sagepub.com/doi/abs/10.1177/0956797614524581][has an impact on memory and
-improves retention.]]
+**** Setting individual nodes up
+This process is almost exactly the same as setting lighthouses up. All
+you'll need to do is generate a couple of certs and keys then tweak the
+configs a bit.
-*** The problem
-Unfortunately, I don't love keeping up with that paper. Across many
-different classes, even with dedicated folders for each one, something
-important inevitably gets lost. Notebooks are also bulky and can take up
-a lot of space. I tried [[https://bulletjournal.com/][bullet journalling]] for about a month earlier
-this year and, while the process was enjoyable, the maintenance was not.
-My brain moves faster than my pen (even though I have terrible
-handwriting) and I inevitably forget letters or even whole words. This
-is a problem while writing in pen because white-out looks ugly and I
-dislike wasting whole pages because of a couple mistakes.
+The following command creates a new cert/key for USER's node with the IP
+address ~192.168.100.2~. The resulting files would go on the /remote/ node
+not yours. Replace ~HOST~ and ~USER~ with fitting values.
-The obvious solution here is to get an iPad with an Apple Pen, right?
-Right??
+#+BEGIN_SRC bash
+ nebula-cert sign -name "HOST.USER.nebula.example.com" -ip "192.168.100.2/24"
+#+END_SRC
-Wrong because Apple bad.[fn:2]
+The following command will create a /similar/ cert/key but it will be part
+of the ~support~ group. The files resulting from this should go on /your/
+nodes. With the config we'll create next, nodes in the ~support~ group
+will be able to VNC and SSH into other nodes. Your nodes need to be in
+the ~support~ group so you'll have access to the others.
-*** The solution
-Enter the world of ... what are they even called? E-ink notebooks? Paper
-tablets? E-R/W?[fn:1] Do they even have a "device category" yet? I don't
-know, but they solve my problem in a wonderful way.
+#+BEGIN_SRC bash
+ nebula-cert sign -name "HOST.USER.nebula.example.com" -ip "192.168.100.2/24" -groups "support"
+#+END_SRC
-As the names suggest, these are devices that can /usually/ open and read
-e-books (EPUBs, PDFs, etc.), annotate them, and create standalone pages
-of notes as if they were full notebooks. The most well-known of these
-devices is likely the [[https://remarkable.com/][reMarkable.]] They had a [[https://venturebeat.com/2019/10/08/remarkable-raises-15-million-to-bring-its-e-paper-tablets-to-more-scribblers/][hugely successful
-crowdfunding campaign]] and produced the reMarkable 1, followed by [[https://blog.remarkable.com/remarkable-2-the-next-generation-paper-tablet-91b47d0080cb][the
-reMarkable 2 in 2020.]] There are a few devices like these by now but
-we'll look at the reMarkable first.
+On to the config now. This tells the node that it is /not/ a lighthouse,
+it should /not/ resolve DNS requests, it /should/ ping the lighthouses and
+tell them its IP address every 60 seconds, and the node at ~192.168.100.1~
+is one of the lighthouses it should report to and query from. If you
+have more than one lighthouse, add them to the list as well.
-*** The reMarkable
-This device boasts all of the features I was looking for. It renders
-digital content, from books and manuals to comics and manga, allows you
-to mark those documents up as you would if they were physical media,
-create full notebooks of hand written text, organise them, search, and,
-if your handwriting is legible enough (mine certainly is not), perform
-OCR on your notes and email a transcription to yourself. It even runs
-Linux and the developers have opened SSH up so you can remote in and
-tinker with it as much as you like. Because of this, there's a pretty
-awesome [[https://github.com/reHackable/awesome-reMarkable][community of people creating third-party tools and integrations]]
-that add even further functionality. My favourite is probably [[https://github.com/bordaigorl/rmview][rMview,]] a
-really fast VNC client for the reMarkable that allows you to view your
-device's screen on any computer.
+#+BEGIN_SRC yaml
+ lighthouse:
+ am_lighthouse: false
+ #serve_dns: false
+ #dns:
+ #host: 0.0.0.0
+ #port: 53
+ interval: 60
+ hosts:
+ - "192.168.100.1"
+#+END_SRC
-After watching all of [[https://www.youtube.com/c/MyDeepGuide][MyDeepGuide's]] [[https://www.youtube.com/playlist?list=PLsSI9-gaSSmiXwb7Vjk5Vb-nB41UTnrXd][extensive playlist on the
-reMarkable,]] however, I decided to go with a different product.
+The other bit that should be modified is the ~firewall:~ section and this
+is where the groups we created earlier are important. Review its
+comments and make sure you understand how it works before proceeding.
-*** Enter the Supernote A5X
-The [[https://www.supernote.com/#/product?type=SN-A5-X][Supernote A5X]] has all of the basic features the reMarkable has:
-reading documents, writing notes, and organising your content. Its
-implementation, on the other hand, seems to be much more polished. It
-also lacks some features from the reMarkable while adding others.
+We want to allow inbound connections on ports 5900, the standard port
+for VNC, and 22, the standard for SSH. Additionally, we /only/ want to
+allow connections from nodes in the ~support~ group. Any /other/ nodes
+should be denied access.
-*** Operating System
-While the reMarkable runs Codex,[fn:3] a /"custom Linux-based OS
-optimised for low-latency e-paper"/, the Supernote just runs Android.
-There are both benefits and detriments to this; on one hand, they're
-running all of Android, bloated that it is, on a very lightweight
-tablet. On the other, they don't have to develop and maintain a custom
-operating system. This allows them to focus on other aspects that are
-arguably more important so I don't actually mind that it runs Android.
+Note that including this section is not necessary on /your/ nodes, those
+in the ~support~ group. It's only necessary on the remote nodes that
+you'll be connecting to. As long as the ~outbound:~ section in the config
+on /your/ node allows any outbound connection, you'll be able to access
+other nodes.
-The only place that Android stands out is in system operations; file
-transfer uses MTP and, when you swipe down from the top of the device, a
-small bar appears similar to what was in early Android. This lets you
-change WiFi networks, sync with the Supernote Cloud, take a screenshot,
-search, and access the system settings. Nothing else about the device
-really screams Android to me.
+#+BEGIN_SRC yaml
+ - port: 5900
+ proto: tcp
+ groups:
+ - support
-*** Community
-I don't usually browse Reddit but [[https://old.reddit.com/r/Supernote/][the Supernote community]] there is
-fascinating. I haven't looked around enough to know exactly what his
-relationship is with the company, but one of the members, [[https://old.reddit.com/user/hex2asc][u/hex2asc,]]
-seems to represent Supernote in something of an official capacity. He's
-incredibly active and usually responds to posts and questions within a
-day or two.
+ - port: 22
+ proto: tcp
+ groups:
+ - support
+#+END_SRC
-Before I purchased a Supernote, [[https://old.reddit.com/r/Supernote/comments/lhffyd/sync_targets_open_document_formats_and_crossnote/][I wrote a post]] asking about a couple of
-things that concerned me: sync targets, open document formats, and
-cross-note links. I don't really plan to write full documents on the
-device but having the option to do so would still be nice. The other
-features are absolutely killer for me as I would like to maintain a
-Zettelkasten (I wrote about [[/vim-as-a-markdown-editor/][using Vim to do so]] last year but didn't end
-up sticking with it) and manage document synchronisation with my own
-Nextcloud server. The community was quick to respond and confirm that
-Zettelkasten functionality would be implemented soon™. u/hex2asc
-responded /the day after/ and said that WebDAV would be supported but not
-earlier than May (September update: it's still not supported), ODF would
-likely not be supported, and cross-note links were definitely a
-possibility. Another community member has been avidly following the
-subreddit and even put together an [[https://app-rm.roadmunk.com/publish/03e6dca3d769e2b7015f7f48a649cb3f75f44d9e][unofficial roadmap.]]
+The certs, key, config, binary, and systemd service should all be copied
+to the same places on all of these nodes as on the lighthouse.
-*** Interfaces
+*** X11vnc
+/Alright./ The hardest part is finished. Now on to setting ~x11vnc~ up on
+the nodes you'll be supporting.
-**** Home & Organisation
+All you should need to do is install ~x11vnc~ using the package manager
+your distro ships with, generate a 20 character password with ~pwgen -s
+20 1~, run the following command, paste the password, wait for ~x11vnc~ to
+start up, make sure it's running correctly, press ~Ctrl~ + ~C~, then add the
+command to the DE's startup applications!
-***** TODO Record very short video about home/organisation
+#+BEGIN_SRC bash
+ x11vnc --loop -usepw -listen <nebula-ip> -display :0
+#+END_SRC
-**** Settings
+~--loop~ tells ~x11vnc~ to restart once you disconnect from the session.
+~-usepw~ is pretty self-explanatory. ~-listen <nebula-ip>~ is important; it
+tells ~x11vnc~ to only listen on the node's Nebula IP address. This
+prevents randos in a coffee shop from seeing an open VNC port and trying
+to brute-force the credentials. ~-display :0~ just defines which X11
+server display to connect to.
-***** TODO Record very short video about settings
+Some distributions like elementaryOS and those that use KDE and GNOME
+will surface a dialogue for managing startup applications if you just
+press the Windows (Super) key and type ~startup~. If that doesn't work,
+you'll have to root around in the settings menus, consult the
+distribution's documentation, or ask someone else that might know.
-**** Writing & Annotating
+After adding it to the startup application, log out and back in to make
+sure it's running in the background.
-The following images are screenshots of the full page above with the
-possible UI variations while reading a book. This first one is default,
-with the editing bar at the top. It is exactly the same as what's
-displayed on the blank pages for hand writing full notes. From left to
-right is the Table of Contents toggle, the pen tools (fineliner,
-"fountain" pen,[fn:5] and highlighter), the erasers, lasso select tool,
-undo/redo, context menu, palm rejection toggle, previous page, goto
-page, next page, and exit.
+*** Remmina
+Now that our network is functioning properly and the VNC server is set
+up, we need something that connects to the VNC server over the fancy
+mesh network. Enter [[https://remmina.org/][Remmina.]] This one goes on /your/ nodes.
-[[/assets/pngs/supernote-reader-default.png]]
+Remmina is a multi-protocol remote access tool available in pretty much
+ever distribution's package archive as ~remmina~. Install it, launch it,
+add a new connection profile in the top left, give the profile a
+friendly name (I like to use the name of the person I'll be supporting),
+assign it to a group, such as ~Family~ or ~Friends~, set the Protocol to
+~Remmina VNC Plugin~, enter the node's Nebula IP address in the Server
+field, then enter their username and the 20 character password you
+generated earlier. I recommend setting the quality to Poor, but Nebula
+is generally performant enough that any of the options are suitable. I
+just don't want to have to disconnect and reconnect with a lower quality
+if the other person happens to be on a slow network.
-You can hold your finger on that bar and drag it down to detach it from
-the top. The default width exposes all the tools without whitespace. You
-can move it around the screen by dragging the circle with a straight
-line through the middle on the far left.
+Save and test the connection!
-[[/assets/pngs/supernote-reader-medium.png]]
+If all goes well and you see the other device's desktop, you're done
+with the VNC section! Now on to SSH.
-If you tap that circle, the width shrinks and everything except the
-pens, erasers, and undo/redo buttons are hidden. It can be dragged the
-same was as in the previous image and tapping that circle will expand
-the bar again.
+*** SSH
+First off, make sure ~openssh-server~ is installed on the remote node;
+~openssh-client~ would also be good to have, but from what I can tell,
+it's not strictly necessary. You /will/ need ~openssh-client~ on /your/ node,
+however. If you already have an SSH key, copy it over to
+~~/.ssh/authorized_keys~ on the remote node. If you don't, generate one
+with ~ssh-keygen -t ed25519~. This will create an Ed25519 SSH key pair.
+Ed25519 keys are shorter and faster than RSA and more secure than ECDSA
+or DSA. If that means nothing to you, don't worry about it. Just note
+than this key might not interact well with older SSH servers; you'll
+know if you need to stick with the default RSA. Otherwise, Ed25519 is
+the better option. After key generation has finished, copy
+~~/.ssh/id_ed25519.pub~ (note the ~.pub~ extension) from your node to
+~~/.ssh/authorized_keys~ on the remote node. The file /without/ ~.pub~ is your
+/private/ key. Like the Nebula CA certificate we generated earlier, this
+is extremely sensitive and should never be shared with anyone else.
-[[/assets/pngs/supernote-reader-small.png]]
+Next is configuring SSH to only listen on Nebula's interface; as with
+~x11vnc~, this prevents randos in a coffee shop from seeing an open SSH
+port and trying to brute-force their way in. Set the ~ListenAddress~
+option in ~/etc/ssh/sshd_config~ to the remote node's Nebula IP address.
+If you want to take security a step further, search for
+~PasswordAuthentication~ and set it to ~no~. This means your SSH key is
+/required/ for gaining access via SSH. If you mess up Nebula's firewall
+rules and accidentally give other Nebula devices access to this machine,
+they still won't be able to get in unless they have your SSH key. I
+/personally/ recommend disabling password authentication, but it's not
+absolutely necessary. After making these changes, run ~systemctl restart
+sshd~ to apply them.
-The last mode is with the bar completely hidden. You achieve this just
-by dragging it to the right edge of the screen. Once hidden, you can
-swipe right to left from the edge and it will be revealed flush with the
-right edge.
+Now that the SSH server is listening on Nebula's interface, it will
+actually fail to start when the machine (re)boots. The SSH server starts
+faster than Nebula does, so it will look for the interface before Nebula
+has even had a chance to connect. We need to make sure systemd waits for
+Nebula to start up and connect before it tells SSH to start; run
+~systemctl edit --full sshd~ and add the following line in the ~[Unit]~
+section, above ~[Service]~.
-[[/assets/pngs/supernote-reader-minimal.png]]
+#+BEGIN_SRC text
+ After=nebula.service
+#+END_SRC
-*** Experience
-**** Reading content
-I love e-ink. I think it looks beautiful and would love to have an e-ink
-monitor.[fn:4] That said, the Supernote has an especially nice display
-with 226 PPI (pixels per inch). The image below was taken with my
-phone's camera so it's not very good. However, if you zoom in a bit, you
-can see that the curved edges of some letters are /slightly/ pixellated.
-Viewing with my naked eye at a comfortable distance, it does look better
-/to me/ than some of my print books, however.
+Even now, there's still a bit of a hiccup. Systemd won't start SSH until
+Nebula is up and running, which is good. Unfortunately, even after
+Nebula has started, it still takes a minute to bring the interface up,
+causing SSH to crash. To fix /this/, add the following line directly below
+~[Service]~.
-[[/assets/pngs/supernote-resolution.png]]
+#+BEGIN_SRC text
+ ExecStartPre=/usr/bin/sleep 30
+#+END_SRC
-/At the moment,/ I am pretty disappointed with Table of Contents detection
-for ePUBs. A great many of my books seem to use a legacy ToC format that
-the Supernote sees and tries/fails to read before attempting to read the
-more up-to-date one. This is easily remedied by editing the ePUB in
-[[https://calibre-ebook.com/][Calibre,]] going to Tools → Upgrade Book Internals → Remove the legacy
-Table of Contents in NCX format. You might need to make a small change
-to one of the HTML files and revert it before the save button is
-enabled. After that, just copy it back over to the Supernote and
-everything should work properly.
+If the ~sleep~ executable is stored in a different location, make sure you
+use that path instead. You can check by running ~which sleep~.
-**** Writing notes
-I write notes as often if not /more/ often than I read and annotate books.
-It's the main reason I purchased the device and I love the experience.
-The Supernote doesn't /really/ feel like paper despite what their
-marketing materials claim, though it doesn't feel /bad/ either. It's hard
-to describe but I would say it's something like writing with a
-rollerball pen on high-quality paper with a marble counter underneath:
-incredibly smooth with but a little bit of texture so it doesn't feel
-like writing on a glass display.
+When the SSH /service/ starts up, it will now wait an additional 30
+seconds before actually starting the SSH /daemon/. It's a bit of a hacky
+solution but it works™. If you come up with something better, please
+send it to me and I'll include it in the post! My contact information is
+at the bottom of [[/][this site's home page.]]
-While writing latency[fn:6] is noticeable, I really don't have a huge
-issue with it. I write very quickly but find that the slight latency
-actually makes writing /more/ enjoyable. It sounds weird and I'm not sure
-why, but I /really/ like writing on the Supernote; it's wonderfully
-smooth, pressure-sensitive, the latency makes things interesting, and
-[[https://supernote.com/#/part?id=SP-04][the Heart of Metal pen]] feels good in my hand.
+After you've made these changes, run ~systemctl daemon-reload~ to make
+sure systemd picks up on the modified service file, then run ~systemctl
+restart sshd~. You should be able to connect to the remote node from your
+node using the following command.
-**** Surfacing Content
-While organisation is done using a regular filesystem hierarchy, the
-Supernote does have other ways to search for and surface your notes. As
-you're writing, you can use the lasso select tool and encircle a word. A
-little dialogue pops up and gives you a few buttons for things you can
-do with that selection: copy, move to another page, cut, add it to the
-Table of Contents, or mark it as a key word. If you select the key word
-icon, the Supernote does some incredible OCR[fn:7] on it and displays a
-dialogue where you can add it to the note file as a tag. This dialogue
-allows you to edit the word before adding it just in case the OCR was
-wonky. Even with my terrible handwriting, I've found that it works very
-well and I rarely have to make edits.
+#+BEGIN_SRC bash
+ ssh USER@<nebula-ip>
+#+END_SRC
-*** TODO Ping Isi and Volpeon when finished
-** TODO Migrating repositories between git hosts
-** TODO A perfect email setup (for me) :Email:Workflow:
+If you want to make the command a little simpler so you don't have to
+remember the IP every time, create ~~/.ssh/config~ on your node and add
+these lines to it.
+
+#+BEGIN_SRC text
+ Host USER
+ Hostname <nebula-ip>
+ User USER
+#+END_SRC
+
+Now you can just run ~ssh USER~ to get in. If you duplicate the above
+block for all of the remote nodes you need to support, you'll only have
+to remember the person's username to SSH into their machine.
+
+*** Going further with Nebula
+This section explains why we used FQDNs in the certs and why the DNS
+resolver is enabled on the lighthouse.
+
+Nebula ships with a built-in resolver meant specifically for mapping
+Nebula node hostnames to their Nebula IP addresses. Running a public DNS
+resolver is very much discouraged because it can be abused in terrible
+ways. However, the Nebula resolver mitigates this risk because it /only/
+answers queries for Nebula nodes. It doesn't forward requests to any
+other servers nor does it attempt to resolve any domain other than what
+was defined in its certificate. If you use the example I gave above,
+that would be ~nebula.example.com~; the lighthouse will attempt to resolve
+any subdomain of ~nebula.example.com~ but it will just ignore ~example.com~,
+~nebula.duckduckgo.com~, ~live.secluded.site~, etc.
+
+Taking advantage of this resolver requires setting it as your secondary
+resolver on any device you want to be able to resolve hostnames from.
+If you were to add the lighthouse's IP address as your secondary
+resolver on your PC, you could enter ~host.user.nebula.example.com~ in
+Remmina's server settings /instead of/ ~192.168.1.2~.
+
+But how you do so is beyond the scope of this post!
+
+If you're up for some /more/ shenanigans later on down the line, you could
+set up a Pi-Hole instance backed by Unbound and configure Nebula as
+Unbound's secondary resolver. With this setup, you'd get DNS-level ad
+blocking /and/ the ability to resolve Nebula hostname. Pi-Hole would query
+Unbound for ~host.user.nebula.example.com~, Unbound would receive no
+answer from the root servers because the domain doesn't exist outside of
+your VPN, Unbound would fall back to Nebula, Nebula would give it an
+answer, Unbound would cache the answer, tell Pi-Hole, Pi-Hole would
+cache the answer, tell your device, then your device would cache the
+answer, and you can now resolve any Nebula host!
+
+Exactly how you do /that/ is */definitely/* beyond the scope of this post :P
+
+If you set any of this up, I would be interested to hear how it goes! As
+stated earlier, my contact information is at the bottom of the site's
+home page :)
+** TODO A perfect email setup (for me) :Email:Workflow:
:PROPERTIES:
:EXPORT_FILE_NAME: a-perfect-email-setup-for-me
:EXPORT_HUGO_CUSTOM_FRONT_MATTER: :toc true
@@ -813,563 +867,506 @@ accounts as you want to send email from.
*** Summary
*** TODO Pong fluffy when finished
-
-** TODO Making yourself overly available
-
-*** References
-[[https://www.nytimes.com/2021/03/05/opinion/ezra-klein-podcast-cal-newport.html?showTranscript=1][Stop. Breathe. We Can’t Keep Working Like This.]]
-
-*** Notes
-**** Get rid of information that isn't important
-**** Escalate the info that is
-**** Set /clear/ boundaries for when you are available
-**** Enforce those with automatic DnD rules or use timers
-**** With groups...
-***** Specialisation is /good/ and should be /encouraged/
-***** /All/ of the above points apply with coworkers as well
-
-*** TODO Pong Jake when finished
-
-** TODO Setting LXC up for local "cloud" development
-** DONE (Ab)using mesh networks for easy remote support :Mesh__networking:Open__source:Remote__support:
-CLOSED: [2021-11-01 Mon 02:51]
+** TODO Audacity and the telemetry pull request :Open__source__culture:Audio__editing:Music:Drama:
:PROPERTIES:
-:EXPORT_FILE_NAME: abusing-mesh-networks-for-easy-remote-support
+:EXPORT_FILE_NAME: audacity-and-the-telemetry-pull-request
:EXPORT_HUGO_CUSTOM_FRONT_MATTER: :toc true
:END:
-One of the things many of us struggle with when setting friends and
-family up with Linux is remote support. Commercial solutions like
-[[https://www.realvnc.com/][RealVNC]] and [[https://rustdesk.com/][RustDesk]] do exist and function very well, but are often more
-expensive than we would like for answering the odd "I can't get Facebook
-open!" support call. I've been on the lookout for suitable alternatives
-for a couple years but nothing has been satisfying. Because of this, I
-have held off on setting others up with any Linux distribution, even the
-particularly user-friendly options such as [[https://linuxmint.com/][Linux Mint]] and [[https://elementary.io/][elementary OS;]]
-if I'm going drop someone in an unfamiliar environment, I want to be
-able to help with any issue within a couple hours, not days and
-/certainly/ not weeks.
-
-[[https://linuxunplugged.com/421][Episode 421 of LINUX Unplugged]] gave me an awesome idea to use [[https://github.com/slackhq/nebula][Nebula,]] a
-networking tool created by Slack, [[https://libvnc.github.io/][X11vnc,]] a very minimal VNC server, and
-[[https://remmina.org/][Remmina,]] a libre remote access tool available in pretty much every Linux
-distribution, to set up a scalable, secure, and simple setup reminiscent
-of products like RealVNC.
-
-*** Nebula
-The first part of our stack is Nebula, the tool that creates a network
-between all of our devices. With traditional VPNs, you have a client
-with a persistent connection to a central VPN server and other clients
-can communicate with the first by going through that central server.
-This works wonderfully in most situations, but there are a lot of
-latency and bandwidth restrictions that would make remote support an
-unpleasant experience. Instead of this model, what we want is a /mesh/
-network, where each client can connect directly to one another /without/
-going through a central system and slowing things down. This is where
-Nebula comes in.
-
-In Nebula's terminology, clients are referred to as /nodes/ and central
-servers are referred to as /lighthouses/, so those are the terms I'll use
-going forward.
-Mesh networks are usually only possible when dealing with devices that
-have static IP addresses. Each node has to know /how/ to connect with the
-other nodes; John can't meet up with Bob when Bob moves every other day
-without notifying anyone of his new address. This wouldn't be a problem
-if Bob phoned Jill and told her where he was moving; John would call
-Jill, Jill would tell him where Bob is, and the two would be able to
-find each other
-
-With Nebula, nodes are Bob and John and Jill is a lighthouse. Each node
-connects to a lighthouse and the lighthouse tells the nodes how to
-connect with one another when they ask. It /facilitates/ the P2P
-connection then /backs out of the way/ so the two nodes can communicate
-directly with each other.
-
-It allows any node to connect with any other node on any network from
-anywhere in the world, as long as one lighthouse is accessible that
-knows the connection details for both peers.
-
-**** Getting started
-The /best/ resource is [[https://github.com/slackhq/nebula][the official documentation,]] but I'll describe the
-process here as well.
-
-After [[https://github.com/slackhq/nebula#1-the-nebula-binaries-or-distribution-packages-for-your-specific-platform-specifically-youll-need-nebula-cert-and-the-specific-nebula-binary-for-each-platform-you-use][installing the required packages,]] make sure you have a VPS with a
-static IP address to use as a lighthouse. If you want something dirt
-cheap, I would recommend one of the small plans from [[https://buyvm.net][BuyVM.]] I do have a
-[[https://my.frantech.ca/aff.php?aff=3783][referral link]] if you want them to kick me a few dollars for your
-purchase. [[https://www.hetzner.com/cloud][Hetzner]] (referral: ~ckGrk4J45WdN~) or [[https://www.netcup.eu/][netcup]] (referral:
-~36nc15758387844~) would also be very good options; I've used them all and
-am very comfortable recommending them.
-
-**** Creating a Certificate Authority
-After picking a device with a static IP address, it needs to be set up
-as a lighthouse. This is done by first creating a Certificate Authority
-(CA) that will be used for signing keys and certificates that allow our
-other devices into the network. The ~.key~ file produced by the following
-command is incredibly sensitive; with it, anyone can authorise a new
-device and give it access to your network. Store it in a safe,
-preferably encrypted location.
+Five days ago at the time of writing, [[https://github.com/crsib][Dmitry Vedenko]] opened a Pull
+Request (PR) in [[https://github.com/audacity/audacity/pull/835][Audacity's GitHub repository]] entitled [[https://github.com/audacity/audacity/pull/835][/Basic telemetry
+for the Audacity/.]] About two days later, all hell broke loose. That PR
+now has over 3.3 thousand downvotes and more than one thousand comments
+from nearly 400 individuals. I started reading the posts shortly after
+they began and kept up with them over the following days, reading every
+single new post. I recognise that few people are going to feel like
+wading through over 1k comments so this is my attempt to provide a
+summary of the PR itself using the community's code reviews along with a
+summary of the various opinions conveyed in the comments.
-#+BEGIN_SRC bash
- nebula-cert ca -name "nebula.example.com"
-#+END_SRC
+When I reference comments, I'll provide a footnote that includes a link
+to the comment and a link to a screenshot just in case it's removed or
+edited in the future.
-I'll explain why we used a Fully-Qualified Domain Name (FQDN) as the
-CA's name in a later section. If you have your own domain, feel free to
-use that instead; it doesn't really matter what domain is used as long
-as the format is valid.
+*** Audacity's acquisition
-**** Generating lighthouse credentials
-Now that we have the CA's ~.crt~ and ~.key~ files, we can create and sign
-keys and certificates for the lighthouse.
+I haven't been able to find /much/ information in this area so forgive me
+if I'm scant on details.
-#+BEGIN_SRC bash
- nebula-cert sign -name "buyvm.lh.nebula.example.com" -ip "192.168.100.1/24"
-#+END_SRC
+On 30 April, a company called [[https://mu.se/][Muse Group]] acquired [[https://www.audacityteam.org/][Audacity.]] According to
+[[https://mu.se][their website]], Muse is the parent company behind many musical
+applications and tools. It was founded by Eugeny Naidenov just days
+before it acquired Audacity. Before all of this, Eugeny Naidenov founded
+[[https://www.ultimate-guitar.com/][Ultimate Guitar]] (UG) in 1998. The service grew rather quickly and now
+has over 300 million users. UG acquired [[https://deanzelinsky.com/][Dean Zelinsky Guitars]] in 2012,
+[[http://agilepartners.com/][Agile Partners]] in 2013, [[https://musescore.org/][MuseScore]] in 2017, and [[http://trycrescendo.com/][Crescendo]] in 2018. Muse
+Group was established in 2021 and it seems as if all of the services UG
+acquired were (or will be) transferred to Muse Group, as well as UG
+itself. Immediately following its establishment, Muse not only acquired
+Audacity but also [[https://www.staffpad.net/][StaffPad.]]
-Here, we're using a FQDN for the same reason as we did in the CA. You
-can use whatever naming scheme you like, I just prefer
-~<vps-host>.lh.nebula...~ for my lighthouses. The IP address can be on any
-of the following private IP ranges, I just happened to use ~192.168.100.X~
-for my network.
+I say 30 April because that's when Muse published their [[https://mu.se/newsroom/tpost/6dhedma301-muse-group-acquires-audacity-expanding-c][press release]]
+and when Martin Keary (Tantacrul) published a video entitled [[https://www.youtube.com/watch?v=RMWNvwLiXIQ][/I’m now in
+charge of Audacity. Seriously./]] According to his comment,[fn:17] Martin
+will help with proposing Audacity's roadmap and many of its future
+features as well as working with the community. This has been his role
+with MuseScore since he joined that project and he will be continuing it
+here.
-| IP Range | Number of addresses |
-|-------------------------------+---------------------|
-| 10.0.0.0 – 10.255.255.255 | 16 777 216 |
-| 172.16.0.0 – 172.31.255.255 | 10 48 576 |
-| 192.168.0.0 – 192.168.255.255 | 65 536 |
+~-----BEGIN PERSONAL OPINION-----~
-**** Creating a config file
-The next step is creating our lighthouse's config file. The reference
-config can be found in [[https://github.com/slackhq/nebula/blob/master/examples/config.yml][Nebula's repo.]] We only need to change a few of
-the lines for the lighthouse to work properly. If I don't mention a
-specific section here, I've left the default values.
+Looking at [[https://www.martinkeary.com/][his website,]] I also suspect he will play a large role in
+redesigning Audacity's interface. Considering that he was instrumental
+in designing [[https://www.martinkeary.com/#/ubuntu-touch-os/][the best mobile interface I've ever had the absolute
+pleasure of experiencing,]] I have high hopes that this is the case.
-The section below is where we'll define certificates and keys. ~ca.crt~
-will remain ~ca.crt~ when we copy it over but I like to leave the node's
-cert and key files named as they were when generated; this makes it easy
-to identify nodes by their configs. Once we copy everything over to the
-server, we'll add the proper paths to the ~cert~ and ~key~ fields.
+~------END PERSONAL OPINION------~
-#+BEGIN_SRC yaml
- pki:
- ca: /etc/nebula/ca.crt
- cert: /etc/nebula/
- key: /etc/nebula/
-#+END_SRC
+*** Telemetry implementation
+**** Implementation Basics
-The next section is for identifying and mapping your lighthouses. This
-needs to be present in /all/ of the configs on /all/ nodes, otherwise they
-won't know how to reach the lighthouses and will never actually join the
-network. Make sure you replace ~XX.XX.XX.XX~ with whatever your VPS's
-public IP address is. If you've used a different private network range,
-those changes need to be reflected here as well.
+A few days after the acquisition, a PR was opened that adds /Basic
+telemetry for the Audacity/. This implementation collects "application
+opened" events and sends those to Yandex to estimate the number of
+Audacity users. It also collects session start and end events, errors
+for debugging, file used for import and export, OS and Audacity
+versions, and the use of effects, generators, and analysis tools so they
+can prioritise future improvements. Sending this data would be optional
+and the user would be presented with a dialogue the first time they
+launch the application after installation or after they update to the
+including release. This description was mostly copied directly from [[https://github.com/audacity/audacity/pull/835#issue-629891447][the
+PR description itself.]]
-#+BEGIN_SRC yaml
- static_host_map:
- "192.168.100.1": ["XX.XX.XX.XX:4242"]
-#+END_SRC
+**** Frontend Implementation
+This is fairly straightforward and a pretty standard UI for prompting
+users to consent to analytics and crash logging. This section is
+included because the community has strong opinions regarding the
+language used and its design, but that will be discussed later. The
+screenshot below is copied directly from the PR.
-Below, we're specifying how the node should behave. It is a lighthouse,
-it should answer DNS requests, the DNS server should listen on all
-interfaces on port 53, it sends its IP address to lighthouses every 60
-seconds (this option doesn't actually have any effect when ~am_lighthouse~
-is set to ~true~ though), and this lighthouse should not send reports to
-other lighthouses. The bit about DNS will be discussed later.
+[[~/repos/sites/secluded/static/assets/pngs/audacity-pr/consentdialogue.png][file:~/repos/sites/secluded/static/assets/pngs/audacity-pr/consentdialogue.png]]
-#+BEGIN_SRC yaml
- lighthouse:
- am_lighthouse: true
- serve_dns: true
- dns:
- host: 0.0.0.0
- port: 53
- interval: 60
- hosts:
+**** Backend Implementation
+Many of the code reviews include the reviewer's personal opinion so I
+will summarise the comment, provide the code block in question, and link
+directly to the comment in a footnote.[fn:9]
+
+#+BEGIN_SRC c
+ if (!inputFile.Write (wxString::FromUTF8 (ClientID + "\n")))
+ return false;
#+END_SRC
+[[https://github.com/crsib/audacity/blob/c9264d2478fe2af82aeb6e2a0295b00b3a27ce53/libraries/lib-telemetry/TelemetryManager.cpp#L199-L200][Lines 199-200 of TelemetryManager.cpp]] save the user's unique client ID
+to a file.[fn:8] This allows the analytics tool (in this case, Google
+Analytics) to aggregate data produced by a single user.
-The next bit is about [[https://en.wikipedia.org/wiki/Hole_punching_%28networking%29][hole punching]], also called /NAT punching/, /NAT
-busting/, and a few other variations. Make sure you read the comments for
-better explanations than I'll give here. ~punch: true~ enables hole
-punching. I also like to enable ~respond~ just in case nodes are on
-particularly troublesome networks; because we're using this as a support
-system, we have no idea what networks our nodes will actually be
-connected to. We want to make sure devices are available no matter where
-they are.
+#+BEGIN_SRC c
+ def_vars()
-#+BEGIN_SRC yaml
- punchy:
- punch: true
- respond: true
- delay: 1s
+ set( CURL_DIR "${_INTDIR}/libcurl" )
+ set( CURL_TAG "curl-7_76_0")
#+END_SRC
+[[https://github.com/crsib/audacity/blob/c9264d2478fe2af82aeb6e2a0295b00b3a27ce53/cmake-proxies/libcurl/CMakeLists.txt#L3-L6][Lines 3-6 of CMakeLists.txt]] "vendor in" libcurl.[fn:10] This is when an
+application directly includes sources for a utility rather than making
+use utilities provided by the system itself.
-~cipher~ is a big one. The value /must/ be identical on /all/ nodes /and/
-lighthouses. ~chachapoly~ is more compatible so it's used by default. The
-devices /I/ want to connect to are all x86 Linux, so I can switch to ~aes~
-and benefit from [[https://www.reddit.com/r/networking/comments/iksyuu/comment/g3ra5cv/?utm_source=share&utm_medium=web2x&context=3][a small performance boost.]] Unless you know /for sure/
-that you won't need to work with /anything/ else, I recommend leaving it
-set to ~chachapoly~.
-
-#+BEGIN_SRC yaml
- cipher: chachapoly
+#+BEGIN_SRC c
+ ExternalProject_Add(curl
+ PREFIX "${CURL_DIR}"
+ INSTALL_DIR "${CURL_DIR}"
+ GIT_REPOSITORY https://github.com/curl/curl
+ GIT_TAG ${CURL_TAG}
+ GIT_SHALLOW Yes
+ CMAKE_CACHE_ARGS ${CURL_CMAKE_ARGS}
+ )
#+END_SRC
+[[https://github.com/crsib/audacity/blob/c9264d2478fe2af82aeb6e2a0295b00b3a27ce53/cmake-proxies/libcurl/CMakeLists.txt#L29-L36][Lines 29-36 of CMakeLists.txt]] add curl as a remote dependency.[fn:11]
+This means that the machine building Audacity from its source code has
+to download curl during that build.
-The last bit I modify is the firewall section. I leave most everything
-default but /remove/ the bits after ~port: 443~. I don't /need/ the ~laptop~ and
-~home~ groups (groups will be explained later) to access port ~443~ on this
-node, so I shouldn't include the statement. If you have different needs,
-take a look at the comment explaining how the firewall portion works and
-make those changes.
+#+BEGIN_SRC c
+ S.Id (wxID_NO).AddButton (rejectButtonTitle);
+ S.Id (wxID_YES).AddButton (acceptButtonTitle)->SetDefault ();
+#+END_SRC
+[[https://github.com/crsib/audacity/blob/c9264d2478fe2af82aeb6e2a0295b00b3a27ce53/src/telemetry/TelemetryDialog.cpp#L93-L94][Lines 93-94 of TelemetryDialog.cpp]] add buttons to the dialogue asking
+the user whether they consent to data collection.[fn:12] ~SetDefault~
+focuses the button indicating that the user does consent. This means
+that if the user doesn't really look at the dialogue and presses
+Spacebar or Enter, or if they do so accidentally by simply bumping the
+key, they unintentionally consent to data collection. If the user
+desires, this can later be changed in the settings menu. However, if
+they weren't aware what they were consenting to /or that they did
+consent/, they won't know to go back and opt out.
-Again, I /remove/ the following bit from the config.
+There are other problems with the code that include [[https://github.com/audacity/audacity/pull/835#discussion_r628816050][simple mistakes,]]
+[[https://github.https://github.com/audacity/audacity/pull/835#discussion_r628774985][styling that's inconsistent with the rest of the project,]] [[https://github.com/audacity/audacity/pull/835#discussion_r628500849][unhandled
+return values resulting in skewed data,]] [[https://github.com/audacity/audacity/pull/835#discussion_r628792423][use of inappropriate functions,]]
+and [[https://github.com/audacity/audacity/pull/835#discussion_r628818054][spelling errors in the comments.]] I believe these are less important
+than those above so they won't be discussed.
-#+BEGIN_SRC yaml
- - port: 443
- proto: tcp
- groups:
- - laptop
- - home
-#+END_SRC
+*** Community opinions
+There were many strong opinions regarding both the frontend and backend
+implementations of this PR, from the wording of the dialogue and
+highlighting the consent button to devices running something other than
+Windows and macOS not being able to send telemetry and thus skewing the
+data that /was/ collected.
-**** Setting the lighthouse up
-We've got the config, the certificates, and the keys. Now we're ready to
-actually set it up. After SSHing into the server, grab the [[https://github.com/slackhq/nebula/releases/latest][latest
-release of Nebula for your platform,]] unpack it, make the ~nebula~ binary
-executable, then move it to ~/usr/local/bin~ (or some other location
-fitting for your platform).
+**** Opinions on the frontend
-#+BEGIN_SRC bash
- wget https://github.com/slackhq/nebula/releases/download/vX.X.X/nebula-PLATFORM-ARCH.tar.gz
- tar -xvf nebula-*
- chmod +x nebula
- mv nebula /usr/local/bin/
- rm nebula-*
-#+END_SRC
+Really, the only frontend here is the consent dialogue. However, there
+are /many/ comments about it, the most common of which is probably that
+the wording is not only too vague[fn:13] but also inaccurate.[fn:14] The
+assertion that Google Analytics are not anonymous and any data sent can
+be trivially de-anonymised (or de-pseudonymised) is repeated many times
+over. Below are a few links to comments stating such. I searched for the
+term /"anonymous"/, copied relevant links, and stopped when my scrollbar
+reached halfway down the page.
-Now we need a place to store our config file, keys, and certificates.
+- [[https://github.com/audacity/audacity/pull/835#discussion_r628156527][r628156527]]
+- [[https://github.com/audacity/audacity/pull/835#issuecomment-833969780][833969780]]
+- [[https://github.com/audacity/audacity/pull/835#issuecomment-833969933][833969933]]
+- [[https://github.com/audacity/audacity/pull/835#discussion_r627995927][r627995927]]
+- [[https://github.com/audacity/audacity/pull/835#issuecomment-834358022][834358022]]
+- [[https://github.com/audacity/audacity/pull/835#issuecomment-834377549][834377549]]
+- [[https://github.com/audacity/audacity/pull/835#issuecomment-834382007][834382007]]
+- [[https://github.com/audacity/audacity/pull/835#issuecomment-834385463][834385463]]
+- [[https://github.com/audacity/audacity/pull/835#issuecomment-834405825][834405825]]
+- [[https://github.com/audacity/audacity/pull/835#issuecomment-834531779][834531779]]
+- [[https://github.com/audacity/audacity/pull/835#issuecomment-834546874][834546874]]
+- [[https://github.com/audacity/audacity/pull/835#issuecomment-834638000][834638000]]
-#+BEGIN_SRC bash
- mkdir /etc/nebula/
-#+END_SRC
+The next most pervasive comment is regarding the consent buttons at the
+bottom of the dialogue where users opt in or out.[fn:15] Many individuals call
+this design a /dark pattern/. Harry Brignull, a UX specialist focusing on
+deceptive interface practises, describes dark patterns as [[https://www.darkpatterns.org/][/tricks used
+in websites and apps that make you do things that you didn't mean to/.]]
+The dark pattern in this situation is the opt-in button being
+highlighted. Many community members assert that users will see the big
+blue button and click it without actually reading the dialogue's
+contents. They just want to record their audio and this window is a
+distraction that prevents them from doing so; it needs to get out of the
+way and the quickest way to dismiss it is clicking that blue button.
+Below is a list of some comments criticising this design.
-The next step is copying the config, keys, and certificates to the
-server. I use ~rsync~ but you can use whatever you're comfortable with.
-The following four files need to be uploaded to the server.
+ - [[https://github.com/audacity/audacity/pull/835#issuecomment-834286641][834286641]]
+ - [[https://github.com/audacity/audacity/pull/835#issuecomment-834358022][834358022]]
+ - [[https://github.com/audacity/audacity/pull/835#issuecomment-834399813][834399813]]
+ - [[https://github.com/audacity/audacity/pull/835#issuecomment-834479968][834479968]]
+ - [[https://github.com/audacity/audacity/pull/835#issuecomment-835250737][835250737]]
+ - [[https://github.com/audacity/audacity/pull/835#issuecomment-835253882][835253882]]
+ - [[https://github.com/audacity/audacity/pull/835#issuecomment-835291066][835291066]]
+ - [[https://github.com/audacity/audacity/pull/835#issuecomment-835445481][835445481]]
-- ~config.yml~
-- ~ca.crt~
-- ~buyvm.lh.nebula.example.com.crt~
-- ~buyvm.lh.nebula.example.com.key~
+Another issue that was brought up by a couple of individuals was the
+lack of a privacy policy.[fn:16] The consent dialogue links to one, but, at the
+time of writing, one does not exist at [[https://www.audacityteam.org/contact/privacy-policy/][the provided URL.]] I have [[https://web.archive.org/web/20210510012924/https://www.audacityteam.org/contact/privacy-policy/][archived
+the state of the page]] in case that changes in the future.
-With ~rsync~, that would look something like this. Make sure ~rsync~ is also
-installed on the VPS before attempting to run the commands though;
-you'll get an error otherwise.
+**** Opinions on the backend
-#+BEGIN_SRC bash
- rsync -avmzz ca.crt user@example.com:
- rsync -avmzz config.yml user@example.com:
- rsync -avmzz buyvm.lh.* user@example.com:
+#+BEGIN_SRC c
+ if (!inputFile.Write (wxString::FromUTF8 (ClientID + "\n")))
+ return false;
#+END_SRC
-SSH back into the server and move everything to ~/etc/nebula/~.
-
-#+BEGIN_SRC bash
- mv ca.crt /etc/nebula/
- mv config.yml /etc/nebula/
- mv buyvm.lh* /etc/nebula/
-#+END_SRC
+The issue many individuals take with this snippet is saving the
+~ClientID~. Say an individual has an odd file that causes Audacity to
+crash any time they try to open it. Say they attempt to open it a
+hundred times. Without giving the client a unique ID, it could look like
+there are 100 people having an issue opening a file instead of just the
+one. However, by virtue of each installation having an entirely unique
+ID, this telemetry /is not anonymous/. Anonymity would be sending
+statistics in such a way that connecting those failed attempts to a
+single user would be impossible. At best, this implementation is
+/pseudonymous/ because the client is given a random ID, you don't have to
+sign in with an account or something.
-Edit the config file and ensure the ~pki:~ section looks something like
-this, modified to match your hostnames of course.
+#+BEGIN_SRC c
+ def_vars()
-#+BEGIN_SRC yaml
- pki:
- ca: /etc/nebula/ca.crt
- cert: /etc/nebula/buyvm.lh.nebula.example.com.crt
- key: /etc/nebula/buyvm.lh.nebula.example.com.key
+ set( CURL_DIR "${_INTDIR}/libcurl" )
+ set( CURL_TAG "curl-7_76_0")
#+END_SRC
-Run the following command to make sure everything works properly.
+Timothe Litt's comment gives a good description of why "vendoring in"
+libcurl is a bad idea[fn:19] and Tyler True's comment gives a good
+overview of the pros and cons of doing so.[fn:18] Many people take issue
+with this /specifically/ because it's libcurl. Security flaws in it are
+/very/ common and Audacity's copy would need to be /manually/ kept up to
+date with every upstream release to ensure none of its vulnerabilities
+can be leveraged to compromise users. If the Audacity team was going to
+stay on top of all of the security fixes, they would need to release a
+new version every week or so.
-#+BEGIN_SRC bash
- nebula -config /etc/nebula/config.yml
+#+BEGIN_SRC c
+ ExternalProject_Add(curl
+ PREFIX "${CURL_DIR}"
+ INSTALL_DIR "${CURL_DIR}"
+ GIT_REPOSITORY https://github.com/curl/curl
+ GIT_TAG ${CURL_TAG}
+ GIT_SHALLOW Yes
+ CMAKE_CACHE_ARGS ${CURL_CMAKE_ARGS}
+ )
#+END_SRC
+The problem with downloading curl at build-time is that it's simply
+disallowed for many Linux- and BSD-based operation systems. When a
+distribution builds an application from source, its build dependencies
+are often downloaded ahead of time and, as a security measure, the build
+machine is cut off from the internet to prevent any interference.
+Because this is disallowed, the build will fail and the application
+won't be available on those operation systems.
-The last step is daemonizing Nebula so it runs every time the server
-boots. If you're on a machine using systemd, dropping the following
-snippet into ~/etc/systemd/system/nebula.service~ should be sufficient. If
-you're using something else, check the [[https://github.com/slackhq/nebula/tree/master/examples/][the examples directory]] for more
-options.
-
-#+BEGIN_SRC text
- [Unit]
- Description=nebula
- Wants=basic.target
- After=basic.target network.target
- Before=sshd.service
-
- [Service]
- SyslogIdentifier=nebula
- ExecReload=/bin/kill -HUP $MAINPID
- ExecStart=/usr/local/bin/nebula -config /etc/nebula/config.yml
- Restart=always
+Note, however, that these build machines would have the option to
+disable telemetry at build-time. This means the machine wouldn't attempt
+to download curl from GitHub and the build would succeed but, again,
+telemetry would be disabled for anyone not on Windows or macOS. This
+defeats the whole purpose of adding telemetry in the first place.
- [Install]
- WantedBy=multi-user.target
+#+BEGIN_SRC c
+ S.Id (wxID_NO).AddButton (rejectButtonTitle);
+ S.Id (wxID_YES).AddButton (acceptButtonTitle)->SetDefault ();
#+END_SRC
-We're almost done!
+There was a lot of feedback about the decision to highlight the consent
+button but that was mentioned up in the frontend section; I won't rehash
+it here.
-**** Setting individual nodes up
-This process is almost exactly the same as setting lighthouses up. All
-you'll need to do is generate a couple of certs and keys then tweak the
-configs a bit.
+**** Broader and particularly well-structured comments
+These are simply some comments I feel deserve particular attention.
-The following command creates a new cert/key for USER's node with the IP
-address ~192.168.100.2~. The resulting files would go on the /remote/ node
-not yours. Replace ~HOST~ and ~USER~ with fitting values.
+From SndChaser...
+- [[https://github.com/audacity/audacity/pull/835#issuecomment-834037351][834037351]]
+-
-#+BEGIN_SRC bash
- nebula-cert sign -name "HOST.USER.nebula.example.com" -ip "192.168.100.2/24"
-#+END_SRC
+*** The Audacity team's response
-The following command will create a /similar/ cert/key but it will be part
-of the ~support~ group. The files resulting from this should go on /your/
-nodes. With the config we'll create next, nodes in the ~support~ group
-will be able to VNC and SSH into other nodes. Your nodes need to be in
-the ~support~ group so you'll have access to the others.
-#+BEGIN_SRC bash
- nebula-cert sign -name "HOST.USER.nebula.example.com" -ip "192.168.100.2/24" -groups "support"
-#+END_SRC
+-----------------
-On to the config now. This tells the node that it is /not/ a lighthouse,
-it should /not/ resolve DNS requests, it /should/ ping the lighthouses and
-tell them its IP address every 60 seconds, and the node at ~192.168.100.1~
-is one of the lighthouses it should report to and query from. If you
-have more than one lighthouse, add them to the list as well.
+*** The privacy policy modification
-#+BEGIN_SRC yaml
- lighthouse:
- am_lighthouse: false
- #serve_dns: false
- #dns:
- #host: 0.0.0.0
- #port: 53
- interval: 60
- hosts:
- - "192.168.100.1"
-#+END_SRC
+https://github.com/audacity/audacity/issues/1213#issuecomment-875274890
-The other bit that should be modified is the ~firewall:~ section and this
-is where the groups we created earlier are important. Review its
-comments and make sure you understand how it works before proceeding.
+** TODO Catchy title about Supernote being "the new paper" :Supernote:Writing:Productivity:Organisation:
+:PROPERTIES:
+:EXPORT_FILE_NAME: something-about-supernote
+:EXPORT_HUGO_CUSTOM_FRONT_MATTER: :toc true
+:END:
-We want to allow inbound connections on ports 5900, the standard port
-for VNC, and 22, the standard for SSH. Additionally, we /only/ want to
-allow connections from nodes in the ~support~ group. Any /other/ nodes
-should be denied access.
+I like writing things down. I like the feel of the pen (preferably a
+fountain pen) gliding smoothly over the paper, that nice solid feeling
+of the tip against the table, seeing the ink dry as it flows from the
+nib, accidentally swiping my hand through it before it's finished and
+smearing a bit of ink across the page, then cursing under my breath as I
+dab it up with a handkerchief or a napkin or something else nearby. I
+also love that writing things by hand [[https://journals.sagepub.com/doi/abs/10.1177/0956797614524581][has an impact on memory and
+improves retention.]]
-Note that including this section is not necessary on /your/ nodes, those
-in the ~support~ group. It's only necessary on the remote nodes that
-you'll be connecting to. As long as the ~outbound:~ section in the config
-on /your/ node allows any outbound connection, you'll be able to access
-other nodes.
+*** The problem
+Unfortunately, I don't love keeping up with that paper. Across many
+different classes, even with dedicated folders for each one, something
+important inevitably gets lost. Notebooks are also bulky and can take up
+a lot of space. I tried [[https://bulletjournal.com/][bullet journalling]] for about a month earlier
+this year and, while the process was enjoyable, the maintenance was not.
+My brain moves faster than my pen (even though I have terrible
+handwriting) and I inevitably forget letters or even whole words. This
+is a problem while writing in pen because white-out looks ugly and I
+dislike wasting whole pages because of a couple mistakes.
-#+BEGIN_SRC yaml
- - port: 5900
- proto: tcp
- groups:
- - support
+The obvious solution here is to get an iPad with an Apple Pen, right?
+Right??
- - port: 22
- proto: tcp
- groups:
- - support
-#+END_SRC
+Wrong because Apple bad.[fn:2]
-The certs, key, config, binary, and systemd service should all be copied
-to the same places on all of these nodes as on the lighthouse.
+*** The solution
+Enter the world of ... what are they even called? E-ink notebooks? Paper
+tablets? E-R/W?[fn:1] Do they even have a "device category" yet? I don't
+know, but they solve my problem in a wonderful way.
-*** X11vnc
-/Alright./ The hardest part is finished. Now on to setting ~x11vnc~ up on
-the nodes you'll be supporting.
+As the names suggest, these are devices that can /usually/ open and read
+e-books (EPUBs, PDFs, etc.), annotate them, and create standalone pages
+of notes as if they were full notebooks. The most well-known of these
+devices is likely the [[https://remarkable.com/][reMarkable.]] They had a [[https://venturebeat.com/2019/10/08/remarkable-raises-15-million-to-bring-its-e-paper-tablets-to-more-scribblers/][hugely successful
+crowdfunding campaign]] and produced the reMarkable 1, followed by [[https://blog.remarkable.com/remarkable-2-the-next-generation-paper-tablet-91b47d0080cb][the
+reMarkable 2 in 2020.]] There are a few devices like these by now but
+we'll look at the reMarkable first.
-All you should need to do is install ~x11vnc~ using the package manager
-your distro ships with, generate a 20 character password with ~pwgen -s
-20 1~, run the following command, paste the password, wait for ~x11vnc~ to
-start up, make sure it's running correctly, press ~Ctrl~ + ~C~, then add the
-command to the DE's startup applications!
+*** The reMarkable
+This device boasts all of the features I was looking for. It renders
+digital content, from books and manuals to comics and manga, allows you
+to mark those documents up as you would if they were physical media,
+create full notebooks of hand written text, organise them, search, and,
+if your handwriting is legible enough (mine certainly is not), perform
+OCR on your notes and email a transcription to yourself. It even runs
+Linux and the developers have opened SSH up so you can remote in and
+tinker with it as much as you like. Because of this, there's a pretty
+awesome [[https://github.com/reHackable/awesome-reMarkable][community of people creating third-party tools and integrations]]
+that add even further functionality. My favourite is probably [[https://github.com/bordaigorl/rmview][rMview,]] a
+really fast VNC client for the reMarkable that allows you to view your
+device's screen on any computer.
-#+BEGIN_SRC bash
- x11vnc --loop -usepw -listen <nebula-ip> -display :0
-#+END_SRC
+After watching all of [[https://www.youtube.com/c/MyDeepGuide][MyDeepGuide's]] [[https://www.youtube.com/playlist?list=PLsSI9-gaSSmiXwb7Vjk5Vb-nB41UTnrXd][extensive playlist on the
+reMarkable,]] however, I decided to go with a different product.
+
+*** Enter the Supernote A5X
+The [[https://www.supernote.com/#/product?type=SN-A5-X][Supernote A5X]] has all of the basic features the reMarkable has:
+reading documents, writing notes, and organising your content. Its
+implementation, on the other hand, seems to be much more polished. It
+also lacks some features from the reMarkable while adding others.
-~--loop~ tells ~x11vnc~ to restart once you disconnect from the session.
-~-usepw~ is pretty self-explanatory. ~-listen <nebula-ip>~ is important; it
-tells ~x11vnc~ to only listen on the node's Nebula IP address. This
-prevents randos in a coffee shop from seeing an open VNC port and trying
-to brute-force the credentials. ~-display :0~ just defines which X11
-server display to connect to.
+*** Operating System
+While the reMarkable runs Codex,[fn:3] a /"custom Linux-based OS
+optimised for low-latency e-paper"/, the Supernote just runs Android.
+There are both benefits and detriments to this; on one hand, they're
+running all of Android, bloated that it is, on a very lightweight
+tablet. On the other, they don't have to develop and maintain a custom
+operating system. This allows them to focus on other aspects that are
+arguably more important so I don't actually mind that it runs Android.
-Some distributions like elementaryOS and those that use KDE and GNOME
-will surface a dialogue for managing startup applications if you just
-press the Windows (Super) key and type ~startup~. If that doesn't work,
-you'll have to root around in the settings menus, consult the
-distribution's documentation, or ask someone else that might know.
+The only place that Android stands out is in system operations; file
+transfer uses MTP and, when you swipe down from the top of the device, a
+small bar appears similar to what was in early Android. This lets you
+change WiFi networks, sync with the Supernote Cloud, take a screenshot,
+search, and access the system settings. Nothing else about the device
+really screams Android to me.
-After adding it to the startup application, log out and back in to make
-sure it's running in the background.
+*** Community
+I don't usually browse Reddit but [[https://old.reddit.com/r/Supernote/][the Supernote community]] there is
+fascinating. I haven't looked around enough to know exactly what his
+relationship is with the company, but one of the members, [[https://old.reddit.com/user/hex2asc][u/hex2asc,]]
+seems to represent Supernote in something of an official capacity. He's
+incredibly active and usually responds to posts and questions within a
+day or two.
-*** Remmina
-Now that our network is functioning properly and the VNC server is set
-up, we need something that connects to the VNC server over the fancy
-mesh network. Enter [[https://remmina.org/][Remmina.]] This one goes on /your/ nodes.
+Before I purchased a Supernote, [[https://old.reddit.com/r/Supernote/comments/lhffyd/sync_targets_open_document_formats_and_crossnote/][I wrote a post]] asking about a couple of
+things that concerned me: sync targets, open document formats, and
+cross-note links. I don't really plan to write full documents on the
+device but having the option to do so would still be nice. The other
+features are absolutely killer for me as I would like to maintain a
+Zettelkasten (I wrote about [[/vim-as-a-markdown-editor/][using Vim to do so]] last year but didn't end
+up sticking with it) and manage document synchronisation with my own
+Nextcloud server. The community was quick to respond and confirm that
+Zettelkasten functionality would be implemented soon™. u/hex2asc
+responded /the day after/ and said that WebDAV would be supported but not
+earlier than May (September update: it's still not supported), ODF would
+likely not be supported, and cross-note links were definitely a
+possibility. Another community member has been avidly following the
+subreddit and even put together an [[https://app-rm.roadmunk.com/publish/03e6dca3d769e2b7015f7f48a649cb3f75f44d9e][unofficial roadmap.]]
-Remmina is a multi-protocol remote access tool available in pretty much
-ever distribution's package archive as ~remmina~. Install it, launch it,
-add a new connection profile in the top left, give the profile a
-friendly name (I like to use the name of the person I'll be supporting),
-assign it to a group, such as ~Family~ or ~Friends~, set the Protocol to
-~Remmina VNC Plugin~, enter the node's Nebula IP address in the Server
-field, then enter their username and the 20 character password you
-generated earlier. I recommend setting the quality to Poor, but Nebula
-is generally performant enough that any of the options are suitable. I
-just don't want to have to disconnect and reconnect with a lower quality
-if the other person happens to be on a slow network.
+*** Interfaces
-Save and test the connection!
+**** Home & Organisation
-If all goes well and you see the other device's desktop, you're done
-with the VNC section! Now on to SSH.
+***** TODO Record very short video about home/organisation
-*** SSH
-First off, make sure ~openssh-server~ is installed on the remote node;
-~openssh-client~ would also be good to have, but from what I can tell,
-it's not strictly necessary. You /will/ need ~openssh-client~ on /your/ node,
-however. If you already have an SSH key, copy it over to
-~~/.ssh/authorized_keys~ on the remote node. If you don't, generate one
-with ~ssh-keygen -t ed25519~. This will create an Ed25519 SSH key pair.
-Ed25519 keys are shorter and faster than RSA and more secure than ECDSA
-or DSA. If that means nothing to you, don't worry about it. Just note
-than this key might not interact well with older SSH servers; you'll
-know if you need to stick with the default RSA. Otherwise, Ed25519 is
-the better option. After key generation has finished, copy
-~~/.ssh/id_ed25519.pub~ (note the ~.pub~ extension) from your node to
-~~/.ssh/authorized_keys~ on the remote node. The file /without/ ~.pub~ is your
-/private/ key. Like the Nebula CA certificate we generated earlier, this
-is extremely sensitive and should never be shared with anyone else.
+**** Settings
-Next is configuring SSH to only listen on Nebula's interface; as with
-~x11vnc~, this prevents randos in a coffee shop from seeing an open SSH
-port and trying to brute-force their way in. Set the ~ListenAddress~
-option in ~/etc/ssh/sshd_config~ to the remote node's Nebula IP address.
-If you want to take security a step further, search for
-~PasswordAuthentication~ and set it to ~no~. This means your SSH key is
-/required/ for gaining access via SSH. If you mess up Nebula's firewall
-rules and accidentally give other Nebula devices access to this machine,
-they still won't be able to get in unless they have your SSH key. I
-/personally/ recommend disabling password authentication, but it's not
-absolutely necessary. After making these changes, run ~systemctl restart
-sshd~ to apply them.
+***** TODO Record very short video about settings
-Now that the SSH server is listening on Nebula's interface, it will
-actually fail to start when the machine (re)boots. The SSH server starts
-faster than Nebula does, so it will look for the interface before Nebula
-has even had a chance to connect. We need to make sure systemd waits for
-Nebula to start up and connect before it tells SSH to start; run
-~systemctl edit --full sshd~ and add the following line in the ~[Unit]~
-section, above ~[Service]~.
+**** Writing & Annotating
-#+BEGIN_SRC text
- After=nebula.service
-#+END_SRC
+The following images are screenshots of the full page above with the
+possible UI variations while reading a book. This first one is default,
+with the editing bar at the top. It is exactly the same as what's
+displayed on the blank pages for hand writing full notes. From left to
+right is the Table of Contents toggle, the pen tools (fineliner,
+"fountain" pen,[fn:5] and highlighter), the erasers, lasso select tool,
+undo/redo, context menu, palm rejection toggle, previous page, goto
+page, next page, and exit.
-Even now, there's still a bit of a hiccup. Systemd won't start SSH until
-Nebula is up and running, which is good. Unfortunately, even after
-Nebula has started, it still takes a minute to bring the interface up,
-causing SSH to crash. To fix /this/, add the following line directly below
-~[Service]~.
+[[~/repos/sites/secluded/static/assets/pngs/supernote-reader-default.png]]
-#+BEGIN_SRC text
- ExecStartPre=/usr/bin/sleep 30
-#+END_SRC
+You can hold your finger on that bar and drag it down to detach it from
+the top. The default width exposes all the tools without whitespace. You
+can move it around the screen by dragging the circle with a straight
+line through the middle on the far left.
-If the ~sleep~ executable is stored in a different location, make sure you
-use that path instead. You can check by running ~which sleep~.
+[[~/repos/sites/secluded/static/assets/pngs/supernote-reader-medium.png]]
-When the SSH /service/ starts up, it will now wait an additional 30
-seconds before actually starting the SSH /daemon/. It's a bit of a hacky
-solution but it works™. If you come up with something better, please
-send it to me and I'll include it in the post! My contact information is
-at the bottom of [[/][this site's home page.]]
+If you tap that circle, the width shrinks and everything except the
+pens, erasers, and undo/redo buttons are hidden. It can be dragged the
+same was as in the previous image and tapping that circle will expand
+the bar again.
-After you've made these changes, run ~systemctl daemon-reload~ to make
-sure systemd picks up on the modified service file, then run ~systemctl
-restart sshd~. You should be able to connect to the remote node from your
-node using the following command.
+[[~/repos/sites/secluded/static/assets/pngs/supernote-reader-small.png]]
-#+BEGIN_SRC bash
- ssh USER@<nebula-ip>
-#+END_SRC
+The last mode is with the bar completely hidden. You achieve this just
+by dragging it to the right edge of the screen. Once hidden, you can
+swipe right to left from the edge and it will be revealed flush with the
+right edge.
-If you want to make the command a little simpler so you don't have to
-remember the IP every time, create ~~/.ssh/config~ on your node and add
-these lines to it.
+[[~/repos/sites/secluded/static/assets/pngs/supernote-reader-minimal.png]]
-#+BEGIN_SRC text
- Host USER
- Hostname <nebula-ip>
- User USER
-#+END_SRC
+*** Experience
+**** Reading content
+I love e-ink. I think it looks beautiful and would love to have an e-ink
+monitor.[fn:4] That said, the Supernote has an especially nice display
+with 226 PPI (pixels per inch). The image below was taken with my
+phone's camera so it's not very good. However, if you zoom in a bit, you
+can see that the curved edges of some letters are /slightly/ pixellated.
+Viewing with my naked eye at a comfortable distance, it does look better
+/to me/ than some of my print books, however.
-Now you can just run ~ssh USER~ to get in. If you duplicate the above
-block for all of the remote nodes you need to support, you'll only have
-to remember the person's username to SSH into their machine.
+[[~/repos/sites/secluded/static/assets/pngs/supernote-resolution.png]]
-*** Going further with Nebula
-This section explains why we used FQDNs in the certs and why the DNS
-resolver is enabled on the lighthouse.
+/At the moment,/ I am pretty disappointed with Table of Contents detection
+for ePUBs. A great many of my books seem to use a legacy ToC format that
+the Supernote sees and tries/fails to read before attempting to read the
+more up-to-date one. This is easily remedied by editing the ePUB in
+[[https://calibre-ebook.com/][Calibre,]] going to Tools → Upgrade Book Internals → Remove the legacy
+Table of Contents in NCX format. You might need to make a small change
+to one of the HTML files and revert it before the save button is
+enabled. After that, just copy it back over to the Supernote and
+everything should work properly.
-Nebula ships with a built-in resolver meant specifically for mapping
-Nebula node hostnames to their Nebula IP addresses. Running a public DNS
-resolver is very much discouraged because it can be abused in terrible
-ways. However, the Nebula resolver mitigates this risk because it /only/
-answers queries for Nebula nodes. It doesn't forward requests to any
-other servers nor does it attempt to resolve any domain other than what
-was defined in its certificate. If you use the example I gave above,
-that would be ~nebula.example.com~; the lighthouse will attempt to resolve
-any subdomain of ~nebula.example.com~ but it will just ignore ~example.com~,
-~nebula.duckduckgo.com~, ~live.secluded.site~, etc.
+**** Writing notes
+I write notes as often if not /more/ often than I read and annotate books.
+It's the main reason I purchased the device and I love the experience.
+The Supernote doesn't /really/ feel like paper despite what their
+marketing materials claim, though it doesn't feel /bad/ either. It's hard
+to describe but I would say it's something like writing with a
+rollerball pen on high-quality paper with a marble counter underneath:
+incredibly smooth with but a little bit of texture so it doesn't feel
+like writing on a glass display.
-Taking advantage of this resolver requires setting it as your secondary
-resolver on any device you want to be able to resolve hostnames from.
-If you were to add the lighthouse's IP address as your secondary
-resolver on your PC, you could enter ~host.user.nebula.example.com~ in
-Remmina's server settings /instead of/ ~192.168.1.2~.
+While writing latency[fn:6] is noticeable, I really don't have a huge
+issue with it. I write very quickly but find that the slight latency
+actually makes writing /more/ enjoyable. It sounds weird and I'm not sure
+why, but I /really/ like writing on the Supernote; it's wonderfully
+smooth, pressure-sensitive, the latency makes things interesting, and
+[[https://supernote.com/#/part?id=SP-04][the Heart of Metal pen]] feels good in my hand.
-But how you do so is beyond the scope of this post!
+**** Surfacing Content
+While organisation is done using a regular filesystem hierarchy, the
+Supernote does have other ways to search for and surface your notes. As
+you're writing, you can use the lasso select tool and encircle a word. A
+little dialogue pops up and gives you a few buttons for things you can
+do with that selection: copy, move to another page, cut, add it to the
+Table of Contents, or mark it as a key word. If you select the key word
+icon, the Supernote does some incredible OCR[fn:7] on it and displays a
+dialogue where you can add it to the note file as a tag. This dialogue
+allows you to edit the word before adding it just in case the OCR was
+wonky. Even with my terrible handwriting, I've found that it works very
+well and I rarely have to make edits.
-If you're up for some /more/ shenanigans later on down the line, you could
-set up a Pi-Hole instance backed by Unbound and configure Nebula as
-Unbound's secondary resolver. With this setup, you'd get DNS-level ad
-blocking /and/ the ability to resolve Nebula hostname. Pi-Hole would query
-Unbound for ~host.user.nebula.example.com~, Unbound would receive no
-answer from the root servers because the domain doesn't exist outside of
-your VPN, Unbound would fall back to Nebula, Nebula would give it an
-answer, Unbound would cache the answer, tell Pi-Hole, Pi-Hole would
-cache the answer, tell your device, then your device would cache the
-answer, and you can now resolve any Nebula host!
+*** TODO Ping Isi and Volpeon when finished
+** TODO Making yourself overly available
-Exactly how you do /that/ is */definitely/* beyond the scope of this post :P
+*** References
+[[https://www.nytimes.com/2021/03/05/opinion/ezra-klein-podcast-cal-newport.html?showTranscript=1][Stop. Breathe. We Can’t Keep Working Like This.]]
-If you set any of this up, I would be interested to hear how it goes! As
-stated earlier, my contact information is at the bottom of the site's
-home page :)
+*** Notes
+**** Get rid of information that isn't important
+**** Escalate the info that is
+**** Set /clear/ boundaries for when you are available
+**** Enforce those with automatic DnD rules or use timers
+**** With groups...
+***** Specialisation is /good/ and should be /encouraged/
+***** /All/ of the above points apply with coworkers as well
+*** TODO Pong Jake when finished
+** TODO Setting LXC up for local "cloud" development
** TODO Stop using Gmail!
-* Education :@Education:
+* Education :@Education:
** TODO Homeschooling
* Music :@Music:
* Pipe Smoking :@Pipe__Smoking: