www.rosenauer.org Open in urlscan Pro
148.251.71.238  Public Scan

Form analysis
1 forms found in the DOM

GET http://www.rosenauer.org/blog/

<form method="get" id="searchform" action="http://www.rosenauer.org/blog/">
  <label for="s" class="assistive-text">Search</label>
  <input type="text" class="field" name="s" id="s" placeholder="Search">
  <input type="submit" class="submit" name="submit" id="searchsubmit" value="Search">
</form>

Text Content

Skip to primary content
Skip to secondary content


WOLFGANG'S BLOG


JUST ANOTHER WEBLOG

Search


MAIN MENU

 * Home
 * Contact
 * Privacy Policy


POST NAVIGATION

← Older posts



LOCAL DNS DOT “UPGRADE”

Posted on September 30, 2021 by Wolfgang Rosenauer

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





TwitterFacebookDiggMastodonPocket
Posted in Uncategorized | Tagged dns, docker, pi-hole, stubby


AURORA GOES FIREFOX DEVELOPER EDITION

Posted on November 17, 2014 by wolfgang

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

TwitterFacebookDiggMastodonPocket
Posted in Mozilla, SUSE


OPENSUSE 11.4 HAS REACHED END OF EVERGREEN SUPPORT

Posted on September 27, 2014 by wolfgang

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


TwitterFacebookDiggMastodonPocket
Posted in SUSE


OPENSUSE CONFERENCE 2012

Posted on October 28, 2012 by wolfgang

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.

TwitterFacebookDiggMastodonPocket
Posted in SUSE


ESR AND THUNDERBIRD UNDER KDE

Posted on March 15, 2012 by wolfgang

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!)

TwitterFacebookDiggMastodonPocket
Posted in Mozilla, SUSE


MOZILLA BASED WEB AUTHORING APPLICATIONS

Posted on January 8, 2012 by wolfgang

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!

TwitterFacebookDiggMastodonPocket
Posted in Mozilla, SUSE


EVERGREEN PROJECT STATUS UPDATE

Posted on November 18, 2011 by wolfgang

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!

TwitterFacebookDiggMastodonPocket
Posted in SUSE


ON MACAW, AURORA, AND MIRAMAR

Posted on April 19, 2011 by wolfgang

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.

TwitterFacebookDiggMastodonPocket
Posted in Mozilla, SUSE


EVERGREEN STATUS AFTER SOME MONTHS

Posted on April 17, 2011 by wolfgang

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.

TwitterFacebookDiggMastodonPocket
Posted in SUSE


OPENSUSE PROJECT “EVERGREEN”

Posted on January 3, 2011 by wolfgang

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.

TwitterFacebookDiggMastodonPocket
Posted in SUSE


POST NAVIGATION

← Older posts





Amazon.de Widgets




OPENSUSE – FIREFOX PUSHLOG

Privacy Policy Proudly powered by WordPress

By continuing to use the site, you agree to the use of cookies. more information
Accept

The cookie settings on this website are set to "allow cookies" to give you the
best browsing experience possible. If you continue to use this website without
changing your cookie settings or you click "Accept" below then you are
consenting to this.

Close

✓
Thanks for sharing!
AddToAny
More…