From 9e54416ae5e095ef5d47eb0c7a642894dddf46aa Mon Sep 17 00:00:00 2001
From: flu0r1ne <flu0r1ne@flu0r1ne.net>
Date: Wed, 21 Jul 2021 00:47:36 -0500
Subject: Rename posts -> logs

---
 pages/posts/cgit-nginx-ubuntu/cgit-nginx-ubuntu.md |  96 --------
 pages/posts/cgit-nginx-ubuntu/index.tsx            |  12 -
 pages/posts/index.tsx                              |  16 --
 pages/posts/packaging-nebula-for-debian/index.tsx  |  12 -
 pages/posts/packaging-nebula-for-debian/nebula.md  | 263 ---------------------
 pages/posts/posts.md                               |   6 -
 6 files changed, 405 deletions(-)
 delete mode 100644 pages/posts/cgit-nginx-ubuntu/cgit-nginx-ubuntu.md
 delete mode 100644 pages/posts/cgit-nginx-ubuntu/index.tsx
 delete mode 100644 pages/posts/index.tsx
 delete mode 100644 pages/posts/packaging-nebula-for-debian/index.tsx
 delete mode 100644 pages/posts/packaging-nebula-for-debian/nebula.md
 delete mode 100644 pages/posts/posts.md

(limited to 'pages/posts')

diff --git a/pages/posts/cgit-nginx-ubuntu/cgit-nginx-ubuntu.md b/pages/posts/cgit-nginx-ubuntu/cgit-nginx-ubuntu.md
deleted file mode 100644
index c225bd4..0000000
--- a/pages/posts/cgit-nginx-ubuntu/cgit-nginx-ubuntu.md
+++ /dev/null
@@ -1,96 +0,0 @@
-Installing cGit behind NGINX on Ubuntu
-======================================
-
-[cGit](https://git.zx2c4.com/cgit/about/) is a fast web interface based on the CGI specification. It is lightweight and doesn't require a database or web authentication system.
-
-It's easy to configure. For some reason, all the online guides for Ubuntu decided they needed to compile it from scratch and write their own start scripts in a mix of perl and bash. You don't need superhero sysadmin skills from the late 90s. All components are packaged with systemd units... there is a better way...
-
-### 1. Install `cgit` and `fcgiwrap`.
-
-`fcgiwrap` will create a socket NGINX can use to pass the CGI variables to cGit: 
-```
-sudo apt install fcgiwrap
-sudo apt install cgit
-```
-
-### 2. Modify the `cgitrc` file under `/etc/cgitrc` to your liking: 
-```
-# See cgitrc(5)
-# prepend this string to every url
-virtual-root=/
-enable-index-links=1
-enable-commit-graph=1
-
-root-title=My Git Repos
-root-desc=I exclusivly write code in Smalltalk-71
-logo=/assets/my_custom_logo.png
-
-# Add site-specific configuration
-# ...
-
-```
-
-### 3. Optionally create an assets directory and add your custom logo / css:
-```
-mkdir /var/www/html/assets
-cp my_custom_logo.png /var/www/html/assets
-```
-
-### 4. Configure NGINX
-
-Add the site to NGINX. This launches the `cgit.cgi` executable passing it to the `fcgiwrap` socket:
-```conf
-echo >/etc/nginx/sites-available/cgit.conf <<EOF
-server {
-    listen 80;
-
-    server_name  git.domain.com;
-    server_name  www.git.domain.com;
-
-    root /usr/share/cgit;
-
-    # Maintainer overridden assets will live in /assets
-    # This allows you to change add a custom logo or modified CSS
-    # See cgitrc(5)
-    location ~* /assets {
-        root /var/www/html;
-        expires 30d;
-    }
-
-    # Fallback to static assets included by cGit 
-    location ~* ^.+\.(css|png|ico)$ {
-        root /usr/share/cgit;
-        expires 30d;
-    }
-
-    try_files $uri @cgit;
-
-    location @cgit {
-        fastcgi_param   SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
-        fastcgi_param   PATH_INFO       $uri;
-        fastcgi_param   QUERY_STRING    $args;
-        fastcgi_param   HTTP_HOST       $server_name;
-        fastcgi_pass    unix:/run/fcgiwrap.socket;
-    }
-
-    access_log /var/log/nginx/access.log;
-    error_log /var/log/nginx/error.log warn;
-}
-EOF
-```
-
-### 4. Enable the site:
-```bash
-ln -s /etc/nginx/sites-available/git.conf /etc/nginx/sites-enabled/cgit.conf
-```
-
-Note: all files in sites-enabled should be included in `nginx.conf`'s http section:
-```conf
-include /etc/nginx/sites-enabled/*;
-```
-
-### 5. Restart NGINX
-
-```
-sudo systemctl restart nginx
-```
diff --git a/pages/posts/cgit-nginx-ubuntu/index.tsx b/pages/posts/cgit-nginx-ubuntu/index.tsx
deleted file mode 100644
index b510b3b..0000000
--- a/pages/posts/cgit-nginx-ubuntu/index.tsx
+++ /dev/null
@@ -1,12 +0,0 @@
-// @ts-ignore
-import md from './cgit-nginx-ubuntu.md';
-import MarkdownPage from '../../../templates/MarkdownPage';
-
-export default function cGitNGINXUbuntu() {
-  return (
-    <MarkdownPage
-      md={md}
-      path={'/posts/cgit-nginx-ubuntu'}
-    />
-  );
-}
\ No newline at end of file
diff --git a/pages/posts/index.tsx b/pages/posts/index.tsx
deleted file mode 100644
index e139ef5..0000000
--- a/pages/posts/index.tsx
+++ /dev/null
@@ -1,16 +0,0 @@
-import DefaultPage from '../../templates/Default';
-import Markdown from '../../components/Markdown';
-//@ts-ignore
-import md from './posts.md';
-
-export default function Posts() {
-  return(
-    <DefaultPage
-      path={"/posts"}
-    >
-      <Markdown
-        md={md}
-      />
-    </DefaultPage>
-  );
-}
\ No newline at end of file
diff --git a/pages/posts/packaging-nebula-for-debian/index.tsx b/pages/posts/packaging-nebula-for-debian/index.tsx
deleted file mode 100644
index 9d3741d..0000000
--- a/pages/posts/packaging-nebula-for-debian/index.tsx
+++ /dev/null
@@ -1,12 +0,0 @@
-// @ts-ignore
-import md from './nebula.md';
-import MarkdownPage from '../../../templates/MarkdownPage';
-
-export default function NebulaOnDebian() {
-  return (
-    <MarkdownPage
-      md={md}
-      path={'/posts/nebula-on-debian'}
-    />
-  );
-}
\ No newline at end of file
diff --git a/pages/posts/packaging-nebula-for-debian/nebula.md b/pages/posts/packaging-nebula-for-debian/nebula.md
deleted file mode 100644
index d1c178f..0000000
--- a/pages/posts/packaging-nebula-for-debian/nebula.md
+++ /dev/null
@@ -1,263 +0,0 @@
-Packaging Nebula for Debian
-=================
-
-> **Created:** 2021-07-18 **Last Updated:** 2021-07-19
-
-I am close to concluding a multi-week endevor to package [Nebula](https://github.com/slackhq/nebula), a VPN-style network mesh networking overlay. If all goes well, it will be uploaded to `debian/experimental` within the next few days. This would also mean the package would be pulled into Ubuntu during the next merge window.
-
-### Timeline
- 
-Unfortunately, Debian does not adhere to a constant release cycle. This means the timeline is uncertain. It will likely be uploaded to `experimental` within a few days. [See the new queue.](https://ftp-master.debian.org/new.html) It will stay in experimental for the next three months or so until the next release occurs. (It is incompatible with the version of protobuf in unstable. This prevents it from moving into unstable until the next version release.)
-```
-{upload queue} -> [experimental] -> [unstable (sid)] -> [testing] -> [next release]
-```
-
-Preemptively, I'm going to write up a set of install instructions specific to debian derivatives and briefly a few of the decisions made during the packaging process.
-
-Installation
-------------
-
-**Step one will currently fail. See [installing from experimental](#installing-from-experimental)**
-
-For the sake of simplicity, I'm going to assume that you're setting up a network with two nodes -- one lighthouse node and a node on your laptop. Once you understand the process, it easily scales to as many nodes as you wish. Pick your favorite virtualization provider in order to set up the lighthouse. The lighthouse requires minimal resources because it functions as a mutually-reachable node which synchronizes the address mappings. You could use a home server provided that you have a static ip (unlikely) or setup dynamic DNS. The latter may introduce some instability. I'm also assuming both clients are debian derivatives and have access to `apt`.
- 
-If this is not the case, please consult the [upstream instructions](https://github.com/slackhq/nebula#user-content-getting-started-quickly) which will guide you through the processing of installing the binaries directly.
- 
-#### 1. Install Nebula through Aptitude
- 
-You'll need to install Nebula on both endpoints.
- 
-```bash
-sudo apt install nebula
-```
- 
-#### 2. Creating a certificate authority
- 
-The certificate authority is to "root of trust" for a Nebula network. Compromising the certificate authority's key file would compromise the integrity and security of the entire network. The upstream instructions recommend that you store the key file in a location with strong encryption [^1].
- 
-You can generate a `ca.key` and `ca.cert` file with the following command:
-```bash
-nebula-cert ca -name "Myorganization, Inc"
-```
- 
-You will copy the `ca.crt` file to all the hosts. The `ca.key` file should remain secret.
- 
-#### 4. Nebula host keys and certificates generated from that certificate authority
- 
-With your `ca.key` file in hand, generate keys for each node.
- 
-```bash
-nebula-cert sign -name "lighthouse" -ip "192.168.100.1/24"
-nebula-cert sign -name "laptop" -ip "192.168.100.2/24"
-```
- 
-Repeate this process for each node. It is important that each is issued a unique internal ip. The IPs are specified in CIDR notation [^2]. This internal ip will be used to configure Nebula later.
- 
-#### 4. Copy the configuration files to each host
- 
-Each host requires the `host.key`, `host.crt`, and `ca.crt` files to be present on the system. By convention, these are located in the `/etc/nebula` directory. Make sure to copy them into this directory.
- 
-For example, to copy the credentials to a lighthouse with ip `203.0.113.11` as `user` you may use sftp and ssh as follows:
- 
-```bash
-sftp user@203.0.113.11 <<EOF
-put lighthouse.key
-put lighthouse.crt
-put ca.crt
-EOF
-```
- 
-```bash
-ssh user@203.0.113.11
-sudo install -m 600 -o root lighthouse.{key,crt} /etc/nebula
-sudo install -m 600 -o root ca.crt /etc/nebula
-rm ca.crt lighthouse.{key,crt}
-```
- 
-#### 5. Configure your network
- 
-The upstream recommends that you start from an example configuration file:
- 
-```
-cp /usr/share/doc/nebula/examples/config.yml /etc/nebula/my_network.yml
-```
- 
-* On your lighthouse, you'll want to change the `cert` and `key` sections to the paths `/etc/nebula/lighthouse.crt` and `/etc/nebula/ligthouse.key`. Change `am_lighthoue: true`. Remove the lighthouse ip from the `hosts` section under `lighthouse`.
- 
-* On the host, change the `cert` and `key` sections to the paths `/etc/nebula/laptop.crt` and `/etc/nebula/laptop.key`. Ensure the lighthouse is added to the `static_host_map` and the `hosts` section.
- 
-Once you're done, you can test whether your configuration is valid with `nebula-service -test -config /etc/nebula/my_network.yml`.
- 
-#### 6. Bringing up the tunnel
- 
-To start the tunnel, you can use the templated `systemd` service packaged alongside Nebula [^3][^4].
- 
-```bash
-sudo systemctl start nebula@my_network
-```
- 
-There is also a means by which a Nebula lighthouse can be run by a unprivileged user but further configuration is required [^5].
- 
-Once both ends of the tunnel have been started, you should be able to ping the lighthouse from the laptop node and vice versa.
-```bash
-ping 192.168.100.1
-PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
-64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=5.67 ms
-```
- 
-#### 7. Additional Configuration
- 
-Nebula has built-in default deny firewall. The default configuration file allows network traffic `outbound`. (That is, any node is permitted to initiate a connection.) In order for a node to provide services, the port mapping needs to be added to the `inbound` section. For instance, to permit ssh to the lighthouse:
- 
-```yaml
-inbound:
-   - port: 22
-     proto: tcp
-     host: lighthouse
-```
- 
-Now, an ssh connection should be able to be initiated via Nebula's internal ip:
-```bash
-ssh 192.168.100.1
-```
- 
-Once you're happy with the setup, you can automatically start Nebula when the laptop / server boots:
- 
-```bash
-sudo systemctl enable nebula@my_network
-```
- 
-For more information on usage and configuration, you may want to take a look at `nebula.yml(5)`, `nebula(1)`, and `nebula-cert(1)`.
- 
-Enjoy.
-```
-  *  . . *    * .          . *    .      *   .   .   * .
-. * .     .  *      .   *    .     *   .      *    .    *
-.    .   *   .    *   .      *    .     *    .      *   .
-. *   *   .   *   .   *   .    .   *   .     .  *    *   .
-  .     .  *   .         *    .      *   .  *    *  .   .
- *   . *      .   *   .  *   . *    .    *   .   .    *  
-```
- 
-### Installation Footnotes
- 
-[^1] If you're in need of a technology to provide strong encryption, [LUKS](https://guardianproject.info/archive/luks/) is a popular choice on Linux. [Veracrypt](https://www.veracrypt.fr) is a venerable cross-platform encryption application. Some password managers, like KeePassXC, also allow you to attach files.
- 
-[^2] Effectively, this means all nodes will receive an ip in the form "192.168.y.x". The y part is a value in the range [0, 255] and is specific to the network. (Thus, all nodes should have the same "y" value.) "x" should be a unique ip for each node and be in the range [0, 244].
- 
-[^3] The launcher I wrote will detect the `my_network.yml` and `my_network.yaml` files. Do not specify the extension when launching the service. The launcher has no way to discriminate between `my_network.yml` and `my_network.yaml` extension so pick a distinct name for each network.
- 
-[^4] If Nebula is misconfigured, the service will fail without warning. You can check the status of the unit with `systemctl status nebula@my_network`. Nebula can also be started within the terminal using `nebula -conifg /etc/nebula/my_network.yml`.
- 
-[^5] The systemd unit that is packaged with Nebula runs the interface as root. This is what I expect most users will want. If the lighthouse doesn't need to be connected to the network, you can `sudo systemd edit nebula@.serivce` and simply change the `User` section to the user you wish to use to launch Nebula. The user will also need read access to the configuration file, key, and cert files.
- 
-Packaging Notes
----------------
- 
-I am going to create a brief summary of the changes made while packaging. I suspect other distros might benefit from some of the work done to package Debian [^6].
- 
-The Debian package differs from the packaging done on [Arch](https://archlinux.org/packages/community/x86_64/nebula/). There's also a package created for [NixOS](https://github.com/NixOS/nixpkgs/blob/8284fc30c84ea47e63209d1a892aca1dfcd6bdf3/nixos/tests/nebula.nix) but Nix is its own beast.
- 
-### Templating the Unit File
- 
-If we were to use the unit file provided by the upstream project, it would fail without warning until the user fully setup the service because (1) the path of to Nebula configuration was hard coded as `/etc/nebula/config.yml` and (2) the user needed to change the configuration file in order for Nebula to function.
- 
-To make the relationship between the user configuration and the `systemd` unit clear, the `systemd` unit was templated. This also means that there is a clear and simple way to connect one machine to multiple Nebula networks. To accomplish this and support both `.yml` and `.yaml` extension, the systemd file executes a shell script under `/usr/lib/nebula/bin/nebula-systemd-launcher` passing the "instance variable" as the first argument. This script then identifies the proper configuration and launches Nebula with this configuration. The script was installed user `/usr/lib` so that it would not autocomplete in the user's shell.
- 
-### Doc and examples
- 
-- Man pages were generated from the nebula help flag to create `nebula(1)` and `nebula-cert(1)`.
-- `nebula.yml(5)` man page was created to describe the configuration process. It was derived from the comments in the example configuration.
-- The `config.yml` example configuration was installed under `/usr/share/doc/nebula/examples/` so users could copy it into `/etc/nebula` if they wished to use it as a starting point.
- 
-### Patching for Go 1.13
- 
-Debian packages all go dependencies to maintain tight control over the versions used while building go binaries. It also packages `go` itself. Currently, `go 1.16` is not in the debian repos [^7]. The following patch was applied since `net.ErrClosed` is not available in older versions of go.
- 
-```go
---- nebula.orig/sshd/server.go
-+++ nebula/sshd/server.go
-@@ -1,7 +1,7 @@
-package sshd
-import (
--   "errors"
-+   "strings"
-   "fmt"
-   "net"
-   "sync"
-@@ -116,7 +116,8 @@ func (s *SSHServer) run() {
-   for {
-       c, err := s.listener.Accept()
-       if err != nil {
--           if !errors.Is(err, net.ErrClosed) {
-+           str := err.Error()
-+           if !strings.Contains(str, "use of closed network connection"){
-               s.l.WithError(err).Warn("Error in listener, shutting down")
-           }
-           return
-```
- 
-### Dependencies
- 
-- I packaged `golang-github-nbrownus-go-metrics-prometheus` since changes were made to [go-metrics-prometheus](https://github.com/deathowl/go-metrics-prometheus) that were not backwards-compatible
-- I also packaged `golang-github-flynn-noise` since it was not in the debian repositories
- 
-### Packaging footnotes
-[^6] All files used to create the package are located in [Salsa (Debian's VCS)](https://salsa.debian.org/go-team/packages/nebula). All external configuration and build rules are located in the `debian` directory.
- 
-[^7] Actually, it is packaged individually but not under the `golang-go` moniker. I initially compiled it by preloading the `PATH` with `go 1.16` to force `dh-golang` to use those build tools. Thus caused `dh-golang` to misbehave and not harden or strip the binaries. Since the changes required to adapt Nebula to `go 1.13` were minimal, I opted to create a patch.
-
-### Installing from experimental
- 
-This is a temporary aside. As mentioned above, the package is currently bouncing around Debian's packaging infrastructure. I'm assuming at the time of reading that it is in experimental. This is an internal Debian repository which allows maintainers, developers, or the curious to test the newest version of software before it enters the next Debian unstable.
- 
-If you are running `buster`, you cannot install it directly using `apt`. _If you would like to test the package while it is experimental,_ I will offer some instructions here. [All the usual disclaimers apply.](https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian) This is fairly safe since Nebula is a binary package (and doesn't have any runtime dependencies other than glibc).
- 
-There is a remote chance it will segfault due to binary incompatibilities with the version of glibc. If so, run `sudo apt purge nebula` and try installing from source. Building it from sources would require you to pull in a plethora of experimental build dependencies.
- 
-#### 1. Add `experimental` to your `sources.list` file
- 
-```bash
-sudo sh -c "
-sudo cat >/etc/apt/sources.list.d/99-tmp-nebula-overrides.list <<EOF
-# Temporary pull in packages from the experimental distribution
- 
-deb https://deb.debian.org/debian experimental main
-EOF
-"
-```
-#### 2. Demote `experimental` in your `apt` preferences
- 
-```bash
-sudo sh -c "
-sudo cat >/etc/apt/preferences.d/99-tmp-nebula-prefer-stable <<EOF
-Package: *
-Pin: release o=Debian,a=experimental
-Pin-Priority: -10
-"
-```
- 
-#### 3. Update
- 
-```bash
-sudo apt update
-```
- 
-If they above steps succeed, you should see:
-```
-All packages are up to date.
-```
- 
-#### 3. Force APT to install the package from `experimental`
-```bash
-sudo apt install -t experimental nebula
-```
- 
-After installing, you can continue to [creating a certificate authority](#2-creating-a-certificate-authority). Just ensure to remove nebula when you're finished testing.
- 
-#### 4. When you're done testing
-```
-sudo rm /etc/apt/sources.list.d/99-tmp-nebula-overrides.list \
-       /etc/apt/preferences.d/99-tmp-nebula-prefer-stable
-sudo apt purge nebula
-```
diff --git a/pages/posts/posts.md b/pages/posts/posts.md
deleted file mode 100644
index 48fb17b..0000000
--- a/pages/posts/posts.md
+++ /dev/null
@@ -1,6 +0,0 @@
-## Posts
-
-Eclectic thoughts, miscellany, and discursive drivel
-
-- [Packaging Nebula for Debian](/posts/packaging-nebula-for-debian)
-- [Installing cGit behind NGINX on Ubuntu](/posts/cgit-nginx-ubuntu)
-- 
cgit v1.2.3