Finally, I get to go to Defcon. I've been waiting for this a long time, but we're going to be on a bit of a tight budget. The boss is only paying for my plane ticket and entry, I've got to cover my hotel and food. Thankfully I've got a buddy who's going to let me crash with him.
Since this is my first time, I'm trying to go light. However, I'm also preparedness-minded, so that is in conflict.
I'm planning on the following for my bag on the conference floor:
- Notebook
- Water
- Ruler
- Sharpie
- External Battery
- Laptop
- Fake Wallet
- First Aid (boo boo) Kit
- CAT Tourniquet and pressure dressing
- Fake mask
- Blank USB x2
- Flashlight
- Spoon
- TP
- Multitool
- Snacks
- Water Bottle
- Ear Plugs
- Headset
I'll have the following available in case opportunity arises to want them (any cool badges, etc):
- USB-C soldering iron and accessories
- Small knock-off ifixit toolkit
- Pi Zero W
- Spare cell phone (my Pixel 6 is down and I don't trust my backup, so the tertiary backup will be available)
- 2M Ham Radio
- Flipper Zero
If zombies attack and I have to walk home:
- Sidearm and accessories
- Tarp
- Fixed blade knife
- Paracord
- Water Filter
Because my budget is tight I'm going to be working on getting vendors to ply me with food and drinks, but if not, the first day I'm going to get a bike share and head to the grocery store to get some basics (water, protein shakes, snacks, power bars, etc).
I'm incredibly excited to finally get to go to Defcon. There's no way to see and do everything, but I hope to learn a ton and meet some great people.
Been a minute. Let my domain expire, and my VPS shut this system down for being idle. Oops.
I'm sitting here finally getting around to installing Qubes on my Dasharo machine, and thought it might be interesting to discuss my work desk/monitor setup. Many times in my life I've lamented not having enough monitors for the amount of work I'm doing. I'm definitely of the "more monitors, not bigger monitors" school of thought.
Currently I have four systems at my desk:
- Librem 14: Primary work machine, using two video outputs (the max), connected to the left and right monitors.
- Mac Pro 2013 "Trash Can": I use this for video conferencing and media-intense stuff. It's running Ventura using OCLP, which works OK, except VMware Fusion doesn't run correctly on it. I'll probably replace it with my old work laptop, a 2018 MBP with a spicy battery. I just hate using Mac laptops in stationary configs. The Trash Can is connected to the top center monitor.
- Current-model Dell Laptop, 13-inch: This is my privileged access workstation that handles all of my tier-0 access at work (anything requiring domain admin/enterprise admin/etc).
- Dasharo Optiplex 9010: I've been doing some light Linux gaming on the Ubuntu partition, finally getting around to testing it out on Qubes.
My monitor setup uses a desk-clamped pole with two 24-inch monitors side by side, and one more centered above. I also have a video capture device connected to the Mac, since if I'm on a vendor support call I may need to share a screen from the Dell laptop or my workstation.
The astute among you may have realized that I've got three displays but five outputs. A simple 4x2 HDMI Matrix, around $30 on Amazon, solves that problem and introduces a ton of flexibility.
The two outputs from the matrix are connected to my right-hand monitor and the video capture card. Input 1 is one of the outputs from my Librem. Input 2 is the Dasharo machine, Input 3 is the output from the privileged laptop, and Input 4 is open.
If I want to play a game? Attach Input 2 to Output 1. Need to have a vendor see my screen from either the privileged device or my main laptop? Simply connect the correct input to Output 2. Want to keep half an eye on an install running on the Dasharo machine? Connect Input 2 to Output 2, then open QuickTime on the Mac and use it to monitor the capture card as a pseudo 4th monitor.
This, of course, leads to being able to easily record videos and screenshots for writing documentation.
One might say that a KVM switch would serve a similar purpose, but you don't have the option (usually) of multiple video outputs. I hope that this approach inspires those of you with too many systems and not enough monitors to think about what your workflow would look like with an HDMI matrix.
Quick stream of consciousness posting about my new phone:
Wow, this is quite a phone for under $350. The hardware is lovely.
There's not much to say about the actual flashing process itself. I followed the simple instructions on their site and used the web flasher which worked flawlessly.
When the device first came up, I thought there was something wrong - all of the icons are in Black and White! There's nothing to worry about, however, that's just their default theming. Once you start adding apps it'll look more normal.
I initially wanted to have a completely Google-free experience, but am not quite ready to wean myself off entirely, so I went with two profiles on the phone. The normal, Owner profile would have as many of my apps in it as I could. A separate user, PlayEnabled, would have Graphene's sandboxed Google Play services and would have Maps, Voice, YouTube (because casting doesn't work without play service apparently), and YouTube Music (because that's what I get cheap and I don't have physical copies of all my favorite artists yet).
Some apps like Outlook, Teams, and Duo complain about the lack of Play services but work adequately. However, I can say after a few weeks of this, I'm annoyed by the constant back and forth between the profiles, so I'm probably going to compromise and install the Play services in the Owner profile and continue to get off of those Google services as soon as I can.
Annoyances:
- Fingerprint Reader: Obviously if you're hardcore security/privacy minded, you aren't going to use biometrics, at least as a solo factor. On the Pixel 6 Pro, the FPR is right in the middle of the screen, so manufacturers of glass screen protectors leave a little circle in that area free of adhesive... Meaning there's a little bubble right there that never goes away.
- Google didn't see fit to enable DisplayPort video out of the USB-C port, so I can't use this as a desktop replacement on occasion. That's a big disappointment.
Conclusion:
I like it. If it weren't for work I could probably phase out of Google a little quicker, but I'm still in a much better place than I was before - and at a cheap price!
I don't recall where it was, but I saw a talk online that by some of the folks behind the Dasharo fork of Coreboot. I was very interested in the fact that they had ported it to the Optiplex 7010 and 9010, very common business PCs that are relatively (< 10 years old) modern.
The Optiplex 7010 and 9010 max out at 32GB of RAM and run third gen Intel CPUs on an LGA 1155 socket. They use the Q77 Intel chipset.
I had a couple of old Optiplex 3010s that were pretty useless. However, the cases are almost the same as the 9010 so I thought the 9010 motherboard would be a drop-in replacemement. A simple mobo transplant to play with some open source firmware that might be of interest to some of my clients (any myself)? Heck yeah.
It's never that simple, is it?
Here's what I started with:
Dell Optiplex 3010 SFF / i3-3220 CPU / 8GB RAM
I purchased an Optiplex 9010 SFF Motherboard from the Bay of Fleas for $15. When it arrived I ran into the first hiccup. The IO shield is formed as part of the case, so Mr. Dremel came out to move the problem areas. Next up, for some reason Dell changed the front panel/audio/usb connector between two models in the same generation. That makes no sense to me, but OK... It's not a breaking issue, but I'll pick up a new front panel. Another trip to ebay and it was on its way for $8.
In the meantime I transferred the i3 and the RAM, made a Dasharo Test Suite (DTS) 1.1.0 USB stick, and fired it up. The next discovery is that the case fan was going full blast for no good reason. I unplugged it.
The DTS stick failed to work without internet access, however once I plugged it into ethernet, the install guide was flawless. I rebooted, was greeted by their "King's Gambit" splash screen, and life was good... almost.
I tried to install Qubes, at which point I realized the i3 didn't support VT-d, so none of the VM stuff was going to work right. Well that's fantastic... Back to eBay to look for CPUs. $50 for a third gen i7? No.
I found a Xeon E3-1230v2 for $20. Sweet. This led to the next complication; the Xeon doesn't have integrated graphics. I figured I'd burn that bridge when I got to it. While waiting for the CPU I did some burn-ins under Ubuntu and scrounged another 8GB of RAM to get me up to 16GB.
Once the Xeon got here, I swapped it in and started trying a few different graphics cards in my stable. The first thing I noticed is that I no longer get the splash screen. Then, ventoy wouldn't boot... or so it seemed.
Upon investigation, no graphical installers seemed to work. Older versions of ubutu failed to grub and had to be launched manually. Very weird. Further testing revealed that things were working, just no graphics were making it to the screen until further on in the boot. Text mode was still working, so it was fine.
Dasharo's community checked it out prettty quickly and realized that because it's unusual for a Xeon to be in a 9010 they never added the necessary code for external graphics. It's not a breaking issue, so I bought an inexpensive Radeon R7 low-profile graphics card for $40.
Everything buckled up, I've been running Ubuntu and doing some light gaming with a USB wireless NIC until I can throw a permanent ethernet cable to support a Qubes install. It's a great machine; I think I'm going to build another one to upgrade/replace my current pfsense box. In hindsight, it may have been less expensive to just buy a used system.
Costs:
- Motherboard - $15
- CPU: Xeon E3-1230v2 - $20
- Replacement Front Panel - $8
- GPU: OEM Radeon R7 4GB - $40
- Total out of pocket - $83
We could have skipped the front panel, since once the new firmware is in place there's no F1 warnings.
I'll report again once I install Qubes on it and have driven it for a while.
On the off chance anyone has been reading my gemlog, you'll know I've had a fair amount of trouble with my Librem 14. It appears that they succeeded in fixing my issue with the most recent RMA. Now that I've been working reliably with it for a little while, here's a summary of my thoughts. I've had it for around eight months, but I've had less than six months productivity with it. More on that later.
The basic specs of my Librem 14v1 are:
Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz
RAM: 32GB
Storage: 1TB Samsung SSD 860
OS: Qubes 4.1.
When I originally received my L14, it came with an outdated version of Qubes. I didn't notice immediately, which caused some problems when I discovered it, as the upgrade process didn't go smoothly. In the course of the RMAs, I reinstalled Qubes each time and the experience was much smoother.
Also of note, there was no documentation of the default LUKS key. I had to dig around until I found a blog post from their CEO that told us it was blank.
My first impressions of the device were quite positive: sleek, black, almost no branding. The hardware switches were nice, allowing a quick kill of the camera and mic in a very positive way. Also, I found that the LCD panel was competitive with the panels on the higher end laptops I'm used to.
We accept certain compromises in the name of privacy and security, but it can be a little difficult to stomach paying premium prices for a laptop using an older CPU. Still, a 10th generation 6-core i7 is plenty capable.
The machine is reasonably serviceable. There's a bunch of 0000 Phillips screws to remove, then pry off the bottom panel. It would be nice if they were captive, but it's not too bad. There's an extra nvme port you can't use without buying a smaller battery.
Over time, however, there have been a number of frustrations with this device:
It's failed on me three times in exactly the same way. If I wasn't a technical person with multiple capable backup laptops I'd have been sunk. RMA times were relatively long, but acceptable for a small company like Purism. Basically, the failure mode was an inability of the device to charge from any source. I had to do some hacky nonsense to back up the system after the failure (my bad for not running backups...). The Purism forums have many people complaining about the same issue.
It's not well advertised, but you can charge the device off of USB-C. However, it's not terribly reliable and other users have reported that you can't get it charged from dead off of USB-C.
I use my L14 mostly on my desk, so the keyboard doesn't bother me too often, but when I have to take it on the road, the layout is annoying. I routinely hit the up arrow when reaching for the right shift key, and because the power button is integrated with the keyboard, it's really easy to hit it by mistake if you're reaching for backspace or delete. Aside from the layout, the keyboard is comparable with most modern ultrabooks: meh, but better than a Macbook Pro at least.
There are a lack of good docking solutions for the device, but that's a common feature with most modern "ultrabook" class devices.
Reasons to buy:
- Support Purism's mission
- Qubes-ready laptop
- Willing to compromise on Intel ME.
- Hardware switches for mic/webcam/wifi/bluetooth
Reasons not to buy:
- Reliability and long RMA times
- Low CPU spec for price
- Unreliable USB-C charging
Final thoughts:
If I had it to do again, I probably would have just installed Qubes on one of our company-standard Dells. I like the idea of Purism's mission, but the reliability of the hardware has burned me enough times and impacted my work that I can't recommend it unless you have a spare machine and good backups.
Like they used to say, "Nobody ever got fired for buying IBM". Unless something else major happens, this will be my last report on the L14.
I have RMAed my L14 twice since August, and now it's dead again less than an hour after moving back in. Purism support suspected that there might be some weirdness involving Dell monitors connected via the right side USB-C, so this time when I got the machine back I went with a minimum peripheral setup: 1x monitor connected via HDMI, USB Keyboard, USB Mouse.
I wrote back to support immediately; I'm not sure what they're going to suggest, but I can't keep going on like this. If this doesn't work out I'll ask for a refund, or ask my VAR to handle it. On the plus side, the Dell Precision 7510 I'm using as a backup is plenty capable.
Back to the drawing board. I wonder what it would cost to pay someone to port coreboot/libreboot to the previous generation Dells...
This is an update to my post on 2022-03-16 regarding turning a Hyper-V VM into a Qubes VM. I recently had to stand up a new 4.1 Qubes system and my existing Win10 HVM didn't survive the move (I eventually got it booted, but even after updating drivers and QWT I couldn't get the integrations to work). A few things seem to have changed.
- Dom0 doesn't seem to have as much disk space available to it.
- qvm-create doesn't work with the command line I previously posted.
- Clipboard sharing with Windows appears to be broken - hopefully that will be fixed soon. I have a workaround, but I'll save that for another post (basically set up RDP and use it instead).
The updated procedure I use is:
- Create your VM in Hyper-V
- Install Qubes Windows Tools (4.1.68 as of this writing) and Xen 9.0 drivers.
- Shutdown the VM
- Convert the disk image from vmdk to raw.
qemu-img convert -f vhdx -O raw <path to vmdk> <path to target .raw file>
- Copy the file to dom0.
- This is where I ran into my first issue. dom0 no longer has enough disk space by default. You could fix this when you install Qubes, but I didn't want to go back to zero, so I had to learn a little about LVM.
# First up, you need to create a partition with enough space for your disk image. This is only temporary until you've created your HVM. In my case I start my VMs at 60GB, so I created a 70GB partition. lvcreate -n vm-staging -L 70G qubes_dom0 #format the partition mkfs -t ext4 /dev/qubes_dom0/vm-staging #create the mount point and mount the volume. mkdir ~/images mount /dev/qubes_dom0/vm-staging ~/images cd ~/images #copy the image qvm-run --pass-io untrusted 'cat "/home/user/usb/VM-NAME.raw"' > ./VM-NAME.img
- Create your VM.
- This was my second problem. I think something changed in the qvm-create command (or I fat fingered it when I entered it in my previous post). I had to add the --standalone switch. Otherwise it's similar.
qvm-create --standalone --property=virt_mode=hvm --property=memory=8192 --property=kernel='' --label=blue --root-move-from ./VM-NAME.img VM-NAME
- Extend your qrexec_timeout (I discovered this was a problem when troubleshooting my other VM. 600 is a good start, but if your machine is slow you might want to go further).
qvm-prefs VM-NAME qrexec_timeout 600
- Boot your VM and verify all is good, then delete the .img file if it's still there.
rm ./VM-NAME.img
- They've also added audio support and recent instructions added a few additional recommended settings:
qvm-featrues VM-NAME audio-model ich9 qvm-features VM-NAME stubdom-qrexec 1 qvm-features VM-NAME timezone localtime
Use virt-manager. The device creation command I included below created a working VM - without sound. No amount of searching was leading me to a solution, so I used virt-manager to create the VM and all the missing magic happened. If I needed to stand up 100 machines programatically I'd figure out what I'm missing from the cli side, but it's an effort:reward equation and figuring out the cli method is a distraction for what I'm trying to accomplish.
As I mentioned over on the gemlog side of the house, I recently finally got around to starting to go through Michael Bazzell's OSINT Techniques, 9th Edition. I haven't made a lot of headway, but since the "technical" side of things is pretty run-of-the-mill for experienced security/infrastructure engineers, I decided to run my VMs on KVM instead of the more pedestrian VirtualBox or VMWare Player.
So, for today's technote, I'll share the basic setup of an Ubuntu 22.04 VM on KVM on Parrot Security. The hardware is a Precision 7510 with 32GB RAM and a 500GB HDD. Nothing terribly special. Yes, with my security/privacy/paranoia hat on you shouldn't just "sudo su" and run everything, but it's a lab box, so I don't care.
One thing I am looking forward to is some of the Firefox plugins I'm not already familiar with. As I've gotten more involved with the hardware/network/policy side of things I've drifted from my past knowledge of the desktop user environment, beyond what I use myself. There's some gaps there I want to fill back in.
sudo su
apt update
apt install qemu qemu-kvm qemu-system qemu-utils aqemu libvirt-clients libvirt-daemon-system virtinst
# verify libvirtd running:
systemctl status libvirtd
#if not running:
# systemctl start libvirtd
# list networks. Default must be active to create vms with libvirt.
virsh net-list --all
virsh net-start default
#set to start on default:
virsh net-autostart default
# create directory tree:
mkdir -pv /kvm/{disk,iso}
#DL/copy isos to /kvm/iso.
#Create VM
virt-install --name osint-ubuntu \
--os-type linux \
--ram 4096\
--disk /kvm/disk/osint-ubuntu.qcow2,device=disk,bus=virtio,size=80,format=qcow2 \
--graphics vnc,listen=0.0.0.0 \
--noautoconsole \
--hvm \
--cdrom /kvm/iso/ubuntu-22.04-desktop-amd64.iso \
--boot cdrom,hd
# Connect to console:
# Find the VNC port:
virsh vncdisplay osint-ubuntu
# fire up a vnc viewer and go to vnc://127.0.0.1:0 (or whatever the VNC connection is)
# After you finish the install, the VM will shutdown. Restart it.
virsh start osint-ubuntu
Two weird things happened to me today in Qubes:
- My USB webcam (the one built into my laptop) would disconnect immediately after being connected to an AppVM. Teams would see it for a split second, and then it would drop.
- My Windows 10 HVM would shut down within minutes of logging in.
It seems like the solution to both was the same, but I'm not sure exactly why. In both cases I had to bounce the max memory. I doubled sys-usb from 300MB to 600MB, and increased Windows' memory from 6GB to 8GB.
I don't *think* there was a recent update applied to dom0, and sys-usb was still using the old fedora-32 template (upgraded it to fedora-34 while I was messing with it.
I'm mostly a blue-team security guy and backup systems engineer in a primarily Windows environment. This means that a lot of my work is done in browsers and from Powershell. Initially, I'll be doing a lot of my work from a Windows HVM (see my post from 2022-03-16 on how to get that imported), but once I get VPN/networking connecting me to the office, I'll be migrating that load to AppVMs, appropriately segmented for the level of access I'm using.
Today I set up the template VM I'm using for my work appVMs. I'm running the Debian 10 template; there's a Debian 11 template available, but there's still some bugs (for example, it can't mount exfat partitions, even with the appropriate packages installed). I'll be installing remmina for RDP access, codium for, well, coding, Chromium, Edge, and PowerShell.
First, I cloned the template to "debian-10-work". Then I enabled networking on the template (some of the installs require going out to the web for curl/wget actions).
Let's do the easy ones first:
apt install remmina apt install chromium
Next, codium (reference: https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo#option-1-recommended):
wget -qO - https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/master/pub.gpg \
| gpg --dearmor \
| sudo dd of=/usr/share/keyrings/vscodium-archive-keyring.gpg
echo 'deb [ signed-by=/usr/share/keyrings/vscodium-archive-keyring.gpg ] https://paulcarroty.gitlab.io/vscodium-deb-rpm-repo/debs vscodium main' \
| sudo tee /etc/apt/sources.list.d/vscodium.list
sudo apt update
sudo apt install codium
I had some major issues with the Edge install; for some reason I couldn't get their signing key to work following the instructions on the official site (https://www.microsoftedgeinsider.com/en-us/download?platform=linux-deb) which caused apt update to fail. I undid all of that, but did eventually get it going. More on that after PowerShell.
pwsh (reference: https://docs.microsoft.com/en-us/powershell/scripting/install/install-debian?view=powershell-7.2#installation-on-debian-10-via-package-repository):
wget https://packages.microsoft.com/config/debian/10/packages-microsoft-prod.deb sudo dpkg -i packages-microsoft-prod.deb sudo apt-get update sudo apt-get install -y powershell
After I finished the PowerShell install, I checked the apt keys (apt-key list) and found that the same key was used for both PowerShell and Edge. So, I tweaked the line to import the repo, tried again, and it worked!
sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/edge stable main" > /etc/apt/sources.list.d/microsoft-edge.list' apt update apt install microsoft-edge-stable
Phew! That's working well now. Now if the 20GB image file with my HVM would quit crashing part way through downloading, I could move in full-time. Next up, trying to get NDES/SCEP enrollment working and get connected to our VPN.
Finally received my Purism Librem 14v1 (not their fault on the delay). Here are my first impressions and some of my initial setup concerns.
I ordered the 32GB / 1TB / SeaBIOS + coreboot / Qubes version. First impression at unboxing is that this is a really attaractive laptop. Nice sharp corners, matte finish, no markings on the top or inside, minimal markings on the bottom. Gives me vibes like a "murdered out" car. Screen is nice, too. I like that sticker life, but I'm go
ing to keep the back clean until it starts getting scratched.
On first boot, you're prompted for your LUKS password. I wasn't given one. I checked the FAQ and support site without luck. I gave up and emailed, but while I was waiting, I found a blog post from the CEO (https://puri.sm/posts/qubes-now-a-preinstall-option-for-librem-14-and-mini/) that mentioned it was blank. Facepalmed, hit the enter key, and was taken to the Qubes OOBE. That was fairly straight forward, especially since I've installed Qubes before. I created a user and set the encryption password and was on my way...
Or so I thought. They shipped the machine with Qubes 4.0 installed. The whonix templates included were the deprecated -15 ones. I could have reinstalled Qubes, but I wanted to get the whole "new user" experience, so I toughed it out.
System time was *way* off. I had to fix that before updates would work (due to cert validity), and it took a reboot before it kicked in. Then I performed a distribution upgrade to get to 4.1: https://www.qubes-os.org/doc/upgrade/4.1/
From dom0:
sudo qubes-dom0-update -y qubes-dist-upgrade sudo qubes-dist-upgrade --all
reboot
sudo qubes-dist-upgrade --resync-appmenus-features
The whonix installs were still on -15, so had to import the new templates:
sudo qubes-dom0-update --enablerepo=qubes-templates-community --action=reinstall qubes-template-whonix-ws-16 sudo qubes-dom0-update --enablerepo=qubes-templates-community --action=reinstall qubes-template-whonix-gw-16
Re-assign the App VMs to the updated templates (don't forget to change the DispVM setting in the -ws VM) and delete -15 templates:
qubes-dom0-update --action=remove cubes-template-whonix-ws-15 qubes-dom0-update --action=remove cubes-template-whonix-gw-15
I also went ahead and installed the Debian 11 template:
sudo qubes-dom0-update --action=install qubes-template-debian-11
That's it for now. I've got to start adding apps to my templates, setting up my app vms, and importing the Windows HVM that I need. Also need to try to see if I can get OpenConnect working (I was working on it on a tester for the past month, but could never get it to work in our environment).
Fairly straight-forward here.
- Create your VM in Hyper-V (I imaged it via SCCM to get a fully standard work build).
- Install the Qubes Windows tools (xenbus, xenvbd drivers, qubes-tools-4.0.1.3).
- Shutdown the VM.
- Convert the disk image from vmdk to raw format:
qemu-img convert -f vhdx -O raw <path to vmdk> <path to target .raw file>
- Copy the file to dom0 (run from dom0):
qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /home/user/win10.img
- Create the HVM (set the RAM, label, and machine name as you wish):
qvm-create --property=virt_mode=hvm --property=memory=4096 --property=kernel='' --label red --standalone --root-move-from /home/user/win10.img win10
Reference: https://www.qubes-os.org/doc/standalones-and-hvms/#converting-virtualbox-vms-to-qubes-hvms
Reference: https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows-tools.md
I'm super pumped to get my Librem 14 in a few weeks. Since I work remote I don't have to worry about jealous coworkers, but on the other hand I don't get to show off, either :(.
OK, here we go, time to write up how *I* installed i3 on OpenBSD 7.0. Hopefully the format will translate from my notes.
Reference: https://ronvalente.net/posts/install-i3-on-openbsd/
Reference: https://www.nxfury.com/lock-down-your-laptop-with-openbsd-part-2
pkg_add i3-gaps i3status rofi rxvt-unicode chromium irssi w3m vim openbsd-backgrounds
sed -i 's/xconsole/#xconsole/' /etc/X11/xenodm/Xsetup_0
echo 'xset b off' >> /etc/X11/xenodm/Xsetup_0
Not using this on the Mini.
rcctl enable apmd rcctl set apmd flags -A rcctl start apmd mkdir /etc/apm # append next two lines to /etc/apm/suspend: #!/bin/sh pkill -USR1 xidle chmod +x /etc/apm/suspend
I'm not familiar with this; just following the guide. Apparently some groups get more resources than others, so you have to make these mods for performance reasons:
usermod -G staff labadmin
Modify the staff: entry in /etc/login.conf to look like this:
staff:\ :datasize-cur=1024M:\ :datasize-max=8192M:\ :maxproc-cur=512:\ :maxproc-max=1024:\ :openfiles-cur=4096:\ :openfiles-max=8192:\ :stacksize-cur=32M:\ :ignorenologin:\ :requirehome@:\ :tc=default:
The only ones I had to modify in my config away from default were macproc-cur, maxproc-max, and I had to add the openfiles and stacksize values.
Then, append this to /etc/sysctl.conf:
# shared memory limits (chrome needs a ton) kern.shminfo.shmall=3145728 kern.shminfo.shmmax=2147483647 kern.shminfo.shmmni=1024 # semaphores kern.shminfo.shmseg=1024 kern.seminfo.semmns=4096 kern.seminfo.semmni=1024 kern.maxproc=32768 kern.maxfiles=65535 kern.bufcachepercent=90 kern.maxvnodes=262144 kern.somaxconn=2048
sysctl.conf did not exist when I started.
Run as user, not root:
mkdir -p ~/.config/gtk-3.0
nano ~/.config/gtk-3.0/settings.ini
Add these lines:
[Settings] gtk-theme-name=Adwaita gtk-icon-theme-name=Adwaita gtk-font-name=Arimo 9 gtk-toolbar-style=GTK_TOOLBAR_ICONS gtk-toolbar-icon-size=GTK_ICON_SIZE_SMALL_TOOLBAR gtk-button-images=1 gtk-menu-images=1 gtk-enable-event-sounds=1 gtk-enable-input-feedback-sounds=1 gtk-xft-antialias=1 gtk-xft-hinting=1 gtk-xft-hintstyle=hintslight gtk-xft-rgba=rgb gtk-cursor-theme-size=0 gtk-cursor-theme-name=Default gtk-key-theme-name=Default
As root:
cp /usr/local/share/examples/i3status/i3status.conf /etc
From the nxfury page:
Lastly, let's configure i3 to actually launch. Open /etc/X11/xenodm/Xsession in a text editor and go to the end of the text file. There will be a portion saying exec fvwm. Remove that line entirely and replace it with exec i3. Now search for anything in this file saying xconsole and remove it (this prevents automatic launching of a console in your desktop.)
Note that this is just "exec i3" not with the prefix variable or any of that nonsense.
Skipping the intel section, not relevant on Mac Mini.
Referenced guides don't include i3lock.
pkg_add i3lock
pkg_add xautolock
At the end of ~/.config/i3/config, add the following lines:
bindsym $mod+Shift+m exec i3lock -c 000000 exec --no-startup-id xautolock -time 15 -locker "i3lock -c 000000"
The first line binds mod-shift-m to lock the screen.
The second starts when i3 starts and locks your screen after 15 minutes.
That wraps it up for now. Stay tuned!
It's taken me a little while to get around to writing up the i3 install. I'll get to that later. For now, let's take a look at getting my current favorite BBS software, SyncTERM, installed and configured for OpenBSD.
I was initially excited because a pkg_add syncterm worked. Unfortunately, the version in the repo wasn't compiled with ssh support. Annoying. I tried downloading the current .tar.gz of the release version (1.1p), but had trouble compiling. I finally got it working with the latest version in git.
References:
Meatlotion's Linux compile instructions: https://www.erb.pw/how-to-install-syncterm-for-linux-from-source/
Bugs 40, 41, and 80 from the SyncTERM bug tracker: https://sourceforge.net/p/syncterm/tickets
A lot of searching and learning about compiling in OpenBSD.
Note that I may have missed a dependency here. Shouldn't be too hard to find it.
Run this as root:
pkg_add unzip gcc git
git clone https://gitlab.synchro.net/main/sbbs.git
cd sbbs/src/syncterm
st_path=$(pwd | sed 's/\/syncterm$//g')
gmake SRC_ROOT=$sst_path
gmake install
which syncterm
It installed to /usr/local/bin/syncterm on my system. Running "syncterm -iSF" runs it full screen, stretched to fit. SSH works as you would expect.
I've been messing around with various alternate Android ROMs for a long time. It's always an adventure - get root, unlock the bootloader, find the right ROM for your exact version of the device, flash it, brick it, recover it, try again, etc.
Usually I'll end up with LineageOS, without any Google services. However, after work got me a Pixel 3 for (cough) testing, I finally had a chance to try Graphene OS.
The Pixel 3 is the oldest supported device for GrapheneOS and may fall off before too long. When buying a phone for GrapheneOS, make sure you can unlock the bootloader - the carrier-provided versions don't allow this and prevent you from installing alternate ROMs. The eBay listing should mention this, or you can ask the carrier. If the IMEI starts with "3", it's a Verizon phone and definitely won't work.
All that said, installing GrapheneOS is the *easiest* alternate ROM install I've ever done. Their web-based installer is flawless. Once booted into the phone you'll find that it's extremely minimal. The first thing to do is go install F-Droid and Aurora so you can easily install other apps. The device is very smooth and the interface is visually appealing.
In terms of drawbacks, the first is that, as all of the supported devices are Pixel 3 and later, you can't buy a phone that has a MicroSD slot; you're committed to the storage on the phone and no more. The second drawback, for some users, is that since Google Play services are not installed, some apps won't work (including Microsoft Intune, if you need it for work).
I'm currently daily driving this as my "personal" phone (I need a full Android experience for work). I'll follow up in a few days with some more impressions.
I began the dual boot install today; the practice runs I took while waiting for the install kit for the second drive paid off. I'm going to document the actual installer steps below. My environment:
- Mac Mini 2011 (MacMini5,2) with dual SSDs, labeled DISK0 and DISK1.
- DISK0 has MacOS Catalina (dosdude1 patched).
- DISK1 is blank.
- The OpenBSD install image (install70.img) is installed on a USB stick.
- Network is connected via Ethernet.
Step-by-step process:
Insert the installer into the Mini.
Hold down the ALT key and power on the Mini.
From the boot menu, select "Windows" (which is actually OpenBSD - the boot menu is just stupid).
At the Welcome choose (i) for install.
At the keyboard layout prompt hit enter for the default.
Enter your host name.
Configure your network interface (on the Mini bge0 is the ethernet interface name).
Choose [autoconf] for IPv4.
Don't bother with IPv6.
Choose [done].
Enter the root password twice.
Set sshd to start by default.
Do you want the X Window System to be started by xenodm: yes.
Setup a user (actually enter the username here - the installer gets snarky if you enter "yes")
Enter the full name, password twice.
Allow root ssh: No.
Enter your timezone.
Select root disk: In my case it's wd1 since wd0 is the MacOS disk.
Use whole disk GPT (this is important - if you go MBR your ability to make certain changes later can be impeded.)
Accept the layout (in hindsight I think I should have modified this for more space on the EFI partition - more about this later).
Don't initialize any additional disks.
Install sets: The installer glosses over part of this; if you didn't know ahead of time that you need to remount sd0 you'll get confused about where you're supposed to find them from.
Location of sets: disk
Is the partition already mounted? No
Which disk contains the media? sd0
Which partition has the install sets? a
Pathname to the sets? 7.0/amd64
Select all (default) and choose done.
Continue without verification.
Installation begins.
Location of sets: done
Exit to Shell, Halt, or Reboot? Halt <--- This doesn't seem to work right on the Mini. Need to investigate.
Remove media, power off.
Hold ALT and power on. You'll see DISK0 (The MacOS install) and "Windows".
Boot into MacOS and make sure it still works.
While in MacOS, this is a good time to purge "Windows".
I found this related article: [Rename EFI Boot Partition "EFI Boot"](https://apple.stackexchange.com/questions/343707/rename-efi-boot-partition-efi-boot). I wanted to add the OpenBSD icon, but I didn't leave enough space on the EFI partition. *Alexa, this is so sad. Play Despacito.*
diskutil mount disk1s1 bless --folder /Volumes/NO\ NAME/efi/boot --label "OpenBSD"
Reboot, hold ALT key again, boot into OpenBSD. SUCCESS!
To do:
- Wireless
- Shutdown / Halt
- Suppress "can't read the disk" message in MacOS.
I recently picked up a Mac Mini 2011 (MacMini5,2 in Apple's parlance). With a 2.5GHz i5 and 8GB of RAM it's a reasonable little machine. My intent is to dual-boot MacOS Catalina (why they can't just use version numbers is beyond me) and OpenBSD 7.0. I ordered a second hard drive kit for it ($9 on eBay) and replaced its spinning 500GB 5400 RPM disk with a pair of 256GB SSDs I had laying around.
Let me just say that servicing this thing is a *nightmare*. I found a video guide from OWC who made the original kit that my ebay special is a knockoff of which made the job *clear*, but taking nearly an hour to replace a hard drive is a little excessive. [OWC Data Doubler Guide](https://www.youtube.com/watch?v=KlR-RWtqzis)
Hopefully my second hand SSDs last long enough that I don't need to strip the thing down again for a good, long, while. Catalina is installing now (using the dosdude1 patcher), and I'm going to try to take good notes when I install OpenBSD.
I need to spend some more time researching, but running SyncTERM with its default settings on my chat machine (4GB RAM) is not going well. A few minutes in it swallows up all the RAM and then crashes. Running in ncurses mode, while ugly, doesn't have that problem. Is it i3, Manjaro, or SyncTERM itself? I don't know...
Posted 2021-05-25
I've never had to use Whatsapp before today when a vendor required it as an out-of-band communication channel. Here's a few notes from my first use:
Posted 2021-05-19