[Bug 236584] netmap does not work with VLAN on em driver (was: ifconfig does not honor disabling vlanhwtag)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236584 Murat changed: What|Removed |Added Summary|netmap does not work with |netmap does not work with |VLAN on em driver (was: |VLAN on em driver (was: |ifconfig does not honor |ifconfig does not honor |disabling vlanhwcsum) |disabling vlanhwtag) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 236584] netmap does not work with VLAN on em driver (was: ifconfig does not honor disabling vlanhwcsum)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236584 --- Comment #5 from Murat --- Vincenzo, It should be as stated in the netmap ticket: vlanhwtag -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 236584] netmap does not work with VLAN on em driver (was: ifconfig does not honor disabling vlanhwcsum)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236584 Vincenzo Maffione changed: What|Removed |Added CC||vmaffi...@freebsd.org --- Comment #4 from Vincenzo Maffione --- Review created https://reviews.freebsd.org/D25286 However, it's not clear if this is about the vlanhwcsum flag or the vlanhwtag flag (as stated on the github). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 236584] netmap does not work with VLAN on em driver (was: ifconfig does not honor disabling vlanhwcsum)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236584 Murat changed: What|Removed |Added Summary|em driver does not honor|netmap does not work with |disabling vlanhwcsum|VLAN on em driver (was: ||ifconfig does not honor ||disabling vlanhwcsum) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 236584] em driver does not honor disabling vlanhwcsum
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236584 --- Comment #3 from Murat --- Related netmap(4) PR: https://github.com/luigirizzo/netmap/issues/703 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 236584] em driver does not honor disabling vlanhwcsum
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236584 Murat changed: What|Removed |Added Version|11.2-STABLE |12.1-RELEASE Keywords||IntelNetworking, easy, ||patch CC||mu...@sunnyvalley.io --- Comment #2 from Murat --- Hi, It looks like this bug effects quite many FreeBSD versions. This was present in FreeBSD 11.x and I could confirm this is present in FreeBSD 12.x Fix looks very easy. Impact will be huge since em(4) driver is being used by many hypervisors (QEMU, Proxmox, VirtualBox, VMware) and you can find this adapter oboard in many COTS hardware. Most obvious effect is you cannot run netmap(4) on em VLAN interfaces. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 245981] BCM57414 not initializing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245981 --- Comment #9 from Ian Smith --- Testing within Ubuntu 18.04 LTS is mapping the queues correctly, although it is loading the driver modules within the kernel for FreeBSD it does not allow for mapping it? Is there any additional steps we can take to identify or solve this allocation of queues? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 236584] em driver does not honor disabling vlanhwcsum
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236584 --- Comment #1 from Murat --- Created attachment 215584 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=215584=edit patch to fix ifconfig vlanhwcsum parameter handling for em -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: unbound and (isc) dhcpd startup order
On 15/06/20 14:47, Andriy Gapon wrote: > On 15/06/2020 14:48, Eugene Grosbein wrote: >> 15.06.2020 13:10, Andriy Gapon wrote: >> >>> I am configuring a small LAN -- mostly a gateway / router for it -- and I am >>> using unbound for a local DNS and isc-dhcp44-server for DHCP. >>> I have a few hosts with static IP addresses (for various reasons). >>> So, in unbound.conf I have an entry like >>> local-data: "hipster.home.arpa. IN A 192.168.0.222" >> >> Consider using /etc/hosts in addition to DNS to solve chicken/egg problem. >> >> > > Having the same IP in more than one place (on the router) is the thing that > I'd > like to avoid in the first place. Otherwise, there is no problem putting it > in > hdcpd.conf. > A secondary DNS server could also help, unless both are rebooted at the same time. -- Guido Falsi ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: unbound and (isc) dhcpd startup order
"Rodney W. Grimes" writes: > Um, yea, I guess the bigger question is why is the port different > than the base system in this respect? The the unbound port existed years before it was decided that unbound should replace bind in the base system. If you want the port to change, send a PR for the port so I won't forget this. > > I would expect unbound to be the same, as unbound_local in almost > every respect, especially with respect to its startup sequencing, > providers and requires. Not really. For a start, the port has a different default configuration then the one in base. > > > > I seen no problem in adding a BEFORE: NETWORKING to the port, covering > > > a larger number of casses than your narrow BEFORE: dhcpd. I don't see a problem either. > > >> On a related note, unbound rc script provides "unbound" service. > > >> I think that maybe it should provide something more generic such as > > >> "nameserver" > > >> or "dns-server" (not sure if there is an established name for that). > > >> The reason I am saying this is that, IMO, if unbound is replaced with > > >> some other > > >> name server implementation the rc dependency chains should stay the > > >> same. > > > > > > I do not see anything in the base system that uses unbound or > > > local_unbound > > > service name, so this looks like it could be straightforward, though > > > there > > > may be some ports that have use of this token. > > > > > > For the blue bikeshed I find that "server" is just noise in the token > > > and that "dns" already has "s" for system, so just "dns" is good with me > > > :-) > > > > That's a good point. I don't agree. The term dns is too generic. People are often running dfferent nameservers on the same machine, as example: authoritative and nonauthoritative (e.g. nsd & unbound). Regards, jaap ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 247242] after upgrade, DHCP fails with: ip length 576 disagrees with bytes received 574
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247242 Mark Johnston changed: What|Removed |Added Status|In Progress |Closed CC||ma...@freebsd.org Resolution|--- |FIXED --- Comment #3 from Mark Johnston --- Thanks for the report. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: unbound and (isc) dhcpd startup order
On 2020-06-15 16:06, DutchDaemon - FreeBSD Forums Administrator wrote:
> BIND serves my domains authoritatively, but does no recursive queries
> for anyone.
>
> Unbound serves the local resolving tasks.
>
> --- /etc/rc.conf:
>
> named_enable="YES"
> unbound_enable="YES"
>
> --- /usr/local/etc/named.conf:
>
> listen-on { xx.22.108.xx; };
>
> --- /usr/local/etc/unbound/unbound.conf:
>
> interface: 127.0.0.1
>
> --- /etc/resolv.conf:
>
> nameserver 127.0.0.1
>
>
> Works absolutely fine.
>
>
To wit:
# sockstat -l4p53
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
unbound unbound 99163 3 udp4 127.0.0.1:53 *:*
unbound unbound 99163 4 tcp4 127.0.0.1:53 *:*
bind named 56098 36 udp4 84.22.108.242:53 *:*
bind named 56098 37 udp4 84.22.108.242:53 *:*
bind named 56098 38 tcp4 84.22.108.242:53 *:*
bind named 56098 39 tcp4 84.22.108.242:53 *:*
bind named 56098 40 tcp4 84.22.108.242:53 *:*
signature.asc
Description: OpenPGP digital signature
Re: unbound and (isc) dhcpd startup order
On 2020-06-15 15:58, Rodney W. Grimes wrote:
> named is specifically the name of the binary included in the bind
> product, which included the resolver stub, named, and some other
> support utilities like rndc and nslookup.
>
> It would make since to unify these, though that is going to take
> some cafeful thought and co-ordination as to not break peoples
> running systems. I suspect the ports conflict stuff is keeping
> one from installing unbound, and bind at the same time, arguable
> wrong as one should be able to install both, but only run one
> at a time, or even run both on different ports.
Certainly how I'm doing it:
BIND serves my domains authoritatively, but does no recursive queries
for anyone.
Unbound serves the local resolving tasks.
--- /etc/rc.conf:
named_enable="YES"
unbound_enable="YES"
--- /usr/local/etc/named.conf:
listen-on { xx.22.108.xx; };
--- /usr/local/etc/unbound/unbound.conf:
interface: 127.0.0.1
--- /etc/resolv.conf:
nameserver 127.0.0.1
Works absolutely fine.
signature.asc
Description: OpenPGP digital signature
Re: unbound and (isc) dhcpd startup order
> On 15/06/2020 15:57, Rodney W. Grimes wrote:
> >>
> >> I am configuring a small LAN -- mostly a gateway / router for it -- and I
> >> am
> >> using unbound for a local DNS and isc-dhcp44-server for DHCP.
> >> I have a few hosts with static IP addresses (for various reasons).
> >> So, in unbound.conf I have an entry like
> >> local-data: "hipster.home.arpa. IN A 192.168.0.222"
> >> and in dhcpd.conf have:
> >> host hipster {
> >>
> >>
> >> hardware ethernet 40:74:e0:xx:xx:xx;
> >>
> >>
> >> fixed-address hipster.home.arpa;
> >>
> >>
> >> }
> >>
> >> I am using a DNS name to avoid hardcoding the same IP address twice.
> >> But obviously this depends on the local DNS server starting before the HDCP
> >> server if they are on the same host / router.
> >> It seems that at the moment there is nothing to ensure that order.
> >>
> >> For the moment I modified rc.d/unbound to add this line:
> >> # BEFORE: dhcpd
> >
> >>From looking at /etc/rc.d/local_unbound we see:
> > # PROVIDE: local_unbound
> > # REQUIRE: FILESYSTEMS defaultroute netwait resolv
> > # BEFORE: NETWORKING
> > # KEYWORD: shutdown
> >
> > What makes it work for that case is the BEFORE: NETWORKING is that
> > line missing for the port version?
>
> Yes, it is:
> # PROVIDE: unbound
> # REQUIRE: SERVERS cleanvar
> # KEYWORD: shutdown
>
> If we add BEFORE: NETWORKING then REQUIRE will also have to be adjusted as
> it's
> impossible to be before NETWORKING and after SERVERS.
Um, yea, I guess the bigger question is why is the port different
than the base system in this respect?
I would expect unbound to be the same, as unbound_local in almost
every respect, especially with respect to its startup sequencing,
providers and requires.
> >> I am not sure if this is the best solution and it's something that can be
> >> included into the port.
> >
> > I think that DNS needs to be started before more than just dhcpd,
> > so this is just 1 of many possible cases. This can also be issues
> > with almost any network stuff that wants to do stuff by DNS value,
> > including the networkself. DNS creates a chicken/egg problem in
> > that you may, or may not need the network to resolve names, I have
> > always hated that aspect of it. Modern tooling can help, you use
> > stuff to build your /etc/rc config files that can me run while the
> > network is up and functional so that this entering IP addresses in
> > N places is less painful.
> >
> > I seen no problem in adding a BEFORE: NETWORKING to the port, covering
> > a larger number of casses than your narrow BEFORE: dhcpd.
>
> I agree.
> I hope it doesn't break any currently working configurations too.
I have no idea how to hunt through ports looking for this. I
suppose find all ports that need unbound and see what there startup
scripts look like.
> >> On a related note, unbound rc script provides "unbound" service.
> >> I think that maybe it should provide something more generic such as
> >> "nameserver"
> >> or "dns-server" (not sure if there is an established name for that).
> >> The reason I am saying this is that, IMO, if unbound is replaced with some
> >> other
> >> name server implementation the rc dependency chains should stay the same.
> >
> > I do not see anything in the base system that uses unbound or local_unbound
> > service name, so this looks like it could be straightforward, though there
> > may be some ports that have use of this token.
> >
> > For the blue bikeshed I find that "server" is just noise in the token
> > and that "dns" already has "s" for system, so just "dns" is good with me :-)
>
> That's a good point.
> I've just checked bind ports and they use PROVIDE: named
> Not sure if "named" here is a bind specific name or a generic one.
named is specifically the name of the binary included in the bind
product, which included the resolver stub, named, and some other
support utilities like rndc and nslookup.
It would make since to unify these, though that is going to take
some cafeful thought and co-ordination as to not break peoples
running systems. I suspect the ports conflict stuff is keeping
one from installing unbound, and bind at the same time, arguable
wrong as one should be able to install both, but only run one
at a time, or even run both on different ports.
> --
> Andriy Gapon
--
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 246629] Multicast stack problem - MRT_ADD_VIF Address already in use
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246629 Joel S changed: What|Removed |Added CC||joel.sam...@hotmail.com --- Comment #5 from Joel S --- Created this account simply to mention this is also causing me some issues as well. Been trying to get my multicast-traffic to work correctly on pfsense 2.5.0 snapshot for the last month without luck. Their related issue can be found here: https://redmine.pfsense.org/issues/7727 Any ideas would be appreciated. I also have the mentioned errors found in these bug reports. Just wanted to advise and be able to keep an eye on any possible patches. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: unbound and (isc) dhcpd startup order
On 15/06/2020 15:57, Rodney W. Grimes wrote:
>>
>> I am configuring a small LAN -- mostly a gateway / router for it -- and I am
>> using unbound for a local DNS and isc-dhcp44-server for DHCP.
>> I have a few hosts with static IP addresses (for various reasons).
>> So, in unbound.conf I have an entry like
>> local-data: "hipster.home.arpa. IN A 192.168.0.222"
>> and in dhcpd.conf have:
>> host hipster {
>>
>>
>> hardware ethernet 40:74:e0:xx:xx:xx;
>>
>>
>> fixed-address hipster.home.arpa;
>>
>>
>> }
>>
>> I am using a DNS name to avoid hardcoding the same IP address twice.
>> But obviously this depends on the local DNS server starting before the HDCP
>> server if they are on the same host / router.
>> It seems that at the moment there is nothing to ensure that order.
>>
>> For the moment I modified rc.d/unbound to add this line:
>> # BEFORE: dhcpd
>
>>From looking at /etc/rc.d/local_unbound we see:
> # PROVIDE: local_unbound
> # REQUIRE: FILESYSTEMS defaultroute netwait resolv
> # BEFORE: NETWORKING
> # KEYWORD: shutdown
>
> What makes it work for that case is the BEFORE: NETWORKING is that
> line missing for the port version?
Yes, it is:
# PROVIDE: unbound
# REQUIRE: SERVERS cleanvar
# KEYWORD: shutdown
If we add BEFORE: NETWORKING then REQUIRE will also have to be adjusted as it's
impossible to be before NETWORKING and after SERVERS.
>> I am not sure if this is the best solution and it's something that can be
>> included into the port.
>
> I think that DNS needs to be started before more than just dhcpd,
> so this is just 1 of many possible cases. This can also be issues
> with almost any network stuff that wants to do stuff by DNS value,
> including the networkself. DNS creates a chicken/egg problem in
> that you may, or may not need the network to resolve names, I have
> always hated that aspect of it. Modern tooling can help, you use
> stuff to build your /etc/rc config files that can me run while the
> network is up and functional so that this entering IP addresses in
> N places is less painful.
>
> I seen no problem in adding a BEFORE: NETWORKING to the port, covering
> a larger number of casses than your narrow BEFORE: dhcpd.
I agree.
I hope it doesn't break any currently working configurations too.
>> On a related note, unbound rc script provides "unbound" service.
>> I think that maybe it should provide something more generic such as
>> "nameserver"
>> or "dns-server" (not sure if there is an established name for that).
>> The reason I am saying this is that, IMO, if unbound is replaced with some
>> other
>> name server implementation the rc dependency chains should stay the same.
>
> I do not see anything in the base system that uses unbound or local_unbound
> service name, so this looks like it could be straightforward, though there
> may be some ports that have use of this token.
>
> For the blue bikeshed I find that "server" is just noise in the token
> and that "dns" already has "s" for system, so just "dns" is good with me :-)
That's a good point.
I've just checked bind ports and they use PROVIDE: named
Not sure if "named" here is a bind specific name or a generic one.
--
Andriy Gapon
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: unbound and (isc) dhcpd startup order
>
> I am configuring a small LAN -- mostly a gateway / router for it -- and I am
> using unbound for a local DNS and isc-dhcp44-server for DHCP.
> I have a few hosts with static IP addresses (for various reasons).
> So, in unbound.conf I have an entry like
> local-data: "hipster.home.arpa. IN A 192.168.0.222"
> and in dhcpd.conf have:
> host hipster {
>
>
> hardware ethernet 40:74:e0:xx:xx:xx;
>
>
> fixed-address hipster.home.arpa;
>
>
> }
>
> I am using a DNS name to avoid hardcoding the same IP address twice.
> But obviously this depends on the local DNS server starting before the HDCP
> server if they are on the same host / router.
> It seems that at the moment there is nothing to ensure that order.
>
> For the moment I modified rc.d/unbound to add this line:
> # BEFORE: dhcpd
>From looking at /etc/rc.d/local_unbound we see:
# PROVIDE: local_unbound
# REQUIRE: FILESYSTEMS defaultroute netwait resolv
# BEFORE: NETWORKING
# KEYWORD: shutdown
What makes it work for that case is the BEFORE: NETWORKING is that
line missing for the port version?
> I am not sure if this is the best solution and it's something that can be
> included into the port.
I think that DNS needs to be started before more than just dhcpd,
so this is just 1 of many possible cases. This can also be issues
with almost any network stuff that wants to do stuff by DNS value,
including the networkself. DNS creates a chicken/egg problem in
that you may, or may not need the network to resolve names, I have
always hated that aspect of it. Modern tooling can help, you use
stuff to build your /etc/rc config files that can me run while the
network is up and functional so that this entering IP addresses in
N places is less painful.
I seen no problem in adding a BEFORE: NETWORKING to the port, covering
a larger number of casses than your narrow BEFORE: dhcpd.
>
> On a related note, unbound rc script provides "unbound" service.
> I think that maybe it should provide something more generic such as
> "nameserver"
> or "dns-server" (not sure if there is an established name for that).
> The reason I am saying this is that, IMO, if unbound is replaced with some
> other
> name server implementation the rc dependency chains should stay the same.
I do not see anything in the base system that uses unbound or local_unbound
service name, so this looks like it could be straightforward, though there
may be some ports that have use of this token.
For the blue bikeshed I find that "server" is just noise in the token
and that "dns" already has "s" for system, so just "dns" is good with me :-)
> Thanks!
> --
> Andriy Gapon
--
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: unbound and (isc) dhcpd startup order
On 15/06/2020 14:48, Eugene Grosbein wrote: > 15.06.2020 13:10, Andriy Gapon wrote: > >> I am configuring a small LAN -- mostly a gateway / router for it -- and I am >> using unbound for a local DNS and isc-dhcp44-server for DHCP. >> I have a few hosts with static IP addresses (for various reasons). >> So, in unbound.conf I have an entry like >> local-data: "hipster.home.arpa. IN A 192.168.0.222" > > Consider using /etc/hosts in addition to DNS to solve chicken/egg problem. > > Having the same IP in more than one place (on the router) is the thing that I'd like to avoid in the first place. Otherwise, there is no problem putting it in hdcpd.conf. -- Andriy Gapon ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: unbound and (isc) dhcpd startup order
On Mon, Jun 15, 2020 at 09:10:18AM +0300, Andriy Gapon wrote:
>
> I am configuring a small LAN -- mostly a gateway / router for it -- and I am
> using unbound for a local DNS and isc-dhcp44-server for DHCP.
> I have a few hosts with static IP addresses (for various reasons).
> So, in unbound.conf I have an entry like
> local-data: "hipster.home.arpa. IN A 192.168.0.222"
> and in dhcpd.conf have:
> host hipster {
>
>
> hardware ethernet 40:74:e0:xx:xx:xx;
>
>
> fixed-address hipster.home.arpa;
>
>
> }
>
> I am using a DNS name to avoid hardcoding the same IP address twice.
> But obviously this depends on the local DNS server starting before the HDCP
> server if they are on the same host / router.
> It seems that at the moment there is nothing to ensure that order.
>
> For the moment I modified rc.d/unbound to add this line:
> # BEFORE: dhcpd
> I am not sure if this is the best solution and it's something that can be
> included into the port.
>
> On a related note, unbound rc script provides "unbound" service.
> I think that maybe it should provide something more generic such as
> "nameserver"
> or "dns-server" (not sure if there is an established name for that).
> The reason I am saying this is that, IMO, if unbound is replaced with some
> other
> name server implementation the rc dependency chains should stay the same.
>
> Thanks!
> --
> Andriy Gapon
It might not be the exact answer you're looking for, but you might get
some idea. I run isc-dhcpd inside CBSD jail and CBSD is started after
local_unbound. For most of my needs, CBSD's b_order (short for boot
order) works nicely, so if jail is an option for you, you might consider
having services in jails and then use your jail manager (does jail.conf
boots jails in order they appear in .conf file or is otherwise able to
sort jail startups?) to force jail startup order.
Regards,
meka
signature.asc
Description: PGP signature
Re: unbound and (isc) dhcpd startup order
15.06.2020 13:10, Andriy Gapon wrote: > I am configuring a small LAN -- mostly a gateway / router for it -- and I am > using unbound for a local DNS and isc-dhcp44-server for DHCP. > I have a few hosts with static IP addresses (for various reasons). > So, in unbound.conf I have an entry like > local-data: "hipster.home.arpa. IN A 192.168.0.222" Consider using /etc/hosts in addition to DNS to solve chicken/egg problem. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: unbound and (isc) dhcpd startup order
On Mon, 15 Jun 2020 09:10:18 +0300 Andriy Gapon a...@freebsd.org said
I am configuring a small LAN -- mostly a gateway / router for it -- and I am
using unbound for a local DNS and isc-dhcp44-server for DHCP.
I have a few hosts with static IP addresses (for various reasons).
So, in unbound.conf I have an entry like
local-data: "hipster.home.arpa. IN A 192.168.0.222"
and in dhcpd.conf have:
host hipster {
hardware ethernet 40:74:e0:xx:xx:xx;
fixed-address hipster.home.arpa;
}
I am using a DNS name to avoid hardcoding the same IP address twice.
But obviously this depends on the local DNS server starting before the HDCP
server if they are on the same host / router.
It seems that at the moment there is nothing to ensure that order.
Isn't there something like a "start late" available in rc.conf rc(8)? That
would then permit starting your local unbound prior to DHCPD?
Maybe that allow you to achieve your desired results?
For the moment I modified rc.d/unbound to add this line:
# BEFORE: dhcpd
I am not sure if this is the best solution and it's something that can be
included into the port.
On a related note, unbound rc script provides "unbound" service.
I think that maybe it should provide something more generic such as
"nameserver"
or "dns-server" (not sure if there is an established name for that).
The reason I am saying this is that, IMO, if unbound is replaced with some
other
name server implementation the rc dependency chains should stay the same.
Thanks!
--
Andriy Gapon
--Chris
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
unbound and (isc) dhcpd startup order
I am configuring a small LAN -- mostly a gateway / router for it -- and I am
using unbound for a local DNS and isc-dhcp44-server for DHCP.
I have a few hosts with static IP addresses (for various reasons).
So, in unbound.conf I have an entry like
local-data: "hipster.home.arpa. IN A 192.168.0.222"
and in dhcpd.conf have:
host hipster {
hardware ethernet 40:74:e0:xx:xx:xx;
fixed-address hipster.home.arpa;
}
I am using a DNS name to avoid hardcoding the same IP address twice.
But obviously this depends on the local DNS server starting before the HDCP
server if they are on the same host / router.
It seems that at the moment there is nothing to ensure that order.
For the moment I modified rc.d/unbound to add this line:
# BEFORE: dhcpd
I am not sure if this is the best solution and it's something that can be
included into the port.
On a related note, unbound rc script provides "unbound" service.
I think that maybe it should provide something more generic such as "nameserver"
or "dns-server" (not sure if there is an established name for that).
The reason I am saying this is that, IMO, if unbound is replaced with some other
name server implementation the rc dependency chains should stay the same.
Thanks!
--
Andriy Gapon
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
