From wouter at nlnetlabs.nl Tue Apr 9 13:17:46 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 09 Apr 2013 15:17:46 +0200 Subject: [Dnssec-trigger] [PATCH] Pass all domains from 'search' through to MacOS. In-Reply-To: <20130328190948.GA40505@redoubt.spodhuis.org> References: <20130328190948.GA40505@redoubt.spodhuis.org> Message-ID: <516414FA.2050509@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Phil, The patch is included in the svn of dnssec-trigger. Thank you for this improvement. Best regards, Wouter On 03/28/2013 08:09 PM, Phil Pennock wrote: > From: Phil Pennock > > Previously, 'search' was like 'domain but allowing extra domains > to appear, and be ignored. This fixes that. > > Note: scutil setting is defined but not actually used (before and > after this patch). I've no idea why scutil changes don't take and > networksetup is needed, but I can confirm that this is the case for > me too; nonetheless, I changed both approaches, to keep things in > sync. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZBT6AAoJEJ9vHC1+BF+N2scQAKp0aNToGKqyvjCvckOzhzWW g3t/4oSJiiu7tI4DEAu9Uw1pPtbdbg2juhf+fmpXEQ0+UCo+Myz5w3zgVv6wK5O3 mcmPq+OknoboyXbrZ1RjSaaLtE6hC5qLTLDiijfzoHmIIrbQAi5wvG+RzS00BARH 4D7E2+haCZkn+coFVZcbqy7dagEE/DzgrgoWQZ/CCc1bdnHZh9WxsZyDwD0RxadV 2E64MntTjF60Fk+e9h36MlOoKeRRYzC+nbRsqaO4PZCToFaXiUNR24na83hQIPYy 32jCvdNCqajs2l8zjFL73myQkCv2Oh8t1QsI0OKIWFybUEaFe4amtlO4hnaK7vVg eaJ9wihHd5H9MdyBSfnKDr3dECgdl/GfspG0Zbo3lZCmCEH0CB5Y8UDAm3CKCH7+ t5Dg/aoYP8UGKRgOvp3aNQFvp+ExCLRJbdlI+uYN5IfMZNA0088sxqf3G+3lKdTg rbDZEZYG8xHGmQGlzz9hHDwfi5JQO/ymF/D8FT8FDc1gYJYSkwZXQJ4/6Pbj8uvb ryzS/4Pk84Rmv8p/8uaQfoBnTsI18oDxoIwbTXQf/s9NlVoscwmWvn3VwpKI8rPg Waq+ZPdcmk0tgADYaUyTGARMq3mpqeF3iTvGSHLx6dxNgvn2HxsRcnJxI63Mej2z uv5T/h/Uf+PSZU3uPF1g =WIpU -----END PGP SIGNATURE----- From wouter at nlnetlabs.nl Tue Apr 9 13:22:51 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 09 Apr 2013 15:22:51 +0200 Subject: [Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8) In-Reply-To: <20130323231327.GA68069@redoubt.spodhuis.org> References: <20130323231327.GA68069@redoubt.spodhuis.org> Message-ID: <5164162B.1030909@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Phil, I have created a snapshot of the devel version of dnssec-trigger. The changes are mostly for OSX, so there is this dmg. http://nlnetlabs.nl/~wouter/dnssectrigger-0.12_20130409.dmg You can install it over your current 0.11. It includes newer ldns and unbound versions as well as some OSX specific improvements in dnssec-trigger: - - install on Mountain Lion - - phil's search domain patch for OSX. - - hibernation fix for OSX The hibernation fix is that it detects the system wakeup and at that time flushes some unbound caches (the infra cache, the requestlist and it flushes bogus information out of the DNS cache). This should hopefully make things work. If you have this, does that still need a kill of mDNSResponder? If adventurous users feel like it, go on and try out this version, it should hopefully remove OSX irritations. Best regards, Wouter On 03/24/2013 12:13 AM, Phil Pennock wrote: > Seen this twice, don't know enough about Mac internals to track it > down, but now that it's recurred, I can perhaps prod further in > future. > > MacOS 10.8.3 on a laptop. > > When I resume from sleep/hibernate, sometimes I am now missing > functioning DNS resolution. At least this time, Chrome was > running still, so the resume resulted in a Gmail tab failing to > talk to the server. This *might* affect open communication paths > to the system resolver? > > I have functioning network, I can ping something outside > (8.8.8.8), "sudo unbound-control forward" shows the forwarding is > there, pointing to the local router gateway (which in turn runs > unbound). Turning off WiFi and turning it back on, does not fix > it. "sudo unbound-control reload" (and then restoring the forward) > does not fix it. "Fix" is defined as "ping www.google.com" in a > Terminal is able to resolve the hostname. > > Only fix is: > > sudo killall -v mDNSResponder > > At which point, everything gets back DNS resolution ability. > > This problem started with dnssec-trigger being installed. > > Anyone have ideas about what might be going on? Failing that, > suggestions for things to look at, the next time, to better > diagnose? > > DNSSec-Trigger installed: % pkgutil --pkgs | fgrep -i dnssec > nl.nlnetlabsdnssectrigger011ForMacosX10.7.Package_Root.pkg > > An extract from system.log is attached, including some > dnssec-trigger failures. I suspect that this is a clue: > > ----------------------------8< cut here > >8------------------------------ Mar 23 18:39:18 ilmenite > com.apple.launchd[1] (nl.nlnetlabs.dnssec-trigger-hook): Throttling > respawn: Will start in 1 seconds ----------------------------8< cut > here >8------------------------------ > > Thanks, -Phil > > > > _______________________________________________ dnssec-trigger > mailing list dnssec-trigger at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZBYrAAoJEJ9vHC1+BF+NpIMP/jNc3SVEoL/O/DfSKimZFPKK O0bZXapxXNfjWtmvP8tkeouoH+LpWezaIqBv4jjx1q0Apx0vvic8mb1N+dEEa35K FrtN3FZ6aoEyvygJvyWtrWqzsb7GXIAJ5889fbhfXO1JLoq6eHKNNmtH3/FoaPaf 2ujopBicjLSSYVbnXr9BbETRH93XMCNBrr1/j2HDUD25GFJiaWFmaJt7ZhNfPqvi gr4FGLbqLqN5GZF5J3TiuYQMPnERCQtvy3j76BVM7mta43iZ6U5LPE6TtDi47RbJ rVFquZy9Khr4M+SR1oj6aUNHlf2fizWqQIdsAJnudICJf5pRZn10kW96+h6ib3Zr 97YrLw4egUglgRQyakhupg8Yda8XEcrFiuTx3uKauw78W5IOQ7eT9b7PM1FhD1i/ ubF8ZeepI4GD62lnb/DuauIerRXb5XJ3swuAOkYrKq0kmLttRxkmUN7HbltRE5en MuM1RHDGG3QJRG736uEPiKwIBf1h6sigu5KuHzzaDV7UZzN1aCNudzVEzMaXAIFj Fq728yXyUaUCiorgf6J33/ms5DXRXwrfx8EjvgE8Po3DvLjU5/QzSSlkcmDMY5Hk MhLR4w0p+pLXOJFdy3edfG3gZql+VmYk+cqZzXSLfhtG4KJCIA2EXOl8nBT1Ieit //biu+gc9+c0lAM4uumV =L8KX -----END PGP SIGNATURE----- From jpmens.dns at gmail.com Tue Apr 9 13:37:22 2013 From: jpmens.dns at gmail.com (Jan-Piet Mens) Date: Tue, 9 Apr 2013 15:37:22 +0200 Subject: [Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8) In-Reply-To: <5164162B.1030909@nlnetlabs.nl> References: <20130323231327.GA68069@redoubt.spodhuis.org> <5164162B.1030909@nlnetlabs.nl> Message-ID: <20130409133722.GA41532@jmbp.ww.mens.de> Hello Wouter, > http://nlnetlabs.nl/~wouter/dnssectrigger-0.12_20130409.dmg > > You can install it over your current 0.11. Which I've just done, thank you. I've been experiencing similar issues to those reported by Phil since upgrading to 10.8.3 a few weeks ago, and have actually had to disable dnssec-trigger a few times recently. (Very hard to diagnose, because I've been running from one lousy WiFi hotspot to the next even lousier one..) Shall keep an eye out for anomalies and report. :) -JP From dnssec-trigger+phil at spodhuis.org Tue Apr 9 17:38:35 2013 From: dnssec-trigger+phil at spodhuis.org (Phil Pennock) Date: Tue, 9 Apr 2013 13:38:35 -0400 Subject: [Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8) In-Reply-To: <5164162B.1030909@nlnetlabs.nl> References: <20130323231327.GA68069@redoubt.spodhuis.org> <5164162B.1030909@nlnetlabs.nl> Message-ID: <20130409173835.GA56842@redoubt.spodhuis.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 2013-04-09 at 15:22 +0200, W.C.A. Wijngaards wrote: > http://nlnetlabs.nl/~wouter/dnssectrigger-0.12_20130409.dmg > > You can install it over your current 0.11. It includes newer ldns and > unbound versions as well as some OSX specific improvements in > dnssec-trigger: > - install on Mountain Lion > - phil's search domain patch for OSX. > - hibernation fix for OSX A colleague installed, reported that DNS resolution was broken, same as before when he tried 0.11, uninstalled, got DNS resolution back. I'll take a look, if I can persuade him, when I'm in the same town as him next week. > If you have this, does that still need a kill of mDNSResponder? Will let you know when I've been through a few hibernate/resume cycles without issue. :) > If adventurous users feel like it, go on and try out this version, it > should hopefully remove OSX irritations. I was slightly disconcerted that /etc/dnssec-trigger/dnssec_trigger_control.key is now installed 0644 since the "submit" command means an untrusted service account can now subvert DNS for the more trusted accounts. Of course, since my "trusted" account runs a web-browser, that's not a clear point in favour of the distinction being meaningful. On a server, I think it is more meaningful. For myself, my logbook shows I used: sudo chmod +a "pdp allow read" \ /etc/dnssec-trigger/dnssec_trigger_control.key sudo chmod +a "pdp allow read" \ /etc/unbound/unbound_control.key /etc/unbound/unbound_control.pem \ /etc/unbound/unbound_server.pem I suspect that the right approach, on MacOS, is to use the "admin" group, so `chmod +a "group:admin allow read" $files` should be the safest invocation (handling when a user called admin exists too). Thoughts? - -Phil -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlFkUhMACgkQQDBDFTkDY3/aoQCglm4ZLbJYctyT/MdzljVClbor l8wAnjnyoEFHxGP3B8BJkRELB5rtTfBo =qGA6 -----END PGP SIGNATURE----- From wouter at nlnetlabs.nl Wed Apr 10 07:18:35 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Wed, 10 Apr 2013 09:18:35 +0200 Subject: [Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8) In-Reply-To: <20130409173835.GA56842@redoubt.spodhuis.org> References: <20130323231327.GA68069@redoubt.spodhuis.org> <5164162B.1030909@nlnetlabs.nl> <20130409173835.GA56842@redoubt.spodhuis.org> Message-ID: <5165124B.2040509@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Phil, On 04/09/2013 07:38 PM, Phil Pennock wrote: > On 2013-04-09 at 15:22 +0200, W.C.A. Wijngaards wrote: >> http://nlnetlabs.nl/~wouter/dnssectrigger-0.12_20130409.dmg > >> You can install it over your current 0.11. It includes newer >> ldns and unbound versions as well as some OSX specific >> improvements in dnssec-trigger: - install on Mountain Lion - >> phil's search domain patch for OSX. - hibernation fix for OSX > > A colleague installed, reported that DNS resolution was broken, > same as before when he tried 0.11, uninstalled, got DNS resolution > back. > > I'll take a look, if I can persuade him, when I'm in the same town > as him next week. Is this VPN related? There is something wrong when VPNs are used? I think it gets confused about nameservers, or VPN and dnssec-trigger software conflict about updating nameserver settings. >> If you have this, does that still need a kill of mDNSResponder? > > Will let you know when I've been through a few hibernate/resume > cycles without issue. :) Ok. >> If adventurous users feel like it, go on and try out this >> version, it should hopefully remove OSX irritations. > > I was slightly disconcerted that > /etc/dnssec-trigger/dnssec_trigger_control.key is now installed > 0644 since the "submit" command means an untrusted service account > can now subvert DNS for the more trusted accounts. Yes. The tray icon menu is also something for admins, because it can click on dialogs 'yes dnssec really fails here'. Your colleague could use the commandline for something like: dnssec-trigger-control status > Of course, since my "trusted" account runs a web-browser, that's > not a clear point in favour of the distinction being meaningful. On > a server, I think it is more meaningful. > > For myself, my logbook shows I used: > > sudo chmod +a "pdp allow read" \ > /etc/dnssec-trigger/dnssec_trigger_control.key sudo chmod +a "pdp > allow read" \ /etc/unbound/unbound_control.key > /etc/unbound/unbound_control.pem \ /etc/unbound/unbound_server.pem > > I suspect that the right approach, on MacOS, is to use the "admin" > group, so `chmod +a "group:admin allow read" $files` should be the > safest invocation (handling when a user called admin exists too). That could be a good idea. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZRJLAAoJEJ9vHC1+BF+NOHsP/RaO2DBF2QOKTmC/2DPcxEB8 AjLn0BPsC77RIeS+PeRu7mqajjKa/ReW+xUwc/AX6m1FQwXDZgrhTD1b7GvItB4U qGl14hk6oufaVSuF7KdUVPah33eNojEugMt4HO8etabyAU1hEo9eGBXZYFHvzb2n opZG27x5fk+VFQHpVHnBNXdfe5ZsaMUAPTzR+o8dJU4+df9UBw/rVWtOhdV0p2DZ +uewKyUJutuHVUp23LLtI9jwwpt6A4JoL/xbNH8zlpq/7J3NB1p5EIsIyj5FnugY YCCaIBbRQnfMxLmBvmn4vR0e6p/KXygYbyJWx898TUheB5+KOFbTr1dpWVM+MUSc KaSL9shT1ztjrz67gqK/we6gS9f6j6IQerHlmGk3YvBW1Nb4v5L2dtbd4J/3nD8l QMKOtO4TUtaldyolRVeBMzW0jovK/HOLs9eFkFnb4RteBe/zKAVN1R+i/qIBP6au +nfS2NFprbl1BzER/DQQShQTwdn2G2xmnE+Bis9WhOjmiIbDliDEe/b6ofmwpvSB Va4o3zLnO5ezSeDBGjnuYfKJACigRZl6EmTKdg3MR9YjzIP4l+8prbT65K3+mLJj vJlxu173lVGwVS4fPaDkWJ7qiu65VLKtXoCWt/X+6NKrNs2tOeQd1MIQLNjuUthL FIcKvyo0+pUbDzdoxFeS =YVtI -----END PGP SIGNATURE----- From dnssec-trigger+phil at spodhuis.org Wed Apr 10 17:47:23 2013 From: dnssec-trigger+phil at spodhuis.org (Phil Pennock) Date: Wed, 10 Apr 2013 13:47:23 -0400 Subject: [Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8) In-Reply-To: <5165124B.2040509@nlnetlabs.nl> References: <20130323231327.GA68069@redoubt.spodhuis.org> <5164162B.1030909@nlnetlabs.nl> <20130409173835.GA56842@redoubt.spodhuis.org> <5165124B.2040509@nlnetlabs.nl> Message-ID: <20130410174722.GA5107@redoubt.spodhuis.org> On 2013-04-10 at 09:18 +0200, W.C.A. Wijngaards wrote: > Is this VPN related? There is something wrong when VPNs are used? I > think it gets confused about nameservers, or VPN and dnssec-trigger > software conflict about updating nameserver settings. No, they're in an office, Juniper router (I think), issuing Google Public DNS as resolvers. Thanks, -Phil From wouter at nlnetlabs.nl Thu Apr 11 06:59:42 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Thu, 11 Apr 2013 08:59:42 +0200 Subject: [Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8) In-Reply-To: <20130410174722.GA5107@redoubt.spodhuis.org> References: <20130323231327.GA68069@redoubt.spodhuis.org> <5164162B.1030909@nlnetlabs.nl> <20130409173835.GA56842@redoubt.spodhuis.org> <5165124B.2040509@nlnetlabs.nl> <20130410174722.GA5107@redoubt.spodhuis.org> Message-ID: <51665F5E.9060604@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Phil, On 04/10/2013 07:47 PM, Phil Pennock wrote: > On 2013-04-10 at 09:18 +0200, W.C.A. Wijngaards wrote: >> Is this VPN related? There is something wrong when VPNs are >> used? I think it gets confused about nameservers, or VPN and >> dnssec-trigger software conflict about updating nameserver >> settings. > > No, they're in an office, Juniper router (I think), issuing Google > Public DNS as resolvers. So, the router could be weird (depending on the software on it), google DNS supports DNSSEC. So I think the issue is mostly the configuration of the OSX machine. I was wondering if there was other software on that OSX machine, such as VPN software, that messes with the nameserver configuration; and in combination with dnssec-trigger's messing with the nameserver configuration this leads to a failure to resolve? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRZl9ZAAoJEJ9vHC1+BF+NBNMP/R0IKf/MHeUlNTolCxW7QWTx 2dkdoEGd2N9GnS/4hJtBREF8lrz+YZjmghd+mUpZqiRP8epFdbjgA0LZ7ATsDj86 foWQBG1VL9TFARpq4y5jKndTOlPgU4kVKMdwqx9Qcaw5yClp8fE8Zin2lTa2SeEM H1HJ8PquQWfYnv9otJuAl2wml+2KNEOqqc5DPL+OHjIINoK6hugB2VLG0qxX6iIL XNu2CdS4R4iAjRholUyr+UZ3E22zJijNC6VfjljdGta+3vBNoObL9bBcm8R/zQNT M80Jf+pSl/R4urUhHLpIXpdc6gBDiKOr9mEiDo3offZ6yeKHkCgYdRS5U1eBkTSE LyOlrnBDDzIwOADszMUl3EWN/Lwd2lvz7mge3EHqgjaoZgKa56TrGx10ZaarhVHQ xTFrtXbZdrRddCVM/JzL2DsyNQnUDidslcSRTzNvJCpV9aadNtA1XlHK3dCfefPy 9uJjPsIJmXGMDkntee5nu4dN34lBbJA8oEh9HnoiHcttO6tGG+4syacdpxRB9BcH 4qsg9NyaT2cY6EMAt1N638+ur1YMokqVqrvQrCXpihTCSnPyh+7RV8affGlZ5E0F qC+1P8bVMfaGm3kZ3Mdqq5LvZ24Rrv90KX0Qo0Q1GGkhdw7ZLCwJ4eXhX1CGe2fY 0oulQRzi40bCmh1fA2ux =HGta -----END PGP SIGNATURE----- From dnssec-trigger+phil at spodhuis.org Thu Apr 11 19:25:09 2013 From: dnssec-trigger+phil at spodhuis.org (Phil Pennock) Date: Thu, 11 Apr 2013 15:25:09 -0400 Subject: [Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8) In-Reply-To: <51665F5E.9060604@nlnetlabs.nl> References: <20130323231327.GA68069@redoubt.spodhuis.org> <5164162B.1030909@nlnetlabs.nl> <20130409173835.GA56842@redoubt.spodhuis.org> <5165124B.2040509@nlnetlabs.nl> <20130410174722.GA5107@redoubt.spodhuis.org> <51665F5E.9060604@nlnetlabs.nl> Message-ID: <20130411192508.GA22331@redoubt.spodhuis.org> On 2013-04-11 at 08:59 +0200, W.C.A. Wijngaards wrote: > So, the router could be weird (depending on the software on it), > google DNS supports DNSSEC. I've used my laptop in the same office, to no ill effect, so I don't think the router is in the mix. > So I think the issue is mostly the > configuration of the OSX machine. I was wondering if there was other > software on that OSX machine, such as VPN software, that messes with > the nameserver configuration; and in combination with dnssec-trigger's > messing with the nameserver configuration this leads to a failure to > resolve? VPN: VPN Tracker, also on my laptop, no ill effects noted. It is software written by people who appear to know what they're doing, thus our using it extensively: we avoid hardware/firewall vendor client software, it always causes far more pain than it solves, and instead use client software written by folks for whom it is their product. Jon doesn't know of anything else running that might affect DNS resolution and he's pretty clueful (to say the least). I'll install dnssec-trigger again next week, see what broke, repair it, report back. -Phil From dnssec-trigger+phil at spodhuis.org Fri Apr 19 21:49:57 2013 From: dnssec-trigger+phil at spodhuis.org (Phil Pennock) Date: Fri, 19 Apr 2013 17:49:57 -0400 Subject: [Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8) In-Reply-To: <5164162B.1030909@nlnetlabs.nl> References: <20130323231327.GA68069@redoubt.spodhuis.org> <5164162B.1030909@nlnetlabs.nl> Message-ID: <20130419214956.GA48328@redoubt.spodhuis.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 2013-04-09 at 15:22 +0200, W.C.A. Wijngaards wrote: > I have created a snapshot of the devel version of dnssec-trigger. > The changes are mostly for OSX, so there is this dmg. > > http://nlnetlabs.nl/~wouter/dnssectrigger-0.12_20130409.dmg > > You can install it over your current 0.11. It includes newer ldns and > unbound versions as well as some OSX specific improvements in > dnssec-trigger We installed again on my co-worker's computer. The "unbound" user was not created. Fixed, installed, validation not working, the linetag updates were not present in the config file. Uninstalled, nuked /etc/unbound and /etc/dnssec-trigger (remnants from 0.11 install attempt?), installed and he has working validation. I unpacked the install stuff on my laptop and found one problem, but the logic should be the same anyway so it's not the root cause. I can't (at this time) take my colleague's laptop away to repeatedly probe what's happening. /Volumes/DnssecTrigger/dnssectrigger-0.12_20130409-i386.mpkg/Contents/Packages/packageroot.pkg/Contents/Resources/postflight - ----------------------------8< cut here >8------------------------------ #!/bin/bash # stop unbound if launch plist exists OSVERS=10.6 INSTLOG=/tmp/dnssectrigger-0.12_20130409-install.log - ----------------------------8< cut here >8------------------------------ So makepackage should probably change: OSVERS=`sw_vers -productVersion | cut -d . -f 1,2` to: OSVERS=\$(sw_vers -productVersion | cut -d . -f 1,2) Similarly throughout the written script. guiuser is hardcoded to "root", which appears to mean it will get hard-set to "wouter" because this: guiuser="`basename \$HOME`" becomes this in the shipped package: guiuser="wouter" and so the attempt to unload the trigger panel runs as wouter on other peoples' machines. Aside: It appears that Google's Public DNS service, now that it validates, blocks the functioning of tests such as: http://test.dnssec-or-not.org/ by causing the host itself to not resolve. Well, at least we know something's blocking the resolution, even if it's not quite right. So there's some weirdness at this location, yes. - -Phil -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlFxu/0ACgkQQDBDFTkDY39sCgCgiXKJ0e0K+FyL+2r6M2ZG15vc zPUAniSd8MfSHa5szAaRwL26smmxrGso =PyzX -----END PGP SIGNATURE----- From wouter at nlnetlabs.nl Mon Apr 22 07:15:36 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Mon, 22 Apr 2013 09:15:36 +0200 Subject: [Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8) In-Reply-To: <20130419214956.GA48328@redoubt.spodhuis.org> References: <20130323231327.GA68069@redoubt.spodhuis.org> <5164162B.1030909@nlnetlabs.nl> <20130419214956.GA48328@redoubt.spodhuis.org> Message-ID: <5174E398.8070406@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Phil, New version I made with fixes: http://nlnetlabs.nl/~wouter/dnssectrigger-0.12_20130422.dmg - - Fixup OSX backquote backslashes. This is in the installer, and affects the user creation. - - Removed wrong OSX version from its installer text. On 04/19/2013 11:49 PM, Phil Pennock wrote: > I unpacked the install stuff on my laptop and found one problem, > but the logic should be the same anyway so it's not the root cause. > I can't (at this time) take my colleague's laptop away to > repeatedly probe what's happening. Something about user permissions, then, likely. > /Volumes/DnssecTrigger/dnssectrigger-0.12_20130409-i386.mpkg/Contents/Packages/packageroot.pkg/Contents/Resources/postflight > > - ----------------------------8< cut here >8------------------------------ > #!/bin/bash # stop unbound if launch plist exists OSVERS=10.6 > INSTLOG=/tmp/dnssectrigger-0.12_20130409-install.log > ----------------------------8< cut here > >8------------------------------ > > So makepackage should probably change: OSVERS=`sw_vers > -productVersion | cut -d . -f 1,2` to: OSVERS=\$(sw_vers > -productVersion | cut -d . -f 1,2) > > Similarly throughout the written script. guiuser is hardcoded to > "root", which appears to mean it will get hard-set to "wouter" > because this: guiuser="`basename \$HOME`" becomes this in the > shipped package: guiuser="wouter" > > and so the attempt to unload the trigger panel runs as wouter on > other peoples' machines. That is so silly that it uses my name. Turned out to be a problem with more of the script. Also with the OSVERS used to install the user under which it runs. And a directory removal in the uninstall. Best regards, Wouter > > Aside: It appears that Google's Public DNS service, now that it > validates, blocks the functioning of tests such as: > http://test.dnssec-or-not.org/ by causing the host itself to not > resolve. Well, at least we know something's blocking the > resolution, even if it's not quite right. So there's some > weirdness at this location, yes. > > -Phil > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRdOOYAAoJEJ9vHC1+BF+NiA0P+wTy48NPdRAUOTt/uHM2UrO8 txc6bjOuMn17cCJInfooh/oDLA1qLrZLIrKCkUQH2WQ4SSjHbIOZ+ERapoXjMVsv QpIB15xNv6fTnIsrIZoszMw0woHICRJ2cGCctBJv4to8HZOvpAtKuZQ7fzZYa8d9 BvUIkJPRWmiPF9732/IqEfTfcyfuTeEv8glNmt9rjEXqsqFy1VzArA9ZlnwxO8Qp 0a3SXJGZXA5jQja9rDakf0K9dz/2etV0BMoQ4N97K+bbDmXGBceiBFqPy/dp0GmN Dn5ylZEAWoWVA/o4gLSZdWuQ0SnPEH8dYy+YCWVOK6QMK/EmfJbEQTnzTW8zF16v pdjrA5eIaRWIW3P32KZm91rJfqL9WkVsvs6WW8wX/6juaugESTFp1VZp2woASYPf RWCwapJXUq6wufMjW44h0Ab7AJOaQxs/z5+aKZXCJn2xoOaG9Cvq8nSaqvbDHLnj bSjdjsat0ff2emr+KMo6IPpq5t6TmDf14+644ipdJL2vJrroCSgNVFinBKO9eWvB BbwHx5twvWlKiVeKQFLW0FV6Xkr2hQDsBpjblqZFtjRRebiQcokRrQFtiobR5h5i LncoiOHmOr4xK+Zz7JD2g7Ejrfg3NcVPKR/Z0fa8vY256HA1xh2n7qDEZwFuXD7P sJRfduGwXVavJqnbUMP5 =El17 -----END PGP SIGNATURE----- From regnauld at nsrc.org Mon Apr 22 13:16:57 2013 From: regnauld at nsrc.org (Phil Regnauld) Date: Mon, 22 Apr 2013 14:16:57 +0100 Subject: [Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8) In-Reply-To: <5174E398.8070406@nlnetlabs.nl> References: <20130323231327.GA68069@redoubt.spodhuis.org> <5164162B.1030909@nlnetlabs.nl> <20130419214956.GA48328@redoubt.spodhuis.org> <5174E398.8070406@nlnetlabs.nl> Message-ID: <20130422131657.GB926@macbook.bluepipe.net> W.C.A. Wijngaards (wouter) writes: > New version I made with fixes: > http://nlnetlabs.nl/~wouter/dnssectrigger-0.12_20130422.dmg > > - - Fixup OSX backquote backslashes. This is in the installer, and > affects the user creation. > - - Removed wrong OSX version from its installer text. Just tried installing that on 10.8.3 - I'd been having problems for a while (since I had backed up and restored my system to a new macbook), and unbound wouldn't start. I removed the unbound macport, ran the uninstall script from dnssec-trigger 0.11. After installing, I'm seeing: Apr 22 14:16:00 macbook com.apple.launchd[1] (nl.nlnetlabs.unbound[4873]): Exited with code: 1 Apr 22 14:16:00 macbook com.apple.launchd[1] (nl.nlnetlabs.unbound): Throttling respawn: Will start in 10 seconds Running /usr/libexec/unbound-launch.sh by hand I see: chown: unbound: illegal user name [1366636394] unbound[4818:0] fatal error: user 'unbound' does not exist. ... ideas ? Did I screw up something ? I could of course create the user manually, but I must have missed something. Cheers, Phil From paul at nohats.ca Mon Apr 22 19:09:40 2013 From: paul at nohats.ca (Paul Wouters) Date: Mon, 22 Apr 2013 15:09:40 -0400 (EDT) Subject: [Dnssec-trigger] Add test for bind RT#21409 ? Message-ID: See https://bugzilla.redhat.com/show_bug.cgi?id=824219 It would be useful for dnssec-trigger to detect this. Paul From dnssec-trigger+phil at spodhuis.org Mon Apr 22 21:42:02 2013 From: dnssec-trigger+phil at spodhuis.org (Phil Pennock) Date: Mon, 22 Apr 2013 17:42:02 -0400 Subject: [Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8) In-Reply-To: <20130422131657.GB926@macbook.bluepipe.net> References: <20130323231327.GA68069@redoubt.spodhuis.org> <5164162B.1030909@nlnetlabs.nl> <20130419214956.GA48328@redoubt.spodhuis.org> <5174E398.8070406@nlnetlabs.nl> <20130422131657.GB926@macbook.bluepipe.net> Message-ID: <20130422214202.GA1199@redoubt.spodhuis.org> On 2013-04-22 at 14:16 +0100, Phil Regnauld wrote: > Running /usr/libexec/unbound-launch.sh by hand I see: > > chown: unbound: illegal user name > [1366636394] unbound[4818:0] fatal error: user 'unbound' does not exist. > > ... ideas ? Did I screw up something ? > I could of course create the user manually, but I must have missed > something. This is the same problem we're encountering: the user isn't ending up created and I haven't yet debugged why not. Thanks, good to know we're not crazy in our office. -Phil From wouter at nlnetlabs.nl Wed Apr 24 11:35:45 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Wed, 24 Apr 2013 13:35:45 +0200 Subject: [Dnssec-trigger] Add test for bind RT#21409 ? In-Reply-To: References: Message-ID: <5177C391.70102@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On 04/22/2013 09:09 PM, Paul Wouters wrote: > > See https://bugzilla.redhat.com/show_bug.cgi?id=824219 The wildcard signature bug in bind in the upstream resolver. > It would be useful for dnssec-trigger to detect this. Can't we just wait for them to upgrade? An actual wildcard detection is very expensive. There are few wildcards at the TLD level (DNSSEC signed) to do the detection with. More realistically, we could probe version.bind, the TXT record? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRd8ORAAoJEJ9vHC1+BF+N85MQAKBPv9iu+/zKFDpNp9ncTM4f PiyV/w9MFCN6vy9RPvDije9d2hA1m5VVc3gOoKo5Ux2EG8al5J2yCZO1e++zW2uG Zis02P1fy+M2v8O9JpseHAg3z/hIozU+9JZjqpooJ3AVp43DNIOtZSE7Bw7ErDVN KNBUEEXz8+Vg6mPGNqdlxn5fEsqeONkSSxkaqp0Dvn75/prgBa4ADFr6KwfeieR2 e6sEC19rcc3Ix4LHpKPRvHmwWHclt2PDLqeqPLWRgF0parDqv14HHYk0xoXXO7Z3 iDrQJrM7by86JxW0OYaOuvu5jeclPGkEdNyPmtI6CZd/YftrqX5VethDdJqgo74p vx1bflNjOiilixuns7TBDcBvXF1Mwd5Ds669zK/DAItr6/qVR/vzKnkSF9gwfDu0 MuxW4znBmuvju2G+N7OpNg1HAw//fsN/tNfDCsAxX+8G2VTLiJRc8sU4YA1VCElP sm5/0ke28YVp2uVjBc0xUNwUxhglk66cx7CY7OVq5nOGaH3Kzz4bRSk+7jsG/yVJ wr7MtxTw1yAKBkFiWcXyTewieWUTZvLCqxlSVEkBbmp4puQbucj+joDuIJQ77AR7 eNSi0vgBbrvAh8Vodk4mdQ80I0roMbBkD2XDQA0KPOjAR8BxgnMHBwfHPnK9qOih uLDs0Yth3yG1EsdnrB1w =o6dM -----END PGP SIGNATURE-----