BSDCan 2009The Technical BSD ConferenceUniversity of OttawaOttawa2009-05-062009-05-105Final Release09:0001:0009:0003:00DMS 1130Building the Network You Need with PF, the OpenBSD packet filterworkshopenBuilding the network you need is the central theme for any network
admin. This tutorial is for aspiring or seasoned network
professionals with at least a basic knowledge of networking in general
and TCP/IP particular. The session aims at teaching tools and
techniques to make sure you build your network to work the way it's
supposed to, keeping you in charge. Central to the toolbox is the
OpenBSD PF packet filter, supplemented with tools that interact with
it. Whether you are a greybeard looking for ways to optimize your
setups or a greenhorn just starting out, this session will give you
valuable insight into the inner life of your network and provide
pointers to how to use that knowledge to build the network you need.
The session will also offer some fresh information on changes
introduced in OpenBSD 4.5, the most recent version of PF and OpenBSD.
The tutorial is loosely based on Hansteen's recent book, /The Book of
PF/ (No Starch Press), with updates and adaptations based on
developments since the book's publication date.Tutorial abstract:
Building the network you need is the central theme for any network
admin. This tutorial is for aspiring or seasoned network
professionals with at least a basic knowledge of networking in general
and TCP/IP particular. The session aims at teaching tools and
techniques to make sure you build your network to work the way it's
supposed to, keeping you in charge. Central to the toolbox is the
OpenBSD PF packet filter, supplemented with tools that interact with
it. Whether you are a greybeard looking for ways to optimize your
setups or a greenhorn just starting out, this session will give you
valuable insight into the inner life of your network and provide
pointers to how to use that knowledge to build the network you need.
The session will also offer some fresh information on changes
introduced in OpenBSD 4.5, the most recent version of PF and OpenBSD.
The tutorial is loosely based on Hansteen's recent book, /The Book of
PF/ (No Starch Press), with updates and adaptations based on
developments since the book's publication date.
Short bio:
Peter N. M. Hansteen is a consultant, writer and sysadmin from Bergen,
Norway. A longtime freenix advocate and during recent years a frequent
lecturer and tutor with emphasis on FreeBSD and OpenBSD, author of
several articles and /The Book of PF/ (No Starch Press 2007).
Long bio:
Peter N. M. Hansteen is a consultant, writer and sysadmin based in
Bergen, Norway, since 2008 employed by the Norwegian free software
consultancy FreeCode AS. He has been tinkering with computers since
the mid 1980s, mainly while working to document how the systems work
and why they don't, in English as well as his native Norwegian. In
1991 he co-founded Datadokumentasjon AS, a documentation and
localization company where he remained chairman and senior consultant
until 2008. Peter rediscovered Unixes about the time 386BSD appeared.
After a few years on Linux, which included participation in the
RFC1149 implementation (2001), he eventually migrated all important
bits to FreeBSD and OpenBSD. A long time freenix advocate, he is a
member of the BLUG (Bergen (BSD and) Linux User Group) core group and
current vice president of NUUG (the Norwegian Unix User Group).
During recent years a frequent lecturer and tutor with emphasis on
FreeBSD and OpenBSD topics, author of several articles and /The Book
of PF/ (No Starch Press 2007) and maintains his blogosphere presence
at http://bsdly.blogspot.com.
Tutorial outline:
0 intro:
This is not a HOWTO
You're wondering ... (Linux? Learn BSD? GUI tools? Automatic conversion? More info?)
PF - Haiku
What PF is
Packet filter? Firewall?
NAT?
PF today
Simplest possible setup (OpenBSD, FreeBSD, NetBSD)
First rule set - single machine
Testing your first rule set
Slightly stricter
Testing your rule set
Statistics from pfctl
1 smalltime networking:
A gateway
Pitfalls: in, out, on
What is your local network, anyway?
Simple gateway (with NAT if you need to)
Testing your rule set
Domain names and host names?
That old and sad FTP thing
ftp-proxy
Making your network troubleshooting friendly
Then, do we let it all through?
The easy way out: The buck stops here
Letting ping through
Helping traceroute
Path MTU discovery
Tables make your life easier
2 wireless
Wireless networks: background
Wireless networks made easy
authpf: per user rules
Basic authpf setup
Per user rules
Wide open but actually shut
Open but shut: pf.conf
3 up a notch: handling services
Filtering for services
Physical Separation: The DMZ
DMZ ruleset
DMZ ruleset: tighten
Sharing the load: Address pools
relayd
Basic relayd config
relayctl
relayd for SSL load balancing
The NAT version
Back to the single NATed network
Single NAT, web & mail server on the inside: from the inside
Filtering on interface groups
The power of tags
The filtering bridge
Where does it go?
Bridge setup
Handling non-routable addresses from elsewhere
4 proactive defense
Turning away the brutes
Expiring table entries with pfctl
expiretable tidies your tables
Giving spammers a hard time
Setting up spamd
Greylisting: My admin told me not to talk to strangers
Setting up spamd
track real SMTP connections: spamdlogd
Beating'em up some more: spamdb and greytrapping
spamdb and greytrapping
Greytrapping - the result
Keeping several spamds in sync
Some people really do not get it
Fixing for the people who really do not get it
Giving spammers a hard time: Conclusion
5 traffic shaping, queueing
Directing traffic with altq
What is your usable bandwidth?
ALTQ - prioritizing by traffic type
ALTQ - allocation by percentage
Queueing for a DMZ
Queueing for a DMZ: rules part 1
Queueing for a DMZ: rules part 2
overloading to a tiny queue
ALTQ - handling unwanted traffic
6 Redundancy and failover
CARP and pfsync
CARP: project spec
Setting up CARP
CARP: ifconfig
pfsync
What happens to the rule set?
7 Logs, debugging, tuning
Logging basics
Taking a peek with tcpdump
Log to syslog
Statistics via labels
Keeping an eye on things with pftop
Graph your traffic: pfstat
Other log tools you may want to look into
Good logs for good debugging
Getting your setup just right
block-policy
skip
state-policy
timeout
limit
debug
ruleset-optimiation
optimization
Hygiene: scrub and antispoof
Testing your setup
Specification (possibly incomplete)
Debugging your setup
Debugging some more
Debug - use tcpdump
Have fun!
If you enjoyed this: Support OpenBSD!
ReferencesPeter Hansteen
Tutorial slides from the November 26 (London, UK) version or the tutorial
13:0003:00DMS 1130voipVoIP TutoriallectureenVoIP is now leading a revolution in the way the World communicates, and is the rising concept which will allow seamless integration between Voice and data networks. Proprietary systems such as Skype are out there, but what can you do with a FreeBSD machine and some fantasy ? In this tutorial we will introduce the key concepts around VoIP, and we will guide you through the terminology, setup and troubleshoot of a small VoIP network, looking towards a connection to some VoIP providers, setting up a simple IVR system, along with some ideas on how to integrate this work in an existing phone system.This tutorial will guide you through the Installation and configuration of the Asterisk Telephony system on BSD. Key telephony concepts are explained during the process to help the audience get into this new world with the right know-how, as well as the hands-on needed to manage the software. Advanced topics are covered such as AGI integration and PRI devices, including driver installation and integration. In the course of the tutorial I'll be presenting the Daemonswitch project, which aims at creating a full featured easy-to-install version of FreeBSD already configured to work with Asterisk, with a configuration panel and preconfigured drivers.Massimiliano Stucchi09:0003:00DMS 1130Networking from the Bottom Up: Device DriverslectureenIn this tutorial I will describe how to write and maintain network drivers in FreeBSD and use the example of the Intel Gigabit Ethernet driver (igb) throughout the course.Students will learn the basic data structures and APIs necessary to implement a network driver in FreeBSD. The tutorial is general enough that it can be applied to other BSDs, and likely to other embedded and UNIX like systems while being specific enough that given a device and a manual the student should be able to develop
a working driver on their own. This is the first of a series of lectures on network that I am developing
over the next year or so.George Neville-Neil13:0003:00DMS 1130Flow-Based Network Managementupdated flow export and analysis tutoriallectureenCover configuring Cisco, Juniper, and BSD systems for flow collection, analysis of data, Perl modules, graphing data with Web tools and gnuplot, and use of data with other network management tools.This is a freshly updated tutorial on using flow export, collection, and analysis to improve network quality, based on the forthcoming book "Network Flow Analysis." The student will learn how to gather data on his network and analyze and interpret the results, using real-world examples.Michael W. Lucas15:0003:00Royal Oak PubregisterRegistration - pubPick up your registration pack, have a beer!otherenRegistration pick upAvoid the line ups of the first day! Pick up your registration pack early, at the pub. Sit back. Have a drink, some food. Enjoy the company.
A BSDCan tradition. :)Dan LangilleDru Lavigne
Map to most locations
09:3001:00MNT 203keynoteThinking about thinking in codeProposed keynote talklectureenThis is not a talk that's specific to any BSD but is a more general talk about how we think about coding and how our thinking changes the way we code.I compare how we built systems to how other industries build their products and talk about what we can learn from how we work and from how others work as well.George Neville-Neil11:0001:00MNT 203Building products with NetBSD - thin-clientsNetBSD: delivering the goodslectureenThis talk will discuss what thin-clients are, why they are useful and why
NetBSD is good choice to build such a device. This talk will provide information on some alternatives and the strengths and weaknesses of NetBSD when used in such a device.
It will discuss problems that needed to be addressed such as how to get a device with rich functionality running from a small amount of flash storage, as well as recent developments in NetBSD that have helped improve
the product.Stephen Borrill
ThinIT
13:0001:00MNT 203Building a Cable ISP with Open Source SoftwarelectureenThis talk is designed to walk someone through the process of
undertaking a large project involving open source software. It
begins with taking a new job at a cable company as technical lead
for their Internet division, and follows through the problem solving
and design process of developing the service, deploying it, and
serving users.
Open source software was used throughout, from NetBSD for the servers,
to Perl and msql for customer service systems, to Expect for linking
to legacy billing systems.
The presentation is designed to provide a peek into what's involved
in a large-scale project, and the problem solving required on many
fronts, technical, institutional, and political, along the way.
While there are references in the material to specific technical
problems to be resolved, the content is suitable for a general track,
as the details of the challenges are only part of the story.
This is based on my job from Aug 1996 - Aug 1999, at Fundy
Communications, where we were the first company in North America to sell
cable modems through retail computer stores. I've never presented it in
this way before, though I've obviously retold anecdotes many times since
then.
David Maxwell14:3001:00MNT 203Understanding and Tuning SCHED_ULElectureenWith the advent of widespread SMP and multicore CPU architectures it was necessary to implement a new scheduler in the FreeBSD operating system. The SCHED_ULE scheduler was added for the 5 series of FreeBSD releases and has now matured to the point where it is the default scheduler in the 7.1 release. While scheduling processes was a difficult enough task in the uniprocessor world, moving to multiple processors, and multiple cores, has significantly increased the number of problems that await engineers who wish to squeeze every last ounce of performance out of their system. This talk will cover the basic design of SCHED_ULE and focus a great deal of attention on how to tune the scheduler for different workloads, using the sysctl interfaces that have been provided for that purpose.Understanding and tuning a scheduler used to be done only by operating systems designers and perhaps a small minority of engineers focusing on esoteric high performance systems. With the advent of widespread multi-processor and multi-core architectures it has become necessary for more users and administrators to decide how to tune their systems for the best performance. The SCHED_ULE scheduler in FreeBSD provides a set of sysctl interfaces for tuning the scheduler at run time, but in order to use these interfaces effectively the scheduling process must first be understood. This presentation will give an overview of how SCHED_ULE works and then will show several examples of tuning the system with the interfaces provided.
The goal of modifying the scheduler's parameters is to change the overall performance of programs on the system. One of the first problems presented to the person who wants to tune the scheduler is how to measure the effects of their changes. Simply tweaking the parameters and hoping that that will help is not going to lead to good results. In our recent experiments we have used the top(1) program to measure our results.
A brief outline:
*) Introduction
*) SCHED_ULE Overview
*) Tuning Parameters
*) A small tuning experiment (handling involuntary context switches)
*) The effect of cpusets
*) Using cpusets effectively
George Neville-Neil16:0001:00MNT 203Crypto Acceleration on FreeBSDlectureenAs more and more services on the internet become cryptographically secured, the load of cryptography on systems becomes heavier and heavier. Crypto acceleration hardware is available in different forms for different workloads. Embedded communications processors from VIA and AMD have limited acceleration facilities in silicon and various manufacturers build hardware for accelerating secure web traffic and IPSEC VPN tunnels.
This talk gives an overview of FreeBSD's crypto framework in the kernel and how it can be used together with OpenSSL to leverage acceleration hardware. Some numbers will be presented to demonstrate how acceleration can improve performance - and how it can curiously bring a system to a grinding halt.Philip originally started playing with crypto acceleration when he saw the "crypto block" in one of his Soekris boards. As usual, addiction was instant and by the grace of the "you touch it, you own it" principle, he has been fiddling the crypto framework more than is good for him.Philip Paeps17:0002:00MNT 203portsFreeBSD portsA BOFworkshopenAs held in many past years.Another FreeBSD ports BOF.Erwin Lansing11:0001:00MNT 207gettingstartedGetting Started in Free and Open SourceInterested in getting involved? But don't really know where or how to start?lectureenThe talk is called "Getting Started in Free and Open Source". It's a talk for beginners who are interested to getting involved but don't really know where or how to start. We cover the basics of:
-why you might want to get involved
-what you can get out of participating
-more than coding is needed
-how to chose a project
-how to get started
-etiquette of lists and other communication
-dos and don't of joining a communityCat AllmanLeslie Hawthorn13:0001:00MNT 207Implementation of TARGET_MODE applicationsHow we used TARGET_MODE in the kernel to create and interesting productlectureenThis presentation will cover a real world implementation of the TARGET_MODE infrastructure in the kernel (stable/6).
Topics to include:
drivers used (isp, aic7xxx, firewire).
scsi_target userland code vs kernel drivers
missing drivers (4/8G isp support, iSCSI target)Target Mode describes a feature within certain drivers that allows a FreeBSD system to emulate a Target in the SCSI sense of the word. By recompiling your kernel with this feature enabled, it permits one to turn a FreeBSD system into an external hard disk. This feature of the FreeBSD kernel provides many interesting implementations and is highly desirable to many organizations whom run FreeBSD as their platform.
I have been tasked with the maintenance of a proprietary target driver that interfaces with the FreeBSD kernel to do offsite data mirroring at the block level. This talk will discuss the implementation of that kernel mode driver and the process my employer went through to implement a robust and flexible appliance.
Since I took over the implementation, we have implemented U160 SCSI(via aic7xxx), 2G Fibre Channel(via isp) and Firewire 400 (via sbp_targ). Each driver has it's own subtleties and requirements. I personally enhanced the existing Firewire target driver and was able to get some interesting results.
I hope to demonstrate a functional Firewire 400/800 target and show how useful this application can be for the embedded space. Also, I wish to demonstrate the need for iSCSI. USB and 4/8G Fibre Channel target implementations that use the TARGET_MODE infrastructure that is currently in place to allow others to expand their various interface types.
The presentation should consist of a high level overview, followed by detailed implementation instructions with regards to the Firewire implementation and finish up with a hands-on demonstration with a FreeBSD PC flipped into TARGET_MODE and a Mac.Sean Bruno14:3001:00MNT 207tcpImproving the FreeBSD TCP ImplementationAn update on all things TCP in FreeBSD and how they affect youlectureenMy involvement in improving the FreeBSD TCP stack has continued this past year, with much of the work targeted at FreeBSD 8. This talk will cover what these changes entail, why they are of interest to the FreeBSD community and how they help to improve our TCP implementation.It has been a busy year since attending my inaugural BSDCan in 2008, where I [talked](https://www.bsdcan.org/2008/schedule/events/87.en.html) about some of my work with TCP in FreeBSD.
I have continued the work on TCP analysis/debugging tools and integrating modular congestion control into FreeBSD as part of the [NewTCP research project](http://caia.swin.edu.au/urp/newtcp/). I will provide a progress update on this work.
Additionally, a [grant win](http://www.freebsdfoundation.org/project announcements.shtml#Lawrence) from the [FreeBSD Foundation](http://www.freebsdfoudnation.org/) to undertake a project titled "Improving the FreeBSD TCP Implementation" at Swinburne University's [Centre for Advanced Internet Architectures](http://caia.swin.edu.au/freebsd/etcp09/) has been progressing well. The project focuses on bringing TCP Appropriate Byte Counting (RFC 3465), reassembly queue auto-tuning and integration of low-level analysis/debugging tools to the base system, all of which I will also discuss.Lawrence Stewart
NewTCP research project
Enhancing the FreeBSD TCP Implementation project
Centre for Advanced Internet Architectures
16:0001:00MNT 207Detecting TCP regressions with tcpdifflectureenDetermining if a TCP stack is working correctly is hard. The tcpdiff project
aims for a simpler goal: To automatically detect differences
in TCP behavior between different versions of an operating system and display
those differences in an easy to understand format. The value judgement
of whether a certain change between version X and Y of a TCP stack
is good or bad will be left to human eyes.Determining if a TCP stack is working correctly is hard. The tcpdiff project
aims for a simpler goal: To automatically detect differences
in TCP behavior between different versions of an operating system and display
those differences in an easy to understand format. The value judgement
of whether a certain change between version X and Y of a TCP stack
is good or bad will be left to human eyes.
The initial version of tcpdiff presented at NYCBSDCon 2008 demonstrated
that it could be used to detect at least two major TCP bugs that were
introduced into FreeBSD in the past few years. The work from that presentation
can be viewed at http://www.silby.com/nycbsdcon08/.
For BSDCan 2009, I hope to fix a number of bugs in tcpdiff, make it
easier to use, set up nightly tests of FreeBSD, and improve it so that
additional known bugs can be detected. Additionally, I plan to run
it on OSes other than FreeBSD.Mike Silbersack17:0002:00MNT 207Firewire BoF PlugfestDebugging and testing of Firewire products with FreeBSDworkshopenCome one come all to a Firewire plugfest. Let's debug and test together and see if we can't knock out some features and bugs.A hands-on testing and debugging session of the Firewire stack in FreeBSD.
Everyone who wishes to attend should bring their Firewire devices, ext Drives and Cameras, and their Laptops. I will be debugging and capturing data points to enhance and improve features in the Firewire stack.
We should be able to knock out quite a bunch of bugs if folks can bring their various Firewire devices along with their various PCs.
Even if your Firewire device works perfectly, bring it by so it can be documented as supported by the Firewire team!Sean Bruno11:0001:00MRT 256Tracking FreeBSD in a commercial EnvironmentHow to stay current while staying sanelectureenThe FreeBSD project publishes two lines of source code: current and
stable. All changes must first be committed to current and then are
merged into stable. Commercial organizations wishing to use FreeBSD
in their products must be aware of this policy. Four different
strategies have developed for tracking FreeBSD over time. A company
can choose to run only unmodified release versions of FreeBSD. A
company may choose to import FreeBSD's sources once and then never
merge newer versions. A company can choose to import each new stable
branch as it is created, adding its own changes to that branch, as
well as integrating new versions from FreeBSD from time to time. A
company can track FreeBSD's current branch, adding to it their changes
as well as newer FreeBSD changes. Which method a company chooses
depends on the needs of the company. These methods are explored in
detail, and their advantages and disadvantages are discussed.
Tracking FreeBSD's ports and packages is not discussed.
http://people.freebsd.org/~imp/bsdcan2009-slides.pdf
http://people.freebsd.org/~imp/bsdcan2009-paper.pdfCompanies building products based upon FreeBSD have many choices in
how to use the projects sources and binaries. The choices range from
using unmodified binaries from FreeBSD's releases, to tracking modify
FreeBSD heavily and tracking FreeBSD's evolution in a merged tree.
Some companies may only need to maintain a stable version of FreeBSD
with more bug fixes or customizations than the FreeBSD project wishes
to place in that branch. Some companies also wish to contribute
some subset of their changes back to the FreeBSD project.
FreeBSD provides an excellent base technology with which to base
products. It is a proven leader in performance, reliability and
scalability. The technology also offers a very business friendly
license that allows companies to pick and choose which changes they
wish to contribute to the community rather than forcing all changes to
be contributed back, or attaching other undesirable license conditions
to the code.
However, the FreeBSD project does not focus on integration of its
technology into customized commercial products. Instead, the project
focuses on producing a good, reliable, fast and scalable operating
system and associated packages. The project maintains two lines of
development. A current branch, where the main development of the
project takes place, and a stable branch which is managed for
stability and reliability. While the project maintains documentation
on the system, including its development model, relatively little
guidance has been given to companies in how to integrate FreeBSD into
their products with a minimum of trouble.
Developing a sensible strategy to deal with both these portions of
FreeBSD requires careful planning and analysis. FreeBSD's lack of
guidelines to companies leaves it up to them to develop a strategy.
FreeBSD's development model differs from some of the other Free and
Open Source projects. People familiar with those systems often
discover that methods that were well suited to them may not work as
well with FreeBSD's development model. These two issues cause many
companies to make poor decisions without understanding the problems
that lie in their future.
Very little formal guidance exists for companies wishing to integrate
FreeBSD into their products. Some email threads can be located via a
Google search that could help companies, but many of them are full of
contradictory information, and it is very disorganized. While the
information about the FreeBSD development process is in the FreeBSD
handbook, the implications of that process for companies integrating
FreeBSD into their products are not discussed.Warner Losh
Slides from my talk on tracking FreeBSD
Updated paper with the latest graphs
13:0001:00MRT 256pcbsdPC-BSD - Making FreeBSD on the desktop a realityFreeBSD on the DesktoplectureenWhile FreeBSD is a all-around great operating system, it is greatly lagging behind in desktop appeal. Why is this? In this talk, we will take a look at some of the desktop drawbacks of FreeBSD, and how are are attempting to fix them through PC-BSD.FreeBSD has a reputation for its rock-solid reliability, and top-notch performance in the server world, but is noticeably absent when it comes to the vast market of desktop computing. Why is this? FreeBSD offers many, if not almost all of the same open-source packages and software that can be found in the more popular Linux desktop distributions, yet even with the speed and reliability FreeBSD offers, a relative few number of users are deploying it on their desktops.
In this presentation we will take a look at some of the reasons why FreeBSD has not been as widely adopted in the desktop market as it has on the server side. Several of the desktop weaknesses of FreeBSD will be shown, along with how we are trying to fix these short-comings through a desktop-centric version of FreeBSD, known as PC-BSD. We will also take a look at the package management system employed by all open-source operating systems alike, and some of the pitfalls it brings, which may hinder widespread desktop adoption.
Kris Moore14:3001:00MRT 256Journaling FFS with WAPBLenNetBSD 5 is the first NetBSD release with a journaling filesystem. This lecture introduces the structure of the Fast File System, the modifications for WAPBL and specific constraints of the implementation.The Fast File System (FFS) has been used in the BSD land for more than two decades. The original implementation offered two operational modes:
- safe and slow (sync)
- unsafe and fast (async)
One decade ago, Kirk McKusick introduced the soft dependency mechanism to offset the performance impact without risk of mortal peril on the first crash. With the advent of Terabyte hard disks, the need for a file system check (fsck) after a crash becomes finally unacceptable. Even a background fsck like supported on FreeBSD consumes lots of CPU time and IO bandwidth.
Based on a donation from Wasabi Systems, Write Ahead Physical Block Logging (WAPBL) provides journaling for FFS with similar or better performance than soft dependencies during normal operation. Recovery time after crashes depends on the amount of outstanding IO operations and normally takes a few seconds.
This lecture gives a short overview of FFS and the consistency constraints for meta data updates. It introduces the WAPBL changes, both in terms of the on-disk format and the implementation in NetBSD. Finally the implementation is compared to the design of comparable file systems and specific issues of and plans for the current implementation are discussed.Joerg Sonnenberger
Presentation
16:0001:00MRT 256Remote and mass management of systems with finstallAutomated management on a largish scalelectureenAn important part of the "finstall" project, created as a graphical installer for FreeBSD, is a configuration server that can be used to remotely administer and configure arbitrary systems. It allows for remote scripting of administration tasks and is flexible enough to support complete reconfiguration of running systems.The finstall project has two major parts – the front-end and the back-end. The front-end is just a GUI allowing the users to install the system in a convenient way. The back-end is a network-enabled XML-RPC server that is used by the front-end to perform its tasks. It can be used as a stand-alone configuration daemon. This talk will describe a way to make use of this property of finstall to remotely manage large groups of systems.Ivan Voras17:0002:00MRT 256ssdSolid State DrivesA BOFworkshopenSolid State Drives have very different performance characteristics from
traditional hard drives.This presents some interesting opportunities for file systems and
even userspace applications. Come along and find out about the
biggest change in hard drives since they were invented in the 1950s.
Rumours of drive giveaways have been greatly exaggerated.
Matthew Wilcox12:0001:30MRT 219bsda1BSDABSD CertificationotherenTake the BSDA certification.The BSD Certification Group Inc. is a non-profit organization committed to creating and maintaining a global certification standard for system administration on BSD based operating systems.
YOU MUST register and pay for this event. See the link for details.Dru Lavigne
Register here
17:0002:00MRT 219gsocGoogle Summer Of CodeThe BoFworkshopenFor GSoC participants, students and mentors.With Google Summer of Code acceptances on Monday, April 20 being so close to BSDCan, BSDCan is an ideal time for people to get together and discuss. Tim Kientzle17:0004:00Royal Oak PubfridayFriday night PubRoyal OakotherenAll gathering at the pub.The usual social evening of food and drink.Dan Langille
Map to most locations
10:0001:00MNT 201pfsensepfSense: 2.0 and beyondFrom firewall distribution to appliance building platformlectureenpfSense is a BSD licensed customized distribution of FreeBSD tailored for use as a firewall and router. In addition to being a powerful, flexible firewalling and routing platform, it includes a long list of related features and a package system allowing further expandability without adding bloat and potential security vulnerabilities to the base distribution. This session will start with an introduction to the project and its common uses, which have expanded considerably beyond firewalling. We will cover much of the new functionality coming in the 2.0 release, which contains significant enhancements to nearly every portion of the system as well as numerous new features.
While the primary function of the project is a firewalling and routing platform, with changes coming in pfSense 2.0, it has also become an appliance building framework enabling the creation of customized special purpose appliances. The m0n0wall code where pfSense originated has proved popular for this purpose, with AskoziaPBX and FreeNAS also based upon it, in addition to a number of commercial solutions. The goal of this appliance building framework is to enable creation of projects such as these without having to fork and maintain another code base. The existing appliances, including a DNS server using TinyDNS, VoIP with FreeSWITCH, and others will be discussed. For those interested in creating appliances, an overview of the process will be provided along with references for additional information. Chris BuechlerScott Ullrich11:3001:00MNT 201Sensors and Management for Server AppliancesFrom stock FreeBSD to enterprise-ready.lectureenIncreasingly hardware vendors are finding FreeBSD to be a platform amenable to appliance development, ranging from low-end embedded systems to high-end server appliances. This talk describes some of the goals and challenges when delivering a product to the high-end server appliance market, particularly in terms of what must be added to the base FreeBSD distribution in order to build a complete enterprise-ready appliance platform out of FreeBSD.
Modern server systems provide a plethora of hardware sensors for monitoring the system health and environment. These sensors provide a non-trivial portion of the complexity of the entire system, and may need to be accessed by a variety of mechanisms and interfaces. This talk discusses some of the mechanisms likely to be found in a modern server appliance (IPMI, SES, I2C, SMBus and others) and describes some of the approaches for implementing policies, along with their benefits and disadvantages. Some of the existing frameworks for sensor event delivery are discussed, and one new approach, which leverages the FreeBSD kqueue mechanism, is discussed in detail.Joshua Neal13:3001:00MNT 201The future of processor power management in OpenBSDlectureenThe proceeding two years of OpenBSD development have seen the substantial improvement of power management techniques on the i386 and amd64 platforms. These improvements include better support for various frequency and voltage scaling technologies such as Advanced Micro Devices Powernow! and Intels Enhanced Speedstep technology, the development of a complete AML interpreter and ACPI stack not derived from Intel's ACPICA reference code, and support for power management in multi-processor machines. This talk will explore these developments, the limitations encountered and the future direction of power management in OpenBSD.OpenBSD utilizes a very simple mechanism for communicating performance targets between user space and the kernel a sysctl mechanism called hw.setperf. The hw.setperf sysctl accepts an integer value of between 0 and 100 representing a percentage of machine performance as a performance target and passes this information to a driver ultimately responsible for implementing the performance target. Users may set performance targets themselves or rely upon the user land daemon apmd to govern the system according to a few simple policies such as cool mode where apmd attempts to keep the system running as cool as possible driven by measurements of system activity as determined from the load average. OpenBSD 4.2 saw the introduction of multiprocessor support for setperf system allowing processor performance management to be performed on all processors while preserving the simplicity of a simple numeric performance target. Subsequent versions of OpenBSD have seen the development of an AML interpreter for implementing ACPI (Advanced Configuration and Power Interface) and supporting code novel in its own right for being one of the few implementations not derived from Intel reference code the addition of support for ACPI has allowed OpenBSD to use power management features on a wider variety of modern hardware. While the simplicity of the hw.setperf mechanism is appreciated with the addition of new power management features has begun to demonstrate the limitations of the mechanism.
While the hw.setperf mechanism has served its purpose it suffers from a number of limitations. Internally the hw.setperf mechanism can only utilize a single power management mechanism at a time and a convoluted priority scheme determines which mechanism is ultimately used at boot time. The addition of multiprocessor support was beneificial but further improvements in processor power scaling technology have introduced the capacity for each cores frequency and voltage to be scaled independently of the others in a system revealing a new limitation of the setperf mechanism. Finally because the governor uses a simple metric like load average to determine system activity power saving opportunities are squandered and sub optimal behaviors are exhibited by systems such as reacting slowly to changes in system activity or by the nature of a user land governor the inability to make better decisions about the ideal performance target for the system.
Gordon Willem Klok15:0001:00MNT 201Multiple Passes of the FreeBSD Device TreelectureenThe existing device driver framework in FreeBSD works fairly well for many tasks. However, there are a few problems that are not easily solved with the current design. These problems include having "real" device drivers for low-level hardware such as clocks and interrupt controllers, proper resource discovery and management, and allowing most drivers to always probe and attach in an environment where interrupts are enabled. I propose extending the device driver framework to support multiple passes over the device tree during boot. This would allow certain classes of drivers to be attached earlier and perform boot-time setup before other drivers are probed and attached. This in turn can be used to develop solutions to the earlier list of problems.A brief outline of the paper follows:
- An overview of the existing single-pass system
- Problems that are not easily solved in the current system
- "Real" devices for low-level hardware such as clocks and interrupt controllers
- Resource discovery and management (finally supporting "PnP OS = yes")
- cold vs non-cold probing
- Supporting multiple passes
- Description of the current proposed passes
- Easy to add new passes in the future similar to SYSINIT SI_SUB_*
- Most device drivers need no modification and attach in the final pass
- Writing an early pass driver
- Use EARLY_DRIVER_MODULE() instead of DRIVER_MODULE() to specify pass number
- New semantics for bus_generic_probe() and bus_generic_attach()
- The BUS_NEW_PASS() method and bus_generic_new_pass()
- If the driver can be attached after boot (e.g. via kldload or hotplug) it must account for this in its attach routine
- Possible solutions to the earlier list of problems
- Use "early" drivers for clocks, interrupt controllers, etc.
- Resource discovery
- Use "early" drivers for buses and bridges
- Possibly add new methods for determining resource requirements and assigning ranges to buses
- Earlier scheduler start
- Start up callouts before final passJohn Baldwin
http://www.FreeBSD.org/~jhb/papers/bsdcan/2009
http://
10:0001:00MNT 202GEOM based disk schedulers for FreeBSDlectureenThe high cost of seek operations makes the throughput of disk devices
very sensitive to the offered workload. A disk scheduler can then
help reorder requests to improve the overall throughput of the device,
or improve the service guarantees for individual users, or both.
Research results in recent years have introduced, and proven the
effectiveness of, a technique called "anticipatory scheduling".
The basic idea behind this technique is that, in some cases, requests
that cause a seek should not be served immediately; instead, the
scheduler should wait for a short period of time in case other
requests arrive that do not require a seek to be served.
With many common workloads, dominated by sequential synchronous
requests, the potential loss of throughput caused by the disk idling
times is more than balanced by the overall reduction of seeks.
While a fair amount of research on disk scheduling has been conducted
on FreeBSD, the results were never integrated in the OS, perhaps
because the various prototype implementations were very device-specific
and operated within the device drivers. Ironically, anticipatory
schedulers are instead a standard part of Linux kernels.
This talk has two major contributions:
First, we will show how, thanks to the flexibility of the GEOM
architecture, an anticipatory disk scheduling framework has been
implemented in FreeBSD with little or no modification to a GENERIC
kernel. While these schedulers operate slightly above the layer
where one would naturally put a scheduler, they can still achieve
substantial performance improvements over the standard disk scheduler;
in particular, even the simplest anticipatory schedulers can prevent
the complete trashing of the disk performance that often occurs in
presence of multiple processes accessing the disk.
Secondly, we will discuss how the basic anticipatory scheduling
technique can be used not only to improve the overall throughput
of the disk, but also to give service guarantees to individual
disk clients, a feature that is extremely important in practice
e.g., when serving applications with pseudo-real-time constraints
such as audio or video streaming ones.
A prototype implementation of the scheduler that will be covered
in the presentation is available at
http://info.iet.unipi.it/~luigi/FreeBSD/
Luigi Rizzo11:3001:00MNT 202Results of a Security Assessment of the TCP and IP protocols and Common implementation StrategieslectureenFernando Gont will present the results of security assessment of the TCP and IP protocols carried out on behalf of the United Kingdom's Centre for the Protection of National Infrastructure (Centre for the Protection of National Infrastructure). His presentation will provide an overview of the aforementioned project, and will describe some of the new insights that were gained as a result of this project. Additionally, it will provide an overview of the state of affairs of the different TCP/IP implementations found in BSD operating systems with respect to the aforementioned issues.During the last twenty years, many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. The discovery of these vulnerabilities led in most cases to reports being published by a number of CSIRTs and vendors, which helped to raise awareness about the threats and the best possible mitigations known at the time the reports were published.
For some reason, much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the organization in charge of the standardization of the communication protocols in use by the Internet: the Internet Engineering Task Force (IETF). This basically led to a situation in which “known” security problems have not always been addressed by all vendors. In addition, in many cases vendors have implemented quick “fixes” to the identified vulnerabilities without a careful analysis of their effectiveness and their impact on interoperability.
As a result, producing a secure TCP/IP implementation nowadays is a very difficult task, in large part because of the hard task of identifying relevant documentation and differentiating between that which provides correct advisory, and that which provides misleading advisory based on inaccurate or wrong assumptions.
During 2006, the United Kingdom’s Centre for the Protection of National Infrastructure embarked itself in an ambitious and arduous project: performing a security assessment of the TCP and IP protocols. The project did not limit itself to an analysis of the relevant IETF specifications, but also included an analysis of common implementation strategies found in the most popular TCP and IP implementations. The result of the project was a set of documents which identifies possible threats for the TCP and IP protocols and, where possible, proposes counter-measures to mitigate the identified threats.
This presentation will will describe some of the new insights that were gained as a result of this project. Additionally, it will provide an overview of the state of affairs of the different TCP/IP implementations found in BSD operating systems.
Fernando Gont13:3001:00MNT 202Updates to the FreeBSD Problem Report SystemlectureenThis talk will present an overview of recent additions to the FreeBSD Problem Report System.The FreeBSD bugbusting team is attempting to improve the ability of users and developers to interact with the Problem Report (PR) tracking system. This talk presents an overivew of reports, graphs, and charts that have recently been added. In addition, some new models for workflow are discussed, and roadmaps for possible upgrades are discussed.Mark Linimon
http://people.freebsd.org/~linimon/studies/prs
15:0001:00MNT 202scrypt: A new key derivation functionDoing our best to thwart TLAs armed with ASICslectureenPassword-based key derivation functions are used for two primary purposes: First, to hash passwords so that an attacker who gains access to a password file does not immediately possess the passwords contained therewithin; and second, to generate cryptographic keys to be used for encrypting or authenticating data. In both cases, if passwords do not have sufficient entropy, an attacker with the relevant data can perform a brute force attack, hashing potential passwords repeatedly until the correct key is found. While commonly used key derivation functions, such as Kamp's iterated MD5, Provos and Mazieres' bcrypt, and RSA Laboratories' PBKDF1 and PBKDF2 make an attempt to increase the difficulty of brute-force attacks, they all require very little memory, making them ideally suited to attack by custom hardware.
In this talk, I will introduce the concepts of memory-hard and sequential memory-hard functions, and argue that key derivation functions should be sequential memory-hard. I will present a key derivation function which, subject to common assumptions about cryptographic hash functions, is provably sequential memory-hard, and a variation which appears to be stronger (but not provably so). Finally, I will provide some estimates of the cost of performing brute force attacks on a variety of password strengths and key derivation functions.Colin Percival16:0001:00MNT 202Kernel Development in UserspaceThe Application ApproachlectureenKernel development is always a challenge. Testing cannot efficiently
be performed on the same host as development, as a crash would
disrupt the development effort. Instead of performing testing on
the development host, multiple classic ways of making testing and
debugging less tedious are available. An emulator or usermode OS
can be used for testing without requiring a full machine. However,
triggering some code paths might be tedious, since the integrity
of the entire operating system must be preserved or a crash in
non-relevant code will bring the entire development operation to
a halt. A much more surgical approach is to do algorithm development
as a userspace application. However, this means rewriting parts
of the kernel functionality to use userspace interfaces.
We argue that often the best approach for kernel development is
using the kernel as a userspace application library. This brings
the benefits of being able to very precisely control what parts of
the code are being executed while still preserving the use of kernel
interfaces. The implementation under test remains isolated from
the host OS in the sense of an application process, so errors cannot
bring the development host down.
This talk explains the NetBSD Runnable Userspace Meta Program (rump)
framework and its uses for kernel development. We will go over
what kind of kernel development it is suitable for and what not.
We also examine the requirements for running the kernel as an
application library. Examples from file systems, the networking
stack and generic kernel algorithms will be presented.
Antti Kantee
http://www.netbsd.org/docs/rump/
10:0001:00MNT 203Quiet Computing with BSDProgramming system hardware monitors for quiet computinglectureenIn this talk, we will present a detailed overview of the features and common problems of microprocessor system hardware monitors as they relate to the topic of silent computing. In a nutshell, the topic of programmable fan control will be explored.Silent computing is an important subject as its practice reduces the amount of unnecessary stress and improves the motivation of the workforce, at home and in the office.
Attendees will gain knowledge on how to effectively programme the chips to minimise fan noise and avoid system failure or shutdown during temperature fluctuations, as well as some basic principles regarding quiet computing.
Shortly before the talk, a patch for programming the most popular chips (like those from Winbond) will be released for the OpenBSD operating system, although the talk itself will be more specific to the microprocessor system hardware monitors themselves, as opposed to the interfacing with thereof in modern operating systems like OpenBSD, NetBSD, DragonFly BSD and FreeBSD.Constantine A. Murenin11:3001:00MNT 203Automating FreeBSD InstallationsPXE Booting and install.cfg DemystifiedlectureenThis paper will provide an explanation of the tools involved in performing an automated FreeBSD install and a live demonstration of the process.
FreeBSD's sysinstall provides a powerful and flexible mechanism for automated installs but doesn't get used very often because of a lack of documentation.
Topics covered include:
* Installation and configuration of isc-dhcpd
* Setting up a TFTP server
* Creating a PXE boot installation source
* Configuration of installation options with install.cfgRandi Harper13:3001:00MNT 203Isolating Cluster Jobs for Performance and PredictabilitylectureenAt The Aerospace Corporation, we run a large FreeBSD based computing cluster to
support engineering applications.
These applications come in all shapes, sizes, and qualities of implementation.
To support them and our diverse userbase we have been searching for ways to
isolate jobs from one another in ways that are more effective than Unix
time sharing and more fine grained than allocating whole nodes to jobs.In this talk we discuss the problem space and our efforts so far.
These efforts include implementation of partial file systems virtualization and
CPU isolation using CPU sets.Brooks Davis15:0001:00MNT 203Multihoming on a budgetNetwork redundancy with open source tools on the BSDslectureenIn this period of economic downturn, getting things done with less money involved is the key to keep your business running.In this talk the audience will be introduced to key internetworking concepts such as BGP and traffic engineering , with focus on using open source technologies available on the BSDs to perform the job. A confrontation side to side will be provided with Cisco and Juniper solutions, with case studies and real world configuration examples.Massimiliano Stucchi16:0001:00MNT 203wipoWorks in Progress SessionsShort stories from projects around the worldlectureenFor the fourth year running, BSDCan will have a WIP (Works In Progress) session, with presentations on diverse topics.The format remains essentially the same: in a one hour period, audiences are entertained and informed by a rapid fire series of short talks on interesting new or on-going work by individuals or groups. Slides aer permitted, but not obligatory; pictures are highly recommended. Topic areas include new open source software projects, works in progress for future releases of existing projects, student projects, etc. WIP topics this year may make good conference papers next year!
The number of slots is limited, and experience suggests there will be more takers than slots. Sign up well in advance to be assured a spot. Please e-mail <wip@bsdcan.org> to sign up. Send a one or two paragraph summary of the topic to be presented, and the names of the person(s) presenting it. Also, please give a time estimate -- typically times will be one to five minutes. The time limit will be strictly enforced -- you will be cut off if you try to run over! The WIP e-mail registration deadline is May 3, after which remaining slots (if any) may be signed up for in person. Any slides must be received by the WIP session chair by, at latest, May 8 at 11:59pm GMT. The session chair this year is Robert Watson.Robert Watson17:0001:00MNT 203Closing sessionThe wrap uplectureenThe closingFun. Games. Awards.Dan Langille12:3001:30MRT 219bsda2BSDABSD CertificationotherenTake the BSDA certification.The BSD Certification Group Inc. is a non-profit organization committed to creating and maintaining a global certification standard for system administration on BSD based operating systems.
YOU MUST register and pay for this event. See the link for details.Dru Lavigne
Register here
18:3004:00Patty Boland'sdinnerSat night at the pubDinner outotherenLast chance for socializingAt least until the tourist thing on Sunday...Dan Langille
Map to most locations
10:0004:00Out and AbouttouristTourist TimeCome along on an organized tourist eventotherenSee the cityWe always arrange a social outing to something interesting.Dan Langille