diff --git a/content/posts/archInstall.adoc b/content/posts/archInstall.adoc
index 6e3385d..c4f7142 100644
--- a/content/posts/archInstall.adoc
+++ b/content/posts/archInstall.adoc
@@ -1,5 +1,5 @@
+++
-title = "Archlinux install with btrfs, systemd-boot, and full-disk encryption"
+title = "Archlinux install with btrfs, systemd-boot, full-disk encryption, and suspend-to-disk"
date = 2021-04-11T19:19:51-05:00
draft = false
+++
@@ -11,8 +11,6 @@ draft = false
:toc:
:toclevels: 6
-== Installing btrfs, systemd-boot, and LUKS with suspend to disk on encrypted swap partition.
-
Ive been using archlinux for several years now.
Of course, my first installs were... blunderous, as i wanted to do full disk encryption from the get-go, and I didnt know what I was doing.
After those first one or two installs, I generally settled on LVM on LUKS with a GRUB bootloader and my swap on an LVM volume,
@@ -25,7 +23,7 @@ With my newest laptop, I decided to try out btrfs, in large part due to its snap
However, suspend-to-disk is also quite important to me, and the archwiki is really only clear on how to do that with unencrypted partitions, LVM on LUKS, and on swapfiles.
The archwiki has some info on how to do it for the encrypt hook with a custom mkinitcpio hook, or with sd-encrypt hooks by just specifying multiple devices, but I didnt want to be writing a ton of custom config for the encrypt hook, and the section on sd-encrypt was not very clear at all, so I decided to do some experimentation and write up what worked for me.
-=== A note on security and risk profiles
+== A note on security and risk profiles
The encryption schema I am setting up in this guide is only meant to protect your data from theft of your physical device when it is turned off or suspended to the disk.
Full disk encryption will not protect you from anything while you laptop is powered on. After boot, the encryption is completely transparent to userspace.
@@ -33,9 +31,9 @@ Full disk encryption will not protect you from anything while you laptop is powe
Also, I did am not encrypting the boot partition, and Im not setting up any sort of secure boot.
This means that an attacker could hypothetically replace your boot partition or firmware and keylog your password, so if you suspect your computer has been tampered with, *DONT* boot it up.
-To reiterate, this setup by itself only protect your data if your powered down machine is stolen. It does not protect you data from being stolen in any scenario where your laptop is powered on.
+To reiterate, this setup by itself only protect your data if your powered down machine is stolen. It does not protect you data from being stolen in any scenario where your laptop is powered on after or during tampering.
-=== Things you should do first
+== Things you should do first
Because some things are quite dependent on your system and network, as well as the type of system you end up with,
I will not be detailing some of the early setup steps, such as creating and booting from the arch ISO, or the final steps,
@@ -48,16 +46,16 @@ You should clearly understand what most of these commands do before typing them
Anyway, start by booting up the arch ISO...
-=== Installing via ssh
+== Installing via ssh
Sometimes, you dont want to be switching from the computer you are installing linux on and the computer with the documentation and a search engine on it,
and Ive found the best way to avoid that is to set up a simple ssh session from the arch ISO to the computer with the documentation on it.
[WARNING]
-====
+===
On a normal, already installed machine, *NEVER* use just a password for SSH. *ESPECIALLY* if it is internet-facing or connected to a public network.
We are only doing this because we are (hopefully) on a personal network, and the password-based SSH session only exists on the Arch ISO, so as soon as you boot into your fresh system, the SSH session will be gone.
-====
+===
On the installee, make a password for the root account
@@ -95,7 +93,7 @@ and type in the password you set on the installee
now lets continue with the installation.
-=== inital setup
+== inital setup
verify you are connected to the internet
@@ -109,7 +107,7 @@ turn on ntp
$ timedatectl set-ntp true
{{}}
-=== Partitioning
+== Partitioning
create partitions using the tools of your choice. I will be using the following partition map.
@@ -119,7 +117,7 @@ a swap partition with a size equal to your RAM.
a btrfs partition containing the rest of the space.
-=== Encryption
+== Encryption
Encrypt the btrfs parition with
@@ -147,7 +145,7 @@ $ cryptsetup open /dev/sda2 swap
$ cryptsetup open /dev/sda3 btrfs
{{}}
-=== Filesystem creation
+== Filesystem creation
format the EFI partition with FAT32 and give it the label EFI (label can be something else.)
@@ -167,7 +165,7 @@ format the root partition with btrfs and give the label root (label can be somet
$ mkfs.btrfs -L btrfs /dev/mapper/btrfs
{{}}
-=== Creating and mounting subvolumes
+== Creating and mounting subvolumes
{{}}
$ mount /dev/mapper/btrfs /mnt
@@ -195,7 +193,7 @@ $ mount /dev/sda1 /mnt/boot
$ swapon /dev/mapper/swap
{{}}
-=== installing base system, generating *stab
+== installing base system, generating *stab
install the base packages. ajust the package list to suit your needs. change intel-ucode to amd-ucode if using an AMD processor.
@@ -219,7 +217,7 @@ $our main device
btrfs LABEL=btrfs
{{}}
-=== system config
+== system config
chroot into the new system
@@ -267,7 +265,7 @@ and add matching entries to /etc/hosts, like so (if static ip, use that. if dyna
127.0.1.1 myhostname.localdomain myhostname
{{}}
-=== installing the boot loader
+== installing the boot loader
edit /etc/mkinitcpio.conf so the HOOKS line looks like this:
@@ -306,7 +304,7 @@ console-mode max
editor no
{{}}
-=== system config
+== system config
set root password
@@ -324,7 +322,7 @@ $ shutdown now
remove the install media, and boot back up. make sure everything boots. from now on, configure the system as normal.
-=== configuring userspace
+== configuring userspace
add a non-root user
diff --git a/content/posts/autologinNextcloudClientOnArch.adoc b/content/posts/autologinNextcloudClientOnArch.adoc
new file mode 100644
index 0000000..68163d4
--- /dev/null
+++ b/content/posts/autologinNextcloudClientOnArch.adoc
@@ -0,0 +1,35 @@
++++
+title = "Getting the Nextcloud client to save login info on arch linux (or any barebones linux distro)"
+date = 2021-12-12T14:59:31-05:00
+draft = false
++++
+:caution-caption: pass:[☠]
+:important-caption: pass:[❗]
+:note-caption: pass:[✏️]
+:tip-caption: pass:[💡]
+:warning-caption: pass:[⚠]
+:toc:
+:toclevels: 6
+
+During the 5 or so years ive had nextcloud, ive always been quite happy with the webclient, but the device clients... need some work.
+I recently figured out how to resolve one of my biggest pain points on the linux desktop client, and am recording it here, mostly so I dont forget next time I setup a new computer,
+and to save others with the same problem from endless forum post and github issue crawling.
+
+== The cause
+Nextcloud expects the environment it is running in to have a 'keychain manager' installed and acessible by libsecret.
+However, curretnly, the archlinx nextcloud package does not list libsecret nor any keychain manager as a dependency.
+This does not cause a problem if you are using a desktop environment, as they will come with one in their own depenency cloud, but if you are just using a window manager, you may very well not have one installed.
+
+(as a side note, this also seems to cause a significant delay in the client starting up, probably some sort of timeout waiting to acess the keyring
+
+== The solution
+
+The solution is... suprisingly simple. You just need to install the `+gnome-keyring+` and `+libsecret+` packages, and set them up to autostart. In order to autostart them properly, adding these 2 lines to your `+.xinitrc+` is enough.
+
+{{}}
+#get gnome-keyring running
+dbus-update-activation-environment --all
+gnome-keyring-daemon --start --components=secrets
+{{}}
+
+(yes, you do need `+dbus-update-activiation-environment+`, as `+gnome-keyring+` seemingly relies on certian environment variables to start properly.)
diff --git a/content/posts/capsToCtrl.adoc b/content/posts/capsToCtrl.adoc
index 6f70432..d7739d2 100644
--- a/content/posts/capsToCtrl.adoc
+++ b/content/posts/capsToCtrl.adoc
@@ -11,8 +11,6 @@ draft = false
:toc:
:toclevels: 4
-== Caps to Ctrl in tty
-
In the past 2 years or so, I have been using my caps lock key as a seperate ctrl key on my desktop keyboard.
This is very easy to do in X11 with a setxkmap command.
However, with my laptop, I try to run without X as much as possible. (Ive found it make a nice, distraction free environment, and it seems to be pretty good for battery life)
@@ -31,12 +29,12 @@ and be done with it.
However, if we do this, we will notice a somewhat odd bug.
When we hold down caps lock and press another key, the kernel starts sending control- keycodes.
However, when we release caps lock, the kernel continues to send control- keycodes.
-From what I can tell, the only way to \'release\' control is to reboot.
+From what I can tell, the only way to 'release' control is to reboot.
In order to figure out why this is happening, we read the man page 'man keymaps'.
[NOTE]
-====
+===
You should be very careful when binding the modifier keys, otherwise you can end up with an unusable keyboard mapping.
If you for example define a key to have Control in its first column and leave the rest of the columns to be VoidSymbols, you're in trouble.
This is because pressing the key puts Control modifier in effect and the following actions are looked up from the fifth column (see the table above).
@@ -44,7 +42,7 @@ So, when you release the key, the action from the fifth column is taken.
It has VoidSymbol in it, so nothing happens.
This means that the Control modifier is still in effect, although you have released the key.
Re-pressing and releasing the key has no effect.
-====
+===
So what is happening seems to be that when we press caps lock, it looks for what keycode to send when no modifier keys are pressed.
Finding Control in the first column (the only column we specified), it activates the control modifier.
@@ -64,7 +62,7 @@ Well, it should!
However, there seems to be a bug in 'loadkeys', as the above only works when defining a complete keymap, not when overriding parts of default.map.
This means, that in order to correctly modify the keymap, we either have to define all columns manually, or we have to copy the default keymap, edit it, and load it as a complete keymap.
-=== Keymap patch
+== Keymap patch
To continue overriding the default keymap, you can simply manually repeat the control command.
Now, technically, there are 256 columns in the keymap file, but, at least for latin keyboards, only the first 16 are used.
@@ -77,7 +75,7 @@ keycode 58 = Control Control Control Control Control Control Control Control Con
Now just put it in in '/usr/share/kbd/keymaps/', and set it as your keymap with 'sudo localectl set-keymap [filename without .map extention]'.
-=== Full keymap
+== Full keymap
In order to create a new full keymap, copy the keymap you want to edit from '/usr/share/kbd/keymaps/i386/[couple more folders here]' to somewhere in 'usr/share/kbd/keymaps/' and unzip it with 'sudo gzip -d [filename]'.
Edit it with sudoedit and replace