Local DNS DoT “upgrade”

First of all: This seems to be my first blogpost since 2014. Partially because of time constraints and also because what to tell 😉 Let’s see if the frequency stays at one post per 7 years.

Just a quick overview of my local DNS setup at home as it was for some years until yesterday:

  • I’m running a Synology Diskstation as network storage as well as a kind of infrastructure server for my home network because I bought it already for that purpose because of its ability to run Docker containers in addition to the normal DSM software and services. A network storage was a basic requirement (I had one for many years before) and because this has to run anyway 24×7 I was looking for a possibility to run as many things as possible on it to not require yet another power consuming device. Others run one or more Raspis but when it comes to disk usage and activity that one is not the best choice I think.
  • On the Synology I already had running a pi-hole docker container for quite some time to provide a network wide malware (and yes, also tracking and advertisement) filter. That one is running on a macvlan Docker network because otherwise pi-hole would not recognize the different devices/IPs. As the Synology Docker implementation is rather limited in the UI but provides also docker-compose via shell access this setup is done via docker-compose.
    My DHCP server (built into my central Mikrotik router) provides the pi-hole IP as DNS server to all clients. (And BTW my outgoing firewall does filter all outgoing access to 8.8.8.8 and the other Google DNS IP. Actually I’m doing a DNAT to the pi-hole for those requests. Some clients accept it and some don’t but hey, that’s how it is.)
  • I still use my ISPs DNS resolvers as recursors for pi-hole because I more or less trust my ISP, would hope that those are closest to my Internet connection with small(est) latency and because I believe in the Internet’s decentralized architecture and want to avoid concentration of vital services into a few big players like Google and Cloudflare. Even if their policies look nice I’m not sure how much those really can be trusted. Not to forget they are US companies.

Having said this: Those services in general have a point. Probably even more in networks/countries not under the European GDPR where collecting data from DNS requests (without consent) would be QUITE illegal.
What is certainly true though is that the still common style of DNS resolution is quite behind my normal privacy expectations.

So at least as a start to address this in my own little silo I decided to go for encryption of DNS traffic. For this different possibilities exist like DoT (DNS over TLS) and DoH (DNS over HTTPS) and probably also others. As I do not see why I would need to use DoH for my home network I decided to go for DoT for now. (NB: I think DoH can be a very good technology especially when being a roadwarrior connecting to arbitrary networks with mobile devices.) (A good summary why I’m not a real DoH fan for general purpose can be found here.)

So with that idea and the fact that pi-hole itself does not support any of that and also does not have real plans to do so I went on and searched for possibilities. What you the find are some references to stubby, unbound and cloudflared. You find even some references how to integrate those with pi-hole but all informations I found are about pi-hole on a Raspi where you can easily install an additional service but very few hints about how to do it in a Docker setup.

stubby

I decided to go for stubby as I heard good things about it and I didn’t need a full recursor like unbound and as I already indicated cloudflared was already out even when it was just from its name and origins.

So it was clear that I need a second container to run stubby while it might have been possible to load stubby into the pi-hole docker container with some effort I wanted to be sure that the DoT proxy is available within the whole network and not only to pi-hole. (Just because w/o a real usecase right now.)
In any case I was searching for a usable stubby container or Dockerfile to create one and ended up using https://github.com/MatthewVance/stubby-docker.git. That one looked quite ok for my usecase, I just changed the Dockerfile to the latest openssl version and the stubby configuration to the DoT servers I would like to connect to. In my case I used one provided by my ISP (which is only semi-official right now but hopefully becomes fully official at some point) and also Quad9’s. This is also some sort of central but at least somewhat more trustable than the other big guys.

Then I quickly learned that connecting a Docker container running on a macvlan network is not able to reach its Docker host network which was a blocking issue until I found a solution. There was some sort of workaround mentioned somewhere in the wide Internet which was something around creating another macvlan bridge on the host to be able to communicate but I was afraid of doing that on the Synology. No idea how flexible DSM would be around such a manual thing.

So what I tried next to solve the Docker host connectivity issue was to add a second network to the pi-hole container (I’ve chosen the default bridge in the beginning) to be able to communicate with the stubby container on the same network. Now, what to say. I wasn’t able to find any reliable way to make sure that pi-hole would set up eth0 on the macvlan and ethX on the other network. Whatever I tried (docker-compose network priority) ended up with macvlan NOT on eth0. For whatever reason I do not yet understand. Still pi-hole can be configured to listen on all interfaces which is not exactly what I wanted but as a workaround that turned out be good enough finally.

After I got both containers connected to the same Docker network, I was facing the next issue: pi-hole expects an IP address as upstream resolver but in the Docker world you don’t care about IP addresses in most cases. Everything is automatic by default.
To solve that issue I ended up with a new specific network instead of the default bridge and a direct IP assignment for the stubby container:

services:
[...pihole...]
  stubby:
    container_name: stubby
    image: wrosenauer/stubby:latest
    hostname: dns
    ports:
      - "53:8053/udp"
    restart: unless-stopped
    networks:
      zzzdns:
        ipv4_address: 172.18.0.250

networks:
[...macvlan...]
  zzzdns:
    driver: bridge
    ipam:
      config:
        - subnet: 172.18.0.0/16
          gateway: 172.18.0.1

This setup now seems to work quite alright (as much as I can tell after a day) for me.

And I finally decided to write something up here because I do not have a huge Docker background and was searching the net for hints how a setup with pi-hole and stubby could look like (on a Docker host which is not totally flexible) and had a hard time to find good pointers. I’m not sure if someone will find this in future searching for a similar solution but at least there is a slighty better chance now 😉

Share

Aurora goes Firefox Developer Edition

Mozilla announced a few days ago a new flavour of the Firefox browser called Firefox Developer Edition. This new Firefox edition is in fact replacing the previous Aurora version. Just to add some background how it was structured until a few days ago:

  • Nightly – nightly builds of mozilla-central which is basically Mozilla’s HEAD
  • Aurora – regular builds published for openSUSE under mozilla:alpha
  • Beta – weekly builds for openSUSE under mozilla:beta
  • Release – full stable public releases as shipped as end user product for openSUSE under mozilla and in Factory/Tumbleweed

There is a 6 weeks cycle where the codebase goes from Nightly to Aurora to Beta to Release while it stabilizes.

Now as Aurora is replaced to be Firefox Developer Edition I am also changing the way how to deliver those to openSUSE users:

  • Nightly – there are no RPMs provided. People who want to run it can/should grab an upstream tarball
  • Firefox Developer Edition – now available as package firefox-dev-edition from the mozilla repository
  • Beta – no changes, available (as long time permits) from mozilla:beta
  • Release – no changes, available in mozilla and submitted to openSUSE Factory / Tumbleweed

A few more notes on the Firefox Developer Edition RPMs for openSUSE:

  • it’s brand new so please send me feedback about packaging issues
  • it can be installed in parallel to Release or Beta and is started as firefox-dev and is using a different profile unless you change that default; therefore it can even run in parallel with regular Firefox
  • it carries most of the openSUSE specific patches (including KDE integration)
  • it currently has NO branding packages and therefore does not use exactly the same preferences as the openSUSE provided Firefox so it behaves like Firefox when installed with MozillaFirefox-branding-upstream
Share

openSUSE 11.4 has reached end of Evergreen support

I have posted the following to the openSUSE lists a few moments ago:

as you probably know our initial commitment to support 11.4 within
Evergreen was until July 2014.
http://en.opensuse.org/openSUSE:Evergreen

While I was hoping that we can keep 11.4 alive for some time longer this
is currently not possible from what I would call the "core team" which
is Stefan and myself. We are too busy nowadays to be able to scan and
patch every issue we get aware of.

Thanks to you all who contributed to the success of Evergreen/11.4!

The important message is:

   openSUSE 11.4 Evergreen is not actively maintained anymore!

So if you can, we recommend to switch to openSUSE 13.1 as soon as
possible which is still planned to be an Evergreen release.


Some more details below:
The repository already got and will most likely get more updates from
package maintainers who care about 11.4 and/or their packages though.
You noticed that with recent releases of patches for the bash and NSS
issues already, BUT this is _no_ guarantee that every security issue
will be fixed.
We will accept contributions from anyone though and I will try to take
care about "my" packages.

Some numbers from 11.4 Evergreen (as far as I was able to get them easily):

Evergreen lifetime: 21 months
11.4 overall lifetime (incl. Evergreen): 41 months / 3 years 5 months

Evergreen lifetime numbers (w/o official maintenance period):
Released update source packages: 804
Unique touched source packages:  177
rough number of patches (based on incident counter): 320

Let me also quote Marcus' numbers from official maintenance lifetime:

Total updates: 723
	Security:    416
	Recommended: 306
	Optional:      1
Share

openSUSE Conference 2012

Finally got around to find time to write a bit about my attendance of the openSUSE Conference 2012 in Prague.

Overall I found it a quite successful event even when I could think of a few improvements for next time.  I’ve attended quite some talks during the days and also helped recording some of them. But to me the most important thing was to meet and talk to people. Since openSUSE 11.4 is going to go Evergreen very soon there were quite some discussions including two related BOFs and a maintenance hands-on with Marcus from the SUSE Maintenance team as we are planning to use OBS’ maintenance features for the upcoming 11.4.

What I missed was a bit more space to meet and hack a bit. Both venues were a bit short on seats outside of the talks or BOF rooms. But congratulations for a pretty stable wifi network during the conference. I missed it at the hotel though 😉

Apart from that I’ve met some new (to me) people and missed some other community members including some from the board which is a bit unfortunate for the main community event but still there were many good conversations.

Special thanks to Petr from SUSE showing us the city and helping me to find my hotel when I arrived (and everything else) and also the openSUSE travel support program which was sponsoring my travel to the conference.

I’m looking forward to next year’s conference and hope I can attend there as well again.

Share

ESR and Thunderbird under KDE

A quick update about recent changes in Mozilla applications for openSUSE.

With the release of Firefox and Thunderbird 11 (and Seamonkey 2.8) the older versions (10) got obsolete as always. But Mozilla created ESR (Extended Support Release) for Firefox and Thunderbird based on versions 10 and will maintain them for a longer time. Please read the FAQ about the details. For openSUSE we will not switch to these versions for different reasons but I’ll provide these from the buildservice repository mozilla. You should be able to install the current versions (10.0.3) of Firefox and Thunderbird by choosing firefox-esr or thunderbird-esr (there is also xulrunner-esr) in your package manager if you added that repository before. Please note that this is opt-in only and it’s not possible to install latest normal version and ESR versions in parallel. They are using the same profile directory and therefore I didn’t give them a separate installation directory neither. It’s also a bit risky to jump between ESR and normal versions because of the profile. So as normal version gets higher every six weeks the riskier to jump back and forth. Basically those ESR versions should probably be used only if really necessary but I still wanted to provide that possibility. If you install the ESR versions and found issues please let me know. Because of the renaming and parallel usage of the branding packages I might have missed some packaging foo to make updates in every case smooth.

A similar topic is about Firefox 3.6 and Thunderbird 3.1. The latest round of updates (3.6.28 / 3.1.20) was most likely the last one and people should start switching to more recent versions. That also means that 11.4 will get Thunderbird 12 as replacement for 3.1.20 with the next round. Other versions are already on the latest packages. (Evergreen will likely switch to the ESR versions btw.)

And about the last announcement (from my “quick update”) people might notice that Thunderbird 11 now got at least some of the KDE integration from Firefox as people kept pinging me about it. (And Firefox’ KDE integration is also back for the official updates!)

Share

Mozilla based web authoring applications

I’m not a web designer really but I happen to be kind of responsible for packaging two web authoring applications in openSUSE which are SeaMonkey’s Composer and KompoZer. While the SeaMonkey integrated editor is somewhat limited (AFAIK) KompoZer (which was forked from Nvu at some point) has more advanced features. But KompoZer development seems to be pretty slow and it misses quite some of the new web stuff which is around nowadays. In addition the current version is BETA for quite some time now and seems to have a major issue in openSUSE 11.4 and 12.1.

Because of that I finally had a look at BlueGriffon (written by the same developer as the Netscape/Mozilla/SeaMonkey Composer and Nvu) as it seems to be in active development and supports quite some of the new HTML5 and CSS3 stuff and created an initial openSUSE package available in the mozilla OBS repository for testing now. There is also an openSUSE feature request to make it available.  If you are a web developer or already know BlueGriffon please give the package a try and send your feedback.

My plan for the openSUSE distribution would be to keep SeaMonkey’s Composer (basically anyway because it’s a part of SeaMonkey which is to stay), add BlueGriffon and drop KompoZer. If you see a reason why that might be a bad idea based on your experience as a web authoring application user please let me know.

Looking forward to your feedback!

Share

Evergreen project status update

I guess it’s time for another Evergreen status update.

I cannot tell much about 11.2 (but as far as I can see Stefan does an awesome job in maintaining it) but will share my thoughts about the 11.1 flavour of Evergreen.

When I started that project it was clearly an experiment as I haven’t had an idea how much work it would be and if people would use it or even help with it. Looking back at what we’ve created it finally is more than I expected. Compared to what I announced in the beginning it was almost possible to maintain every part of the distribution and not only server packages. There are things which turned out be quite hard (e.g. kernel) but overall most issues were covered for 11.1. I think what I was able to prove is that it’s possible to somehow maintain a distribution  with very few manpower.

Now as 11.1 is nearing its 3rd birthday on December, 18th and given the fact that it’s getting harder having stuff updated while still being more or less compatible and stable I found that I cannot keep the pace with my limited spare time and without neglecting my other volunteer projects (remember Mozilla’s rapid release cycle?). For that reason I’m announcing that I’ll step back from being the Evergreen/11.1 project leader by end of this year. As of now noone else has stepped up so I need to announce that 11.1 will most likely be unmaintained as of end of this year. This does not affect 11.2 and I’ll also try to keep my packages updated for maintained Evergreen projects in the future. I’ll also stay involved and help out with organizational and administrative stuff where needed.

It’s still possible to step up taking over the 11.1 maintenance but in the end I think 3 years is already a good timeframe for a community distribution.

I hope that I find a bit of time in december to post a (statistical) summary about Evergreen/11.1 to let you know about some details.

Thanks for your support during the last year!

Share

on Macaw, Aurora, and Miramar

With Firefox 4 released a few weeks ago it’s time for me to look into what comes next.

The first to follow are maintenance updates for Firefox 4 which are now codenamed Macaw. 4.0.1 is in upstream beta testing for a few days now. At some point in future we will have a SeaMonkey 2.1 release which will  be (most likely) based on the same Gecko version as Firefox 4 and you can get 2.1b3 snapshots for that from mozilla:beta. From the same repository you can also install a new Thunderbird 3.3a4 (codename Miramar). Please note that this early package has no Enigmail support yet.

Now to some interesting changes which are coming up with Firefox development and releases. Mozilla switched to a “rapid release cycle” after the release of FF4. This means that we will see new Firefox major releases around every 6 weeks. Firefox 5 is currently planned for end of June 2011. Firefox now is developed through different stages before the final release where Aurora is branched already for FF5 and will enter the beta stage in a few weeks. A current Firefox Aurora build is available in mozilla:alpha.

This changed release process also means that there won’t be long maintained branches anymore which has an impact on how we deal with updates during a distribution lifetime. Nothing has been discussed on that topic yet though. Another fallout is that our Firefox packages will be standalone packages again after several years of being based on XULRunner. What will happen to XULRunner in the distribution is yet another thing we need to figure out.

Share

Evergreen status after some months

I’ve just noticed that I haven’t written about Evergreen here since the beginning. I actually did post at least one status update on our list but I think it would be good to give some information to a wider audience (hoping that this blog is read by more people).

In general we are in good shape. Up to now we have released around 55 source updates. You can find the list here. So looking back that means that we were able to update almost everything including desktop applications which was not clear in the beginning how that would work out. Also the Packman team decided to support Evergreen by keeping the Essentials repository available. Unfortunately it is not quite usable at the moment since it contains RPM packages signed with keys not supported by the RPM version in 11.1 which means zypper refuses to install those.

Another milestone is that it seems we will also support 11.2 when it runs out of Novell’s maintenance on May 12th, 2011. Another community member agreed to  lead the effort. More details on that to come soon.

But not everything is working perfectly fine though. Besides some rare cases where community members submitted packages to Evergreen/11.1 all the backporting/packaging work up to now was done by myself. At some points in time I was quite on the limit of my time for the project and there is no redundancy if something bad happens to me. We really need more people contributing to Evergreen. That said it would be really nice if maintainers (especially community maintainers) would  prepare updates for 11.1 as well. Obviously there is no obligation in doing so but I somehow think that in some cases they are just missing the fact that Evergreen exists at all.

So if anyone out there has interest in helping maintaining 11.1 and/or 11.2 please contact us through our mailinglist or contact me directly.

Share

openSUSE project “Evergreen”

Following up on my previous blogpost I would like to give a small update on what happened so far about a longer supported (open)SUSE release.

We had a longer discussion on the mailing list if an openSLES (a’la CentOS) or “openSUSE LTS” would be the better or easier solution. There are pros and cons for both while the required infrastructure differs a lot. I’m not diving into details here though. While I would find a SLES clone appealing I’m not in the position to drive such an effort. I also do not think that having both makes sense and therefore I decided to go on with the other approach for now trying to extend the lifetime of an existing openSUSE release.

People in the community came up with the project name Evergreen and I think that matches what we try to build pretty well. I proposed to give the whole effort a trial with openSUSE 11.1 which went unsupported with the new year. At the moment we still have organizational and technical issues and most likely won’t be able to utilize all the update features (deltarpms, zypp patches) but still we will try to deliver updates from a certain update repository. Because of the holiday season we couldn’t figure out the details yet but hopefully will get it sorted out in time. Stay tuned for further detailed information here and on the mailing lists.

Please note that this effort is in experimental state still and didn’t attract that many contributors yet unfortunately. So at the moment it’s still unclear if we will be able to deliver as we would like to.

If you are interested in this project feel free to join our (current) project list.

Share