DNS improvements in FreeBSD 11

Erwin Lansing just posted a summary of the DNS session at the FreeBSD DevSummit that was held in conjunction with BSDCan 2014 in May. It gives a good overview of the current state of affairs, including known bugs and plans for the future.

I’ve been working on some of these issues recently (in between $dayjob and other projects). I fixed two issues in the last 48 hours, and am working on two more.

Reverse lookups in private networks

Fixed in 11.

In its default configuration, Unbound 1.4.22 does not allow reverse lookups for private addresses (RFC 1918 and the like). NLNet backported a patch from the development version of Unbound which adds a configuration option, unblock-lan-zones, which disables this filtering. But that alone is not enough, because the reverse zones are actually signed (EDIT: the problem is more subtle than that, details in comments); Unbound will attempt to validate the reply, and will reject it because the zone is supposed to be empty. Thus, for reverse lookups to work, the reverse zones for all private address ranges must be declared as insecure:

server:
    # Unblock reverse lookups for LAN addresses
    unblock-lan-zones: yes
    domain-insecure:      10.in-addr.arpa.
    domain-insecure:     127.in-addr.arpa.
    domain-insecure: 254.169.in-addr.arpa.
    domain-insecure:  16.172.in-addr.arpa.
    # ...
    domain-insecure:  31.172.in-addr.arpa.
    domain-insecure: 168.192.in-addr.arpa.
    domain-insecure: 8.e.ip6.arpa.
    domain-insecure: 9.e.ip6.arpa.
    domain-insecure: a.e.ip6.arpa.
    domain-insecure: b.e.ip6.arpa.
    domain-insecure: d.f.ip6.arpa.

FreeBSD 11 now has both the unblock-lan-zones patch and an updated local-unbound-setup script which sets up the reverse zones. To take advantage of this, simply run the following command to regenerate your configuration:

# service local_unbound setup

This feature will be available in FreeBSD 10.1.

Building libunbound writes to /usr/src (#190739)

Fixed in 11.

The configuration lexer and parser were included in the source tree instead of being generated at build time. Under certain circumstances, make(1) would decide that they needed to be regenerated. At best, this inserted spurious changes into the source tree; at worst, it broke the build.

Part of the reason for this is that Unbound uses preprocessor macros to place the code generated by lex(1) and yacc(1) in its own separate namespace. FreeBSD’s lex(1) is actually Flex, which has a command-line option to achieve the same effect in a much simpler manner, but to take advantage of this, the lexer needed to be cleaned up a bit.

Allow local domain control sockets

Work in progress

An Unbound server can be controlled by sending commands (such as “reload your configuration file”, “flush your cache”, “give me usage statistics”) over a control socket. Currently, this can only be a TCP socket. Ilya Bakulin has developed a patch, which I am currently testing, that allows Unbound to use a local domain (aka “unix”) socket instead.

Allow unauthenticated control sockets

Work in progress

If the control socket is a local domain socket instead of a TCP socket, there is no need for encryption and little need for authentication. In the local resolver case, only root on the local machine needs access, and this can be enforced by the ownership and file permissions of the socket. A second patch by Ilya Bakulin makes encryption and authentication optional so there is no need to generate and store a client certificate in order to use unbound-control(8).

Cross building ports with qemu-user and poudriere-devel on #FreeBSD

I’ve spent the last few months banging though the bits and pieces of the work that Stacey Son implemented for QEMU to allow us to more or less chroot into a foreign architecture as though it were a normal chroot.  This has opened up a lot of opportunities to bootstrap the non-x86 architectures on FreeBSD.

Before I get started, I’d like to thank Stacey Son, Ed Maste, Juergen Lock, Peter Wemm, Justin Hibbits, Alexander Kabaev, Baptiste Daroussin and Bryan Drewery for the group effort in getting us the point of working ARMv6, MIPS32 and MIPS64 builds.  This has been a group effort for sure.

This will require a 10stable or 11current machine, as this uses Stacey’s binary activator patch to redirect execution of binaries through QEMU depending on the ELF header of the file.  See binmiscctl(8) for more details.

Mechanically, this is a pretty easy setup.  You’ll need to install ports-mgmt/poudriere-devel with the qemu-user option selected.  This will pull in the qemu-user code to emulate the environment we need to get things going.

I’ll pretend that you want an ARMv6 environment here.  This is suitable to build packages for the Rasberry PI and Beagle Bone Black.  Run this as root:

binmiscctl add armv6 –interpreter “/usr/local/bin/qemu-arm” –magic
“x7fx45x4cx46x01x01x01x00x00x00x00x00x00x00x00x00x02
x00x28x00″ –mask “xffxffxffxffxffxffxffx00xffxffxffxff
xffxffxffxffxfexffxffxff” –size 20 –set-enabled

This magic will load the imgact_binmisc.ko kernel module.  The rest of the command line instructs the kernel to redirect execution though /usr/local/bin/qemu-arm if the ELF header of the file matches an ARMv6 signature.

Build your poudriere jail (remember to install poudriere-devel for now as it has not been moved to stable at the time of this writing) with the following command:

poudriere jail -c -j 11armv632 -m svn -a armv6 -v head

Once this is done, you will be able to start a package build via poudriere bulk as you normally would:

poudriere bulk -j 11armv632 -a

or

poudriere bulk -j 11armv632 -f <my_file_of_ports_to_build>

Currently, we are running the first builds in the FreeBSD project to determine what needs the most attention first.  Hopefully, soon we’ll have something that looks like a coherent package set for non-x86 architectures.

For more information, work in progress things and possible bugs in qemu-user code, see Stacey’s list of things at:

https://wiki.freebsd.org/QemuUserModeHowTo

https://wiki.freebsd.org/QemuUserModeToDo

BSDCan 2014 – Ports and Packages WG

Baptiste Daroussin started the session with a status update on package building. All packages are now built with poudriere. The FreeBSD Foundation sponsored some large machines on which it takes around 16 hours to build a full tree. Each Wednesday at 01:00UTC the tree is snapshot and an incremental build is started for all supported released, the 2 stable branches (9 and 10) and quarterly branches for 9.x-RELEASE and 10.x-RELEASE. The catalogue is signed on a dedicated signing machine before upload. Packages can be downloaded from 4 mirrors (us-west, us-east, UK, and Russia) and feedback so far has been very positive.

He went on to note that ports people need better coordination with src people on ABI breakage. We currently only support i386 and amd64, with future plans for ARM and a MIPS variant. Distfiles are not currently mirrored (since fixed), and while it has seen no progress, it’s still a good idea to build a pkg of the ports tree itself.

pkg 1.3 will include a new solver, which will help 'pkg upgrade' understand that an old packages needs to be replaced with a newer one, with no more need for 'pkg set' and other chicanery. Cross building ports has been added to the ports tree, but is waiting for pkg-1.3. All the dangerous operations in pkg have now been sandboxed as well.

EOL for pkg_tools has been set for September 1st. An errata notice has gone out that adds a default pkg.conf and keys to all supported branches, and nagging delays have been added to ports.

Quarterly branches based on 3 month support cycle has been started on an evaluation basis. We’re still unsure about the manpower needed to maintain those. Every quarter a snapshot of the tree is created and only security fixed, build and runtime fixed, and upgrades to pkg are allowed to be committed to it. Using the MFH tag in a commit message will automatically send an approval request to portmgr and an mfh script on Tools/ makes it easy to do the merge.

Experience so far has been good, some minor issues to the insufficient testing. MFHs should only contain the above mentioned fixes; cleanups and other improvements should be done in separate commits only to HEAD. A policy needs to be written and announced about this. Do we want to automatically merge VuXML commits, or just remove VuXML from the branch and only use the one in HEAD?

A large number of new infrastructure changes have been introduces over the past few months, some of which require a huge migration of all ports. To speed these changes up, a new policy was set to allow some specific fixes to be committed without maintainer approval. Experience so far has been good, things actually are being fixed faster than before and not many maintainers have complained. There was agreement that the list of fixes allowed to be committed without explicit approval should be a specific whitelist published by portmgr, and not made too broad in scope.

Erwin Lansing quickly measured the temperature of the room on changing the default protocol for fetching distils from MASTER_SITE_BACKUP from ftp to http. Agreement all around and erwin committed the change.

Ben Kaduk gave an introduction and update on MIT’s Athena Environment with some food for thought. While currently not FreeBSD based, he would like to see it become so. Based on debian/ubuntu and rolled out on hundreds of machines, it now has it’s software split into about 150 different packages and metapackages.

Dag-Erling Smørgrav discussed changes to how dependencies are handled, especially splitting dependencies that are needed at install time (or staging time) and those needed at run time. This may break several things, but pkg-1.3 will come with better dependency tracking solving part of the problem.

Ed Maste presented the idea of “package transparency”, loosely based on Google’s Certificate Transparency. By logging certificate issuance to a log server, which can be publicly checked, domain owners can search for certificates issued for their domains, and notice when a certificate is issued without their authority. Can this model be extended to packages? Mostly useful for individually signed packages, while we currently only sign the catalogue. Can we do this with the current infrastructure?

Stacy Son gave an update on Qemu user mode, which is now working with Qemu 2.0.0. Both static and dynamic binaries are supported, though only a handful of system call are supported.

Baptiste introduced the idea of having pre-/post-install scripts be a library of services, like Casper, for common actions. This reduces the ability of maintainers to perform arbitrary actions and can be sandboxed easily. This would be a huge security improvement and could also enhance performance.

Cross building is coming along quite well and most of the tree should be able to be build by a simple 'make package'. Major blockers include perl and python.

Bryan Drewery talked about a design for a PortsCI system. The idea is that committer easily can schedule a build, be it an exp-run, reference, QAT, or other, either via a web interface or something similar to a pull request, which can fire off a build.

Steve Wills talked about using Jenkins for ports. The current system polls SVN for commits and batches several changes together for a build. It uses 8 bhyve VMs instances, but is slow. Sean Bruno commented that there are several package building clusters right now, can they be unified? Also how much hardware would be needed to speed up Jenkins? We could duse Jenkins as a fronted for the system Bryan just talked about. Also, it should be able to integrate with phabricator.

Erwin opened up the floor to talk about freebsd-version(1) once more. It was introduced as a mechanism to find out the version of user land currently running as uname -r only represents the kernel version, and would thus miss updates of the base system that do no touch the kernel. Unfortunately, freebsd-version(1) cannot really be used like this in all cases, it may work for freebsd-update, but not in general. No real solution was found this time either.

The session ended with a discussion about packaging the base system. It’s a target for FreeBSD 11, but lots of questions are still to be answered. What granularity to use? What should be packages into how many packages? How to handle options? Where do we put the metadata for this? How do upgrades work? How to replace shared libraries in multiuser mode? This part also included the quote of the day: “Our buildsystem is not a paragon of configurability, but a bunch of hacks that annoyed people the most.”

Thanks to all who participated in the working group, and thanks again to DK Hostmaster for sponsoring my trip to BSDCan this year, and see you at the Ports and Packages WG meet up at EuroBSDCon in Sofia in September.

FreeBSD Developer Summit – BSDCan 2014 – Ports and Packages WG

Baptiste Daroussin started the session with a status update on package building. All packages are now built with poudriere. The FreeBSD Foundation sponsored some large machines on which it takes around 16 hours to build a full tree. Each Wednesday at 01:00UTC the tree is snapshot and an incremental build is started for all supported released, the 2 stable branches (9 and 10) and quarterly branches for 9.x-RELEASE and 10.x-RELEASE. The catalogue is signed on a dedicated signing machine before upload. Packages can be downloaded from 4 mirrors (us-west, us-east, UK, and Russia) and feedback so far has been very positive.

He went on to note that ports people need better coordination with src people on ABI breakage. We currently only support i386 and amd64, with future plans for ARM and a MIPS variant. Distfiles are not currently mirrored (since fixed), and while it has seen no progress, it’s still a good idea to build a pkg of the ports tree itself.

pkg 1.3 will include a new solver, which will help 'pkg upgrade' understand that an old packages needs to be replaced with a newer one, with no more need for 'pkg set' and other chicanery. Cross building ports has been added to the ports tree, but is waiting for pkg-1.3. All the dangerous operations in pkg have now been sandboxed as well.

EOL for pkg_tools has been set for September 1st. An errata notice has gone out that adds a default pkg.conf and keys to all supported branches, and nagging delays have been added to ports.

Quarterly branches based on 3 month support cycle has been started on an evaluation basis. We’re still unsure about the manpower needed to maintain those. Every quarter a snapshot of the tree is created and only security fixed, build and runtime fixed, and upgrades to pkg are allowed to be committed to it. Using the MFH tag in a commit message will automatically send an approval request to portmgr and an mfh script on Tools/ makes it easy to do the merge.

Experience so far has been good, some minor issues to the insufficient testing. MFHs should only contain the above mentioned fixes; cleanups and other improvements should be done in separate commits only to HEAD. A policy needs to be written and announced about this. Do we want to automatically merge VuXML commits, or just remove VuXML from the branch and only use the one in HEAD?

A large number of new infrastructure changes have been introduces over the past few months, some of which require a huge migration of all ports. To speed these changes up, a new policy was set to allow some specific fixes to be committed without maintainer approval. Experience so far has been good, things actually are being fixed faster than before and not many maintainers have complained. There was agreement that the list of fixes allowed to be committed without explicit approval should be a specific whitelist published by portmgr, and not made too broad in scope.

Erwin Lansing quickly measured the temperature of the room on changing the default protocol for fetching distils from MASTER_SITE_BACKUP from ftp to http. Agreement all around and erwin committed the change.

Ben Kaduk gave an introduction and update on MIT’s Athena Environment with some food for thought. While currently not FreeBSD based, he would like to see it become so. Based on debian/ubuntu and rolled out on hundreds of machines, it now has it’s software split into about 150 different packages and metapackages.

Dag-Erling Smørgrav discussed changes to how dependencies are handled, especially splitting dependencies that are needed at install time (or staging time) and those needed at run time. This may break several things, but pkg-1.3 will come with better dependency tracking solving part of the problem.

Ed Maste presented the idea of “package transparency”, loosely based on Google’s Certificate Transparency. By logging certificate issuance to a log server, which can be publicly checked, domain owners can search for certificates issued for their domains, and notice when a certificate is issued without their authority. Can this model be extended to packages? Mostly useful for individually signed packages, while we currently only sign the catalogue. Can we do this with the current infrastructure?

Stacy Son gave an update on Qemu user mode, which is now working with Qemu 2.0.0. Both static and dynamic binaries are supported, though only a handful of system call are supported.

Baptiste introduced the idea of having pre-/post-install scripts be a library of services, like Casper, for common actions. This reduces the ability of maintainers to perform arbitrary actions and can be sandboxed easily. This would be a huge security improvement and could also enhance performance.

Cross building is coming along quite well and most of the tree should be able to be build by a simple 'make package'. Major blockers include perl and python.

Bryan Drewery talked about a design for a PortsCI system. The idea is that committer easily can schedule a build, be it an exp-run, reference, QAT, or other, either via a web interface or something similar to a pull request, which can fire off a build.

Steve Wills talked about using Jenkins for ports. The current system polls SVN for commits and batches several changes together for a build. It uses 8 bhyve VMs instances, but is slow. Sean Bruno commented that there are several package building clusters right now, can they be unified? Also how much hardware would be needed to speed up Jenkins? We could duse Jenkins as a fronted for the system Bryan just talked about. Also, it should be able to integrate with phabricator.

Erwin opened up the floor to talk about freebsd-version(1) once more. It was introduced as a mechanism to find out the version of user land currently running as uname -r only represents the kernel version, and would thus miss updates of the base system that do no touch the kernel. Unfortunately, freebsd-version(1) cannot really be used like this in all cases, it may work for freebsd-update, but not in general. No real solution was found this time either.

The session ended with a discussion about packaging the base system. It’s a target for FreeBSD 11, but lots of questions are still to be answered. What granularity to use? What should be packages into how many packages? How to handle options? Where do we put the metadata for this? How do upgrades work? How to replace shared libraries in multiuser mode? This part also included the quote of the day: “Our buildsystem is not a paragon of configurability, but a bunch of hacks that annoyed people the most.”

Thanks to all who participated in the working group, and thanks again to DK Hostmaster for sponsoring my trip to BSDCan this year, and see you at the Ports and Packages WG meet up at EuroBSDCon in Sofia in September.

FreeBSD Developer Summit – BSDCan 2014 – DNS WG

The DNS Working Group at the FreeBSD Developer Summit at BSDCan this year was off to a good start by noticing that DNSSEC validation could not work on the University of Ottawa’s wireless network. The university’s resolvers added additional records to the root zone, thus failing validation at the root. This led to some discussion on how to provide a user-friendly way to explain this in an understandable way to the user and giver the user a choice of turning off validation or find another network. This certainly is going to be a major problem when turning on validation by default as broken resolvers are very common at hotels, coffee shops, etc. etc.

On a more positive note, all the FreeBSD projects zones are DNSSEC signed and all project-owned servers have SSHFP records in the zone. Dog food was eaten.

Dag-Erling Smørgrav started off by giving an overview of the current state of affairs. ldns and unbound are imported into base in HEAD and 10.x. unbound is meant to act as a local resolver only and as it is not linked to libevent, it will not scale to anything else. For a network-wide resolver or any other configuration, it is recommended to install unbound from ports. DES further went into some of the implementation details on how the base unbound is installed to make sure it does not conflict with an unbound installed from ports.

DES explained some issues he encountered with local and RFC1918 zones which are filtered by default by unbound. Others reported no issues with the right configuration options, so more investigation is needed.

Some people reported having difficulty getting patches accepted upstream by NLNetLabs, which gave some cause for concern as we clearly want a good and active working relationship with our DNS vendor. Others reported no problem working with NLNetLabs, quite the opposite, they are very interested to see the work going on in operation systems, so we’ll just need to build upon that relationship and make sure to invite them to the next WG meeting. Patches that are currently being worked on, DES has some code cleanups, Björn a DNS64 feature, should be submitted through the “normal” submission process and review with NLNetLabs and we’ll see how that goes.

Erwin Lansing started the brainstorm session on future work. Some command line tools would be nice to have; drill does most things one wants, but people are too used to writing dig and dig has many more options; Peter Wemm would like to see contrib scripts line ldns-dane, which are just really easy to use; the control socket should be a unix socket, there’s a patch floating around and should be submitted upstream.

The “Starbucks” problem came up again, with a proposal to turn on val-permissive-mode by default. Another solution may be by looking at how unbound-trigger does its magic.

After a coffee break, Peter Losher, ISC, went over some of the recent changes at ISC. BIND10 development has been handed over to a new project and ISC will concentrate on BIND9 and a stand-alone project for the DHCP component. BIND 9.10 was recently released and plans are in place for 9.11. ISC is open to suggestions and feature requests.

Peter brought up the topic of clientID for which a IETF draft (draft-edns0-client-subnet) is available. This would help client find the nearest CDN node, etc. ISC wants this to be an opt-out in operating systems as it will peel off a layer of anonymisation, and should be controllable by the user.

Next up was Michael Bentkofsky, Verisign, who, while not involved in the project himself, gave an introduction into the getDNS API, which is a replacement for getaddrinfo and allows the stub resolver to get validation information down at the client level. It’s available in ports. The discussion went into more of a brainstorm on how applications should get DNS and DNSSEC information and who gets to make decisions about its security. There should be a clear separation between policy and mechanism, where application programmers should not have to worry about this; it should be a system policy. There should be a higher level API where an application basically can ask the operating system for a “connection” and the operation system takes care of everything behind the scenes, DNS, DNSSEC, SSL, DANE, etc. and just return a socket, with some information on how the connection was established and which security mechanisms were used. In FreeBSD, it would make sense to let the Casper daemon hand out the different sub-tasks to ensure all lookups, cryptography, etc. are properly compartmentalised. One potential problem with passing on additional information is that all DNS lookups currently go through nsswitch, which would need to grow knowledge about that data as well. Are people still using other mechanisms for hostname lookups besides the hosts file and DNS? We can probably just remove nsswitch for the hostname lookups.

The session ended with some aims for the 11.0 release. We’ll need to have a wider discussion about the aforementioned removal of nsswitch out of the hostname lookups. We’ll also need a better understanding of what API capabilities applications may need. Can Casper provide all these? Can it run unbound behind the scenes to do all the DNS “stuff” for it? Can we capsicumize unbound and will that be accepted upstream? Enough food for thought and even more for writing code.

Thanks again to DK Hostmaster for sponsoring my trip to BSDCan this year, and see you at the DNS WG meet up at EuroBSDCon in Sofia in September.

FreeBSD 9.3-RELEASE Available

FreeBSD 9.3-RELEASE is now available. Please be sure to check the Release Notes and Release Errata before installation for any late-breaking news and/or issues with 9.3. More information about FreeBSD releases can be found on the Release Information page.

FreeBSD 9.3-RELEASE Now Available

FreeBSD 9.3-RELEASE Announcement

The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 9.3-RELEASE. This is the fourth release of the stable/9 branch, which improves on the stability of FreeBSD 9.2-RELEASE and introduces some new features.

Some of the highlights:
  • The zfs(8) filesystem has been updated to support the bookmarks feature.
  • The uname(1) utility has been updated to include the -U and -K flags, which print the __FreeBSD_version for the running userland and kernel, respectively.
  • The fetch(3) library has been updated to support SNI (Server Name Identification), allowing to use virtual hosts on HTTPS.
  • Several updates to gcc(1) have been imported from Google.
  • The hastctl(8) utility has been updated to output the current queue sizes.
  • The protect(1) command has been added, which allows exempting processes from being killed when swap is exhausted.
  • The etcupdate(8) utility, a tool for managing updates to files in /etc, has been merged from head/.
  • A new shared library directory, /usr/lib/private, has been added for internal-use shared libraries.
  • OpenPAM has been updated to Nummularia (20130907).
  • A new flag, "onifconsole" has been added to /etc/ttys. This allows the system to provide a login prompt via serial console if the device is an active kernel console, otherwise it is equivalent to off.
  • Sendmail has been updated to version 8.14.9.
  • BIND has been updated to version 9.9.5.
  • The xz(1) utility has been updated to a post-5.0.5 snapshot.
  • OpenSSH has been updated to version 6.6p1.
  • OpenSSL has been updated to version 0.9.8za.
For a complete list of new features and known problems, please see the online release notes and errata list, available at:
For more information about FreeBSD release engineering activities, please see:

Availability

FreeBSD 9.3-RELEASE is now available for the amd64, i386, ia64, powerpc, powerpc64, and sparc64 architectures.

FreeBSD 9.3-RELEASE can be installed from bootable ISO images or over the network. Some architectures also support installing from a USB memory stick. The required files can be downloaded via FTP as described in the section below. While some of the smaller FTP mirrors may not carry all architectures, they will all generally contain the more common ones such as amd64 and i386.

SHA256 and MD5 hashes for the release ISO and memory stick images are included at the bottom of this message.  A PGP-signed version of this announcement is available at:
Please refer to the official announcement email for the full details regarding FreeBSD 9.3-RELEASE.

Acknowledgments

Many companies donated equipment, network access, or man-hours to support the release engineering activities for FreeBSD 9.3 including The FreeBSD Foundation, Yahoo!, NetApp, Internet Systems Consortium, ByteMark Hosting, Sentex Communications, New York Internet, Juniper Networks, NLNet Labs, iXsystems, and Yandex.

The release engineering team for 9.3-RELEASE includes:
Glen Barber <[email protected]> Release Engineering Lead, 9.3-RELEASE Release Engineer
Konstantin Belousov <[email protected]> Release Engineering
Joel Dahl <[email protected]> Release Engineering
Baptiste Daroussin <[email protected]> Package Building
Bryan Drewery <[email protected]> Package Building
Marc Fonvieille <[email protected]> Release Engineering, Documentation
Steven Kreuzer <[email protected]> Release Engineering
Xin Li <[email protected]> Release Engineering, Security Officer
Josh Paetzel <[email protected]> Release Engineering
Colin Percival <[email protected]> Security Officer Emeritus
Craig Rodrigues <[email protected]> Release Engineering
Hiroki Sato <[email protected]> Release Engineering, Documentation
Gleb Smirnoff <[email protected]> Release Engineering
Ken Smith <[email protected]> Release Engineering
Dag-Erling Smøgrav <[email protected]> Security Officer
Marius Strobl <[email protected]> Release Engineering
Robert Watson <[email protected]> Release Engineering, Security

Trademark

FreeBSD is a registered trademark of The FreeBSD Foundation.

Love FreeBSD? Support this and future releases with a donation to The FreeBSD Foundation!

Monthly dashboard

Thursday morning, 5 AM, I couldn’t sleep. I thought I could use the time before
work to do something useful, so I started handling a few PRs for FreeBSD. After
a couple of commits, a warm shower, and just before heading to work, I quickly
browsed through my irc backlog and suddently got very sad: someone was angrily
asking why bug reports were being ignored for such a long time, pushing for his
own PR to finally be given some consideration.

Thinking about it in the bus to work I realized that this guy was right to
complain: when a bug is reported it should ideally be fixed right away. Still I
was feeling sad because being on the other side of the fence I know how much
dedication volunteers put into FreeBSD, but I was not sure everybody was aware
of this. I had to find something to express this dedication.

That’s how the idea of the monthly dashboard came: simple figures that can tell
a whole story. See for yourself with this dashboard that can be found in portmgr
monthly report for June 2014:


Monthly dashboard

Number of messages to portmgr@: 564 (+53%)
Number of commits on ports: 3,717 (+17%)
Number of ports PRs closed: 873 (+25%)
Active ports committers: 147 (+10%)


 

Isn’t it amazing? Nearly 4,000 updates on the ports tree and nearly 900 problem
reports closed in a single month!

That’s a tremendous amount of work done by our committers. Take Linux for
example: with more than twice as much contributors during the same period four
times less commits were applied to the Linux kernel than to the FreeBSD ports
tree [1].

Those figures pay tribute to our committers, and I am pleased to see that the
activity keeps growing. I personnally believe there has never been a better time
to start contributing to the FreeBSD ports tree with all those new features
currently being introduced. So come and join the party!


[1] Statistics taken from http://www.ohloh.net/p/linux:
962 commits done by 344 contributors (activity recorded from Jun 9 2014 to Jul 9 2014)

New FreeBSD Core Team elected

The FreeBSD Project is pleased to announce the completion of the 2014 Core Team election. The FreeBSD Core Team acts as the project's "board of directors" and is responsible for approving new src committers, resolving disputes between developers, appointing sub-committees for specific purposes (security officer, release engineering, port managers, webmaster, etc ...), and making any other administrative or policy decisions as needed. The Core Team has been elected by FreeBSD developers every two years since 2000.

PC-BSD Feature Digest 31 — Warden CLI upgrade + IRC Announcement

Hey everyone!  After a brief hiatus from feature updates we are back!  We’ve switched from Fridays to Mondays and rather than trying to get an update out every week we aren’t on a specific schedule.  We will continue to push out these feature updates when we have some cool new features come out we think you’ll want to know about.

The Warden and PBI_add backend (CLI)  management tools have received some exciting new features we’d like to tell you about.  You can now create jails on the fly when adding a new PBI to your application library.  For instance say you’re adding a PBI using the “pbi_add” command and you want to install the PBI into a new jail that you haven’t created yet.  You would specify:  “sudo pbi_add –J apache” without the quotes to create a default named jail with the PBI apache installed directly into it.  The –J being the new flag that specifies the creation of the new jail.

There’s also a new option now to do a bulk jail creation.  By simply using the new –bulk and –ip4pool flag you can easily roll out your preset number of jails quickly and efficiently.  To use this cool new feature just type:  “warden create <jailname> –bulk 5 –ip4pool 192.168.0.2″ and voila you’ve got 5 brand spanking new jails created in no time starting at IP address 192.168.0.2 .

The PC-BSD team is now hanging out in IRC!  Get involved in the conversation and come  visit us on Freenode in channel #pcbsd.  We look forward to seeing you there!

FreeBSD 9.3-RC3 Now Available

FreeBSD 9.3-RC3 Now Available


The third RC build of the 9.3-RELEASE release cycle is now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and sparc64 architectures.

The image checksums can be found in the PGP-signed announcement email.

ISO images and, for architectures that support it, the memory stick images are available here:

    http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.3/

(or any of the FreeBSD mirror sites).

If you notice problems you can report them through the normal Bugzilla PR system or on the -stable mailing list.

If you would like to use SVN to do a source based update of an existing system, use the "releng/9.3" branch.

A list of changes since 9.2-RELEASE are available on the 9.3-RELEASE release notes page here:


Changes between 9.3-RC2 and 9.3-RC3 include:

  • Bug fix for axge(4) range checks and receive loop header parsing.
  • Bug fix to exclude loopback addresses rather than loopback interfaces has been fixed.
  • Bug fix in uhso(4) to prevent memory use after free() and mtx_destroy().
  • Bug fix in bsdinstall(8) where certain conditions could prevent directory creation before use.
  • Bug fix for DNS-based load balancing.
  • Vendor update to oce(4).

The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases.  Systems running earlier FreeBSD releases can upgrade as follows:

    # freebsd-update upgrade -r 9.3-RC3

During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly.

    # freebsd-update install

The system must be rebooted with the newly installed kernel before continuing.

    # shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new userland components:

    # freebsd-update install

It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 8.x.  Alternatively, the misc/compat8x port can be installed to provide other compatibility libraries, afterwards the system must be rebooted into the new userland:

    # shutdown -r now

Finally, after rebooting, freebsd-update needs to be run again to remove stale files:

    # freebsd-update install

Love FreeBSD?  Support this and future releases with a donation to the FreeBSD Foundation!

FreeBSD 9.3-RC3 Available

The third RC build for the FreeBSD-9.3 release cycle is now available. ISO images for the amd64, i386, ia64, powerpc, powerpc64 and sparc64 architectures are available on most of our FreeBSD mirror sites.

BSDday

BSDday (http://bsdday.org/), University of Buenos Aires' Faculty of natural and exact sciences, Buenos Aires, Argentina 9 August, 2014. BSDday Argentina is a conference for users, sysadmins and developers of BSD software and based systems. The conference is for anyone developing, deploying and using systems based on FreeBSD, NetBSD, OpenBSD, DragonFlyBSD and others *BSD. BSDday Argentina is a technical conference and aims to collect the best technical papers and presentations available to ensure that the latest developments in our open source community are shared with the widest possible audience.

Getting to know your portmgr-lurker: William Grzybowski

From July to the end of October two new lurkers will have the opportunity to get insights into FreeBSD portmgr internals, namely William Grzybowski and Nicola Vitale. William was the first to answer our interview so let’s get to know him a bit better.

 

Name

William Grzybowski

Committer name

wg

Inspiration for your IRC nick

my name initials

 TLD of origin

.br

 Current TLD (if different from above)

Occupation

Software engineer

 Blog

None

Inspiration for using FreeBSD

Stability and simplicity

Who was your first contact in FreeBSD

I don’t recall, too long ago!

Who was your mentor(s)

culot, jpaetzel

What was your most embarrassing moment in FreeBSD

Breaking INDEX, but hey, who ever didn’t? ;)

vi(m) /  emacs / other

vim

What keeps you motivated in FreeBSD

The passion of everyone in the zoo about it. You can very easily see a
guy angry by someone’s else commit like stealing candy from his son :)

Favorite musician/band

AC/DC

What book do you have on your bedside table

book? what is that? :)

coffee / tea / other

coffee, beer (but real beer, no corn!)

How would you describe yourself

Calm and mind-centered

sendmail / postfix / other

postfix

Do you have a hobby outside of FreeBSD

Play soccer, gym

What is your favorite TV show

Fringe

Claim to Fame

I was mentored by culot and I survived! Just kidding, I have none, I am a joke!

What did you have for breakfast today

An orange and a slice of yogurt cake

What sports team do you support

Gremio Foot-Ball Porto Alegrense, brazillian soccer team

What else do you do in the world of FreeBSD

I do work mostly in python ports and help closing PRs.