dnscrypt-proxy
Hello, OpenBSD has this package. Is it trustworthy? Anyone uses here? I believe this works with OpenDNS, and a few other providers of "secure" recursive caches that support dnscurve through this package. DNS is probably never going to be secure against attacks in our lifetimes (but, hey, maybe not, due to the recent bruhaha), but at least protecting the "last mile" seems somewhat feasible with this. Any help would be greatly appreciated. Thanks.
Re: VPN Between OpenBSD and iOS
Strangely enough I am having the exact same problem. OPENBSD 5.4, etc. Phase I works once I tweaked my isakmp settings to match IOS7's capabilities (no modp2048 mainly), but I get the same messages Matt does on phase II. I have a npppd PPTP tunnel to the same server that works fine. It is just L2TP/IPSEC that has the issues. Mike
Re: VPN Between OpenBSD and iOS
Jeff,
Here you go:
$ grep -v ^# /etc/npppd/npppd.conf
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
tunnel L2TP_ipv4 protocol l2tp {
listen on 0.0.0.0
}
ipcp IPCP {
pool-address 10.0.0.2-10.0.0.254
dns-servers 8.8.8.8
}
interface pppx0 address 10.0.0.1 ipcp IPCP
bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx0
Thanks,
Matt
On Mon, Dec 30, 2013 at 4:10 PM, Jeff Goettsch wrote:
> What does your npppd.conf look like?
>
>
>
> --
> Jeff Goettsch
> Agricultural and Resource Economics
> http://agecon.ucdavis.edu/
> 530-752-2219
>
>
> On 12/29/13 5:58 PM, Matt Carlson wrote:
>
>> Hello,
>>
>> I'm trying to get my iPhone with iOS 7.0.4 to connect to my OpenBSD
>> VPN server. If I understand the problem correctly, it's unable to
>> negotiate phase 2. I'd welcome any pointers.
>>
>> Below, I've provided the output of uname, rc.conf.local, ipsec.conf,
>> messages, isakmpd.pcap. I changed a couple IP addresses and FQDNs
>> (e.g. 10.a.b.c) and I removed some line from /var/log/messages and
>> replaced them with "", since this is already fairly long.
>>
>> I welcome any suggestions/recommendations.
>>
>> Thanks,
>>
>> Matt
>>
>> # uname -a
>> OpenBSD carbon.my.domain 5.4 GENERIC#37 i386
>> # cat /etc/rc.conf.local
>>
>>
>> ipsec=YES
>> isakmpd_flags="-Kv"
>> ftpproxy_flags=""
>> ntpd_flags=
>> pppd_flags=""
>> route6d_flags=""
>> named_flags=""
>> # grep -v ^# /etc/ipsec.conf
>>
>>
>> ike passive esp transport \
>> proto udp \
>> from any to any port 1701 \
>> main auth "hmac-sha1" enc "aes" group modp1024 \
>> quick auth "hmac-sha1" enc "aes-256" \
>> psk "1"
>> # cat /var/log/messages
>>
>> Dec 29 16:31:23 carbon named[6427]: starting BIND 9.4.2-P2
>> Dec 29 16:31:24 carbon named[6427]: command channel listening on
>> 127.0.0.1#953
>> Dec 29 16:31:24 carbon named[6427]: command channel listening on ::1#953
>> Dec 29 16:31:24 carbon named[6427]: running
>> Dec 29 16:31:26 carbon isakmpd[595]: isakmpd: starting
>> Dec 29 16:31:29 carbon npppd[22659]: Starting npppd pid=22659
>> version=5.0.0
>> Dec 29 16:31:30 carbon isakmpd[28467]: log_packet_init: starting IKE
>> packet
>> capture to file "/var/run/isakmpd.pcap"
>> Dec 29 16:31:30 carbon npppd[22659]: Load configuration
>> from='/etc/npppd/npppd.conf' successfully.
>>
>> Dec 29 16:32:58 carbon isakmpd[28467]: isakmpd: phase 1 done (as
>> responder): initiator id 10.a.b.c, responder id 69.g.h.i, src: 69.g.h.i
>> dst: 166.d.e.f
>> Dec 29 16:32:59 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:32:59 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:02 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:02 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:06 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:06 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:09 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:09 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:12 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:12 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:16 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:16 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:19 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:19 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:22 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:22 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:25 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 2
Re: VPN Between OpenBSD and iOS
Yasuoka, I tried that just now and it doesn't seem to make a difference. Thanks, Matt On Mon, Dec 30, 2013 at 7:34 PM, YASUOKA Masahiko wrote: > Hi, > > On Sun, 29 Dec 2013 20:58:03 -0500 > Matt Carlson wrote: > > # grep -v ^# /etc/ipsec.conf > > > > > > ike passive esp transport \ > >proto udp \ > >from any to any port 1701 \ > >main auth "hmac-sha1" enc "aes" group modp1024 \ > >quick auth "hmac-sha1" enc "aes-256" \ > >psk "1" > > AFAIK, fixed IP address should be used for the source address. > > Does changing > > from any to any port 1701 \ > > to > > from "69.g.h.i" to any port 1701 \ > > fix the problem? > > --yasuoka
smtpd dies with fatal: smtp: ssltree out of sync
Hi, I've just upgraded my OpenBSD-based mail server to: OpenBSD 5.4-current (GENERIC.MP) #187: Sat Dec 28 17:15:20 MST 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP and I cannot figure out where is the problem in my smtpd config: # /etc/mail/smtpd.conf ext_if = re0 max-message-size 35m bounce-warn 4h, 1d, 2d expire 7d pki openbsd.my.domain ca "/etc/ssl/cert.pem" pki openbsd.my.domain key "/etc/mail/certs/smtpd.key" pki openbsd.my.domain dhparams "/etc/mail/certs/dh4096.pem" pki openbsd.my.domain certificate "/etc/mail/certs/smtpd.crt" listen on lo0 listen on $ext_if tls pki openbsd.my.domain auth-optional table aliases db:/etc/mail/aliases.db accept from any for local alias deliver to mbox accept from local for any relay # smtpd -n -f /etc/mail/smtpd.conf configuration OK # smtpd -dvvv -f /etc/mail/smtpd.conf debug: init ssl-tree info: loading pki information for openbsd.my.domain info: OpenSMTPD 5.4.1 starting debug: bounce warning after 4h debug: bounce warning after 1d debug: bounce warning after 2d debug: using "fs" queue backend debug: using "ramqueue" scheduler backend debug: using "ram" stat backend info: startup [debug mode] debug: parent_send_config_ruleset: reloading debug: parent_send_config_mfa: reloading debug: parent_send_config: configuring smtp mfa: building simple chains... mfa: building complex chains... mfa: done building complex chains mfa: done building default chain debug: mfa ready smtpd: fatal: smtp: ssltree out of sync warn: mfa -> smtp: pipe closed warn: control -> smtp: pipe closed warn: parent -> smtp: pipe closed failed to open table aliases warn: mta -> control: pipe closed warn: mda -> control: pipe closed warn: scheduler -> control: pipe closed debug: queue: done loading queue into scheduler warn: queue -> smtp: pipe closed # pgrep -lf smtpd | wc -l 0 Any idea what I'm doing wrong? -- best regards q#
Re: VPN Between OpenBSD and iOS
Hi, On Sun, 29 Dec 2013 20:58:03 -0500 Matt Carlson wrote: > # grep -v ^# /etc/ipsec.conf > > > ike passive esp transport \ >proto udp \ >from any to any port 1701 \ >main auth "hmac-sha1" enc "aes" group modp1024 \ >quick auth "hmac-sha1" enc "aes-256" \ >psk "1" AFAIK, fixed IP address should be used for the source address. Does changing from any to any port 1701 \ to from "69.g.h.i" to any port 1701 \ fix the problem? --yasuoka
Re: unbound dnssec revisited
On Mon, Dec 30, 2013 at 6:10 PM, Remi Locherer wrote: > Having the root.key in a separate directory works. Yes, it works. But "/var/unbound/etc" was the choice during configure which means a little more work: The autotrust path line in unbound.conf needs to be edited with the new root.key path. The new autotrust path must be specified when running unbound-anchor (or the compiled in default will be used). The new autotrust directory must be created with proper permissions. It's not a big deal, and it would maybe add a line or two to the proposed function addition to the rc file, but it would be better to just adjust the configure options when building the package if it's so dangerous to provide the daemon write access to its own configuration directory. I figured if the package creator compiled in those defaults they should be used instead of my original workaround (adding the directory, etc.). Chris
Re: unbound dnssec revisited
On Mon, Dec 30, 2013 at 3:22 PM, Ted Unangst wrote: > More simply, can that file be moved to another location? Then we can > enable write permissions to /var/unbound/etc/autotrust/files/... or > something, without giving away the keys to the whole kingdom. Actually that was close to my first solution, creating and using the /var/unbound/etc/autotrust directory. But then I thought that it might be a bit convoluted.
Re: unbound dnssec revisited
On Mon, Dec 30, 2013 at 03:22:34PM -0500, Ted Unangst wrote: > On Mon, Dec 30, 2013 at 12:10, Chris Smith wrote: > > I've been working on using dnssec with the unbound package and viewing > > some of the threads here on the list regarding this. > > > > Enabling autotrust and the validator module in unbound.conf and > > running unbound-anchor before starting unbound will enable dnssec but > > eventually will log errors of: > > > > could not open autotrust file for writing > > > > This is apparently because the _unbound user or group does not have > > write privileges to the directory, running unbound-anchor with "sudo > > -u _unbound" doesn't change the directory perms. > > That is on purpose. It's very bad for running daemons to have write > privileges. > > There are a couple solutions. More elaborately, it should use some > sort of privelege separation code to communicate with another daemon > if it needs to create new files after startup. > > More simply, can that file be moved to another location? Then we can > enable write permissions to /var/unbound/etc/autotrust/files/... or > something, without giving away the keys to the whole kingdom. Having the root.key in a separate directory works. My unbound.conf file: server: verbosity: 1 interface: 127.0.0.1 interface: ::1 root-hints: "named.cache" auto-trust-anchor-file: "/var/unbound/etc/autotrust/root.key" dlv-anchor-file: "dlv.isc.org.key" remote-control: control-enable: ye The directory structure and permissions: # find /var/unbound/etc -ls 18448664 drwxr-xr-x3 root wheel 512 Dec 30 23:43 /var/unbound/etc 18448674 -rw-r--r--1 root wheel 245 Dec 30 23:44 /var/unbound/etc/unbound.conf 18448704 -rw-r-1 root wheel1281 Feb 6 2011 /var/unbound/etc/unbound_server.key 18448714 -rw-r-1 root wheel1277 Feb 6 2011 /var/unbound/etc/unbound_control.key 18448978 -rw-r--r--1 root wheel3048 Nov 11 18:31 /var/unbound/etc/named.cache 18448734 -rw-r-1 root wheel 790 Feb 6 2011 /var/unbound/etc/unbound_server.pem 18448744 drwxr-xr-x2 _unbound _unbound 512 Dec 30 23:45 /var/unbound/etc/autotrust 18449074 -rw-r--r--1 _unbound _unbound 759 Dec 30 23:45 /var/unbound/etc/autotrust/root.key 18448754 -rw-r-1 root wheel 802 Feb 6 2011 /var/unbound/etc/unbound_control.pem 18448774 -rw-r--r--1 root wheel 386 Feb 6 2011 /var/unbound/etc/dlv.isc.org.key
Re: VPN Between OpenBSD and iOS
What does your npppd.conf look like? -- Jeff Goettsch Agricultural and Resource Economics http://agecon.ucdavis.edu/ 530-752-2219 On 12/29/13 5:58 PM, Matt Carlson wrote: Hello, I'm trying to get my iPhone with iOS 7.0.4 to connect to my OpenBSD VPN server. If I understand the problem correctly, it's unable to negotiate phase 2. I'd welcome any pointers. Below, I've provided the output of uname, rc.conf.local, ipsec.conf, messages, isakmpd.pcap. I changed a couple IP addresses and FQDNs (e.g. 10.a.b.c) and I removed some line from /var/log/messages and replaced them with "", since this is already fairly long. I welcome any suggestions/recommendations. Thanks, Matt # uname -a OpenBSD carbon.my.domain 5.4 GENERIC#37 i386 # cat /etc/rc.conf.local ipsec=YES isakmpd_flags="-Kv" ftpproxy_flags="" ntpd_flags= pppd_flags="" route6d_flags="" named_flags="" # grep -v ^# /etc/ipsec.conf ike passive esp transport \ proto udp \ from any to any port 1701 \ main auth "hmac-sha1" enc "aes" group modp1024 \ quick auth "hmac-sha1" enc "aes-256" \ psk "1" # cat /var/log/messages Dec 29 16:31:23 carbon named[6427]: starting BIND 9.4.2-P2 Dec 29 16:31:24 carbon named[6427]: command channel listening on 127.0.0.1#953 Dec 29 16:31:24 carbon named[6427]: command channel listening on ::1#953 Dec 29 16:31:24 carbon named[6427]: running Dec 29 16:31:26 carbon isakmpd[595]: isakmpd: starting Dec 29 16:31:29 carbon npppd[22659]: Starting npppd pid=22659 version=5.0.0 Dec 29 16:31:30 carbon isakmpd[28467]: log_packet_init: starting IKE packet capture to file "/var/run/isakmpd.pcap" Dec 29 16:31:30 carbon npppd[22659]: Load configuration from='/etc/npppd/npppd.conf' successfully. Dec 29 16:32:58 carbon isakmpd[28467]: isakmpd: phase 1 done (as responder): initiator id 10.a.b.c, responder id 69.g.h.i, src: 69.g.h.i dst: 166.d.e.f Dec 29 16:32:59 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i Dec 29 16:32:59 carbon isakmpd[28467]: dropped message from 166.d.e.f port 48970 due to notification type INVALID_ID_INFORMATION Dec 29 16:33:02 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i Dec 29 16:33:02 carbon isakmpd[28467]: dropped message from 166.d.e.f port 48970 due to notification type INVALID_ID_INFORMATION Dec 29 16:33:06 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i Dec 29 16:33:06 carbon isakmpd[28467]: dropped message from 166.d.e.f port 48970 due to notification type INVALID_ID_INFORMATION Dec 29 16:33:09 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i Dec 29 16:33:09 carbon isakmpd[28467]: dropped message from 166.d.e.f port 48970 due to notification type INVALID_ID_INFORMATION Dec 29 16:33:12 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i Dec 29 16:33:12 carbon isakmpd[28467]: dropped message from 166.d.e.f port 48970 due to notification type INVALID_ID_INFORMATION Dec 29 16:33:16 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i Dec 29 16:33:16 carbon isakmpd[28467]: dropped message from 166.d.e.f port 48970 due to notification type INVALID_ID_INFORMATION Dec 29 16:33:19 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i Dec 29 16:33:19 carbon isakmpd[28467]: dropped message from 166.d.e.f port 48970 due to notification type INVALID_ID_INFORMATION Dec 29 16:33:22 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i Dec 29 16:33:22 carbon isakmpd[28467]: dropped message from 166.d.e.f port 48970 due to notification type INVALID_ID_INFORMATION Dec 29 16:33:25 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i Dec 29 16:33:25 carbon isakmpd[28467]: dropped message from 166.d.e.f port 48970 due to notification type INVALID_ID_INFORMATION Dec 29 16:33:29 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i Dec 29 16:33:29 carbon isakmpd[28467]: dropped message from 166.d.e.f port 48970 due to notification type INVALID_ID_INFORMATION Dec 29 16:33:29 carbon isakmpd[28467]: isakmpd: Peer 166.d.e.f made us delete live SA peer-default for proto 1, initiator id: 10.a.b.c, responder id: 69.g.h.i # tcpdump -vvr /var/run/isakmpd.pcap tcpdump: WARNING: snaplen raised from 116 to 65536 16:32:57.256488 mobile-166-d-e-f.mycingular.net.6885 > c-69.g.h.i.hsd1.va.comcast.net.isakmp: [udp sum o
openbsd snmpd and disk/sensors monitoring
Hello, I'm trying to see if I can switch my new openbsd 5.4 box from net-snmp to snmpd and for now, I miss only 2 things, disk informations and sensors that are not in snmpd.conf man. For disk monitoring, I didn't find information anywhere. Checking the output of snmpwalk, I found the HOST-RESOURCES-MIB::hrStorageSize but the format seems different than net-snmp which makes an update needed to my cacti graph configuration (or did someone made an update openbsd template?). Any translation table? For sensors, I saw the MIB /usr/share/snmp/mibs/OPENBSD-SENSORS-MIB.txt but a snmpwalk of my host gives nothing $ snmpwalk -v2c -c 'MyCommunity' 127.0.0.1 |egrep -i '(sensor|temp|volt)' SNMPv2-MIB::sysORID.10 = OID: OPENBSD-BASE-MIB::sensorsMIBObjects SNMPv2-MIB::sysORDescr.10 = STRING: iso.org.dod.internet.private.enterprises.openBSD.sensorsMIBObjects So not sure if I can get temperature/volts/... from soekris4801. Any pointer? Else, I will probably have to stick to net-snmp or combine both like said http://www.packetmischief.ca/2012/02/26/net-snmp-and-snmpd-coexistence-on-openbsd/ Thanks a lot. Cheers, Julien
Re: unbound dnssec revisited
On Mon, Dec 30, 2013 at 12:10, Chris Smith wrote: > I've been working on using dnssec with the unbound package and viewing > some of the threads here on the list regarding this. > > Enabling autotrust and the validator module in unbound.conf and > running unbound-anchor before starting unbound will enable dnssec but > eventually will log errors of: > > could not open autotrust file for writing > > This is apparently because the _unbound user or group does not have > write privileges to the directory, running unbound-anchor with "sudo > -u _unbound" doesn't change the directory perms. That is on purpose. It's very bad for running daemons to have write privileges. There are a couple solutions. More elaborately, it should use some sort of privelege separation code to communicate with another daemon if it needs to create new files after startup. More simply, can that file be moved to another location? Then we can enable write permissions to /var/unbound/etc/autotrust/files/... or something, without giving away the keys to the whole kingdom.
Re: unbound dnssec revisited
On Mon, Dec 30, 2013 at 12:10 PM, Chris Smith wrote: > And to strongly reiterate that it would be supper to have this product > in base Er.. that it would be SUPER to have this product in base
unbound dnssec revisited
I've been working on using dnssec with the unbound package and viewing
some of the threads here on the list regarding this.
Enabling autotrust and the validator module in unbound.conf and
running unbound-anchor before starting unbound will enable dnssec but
eventually will log errors of:
could not open autotrust file for writing
This is apparently because the _unbound user or group does not have
write privileges to the directory, running unbound-anchor with "sudo
-u _unbound" doesn't change the directory perms.
I'm using the following diff to make this all work (you can all
probably improve on it, and please do):
===
--- unbound.origMon Dec 30 11:03:51 2013
+++ unbound Mon Dec 30 11:38:19 2013
@@ -8,6 +8,14 @@
. /etc/rc.d/rc.subr
pexp="unbound${daemon_flags:+ ${daemon_flags}}"
+
+autotrust() {
+ chgrp _unbound "/var/unbound/etc"
+ chmod 775 "/var/unbound/etc"
+ sudo -u _unbound /usr/local/sbin/unbound-anchor
+ wait
+}
+
rc_reload=NO
rc_pre() {
@@ -16,6 +24,7 @@
-f /var/unbound/etc/unbound_control.pem ]]; then
unbound-control-setup >/dev/null 2>&1
fi
+ autotrust
}
rc_start() {
===
If the autotrust function is run (it can be commented out if desired)
it retrieves the root.key and gives the _unbound group write
privileges to the /var/unbound/etc directory thereby preventing the
above log errors.
I must admit that I'm not sure about the use of "wait" in the added
autotrust function but if I don't use it unbound will not start the
first time (if there is no root.key file), but will on all subsequent
attempts (seems unbound will try to start before the key is
retrieved).
Also discovered that unbound-anchor can retrieve the root.key without
added DNS support which was a concern posted in an earlier thread. For
example on the box I've been working with Unbound is the DNS provider
and resolve.conf points directly (127.0.0.1) and only to it, but yet
with unbound stopped and no DNS support unbound-anchor will retrieve
the key.
Whether or not to run the autotrust function could also be made more
automatic by testing the unbound.conf file (as was previously posted
in another thread).
And to strongly reiterate that it would be supper to have this product
in base as then it would properly start up before the dhcpd daemon so
that addresses could be assigned via hostnames instead of duplicating
the dotted quad work - if one uses hostname lookups in dhcpd then it
will not start if DNS is not up, workarounds notwithstanding.
Chris
Re: Puccini 2x in calendar
On Mon, Dec 30, 2013 at 04:06:03PM +0100, frantisek holop wrote: > hmm, on Sun, Dec 29, 2013 at 06:44:59PM +0001, Jason McIntyre said that > > On Sun, Dec 29, 2013 at 10:52:11AM +0100, frantisek holop wrote: > > > i think he should be removed from birthday: > > > > > > calendar.birthday:12/22 Giacomo Puccini born, 1858 > > > calendar.music:12/22Giacomo Puccini is born in Lucca, Italy, 1858 > > > > > > calendar.music:11/29Giacomo Puccini dies due to throat cancer in > > > Brussels, Belgium, 1924 > > > > > > > i feel a can of worms a-coming... anyway, i removed it from > > calendar.birthday. > > i dont know the policy, but looked at other random > composers and they were only in music... > well, i just meant it's kind of hard to not justify putting some really famous musicians in there. and samuel barber, for one, is still in there. anyway, your diff did seem logical. jmc
Re: Puccini 2x in calendar
hmm, on Sun, Dec 29, 2013 at 06:44:59PM +0001, Jason McIntyre said that > On Sun, Dec 29, 2013 at 10:52:11AM +0100, frantisek holop wrote: > > i think he should be removed from birthday: > > > > calendar.birthday:12/22 Giacomo Puccini born, 1858 > > calendar.music:12/22Giacomo Puccini is born in Lucca, Italy, 1858 > > > > calendar.music:11/29Giacomo Puccini dies due to throat cancer in > > Brussels, Belgium, 1924 > > > > i feel a can of worms a-coming... anyway, i removed it from > calendar.birthday. i dont know the policy, but looked at other random composers and they were only in music... -f -- friends are people you can be quiet with.
