Lists all of the journal entries for the day.

Fri, 21 Apr 2023

9:34 AM - Server outage

We've had a bad hardware upgrade and some of our infrastructure is down.? This includes the midnightbsd app store, jenkins and portsnap updates.? We also use this system for a number of magus package builds.?

A replacement motherboard should arrive soon to fix this.

()

9:38 AM - Using the MidnightBSD security advisory api

We've updated the security advisory api recently and it now has a new endpoint that lets you lookup by CPE.?

https://sec.midnightbsd.org/api/cpe/partial-match?cpe=cpe:2.3:a:openssl:openssl:1.0.1d:::::::*

This URL will lookup CVEs that may impact openssl 1.0.1d?

We're considering possibly using this with mport to provide security notifications via a new command.? Right now we have the security-advisory-client in mports that hits different endpoints within this API to provide auditing data.

()

9:40 AM - Access to packages available

If you're an end user and you want to know what software is available for MidnightBSD, the best place to go is the?app store. You can also use the mport search command to look for available packages, or in mports use make search key=

For software developers, there are several ways to get the data for consumption. Our package build cluster software has several endpoints available including:

https://www.midnightbsd.org/magus/api/latest

https://www.midnightbsd.org/magus/api/run-ports-list?run=328&status=pass

The latest endpoint gives you a list of packages available in the most recent magus runs that have been blessed (published). The other one lets you look at a specific run and filter on status.

There are multiple APIs available in the app store as well. Consult the midnightbsd-app-store repository on GitHub for details on those.

Finally, there are the actual sqlite3 databases generated by blessed package builds per arch and os-release.
http://index.mport.midnightbsd.org/amd64/3.0/index.db.bz2

()

9:42 AM - ZFS Replacing a bad disk

First, identify the failed disk. You can run zpool list to identify the failed drive.

zpool status

If you were clever, you named your disks with meaningful labels. If not, it might be trial and error. If it's ada0, you know it's in the first SATA port, for instance.

Remove the old disk. Confirm the disk is gone in the BIOS after booting the system.

Now put in the new disk.

It's recommended you boot into single-user mode. (see the option on the midnightbsd boot menu)

Now verify the OS detected the new drive.

camcontrol devlist

You should see the new drive. If you placed it in the same sata port, it is likely the same name. For our example, ada0

gpart create -s gpt ada0

gpart show

gpart add -a 4k -t mnbsd-zfs -l mydisklabel ada0

gpart show

Now if you run zpool status again you should see one drive marked as offline with a long number identifier rather than a label or device name (ada0)

zpool replace mypoolname longnumberfromzpoolstatus gpt/mydisklabel

If you didn't use the label flag above, replace that last part with ada0

This will start the resilvering process, which can take several hours. You can run zpool status to check the status of this process.

While you can boot the system at this point, and it will work, it will run slowly. If possible, let it resilver in single-user mode. It will go a lot faster.

Note there is a better guide on this here:?https://dan.langille.org/2015/08/03/replacing-a-failed-drive-in-zfs-on-freebsd/?The big difference is the partition type above (mnbsd-zfs vs freebsd-zfs)

()