Several bug fixes have been made on the mport package manager.
It's now using a sha256 hash for verification of files rather than md5.
It gracefully ignores missing files on a mport update.
mport install can now update dependencies it needs to install a package.
MidnightBSD mports started as a refactor of the FreeBSD ports with some influence from OpenBSD many years ago. For the first few months of the project, we actually had a "ports" that was literally a checkout of FreeBSD ports with a bunch of changes to make things build. It was horribly unreliable and a huge mess. Chris Reinhardt did a big refactor along with input from Phil Peria and I. We started moving features into the extensions directory, which FreeBSD is now doing with their Uses directory. We also broke up a bunch of the bsd.port.mk and bsd.*.mk files into components as smaller chunks to work on and pull them in as necessary. Then the mport package manager prototype in perl happened as a replacement for pkg_tools (pkg_add, pkg_delete, etc). Chris ported that prototype mostly to C and then I finished the port and wrote the driver program for it. Chris got it to a point it could install and deinstall packages from the mports tree.
One of the big design goals we all agreed on as well as our then security officer Adam Karim, was that we wanted to install the package into a directory, which we called FAKE_DESTDIR, and to force all installed mports to be packages and then installed by the tool. This cut down on installation errors from packages that we frequently had as everything was tested this way. It was a bit slower in mports, but the benefits outweighed the risks. This wasn't really our original idea and it was inspired by OpenBSD ports at the time. Still, it worked out really well. As we were trying to adapt FreeBSD ports, we made a bunch of decisions that are still a difference from how FreeBSD ports work today.
FreeBSD eventually introduced STAGEDIR which aside from being a better name, also works similarly to FAKE_DESTDIR with a few differences. When we did the change, many ports did not have or honor a DESTDIR directory. We found that the ones that did would just work if we made the do-install and post-install targets include it in make invocations. In contrast, FreeBSD often has to add STAGEDIR everywhere to get it to work. There are cases their way is better such as dealing with ruby gems or similar funky ports. We have some mechanisms for those problems too. FAKE_OPTS has a trueprefix option that with change the behavior of the do-install and post-install targets. Sometimes you will see ports that are double appending the DESTDIR (/usr/mports/mycat/my/port/fake_install/usr/mports/mycat/my/port/fake_install/usr/local) type of nightmares. This works around that. In some cases PREFIX includes both the DESTDIR and the PREFIX from a makefile sense. This is only true for do-install, post-install, do-fake, post-fake. So if you have a newer target like ones based on options, it will not apply and you will need to use FAKE_DESTDIR. If you actually need the PREFIX value without DESTDIR, it's available as TRUE_PREFIX.
Another difference is the order that different parts of the framework are loaded. This can cause weird bugs if you're trying to copy a freebsd port over. It's very evident with some of the python ports. Different modules will sometimes fail to save the options selected using the options framework. It's a combination of the loaading order and the name that is used to distinguish different port options. In midnightbsd, port names must be unique or it really breaks the package manager index. OPTIONS mostly work the same aside from that bug.
Fetching distfiles is another area that can differ slightly. Most of the same features work, but there can occasionally be difficulties fetching from github or gitlab due to the subtle differences in how package names are used in the framework as well as features we're supporting. Sometimes one just has to add the DISTFILES explicitly or set the git tag to get it to fetch right. MidnightBSD like FreeBSD includes fetch and libfetch. Both mports and mport use these to get files. The MidnightBSD version also includes the OSNAME in the user agent string so you can actually tell it came from MidnightBSD in logs.
mport package manager doesn't support LUA scripts like pkg. Most of those trigger operations in the PLIST files. pkg-plist by default. You will see basic commands like @dir or @mode that work in both. Some have been augmented in mport with the use of hacks that substitute the commands for @exec or @preexec/@postexec commands in package plists. In other cases, the business logic is in the mport package manager and requires a minimum version.
on that topic, we recently created a port to install new versions of the package manager. That meant we needed to put it in it's own repo. We're bumping the version number based on updates, but mport itself doesn't know about that. Instead it reports the OS version and it's bundle version. That is the version of the package format and sqlite database schema in use. It gets bumped when we add breaking features. This used to go out with new OS versions and we're still working on how to manage that going forward. We may add version numbers to the package manager to make it easier to determine in the future.
We also are looking at adding UCL support to mport.
Another area where things are quite different is how we build packages, where to find information for them and how to detect security issues in installed packages. We have magus for package building which is a set of perl scripts included in the mports repository currently along with a postgresql database. There was some work to rewrite this in java a few years ago but it hasn't been completed. We also have a few endpoints that return JSON in there for services like repology to use as well as the MidnightBSD app store which is a searchable list of packgages. the app store also powers metadata in the graphical mport package manager in gtk3. Then we have the sec.midnightbsd.org security advisory site which is mostly there to work with a perl script in mports called security-advisory. It will check installed ports against the website REST api for security issues. it's a bit slow because it fetches vulnerabilites for ALL versions from the API so as to not tip off our server what release you're using for security reasons. We may know IP x is curious about apache httpd but we don't know what version. We have considered adding some kind of range to this as apache in particular is very slow to process. Magus has a web interface but it's optional. You can actually do a package build just with the perl client that runs on a build node, and the indexer. We then have a C program called bless that creates a sqlite3 database from the postgres database data for a given run. We then vacuum it and bzip2 it and put it on the index site. Finally, we mark it blessed=true in the database which is a signal for the app store and repology that those files are LIVE.
We recently added a new port, mports/sysutils/bastille that allows you to manage containers. This is a port of a project that originally targetted FreeBSD, but also works on HardenedBSD.
You can see the getting started guide at the link below.
https://bastillebsd.org/getting-started/
A few notes on using this with MidnightBSD. Our port supports bootstrap, create, stop and destory. It may work with ZFS but we have not tested it. If you are using MidnightBSD 2.0.x amd64, you likely want to use a version of 2.0.3 in your create statement. MidnightBSD versions don't include RELEASE or other strings at the end so it's just a straight up version number.
The getting started guide also recommends using PF. The instructions will work on MidnightBSD just fine, but you do need to disable IPFW which is enabled by default on MidnightBSD first.
The update/upgrade function does not work in MidnightBSD right now because it requires binary update support. We do have the binary in 2.0 as it was planned to add it but the server side work isn't done yet.
There's also a bug in the port but it shouldn't affect operation on MIdnightBSD, just if you tried to use that code on FreeBSD with pkg integration. This came up when we upstreamed it and should be fixed in that PR now, although we didn't bother to fix the port since it's not used on other systems.
New 2.0.5 release tagged in git.
Happy 15th anniversary to MidnightBSD!
Fixes: pam security issue Updates: mport 2.0.5 tzdata 2021a Now uses sysrc for firstboot script.
We will do ISO builds later for this one.
We've recently added a default .xinitrc file for user profiles to help with the desktop integration on a fresh install. The default desktop environment has recently changed to Xfce. We still need to build packages to get the default on midnightbsd-desktop updated.
A number of package bugs are being worked on and we've placed the mport package manager in it's own repository now to help with contributions and allow us to easily package it in mports. You can test newer versions there.
February is the 15th anniversary for the project!
We have a new Jenkins CI server at https://jenkins.midnightbsd.org/
We have a new video up on youtube that explains how to install MidnightBSD 2.0.1 with a desktop environment.
mports:
We've updated gnome web (epiphany), midori and webkit2-gtk3 mports.
We're in the process of updating GNOME 3.x
Two new security ports were added for systems that have ssh, mail, web or other services exposed to block some attackers. security/blacklist-de-all and security/fire-hol-list which install scripts that can download updates and you tie it in with IPFW and cron. These are unique to midnightbsd at the moment.
We've added bhyve-firmware ports recently to allow you to run linux or windows vms on midnightbsd, with some effort.
We just fixed a plist problem with the nvidia-driver port that should help folks trying to use it in stable/2.0 or 2.0.1.
We fixed a bug with one of the install scripts that will be present in 2.0.2. You can use mport install midnightbsd-desktop manually for now to get the desktop stuff.
We recently added an eclipse port. You can of course use this with java, php, C/C++ and several other languages.
We fixed some of the mono ports on stable/2.0 releases. Still need to update fsharp and fix gnome-sharp20
We updated the chromium port, although it's still broken at the moment, it's the first step in bringing a new native browser in.
As for firefox, we will first need to update our rust port which also is needed to fix several other broken ports and bring in librsvg_rust. The blocker on this before was the compiler in 1.2 so now with 2.0 out, we can revisit it.
we updated 2.0 amd64 packages recently.
We just ran a 2.0 i386 build with the first of the gnome 3 changes. 450 ports less than the previous run. we won't be releasing these packages, but it's a good start.
mail/evolution was updated.
There is a security fix for OpenSSL in master and stable/2.0 branches of MidnightBSD. It's strongly recommended that you update to this version. It will be part of the 2.0.3 release.
MidnightBSD 2.0.2 in git.
Fixes the following:
firstboot script package name
ICMPv6 security issue
tzdata 2020d import to fix time zone problems.
certctl & certificates updated/fixed
USB audio improvements.
ACPI improvement with newer AMD systems.
NFSv4 server fixes
Hygon AHCI and USB controllers
pciconf can show extended pci capabilities
mlx5 improvements
WD green ssds quirk for trim
Denverton UART PCI ID
ZFS fixes
synaptics touchpad fixes
Add Atom C3000 watchdog ID.
JMicron JMB582/JMB585 AHCI
MidnightBSD 2.0.1 was released for amd64. The only change is a fix for UEFI booting.
We identified some issues with the 2.0 ISOs slated for release with the ZFS bootloader not working.
Until this issue is resolved, we are unable to build release ISOs. We've left the old ones up as they work fine for anyone using UFS.
We just added the F-PROT antivirus comamnd line scanner for BSD systems to mports under security/f-prot.
I recently setup a new system with the FreeBSD 9 32bit scanner. I was able to get it to work on a modern 64bit system with a few caveats.
As it's an old school FreeBSD package and not using the modern pkg, I extracted it at / and then removed the "+INSTALL, +DESC" and other + files from /.
First, the binary requires libintl.so and libiconv.so which are external dependencies not included with the compat32 system in FreeBSD. Normally one would install some packages to get those. gettext-runtime and libiconv i think. It would be nice if the binary was either static linked or at least mentioned these need to be installed. You can get packages from a 32bit version of freebsd 10.x or MidnightBSD 1.2.x for these and install them and it will just work.
Second, since I was trying to run on a 64bit system, I had to install compat9x, compat8x and manually copy the above mentioned libraries into /usr/local/lib32/compat/ and then update the runtime path. I set the following in /etc/rc.conf to get it to run easier
ldconfig32_paths="$ldconfig32_paths /usr/local/lib32/compat /usr/local/lib"
ldconfig_local32_dirs="$ldconfig_local32_dirs /usr/local/libdata/ldconfig"
Then I ran /etc/rc.d/ldconfig restart
I found that I had to make two directories that are included in the +INSTALL script including one for license files and one for logging. You'll see errors when running the tools that tell you what to make if you forget.
I was then able to import the license file and startup the daemon using the rc.d script and then perform a manual scan.
It would be really nice of the binary was static linked and also if a 64bit version could be created.
I technically did this on a MidnightBSD 1.2 amd64 system, but it would also work on FreeBSD 10.x or 11.x.
Folks have been asking me about webcams lately. I've previously gotten an integrated cam on my thinkpad working, but decided to try to get my logitech 920 usb camera working on my desktop.
I've installed the following packages:
webcamd, cuse4bsd, pwcview (new port), v4l-utils (new port), v4l_compat
I then did
kldload cuse4bsd
also added it to /boot/loader.conf
Then I did
webcamd scan
I found the camera line and copied the -N line for it into /etc/rc.conf as
webcamd_o_flags="-N ... "
webcamd_enable="YES"
I added my user to webcamd group.
I then started webcamd. I was able to load pwcview (as root) and see the picture from the camera at this point. Cheese is not seeing the camera though and neither is firefox with youtube.
It's now possible to install 2.0-CURRENT from a 1.2.7 machine with some caveats.
This is only tested on amd64 so far.
before installworld, setenv MK_TESTS no (or put this in /etc/src.conf)
lib/libcasper won't install without this.
mergemaster is broken AFTER installworld. Do mergemaster -p before at least
makewhatis is broken. Comment out lines using it in src/share/man/Makefile when running installworld, then build makewhatis with new compiler, then uncomment and run make install from src/share/man directory to workaround this. (it segfaults)
sendmail is not binding after updating. Unclear what is going on so far.
Current was recently renamed 2.0 (rather than 1.3) in case we need to do a security upate past 1.2.9. It also made sense as 2.0 is a major update.
There aren't any snaps yet for current. In fact, it's not building at the moment. We're actively working on it. Buildworld on an amd64 box gets into lib32 compat libraries at this point.
The go port has been updated in mports to 1.14.3. (lang/go) This should allow newer go apps to be built.
We've finally got a native rust port (lang/rust) with 1.2.6.x version of rust. The blocker to updating further is a newer system compiler. We will attempt to updatee to 1.3.0 or so.
There was a security issue in dhclient. We've created new ISOs for 1.2.8 for those installing from scratch.
If you are on 1.2.7, you can simply update the source from git for stable/1.2 branch and rebuild dhclient.