ddupdate – instead of ddclient?

Some of us has a need of not just being connected but also connectable  while moving around. Moving around means having different IP addresses, being connectable means that we need a fixed dns name such as myhost.somewhere.net. Enter dynamic DNS.

There are many services out there. However, they are not only dynamic in the sense they can map a changing ip address to a fixed name. They are also dynamic in the sense that they come and go, not least the free ones. So, there is a need for a general framework handling this, capable of handling changing services.

The task to update the DNS data for the host is just so often handled by ddupdate, a perl script ubiquitous in all linux distros. It’s mature, and many services have instructions how to use it. Still, it has drawbacks: the config file is really complicated, it’s not flexible enough for all services, the documentation and help is not that great, and it’s really hard to maintain given the legacy. There are also security issues how passwords are handled.

I have spent some time creating an alternative.. While still simplistic, it supports 13 services out there. It’s called ddupdate, a python3 application. In some ways it’s an improvement.:

  • It’s a plugin system configured in code rather than configuration files.
  • User help is available, partly based on the installed plugins.
  • The configuration is simple as long as there is a plugin supporting the used service,
  • it’s linux-centric, using things like systemd, netrc and NetworkManager to solve things like running regularly, handling passwords and interfaces going up/down
  • It’s ipv6-aware from the beginning
  • It’s thoroughly documented in a README and a manpage.
  • It’s packaged: pypi, debian and fedora packaging is available.

Try it, you might like it! https://github.com/leamas/ddupdate

 

Advertisements

Getting Spotify and Skype into Fedora.

Fedora is really about free software, which can be used, inspected and modified according to our needs. Still, there are  commercial, closed source applications which offers a great value without being free. They are typically only distributed as binary code.

So, let’s download the binary application, build an rpm and make it available to fedora users!  For some apps this works fine,  you most often find them on rpmfusion.

However, some applications are not only closed-source but also non-redistributable. This means that rpmfusion can’t host such a package. Instead, each user must download and install the software. Examples include skype and spotify.

One could of course package some kind of ‘skype-installer’ which makes this. However, this would mean several installers and commands to handle them which might become messy. So, instead I wrote some silly shellscripts which I called lpf, which should be read Local Package Factory. The basic idea with lpf is to provide a common framework for these applications.

Using lpf,, there is now a package lpf-spotify-client. After installing this, one just have to click on the lpf-spotify-client icon  or use ‘lpf update’ in the terminal. This will download spotify, build an rpm and install it.  It’s meant to be as simple as possible, but it will always need a user actually pushing the button.

One advantage is the packaging. The lpf-spotify-client actually contains and uses spotify-client.spec, an already tested spec. There’s nothing lpf-specific  in it. OTOH, the lpf-spotify-client.spec is just some boilerplate code which should be simple to use in other applications.

One problem I’ve seen so far is the process. When I submit lpf-spotify-client for review, what the reviewer checks is lpf-spotify-scient.spec. However, this is just boilerplate code and not much to check. The central spotify-client.spec gets no attention, although the quality of this spec is what the user really is affected by. Obviously, we need to fix the review process if there will be more of these.

Now, the lpf command can actually do much more. It supports the complete package life-cycle: install,  update, remove. The upstream is at https://github.com/leamas/lpf. Here is a more in-depth presentation of the package.

The lpf-spotify-client package is now in f20 updates-testing and  rawhide if you want to give it a try. lpf-skype needs a reviewer, but looks good to me. We’ll see if this idea for a framework handling non-distributable files is the way to go until those software vendors sees the light and at least make their clients re-distributable.