Roy's Blog

A Hacker's musings on Code | Tech | Life

Yay! Finally here!Should be very very stable and the feature set is now locked.Features to look forward to :)4.1 - single instance supportBasically a single dhcpcd instance managing multiple interfaces.This is needed to correctly handle routing on the BSD's as they lack route metrics.It should also make the userland implementation easier.5.0 - dual IPv4/IPv6 stackThe initial release should handle both at the same time and all DHCP options.Authentication and other trimmings will probably come later.

Continue reading...

sed is a very powerful tool. Small than awk and grep and much more powerful. Some would also say it's harder to use, but I like it :)

Whilst putting a mini resolvconf into dhcpcd, I use very similar code to what I already had. But, I ran into a wall - dhcpcd needs to work when /usr is not mounted as it may be network mounted later. On Gentoo and most Linux distros, sed is found in /bin. However, on NetBSD it's in /usr/bin.

Oh what is a man to do :?

Luckily, we can fall back to shell for simple sed usage. Here's a simple snippet

key_get_value()
{
       local key="$1" value= x= line=
       shift
       if [$# -eq 0 ](); then
               while read line; do
                       case "${line}" in
                       "${key}"*) echo "${line##${key}}";;
                       esac
               done
       else
               for x; do
                       while read line; do
                               case "${line}" in
                               "${key}"*) echo "${line##${key}}";;
                               esac
                       done < "${x}"
               done
       fi
}

Old call

sed -n -e 's/^nameserver //p' /etc/resolv.conf

New call

key_get_value "nameserver " /etc/resolv.conf

According to the time command on dash and bash shells this is ever so slightly faster when doing resolvconf -u. This is probably because we aren't forking an external command. Also, we're working on small files - this probably sucks hard for big ones.

Anyway, this has made it into openresolv-1.6 which now works in the root of a BSD system without /usr mounted :)

Continue reading...

Shiny! Hot! merged resolv.conf and ntp.conf support!Less bugs! (hopefully no more introduced - lol)

Continue reading...

/etc/resolv.conf is a single file that is often stamped on by many different applications.One example of this is dhcpcd running on multiple interfaces.openresolv is a resolvconf implementation to help ahem resolve this by taking resolv.confs from these applications to make a single sane file.dhcpcd has always supported resolvconf when available - but what if it's not? :?dhcpcd restores the last saved resolv.conf when it fails/exits to try and make things work, but it's not exactly optimal as the order interfaces go down may not be the same order as when they come up.Well, fear no more! As dhcpcd-4 is now scriptable, implementing basic resolvconf functionality is fairly trivial. So dhcpcd remembers each interface resolv.conf and makes a single one each time dhcpcd calls its hook script.You should note that this is no replacement for resolvconf, as resolvconf is desgined to trivially hook into other packages, such as OpenVPN. Also, resolvconf can configure local nameservers such as BIND and dnsmasq which allows for a more powerful solution as libc is very limited here.

Continue reading...

All DHCP clients like to stamp their view on configuration files. After all, that is part of their job :) However, many people also have their own settings in the same configuration file. Most people don't notice dhcpcd stamping on these files, but when they do they normally just turn that feature off.

The main culprit here is ntp.conf, as it can have quite a complex setup and dhcpcd has always imposed it's own world view on it. However, this lead to an interesting bug being found in NetBSD rc.d script for ntpd - it requires ntp.conf to configure pidfile /var/run/ntpd.pid. Now, dhcpcd can't put this in as the pidfile location changes from distro to distro, so effectively dhcpcd broke the stock script. Whilst this is a NetBSD bug, some people also asked why dhcpcd could not be more intelligent about things? :?

So I've now added a nice framework so that dhcpcd hook scripts can trivially top/tail config files with their own data can clean up after themselves. Here's a snippet from 50-ntp.conf itself

do_ntp_conf()
{
   local cleaned= added=1 conf= x= 
   clean_conf /etc/ntp.conf
   cleaned=$?
   if ["$1" = "add" -a -n "${new_ntp_servers}" ](); then
      for x in ${new_ntp_servers}; do
         conf="${conf:+\n}server ${x}"
      done
      append_conf /etc/ntp.conf "${conf}"
      added=$?
   fi
   if [${cleaned} -eq 0 -o ${added} -eq 0 ](); then
      [-n "${ntpd_restart_cmd}" ]() && ${ntpd_restart_cmd}
   fi
}

Nice and simple :D I'm currently debating if we can use this framework to do more intelligent handling of /etc/resolv.conf if resolvconf is not installed, but that's not as critical.

Continue reading...