Tag Archives: Mac

Avahi 0.6.13 released

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.6.13.html

Avahi Logo

I am happy to bring you yet another release of Avahi, everyone’s favourite Zeroconf stack.

Add a new D-Bus method for changing the mDNS host name during
runtime. This functionality is only available to members of the
UNIX group “netdev”, which is the same access group that is
enforced by GNOME’s NetworkManager daemon. Since NM will probably
be the most prominent user of this new method, we decided to limit
access to the same group. The access group can be set by passing
–with-avahi-priv-access-group= to “configure”. If you need more
sophisticated access control you can freely edit
/etc/dbus/system.d/avahi-dbus.conf.
Add a new utility “avahi-set-host-name” which is a command line
wrapper around the aforementioned SetHostName() method.
Bonjour API compatibility library:

Implement DNSServiceUpdateRecord()
Allow passing NULL as callback function for DNSServiceRegister()
Implement subtype registration in DNSServiceRegister() in a
way that is compatible with Bonjour.
Update to newer copy of dns_sd.h

If the host name changes update names of static services wich
contain wildcards.
Don’t build documentation about embedding the Avahi mDNS stack into
other programs by default. This is a feature used only by embedded
developers. Pass –enable-core-docs to “configure” to enable
building these docs, like in Avahi <= 0.6.12.
Build Qt documentation only when Qt support is enabled in
the configuration. Same for GLib.
Change algorithm used to find a new host name on conflict. In
Avahi <= 0.6.12 a conflicting host name of “foobar” would be
changed to the new name “foobar2”. With 0.6.13 “foobar-2” will be
picked instead. This follows Bonjour’s behaviour and has the
advantage not confusing people with regular host names ending in
digits.
Don’t disable all static services when SIGHUP is recieved.
Fix build when Avahi is configured without Gtk+ but with Python
support
Fix build on MacOS X
Support using Solaris DBM instead of gdbm for the service type
database. The latter is still recommended
Minor other fixes and documentation updates

The relevant NetworkManager bug about SetHostName() is #352828.

And our bug tracker is back to only two open bugs for Avahi. That’s a good feeling, I can tell you!

Avahi 0.6.13 released

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.6.13.html

Avahi Logo

I am happy to bring you yet another release of Avahi, everyone’s favourite Zeroconf stack.

  • Add a new D-Bus method for changing the mDNS host name during
    runtime. This functionality is only available to members of the
    UNIX group “netdev”, which is the same access group that is
    enforced by GNOME’s NetworkManager daemon. Since NM will probably
    be the most prominent user of this new method, we decided to limit
    access to the same group. The access group can be set by passing
    –with-avahi-priv-access-group= to “configure”. If you need more
    sophisticated access control you can freely edit
    /etc/dbus/system.d/avahi-dbus.conf.
  • Add a new utility “avahi-set-host-name” which is a command line
    wrapper around the aforementioned SetHostName() method.
  • Bonjour API compatibility library:
    • Implement DNSServiceUpdateRecord()
    • Allow passing NULL as callback function for DNSServiceRegister()
    • Implement subtype registration in DNSServiceRegister() in a
      way that is compatible with Bonjour.
    • Update to newer copy of dns_sd.h
  • If the host name changes update names of static services wich
    contain wildcards.
  • Don’t build documentation about embedding the Avahi mDNS stack into
    other programs by default. This is a feature used only by embedded
    developers. Pass –enable-core-docs to “configure” to enable
    building these docs, like in Avahi <= 0.6.12.
  • Build Qt documentation only when Qt support is enabled in
    the configuration. Same for GLib.
  • Change algorithm used to find a new host name on conflict. In
    Avahi <= 0.6.12 a conflicting host name of “foobar” would be
    changed to the new name “foobar2”. With 0.6.13 “foobar-2” will be
    picked instead. This follows Bonjour’s behaviour and has the
    advantage not confusing people with regular host names ending in
    digits.
  • Don’t disable all static services when SIGHUP is recieved.
  • Fix build when Avahi is configured without Gtk+ but with Python
    support
  • Fix build on MacOS X
  • Support using Solaris DBM instead of gdbm for the service type
    database. The latter is still recommended
  • Minor other fixes and documentation updates

The relevant NetworkManager bug about SetHostName() is #352828.

And our bug tracker is back to only two open bugs for Avahi. That’s a good feeling, I can tell you!

MSI S270 Laptop Linux Kernel Driver

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/s270-kernel.html

Earlier this year I worked on reverse engineering the
brightness control of my MSI
S270 laptop
. Turning this work into a proper kernel driver was still left
to be done. Until yesterday… The result of yesterday’s work are two kernel patches I already posted
for upstream inclusion.

If you want to test these drivers, download the latest kernel patches:

acpi-ec-transaction.patch
acpi-s270.patch

The two patches apply to kernel 2.6.17. After patching activate “MSI S270
Laptop Extras” under “Device Drivers”/”Misc devices” and recompile and install.
After loading the s270 module, you now have a backlight class driver
exposing its innards in /sys/class/backlight/s270bl/. For
changing the screen brightness issue as root:

echo 8 > /sys/class/backlight/s270bl/brightness

This will set the screen brightness to maximum. The integer range is 0..8.

In addition to this backlight class driver we export a platform driver which
allows reading the current state of the WLAN/Bluetooth subsystem. The platform
drivers also allows toggling the automatic brightness control feature:

cat /sys/devices/platform/s270pf/wlan # Show WLAN status
cat /sys/devices/platform/s270pf/bluetooth # Show Bluetooth status
echo 1 > /sys/devices/platform/s270pf/auto_brightness # Enable automatic brightness control

If the driver refuses to load (returning ENODEV) and you are sure you have
an MSI S270 the machine is probably not recognized correctly by its DMI data.
In that case you can pass force=1 to the driver which will force the
driver load even when the DMI data doesn’t match. YMMV. If everything works
correctly please make sure to send me the output of dmidecode, so that
I can add the DMI data to the list of known laptops in the driver.

There might even be a chance that this driver works on other MSI laptop
models, too (such as S260). YMMV. But don’t come running when the driver causes
your machine to explode! MSI laptops such as the S270 or S260 are often sold as
OEM hardware under different brands (such as Cytron/TCM/Medion/Tchibo MD96100
or “SAM2000”), so if your laptop looks remotely like this one and dmidecode |
grep MICRO-STAR yields at least a single line, and you are adventurous
than you might want to test this driver on it. And don’t forget to send me your
dmidecode output if it works for you!

Unfortunately HAL (at least in my version 0.5.7) doesn’t support the generic
backlight device class yet, which means no gnome-power-manager support
for now.

Although this driver is based on reverse engineered data it should be
legally safe even in the US. After I did my initial work on the S270 controls
MSI supplied me with a register table of their ACPI Embedded Controller
(which is what this driver interfaces with) and one of their engineers even
tested my work.

Last but not least I created a mailing list for
discussion of Linux on the MSI S270
. Please join if you run Linux on one of
these machines! I will announce future driver work for the S270 there.

MSI S270 Laptop Linux Kernel Driver

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/s270-kernel.html

Earlier this year I worked on reverse engineering the
brightness control of my MSI
S270 laptop
. Turning this work into a proper kernel driver was still left
to be done. Until yesterday… The result of yesterday’s work are two kernel patches I already posted
for upstream inclusion.

If you want to test these drivers, download the latest kernel patches:

  1. acpi-ec-transaction.patch
  2. acpi-s270.patch

The two patches apply to kernel 2.6.17. After patching activate “MSI S270
Laptop Extras” under “Device Drivers”/”Misc devices” and recompile and install.
After loading the s270 module, you now have a backlight class driver
exposing its innards in /sys/class/backlight/s270bl/. For
changing the screen brightness issue as root:

echo 8 > /sys/class/backlight/s270bl/brightness

This will set the screen brightness to maximum. The integer range is 0..8.

In addition to this backlight class driver we export a platform driver which
allows reading the current state of the WLAN/Bluetooth subsystem. The platform
drivers also allows toggling the automatic brightness control feature:

cat /sys/devices/platform/s270pf/wlan                 # Show WLAN status
cat /sys/devices/platform/s270pf/bluetooth            # Show Bluetooth status
echo 1 > /sys/devices/platform/s270pf/auto_brightness # Enable automatic brightness control

If the driver refuses to load (returning ENODEV) and you are sure you have
an MSI S270 the machine is probably not recognized correctly by its DMI data.
In that case you can pass force=1 to the driver which will force the
driver load even when the DMI data doesn’t match. YMMV. If everything works
correctly please make sure to send me the output of dmidecode, so that
I can add the DMI data to the list of known laptops in the driver.

There might even be a chance that this driver works on other MSI laptop
models, too (such as S260). YMMV. But don’t come running when the driver causes
your machine to explode! MSI laptops such as the S270 or S260 are often sold as
OEM hardware under different brands (such as Cytron/TCM/Medion/Tchibo MD96100
or “SAM2000”), so if your laptop looks remotely like this one and dmidecode |
grep MICRO-STAR
yields at least a single line, and you are adventurous
than you might want to test this driver on it. And don’t forget to send me your
dmidecode output if it works for you!

Unfortunately HAL (at least in my version 0.5.7) doesn’t support the generic
backlight device class yet, which means no gnome-power-manager support
for now.

Although this driver is based on reverse engineered data it should be
legally safe even in the US. After I did my initial work on the S270 controls
MSI supplied me with a register table of their ACPI Embedded Controller
(which is what this driver interfaces with) and one of their engineers even
tested my work.

Last but not least I created a mailing list for
discussion of Linux on the MSI S270
. Please join if you run Linux on one of
these machines! I will announce future driver work for the S270 there.

ZeroConf in Ubuntu

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/zeroconf-ubuntu.html

(Disclaimer: I am not an Ubuntu user myself. But I happen to be the lead developer of Avahi.)

It came to my attention that Ubuntu is
discussing
whether
to
enable Zeroconf/Avahi in default installations. I would like to point out a few
things:

The “No Open Ports” policy: This policy (or at least the
way many people interprete it) seems to be thought out by someone who
doesn’t have much experience with TCP/IP networking. While it might make sense
to enforce this for application-level protocols like HTTP or FTP it doesn’t
make sense to apply it to transport-level protocols such as DHCP, DNS or in
this case mDNS (the underlying protocol of Zeroconf/Avahi/Bonjour):

Even the simplest DNS lookup requires the opening of an UDP port for a
short period of time to be able to recieve the response. This is usually not
visible to the administrator, because the time is too short to show up in
netstat -uln, but nonetheless it is an open port. (UDP is not
session-based (like TCP is) so incoming packets are accepted regardless where
they come from)

DHCP clients listen on UDP port 68 during their entire lifetime (which in
most cases is the same as the uptime of the machine). DHCP may be misused for
much worse things than mDNS. Evildoers can forge DHCP packets to change IP
addresses and routing of machines. This is definitely something that cannot be
done with mDNS.

All three protocols, DNS, DHCP and mDNS, require a little bit of trust in
the local LAN. They (usually) don’t come with any sort of authentication and
they all are very easy to forge. The impact of forged mDNS packets is clearly
less dangerous than forged DHCP or DNS packets. Why? Because mDNS doesn’t
allow you to change the IP address or routing setup (which forged DHCP allows)
and because it cannot be used to spoof host names outside the .local
domain (which forged DNS allows).

Enforcing the “No Open ports” policy everywhere in Ubuntu would require that
both DNS and DHCP are disabled by default. However, as everybody probably
agrees, this would be ridiculous because a standard Ubuntu installation
couldn’t even be used for the most basic things like web browsing.

Oh, and BTW: DNS lookups are usually done by an NSS plugin which is loaded
by the libc into every process which uses gethostbyname() (the function for doing host name resolutions). So, in
effect every single process that uses this function has an open port for a
short time. And the DNS client code runs with user priviliges, so an exploit
really hurts. dhclient (the DHCP client) runs as root during the entire
runtime, so an exploit of it hurts even more. Avahi in contrast runs as its own user and
chroot()s
.

It is not my intention to force anyone to use my
software
. However, enforcing the “No Open Ports” policy unconditionally is
not a good idea. Currently Ubuntu makes exceptions for DHCP/DNS and so
it should for mDNS.

I do agree that publishing all kinds of local services with Avahi in a
default install is indeed problematic. However, if the “No Open Ports” policy
is enforced on all other application-level software, there shouldn’t be any
application that would want to register a service with Avahi.

Starting Avahi “on-demand” is not an option either, because it offers useful
services even when no local application is accessing is. Most notably this is
host name resolution for the local host name. (Hey, yeah, Zeroconf is more than
just stealing music.)

Remember: Zeroconf is about
Zero Configuration. Requiring the user to toggle some obscure
configuration option before he can use Zeroconf would make it a paradox.
Zeroconf was designed to make things “just work”. If it isn’t enabled by
default it is impossible to reach that goal.

Oh, and I enabled commmenting in my blog, if anyone wants to flame me on this…

ZeroConf in Ubuntu

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/zeroconf-ubuntu.html

(Disclaimer: I am not an Ubuntu user myself. But I happen to be the lead developer of Avahi.)

It came to my attention that Ubuntu is
discussing
whether
to
enable Zeroconf/Avahi in default installations. I would like to point out a few
things:

The “No Open Ports” policy: This policy (or at least the
way many people interprete it) seems to be thought out by someone who
doesn’t have much experience with TCP/IP networking. While it might make sense
to enforce this for application-level protocols like HTTP or FTP it doesn’t
make sense to apply it to transport-level protocols such as DHCP, DNS or in
this case mDNS (the underlying protocol of Zeroconf/Avahi/Bonjour):

  • Even the simplest DNS lookup requires the opening of an UDP port for a
    short period of time to be able to recieve the response. This is usually not
    visible to the administrator, because the time is too short to show up in
    netstat -uln, but nonetheless it is an open port. (UDP is not
    session-based (like TCP is) so incoming packets are accepted regardless where
    they come from)
  • DHCP clients listen on UDP port 68 during their entire lifetime (which in
    most cases is the same as the uptime of the machine). DHCP may be misused for
    much worse things than mDNS. Evildoers can forge DHCP packets to change IP
    addresses and routing of machines. This is definitely something that cannot be
    done with mDNS.

All three protocols, DNS, DHCP and mDNS, require a little bit of trust in
the local LAN. They (usually) don’t come with any sort of authentication and
they all are very easy to forge. The impact of forged mDNS packets is clearly
less dangerous than forged DHCP or DNS packets. Why? Because mDNS doesn’t
allow you to change the IP address or routing setup (which forged DHCP allows)
and because it cannot be used to spoof host names outside the .local
domain (which forged DNS allows).

Enforcing the “No Open ports” policy everywhere in Ubuntu would require that
both DNS and DHCP are disabled by default. However, as everybody probably
agrees, this would be ridiculous because a standard Ubuntu installation
couldn’t even be used for the most basic things like web browsing.

Oh, and BTW: DNS lookups are usually done by an NSS plugin which is loaded
by the libc into every process which uses gethostbyname() (the function for doing host name resolutions). So, in
effect every single process that uses this function has an open port for a
short time. And the DNS client code runs with user priviliges, so an exploit
really hurts. dhclient (the DHCP client) runs as root during the entire
runtime, so an exploit of it hurts even more. Avahi in contrast runs as its own user and
chroot()s
.

It is not my intention to force anyone to use my
software
. However, enforcing the “No Open Ports” policy unconditionally is
not a good idea. Currently Ubuntu makes exceptions for DHCP/DNS and so
it should for mDNS.

I do agree that publishing all kinds of local services with Avahi in a
default install is indeed problematic. However, if the “No Open Ports” policy
is enforced on all other application-level software, there shouldn’t be any
application that would want to register a service with Avahi.

Starting Avahi “on-demand” is not an option either, because it offers useful
services even when no local application is accessing is. Most notably this is
host name resolution for the local host name. (Hey, yeah, Zeroconf is more than
just stealing music.)

Remember: Zeroconf is about
Zero Configuration. Requiring the user to toggle some obscure
configuration option before he can use Zeroconf would make it a paradox.
Zeroconf was designed to make things “just work”. If it isn’t enabled by
default it is impossible to reach that goal.

Oh, and I enabled commmenting in my blog, if anyone wants to flame me on this…

A big bear hugged one and then there were two

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/howl.html

Scott Herscher decided to cease development of HOWL.
That means only Avahi and Bonjour are left as
widely known mDNS/DNS-SD implementations.

Scott, your work on HOWL has not been in vain. Many Linux/Free Software
people (including me) learned to know Zeroconf with your software. Without the
troubles surrounding the licensing, I would never have started what is now
known as Avahi, and HOWL would still be the number one of the Linux mDNS/DNS-SD
implementations.

The HOWL legacy will live on, since Avahi includes a HOWL compatibility layer which will be kept around for a while.

A year and a few weeks ago Trent and I decided to merge our efforts and
form Avahi from our seperate works. I wonder how much time it will take us
until we see a similar R.I.P. note from the Bonjour camp, on our route to
AVAHI WORLD DOMINATION. 😉

In contrast to what Scott wrote in his announcement, Avahi is far from being
strictly Linux. Avahi has been ported to FreeBSD, OpenBSD, MacOSX and recently
(not yet official) Solaris. (However, he’s right with what he writes
about me.)

A big bear hugged one and then there were two

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/howl.html

Scott Herscher decided to cease development of HOWL.
That means only Avahi and Bonjour are left as
widely known mDNS/DNS-SD implementations.

Scott, your work on HOWL has not been in vain. Many Linux/Free Software
people (including me) learned to know Zeroconf with your software. Without the
troubles surrounding the licensing, I would never have started what is now
known as Avahi, and HOWL would still be the number one of the Linux mDNS/DNS-SD
implementations.

The HOWL legacy will live on, since Avahi includes a HOWL compatibility layer which will be kept around for a while.

A year and a few weeks ago Trent and I decided to merge our efforts and
form Avahi from our seperate works. I wonder how much time it will take us
until we see a similar R.I.P. note from the Bonjour camp, on our route to
AVAHI WORLD DOMINATION. 😉

In contrast to what Scott wrote in his announcement, Avahi is far from being
strictly Linux. Avahi has been ported to FreeBSD, OpenBSD, MacOSX and recently
(not yet official) Solaris. (However, he’s right with what he writes
about me.)

Avahi Support for Apache

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/mod_dnssd.html

The first release of mod_dnssd is now available. It adds DNS-SD based Zeroconf support to Apache 2.0 using Avahi.

This work has been inspired by Sander Temme’s and Sebastien Estienne’s mod_zeroconf module, but supersedes it in every way. MacOSX ships with mod_rendezvous/mod_bonjour, but mod_dnssd is much more powerful than this piece of software as well. In short: mod_dnssd is definitely the greatest way to add Zeroconf support to Apache available today.

A few examples just to show how great mod_dnssd is:

DNSSDEnable On

This is everything you need to enable DNS-SD support in Apache after loading the module. It will publish all virtual hosts and all existing mod_userdir directories (i.e. ~/public_html) as services of type _http._tcp.

In case you want to publish some subdirectory of the web server as service, just place DNSSDServiceName inside a <Location> section for that path:

<Location /foobar>
DNSSDServiceName “A special service called foobar”
</Location>

You can even use it to publish WebDAV shares using Apache’s mod_dav module:

<Location /webdav>
Dav On
DNSSDServiceName “A WebDAV folder”
DNSSDServiceTypes _webdav._tcp
</Location>

This especially cool since we now have a free software server counterpart for Gnome’s and KDE’s WebDAV client functionality.

Or to publish your blog as RSS service:

<Location /blog.cgi?rss>
DNSSDServiceName “The blog”
DNSSDServiceTypes _rss._tcp
</Location>

Get it while it is hot!

Avahi Support for Apache

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/mod_dnssd.html

The first release of mod_dnssd is now available. It adds DNS-SD based Zeroconf support to Apache 2.0 using Avahi.

This work has been inspired by Sander Temme’s and Sebastien Estienne’s mod_zeroconf module, but supersedes it in every way. MacOSX ships with mod_rendezvous/mod_bonjour, but mod_dnssd is much more powerful than this piece of software as well. In short: mod_dnssd is definitely the greatest way to add Zeroconf support to Apache available today.

A few examples just to show how great mod_dnssd is:

DNSSDEnable On

This is everything you need to enable DNS-SD support in Apache after loading the module. It will publish all virtual hosts and all existing mod_userdir directories (i.e. ~/public_html) as services of type _http._tcp.

In case you want to publish some subdirectory of the web server as service, just place DNSSDServiceName inside a <Location> section for that path:

<Location /foobar>
	DNSSDServiceName "A special service called foobar"
</Location>

You can even use it to publish WebDAV shares using Apache’s mod_dav module:

<Location /webdav>
	Dav On
	DNSSDServiceName "A WebDAV folder"
	DNSSDServiceTypes _webdav._tcp
</Location>

This especially cool since we now have a free software server counterpart for Gnome’s and KDE’s WebDAV client functionality.

Or to publish your blog as RSS service:

<Location /blog.cgi?rss>
	DNSSDServiceName "The blog"
	DNSSDServiceTypes _rss._tcp
</Location>

Get it while it is hot!

Introducing nss-myhostname

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/nss-myhostname.html

I am doing a lot of embedded Linux work lately. The machines we use configure their hostname depending on some external configuration options. They boot from a CF card, which is mostly mounted read-only. Since the hostname changes often but we wanted to use sudo we had a problem: sudo requires the local host name to be resolvable using gethostbyname(). On Debian this is usually done by patching /etc/hosts correctly. Unfortunately that file resides on a read-only partition. Instead of hacking some ugly symlink based solution I decided to fix it the right way and wrote a tiny NSS module which does nothing more than mapping the hostname to the IP address 127.0.0.2 (and back). (That IP address is on the loopback device, but is not identical to localhost.)

Get nss-myhostname while it is hot!

BTW: This tool I wrote is pretty useful on embedded machines too, and certainly easier to use than setterm -dump 1 -file /dev/stdout | fold -w 80. And it does color too. And looping. And is much cooler anyway.

Introducing nss-myhostname

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/nss-myhostname.html

I am doing a lot of embedded Linux work lately. The machines we use configure their hostname depending on some external configuration options. They boot from a CF card, which is mostly mounted read-only. Since the hostname changes often but we wanted to use sudo we had a problem: sudo requires the local host name to be resolvable using gethostbyname(). On Debian this is usually done by patching /etc/hosts correctly. Unfortunately that file resides on a read-only partition. Instead of hacking some ugly symlink based solution I decided to fix it the right way and wrote a tiny NSS module which does nothing more than mapping the hostname to the IP address 127.0.0.2 (and back). (That IP address is on the loopback device, but is not identical to localhost.)

Get nss-myhostname while it is hot!

BTW: This tool I wrote is pretty useful on embedded machines too, and certainly easier to use than setterm -dump 1 -file /dev/stdout | fold -w 80. And it does color too. And looping. And is much cooler anyway.

Avahi 0.6 in Beta

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.6-pre.html

Unless we find any major bugs Avahi 0.6 will be released on friday. We ask everyone to do some testing for us:

Current Avahi SVN snapshort
Current libdaemon SVN snapshot

There have been a bunch of API changes. However, the API is now frozen, so feel free to start porting your application to the new API now.

A rough overview about the many improvements in Avahi 0.6.

Support for (read-only) wide area support. (i.e. DNS-SD over unicast DNS)
Ported to FreeBSD, NetBSD, Darwin/MacOSX and to some extent OpenBSD
Compatibility layers for HOWL and Bonjour
Support for registering/browsing abritrary records
Proper support for DNS-SD service subtypes
Native C implementations of the client utilities
Now passes the Bonjour conformance test suite without any exceptions
“Passive observation of failures”
chroot() support
Many traffic reduction improvements
Bugfixes, cleanups

Avahi 0.6 in Beta

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.6-pre.html

Unless we find any major bugs Avahi 0.6 will be released on friday. We ask everyone to do some testing for us:

There have been a bunch of API changes. However, the API is now frozen, so feel free to start porting your application to the new API now.

A rough overview about the many improvements in Avahi 0.6.

  • Support for (read-only) wide area support. (i.e. DNS-SD over unicast DNS)
  • Ported to FreeBSD, NetBSD, Darwin/MacOSX and to some extent OpenBSD
  • Compatibility layers for HOWL and Bonjour
  • Support for registering/browsing abritrary records
  • Proper support for DNS-SD service subtypes
  • Native C implementations of the client utilities
  • Now passes the Bonjour conformance test suite without any exceptions
  • “Passive observation of failures”
  • chroot() support
  • Many traffic reduction improvements
  • Bugfixes, cleanups

IBM xSeries EZ Swap Hard Drive Trays

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2005/05/04/ibm-xseries.html

A few days ago, I acquired a number of IBM xSeries servers — namely x206
and x226 systems — for my work at the The Software Freedom Law
Center
. We bought bare-metal, with just CPU and memory, with
plans to install drives ourselves.

I did that for a few reasons. First, serial ATA (S-ATA or SATA)
support under Linux has just become ready for prime time, and
despite being a SCSI-die-hard for most of my life, I’ve given in
that ATA’s price/performance ratio can’t really be beat, especially
if you don’t need hot swap or hardware RAID.

When I got the machines, which each came with one 80 GB S-ATA drive, I
found them well constructed, including a very easy mounting system
for hard drives. Drives have a blue plastic tray that looks like
this (follow link of image for higher resolution shot).


Image of the IBM xSeries Easy Swap Tray

These so-called “EZ Swap” trays are not for hot-swap; the big IBM swap
trays with the lever are for that. This is just to mount and unmount
drives quickly. I was impressed, and was sad that, since IBM’s goal
is to resell you hard drives, they don’t make it easy to buy these
things outright. You have to look on IBM’s
parts and upgrade site for the x206
, you’ll find that they offer
to sell 26K-7344, which is listed as a “SATA tray”, and a 73P-8007,
which is listed as a “Tray, SATA simple swap”. However, there is no
photo, and that part number does not match the part number on the item
itself. On the machines I got, the tray is numbered 73P-9591 (or
rather, P73P9591, but I think the “P” in the front is superfluous and
stands for “Part”).

I spoke to IBM tech support (at +1-800-426-7378), who told me the
replacement part number he had for that tray I had was 73P-8007.
Indeed, if you look at third
party sites, such as Spare Parts Warehouse
, you find that number
and a price of US$28 or so. Spare Parts Warehouse doesn’t even sell
the 26K-7344.

It seemed to me strange that we had two things described as SATA tray
could be that different. And the difference in price was
substantial. It costs about US$28 for the 73P-8007 and around US$7
for the 26K-7344.

So, I called IBM spare parts division at +1-800-388-7080, and ordered
one of each. They arrived by DHL this morning. Lo and behold, they
are the very same item. I cannot tell the difference
between them upon close study. The only cosmetic difference is that
they are labeled with different part numbers. The cheaper one is
labeled 26K-7343 (one number less than what I ordered) and the other
is labeled 73P-9591 (the same number that my original SATA drives
came with).

So, if you need an EZ Swap tray from IBM for the xSeries server, I
suggest you order the 26K-7344. If you do so, and find any difference
from the 73P-8007, please do let me know. Update: on 2005-06-22, a
reader told me they now charge US$12 for the 26K-7344 tray. Further
Update: The prices seem to keep rising! Another reader reported to me
on 2005-08-08 that the 26K-7344 is now US$84 (!) and the 73P-8007 is now
only US$15. So, it costs twice as much as it did a few months
ago to get these units, and the cheaper unit apperas to be the 73P-8007.
It’ll be fun to watch and see if the prices change big again in the months
to come.

When you call IBM’s spare parts division, they may give you some
trouble about ordering the part. When you call +1-800-388-7080,
they are expecting you to be an out-of-warranty customer, and make
it difficult for you to order. It depends on who you get, but you
can place an order with a credit card even without an “IBM
Out-of-Warranty Customer Number”. If you have a customer number you
got with your original IBM equipment order, that’s your warranty
customer number and is in a different database than the one used by
the IBM Spare Parts Division.

You can just tell them that you want to make a new order with a credit
card. After some trouble, they’ll do that.