Re: SCM
Hi, Aaron Mason wrote on Mon, Jul 29, 2019 at 11:21:37AM +1000: > On Mon, Jul 29, 2019 at 3:25 AM Nathan Hartman wrote: >> 9. Apache license. Not BSD but much closer than any GPL revision. > Yeah, hard pass. The Apache license is full of encumbering legalese. > They stopped including Apache in base (after supporting a 1.x tree for > years) for this very reason. Not exactly; the reason for dropping the Apache 1.3 HTTP daemon wasn't licensing, but rather that 1.3 proved a dead end, 2.0 would hardly have been considered no matter the license, whereas nginx looked useful and viable back in the day; nobody expected that nginx would also become unmaintainable within less than three years. But all's well that ends with httpd(8)... :-) You are right, though, that "closer" is not "close enough" in this case: see https://www.openbsd.org/policy.html for details, search for "Apache" in that page. Yours Ingo
Re: SCM
On Mon, Jul 29, 2019 at 3:25 AM Nathan Hartman wrote: (snip) > * Hg does not mean Au. I see what you did there :) > 9. Apache license. Not BSD but much closer than any GPL revision. Yeah, hard pass. The Apache license is full of encumbering legalese. They stopped including Apache in base (after supporting a 1.x tree for years) for this very reason. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: Syncing unbound.conf
Config file ns0# cat /var/unbound/etc/unbound.conf # $OpenBSD: unbound.conf,v 1.7 2016/03/30 01:41:25 sthen Exp $ server: interface: 127.0.0.1 #interface: ::1 do-ip6: no access-control: 0.0.0.0/0 refuse access-control: 127.0.0.0/8 allow access-control: 192.168.0.0/16 allow access-control: ::0/0 refuse access-control: ::1 allow hide-identity: yes hide-version: yes remote-control: control-enable: yes control-use-cert: no control-interface: /var/run/unbound.sock # Use an upstream forwarder (recursive resolver) for specific zones. # forward-zone: name: "testing." forward-addr: 127.0.0.1@5353 # to nsd daemon forward-zone: name: "." # use for ALL queries forward-addr: 1.1.1.1 forward-addr: 74.82.42.42 forward-addr: 2001:470:20::2 forward-addr: 208.67.222.222 forward-first: yes -- Sincerely flipchan On July 28, 2019 6:21:49 PM GMT+03:00, Flipchan wrote: >Thanks for the configs ! > >https://jonwillia.ms/2018/09/23/anycast-dns-openbsd >(github.com/bongozone/kibble) > >I have got it to work as only either only working with my internal zone >records or working with everything else > >Unbound ignores when i put a forward-zone: name: ".testing" when i have >another forward-zone: name: "." > >Does anyone know how this could be done ? I have nsd running the zone >records for .testing and it works when i only have the .testing >forward-zone in the unbound.conf , does anyone know what im doing wrong >? > > > >On July 27, 2019 1:35:55 AM GMT+03:00, Vijay Sankar > wrote: >> >>Quoting Stuart Henderson : >> >>> No - you wouldn't do it with Unbound which is a *recursive* DNS >>> server, you would use an authoritative one like NSD, PowerDNS, Knot > >>> or BIND. All you would do with Unbound is use stub-zone to point it > >>> at an authoritative server. >>> >>> -- >>> Sent from a phone, apologies for poor formatting. >>> On 26 July 2019 11:05:44 Flipchan wrote: Can you link to any guides or pratical howtos on how to pratically > do that with unbound ? Thanks On July 25, 2019 9:32:29 PM GMT+03:00, Stuart Henderson wrote: On 2019-07-25, Flipchan wrote: Greetings everyone, Does anyone have a good solution for syncing unbound configuration >>files? i have the senario where i have two internal LAN's that in two different offices that need to have the same internal dns system for the local systems, and there is a lot of changes being done in the internal zone records so i need a good way to sync them(the ideal way where to have a similar solution like mysql's master-master replication). Both dns resolvers are running unbound on openbsd 6.5 and right now > >> the configuration file is synced with ansible. Does anyone have a good solution on replicating dns records/configs > >> for unbound. In the future it will be scaled even more so right now is a good time to implement some replication > >> for the unbound configs. Does anyone have a solution for this? There is people changing the config files on both instances so the > ideal way would be a replication real time sync function. Anyone got any ideas? Thanks in advance Ciao flipchan If multiple sites are updating records in the same internal zone at >>various times, they would probably be better off with a normal authoritative DNS server serving that zone (with e.g. stub-zone to point unbound at it), editing it in one place, and using normal DNS replication (zone-transfer and >>notify) to push the updates. -- Sent from my Android device with K-9 Mail. Please excuse my >brevity. >> >>I have two locations (foretell.ca and lab.foretell.ca) and for quite a > >> >>while used NSD and Unbound. But switched to the following approach >>(however my use case is very simple and my networks are small, but it > >>works well for me) >> >>My unbound.conf on four DNS servers have >> >>include: "/var/unbound/etc/zonedata" >> >>I then set up a simple zonedata file on one server with stuff such as: >> >>local-zone: "foretell.ca." static >>. >>. >>local-zone: "lab.foretell.ca." static >>. >>. >>local-zone: "0.0.10.in-addr.arpa." static >>. >>. >>local-zone: "3.72.10.in-addr.arpa." static >>. >>. >>etc. etc. >> >>Changes to zonedata reflect changes at both locations. Then I just >>have a rsync process running a few times a day that does the >following: >> >>fr1s1.foretell.ca# more dnsupdate.sh >>rsync -av zonedata 10.0.0.1:/var/unbound/etc/ >>rsync -av zonedata 10.0.0.3:/var/unbound/etc/ >>rsync -av zonedata 10.72.3.1:/var/unbound/etc/ >>rsync -av zonedata 10.72.3.3:/var/unbound/etc/ >>ssh 10.0.0.1 /etc/rc.d/unbound restart >>ssh 10.0.0.3 /etc/rc.d/unbound restart >>ssh 10.72.3.1 /etc/rc.d/unbound
intermittent TCP-connection failure, suspect resolv.conf and/or unbound mis-configuration
I have a firewall/router which runs unbound(8) to provide a caching
DNS service to local machines. This mostly works ok, but the local
machines are seeing intermittent failures to open new TCP connections.
I speculate that this problem may be due to DNS failures caused my
having mis-configured resolv.conf(5) and/or unbound(8) on the firewall.
Before I break out tcpdump, can anyone point out any problem with my
configuration?
The firewall is a PC Engines Alix board running 6.5-stable/i386.
The wired client is a laptop running 6.5-stable/amd64; both this and
the firewall have had the 2019-06-10 libssl patch applied. The wifi
clients are laptops running a mixture of Windows 7 and Windows 10.
The wired and wifi clients both see the same sort of intermittent
failures, signalled by (e.g.) a web browser reporting that it's unable
to resolve a hostname, or Thunderbird (on a Windows client) reporting
that it's unable to save a message to its sent-mail folder.
The failures tend to cluster in time, i.e., immediately after a failure
there's a much-larger-than-usual chance that retrying the same command
will fail again. Eventually (after enough retrying) the connection
always succeeds. I speculate that I might be seeing a race condition
on the firewall between its unbound(8) and whatever the ISP router/gateway
is doing?
The network topology is this:
internet
|
|
+-+ +--+
| | | | ++ ) ) wifi
| ISP | | | | wifi | ) ) clients
| gateway |--|vr0 firewall vr2|-| access |
| /router | | | | point |
| | |vr1 | ++
+-+ +--+
|
|
wired client
The firewall has 3 (ethernet) interfaces, vr0, vr1, and vr2.
vr0 is connected to the ISP gateway/router; vr1 to the wired client,
and vr2 to a wifi access point for the wifi clients.
On the firewall, vr0 gets a dhcp IP address from the ISP gateway/router,
while vr1 and vr2 have static IP addresses. The firewall runs dhcpd on
vr1 and vr2 to assign dynamic IP addresses to the clients.
The firewall uses pf for access control and to NAT internal addresses
to the outside world:
--- begin firewall /etc/pf.conf ---
# our interfaces
if_outside = "vr0"
if_wired= "vr1"
if_wifi = "vr2"
if_inside = "{" $if_wired $if_wifi "}"
if_all = "{" $if_wired $if_wifi $if_outside "}"
# subnets
addr_wired = "192.168.105.0/26"# .0 to .63
addr_wifi = "192.168.105.64/26" # .64 to .127
# all internal addresses
addr_internal = "192.168.105.0/24"
set skip on lo0
antispoof quick for $if_all
block all
# allow outgoing connections from any internal address, NAT these
pass in on $if_wired from $addr_wired
pass in on $if_wififrom $addr_wifi
pass out on $if_outside from { $addr_internal ($if_outside) } \
nat-to ($if_outside) modulate state
# allow incoming connections to our ssh ONLY from wired network
block in on !$if_wired proto {tcp,udp} to port ssh
--- end firewall /etc/pf.conf ---
The firewall runs unbound(8) (started from /etc/rc.conf.local). Right
now unbound is *not* doing DNSSEC validation (that's still on the TODO
list for the future). The ISP gateway/router always gives out the same
DNS address, so for simplicity I've just hardwired that in the firewall's
/var/unbound/etc/unbound.conf . On the firewall, unbound-checkconf(8)
reports nothing wrong.
--- begin firewall /etc/resolv.conf ---
# Generated by vr0 dhclient
search Home
nameserver 127.0.0.1
nameserver 192.168.1.254
--- end firewall /etc/resolv.conf ---
--- begin firewall /var/unbound/etc/unbound.conf ---
# $OpenBSD: unbound.conf,v 1.14 2018/12/16 20:41:30 tim Exp $
server:
interface: 192.168.105.62 # wired network vr1
interface: 192.168.105.126 # wifi network vr2
do-ip6: no
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.1 allow
access-control: 192.168.105.0/26 allow
access-control: 192.168.105.64/26 allow
hide-identity: yes
hide-version: yes
# Uncomment to enable DNSSEC validation.
#
#auto-trust-anchor-file: "/var/unbound/db/root.key"
#val-log-level: 2
# Uncomment to synthesize NXDOMAINs from DNSSEC NSEC chains
# https://tools.ietf.org/html/rfc8198
#
#aggressive-nsec: yes
# UDP EDNS reassembly buffer advertised to peers. Default 4096.
# May need lowering on broken networks with fragmentation/MTU issues,
# particularly if validating DNSSEC.
#
#edns-buffer-size: 1480
# Use TCP for "forward-zone"
Re: SCM
On Sun, Jul 28, 2019 at 3:27 PM Stefan Sperling wrote: > On Sun, Jul 28, 2019 at 01:24:02PM -0400, Nathan Hartman wrote: > > *IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I > > root for Subversion. > > Vetoed, for 3 simple reasons: > (snip) > 3) I don't want to be held responsible when it breaks on Theo > THAT is definitely a valid reason!
Re: SCM
On Sun, Jul 28, 2019 at 01:24:02PM -0400, Nathan Hartman wrote: > *IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I > root for Subversion. Vetoed, for 3 simple reasons: 1) Wrong licence 2) FreeBSD uses it 3) I don't want to be held responsible when it breaks on Theo -- Stefan Sperling V.P., Apache Subversion ASF member (https://www.apache.org/foundation/members.html) PGP fingerprint: B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0
Re: SCM
On Fri, Jul 26, 2019 at 8:31 PM Австин Ким wrote: > I can't argue with that, and obviously code quality is infinitely more > important than what SCM you use, but I feel you run the risk of turning off > potential new developers coming out of colleges and universities who cut > their > teeth on distributed SCM systems like hg and Git who might be taken aback > at > why the Project is still stuck with CVS (and again, I am not advocating for > Git; though if it isn't obvious by now I really believe OpenBSD developers > would honestly like Mercurial; to me it just seems consistent with > OpenBSD's > culture of cleanliness and simplicity). One can cut one's teeth on git and believe whatever one wants to believe but SCMs are not one-size-fits all. * Distributed does not mean better. * Centralized does not mean worse. * CVS does not mean "stuck." * Git does not mean smart. * Hg does not mean Au. Every project has its own requirements and should use the tools that fit best. *IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I root for Subversion. Subversion offers the following advantages: 1. CVS's closest relative; fixes all of CVS's shortcomings. 2. Very easy to learn and use. You practically can't screw it up. 3. Immutable history, i.e., SAFE to use. 4. Handles a giant repository with ease. (Many git projects fracture into numerous repositories to work around git limitations, so you lose atomic commits and get a maintenance headache instead.) 5. Sparse checkouts. 6. Versioned properties attached to files and directories (git can't version directories). 7. Follow history through copies, moves, and renames. 8. Coded in C89. Very few dependencies. 9. Apache license. Not BSD but much closer than any GPL revision. I'm sure you've heard bad things about Subversion. These old myths and facts stopped being true a decade ago.
Re: Syncing unbound.conf
Thanks for the configs ! https://jonwillia.ms/2018/09/23/anycast-dns-openbsd (github.com/bongozone/kibble) I have got it to work as only either only working with my internal zone records or working with everything else Unbound ignores when i put a forward-zone: name: ".testing" when i have another forward-zone: name: "." Does anyone know how this could be done ? I have nsd running the zone records for .testing and it works when i only have the .testing forward-zone in the unbound.conf , does anyone know what im doing wrong ? On July 27, 2019 1:35:55 AM GMT+03:00, Vijay Sankar wrote: > >Quoting Stuart Henderson : > >> No - you wouldn't do it with Unbound which is a *recursive* DNS >> server, you would use an authoritative one like NSD, PowerDNS, Knot >> or BIND. All you would do with Unbound is use stub-zone to point it >> at an authoritative server. >> >> -- >> Sent from a phone, apologies for poor formatting. >> On 26 July 2019 11:05:44 Flipchan wrote: >>> Can you link to any guides or pratical howtos on how to pratically >>> do that with unbound ? >>> >>> Thanks >>> >>> >>> On July 25, 2019 9:32:29 PM GMT+03:00, Stuart Henderson >>> wrote: >>> On 2019-07-25, Flipchan wrote: >>> >>> Greetings everyone, >>> >>> Does anyone have a good solution for syncing unbound configuration >files? >>> >>> >>> i have the senario where i have two internal LAN's that in two >>> different offices that need to have the same internal >>> dns system for the local systems, and there is a lot of changes >>> being done in the internal zone records so i need >>> a good way to sync them(the ideal way where to have a similar >>> solution like mysql's master-master replication). >>> >>> Both dns resolvers are running unbound on openbsd 6.5 and right now > >>> the configuration file is synced with ansible. >>> Does anyone have a good solution on replicating dns records/configs > >>> for unbound. In the future it will be scaled >>> even more so right now is a good time to implement some replication > >>> for the unbound configs. >>> >>> Does anyone have a solution for this? >>> >>> There is people changing the config files on both instances so the >>> ideal way would be a replication real time sync function. >>> >>> Anyone got any ideas? >>> >>> >>> Thanks in advance >>> Ciao >>> flipchan >>> >>> >>> If multiple sites are updating records in the same internal zone at >various >>> times, they would probably be better off with a normal >>> authoritative DNS server >>> serving that zone (with e.g. stub-zone to point unbound at it), >>> editing it in >>> one place, and using normal DNS replication (zone-transfer and >notify) >>> to push the updates. >>> >>> >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. > >I have two locations (foretell.ca and lab.foretell.ca) and for quite a > >while used NSD and Unbound. But switched to the following approach >(however my use case is very simple and my networks are small, but it >works well for me) > >My unbound.conf on four DNS servers have > >include: "/var/unbound/etc/zonedata" > >I then set up a simple zonedata file on one server with stuff such as: > >local-zone: "foretell.ca." static >. >. >local-zone: "lab.foretell.ca." static >. >. >local-zone: "0.0.10.in-addr.arpa." static >. >. >local-zone: "3.72.10.in-addr.arpa." static >. >. >etc. etc. > >Changes to zonedata reflect changes at both locations. Then I just >have a rsync process running a few times a day that does the following: > >fr1s1.foretell.ca# more dnsupdate.sh >rsync -av zonedata 10.0.0.1:/var/unbound/etc/ >rsync -av zonedata 10.0.0.3:/var/unbound/etc/ >rsync -av zonedata 10.72.3.1:/var/unbound/etc/ >rsync -av zonedata 10.72.3.3:/var/unbound/etc/ >ssh 10.0.0.1 /etc/rc.d/unbound restart >ssh 10.0.0.3 /etc/rc.d/unbound restart >ssh 10.72.3.1 /etc/rc.d/unbound restart >ssh 10.72.3.3 /etc/rc.d/unbound restart > >Obviously I am not sure if this will scale for your requirements but >mentioning this just in case it helps. > >Vijay > > >-- >ForeTell Technologies Limited >59 Flamingo Avenue >Winnipeg, MB, Canada >R3J 0X6 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
