Bug 909733 - dhcp-4.2.5-3.fc18.x86_64 missing /etc/sysconfig/dhcpd
dhcp-4.2.5-3.fc18.x86_64 missing /etc/sysconfig/dhcpd
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
18
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
:
: 924631 967457 974230 982881 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-10 14:11 EST by Richard
Modified: 2013-12-10 10:39 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-11 06:19:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Richard 2013-02-10 14:11:00 EST
Description of problem:

After upgrading from FC17 to FC18 and installing dhcp-4.2.5-3.fc18.x86_64 I can nolonger set the interface that DHCPd should listen on.

Version-Release number of selected component (if applicable):
dhcp-4.2.5-3.fc18.x86_64

How reproducible:
yum install dhcp
vi /etc/sysconfig/dhcp (file missing)

The systemd script /usr/lib/systemd/system/dhcpd.service needs this content:

[Unit]
Description=DHCPv4 Server Daemon
Documentation=man:dhcpd(8) man:dhcpd.conf(5)
After=network.target
After=time-sync.target

[Service]
EnvironmentFile=/etc/sysconfig/dhcpd
ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid $DHCPD_ARGS

[Install]
WantedBy=multi-user.target

and you also need to create /etc/sysconfig/dhcpd with this:

#DHCPD_ARGS=""

Once that happens you can set which interface the dhcpd daemon binds onto.

Thanks,

Rich
Comment 1 Jiri Popelka 2013-02-11 06:19:34 EST
(In reply to comment #0)
> vi /etc/sysconfig/dhcp (file missing)

Yes, this has been intentional change. [1]

> The systemd script /usr/lib/systemd/system/dhcpd.service needs this content:

No, it does not.
Although /etc/sysconfig/* files are easy to use, upstream systemd recommends a different approach. Their recommendation for administrators who need to reconfigure systemd .service files is to copy them from /lib/systemd/system to /etc/systemd/system and modify them there. Unit files in /etc/systemd/system override those in /lib/systemd/system if they otherwise carry the same name. 

So in your case:
$ cp /usr/lib/systemd/system/dhcpd.service /etc/systemd/system/
$ vim  /etc/systemd/system/dhcpd.service
$ ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid <your_interface_name>
$ systemctl --system daemon-reload
$ systemctl restart dhcpd.service

> Once that happens you can set which interface the dhcpd daemon binds onto.

As I already stated in bug #895475, comment #6,
dhcpd listens only on interfaces, for whose it finds subnet declaration in config file so explicitly setting which interface dhcpd binds onto should not be necessary in most cases.

[1] http://pkgs.fedoraproject.org/cgit/dhcp.git/commit/?id=c0272c7d8a9cbed9d78e9e1485d151318d6d3360
Comment 3 Tomas Hozza 2013-03-22 05:55:24 EDT
*** Bug 924631 has been marked as a duplicate of this bug. ***
Comment 4 Richard 2013-03-22 06:43:45 EDT
Was it ever announced anywhere that the use of config files in /etc/sysconfig was going to be removed??
Comment 5 Jiri Popelka 2013-03-22 06:53:55 EDT
If you mean generally, then it's been connected with 'SysV init scripts' -> 'service unit files' move (see http://0pointer.de/blog/projects/on-etc-sysinit.html)

If you mean dhcp specifically, then, we just removed it because I think most of the users should never need to add anything to dhcpd command (see the bottom of comment #1). We have a scriptlet in dhcp RPM that checks DHCPDARGS on upgrade and move it's value (if provided) from /etc/sysconfig/dhcpd to /etc/systemd/system/dhcpd.service
Comment 6 Michal Jaegermann 2013-03-26 10:58:59 EDT
(In reply to comment #5)
>> Was it ever announced anywhere that the use of config files 
>> in /etc/sysconfig was going to be removed??

> If you mean generally, then it's been connected with 'SysV init scripts' ->
> 'service unit files' move (see
> http://0pointer.de/blog/projects/on-etc-sysinit.html)

I am not sure why do you persist on claiming that while this is obviously not the case.  See 'man systemd.directives' and 'man systemd.exec' on EnvironmentFile directive and also note a wide use of that directive in various systemd unit files.

In comments to bug 850558 there is an example how this directive could be used with dhcpd.service

> If you mean dhcp specifically, then, we just removed it because I think most
> of the users should never need to add anything to dhcpd command

"Most" is very far from beeing "all".  Some of us may have more than a single network interface, for example.

As far as I am concerned this is an obvious bug and no amount of NOTABUG allegations can change that.
Comment 7 Jiri Popelka 2013-03-26 11:10:08 EDT
(In reply to comment #6)
> "Most" is very far from beeing "all".
Yes, and the minority can copy and modify the service unit.

> Some of us may have more than a
> single network interface, for example.

Michal, have you seen comment #1 ?
dhcpd listens only on interfaces, for whose it finds subnet declaration in config file. If you don't put a subnet declaration for that another interface there, dhcpd won't listen on it.

> As far as I am concerned this is an obvious bug and no amount of NOTABUG
> allegations can change that.

That's OK. So many men, so many opinions
Comment 8 Michal Jaegermann 2013-03-26 12:11:15 EDT
(In reply to comment #7)

> Yes, and the minority can copy and modify the service unit.

Just looking through various units in /lib/systemd/ if I would have to do that every time when some configuration is needed I would have a lot of things to copy, modify and maintain.  The same logic can be applied to other things as well but I thought that it is a good idea to rather avoid such mess.

> Michal, have you seen comment #1 ?

Yes, I learned quite a while ago that systemd indeed provides relatively painless ways to work around bugs like this one but this is really not the point.  I any case I am not going to loose my sleep over it.
Comment 9 Michal Jaegermann 2013-03-26 12:19:02 EDT
(In reply to comment #7)

> Yes, and the minority can copy and modify the service unit.

Just looking through various units in /lib/systemd/ if I would have to do that every time when some configuration is needed I would have a lot of things to copy, modify and maintain.  The same logic can be applied to other things as well but I thought that it is a good idea to rather avoid such mess.

> Michal, have you seen comment #1 ?

Yes, I learned quite a while ago that systemd indeed provides relatively painless ways to work around bugs like this one but this is really not the point.  I any case I am not going to loose my sleep over it.
Comment 10 Michal Jaegermann 2013-03-26 12:20:50 EDT
Sorry for a double comment.  Bugzilla is acting up and reports "proxy errors" while apparently still processing comments.
Comment 11 Tomas Hozza 2013-03-27 05:36:14 EDT
(In reply to comment #9)
> (In reply to comment #7)
> 
> > Yes, and the minority can copy and modify the service unit.
> 
> Just looking through various units in /lib/systemd/ if I would have to do
> that every time when some configuration is needed I would have a lot of
> things to copy, modify and maintain.  The same logic can be applied to other
> things as well but I thought that it is a good idea to rather avoid such
> mess.

Previously used approach with EnvironmentFile had some downsides. In dhcpd
service file there were already some option defined and $DHCPDARGS were used
after those options. So you could add some options conflicting with options
defined in service file.

I think that NOT using EnvironmentFile is way more better approach. Even if
you would want to use $DHCPDARGS you would have to edit /etc/sysconfig/dhcpd
file. Then I see no difference in editing EnvironmentFile instead of your custom
service file. You don't have to write your own service file just copy it
elsewhere and edit one line in it.

Another positive thing about using your custom service file if you need it, is
that you are immune to any changes in dhcpd service file made by the maintainer.

> > Michal, have you seen comment #1 ?
> 
> Yes, I learned quite a while ago that systemd indeed provides relatively
> painless ways to work around bugs like this one but this is really not the
> point.  I any case I am not going to loose my sleep over it.

I personally also think that this is NOTABUG. It is just different way how to
do things. From my point of view a better way.
Comment 12 Tomas Hozza 2013-05-28 02:43:15 EDT
*** Bug 967457 has been marked as a duplicate of this bug. ***
Comment 13 Tom Horsley 2013-06-13 14:09:18 EDT
> Another positive thing about using your custom service file if you need it, is
> that you are immune to any changes in dhcpd service file made by the maintainer.

Unless, of course, those changes were actually necessary for things to work right, in which case you are immune from getting a required bug fix. Specifying just command line arguments in a separate file means you don't have to suddenly gain ownership of a slew of other junk you didn't want to change.
Comment 14 Jiri Popelka 2013-06-14 03:31:48 EDT
*** Bug 974230 has been marked as a duplicate of this bug. ***
Comment 15 Jiri Popelka 2013-06-14 06:50:39 EDT
/etc/sysconfig/dhcpd strikes back

http://pkgs.fedoraproject.org/cgit/dhcp.git/commit/?id=0516f9e57d1fcf8988b8348adf8e3f388196cd07
Comment 16 Tom Horsley 2013-06-14 09:47:30 EDT
One could wonder why dhcpd spews error messages about missing subnets all over the /var/log/messages file if it is intended to operate this way.
Comment 17 Harald Reindl 2013-06-15 16:18:02 EDT
besides the fact that "return /etc/sysconfig/dhcpd back, but do NOT use it (#909733)" is *pure bullshit* http://koji.fedoraproject.org/koji/buildinfo?buildID=426621 conflicts with recent named-builds

Error: Package: 12:dhclient-4.2.5-13.fc18.x86_64 (/dhclient-4.2.5-13.fc18.x86_64)
           Requires: libdns-export.so.95()(64bit)
           Available: 32:bind-libs-lite-9.9.2-5.P1.fc18.x86_64 (fedora)
               libdns-export.so.95()(64bit)
           Available: 32:bind-libs-lite-9.9.2-10.P2.fc18.x86_64 (updates)
               libdns-export.so.95()(64bit)
           Installed: 32:bind-libs-lite-9.9.3-3.P1.fc18.x86_64 (@updates-testing)
               Not found
Error: Package: 12:dhclient-4.2.5-13.fc18.x86_64 (/dhclient-4.2.5-13.fc18.x86_64)
           Requires: libisc-export.so.92()(64bit)
           Available: 32:bind-libs-lite-9.9.2-5.P1.fc18.x86_64 (fedora)
               libisc-export.so.92()(64bit)
           Available: 32:bind-libs-lite-9.9.2-10.P2.fc18.x86_64 (updates)
               libisc-export.so.92()(64bit)
           Installed: 32:bind-libs-lite-9.9.3-3.P1.fc18.x86_64 (@updates-testing)
               Not found
Error: Package: 12:dhcp-4.2.5-13.fc18.x86_64 (/dhcp-4.2.5-13.fc18.x86_64)
           Requires: libdns-export.so.95()(64bit)
           Available: 32:bind-libs-lite-9.9.2-5.P1.fc18.x86_64 (fedora)
               libdns-export.so.95()(64bit)
           Available: 32:bind-libs-lite-9.9.2-10.P2.fc18.x86_64 (updates)
               libdns-export.so.95()(64bit)
           Installed: 32:bind-libs-lite-9.9.3-3.P1.fc18.x86_64 (@updates-testing)
               Not found
Error: Package: 12:dhcp-4.2.5-13.fc18.x86_64 (/dhcp-4.2.5-13.fc18.x86_64)
           Requires: libisc-export.so.92()(64bit)
           Available: 32:bind-libs-lite-9.9.2-5.P1.fc18.x86_64 (fedora)
               libisc-export.so.92()(64bit)
           Available: 32:bind-libs-lite-9.9.2-10.P2.fc18.x86_64 (updates)
               libisc-export.so.92()(64bit)
           Installed: 32:bind-libs-lite-9.9.3-3.P1.fc18.x86_64 (@updates-testing)
               Not found
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
Comment 18 Tomas Hozza 2013-07-10 02:43:41 EDT
*** Bug 982881 has been marked as a duplicate of this bug. ***

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