Earlier this year, I gave a short talk at OSHUG about the BSD family of operating systems to a group of open hardware enthusiasts. I previously wrote about the event here
The videos from the event are now available on youtube
After many years of tinkering with FreeBSD, I received an invite to join the FreeBSD project earlier last month. When I first started out with FreeBSD (back in v5.0), the handbook was what lead me through the start and made me realise how empowering decent documentation is. My previous experience with $LICENSEPREFIX/$SOMEKERNEL distros had mainly consisted of marathon searches on instruction how to accomplish $thing, finding instructions for another distro which I wasn’t running & going down another rabbit hole from there. I’ll be working with my mentor Benedict Reuschling as a member of the documentation team to continue the maintenance and improvement of the documentation & manual pages in FreeBSD and also cross-polinating necessary changes to the other BSDs in the family, where applicable.
As a starting point, the committers guide instructs a new committer on some preliminary commits to the doc, base and ports repositories to add necessary information such as name / email address, PGP keys and ICBM co-ordinates.
— Sevan Janiyan (@sevanjaniyan) September 28, 2016
Pretty stoked to reach this mile stone as a part of a journey that started some years back and took me travelling around the world because of work to attending conferences and other events such as the doc sprints at BSDCan.
Now begins the next milestone to make the documentation even greater, again!
to the kernel source code!
I was looking to test a change related to buffering in
cat(1) and wondered what was the slowest system I could use which was capable of running the current versions of NetBSD, FreeBSD, OpenBSD. An old PC and the ARM based BeagleBone Black sprang to mind immediately, then a PowerPC Mac? SPARC64?
Apart from a Sun Fire T1000, I do not have any SPARC hardware, sun4v is only supported on NetBSD & OpenBSD at present, FreeBSD/sun4v was only a pre-alpha rough cut from before the days of version 7 and sparc64 support may be going away in FreeBSD moving forward.
A G4 based PowerPC Mac is supported between my choice of BSDs, unfortunately I couldn’t get a working disk burnt from the FreeBSD iso files to try it out on a 12″ PowerBook. bug/211488.
I settled on running i386 builds on a Alix 2c3 I have, it has 256MB RAM and a 500Mhz Geode CPU, currently running FreeBSD/i386 11-BETA3 without issue and has no problems with any of the other BSDs. It’s a little too “modern” and high spec though in my test.
I’ve been running a mixture of FreeBSD / OpenBSD & NetBSD as guests on a dedicated server at Online.net. While getting the operating systems installed was fairly seamless, getting networking going was not.
- Client are not isolated in a layer 2 domain
- DHCPv6 config is broken
Clients not being isolated is not so much a problem itself and is typically what you’d expect if you plugged a bunch of computers into a switch with a single VLAN or unmanaged switched for example; but in a shared environment with untrusted tenants it can cause problems. Broadcast & IPv6 multicast floods aside, one is open to most of the attacks in something like THC-IPv6 due to lack of MLD snooping which would prevent a rogue IPv6 router.
Attacks via IPv6 are not so much of a problem as their use of non-RFC complaint timers settings in their DHCPv6 make it unfeasible to use the offered native IPv6 connectivity as clients will fail to renew leases. Depending on the DHCPv6 client used, the amount of time it takes fail to renew a lease will vary. dhcpcd for example now warns if detects a lease is not compliant with RFC 3315 section 22.4 “Identity Association for Non-temporary Addresses Option”.
Despite having a vast address range in IPv6 and a /48 subnet is allotted free of charge, you’ll need the equal amount of v4 address addresses as the v6 addresses you intend to use at Online.net. There is a way of using a /48 and allocating addresses yourself but it’s only possible using a version of Proxmox which they provide.
You can save yourself a lot of hassle both with configuration & trying to deal with their support regarding IPv6 by using a Hurricane Electric tunnel. I actually found connectivity was also faster from Hurricane Electric than using the native connectivity.
For IPv4 connectivity on a guest (assuming you’re renting individual IP addresses & not a /27 prefix), you’ll need to use the default gateway IP address assigned to your host alongside the allotted IP address and a /32 prefix.
Assuming the network details are as follows
Default gateway on host: 192.0.2.1
Failover IP #1: 198.51.100.10, assigned to MAC address 00:50:56:00:01:AA
Failover IP #2: 203.0.113.11, assigned to MAC address 00:50:56:00:02:BB
Failover IP #3: 203.0.113.100, assigned to MAC address 00:50:56:00:03:CC
The MAC addresses need to be assigned to the
tap(4) interface on the host.
If you’re using bhyve and your guest is using the interface
tap0, this would be performed using the
-s flag to configure the virtual PCI ethernet card, eg
It’s then onto configuring each OS to handle a gateway which is in a another subnet for IPv4 connectivity.
In FreeBSD you need to construct a route to reach the default IP address first, before you specify the default IP address, otherwise things will not work. So assuming we’re going to use Failover IP #1, your configuration in
/etc/rc.conf would be as follows
route_gateway="-host $gateway_ip -interface $gateway_if"
Note, the installer at present prevents network installs, you should use a iso image containing the distfiles, bug 206355 has more details.
On NetBSD, configure networking using
/etc/netstart.local, entering the commands you’d enter at the console inside the file. Assuming failover IP #2 is going to be used for the NetBSD VM, the following would configure the guest to reach the outside world using 192.0.2.1, as discussed in the NetBSD Network FAQ
ifconfig vioif0 203.0.113.11/32
route add -net 192.0.2.1 -link -cloning -iface vioif0
route add default -ifa 203.0.113.11 192.0.2.1
On OpenBSD, configure the networking from the ethernet interfaces configuration file
Assuming failover IP #3 is going to be used for the OpenBSD VM, the following will setup networking.
inet 203.0.113.100 255.255.255.255 NONE
!/sbin/route add -net 192.0.2.1 -netmask 255.255.255.255 -link -cloning -iface vio0
!/sbin/route add default -ifa 203.0.113.100 192.0.2.1
It’s also possible to not specify the
-cloning flag but a patch is required if you’re running 5.9 release.
At OSHUG #46 I was given the opportunity to present the BSD’s to a group of open source hardware enthusiast & speak about why this family of operating systems would benefit the person running a flavour on their hardware. There was a recording made of the talk but it may be some time before it is made available online, so I thought I’d take the time to write something up to share in the meantime.
This line of operating systems started out life as a series of patches to AT&T UNIX which was introduced to the University of Berkeley by Ken Thompson whilst on sabbatical in 1977.
From the 1BSD
TAPE file included in the CSRG archive CD set
Berkeley UNIX Software Tape
Jan 16, 1978 TP 800BPI
The first release came with things such as the
ashell and Pascal compiler as an add-on for UNIX v7, running on a PDP-11. Over the life time of the CSRG they produced releases which included
csh, the IPv4 TCP/IP network stack, the virtual memory subsystem (the kernel being named
vmunix, parodied by Linux as
vmlinuz) and UFS.
The distribution tapes were only available to AT&T licensees; over time the code base of the distribution grew increasingly independent from AT&T UNIX. At the same time the cost of the AT&T license continued to increase as well. Starting out at a cost of $10000 and reaching north of $250000 in the late 80’s. According to Kirk McKusick there was pressure to release the independently developed components of the CSRG so the community could benefit from the use of things such as the network stack without purchasing a costly license. This resulted in several release, comprised mostly of the code developed outside of AT&T such as 4.3BSD-Net/1, Net/2, 4.4BSD-Lite & Lite2. “Mostly” in that with the release of Net/2 AT&T file a lawsuit against the University of California for alleged code copying and theft of trade secrets.
During its lifetime, BSD saw itself being run on several CPU architectures from the DEC PDP-11, VAX to the MIPS, HP 9000 and Motorola 68000 to name a few. These ports along with the Power 6/32 helped to improve the portability of the code base. The code base was deemed to be 90% platform independent, the remaining 10% being mostly related to the VM subsystem which was platform specific. As with AT&T UNIX, portability & migration between different systems was part of the nature of the code base, from the beginning.
The 4.3BSD-Net/2 code base was used as the basis for a port to the Intel 386, resulting in 386BSD (free) & BSD386 (commercial) releases.
The Modern BSD variants
At the time of writing there are many BSD variants in existence, each with its own area of focus. Everything still leads back to 2 major variants.
NetBSD was the first of the modern variants that is still actively developed. It started out life as a fork of 386BSD. The focus of NetBSD is portability which not only makes porting to new hardware easier (currently supporting over 60 different ports across may CPU architectures).
Everything from a VAX, ARM & MIPS Windows CE based PDAs to a Sega Dreamcast and many other systems are supported and able to run the latest version of NetBSD. There’s even a toaster which run NetBSD
The focus on portability also makes reusing components on other operating systems easy. For example the packaging system (forked from FreeBSD (which we’ll talk about next)) supports over 20 operating systems.
This enables a consistent toolset to be used regardless of operating system.
Some of the highlights of NetBSD include ATF, unprivileged builds and portable build infrastructure using
ATF, as the name suggests is used for automated tests of the source code to discover regression in the code base in an automated manner. Results can be found on the NetBSD release engineering page.
Unprivileged builds allow a user to not only build a copy of the operating systems without elevated privileged, but they can also build and install software from pkgsrc in a location they have write access to (by default, in a prefix under their home directory).
build.sh, the build framework, allows NetBSD to be built on any modern POSIX compliant operating system. Freeing the person to use a operating system of their choice to build releases.
04/05/2016- Note Ollivier’s comment, I made a mistake when I was gathering info and looked at the source for head and checked the history for the COPYRIGHT file there, not noticing the repository started with v2.0.
Forked from the 4.4BSD Lite code base, 6 months after NetBSD was started. The focus of FreeBSD was performance on i386 systems. Over time support was added for the DEC Alpha as this meant porting the code base to a 64bit systems and addressing any bugs which would prevent the code base from running on a 64bit system. Many years later the project branched out and introduced support for additional platforms. Today the project boasts support for CPUs such as ARMv8, RISC-V and BERI.
Forked from NetBSD, the focus of OpenBSD is security. The project is home to many components which see wider use outside of OpenBSD, such as OpenSSH, PF (firewall), LibreSSL and others.
Forked from FreeBSD, the focus of DragonFly BSD is scalability & performance. Taking the operating system in a new direction with regards to how SMP is implemented and from there, developing a new files system called HAMMER.
No matter the flavour, documentation is a key part of the development process for the BSD’s.
Whether it is the Design & Implementation series which started with covering 4.3BSD in 1989 and more recently FreeBSD 10 in the fourth instalment of the series, or each projects own set of documentation. Documentation is important as it distinguishes intent & implementation as well as save a lot of question and answers emails.
FreeBSD has handbooks, NetBSD has guides, OpenBSD has FAQs and all projects make their man pages available online as web pages. There is even a teaching course based around the The Design and Implementation of the FreeBSD Operating System, 2nd edition.
Frameworks for building embedded images
Each operating system release is a complete, self contained bundle, containing the documentation and necessary toolchain required for building a copy of the operating system from source.
release(7) on FreeBSD & NetBSD,
release(8) on OpenBSD,
nerelease(7) on DragonFlyBSD
For the purpose of embedding the operating system it may not be desirable to build a full blown release. Depending on the choice of variant, either the functionality is built in as standard or a project exists to assist with generating customised images with ease.
FreeBSD had PicoBSD which is now superseded by NanoBSD.
OpenBSD has flashrd and resflash.
NetBSD has a target for generating an image in
build.sh, customisations controlled by variables set in mk.conf.
DragonFlyBSD has nrelase.
RetroBSD / LiteBSD
RetroBSD is a port of 2.11BSD (originally targeted for the PDP-11) to the MIPS M4K core found on the PIC32 micro-controllers. LiteBSD is a port of 4.4BSD to the PIC32MZ micro-controllers with a MIPS32 core. Due to the limited resources available, RetroBSD does not offer a network stack, Of the 128KB of RAM, 96KB are available for user space applications. A compiler, editor & various utilities come bundled with the OS so software could be developed on the PIC itself. Variants of common software titles are available to extend the system, such as an Emacs like editor.
LiteBSD is based on a more recent version of BSD, taking advantage of the availability of more RAM (512KB) and MMU on the targeted micro controller. It features a network stack.
Projects such as these take advantage of prior effort and offer the user a consistent environment from the microcontroller to desktop to server. With the extensive documentation and availability of source history, it is possible to realise at which stage in the evolution of the code base the currently running system is and if a desired feature is implemented.
The development of BSD is closely tied with that of the internet. BSD’s modern variants are some of the oldest communities who have collaborated over the internet to develop a software project. The workflow of the projects has transpired to become the standard way of developing open source software on the internet, whether it’s adhering to a style guide or developing with a publicly accessible source repository or holding a hackathon.
For a newcomer interested in an operating system to run on your hardware, it is a great opportunity to be a part of a tech savvy community working to evolve an idea started almost 40 years ago.
As a business, each project produces a mature and robust operating system that has seen many applications from running on devices such as game consoles, mobile phones, cars, satellites and the international space station. Nearly all projects are backed by a non-profit foundation which can act as a liaison for businesses and assist with enquiries regarding development.
To fill in the gap since the last post, I thought I’d get the notes which had been collecting up, posted here. pkgsrc got a mention in the Quarterly FreeBSD status report. My bulkbuild effort started on FreeBSD/amd64 10.1-RELEASE but thanks to my friend James O’Gorman, I was able to expand to FreeBSD 11-CURRENT and recently switched over from 10.1-RELEASE to 10.2-RELEASE.
I got the idea to try to pkgsrc on Android after someone posted a screenshot of their Nexus 7 tablet with the bootstrap process completed.
Android Nexus7?NetBSD?????????pkgsrc???????????? gcc?ncurses,coreutils??????????????debian?noroot???????????????????? pic.twitter.com/NclfQ9tJ9K
— Kapper@Netwalker Lab (@kapper1224) July 26, 2015
There are several projects on the google play store for running the user land built from a Linux/arm distro in a chroot on Android.
The first project I tried was Debian noroot (based on the tweet that inspired me), it spawned a full X11 desktop to run & so the process was painfully slow.
— Sevan Janiyan (@sevanjaniyan) August 22, 2015
Switching to GNUroot Debian which just ran a shell in the chroot was much faster at extracting the pkgsrc archive though bootstrap still took long. The best result was with Linux deploy using an Arch Linux user land, everything was very snappy.
On Mac OS X Tiger PowerPC, GCC 5 appears to no longer require switching off multilib support when building on a 32-bit PowerPC CPU, my hardware has changed but the CPU is still a G4. The same changes to force dwarf2 and removing the space in-between flags and paths fed to the linker were otherwise required, as with previous versions of GCC.
I spent a little time with OmniOS and “addressed” the outstanding issues which prevented it from working out of the box.
shells/standalone-tcsh was excluded on OmniOS which prevented the version of
tcsh shipped with the OS from being clobbered during bulkbuilds. The other issue was what appeared to be a problem with gettext but turned to be an issue with the compiler shipped with OmniOS. This became a topic of discussion on what the correct solution to the problem is. The GCC provided with OmniOS is built with Fortran support and includes the OpenMP libraries (I’m guessing this is the reason for the libraries) in its private lib directory inside
/opt/gcc-4.8.1/lib, it turns out that gettext will make use of OpenMP libraries if it detects them during configure stage which I’ve not been able to find a concrete answer for why, the GCC documentation don’t say more than a paragraph about the OpenMP libraries themselves (libgomp) either. The problem was that GCC was exposing its private library in the link path but not in the run path, this meant you could produce binaries which would compile fine but would not run without having to play around with the runtime linker. In my case I’d previously added the private library locate to the runtime linkers search path as a workaround, I disabled the OpenMP support in
devel/gettext-tools and that’s where the discussion began. Basically, it’s not possible to expose the private library location to the linker because that would cause issues with upgrades. The location should not be exposed by the compiler in the first place (I guess this was for the convenience of building the actual release of OS?). Richard Palo pursued the issue further and I’m informed that future releases of OmniOS will move libgomp out from this private location to
/usr/lib so that it’s in the default library search path.
With the introduction of the GPLv3 license, GNU projects have been switching to the new license. This causes problems for projects outside the GNU eco-system which utilise them if the terms of the new license are unacceptable for them. Each project has dealt with it differently, for OpenBSD they maintain the last version which was available under GPLv2 & extend the functionality it provides. Bitrig has inherited some of this through the fork. Through the bulkbuilds it was revealed that the upstream version of binutils has no support for OpenBSD/amd64 or Bitrig at all. Adding rudimentary support was easily achieved by lifting some of the changes from the OpenBSD CVS repo. While at present I’m running bulkbuilds against a patched devel/binutils which I’ve not upstreamed or committed for both OpenBSD & Bitrig, I am thinking that for OpenBSD we should actually just use the native version and not attempt to build the package. For Bitrig, there is already a separate package in their ports tree for a newer version of binutils, it’s pulled in alongside other modern versions of tools under the meta/bitrig-syscomp package so it makes sense to mimic that behaviour.
Coming to the realisation that stock freedesktop components were not going to build on OpenBSD, I switched to using
X11_TYPE=native to utilise what’s provided by Xenocara. Despite the switch, pkgsrc still attempted to ignore the native version of MesaLib and try to build its own, the build would fail and prevent a couple of thousand packages from building.
This turned out to be because of a test to detect the presence of X11 in
mk/defaults/mk.conf, it was testing for the presence of an old path which no longer exists. As this test would fail, the native components would be ignored & pkgsrc components would be preferred. The tests for OpenBSD & Bitrig were removed & now default to a default of an empty
PREFER_PKGSRC variable. The remaining platforms need to be switched over after testing now.
As Mac OS X on PowerPC gets older and older with time, the requirement for defining
MACOSX_DEPLOYMENT_TARGET grows ever more redundant, Ruby now ships with it & unless it’s defined, you will find that it’s not possible to build the ruby interpreter any more. I am considering setting
MACOSX_DEPLOYMENT_TARGET="10.4" for PowerPC systems running Tiger or Leopard so that packages could be shared between the two but have not had a chance to test on Leopard yet to commit it. I somehow ended up on a reply list for a ticket in the Perl RT for dealing with this exact issue there. They opted to cater for both legacy & modern version of OS X by setting the necessary variables where necessary.
Getting through backlogged notes to be continued
It’s been a while since the last post in the series, the details of what was covered in these posts was the partial basis of my talk at BSDCan and I got to repeat the talk again in Berlin, I was much less nervous the second time, not having a fire alarm going off during the talk may have helped. I will cover briefly some things that were mentioned in the talks which I hadn’t written up here, for the sake of completeness.
Thanks to the DragonFlyBSD folks, I have access to a build server for doing regular bulkbuilds on. As I’m running these as a unprivileged user, there’s not much parallelism in the package builds, it’s one package at a time. The system aptly named Monster is a 48 Opteron CPU server with a 128GB of RAM so I can at least run with
MAKE_JOBS set to 96. At the start of the bulkbuilds some deadlock issues in DragonFlyBSD were revealed by pkgsrc which Mat Dillon addressed promptly.
On the Bitrig front, I managed to add support for the OS to
lang/python27 which was the package causing the biggest breakage and now in the process of trying to get the support added upstream, there appears to be a bug report from 2013 in the Python bug tracker to add support ubut it was marked as won’t fix, I’m hoping the decision will be changed but will have to wait and see.
With Python 2.7 built successfully it was onto the next set of breakages, gettext!
I had taken a patch from OpenBSD ports for getting
devel/gettext-tools building but was asked to back it out as it was not the correct solution to the problem. I decided to reapply the fix in my build just to progress to the next hurdle. The next major breakage was with
devel/p5-gettext which needed to be told to include
libiconv, I’m now stuck at getting
During this process I found that we were missing some necessary flags for creating shared libraries which were highlighted by clang:
relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC
This turned out to be bug in the platform support, the necessary fPIC flags were defined but under a if statement for version of OS running with a.out binaries still.
mk/platform/Bitrig.mk was stripped of anything related to a.out and everything was rebuilt again from scratch.
OpenBSD and Bitrig probably have many more breakages due to the fact that their architecture is detected as amd64 and not under the x86_64 banner by the build system. One example is
x11/libdrm which is set to add
sysutils/libpciaccess as a dependency if the host is a i386 or x86_64.
At present libdrm fails at the configure stage with
checking for PCIACCESS... no
configure: error: Package requirements (pciaccess >= 0.10) were not met:
No package 'pciaccess' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables PCIACCESS_CFLAGS
and PCIACCESS_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
Trying to add OpenBSD to the x86_64 arch list revealed a problem in pkgsrc, the culprit being
The problem is that there are three separate points where the architecture is defined. In the bootstrap script, in BSDMake’s on source and the settings it passes onto
pkgtools/pkg_install. Unfortunately the settings defined at the start in bootstrap are ignored at the bootstrap stage & are not necessarily what pkg_install is built with. To add to this, it’s possible that BSDMake may need to work out what the system is for itself rather than to be expected to have settings passed to itself. That is they should build with settings passed down in succession or independently.
With severe bludgeoning of code between
pkgtools/pkg_install, I managed to get it to
pkg_add: OpenBSD/x86_64 5.7 (pkg) vs. OpenBSD/amd64 5.7 (this host)
pkg_install performs a check of the OS it’s running on against the settings it was built with (the settings bmake passed it during bootstrap), removing the check revealed there was nothing else preventing things from working but the check needs to be there.
For OmniOS, a major components components in the OS which caused many packages to break was the bundled
gettext, failing during builds as it could not find the
libgomp from (the also bundled) GCC. As a temporary work around to see how the build would progress if
libgomp could be found, I added the lib directory to the search path of
Configuration file [version 4]: /var/ld/ld.config
Platform: 32-bit LSB 80386
Default Library Path (ELF): /lib:/usr/lib:/opt/gcc-4.8.1/lib
Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default)
crle -c /var/ld/ld.config -l /lib:/usr/lib:/opt/gcc-4.8.1/lib
It was possible to build 13398 packages out of 16536 possible packages with this workaround in place.
With the help of Joerg Sonnenberger, at pkgsrcCon I added support for fetching the OS version info in OmniOS & SmartOS for use in build build reports, this should mean that these operating systems will be reported correctly rather than as SunOS 5.11.
sevan.mit.edu is back online as a G4 Mac Mini with 128GB SSD. It’s yet to complete its first bulkbuild since the rebuild but it’s nearly finished as I type this.
It’s now possible to build more than 14100 packages on FreeBSD 10.1-RELEASE with pkgsrc.
The past few weeks have been pretty hectic, as the time for BSDcan gets shorter and shorter, I’m thinking about my talk and testing more and more in pkgsrc. Rodent@ added support for Bitrig to pkgsrc-current last month, his patches highlighted an issue with the autoconf scripts (which should be shared across core components) not being pulled in automatically. Joerg Sonnenberger resolved this issue and I regenerated the patch set again. With the system bootstrapped the next thing which was broken was Perl, applying the changes needed for OpenBSD resolved any remaining issues and the bulk build environment was ready. After three days, the first bulkbuild attempt on Bitrig was complete and a report was published. There is now a bulkbuild in progress with
archivers/unzip fixed, that should free over 8400 packages to be attempted to be built.
For Solaris, my first bulkbuild on Solaris 10 completed after 22 days. Mid-April I also started off bulkbuilds on Solaris 11 (x86 and SPARC) using the SunStudio compilers (It’s not possible to use GCC at the moment due to removed functionality that was previously deprecated). The Solaris 11 SPARC bulkbuild is still in progress and the x86 bulkbuild is running. Unfortunately the build cluster had some connectivity issues and needed rebooting during the bulkbuild but not until lots of packages had failed to fetch distfiles, hence the figures look a lot worse than they could be. Solaris 10 SPARC report, Solaris 11 x86 report.
Through bulk building on multiple operating systems another issue that’s surfaced is problematic packages that hold the build up. On Bitrig
mail/fml4 is an issue, on OpenBSD
www/wml, FTP mirror issues for ruby extension on Solaris, Xorg FTP mirror issues on OmniOS. Things need regular kicking, a brief glance into
pkgsrc/mk didn’t reveal any knobs which would allow the preference of HTTP for fetching distfiles. On Bitrig & OpenBSD I’ve excluded these packages from being attempted via
NOT_FOR_PLATFORM statement in their
Makefile until I have a look into the issue.
sevan.mit.edu completed another bulkbuild, pkgsrc-current now ships with MesaLib 10.5.3 as
graphics/MesaLib, version 7 has now been re-imported as
graphics/MesaLib7 by tnn@, the new MesaLib needed a patch for FreeBSD, similar to NetBSD to build successfully, due to
ERESTART not being defined. At present, it’s still broken on Tiger as I’ve not looked into yet.
I revisited AIX again to test out pkgsrc once again, this has turned into a massive yak shaving session. I’ve yet to run a bulkbuild successfully as the scan stage ends with a coredump.
I originally started off with using the stock system shell, bootstrap completed successfully but scan stage of a bulkbuild would just stop without anything being logged. Manually changing the shell used to
pbulk/etc/mk.conf resulted in the following error message:
bmake: don't know how to make pbulk-index. Stop
pbulk-scan: realloc failed:
This turned to be a lack of RAM, my shell account was to a AIX 7.1 LPAR running on a Power8 host with 2 CPUs and 2GB of RAM committed, unfortunately the OS image IBM provided came with Tivoli support enabled and a bug in the resource management controller which meant RMC was consuming way more resource than it needed to. I was running with less than 128MB of RAM.
Stopping Tivoli & RMC freed up about 500MB of RAM, attempting to bulkbuild again, caused the process to fail once again at the same stage. With a heads up from David Brownlee & Joerg Sonnenberger, I bumped the memory and data area resource limits to 256MB.
This allowed the scan to finish with a segfault.
/usr/pkgsrc/pbulk/libexec/pbulk/scan: 11272416 Segmentation fault(coredump).
pscan.stderr logged multiple instances of
bmake: don't know how to make pbulk-index. Stop.
The segfault generated a coredump but it turned out that
dbx, the debugger in AIX was not installed. IBMPDP on twitter helped by pointing to the path where some components are available for installation, unfortunately, while the dbx package was available there, some of its dependencies were not. Waiting on IBMPDP to get back to me, I fetched a new pkgsrc-current snapshot (I couldn’t update via CVS because it wouldn’t build) and re-setup my pbulk environment via
I should mention that initially when I setup, I’d explicitly set
CC=/usr/bin/gcc last time, then while trying to get various things to build subsequently, I’d symlink
/usr/bin/gcc. When I came to set thing up with the new snapshot, I did not pass
CC=/usr/bin/gcc this time round and found that I was unable to link Perl, not sure if this was the Perl build files assuming if on AIX &
/usr/bin/cc exists, it’s XLC or if
ld(1) takes on different behaviour but I had to remove this symlink.
Once everything was setup, the bulkbuild failed agin at the same place, except this time I had a different message logged.
/bin/sh: There is no process to read data written to a pipe..
I edited the
bootstrap/bootstrap script &
devel/bmake/Makefile to set
shells/pdksh as a dependency & rerun bulkbuild.
The scan stage again completed with a coredump with this time
pscan.stderr just contained
Memory fault (core dumped).
I’ve committed these changes so pkgsrc-current now defaults to using
shells/pdksh as its shell but have not been able to try anything else as this weekend the system is unaccessible due to maintenance.
At present, I’m attempting to bulkbuild pkgsrc-current on 8 Operating systems
OpenBSD (5.6-RELEASE & -current), FreeBSD, Bitrig (current), Mac OS X (Tiger), Solaris (10 & 11), OmniOS on 4 architectures (i386, AMD64, SPARC, PowerPC).
If I could get AIX going that would bump the OS & arch could up by 1. Maybe by the next post perhaps. 🙂
Thanks to Patrick Wildt for access to host running Bitrig and Rodent@ for adding support to pkgsrc.
Yesterday I gave a talk at SANE user group on my history with wireless networks as part of the PierToPier.net project in Brighton (now defunct) and my experimentation with captive portal software which I began revisiting this time last year. I thought it would be a good opportunity to develop my programming skills by tidying up and modernising parts of the codebase which caused problems, such as things preventing builds on a modern system with clang which is now the default compiler for FreeBSD on i386/AMD64 architectures and OS X. The slides from my talk can be found here.
Back in the early to mid 2000’s there were 2 initiatives to provide public access wifi in Brighton. Loose Connection and PierToPier.net, each had a different focus & approach.
Loose Connection was a commercial venture which could be deemed a VAR, they resold a ADSL connection along with a draytek router & that was it. Individual wireless networks with the loose connection SSID dotted around drinking holes in Brighton, the founding(?) company Metranet lives on as a WISP today.
PierToPier.net was a community driven effort with a technical team of volunteers, predominantly from a service provider / telecoms / networking background. Each node on the network was sponsored by a host who’d buy and run the equipment while the project members managed it.
The project started off based around the fanless VIA mini-itx boards, Prism2 chipset wireless cards, booting linux with hostapd and nocatauth/nocatsplash off a CF card in a IDE to CF adapter.
This was a very flexible platform, if there was no package for it you could build it with ease, problem was that it had a high cost for entry, £250 to £300? so from the start we were looking to reduce costs.
The other issue was though we’d eliminated moving parts, the casing was not suitable for outdoor use.
With the availability of 3rd party firmware and promotional sales of the WRT54G, PierToPier switched hardware platforms as the low cost solution for new nodes.
Tom Grifiths discovered Chillispot around the same time frame and we adopted it due to enhanced functionality it provided, such as RADIUS accounting and working captive portal. We’d previously ran into issues with browser support running nocatauth which by that point was no longer maintained and stability issues with nocatsplash.
VIA motherboard again this time with CF adapter & mini-pci slot onboard
2x Atheros A/B/G mini-pci cards, one on mini-pci to PCI bridges and second onboard
Stuck to a pelican case with epoxy
Two holes drilled in the side of the case for external antennas
It was early times for support of the cards and the wireless standards. In this era OpenBSD was leading the way in terms of support of hardware and development of their
ieee80211 wifi stack, they were the first to reverse engineer the Atheros binary blob HAL (years before anyone?) but late to the game for the 802.11g, 11a was enabled from the start but didn’t appear to work – bringing the interface up in .11a hostap mode wouldn’t necessarily work.
Looking at alternatives there was a short lived live environment named WifiBSD which was based around FreeBSD but later moved to NetBSD before development ceased. The support for the Atheros cards was not as good as OpenBSD, hence not wasn’t much use.
The hardware for the Glastonbury nodes were truly terrible, all functionality had been wired to a single bus which caused the system to lock hard in most configurations. e.g. you booted from a CF card and tried to bring up a wireless interface. The only way to use the system was to disable everything that wasn’t needed in the BIOS including VGA, if there was an issue, you’d have to factory reset the BIOS before diagnosing.
For the wireless network at Glastonbury, the 11a 5GHz network was used as the backhaul while the 11b/g interface was used for connecting wireless clients. No captive portal, connect to the AP & off you go.
We arrived onsite on Tuesday, starting getting things running, Thursday morning the rain and lightning started things went downhill from there. loss of connectivity between the backhaul links meant things fell apart.
By the time we’d discovered Chillipot the project had a 1.0 release out which had preliminary support for FreeBSD. The website claimed only FreeBSD 5 and up were supported, I created a port and submitted it for inclusion in the tree, net-mgmt/chillispot was born, Edwin@ from the ports team fixed the code so that it’d work on previous releases. I then moved onto creating a OpenBSD port, this was slightly harder and the final peace was actually resolved by a Steve Davies. I got the code to build on OpenBSD but networking wouldn’t work. This turned out to be because an additional 4 bytes needed to be allocated which Steve fixed. It never made it into the OpenBSD tree (only tested it on i386 and SPARC, it used strcpy() everywhere and didn’t run on SPARC) but it can be found in ports-wip. I then moved onto creating a live CD environment based on FreeBSD 6 using freesbie for advocacy purposes named BrightonChilli. The idea was to remove the hurdle of going through the installation process and provided an environment that just needed the configuration of network interfaces and chillispot. A person with previous experience of running chillispot would be familiar and a new user would not be too out of place.
This was in the days of X configuration being a part of sysinstall which could hang if Xconfigure was run and you’d have to start the install process again as the install was incomplete (for a newcomer). I was interviewed on BSDtalk #73 regarding BrightonChilli.
PierToPier also produced its own Linux image named Muddy Linux targeted for x86 hardware that ran the necessary stack to serve as a node on the network.
After Chillispot 1.1.0, the project went quiet, there was no answer from the founding developer for quite a while and eventually the web hosting stopped and the domain expired.
The community rehomed to coova.org and development continued in Coovachilli which was founded by David Bird, a contributor to Chillispot.
Coovachilli initially lacked support for FreeBSD but it was eventually added in by David and net-mgmt/coovachilli was born in ports. Not much else was done after that until a year ago. With FreeBSD 10 and the switch to clang, the codebase needed attention, first step was to get it to build correctly with GCC. The use of
error_t from glibc caused the build to fail as it’s not available in FreeBSD, ensuring this was declared allowed the build to complete successfully. To resolve build issues with clang, nested functions were separated out. Any function with missing prototypes & parameter lists were addressed next.
struct ifreq had been marked as deprecated since 2000 and was finally removed in FreeBSD 10. The *BSD specific sections of Coova were switched out to the new
struct ifaliasreq & Linux was left to use the pre-existing method. There was extensive use of macros for the logging functionality, these were dropped in favour of using the existing standard
syslog(3) with the correct log level defined. This had the benefit of revealing issues which were not detected previously such as incorrect format specifiers.
There are still many things that need to be cleared up, the 3rd party functions added in are particularly problematic and will probably be my next task to replace with standard components.
CoovaChilli & Chillisport have seen large scale deployments thanks to use by Fon, o2 and Google which now owns Coova.
Or should that be a month of pkgsrc!
Since I wrote my last post I received the good news that I’ll be presenting at BSDCan this year in Ottawa. I’m really stoked about this and looking forward to presenting there. In preparation for the big day, I’ll be speaking about different aspects of what I’ve been working on at various events/meetings. My first speaking opportunities will be at Oracle’s SolarisSIG (LOSUG in a past life) tomorrow on cross platform packaging with pkgsrc.
I didn’t have any hosts running Solaris to attempt bulkbuilds on for this, so I asked for shell access at various places, this landed me with access to Solaris 9 to 11 on x86 & SPARC and OmniOS.
Shell access to a Solaris 10u9 host came first and I quickly found that mandoc would not build due to the use of
vasprintf() whilst attempting to setup a bulkbuild environment using the
mk/pbulk/pbulk.sh script in pkgsrc.
Following up with the mandoc developers regarding the issue meant the issue was fixed by Ingo Schwarze within a couple of days with access to Solaris via OpenCSW, the next release of mandoc due Summer time will contain these fixes. I’m undecided whether to back port the fixes to the current release or not. If you have a Solaris 10 host with a “recent” patch cluster (unsure how recent) you should be unaffected by this issue.
On OmniOS, the
shells/standalone-tcsh package reared its head again. OmniOS ships with tcsh as standard which
shells/standalone-tcsh clobbers again during bulkbuild. The solution to this may be that pkgsrc becomes aware of the various Illumos distros instead of treating everything as SunOS, but nothing has been decided for definite and needs further discussion.
The bulkbuilds on OmniOS using the toolchain published in IPS for that release show issues in pkgsrc where libgomp bundled with GCC is not being found by gettext, this causes lots of packages to fail.
The first bulkbuild which completed showed it was possible to build 9547 out 15245 packages without issue but the inability to build
databases/shared-mime-info due to the libgomp issue caused 2274 packages to fail. This was the large impact of the issue mentioned but there are more packages which suffer from the same problem.
With the resumption of bulk building pkgsrc on FreeBSD, I found lots of packages which would fail to package due to use of the
-o flag with
pax(1) which is not present in the FreeBSD version. I’ve not yet addresses the issue with those packages but I did raise a patch for FreeBSD-current so that it will be available in future versions of FreeBSD. It is now committed and will treacle down to 10-STABLE at some point for inclusion in FreeBSD 10.2-RELEASE.
Bulk builds have also resumed on OpenBSD/amd64 and Sparc64, there is a third bulkbuild in progress on amd64 while the sparc64 host is still running the first attempt. The use of unprivileged user account and the lack of nullfs support prevents the setup of parallel runs to speed up the process. Building on OpenBSD was extremely useful for indicating what software in pkgsrc is effected by LibreSSL without having to put effort into integrating LibreSSL into pkgsrc first. It also raised an instance of copying overlapping buffers destructively (using
memmove()), a fix for this issue is yet to be committed pending further investigation.
MAKE_JOBS was raised to 8 on OpenBSD/sparc64 to improve performance whilst compiling, the build environment is hosted on a Sun T5210 with a dedicated disk mounted with soft writes & the
kern.bufcachepercent value bumped from 20 to 50.
With the pkgsrc-2015Q1 release announced, the figures for packages indicate that Darwin/PowerPC exceeded Darwin/x86.
11224 binary packages built with gcc for Darwin 8.11.0/powerpc
10019 binary packages built with gcc for Darwin 10.8.0/i386
My first bulkbuild report sent to to the pkgsrc-bulk mailing list back in September 2014 shows a total of 8501 packages could be built. There is more work required to keep this position in the future, as a new version of MesaLib is to be committed at some point soon. There is a bulkbuild in progress on sevan.mit.edu, upon completion I’ll be placing a request for the host to be wiped and setup again, the bulk builds are getting slower and slower and I suspect the IDE disk may be failing.
Thanks to Phil Stracchino, Sascha Curth and the OpenCSW Project for access to hosts running Solaris. Ian Kremlin, Brandon Mercer & Rodent @ NetBSD for access to hosts running OpenBSD.
Time again to write up what’s been happening on the pkgsrc front since last time, this time the focus hasn’t been so much around pkgsrc on Darwin/PowerPC but more about pkgsrc in general & not necessarily code related.
At the end of the last post I mentioned a gentleman who’d been working on pkgsrc/Haiku and posting videos of his progress, I managed to make contact with him (James) & discussed his work that he’d been doing on pkgsrc. He sent me copy of the repo he’d be working off so I could assist with the aim of getting everything upstreamed as in the current state everything would need to be reintegrated per quarterly release rather than only having to pay attention if a new issue has arisen.
After getting the correct version of Haiku installed in virtualbox, I discovered a nasty bug in the Haiku network kit, it was unable to detect when the end of the file had been reached & would continue (restart?), this was revealed when I tried to download the pkgsrc tar ball from via WebPositive, ftp from the terminal was not affected however. pkgsrc bootstrapped unprivileged without issue. Hint: use the nightly snapshots until there is a newer release than Alpha 1 available.
The integration of pkgsrc into the user-land on Haiku is not currently possible due to the way the user-land is constructed, from what I understood, each Haiku package contains a piece of the filesystem, all the packages are union mounted to construct the user-land dynamically when the system comes up. That aside, with my system bootstrapped, I attempted to build Perl and ran into another bug, it seems that the library path for libperl is not populated on haiku hence perl is able to “build” but unable to run, the workaround for this in the tree I was given was to symlink libperl into
~/pkg/lib & move on. I tried various things but was unsuccessful, I believe the problem is pkgsrc specific as the version of Perl available in haikuports do not need any special treatment and the
rpath is passed in correctly.
The problem was trying to isolate the required change to fix the problem, whereas in pkgsrc a policy file is passed to the build to set how Perl should be built, haikuports clobbers the source & patches in a replacement, I stopped at that point.
At around about this time I received the good news about the NetBSD Foundation membership and commit bit so my focus moved to reading the various developer documentation & getting familiar with processes.
sevan.mit.edu finished a bulkbulid attempt of the entire tree which took the longest time so far to complete, through all the build attempts I uncovered a new bug, the range to use for numerical IDs of UID/GID, is not sufficient to cover all the packages in the tree that need to create an account. On further discussion with asau@, it was suggested the IDs are allocated randomly and should be fixed for consistency across builds. I started doing bulkbuilds of the entire tree on FreeBSD 10.1-RELEASE and stumbled across a very nasty bug. There is a version of tcsh package in the pkgsrc tree called
shells/standalone-tcsh, this is tcsh built as a static binary & set to install to
/bin (the only package in the pkgsrc tree which violates the rules and places files outside of
$PREFIX by default?), this ended up overwriting the system bundled version of tcsh in FreeBSD & then deleting
/bin/tcsh when the package is removed, this was fixed promptly by dholland@. It was also discovered that Python’s configure script had not been changed when FreeBSD switched to elf binaries and so still trimmed the name of libraries to account for the old linker which could not handle a minor version in a libraries filename (libpython.so.1, not libpython.so.1.0). All versions of Python had been patched in the pkgsrc tree to remove this change so that it used a consistent naming convention across all platforms. After discussing this with bapt@ (FreeBSD) at FOSDEM, it turned out to be bug and should be fixed in future Python versions once the fixes are upstreamed.
The opportunity to join the pkg-security team came up & for the past few weeks I’ve been getting familiar with the processes of dealing with security advisories & listing them so that users who fetch the pkg-vulnerabilities database are notified if they have any vulnerable packages installed. The general advisory process is a little infuriating, based on my recent experience I’d say at the top of my list are the Oracle security advisories as they do not divulge any details other than “unknown” in version(s) X, PHP for the frequency, OpenSSL for the impact. On the one hand I was quite impressed that CVE IDs were becoming so familiar that I could spot, on the fly, an advisory that had been accounted for, but on the other hand quite upset that I was using brain capacity on this. The availability of information is quite frustrating too, issues which are assigned an ID but cannot by checked on Mitre’s site take extra effort to find the necessary information to include (Mitre are responsible for allocating the CVEs!), I should note that this is from public advisories, say from a distribution. Example, CVE-2015-0240 was announced today, the Redhat security team published a blog post covering the issue, the Mitre site at present says:
“** RESERVED ** This candidate has been reserved by an organisation or individual that will use it when announcing a new security problem. When the candidate has been publicised, the details for this candidate will be provided.”
The wording & the lack of information can also be frustrating because it’s not clear what is affected. Looking at it positively, the requirement for clarification on these discrepancies means I get lots of opportunities to approach new people in different communities to ask questions.
I created a new wiki article on the NetBSD wiki to start documenting the bootstrap process of pkgsrc on Solarish, Illumos based distributions. At present the article covers what’s required to bootstrap successfully on OmniOS, Tribblix, OpenIndiana and OpenSXCE.
One thing that’s clearly evident is my workflow needs attention, at the moment things are very clumsy, involving lots of switching around but hopefully that will be addressed in the coming month. The first thing I’ve done is setup templates for emails with the correct preferences specified so that I just need to fill the necessary information & hit send, the necessary settings are automatically applied. Still thinking about how to deal with the scenario where the system that work is being carried out on is different to the system where the patch is going to be committed from, this also happens to be a different system which a developer is using. How to deal with that in as few steps from reading, say a bug report, to generating a patch, testing it & committing a fix.
For testing patches on Mac OS X, I revisited running OS X as guest on a Mac running OS X with virtualbox. Attempts in the past had not been successful & it seemed from search results that the only approach taken was to use modified OS images for hackintosh which I did not want to take. I have a genuine machine & genuine license, I shouldn’t have to resort to 3rd party images to run this. After whinging on twitter & referencing some older links I was able to successfully virtualise Mac OS X 10.7 to 10.10 in virtualbox. Will follow up with the details on that in a separate post.
The ATA command set has a command to instruct a device to secure erase itself.
Depending on the application & level of sensitivity of the data on disk, it can be a convenient way to decommission a disk or reset an SSD to regain performance. On FreeBSD this can be issued using camcontrol(8).
The command below performs an enhanced erase with a timeout of 60 seconds for the command to be accepted by the disk, this is needed if you get timeout errors when you do not specify it.
camcontrol security ada0 -U user -s Erase -h Erase -T 60
Things have moved forward in the world of bhyve since I last looked at it over a year ago, support for zvol backed guests where fixed long ago among other things such as the birth of vmrc by Michael Dexter.
To run a guest with a ZFS zvol as its disk is no different to running with a disk image, only thing is that my version of
/usr/share/examples/bhyve/vmrun.sh (11.0-CURRENT r267869 at the time of writing) fails to start from the disk once the OS has been installed.
A typical deployment scenario would be
Create a zvol of some size, e.g. 10GB
zfs create -V 10g zroot/guest0
Start a guest which’ll boot from the FreeBSD install CD iso & install onto the zvol
# sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 1024M -t tap0 -d /dev/zvol/zroot/guest0 -i -I FreeBSD-10.0-RELEASE-amd64-disc1.iso guest0
Use the “ZFS – Automatic Root-on-ZFS” option from the Partitioning menu
As instructed in the bhyve section of the handbook, before rebooting, drop to the shell & edit
/etc/ttys & replace the
console line with
console "/usr/libexec/getty std.9600" xterm on secure
Shutdown the operating system
Kill the guest
/usr/sbin/bhyvectl --destroy --vm=guest0
Create a new guest
bhyveload -m 4G -d /dev/zvol/zroot/guest0 guest0
Boot the new guest from the zvol
bhyve -c 1 -m 4G -A -H -P -s0:0,hostbridge -s 1:0,virtio-net,tap0 -s 2:0,ahci-hd,/dev/zvol/zroot/guest0 -s 31,lpc -l com1,stdio guest0
These instruction skip the creation of networking which is covered in the FreeBSD handbook as linked to above.
Copyright (c) 1992-2014 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (3399.54-MHz K8-class CPU)
Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping = 9
Standard Extended Features=0x200
TSC: P-state invariant
real memory = 5368709120 (5120 MB)
avail memory = 4103143424 (3913 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table:
ioapic0 irqs 0-23 on motherboard
module_register_init: MOD_LOAD (vesa, 0xffffffff80cfa5e0, 0) error 19
kbd1 at kbdmux0
acpi0: on motherboard
acpi0: Power Button (fixed)
atrtc0: port 0x70-0x71 irq 8 on acpi0
Event timer "HPET" frequency 10000000 Hz quality 550
Event timer "HPET1" frequency 10000000 Hz quality 450
Event timer "HPET2" frequency 10000000 Hz quality 450
Event timer "HPET3" frequency 10000000 Hz quality 450
Event timer "HPET4" frequency 10000000 Hz quality 450
Event timer "HPET5" frequency 10000000 Hz quality 450
Event timer "HPET6" frequency 10000000 Hz quality 450
Event timer "HPET7" frequency 10000000 Hz quality 450
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: port 0x408-0x40b on acpi0
pcib0: port 0xcf8-0xcff on acpi0
pci0: on pcib0
virtio_pci0: port 0x2000-0x201f mem 0xc0000000-0xc0001fff irq 16 at device 1.0 on pci0
vtnet0: on virtio_pci0
virtio_pci0: host features: 0x1018020
virtio_pci0: negotiated features: 0x18020
vtnet0: Ethernet address: 00:a0:98:7f:5a:41
virtio_pci1: port 0x2040-0x207f mem 0xc0002000-0xc0003fff irq 17 at device 2.0 on pci0
vtblk0: on virtio_pci1
virtio_pci1: host features: 0x10000044
virtio_pci1: negotiated features: 0x10000044
vtblk0: 40960MB (83886080 512 byte sectors)
isab0: at device 31.0 on pci0
isa0: on isab0
uart0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (9600,n,8,1)
uart1: port 0x2f8-0x2ff irq 3 on acpi0
sc0: at flags 0x100 on isa0
vga0: at port 0x3b0-0x3bb iomem 0xb0000-0xb7fff on isa0
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: irq 1 on atkbdc0
kbd0 at atkbd0
ppc0: cannot reserve I/O port range
ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present;
to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf.
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
Timecounters tick every 10.000 msec
random: unblocking device.
Netvsc initializing... Timecounter "TSC-low" frequency 1699769676 Hz quality 1000
Trying to mount root from zfs:zroot/ROOT/default ...
After 5 years of going back & forth, I’ve decided to give up on trying to complete the OpenNMS ports for FreeBSD and dropped maintainership of the Java dependencies in the ports tree (net/jicmp, net/jicmp6, databases/jrrd, databases/iplike)
There are some issues which are show stoppers that need addressing upstream
- Separation of configuration & user data from the location of application binaries, Initially I began patching the source to look for files in a different location to the default so that things would integrate with the user land correctly but it soon became apparent that the patching would be a nightmare to maintain on an ongoing basis due to the number of patches required per configuration file. It was clear that things would need to be dealt with at the source rather than patched post release, a long running discussion with developers, bug reports raised, some (minor) patches submitted, 4+ years on, still ignored due to a lack of interest.
- Dynamically generated filenames, inherited from Google Web Toolkit, every build attempt generates new filename which make packing impossible.
Update OpenNMS developer Benjamin Reed points to a possible fix
- Unreliable build process, maven fails between 2 to 3 times minimum which would cause lots of false alarms in an automated build environment e.g. the freebsd build cluster.
This is somewhat of an improvement from a few years back where it would not be possible to build because repositories were not available for a day or two.
As it stands, the port is a shell which make it easy to install OpenNMS on FreeBSD but has major issues when it comes to upgrades or uninstallation. It’s best install dependencies from ports & install OpenNMS manually.
I’d installed FreeBSD on my ThinkPad X61s when the head branch of the source tree was at 9-CURRENT, multi-booting it with Windows 7 & OpenBSD.
At the time I was not aware that it was possible to boot FreeBSD from a root file system on a ZFS volume from a disk partitioned using a MBR scheme. Instead, I opted to store /boot on a UFS filesystem.
This install existed for a couple of years, the ThinkPad got a roasting every once in a while to build a new release to install for updates. At some point support for 4K sectors in ZFS was improved,
zpool status began to report degraded performance as the disk had been using 512byte sectors where in fact it could support 4K sized sectors.
Eventually, I deleted the existing slices in the FreeBSD partition & attempted to reinstall but found this time the system would not boot.
Booting from the install CD & issuing
zpool import reported the new pool & old pool from the previous install.
Destroying a pool before deleting slices stopped this problem from re-occurring but the system still wouldn’t boot from a ZFS volume on a MBR partition.
The next step was to see if things would work if the whole disk was dedicated to FreeBSD, with a GPT partition scheme, things worked but switching to MBR, again, it failed to boot, hanging at a flashing cursor.
Over the next four months, many installs were attempted. On a MBR partitioned disk
FreeBSD failed to boot but PCBSD could by using GRUB.
I stopped trying any further at this point & took a break from it, one thing that had been raised at BSDCan was the possibility it could be lingering metadata, I’d thought as zpool(8) wasn’t reporting any existing pools when asked to
import that this wasn’t the case. To give the benefit of a doubt, I ran
dd on the disk with no difference in result.
This approach to clearing old pools seemed a little rough so over the weekend I looked into what other options are available.
The zpool(8) man page documents the
labelclear option as
zpool labelclear [-f] device
Removes ZFS label information from the specified device. The device
must not be part of an active pool configuration.
-v Treat exported or foreign devices as inactive.
I still had the FreeBSD snapshot from the last attempt which I booted the X61s with, headed to the shell, deleted the existing partitions & issued
zpool labelclear -f /dev/ada0
Everything worked as intended after that.
Thanks to Allan Jude & everyone who chipped in at BSDCan.
Through the trial of getting this working Allan added the option to use a BSD partition scheme to the FreeBSD installer as well as MBR & GPT, which was previously unavailable.
I’ve been working on getting CoovaChilli running on FreeBSD 10 the past few weeks. The first problem was that the source code would not build. FreeBSD 10 shipped with clang instead of GCC as the default compiler which is not as forgiving as GCC, clang flagged up lots of issues with the code base such as lack of parameters for functions, one change needed which was a shortcoming of clang itself was the lack of support for nested functions.
The other problem was that CoovaChilli was using a structure that had been marked as deprecated in Net/Free/OpenBSD/Darwin for quite some time & with the release of 10.0, FreeBSD removed this structure from their codebase. This resulted in the
tun(4) interface being initialised but no IP address being assigned to it, which was interesting, dhcp responses were still going out but obviously nothing could talk back to the IP address that coova was configured to be listening on (
All BSDs & derivatives were separated out from Linux in
dev_set_address(), Linux was set to use the pre-existing method & the BSD & derivatives were switch to use the “new”
With these change, it’s possible for a client connected to a router running CoovaChilli to visit sites listed in
uamallowed. These are sites which CoovaChilli allows to be browsed without needing authentication through the captive portal first. Next stage is to get the captive portal running along with a RADIUS server so that the previous revision of the setup guide can be updated. With the release of FreeRADIUS 3 configuration has changed somewhat, hence the old documentation for version 2 doesn’t necessarily apply.
These changes so far only allow the code to build without any features enabled, for example, enabling OpenSSL support yielded more errors which have not been fixed yet & I suspect others will show up as more options are switched on.
The work so far can be found here
Just short of four years ago I posted an article on setting up jails using the pre-built sets FreeBSD comes with.
The changes are now part of the Jails section of the FreeBSD Handbook as PR docs/189901 was closed today. The changes were generated at the doc sprints which happened at BSD Can 2014.
Since getting a MacBook Air with a Japanese keyboard, I have grown accustomed to having the control key in place of the caps lock, so much so that now it’s annoying not having it there if I switch to another system. Searching around to see what I’d find on the subject, it seems that a similar frustration exists for users who are used to the left control key being in the bottom left hand side instead of the new Fn key & infact I have a bios image which makes this change for my X61s.
From the brief search for a bios image brought up lots of links to the image which I already have for swapping fn with ctrl & I didn’t fancy an introduction to ThinkPad BIOS hacking with IDA so I began to look for OS specific solutions.
On FreeBSD, a variant of the UK (
uk.iso-ctrl.kdb) & US standard layouts (
us.pc-ctrl.kbd) exist which swap the location of the two keys round & I found this guide (in Japenese) which discusses what changes are needed to a layout file (reassigning scan codes 29 & 58) but all this was already taken care of some 12 years ago. The header of
“There are some minor variations, but this seems like the most common layout. I personally use one with three more pairs swapped:
clock lctrl, and
=+ \| (supplied as “
I just needed to declare
/etc/rc.conf & restart
With the videos released last month from euroBSDcon 2012, I watched Michael Dexter’s talk on bhyve, the BSD hypervisor has come along way since I last tried it over a year ago & Michael has helped a with it’s progress by writing articles on CFT & scripts for running bhyve.
Last week I decided to get myself a server which I could use to do builds quickly & to run virtual machines for testing. Hetzner do high spec consumer hardware as servers, €59 per month get you a i7 with 32GB of RAM & 2x 3TB HDD, I ordered the server along with a 16GB USB flash drive with the plan of running SmartOS, once my login details for the server came through, I raised a support ticket for access to a IP KVM, within the hour I was given access & the installation went seamlessly. SmartOS was running on my server & it all went down hill from there.
As there is a IPv4 address shortage, hetzner charge a premium for additional addresses as a routed subnet, along with an additional fee for having the ability to request additional addressses as a “flexi pack”, a /27 would cost €47, I was not going to pay this so decided to go IPv6 only as I have connectivity at home & work. Unfortunately, though IPv6 support is there in the core of SmartOS by interitence from OpenSolaris, the additions from Joyent for KVM don’t, main culprit being vmadm(1m), after losing two days trying to get things working I came to the conclusion that A) it would be a big pain to maintain going forward as the burden would be on me to work around the shortfalls of the system B) I didn’t want to maintain my own release with third party patches which were not in yet C) I didn’t like the way I would have to extend the system to add functionality eg to set the hostname for your system persistently you have to use a script D) getting IPv6 support to guests was painful.
The majority of the work I’m doing is oriented around FreeBSD, it takes over 4 hours to do a build world & kernel on my ThinkPad X61s with a 1.6GHz Core2Duo so anything that can prolong it’s life & give me new builds quickly is good. I placed another support request for IP KVM (LARA in the world of hetzner) & once I had the login details I netbooted the server to their FreeBSD rescue environment which is a FreeBSD 8.3 based copy of mfsBSD. From there I fetched the latest FreeBSD-CURRENT usb image & wrote it to the flash drive using
dd(1) & went about setting up a mirrored zpool to install FreeBSD onto.
Once the installation was complete & the system was up & running I revisited Michael’s talk, slides & scripts.
His scripts are numbered sequentially so you can easily go from creating a disk image to running & managing your virtual machines. This article covers a summary of what is involved to get a guest VM ready with FreeBSD-CURRENT built from source which are taken from his scripts & slides. As development has progressed since the talk, some things which are performed are no longer required. Essentially, you can boot a stock system from a disk image with only 2 necessary modifications to stock configuration files for dealing with the console.
There is also a
vmrun.sh script which simplifies the whole process to try out (see instructions)
First build world & kernel (not necessary, you can use the precompiled binary instead if you choose)
On the host add the following to
Create a file which will be used as your disk, eg a 80GB one
truncate -s 80G disk.img
md(4) disk with the file you just created
Initialise the disk to use the entire disk as a freebsd slice
fdisk -BI md0
You’ll receive the following error which can be safely ignored
******* Working on device /dev/md0 *******
fdisk: invalid fdisk partition table found
Write a standard label & boot code to slice 1
bsdlabel -wB /dev/md0s1
Write a filesystem to slice 1a
newfs -U /dev/md0s1a
Mount it to /mnt
mount /dev/md0s1a /mnt
/usr/src, install world, kernel & distribution (contents of
/etc) onto the disk image
make installworld DESTDIR=/mnt
make installkernel DESTDIR=/mnt
make distribution DESTDIR=/mnt
fstab to mount root from
echo "/dev/vtbd0s1a / ufs rw 1 1" > /mnt/etc/fstab
Configure your console
echo 'console "/usr/libexec/getty std.9600" vt100 on secure' > /mnt/etc/ttys
echo 'console="userboot"' > /mnt/boot/loader.conf
Aside from configuring
/etc/rc.conf the instructions above cover the bare minimum to get a booting VM.
2-install-guest.sh I’ve skipped loading the virtio drivers in
/boot/loader.conf as they’re loaded by default in FreeBSD-CURRENT & the following though I’ve not given it more testing
Helps Kernel detected it’s running in a virtualised environment
Avoid clock drift
PCI pass-through support as it caused hangs
Unmount the file system
Detach the file from
mdconfig -d -u 0
Assuming you’re using
You can get a list of configured devices with
As covered in
3-host-prep.sh you can load the required kernel modules for bhyve & guest networking by running
kldload vmm or rebooting 🙂
Before starting your VM, you need to create the needed interfaces, a
tap(4) interfaces with a
bridge(4) linked to the interface you want the VM to be able to communicate on, in my case a
ifconfig tap0 create up
ifconfig bridge0 create up
ifconfig bridge0 addm tap0 addm re0 up
Because of STP, once you have started the virtual machine, you should pause at the boot menu by pressing space & waiting 20 seconds until STP has stabilised otherwise you may find strange issues with you guest not being able to communicate properly.
If you restart a VM, it is also important to destroy the tap & bridge interfaces before starting up again or you will again experience odd behaviour e.g I was seeing traffic come in to the VM but not going out.
ifconfig tap0 destroy
To start a VM with less than 4GB RAM issue
sudo bhyveload -d /path/to/disk.img -m 256 vmname && sudo bhyve -c 1 -a -A -m 256 -I -H -g 0 -s 0:0,hostbridge -s 2:0,virtio-blk,/path/to/disk.img -s 1:0,virtio-net,tap0 -S 31,uart,stdio vmname
This will start a VM called vmname which uses 256MB RAM.
To start a VM which uses 4GB or more you’ll have to specify memory settings differently as you need to lead space for PCI MMIO decode below 4GB, so for example, if you wanted to use 8GB RAM, you’d issue
sudo bhyveload -d /path/to/disk.img -m 2048 -M 6144 vmname && sudo bhyve -c 1 -a -A -m 2048 -M 6144 -I -H -g 0 -s 0:0,hostbridge -s 2:0,virtio-blk,/path/to/disk.img -s 1:0,virtio-net,tap0 -S 31,uart,stdio vmname
To shutdown a VM issue
bhyvectl --vm=vmname --destroy
My next step is to now see how to use a ZFS filesystem instead of a file based disk for the VM.
Last week I attended a conference on open source software called FOSDEM in Brussels, the two day event has lots of tracks, based on either specific projects or topics such as Java or securiy.
I attended the following talks
The Open Observatory of Network Interference
Practical Security for developers, using OWASP ZAP
The future of X.org on non-Linux systems
Declarative style GUI programming
How to build an Identity Management System on Linux
My favourite talk of the event was the OWASP talk on Saturday by Simon Bennetts who did a great job of clearly explaining what ZAP can do & how it is of use for testing the security of your web application.
The XMPP 101 talk gave an overview of what the protocol can do, the OONI talk had a very late start & laptop issues, didn’t get much from the talk but it does seem like an interesting project from the info on the website. Matthieu Herrb talked about the progress of running X.org on UNIX, conclusion “Tough times for non-linux systems”. Marc Balmer gave two talks on using Lua, first in GUI programming & the second on the lua(4) subsystem in the NetBSD kernel, allowing users to explore the system easily & doing rapid prototype without the initial steep learning curve of learning C & kernel internal, making the system internals easily accessible. The last talk on the Security track was on FreeIPA, luckily the slides were quiet detailed as it was impossible to hear the speaker because the mic was hanging too low off his shirt collar.
The BSD track on Sunday was where I spent most of the day. David Chisnall spoke about the C & C++ standards & the mistakes made by the standards groups which we have to live with. I spent the lunch break talking with David about FreeBSD, how I struggle with doing buildworld on my X61s, what can be done to speed up buildworld, why the buildworld process takes so long & the tools Juniper has developed which allow you to track the dependency path for building each component in FreeBSD base.
Mike Belopuhov spoke about the IPsec stack & NAT64 support in OpenBSD, I had an opportunity to ask Mike about dead peer detection, in my previous site to site VPN deployment I had issues where if the connection dropped at either site, the tunnel with not be re-established, needing manual intervention, It was good to hear that this was a problem with the isakmpd & not necessarily a configuration issue.
There were a lots of projects & businesses with stands, Oreilly had a stand selling books, Google were in the recruitment section, Oracle with three big banners for java, mysql & something else, the lady on the stand was very friendly, telling me about how Oracle participates in open source software such as Java, the penny then dropped about the update 13 release.
It was good to see CAcert had a stand and were looking very busy with assurances. I visited the mozilla stand & had the opportunity to try out the firefoxOS on a nexus s?
I’m strongly considering moving to it as I’d rather go with firefoxOS than android, the lock down of iOS is very painful for sharing data between my own devices & makes it frustrating for getting content from several devices to a single place.
I visited the google stand to talk to the recruiters there, I was curious to learn about their recruitment process, since 2007 I have been approached by Google on 3 different occasion, the most recent being back in July last year. I always assumed they had drives every so many years & I’d just been lucky to have been listed on three separate occasions, it turns out actually that once you’re on their radar, they will make contact every once in a while to see if your situation has changed & if have developed sufficiently since last time to be able to pass the interview tests.
I spoke with others regarding this, with those now employed by them & those who have also been approached in the past, discussing why systems folks are sought after & what options you have should you wish to no longer be contacted (supposedly under Californian law, if a person requests a company to never be contacted again, the company has to comply?).
Over the weekend I spotted a few OpenBSD tops (more hoodies than t-shirts) & met my first MirBSD user/developer, Benny Siegert who was the organiser of the BSD track at FOSDEM.
I also had the opportunity to meet up with/bump into folks from communities such as MetaBUG, OSHUG, LOSUG, Brighton 2600, London *BSD, it was good to catch up.