The Technical BSD Conference University of Ottawa Ottawa 2007-05-16 2007-05-19 4 Confirmed Schedule 09:00 00:30 09:00 04:00 SITE F0126 chatting over TCP/IP Tutorial Lecture English VoIP 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. VoIP 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. The tutorial will be based mainly on Asterisk, but with also an eye on SER and sipxpbx, making an evaluation of all of them. Massimiliano Stucchi 13:30 04:00 SITE F0126 netflow How to Stop Blaming the Network and Find the Real Problem Tutorial Workshop English Netflow is a tool for collecting evidence of actual network activity. Unlike Wireshark or tcpdump, which only tell you what is happening right now, netflow tells you what happened in the past and allows you to compare and contrast current and historical behavior. Netflow is extremely powerful but has a reputation for being obtuse and costly. While netflow might not be easy, it becomes much less agonizing if someone takes you through its worst parts. With the right knowledge, anyone can implement netflow for minuscule costs in both hardware and time. Netflow picks up where tools like MRTG leave off, and will not only solve innumerable technical problems but resolve administrative and social problems you probably resigned yourself to enduring years ago. Michael W. Lucas part 1 part 2 part 3 09:00 03:00 SITE F0126 bacula Network backups - flexible and easy Tutorial Workshop English Bacula is a very flexible and easy to use network backup solution. Over the past few years, Bacula has become more and more widespread. The increasing popularity of this fully featured solution is evident by its inclusion in in recent books and courses. Bacula is well suited to a wide array of scenarios, varying from backing up to DVD or disk or to huge tape libraries with multiple drives and robots. This tutorial will introduce the Bacula concepts and the fundamentals of how Bacula works. Topics covered will include: * configure and install Bacula * create backups with various criteria * backup securely over untrusted networks * migrate jobs from one media to another * spooling * tips and tricks to get better performance Dan Langille 13:00 04:00 SITE F0126 packet Putting PF to good use - an introduction which gets you to the point where adminning is fun again Tutorial Workshop English This half day tutorial is a further evolved version of the "Firewalling with PF" tutorial offered at various conferences over the last year and a half. The tutorial's intended audience are aspiring or seasoned network professionals with at least a basic knowledge of networking in general and TCP/IP particular. By the time May rolls around, OpenBSD 4.1 will be the latest released version, with subtle but significant changes which will be included in the updated tutorial. The manuscript is due for significant revisions over the next few months, however the main points remain: Before we start - this is a tutorial, how we conduct the session PF? - why PF was needed and some history Packet filter? Firewall? - some common terms explained NAT? - common tricks of TCP/IP explained PF today - a short overview of PF's feature set BSD vs Linux - Configuration - if you came from Linux, how network config is done on BSD Simplest possible setup (OpenBSD) - the minimal setup for an OpenBSD machine Simplest possible setup (FreeBSD) - the bare minimum, on FreeBSD Simplest possible setup (NetBSD) - the bare minimum, on NetBSD First rule set - single machine - introducing actual filtering rules Slightly stricter - tightening security while introducing PF's macros, lists and other readability helpers Statistics from pfctl - getting to know your main tool Simple gateway with NAT - going stepwise to a typical home or small office gateway, adding some received wisdom and eliminating some bad habits, subsectioned into "Gateways and the pitfalls of in, out and on" "What is your local network, anyway?" and finally "Setting up" That sad old FTP thing - our first introduction to redirection is an attempt to handle that weird old protocol geeks all geeks hate with a passion, we end up with ways to make life more tolerable. Progresses through the use of several proxy-type applications, covering "FTP through NAT: ftp-proxy", "FTP through pf with routable addresses: ftpsesame, pftpx and ftp-proxy!" and finally "ftp-proxy, new style". Making your network troubleshooting friendly - you do need ICMP, and you can filter away the bits you do not need. Provides some background, which leads to the subsections "Then, do we let it all through?", "The easy way out: The buck stops here", "Letting ping through", "Helping traceroute", and finally "Path MTU discovery". Network hygiene: Blocking, scrubbing and so on - at this point, your filtering gateway will work, but a few tweaks might be what adds that extra sparkle: "block-policy", "scrub", "antispoof" and "Handling non-routable addresses from elsewhere". A web server and a mail server on the inside - over time, your needs *will* change. Here we build on previous examples up to set up an environment where you need to host your own mail and web server on your LAN, still using only that single official IP address. The "Taking care of your own - the inside" subsection adds some extra tips for making your servers accessible to the LAN as well Tables make your life easier - changing your filtering gateway's configuration while it's running, some command-line and script ideas. Logging - explains how PF logs work and how to get just the data you need, with "Taking a peek with tcpdump" and "But there are limits (an anecdote)" to point you in useful directions. Keeping an eye on things with pftop - introducing a useful monitoring tool which is not in the base system. Invisible gateway - bridge - stealth firewalling, shows the bare basics of filtering while hiding the actual machine doing the filtering. Directing traffic with ALTQ - introducing the ALTQ traffic shaping, bandwidth allocating network, with three examples, "ALTQ - prioritizing by traffic type" "ALTQ - allocation by percentage" and "ALTQ - handling unwanted traffic", introducing the reader to filtering on operating system SYN signatures in the last example. CARP and pfsync - explains the principles of setting up redundant hosts with automagic failover. Wireless networks made simple - given useful hardware, wireless networks with BSD are easy and fun. Provides "A little IEEE 802.11 background" covering basic principles and some words about link level encryption methods before proceeding to "Setting up a simple wireless network". An open, yet tightly guarded wireless network with authpf - using the authpf authenticating shell to load per user rule sets; useful for wireless and wired networks both. Turning away the brutes - introduces 'pass with overload' rules which add DOS wannabes to a table we "block quick", proceeds to "expiretable tidies your tables" to prune tables of old clutter using a third-party tool. Giving spammers a hard time - introduces redirecting to spamd, the fake SMTP daemon. spamd can use blacklists for tarpitting, do greylisting or both; we explain the principles, describe how to set it up and shows how much fun we can have at spammers' expense. It hurts them, not us. and finally, "PF - Haiku", "References", "Where to find the tutorial on the web" and "If you enjoyed this: Buy OpenBSD CDs and other items, donate!". The work in progress manuscript is BSD licensed and downloadable from http://home.nuug.no/~peter/pf/. Peter Hansteen The PF tutorial home page Slides for the PF tutorial 10:00 01:00 SITE A0150 sdmmccards An implementation overview Embedded Lecture English This lecture will present an outline of FreeBSD's SD/MMC infrastructure. It will summarize the relevant standards and relate them to the implementation. The interfaces between layers will be explored in enough detail to learn how to write drivers for new SD/MMC devices or to expand the number of supported host interface adapters. While SD/MMC support on the i386 platform is a nice to have item, usually the needs of that platform are covered by a small USB dongle. The i386 platform has used the CF flash device in True IDE mode to load the OS. There are a few places where SD/MMC cards are natively supported (mostly in laptops). There hasn't been much of an inroads on the i386 platform for these devices. However, the situation is quite a bit different in the embedded world. Here, cost concerns drive selection of devices with reduced pin count. Lower cost devices are interfaced serially rather than in parallel (or with bus widths that are signficantly smaller than 32 or 64 as is typical in the i386 world). Due to the semi-openness of the SD/MMC standards, these devices have won out in many cases over other flash technology. Most embedded systems today that support some kind of mass storage device support the SD/MMC cards. Many are even starting to support the SDIO standard as well. As FreeBSD moves into more embedded platforms, the need to support a variety of SD/MMC bridges is great. Most embedded platforms do not follow the same interfaces as the i386 laptops, mostly due to a desire to keep costs down by keeping royalty payments down. At present, linux supports about a dozen different flavors of bridges. If FreeBSD is to compete in this area, it must have an architecture that is as flexible and extensible as Linux. Now that most of the SD standards are freely available, many of the barriers to entry into this market are gone. This talk will review the SD standards, how they relate to the older MMC standard, how both standards are evolving. The first part of this lecture will give the basics necessary to even begin work in this area. SDHC is an emerging standard that will be discussed in detail. Once that is complete, a summary of the current state of the art in FreeBSD will be given. Cards that are supported will be enumerated, as well as the current bridges. The last part of the lecture will concentrate on writing drivers for SD cards, as well as writing bridge drivers for new platforms. The APIs will be discussed, and the mechanisms for effecting transfers will be explored. Future directions for the APIs will also be discussed. The author will present areas where enthusiastic individuals can contribute to the overall efforts. Warner Losh 11:30 01:00 SITE A0150 interrupts Pardon me. Excuse Me. Advanced Lecture English An important element in computers with multiple autonomous devices is the ability of a device to notify the CPU that it needs attention via an interrupt. The OS visible mechanics of interrupts for PCI devices is quite convoluted, especially on x86 PC systems. This paper will cover the various ways that PCI INTx interrupts have been implemented on x86 as well as the methods used by the system BIOS to communicate the implementation to operating systems. It will also cover the newer Message Signalled Interrupts that address some of the limitations of INTx interrupts. Finally, the paper will provide an overview of FreeBSD's implementation of both INTx and MSI interrupts on the x86 platform. - Legacy PCI INTx interrupts - Each device/slot has 4 pins, A# - D# shared by the functions that are hooked up to something. The pins are wired via side-band signals. - Figuring out how various things are hooked together so when an interrupt comes in we know which device(s) triggered it is called interrupt routing. - Interrupts on x86 - Each interrupt includes an IDT index (vector) and the OS maps a handler for each of the 256 possible vectors. 0-31 are reserved for faults. - Interrupt Controllers (Stuff in the Middle) - 8259A Master and Slave PICs (PC-AT) - 8 pins each, resulting in 16 ISA IRQs. IRQ 2 is really lost as it is used to chain the slave onto the master. IRQs 0, 1, 8, 13 are always reserved for non-PCI devices. IRQs 3, 4, 6, 7, 12, 14, and 15 are usually reserved for non-PCI devices. That leaves IRQs 5, 9, 10, and 11, and 5 is sometimes used as well (e.g. sound cards often used it). Each PIC is given a range of 8 contiguous (and aligned) IDT vectors. - Programmable Interrupt Routers (PCI Link Devices) - Routes PCI interrupts to pins on an interrupt controller. Provides N input pins. Can have 0 or more PCI interrupt lines tied together on an input pin. Each input pin can then be independently routed (or steered) to a specific pin on an interrupt controller. - I/O APICs - Can have any number of I/O APICs. I/O APICs tend to have 16, 24, or 32 pins. The first 16 pins for the I/O APICs are reserved for ISA devices. Typically PCI interrupt lines are tied to dedicated pins, but sometimes still shared. Can have a PCI Link tied to an input pin. Each pin has its own IDT vector value. - PCI interrupt routing on x86 thus consists of finding which (controller, pin) a (bus, slot, pin) maps to and making sure the IDT vector for (controller, pin) will trigger the interrupt handler for (bus, slot, pin). - Figuring out the Mapping - For devices behind a PCI-PCI bridge on an add-in card, interrupts are routed via a swizzle onto the interrupt pins on the bridge's upstream interface. This is also used for PCI-PCI bridges in the system where no other interrupt routing information is provided for that bus. - Really old systems' BIOS just wrote the ISA IRQ into the interrupt line PCI config register. - For systems with a programmable interrupt router, the $PIR table was added. It maps (bus, slot, pin) tuples to a link value. Each link value represents a programmable input pin on the router. Thus, to route an interrupt you first look up the right link value. Then you see what IRQ that link is routed to. If the link isn't routed yet, you have to route it to an IRQ. - When I/O APICs were introduced, the MP Table was added. This table not only enumerates the I/O APICs in the system, it also tells you which device interrupts are hooked up to pins on I/O APICs. In some of the oldest systems with I/O APICs, there was only a single I/O APIC with 16 intpins that provided 16 ISA IRQs. Interrupts were still routed to the ISA IRQs using a programmable interrupt router. For most systems, however, individual PCI interrupts are routed to individual pins on I/O APICs. - ACPI reduces the two tables ($PIR and MP Table) down to one. With ACPI, each PCI bus has its own routing table (_PRT). The OS tells ACPI if it is using APIC or the 8259A's up front. To route an interrupt, the OS finds the parent PCI bus object in the ACPI namespace and looks up the (device, pin) tuple in the _PRT table to find the destination. The destination can either be a hard-wired interrupt number (typical for the APIC case) or a link device. ACPI treats individual pins on the programmable interrupt router as PCI link devices, and provides methods for programming the link devices. Note that ACPI lets you use programmable links with APIC which the MP Table does not let you do. At least some NVidia amd64 motherboards are known to do this. - FreeBSD's implementation - Interrupts are routed to an IRQ cookie value by the PCI bridge drivers. Different PCI bridge drivers use different methods (ACPI _PRT, $PIR, MP Table, PCI-PCI swizzle) of routing IRQs. On x86, each interrupt source (i.e., pin on an APIC or 8259A) is assigned a unique IRQ. When a bridge driver locates the interrupt source a PCI interrupt is connected to, it queries it determines its IRQ value and returns that. When an interrupt is then activated via bus_setup_intr(), the nexus driver looks up the interrupt source for the specified IRQ cookie value and asks it to register the driver's interrupt handler. - IDT vectors - 0-31 are reserved for exceptions - 240-255 are used for IPIs and spurious vector - 128 (0x80) is used for system calls - 239 is used for the local APIC timer - 32 through 47 are statically assigned to the 8259As - That leaves 48 though 127 and 129 though 238 for device interrupts. I/O APIC pins allocate an IDT vector on demand when they are assigned their first interrupt handler. - PCI Message Signalled Interrupts - Interrupts are signalled via memory writes instead of sideband signals. Reduces number of physical signal lines needed. Architectures and/or chipsets define the format of the data to write as well as the address to write to. On x86, the message data include the IDT vector directly and is parsed by the chipset (either a Host-PCI or HT-PCI bridge) and dispatched directly to the CPUs. Interrupt controllers are no longer involved in interrupt delivery and interrupt routing is no longer required. Instead, the OS assigns IDT vectors directly to messages. Also, each PCI function can have multiple messages. - FreeBSD implementation - PCI bus asks the PCI bridge driver for IRQ cookie values. PCI bridges pass request up the tree. - On x86, the nexus0 device eventually gets the request and allocates some free IRQ cookie values in the range 256 to 383. It also assigns IDT vectors to those IRQs. When the interrupt is activated, the appropriate address and data values are generated and written into the MSI control registers in the PCI device. John Baldwin Paper and Slides 13:30 01:00 SITE A0150 netbsdipstack Changing architecture means code changes Networking Lecture English One of the challenges of providing network connectivity to a microkernel operating system is in adapting existing network stacks to work outside of the kernel environment. QNX has used the NetBSD networking stack for a number of years in it's Neutrino microkernel real-time operating system. We've recently completed a port of the NetBSD 3.0 source to Neutrino. This paper will discuss the architectural differences and code changes required to make the NetBSD network stack run as a userland process and highlight some of the tradeoffs associated with the final product. Sean Boudreau Robert Craig 15:00 01:00 SITE A0150 networkstack How many machines do you want? Networking Lecture English Due to better scalability and significantly lower performance cost than full hardware virtualization platforms, operating system level virtualization frameworks such as BSD jails often become platforms of choice among production hosting environments. Network stack virtualization allows complete networking independence between jails on a FreeBSD system, including providing each jail with its own virtual network interface set, routing tables, firewall, rate limiting, IPSEC configuration and more. This paper describes the design and implementation of a network stack virtualization framework for FreeBSD -CURRENT. The original implementation of the virtualized network stack for FreeBSD first appeared and was maintained as a patchset against the 4.x versions of the OS kernel. In this paper I'll describe the design issues, choices and experiences from the from-scratch reimplementation of the network stack virtualization for FreeBSD 7.0-CURRENT. The major questions the paper will address are as follows: - what are the major changes to the internal kernel API-s that the virtualization framework introduces; - what methodology can be applied for virtualizing the existing kernel code / subsystems - which parts can be done mechanically and which can be expected to be more tricky; - what are the performance implications of the stack virtualization: benchmarking against the unmodified OS; Furthermore, I'll attempt to tackle the traditional monolithic view on system virtualization, asking the question what could be the benefits of a more modular virtualization approach, in a system where diverse virtualized OS resources could be freely combinable in order to create the “right” level of virtualization for specific application scenarios. In contrast to the paper, I believe that in the talk the focus can be slightly shifted from the kernel internals to the usability and application aspects of the full network stack virtualization, compared to the standard FreeBSD jails and other system virtualization platforms. The talk would also include a brief live demo of the technology to illustrate its potentials to the audience. Marko Zec http://imunes.tel.fer.hr/virtnet/ 16:30 01:00 SITE A0150 ipv6 A Google Summer of Code Project Networking Lecture English One of the main features of the next generation IP protocol, IPv6, is security. As a summer of code project we used publicly available tools, as well as a home grown, open source, network protocol test library to test the security of the IPv6 stack in FreeBSD. This paper and presentation give the results of that work including a description of what was tested, how it was tested, and the security vulnerabilities found. Security was one of the main goals when IPv6 was being designed and is also a motivating factor for organizations moving to IPv6. Given these facts we can ask if IPv6 is really safer than IPv4. Answering this question was our project during Google Summer of Code 2006 and this paper describes our work in investigating the security of the FreeBSD IPv6 protocol stack. The paper contains a list of possible IPv6 attacks, a description of the oldest vulnerabilities, an overview of the newest ones found in the FreeBSD IPv6 stack, some new ways to do OS fingerprinting and finally a list of tricks in order to evade/bypass IDS or firewalls. The paper also explains various bug fixes as well as the new tools developed during this project. The paper covers the tools used to test for security problems, as well as the techniques used with the tools. Various tools were used in evaluating the security of the protocol code including protocol and API fuzzers. All the tools are open source and are described in the paperBlind fuzzing was not sufficient to generate interesting results and so a targeted approach was taken. Knowledge of the basic protocols involved allowed for the adaptation of attacks against the current IP protocol, IPv4, to be used in attacks on IPv6. The lower levels of the protocol, such as neighbor and router discovery, turn out to have the same issues as the Address Resolution Protocol (ARP), and several problems were found in the protocol design itself, as opposed to being found in the code. Coding problems were also found, and fixed by the FreeBSD project, as a result of this work. George Neville-Neil 09:00 01:00 SITE B0138 opening Welcome To BSDCan 2007 Plenary Meeting English Welcome to BSDCan 2007 Be there for door prizes. Dan Langille 10:00 01:00 SITE B0138 scan Coverity Scan project results and announcements Security Lecture English One year ago, Coverity launched scan.coverity.com. It offers an overview to the public, and detailed results to open source developers, of the results from the Coverity Prevent static analysis tool. This lecture will review interesting results, reveal more information to non-developers, and announce new information about the Scan project. Coverity Inc began its public Scan project March 6th, 2006. Since then, hundreds of developers have accessed the results of the scan, and committed fixes to thousands of defects in the 52 open source projects included in the Scan. Part of the purpose of this lecture is to report on the progress made in open source projects to date, by looking at some examples of fixes that have been committed, as well as show some statistical analysis. Another portion of the purpose is to share more information with people who are not developers on any of the listed projects. Since detailed results have only been available to the developers, the project has been more than a bit opaque for the rest of the public. The final portion of the purpose is to announce new information about the Scan project. The information announced could be coordinated with press releases from Coverity, or we could do the large announcements at another time and announce smaller items at BSDCan. Depends on what the conference committee prefers. This is _not_ a sales pitch. There will be no more than one slide explaining what static analysis is. David Maxwell Scan 11:30 01:00 SITE B0138 lesson Listen. Learn. Security Lecture English Wietse discusses lessons learned from the software that he released over the years. This includes how the software came into being, the widely varying publicity that his work received, and the impact his work had on open source and security. Wietse Venema 13:30 01:00 SITE B0138 auditocapture Audio, Video, and Data Capture at Home Security Lecture English This presentation illustrates the individual components of the author's home security / monitoring system, which includes a voice activated call recorder, a caller ID DSP software modem, weather station, a motion activated video recording system, and miscellaneous interface tools. A technical focus will present source code and discuss implementation details, very much a "how to" presentation. In this talk, I intend to present an overall "big picture" view of the system that I have at home. It includes a voice activated call recorder that is connected to the incoming phone lines and gives me a record of each and every conversation. This includes decoding of the caller ID tones as they come in in realtime via a DSP program. In conjunction with that, the decoded caller ID is then displayed on a TV channel in the house, so that it can be referred to from any TV, as well as being logged to disk. There are two video cameras, with plans to boost this to four, that are aimed at various locations outside. An 8x8x3 audio/video switch (custom built) is controlled by the PC and selects the video source for the motion activated recording package to look at and capture. Only frames with sufficient motion are captured, and written to disk as JPEGs and later compressed into a DIVX movie each midnight. In this talk, I want to present the big picture, followed by implementation details of how each piece was built, and the challenges and pitfalls that were encountered and overcome. Robert Krten Description and slides 15:00 01:00 SITE B0138 stocks Using a combination of open source and custom tools for fun and profit User Lecture English This presentation describes how to download a large variety of equity and option data from various sources on the internet, how to manage the data (parsing, archiving, etc), and finally how to present the data to applications with a focus on efficiency and access speed. Public domain / open source tools like curl and lynx are highlighted, as well as the author's own custom tools. The entire database schema is presented, and then the use of mmap() is shown for complete efficiency. While getting stock market data for a few stocks is very simple, the problem rapidly becomes complicated when data needs to be fetched from different data providers (some free, some subscription based) and different data formats (equities, options, automated recommendations). Storing the data is analyzed as well -- for efficiency and for archival purposes. Two passes of data parsing are required; one to get the data from the Internet format (be it a set of comma separated values from an FTP site, or deeply-buried HTML tags from a web site) and translate that into an archivable text format, and the second pass is to take the text database files and convert them into a binary database that is fast and simple to use for all downstream applications. This presentation will show the use of curl and lynx as the basic data transports to fetch the data, and then show custom tools the author has created to parse the data. Then we'll look at the format of the text database and the rationale. Finally, the database schema is presented, and a description of the data fields is given, to illustrate how all of the different forms of data (equities, options, recommendations) are stored in a logical and consistent manner. Code will be presented throughout, with a particular focus on the parsing and the mmap() database access, as well as the API for accessing the stock database. Some discussion will take place of the downstream data consumers, like the automated trading system and the quotes and option selection system. Robert Krten Description and slides 16:30 01:00 SITE B0138 embedding Embedding NetBSD - Portability Lesson's from the Lunatic Fringe Embedded Lecture English The use of embedded BSD in "software defined" hardware environments (such as FPGAs) that will exhibit a plethora of distinctly hostile behaviours entails a number of engineering decisions and trade-offs that are decidedly outside the norm of conventional hardware/software systems design. We'd like to share what we have learned about embedding BSD, and how we solve some of the problems that are related to the use of BSD operating systems in some rather unanticipated environments. General Dynamics Canada has undertaken the use of NetBSD to deliver a number a number of ruggedized communications devices. These products involve a number of interesting technologies, such as embedding NetBSD and related peripherals inside FPGA (Field Programmable Gate Array) devices. FPGA's are a rather novel place to run an operating system, and they offer a number of skull stretching challenges, as well as some distinctly funky solutions to problems you may not realize you have. Portability means different things to different people, and we have a rather unique perspective on the use of BSD in the process of developing hardware and software that exposes aspects of portability that are by turns both fascinating and maddening, often simultaneously. We use NetBSD in ruggedized (seriously ruggedized!) platforms such as wheeled and tracked vehicles operating under conditions that can be described as distinctly hostile. People talk about "bullet proof" code, we actually know what it means to develop a bulletproof BSD-based computing solution. Howard Harvey 10:00 01:00 SITE H0104 packages Your boss wants software update tools to be manager-friendly, not just sysadmin-friendly. System Administration Lecture English The ports system is a powerful, flexible method for managing software installed in FreeBSD, but it's not what many corporations are looking for in a software management tool. Large corporations rarely allow technically adept sysadmins to make decisions about when to upgrade mission-critical servers. In order for IT managers to make sensible decisions, they require information which has hitherto been communicated informally, or via home-grown (non-standard) tools in FreeBSD. Or they've simply used other platforms. This talk addresses some of the concerns about and arguments against FreeBSD that are made by corporate IT management, and presents some tools that may be used by system administrators to address these concerns, including ITIL compliance, version consistency, approval processes, integration with corporate change management systems. ===Version consistency, QA=== Large groups of servers need to be maintained in a consistent fashion, with common software versions. The process of upgrading a package needs to upgrade to a **specific** **approved** version, not simply the latest one in the ports tree. Local repositories may be used in various environments: -Corporations may be conservative with regard to the risk of downloading software built elsewhere. -Particular port option requirements may require packages to be built locally. -Large numbers of servers that share a buildenv may use a local copy rather than compiling each port on their own. -A common install package creates consistency that managers like, if they understand it in the first place. If a package repository is to be maintained, something needs to populate it. The talk will include discussion of how to manage local tinderbox-style build environments. On a related note, production environments that need to "approve" internal software releases against a specific set of package versions (for example, a PHP-based web site that may depend on default behaviour in certain versions of MySQL) will likely need to test releases in a QA. A mechanism for identifying and deploying an approved collection of package versions to distinct groups of servers will be discussed. ===Integration / Standardization of process=== We should aim for ITIL compliance wherever possible. We'll have some examples of how corporate-friendly change management works, and how automated process can inform CMDB systems (RT, Remedy, etc). ===Approval process=== Multiple management-friendly communication methods must exist, so that security vulnerabilities and other errata can prompt changes that go smoothly. For example, you might want to email your manager a URL that dynamically generates a PDF (with your company's logo at the top) that notes a recent VuXML submission, includes the applicable CVE notice's description, and the list of your company's servers that are affected. None of us like generating documentation. Having it generated for us by software that keeps things complete and consistent seems far more elegant. ===Channels/Package-sets/Metaports=== The business needs addressed by any of //Red Hat Network//, Novell's //Zenworks Linux Management// may be identified and used as comparative examples, with a review of some of the tools already available to FreeBSD admins. Paul Chvostek RHN - package management for RedHat Linux ZLM - package management for SUSE linux 11:30 01:00 SITE H0104 cluster Faster, bigger, stronger. System Administration Lecture English Since late 2000 we have developed and maintained a general purpose technical and scientific computing cluster running the FreeBSD operating system. In that time we have grown from a cluster of 8 dual Intel Pentium III systems to our current mix of 64 dual Intel Xeon and 289 dual AMD Opteron systems. In this talk we reflect on the system architecture as documented in our BSDCon 2003 paper "Building a High-performance Computing Cluster Using FreeBSD" and our changes since that time. After a brief overview of the current cluster we revisit the architectural decisions in that paper and reflect on their long term success. We then discuss lessons learned in the process. Finally, we conclude with thoughts on future cluster expansion and designs. Brooks Davis 13:30 01:00 SITE H0104 ports Watching what people do System Administration Lecture English This talk discusses recent improvements to the FreeBSD Ports Monitoring System, a set of web pages used to track issues affecting the Ports Collection. This talk discusses recent improvements to the FreeBSD Ports Monitoring System. The Ports Monitoring System is a set of programs including ones to gather data about the state of the FreeBSD Ports Collection from existing web pages and then to process them into an SQLdatabase and create a set of web pages with the data analysed. The implementation described at BSDCan 2006 included such data as port building errorlogs, Problem Reports, and CVS checkins. The major change is code to track the state of packages, not just the state of ports. This change allows FreeBSD maintainers for the first time to understand to what degree the binary packages are lagging behind the source ports, including being able to compare across OS releases and architectures. Goals of the work are to be able to highlight problems in the dependencies which then affect many other packages, and to understand the degree to which the other architectures lag the most common architecture (i386). Mark Linimon 15:00 01:00 SITE H0104 silent Denying the spam and malware chatter using free tools System Administration Lecture English Though the first Internet worm in 1988 was Unix software, malicious software today is primarily a Windows problem. In the free unix environments, a number of techniques and tools are available to stop unsolicited email and malware before it reaches the end user. This presentation deals with the principles and practice of keeping your network peace through intelligent use of free tools which are available on your favorite BSD. Preliminary Table of Contents: Malware, Virus, Spam The definitions A history of malware a brief historical overview The Morris Worm The first unix worm, what it did and its consequences in Internet security thinking Microsoft invents the internet In the mid nineties, the writers of edlin discovered networking. we consider their discoveries and what they brought with them Modern malware if they crack your system, what do they do? Spam Back to the other annoyance, and why it ties in with malware The ugly truth a few basics you should know about non-trivial software Fighting back How OpenBSD and other freenixes go about making life unbearable for malware writers in a few (or at least logical) easy steps Where do we fit in? Enough theory already, what can a Unix sysadmin *do* Spam: characteristics We see patterns, note them Tools: content scan Make the robots read mail, make decisions a few pros and cons More of the mundane: behavioral methods the miscreants are fun to watch, and we read their (en)trails we look at some examples of how they've adapted and review some of the tools at our disposal A working model Finally, a sample configuration. One you can build on any BSD. Integrating content filtering in your MTA's delivery chain Giving spammers a hard time The final part of the presentation goes into some detail of how to use PF and its spamd companion application, progressing through the proper selection of blacklists, greylisting and greytrapping with some examples and data on our success rate and the level of noise we are fighting. Protecting expensive proprietary appliance style tools with free tools can sometimes be enlightening. Peter Hansteen Slides for the "Silent network" talk Full text of the "Silent network" paper (pdf) 16:30 01:00 SITE H0104 varnish A lesson in performance programming System Administration Lecture English Varnish is a state of the art HTTP Accelerator written by a hard-core kernel hacker. In addition to a radical new approach in software configuration and management, Varnish is also fast. The talk will give a quick tour of Varnish and then focus on how to program for maximum performance on modern hardware and operating systems. Poul-Henning Kamp Varnish Homepage 10:00 01:00 SITE A0150 deploying Deploying Advanced Operating System Security Services User Lecture English UNIX system administrators are familiar with the UNIX security model: users, groups, and file permissions. Many will also have deployed firewalls to protect their systems. Security for UNIX systems has been one of the most active areas of OS research and development over the last ten years, leading to dozens of new features in FreeBSD between FreeBSD 4.x and FreeBSD 6.x. This talk will provide a tour of some of the new FreeBSD security features, describing where they may be useful and how to use them. Topics covered include Access Control Lists (ACLs), Pluggable Authentication Modules (PAM), Jails, Security Event Auditing, and several system hardening techniques based on the TrustedBSD MAC Framework. The presenter offers a unique perspective as the designer or implementor of several of these features. Robert Watson 11:30 01:00 SITE A0150 portsnap What (it is), Why (it was written), and How (it works) Advanced Lecture English In this talk, I will describe three years of development on portsnap: Why I wrote it, the design decisions I made, and the lessons I learned. While portsnap is a utility with a very narrow focus -- distributing updates to the FreeBSD ports tree -- the lessons learned from it are far more widely applicable, and this can be considered as a "case study" of software for distributing and keeping a set of files updated. I won't know exactly what I'll cover until I prepare my slides, but topics are likely to include * An overview of portsnap (build code vs. mirroring code vs. client code) * Why I decided to write portsnap: Security, security, security * The basic idea behind portsnap: Divide the tree into lots of small pieces plus an index which says which bits go where * The messier details: Distributing INDEX files as well * Why portsnap is fast: Pipelined HTTP * Why there isn't any srcsnap/docsnap/wwwsnap/cvssnap (but there might be a tarsnap some day) Generally speaking, I intend to talk about the design decisions, since I think BSDCan attendees probably already know how to use portsnap. Colin Percival 13:30 01:00 SITE A0150 olpc We're putting a laptop in the hands of every child in the world. User Lecture English The One Laptop Per Child initiative aims to put a low cost laptop computer in the hands of every child in the world. This talk will attempt to explain the goals, challenges (aggressive power management, mesh networking, and activity collaboration), and implementation of this ambitious project. Most of the nearly two–billion children in the developing world are inadequately educated, or receive no education at all. One in three does not complete the fifth grade. The One Laptop Per Child initiative is an ambitious project to put a low-cost yet powerful laptop computer into the hands of every child in the world, using only Free Software. OLPC also brings some unique technical challenges forward for hackers of all kinds, from the kernel (power management and mesh networking), to user space (collaborative activities, UI design, and performance). Andrew Clunis One Laptop Per Child 15:00 01:00 SITE A0150 pfsense When things fail, be prepared. System Administration Lecture English Last year many BSDCan attendees saw an overview of what pfSense is all about. Since then, the first stable release of pfSense is out and this presentation will cover a few of the more advanced features that are available. This presentation will cover how the multi-WAN and failover capabilities in pfSense function, and how to implement them in your environment. -CARP The inclusion of OpenBSD's CARP allows for seamless failover in the case of hardware failure, including maintaining the state table. This also allows for firewall maintenance and upgrades without any loss of network connectivity. -Multi-WAN failover How you can connect multiple Internet connections to your firewall and allow for failover between them in the case of an outage. -Policy based routing + failover How you can direct specific traffic over a specific WAN interface, and also fail over to another WAN interface if your desired connection is down. -DNS Failover When one of your WAN connections fails, the multi-WAN failover capabilities of pfSense keep your Internet up and running. But what about DNS-based services you provide to external users, like web site hosting? DNS failover comes into play here by automatically updating your external DNS records to direct users to the appropriate WAN connection. -Incoming and Outgoing Load Balancing The outgoing load balancing functionality of pfSense allows you to load balance your outbound Internet traffic over multiple WAN connections. The incoming load balancing enables you to load balance incoming traffic from the Internet to multiple internal servers. Scott Ullrich Chris Buechler 16:30 01:00 SITE A0150 openvpn OpenVPN means never having to say your sorry for buying customized IPSec clients System Administration Lecture English UTORvpn is an institutional implementation of OpenVPN which services remote campus access from both MS-Windows and Unix based clients. UTORvpn is an Opensource VPN solution that allows remote users to connect to central campus resources over a secure SSL channel. Authenticated clients recieve a local institutional IP address; either statically or dynamically allocated. Free software exists for WinXP, Win2k, and Unix (Linux, *BSD, Mac OS X, and Solaris) based clients. Customized binary packages are created on the fly for MS-Windows clients. At run time, all clients authenticate using Kerberos credentials. Russell Sutherland 10:00 01:00 SITE B0138 securityofficier Things that go bump in the night Security Lecture English The presentation basically describes what the FreeBSD Security Team is doing behind the scenes to handle security vulnerabilities in FreeBSD. Today most computers are connected to some kind of network, so it is an important requirement for many users / administrators that the operating system and application programs are updated with regards to security vulnerabilities. The presentation will describe how the FreeBSD project handles security vulnerabilities in the base system and Ports Collection and a bit about how a user / administrator can keep up-to-date with regard to software fixes when using FreeBSD. Simon L. Nielsen 11:30 01:00 SITE B0138 zfs A much anticipated FS Filesystems Lecture English There will be 3 parts to this presentation. - a short introduction to ZFS and its great features - discussion of porting work, enumerate differences between the FreeBSD port and Solaris ZFS, and show some performance numbers. - demonstrate how ZFS works on a FreeBSD machine I would like to present the work I did on porting ZFS file system from the OpenSolaris to the FreeBSD. ZFS is one of the most wanted file system these days, it offers a huge number of interesting features and some unique ones, like: - storage pool model, - copy-on-write model (no fsck, no journaling), - end-to-end data integrity, - integrated volume manager, which provides for example single and double parity RAID-Z, RAID-1, dynamic stripping, hot-spare support, etc. - cheap snapshots, - snapshots rollback, - clones (writtable snapshots), - simplified administration (no newfs(8), bsdlabel(8), fdisk(8), growfs(8), tunefs(8)), - no limits, - fast native backup and restore, - data compression, - adaptive endianess, - data encryption (WIP). One part of my talk and paper will provide more detailed introduction to ZFS and its features. I started working on ZFS port in the middle of August 2006. At this point (January 2007) my port is almost complete. 95% of the entire functionality is already implemented and works. Performance optimization process is in progress as well, file system is already marked as MPSAFE and works stable. The main part of the paper will describe porting work I did. ZFS consists userland applications and libraries, but it's heart is a kernel module. I'll try to show how well ZFS fits into FreeBSD because of integration with the GEOM infrastructure. I'd also like to describe methods I used to speed up the whole porting process and keep vendor source mostly unmodified, which will allow for easy vendor's changes tracking. I'll also like to use my port as an excuse to compare OpenSolaris' and FreeBSD's kernels, mostly VFS and disk I/O subsystems. While doing presentation I'd like to demonstrate working ZFS on FreeBSD, which may be interesting for those who attend the conference. At the end of the paper, I'll show some performance comparsion between UFS2 and ZFS (although ZFS on FreeBSD is not yet well optimized). I'd also enumerate future goals and directions on my work as ZFS opens many doors, ie. ZFS integration with jails, iSCSI, NFS, etc. We also need to port NFSv4 ACLs, which are natively used in ZFS. Pawel Dawidek 13:30 01:00 SITE B0138 freenas The FreeNAS little story Filesystems Lecture English Network-attached storage (NAS) is the name given to dedicated data storage technology that can be connected directly to a computer network to provide centralized data access and storage to heterogeneous network clients. NAS has increased in popularity as storage requirements and disk capacity escalate. FreeNAS is a free NAS server, supporting: CIFS (samba), FTP, NFS, AFP, RSYNC, iSCSI protocols, S.M.A.R.T., local user authentication, Software RAID (0,1,5) with a Full WEB configuration interface. FreeNAS takes less than 32MB once installed on Compact Flash, hard drive or USB key. The minimal FreeBSD distribution, Web interface, PHP scripts and documentation are based on M0n0wall. Olivier Cochard-Labbe FreeNAS - Official Web Site FreeNAS - Sourceforge site 15:00 01:00 SITE B0138 autofs A new protocol for an asynchronous automounting filesystem, on FreeBSD Filesystems Lecture English Filesystems store, organize, and retrieve data for users and often these files are stored on remote machines, or removable media. The UNIX system requires that these filesystems must be mounted before files can be accessed. In network environments, mounted filesystems can result in extra traffic, even when the filesystem is mounted, but no files are used. This extra traffic is undesirable, and adversely affects the available network bandwidth, and mounted filesystems require more in-kernel memory and datastructures to maintain them as "active." Nobody wants to keep remote filesystems mounted, when they're not in use. AutoFS works with AMD, a daemon which auto-mounts filesystems, to provide an on-demand mounting facility. The purpose of AutoFS is to limit the load upon AMD, and to provide a layer of kernel control over mounting. This control is used to minimise the number of calls to the Automounting daemon (AMD) thereby providing better performance as a user navigates the "unified" filesystem tree. This paper describes the implementation details of AutoFS for FreeBSD 6.x AutoFS on FreeBSD 6: The file system is one of the most fundamental constructs of modern computer usage to almost any class of user. Anyone from the casual Web surfer to the dedicated developer relies upon this simple, subtle, yet crucial technology to save, file, and later review his work. One's installed software is saved in various files in the file system, as are one's own valuable work. Because this technology is so ubiquitous and relied upon, improvements in performance or capability to this simple mechanism will reap great rewards for system vendors, and users alike. System vendors can market their product's improvements over the status quo as value added, and improve their competitive edge in the software systems market. Users benefit, because all great software products will have these improvements to remain competitive. However, economics aside, improvements to the file system and it's access methods are arguably the easiest way to improve any software system. Filesystems store, organize, and retrieve data for users and often these files are stored on remote machines, or removable media. The UNIX system requires that these filesystems must be mounted before files can be accessed. In network environments, mounted filesystems can result in extra traffic, even when the filesystem is mounted, but no files are used. This extra traffic is undesirable, and adversely affects the available network bandwidth, and mounted filesystems require more in-kernel memory and datastructures to maintain them as "active." Nobody wants to keep remote filesystems mounted, when they're not in use. AutoFS works with AMD, a daemon which auto-mounts filesystems, to provide an on-demand mounting facility. The purpose of AutoFS is to limit the load upon AMD, and to provide a layer of kernel control over mounting. This control is used to minimise the number of calls to the Automounting daemon (AMD) thereby providing better performance as a user navigates the "unified" filesystem tree. Removable media can also be serviced by the automounter. Users often expect their removable media to be available on-demand, without requiring a user-issued command to attach the filesystem to the unified tree. AutoFS can be used to intercept calls, for AMD, and determine whether AMD must mount a filesystem. AutoFS maintains an in-kernel state, to ease the burden upon AMD, and to provide for the ability to service directory lookups which do not need AMD to mount filesystems. AutoFS can be used to ease the user-burden for removable media -- user access patterns for removable media revolves around using a set of files from a removable media filesystem, then removing the media, and perhaps inserting another removable volume, to access another set of files. For example, the user will insert a CDROM, access a set of documents and images, then remove the disc, and insert another, and copy a set of binaries and music to another directory. AutoFS must be written to have an internal timer, removing stale filesystems from the "mounted" status, should the filesystem be inactive. The current AutoFS protocol is also very obsolete, and has many shortcomings. I have been writing an AutoFS implementation for FreeBSD, implementing a new protocol which will be a model for other future implementations on other operating systems. This AutoFS will have a restartable, transaction based protocol. AMD, should it crash, must be able to interact with AutoFS and find out the current system state for the set of paths it monitors. This AutoFS will allow "in-place" mounting wherein the filesystem can be mounted directly over a path that AutoFS monitors, without forcing AutoFS to stop the AMD process. The AMD mounter and AutoFS will communicate using an "asynchronous" protocol, whereby AutoFS can request several mounts of AMD simultaneously, and AMD will report successes in any particular order. This will allow AMD to be rewritten or modified in a multithreaded fashion, and allow for more responsive filesystem activity on operations which will work with several paths at once. AutoFS will also track an internal listing of mountable and nonmountable paths, which nonmountable paths AMD should never receive notification about access, but mountable paths AMD must be notified if the path in question is not mounted. Hopefully this will allow FreeBSD to move to the forefront of the field regarding automount features, and make the system a reference platform for the creation of future AutoFS implementations on other systems. In other words, developers will look to FreeBSD as an example for implementation of this feature, opposed to the normal situation, where FreeBSD must strive to work like other systems. It is also possible that AutoFS could be easily ported to other UNIX systems in the BSD family, with great ease. Adam Martin 16:30 01:00 SITE B0138 wip Short stories from projects around the world Lightning-Talk English For the third 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 6, 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 11 at 11:59pm GMT. The session chair this year is ?. Robert Watson 17:30 01:00 SITE B0138 closing Thanks for all the fish Plenary Lecture English Closing session of BSDCan 2007 Jason Dixon will speak about why BSD is Dying. Dan Langille will provide a wrap-up of the conference, and throw out door prizes to those seated at the front of the room. Jason Dixon Dan Langille 18:30 01:00 SITE B0138 keysigning Sign other people's keys - will start immediately after the closing session Workshop English Each BSDCan has had a key signing. Dan Langille 10:00 01:00 SITE H0104 bsdcert How to apply BSD methods to certification programs Advocacy Podium English While creating the standard for assessing BSD sysadmin skills, the BSD Certification Group identified several areas within the existing certification infrastructure that did not meet the needs of the BSD community. This talk will outline those areas then concentrate on the collaborative development of a BSD licensed testing engine. The BSD projects have well defined mechanisms for running globally collaborative development and documentation projects. These include versioning systems, release engineering and security teams, a commit bit process, style guides, mentoring, translation teams, and mailing lists. In addition to the excellent code and documentation resulting from these mechanisms, those using BSD benefit from the BSD license. The BSD Certification Group quickly realized that none of these mechanisms exist in the current IT certification world, including the existing certifications which cover Open Source operating systems and applications. Certifying bodies are closed groups, often associated with specific commercial vendors. Examinations are delivered using expensive, proprietary software whose security mechanisms are unavailable for inspection. Study materials are not freely available or created through a collaborative process. There is little to no association with existing post-secondary programs. In short, then entire process is closed, expensive, and seemingly designed to generate profit for commercial vendors. The BSD Certification Group has strived to keep their process open, affordable, understandable, and auditable. In other words, they are breaking new ground in introducing BSD methods into the IT certification process. One such example is the collaborative development of an exam delivery method. This talk will discuss the mechanisms used to structure the development, then give details of the delivery method itself. Dru Lavigne BSD Certification website 11:30 01:00 SITE H0104 opencvs A viable alternative to CVS System Administration Lecture English OpenCVS is a FREE implementation of the Concurrent Versions System, the most popular open source revision control software. It can be used as both client and server for repositories and provides granular access control over data stored in the repository. It aims to be as compatible as possible with other CVS implementations, except when particular features reduce the overall security of the system. This talk will discuss the reasons for and the development process of OpenCVS and OpenRCS. There will be comparisons against other version control systems and reasons why CVS is preferred. Ray Lai 13:30 01:00 SITE H0104 poison (and you can too) Advocacy Lecture English Every open source project runs into people who are selfish, uncooperative, and disrespectful. These people can silently poison the atmosphere of a happy developer community. Come learn how to identify these people and peacefully de-fuse them before they derail your project. Told through a series of (often amusing) real-life anecdotes and experiences. Brian Fitzpatrick Ben Collins-Sussman 15:00 01:00 SITE H0104 pcbsd 4 out of 5 newbies prefer a graphical installer and ease of use Advocacy Lecture English PC-BSD is set to dominate the desktop. Find out why. PC-BSD is a FreeBSD-based system designed to entice new users with some additions and modifications to FreeBSD that include a graphical installer, a default KDE desktop setup, and a GUI-based self-extracting package installer that attempts to reduce some of the complexities of software and dependency management for casual users. These changes, combined with some system pre-configuration and other features, make PC-BSD easier and more attractive than many other options as a potential desktop operating system choice to try out. Matt Olander 16:30 01:00 SITE H0104 powerpc Notes on the journey to the embedded world Embedded Lecture English This paper covers recent development work to port FreeBSD to embedded PowerPC machine, with a particular example of Freescale MPC8555 communications processor. Current FreeBSD/powerpc supports only Apple's PowerMacs (now getting legacy). This paper covers recent development work to port FreeBSD to embedded PowerPC machine, with a particular example of Freescale MPC8555 communications processor. Challenges of porting an operating system to another architecture and platform are briefly explained. Highlights of current FreeBSD/powerpc state and its areas that are subject to change and adaptation are also presented. The discussion covers key areas of the bring up: bootloader, locore kernel initialization, on-chip peripheral devices. Special attention is given to the virtual memory concepts, how the e500 core facilities were modelled, and their software counterparts designed and implemented in order to fit the established conventions and APIs. A number of hints are given on the methodology used; a summary of problems identified along the way is presented, as well as details on on the prospective PowerPC variations to be supported in the future. Currently ongoing effort to integrate the port with the FreeBSD/powerpc source tree is also explained. Rafal Jaworowski