Bug 491152 - MaraDNS startup script does not allow zoneserver
MaraDNS startup script does not allow zoneserver
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: maradns (Show other bugs)
10
All Linux
low Severity low
: ---
: ---
Assigned To: Michael Fleming
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-19 11:55 EDT by Simone Deponti
Modified: 2009-03-20 09:17 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-20 09:17:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/init.d/maradns (4.36 KB, application/x-sh)
2009-03-19 11:55 EDT, Simone Deponti
no flags Details
/etc/sysconfig/maradns (387 bytes, application/x-sh)
2009-03-19 11:56 EDT, Simone Deponti
no flags Details

  None (edit)
Description Simone Deponti 2009-03-19 11:55:30 EDT
Created attachment 335878 [details]
/etc/init.d/maradns

Description of problem:
The standard MaraDNS startup script (/etc/init.d/maradns) has the following shortcomings:
* Does not allow to start the zoneserver (zone transfer utility)
* Has configuration parameters embed into the script and not changeable without modifying /etc/init.d/maradns

Version-Release number of selected component (if applicable):
1.3.07.09

How reproducible:
The first requirement is to install the maradns package.
It is reproducible on all platforms.

Steps to Reproduce:
1. Edit /etc/mararc to serve an example zone and allow zone transfers through zone_transfer_acl
2. Copy the configuration file to /etc/mararc.1 to serve a different zone on a different IP
3. Restart MaraDNS using /sbin/service maradns restart (or /sbin/service maradns start if not started yet)
4. Type ps -elyf | grep zoneserver
5. Type ps -elyf | grep maradns
  
Actual results:
The only process matching "zoneserver" is the grep process itself. Also there is only one maradns process (instead of two).

Expected results:
There should be atleast one /usr/sbin/zoneserver process running, and two maradns processes serving different zones on different IPs.

Additional info:
The utility of having MaraDNS serve different zones on different IPs (subnets) is useful especially when the DNS server actually sits on two networks: the name resolution will then be dependant on the network from which the request comes (this feature is supported by BIND).
This can currently be achieved with two configuration files and with editing the MARARCS variable in /etc/init.d/maradns

Attached are two files, one if /etc/sysconfig/maradns and the other /etc/init.d/maradns, that solve those shortcomings by adding a sysconfig editable options (MARARCS and ZONECONFIGFLAG) and allows to also start the zoneserver by setting ZONECONIGFLAG to "on" inside /etc/sysconfig/maradns
Comment 1 Simone Deponti 2009-03-19 11:56:15 EDT
Created attachment 335879 [details]
/etc/sysconfig/maradns
Comment 2 Michael Fleming 2009-03-20 09:17:32 EDT
1) The /etc/init.d/maradns init file will not start zoneserver - nor should it. That's what the /etc/init.d/maradns-zoneserver file is for, and it's perfectly functional, if somewhat inelegant from some points of view - I personally can see why it's done however (keeping the startup discrete fits with having discrete processes for auth vs. recursive/caching, so there's a level of consistency there. YMMV). NOTABUG

2) Breaking out the variables set in the init file to a sysconfig one would be useful and more in line with how RH/Fedora does things. I'll slot it in my "to-do" for the package but it's not a high priority (and I'd need to consider upgrades for people that have edited the init file to set them..)

There's nothing in the package stopping you from doing what you want to do, it's just not ideally done at this point.

Note You need to log in before you can comment on or make changes to this bug.