Homepage

Topic

Staff

Registration

Sponsors

Program

Talk

Accomodation

Travelling

Slide

Photo

For general, organization and sponsorship infos, please write an email to info@opencon.org

Between OpenBSD 3.9 and 4.0 some major changes were implemented in the network stack. Most of the features were designed or implemented at the r2k6 mini hackathon (14-18 June in Hamburg). This presentation gives an overview of what was done and why. Most notably it will cover stuff like: - policy routing - equal cost multipath routing - route priorities and their effect on the routing daemons Maybe a few more topics may be covered like multicast routing (with dvmrpd), etc.

Support for some time signal stations and GPS receivers has recently been added to OpenBSD in the the form of the udcf(4) driver and the nmea(4) tty line discipline. The two provide timedelta sensors, a new concept, which software like e.g. ntpd(8) can use to adjust the local and network time. I will talk on the background of my work, show practical implementations and ive some implementattion details.

a general presentation of OpenRIPD possibly on OpenBSD 4.0. I will describe the protocol, the implementation and a little bit of use.

Felix Kronlage will give an introduction on how to deploy 3G technology (UMTS, EDGE, GPRS) datacards with OpenBSD in a mobile environment as well as the use of this technology in an embedded appliance in order to achieve redundancy over alternative links. Furthermore the talk will give details on how 3G works in general as well as to give an overview of the current state of support in OpenBSD. Depending on the crowd, the talk could cover internals on the new type of 3G devices popping up and how new drivers need to be developed for these.

Drivers involve interacting with a rather diverse cross section of the kernel. I will discuss some of the facilities the kernel provides for drivers, briefly mention several of the higher layers in the kernel, and cover the methods for exchanging data with userland. Time permitting some of the problems involved with hardware documentation and dealing with vendors will also be touched on.

If the only computer you're responsible for is your desktop or notebook computer it is easy to keep an eye on the health of the system and to get an idea of how well it is running. As soon as a component fails the service relying on that component fails as well. If a disk starts to fail or the CPU gets too hot you get pretty immediate feedback on that issue. However, in the server space there is a continual push to provide services on redundant hardware. The systems we can put in place these days may sport redundant hardware such as raid controllers and disks, power supplies, cooling elements, memory and CPUs. Some services can even take advantage of using multiple computers to provide fail-over in the event of a whole machine dying. All of this means that if one of these components fails the service will just keep running. The problem with this is that we no longer get the friendly phone call from our users telling us when something isn't working anymore. Instead we need to be able to get the status of the components so that in the event of a failure we can take appropriate action and maintain redundancy. Fortunately servers these days are built with a variety of sensors onboard so you can monitor their health. In the case of raid, the controller is aware of the health of the disks and is able to report their state. However, like all hardware, unless there is appropriate software you cannot take advantage of all this information simply because you can't get at it. We intend to present the sensors and bio interfaces and several drivers in OpenBSD as examples of how you can take advantage of this hardware to keep an eye on your systems.

OpenBSD is written by a group of people spread across the world, in different cities, in different timezones, in different occupations, and with different interests. Most of us became involved in OpenBSD without meeting another OpenBSD developer (both in real life or on the "interweb"). What attracted us to the project? Why are we still here?

A discussion of current hardware support for processor power management features such as frequency/voltage scaling, and clock throttling in OpenBSD 4.0. I will also discuss how the sysctl hw.setperf mechanism works, its behaviour and current limitations, and future work in this area.

OpenBSD focuses on writing correct and secure software. In this presentation I will talk about general secure software development practices. Techniques such as privilege sepatation, and working with lower privileges will also be discussed.