Bug 909733

(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

http://0pointer.de/blog/projects/on-etc-sysinit.html

*** Bug 924631 has been marked as a duplicate of this bug. ***

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)

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

(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.

(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

(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.

(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.

Sorry for a double comment.  Bugzilla is acting up and reports "proxy errors" while apparently still processing comments.

(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.

*** Bug 967457 has been marked as a duplicate of this bug. ***

> 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.

*** Bug 974230 has been marked as a duplicate of this bug. ***

/etc/sysconfig/dhcpd strikes back

http://pkgs.fedoraproject.org/cgit/dhcp.git/commit/?id=0516f9e57d1fcf8988b8348adf8e3f388196cd07

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.

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

*** Bug 982881 has been marked as a duplicate of this bug. ***