dhcp-4 allows the use of a DHCPv6 server. This requires running another server instance if you wish to allow DHCPv4 as well. The current init script does not easily multiplex. This patch should, allowing you to ln -s dhcpd /etc/init.d/dhcpd6 and then creating /etc/dhcp/dhcpd6.conf.
Created attachment 165992 [details, diff] Allow multiplexing of dhcpd init script
Created attachment 188516 [details, diff] Patch to enable ISC DHCP multiplexing (starting) - for IPv4 and IPv6 usage Hi guys, this issue is hanging around for some time now, what's up? I'd like to bump this bug and add a new version of the suggested patch (though modified, I hope you'll like it.) Also, could the maintainer please drop a message on it? Thank you very much.
(In reply to comment #2) > Created an attachment (id=188516) [edit] > Patch to enable ISC DHCP multiplexing (starting) - for IPv4 and IPv6 usage Please don't use sed (or any external tool) in global scope. You want something like so case "${SVCNAME}" in *6*) DHCPD_OPTS="${DHCPD_OPTS} -6" *) DHCPD_OPTS="${DHCPD_OPTS} -4" esac Also, you cannot assume ipv6 just because of the existance of the number 6 in the SVCNAME so I would argue that it's wrong anyway.
Hi Roy, (In reply to comment #3) > Please don't use sed (or any external tool) in global scope. Sorry, I didn't know that as of now. Due to the fact that sed has been used in this eBuild as well before (have a look at the get_var function), I have assumed that it is safe to use. Of course, your suggestion is good, too. But coming to think of "global scope", the check is at the wrong position anyways. It really should be moved into start(), because it's only used in this function. > Also, you cannot assume ipv6 just because of the existance of the number 6 in > the SVCNAME so I would argue that it's wrong anyway. Well, why not? It's a quick, easy and reliable way to check for IPv6 usage. When running dhcpd in IPv6 mode, it is natural to me to specifiy a six *somewhere* in the symbolic link, no? "Hardcoding"/checking for i.e. "dhcp6" is no better way, because some people may actually want to call the symlink "dhcpv6" or something like this, you'll get it... To me this has been a question of freedom. Of course you can also check for SVCNAME being "dhcp6", but I do like the generic way. I am awaiting your thoughts on this matter. :) --Ionic
(In reply to comment #4) > But coming to think of "global scope", the check is at the wrong position > anyways. It really should be moved into start(), because it's only used in this > function. Correct > > Also, you cannot assume ipv6 just because of the existance of the number 6 in > > the SVCNAME so I would argue that it's wrong anyway. > Well, why not? It's a quick, easy and reliable way to check for IPv6 usage. > When running dhcpd in IPv6 mode, it is natural to me to specifiy a six > *somewhere* in the symbolic link, no? > "Hardcoding"/checking for i.e. "dhcp6" is no better way, because some people > may actually want to call the symlink "dhcpv6" or something like this, you'll > get it... > > To me this has been a question of freedom. Of course you can also check for > SVCNAME being "dhcp6", but I do like the generic way. > > I am awaiting your thoughts on this matter. :) /etc/init.d/dhcp1 /etc/init.d/dhcp2 /etc/init.d/dhcp3 /etc/init.d/dhcp4 /etc/init.d/dhcp5 /etc/init.d/dhcp7 /etc/init.d/dhcp8 Using your idea, dhcp6 is ipv6. So it must follow that dhcp4 is ipv4 and the others are unknown. After working with stuff being implied by a fixed name (think interface names) and then the user being given the ability to change the name, every inference is wrong. You can call a bonded interface br0 to confuse things. Whilst silly, it's possible and has happened. So no, interering a state or action based on a user defined name hazardous and should be avoided.
(In reply to comment #5) > (In reply to comment #4) > > But coming to think of "global scope", the check is at the wrong position > > anyways. It really should be moved into start(), because it's only used in this > > function. > > Correct ACK :) > > > Also, you cannot assume ipv6 just because of the existance of the number 6 in > > > the SVCNAME so I would argue that it's wrong anyway. > > Well, why not? It's a quick, easy and reliable way to check for IPv6 usage. > > When running dhcpd in IPv6 mode, it is natural to me to specifiy a six > > *somewhere* in the symbolic link, no? > > "Hardcoding"/checking for i.e. "dhcp6" is no better way, because some people > > may actually want to call the symlink "dhcpv6" or something like this, you'll > > get it... > > > > To me this has been a question of freedom. Of course you can also check for > > SVCNAME being "dhcp6", but I do like the generic way. > > > > I am awaiting your thoughts on this matter. :) > > /etc/init.d/dhcp1 > /etc/init.d/dhcp2 > /etc/init.d/dhcp3 > /etc/init.d/dhcp4 > /etc/init.d/dhcp5 > /etc/init.d/dhcp7 > /etc/init.d/dhcp8 > > Using your idea, dhcp6 is ipv6. So it must follow that dhcp4 is ipv4 and the > others are unknown. > > After working with stuff being implied by a fixed name (think interface names) > and then the user being given the ability to change the name, every inference > is wrong. You can call a bonded interface br0 to confuse things. Whilst silly, > it's possible and has happened. > > So no, interering a state or action based on a user defined name hazardous and > should be avoided. > Thus your suggestion would be using a unique name like "dhcpv6" or something similar? --Ionic
(In reply to comment #6) > Thus your suggestion would be using a unique name like "dhcpv6" or something > similar? No, my suggestion is don't infer anything from the name - the user has to explicitly request DHCPv6 support in another variable.
included Roy's patch with dhcp-4.2.1
