Re: [Dnsmasq-discuss] systemd service improvements

[Jan Psota]

Dnia 2016-07-05, o godz. 16:28:14
Craig Andrews  napisał(a):
[...]

I agree with _all_ you've written.

(I'm Gentoo on systemd user - 7s to boot from grub prompt to xdm.
Booted from cheap pendrive not SSD! :-)

--
Jan Psota

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] systemd service improvements

[Pali Rohár]

On Tuesday 05 July 2016 22:54:33 Kurt H Maier wrote:
> I'm not sure "me, too" is a very good reason to make this change.  I
> would instead start by convincing the distros you mention above to
> use the unit file dnsmasq already has in /contrib, and getting them
> all on the same page.  dnsmasq is a very flexible tool whose
> deployment needs to be crafted to the situation in which it is
> used.  Aside from some tuning tweaks, most of the applications you
> list are classical monoliths, where dnsmasq is very commonly used as
> part of a larger package of tools.

I fully agree, /contrib is the best place where to have it.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] systemd service improvements

[Kurt H Maier]

On Tue, Jul 05, 2016 at 04:28:14PM -0400, Craig Andrews wrote:
> On 30.06.2016 17:39, Kurt H Maier wrote:
> 
> The "make" invocation. Just like how there is a "-DHAVE_DNSSEC" option, 
> there could be a "-DHAVE_SYSTEMD" one.

What is the advantage to putting this in the makefile itself?  None of
the distributions you mentioned ship dnsmasq source directly; they ship
packages.  The packagers all have build scripts.  The build scripts put
the files into place.  Why does this need to be offloaded onto dnsmasq?

> The point isn't (necessarily) to conserve lines of code - the point is 
> to have one place for distributions/users to collaborate in order to 
> best develop and maintain this portion of the project. And each distro 
> does not (and absolutely should not) rewrite the unit file. (Would you 
> be happy if each distro patched dnsmasq? Same thing.)

Each distro *does* patch dnsmasq.  Why does modifying dnsmasq's Makefile
make it easier for all these hypothetical people to contribute than
having the unit file in /contrib?

> Right now, note how each of these distribution's systemd units are 
> different:
> Gentoo: 
> https://github.com/gentoo/gentoo/blob/cae8d8ccd7658253a336a7595796f8a9264332de/net-dns/dnsmasq/files/dnsmasq.service-r1
> Debian: 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=debian/systemd.service;h=40b8d27cba21400d8b56ecc4a85266879988911d;hb=HEAD
> Fedora: 
> http://pkgs.fedoraproject.org/cgit/rpms/dnsmasq.git/tree/dnsmasq.service
> 
> The differences are in paths (a Makefile can eliminate those difference) 
> and different security features (which are only different because some 
> distros didn't notice some security features).

Are you suggesting dnsmasq override distribution file heirarchies?  And
why do you assume packagers "didn't notice" some of the security
features?  Is it impossible they decided not to enable them for specific
reasons?

> Distros are trying to use upstream units and get upstreams to include 
> units:
> * Fedora: https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files 
> "Ideally, systemd unit files are reusable across distributions and 
> shipped with the upstream packages. Please consider working with 
> upstream to integrate the systemd files you prepare in the upstream 
> sources."
> * https://wiki.archlinux.org/index.php/DeveloperWiki:Systemd#Units "Use 
> the upstream unit files whenever they exist"

Fedora wants this because Red Hat pays the systemd maintainers, so any
time they can get other projects to do their work for them, they save
money.  Arch wants this because they're undermanned and their packagers
need all the help they can get.  I don't think either of these
conditions are universal.

> A growing number of projects (big and small) have upstreamed systemd 
> units, such as:

I'm not sure "me, too" is a very good reason to make this change.  I
would instead start by convincing the distros you mention above to use
the unit file dnsmasq already has in /contrib, and getting them all on
the same page.  dnsmasq is a very flexible tool whose deployment needs
to be crafted to the situation in which it is used.  Aside from some
tuning tweaks, most of the applications you list are classical 
monoliths, where dnsmasq is very commonly used as part of a larger
package of tools. 

In short, the only people who would save time on this are packagers, and
the only time it would really save them is not having to add a "copy
unit file" line in their build scripts.  

For example, I frequently build dnsmasq for deployment to networking
devices of all shapes and sizes; a coworker most frequently builds
dnsmasq as part of openstack or docker+kubernetes development.  In each
of those cases, we're building on a systemd-equipped machine, but we're
not installing dnsmasq as a systemwide service suitable for activation
by systemd.  I'd argue that you may find such deployments of dnsmasq are
far, far more common than you'd think.

I support your plan to get all the distro packagers on the same page,
and standardize the unit file for everyone.  I just really don't think
the dnsmasq build system is the place to do it.

khm

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] systemd service improvements

[Craig Andrews]

On 30.06.2016 17:39, Kurt H Maier wrote:

On Thu, Jun 30, 2016 at 05:19:54PM -0400, Craig Andrews wrote:

I have no argument against only installing the systemd unit if a
configure flag is specified. Many pieces of software do it that way - 
I

think the important thing is that it's available from dnsmasq. So I
rescind my thought to install it unconditionally.


What would the configure flag be passed to?


The "make" invocation. Just like how there is a "-DHAVE_DNSSEC" option, 
there could be a "-DHAVE_SYSTEMD" one.




It would take more lines of code to modify the build process to suit
this than it would just to write the unit file, and then you'd still
have to rewrite the unit file for each distro.


The point isn't (necessarily) to conserve lines of code - the point is 
to have one place for distributions/users to collaborate in order to 
best develop and maintain this portion of the project. And each distro 
does not (and absolutely should not) rewrite the unit file. (Would you 
be happy if each distro patched dnsmasq? Same thing.)




The traditional allocation of init responsibilities has always been 
such

as to free the upstream developer from the administrative minutiae by
devolving the systems management functions to those whose experience 
and

daily operations have better formed them for the performance of such
maintenance takss, thereby releasing the upstream developers for the
more task-specific duties and deliberations.


Agreed. Systemd advances the situation by making it consistent and 
easier to manage these kinds of operations by using these short, 
readable, not many lines of code files that work across distros. 
Upstream is free to not worry if distros are doing something bizarre in 
their init process; upstream can trust that all distros are doing the 
same thing, giving upstream one (signficant) less thing to worry about.


Right now, note how each of these distribution's systemd units are 
different:
Gentoo: 
https://github.com/gentoo/gentoo/blob/cae8d8ccd7658253a336a7595796f8a9264332de/net-dns/dnsmasq/files/dnsmasq.service-r1
Debian: 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=debian/systemd.service;h=40b8d27cba21400d8b56ecc4a85266879988911d;hb=HEAD
Fedora: 
http://pkgs.fedoraproject.org/cgit/rpms/dnsmasq.git/tree/dnsmasq.service


The differences are in paths (a Makefile can eliminate those difference) 
and different security features (which are only different because some 
distros didn't notice some security features).


Distros are trying to use upstream units and get upstreams to include 
units:
* Fedora: https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files 
"Ideally, systemd unit files are reusable across distributions and 
shipped with the upstream packages. Please consider working with 
upstream to integrate the systemd files you prepare in the upstream 
sources."
* https://wiki.archlinux.org/index.php/DeveloperWiki:Systemd#Units "Use 
the upstream unit files whenever they exist"


A growing number of projects (big and small) have upstreamed systemd 
units, such as:

* bluez / Linux Bluetooth
* Tor
* MariaDB
* netdata
* lirc
* php
* memcached



In short, I still think a generic unit file in /contrib is best, and
people who want to use it will be okay if they have to copy it where
their OS wants it.  dnsmasq runs in a lot of places systemd doesn't, so
systemd is not to be taken as given.

khm


I agree systemd isn't a given (again, my apologies once again for 
suggesting that units are installed unconditionally). However, the file 
does need to be customized for install paths and features (ex -DHAVE_) 
which the Makefile already does, so the file shouldn't in /contrib - I 
think it should be with the rest of the source, and conditionally 
processed and installed to the correct location by the Makefile.


I modified the Makefile and added the systemd unit. I'm not a Make 
expert, so I apologize for the errors I've very likely made. With this 
patch, you can run (for example):

make COPTS="-DHAVE_DBUS -DHAVE_SYSTEMD" all install
and you'll get a dnsmasq.system file created, customized, and installed 
to the correct location (for any distribution). While I was in there, I 
also made the Makefile (conditionally, if -DHAVE_DBUS is provided) 
install the dbus service configuration.


I'm eager to hear thoughts about this approach.

Thanks,
~Craigdiff --git a/.gitignore b/.gitignore
index 23f1148..3bfdebb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
+src/dnsmasq.service
 src/*.o
 src/*.mo
 src/dnsmasq.pot
diff --git a/Makefile b/Makefile
index dd0513b..624047c 100644
--- a/Makefile
+++ b/Makefile
@@ -51,6 +51,8 @@ top!=pwd
 # GNU make way.
 top?=$(CURDIR)
 
+systemd_system_unit_dir = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_SYSTEMD $(PKG_CONFIG) --variable=systemdsystemunitdir systemd`
+dbus_sysconfdir = `echo $(COPTS) | $(top)/bld/pkg-wrapper HAVE_DBUS $(PKG_CONFIG) --variable=sysconfdir dbus-1`
 dbus_cflags =   `echo $(COPTS) | 

Re: [Dnsmasq-discuss] dnsmasq to provide public DNS service

[Albert ARIBAUD]

Hi Tong,

Le Tue, 5 Jul 2016 00:42:25 + (UTC)
T o n g  a écrit:

> > 1) Does your dnsmasq host have access to the Internet?
> > 
> > 2) Have you configured your Internet access so that DNS requests
> > incoming from the outside are routed to your dnsmasq host?  
> 
> Yeah, those "out-side" factors, I know how to control, and they are 
> working fine. For example, I have use `listen-address=192.168.1.1`
> before to provide DNS service for my own home network, and it works
> fine. 

Yes, listening to a LAN address allows serving client on the LAN. But
this does absolutely not mean that conditions 1 and 2 above are met
and that clients from the Net can be served.

> This box I'm configuring, it has its own public IP, not on
> 192.168.x.x. The SSH, DNS, etc ports are open to the would as well. 

This piece of information raises a lot of questions. Could you please
anwer by 'yes' or 'no' to the following?

1. Does the "box" you are referring to run the dnsmasq you are trying
to configure?

2. Is this box also the gateway from your LAN to the Internet?

3. Does it hace two network interfaces, one facing the Internet and one
facing the LAN?

> Oh, should I listen to its Gateway IP instead of 0.0.0.0?

You should not specifiy listen-address *at all* unless you want
your dnsmasq to serve *only* your LAN or to serve *only* the Net.

You should not even specify any interface= option.

> The outside world is not involved yet -- I haven't been able to make 
> itself work first. 

Before making dnsmasq work with clients from outside your LAN, you need
to verify that your "box" meets conditions 1 and 2 above.

Let's start with condition 1. You can check it by running a traceroute
from your "box" to some known internet host (e.g. google.com). What
does such a traceroute print out?

Amicalement,
-- 
Albert.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss