Probably not a bug. But I need help!
I've read the fine manual(s). Many times.
I still can't figure it out.
The nsd daemon will not start at boot time.
It will start and run by hand later.
There is NOTHING in the logs indicating what the failure was.
In fact, the logs indicate that everything i
--- Ian Darwin wrote:
> Try doing it by the book, i.e., rcctl start nsd
> If it fails silently, try rcctl -d start nsd
Thanks for that.
I haven't upgraded my OpenBSD boxes in some years,
so I didn't know about it.
I have nsd working now, serving up my local DNS names.
Unbound is still not workin
What am I doing wrong??? I'm using nsd on OpenBSD.
nsd works only in the forward direction: from a name to an IP address.
I'm using my named zone files from way back.
nsd-checkzone says that the zone files are good.
Here are the startup logs for nsd:
--
I asked:
>> nsd works only in the forward direction: from a name to an IP address.
>> I'm using my named zone files from way back.
--- Amelia A Lewis wrote:
> $ORIGIN
>
> You haven't got one. You have a comment saying what the origin is,
> but no $ORIGIN directive in the example supplied.
Adding
Nope. I still don't have it working.
NSD is working in both directions.
Unbound is only working in the forward direction.
Here is proof that both Unbound and NSD are working in the forward direction:
7 Soekris2# nslookup
I appreciate your help!
Either you solved the previous problem telling me to put $ORIGIN in my BIND
zone files,
or I had made a mistake with the 'set port=number' command in nslookup.
In either case NSD is now working properly in both directions.
But Unbound is only working correctly in the forw
I have a few TrueRNG hardware random number generators.
They are USB devices, and generally appear as modems.
How do I use them to continuously seed /dev/random with new truly random
numbers?
It's got to be something very simple like
tail -f /dev/TrueRNG > /dev/random
or something like that. R
I wrote:
>> How do I use a hardware random number generator to
>> continuously seed /dev/random with new truly random numbers?
--- Theo de Raadt wrote:
> We consider these devices boring, because the kernel does a good enough job
> creating random.
> randomness only has a bootstrap problem. And
--- Theo de Raadt wrote:
> And I don't give a rats ass about a cheap-ass garbage usb device
> that can't even afford to allocate a proper usb device ID.
> I don't care.
I get that you think I'm wrong (and maybe I am!)
but I don't yet understand why.
Can you point me to some literature on the topi
--- Theo de Raadt wrote:
> And I went out of my way to politely explain it to you
I would like a more detailed explanation, because I don't yet understand.
That's why I asked for literature I could read.
Thanks,
Ken
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole u
Thanks for all of the help so far, but I am completely failing.
Nothing I have tried will make unbound work.
What I would like to do now is make the *simplest possible*
unbound.conf file and get it working.
Then I want to add more and more stuff, to get the point I want.
I have searched for such
--- I asked:
> What I would like to do now is make the *simplest
> possible* unbound.conf file and get it working.
Thinking that an absolutely empty unbound.conf file
would be the simplest, I tried it. It doesn't work.
Can anybody help me with the simplest possible
unbound.conf file???
Thanks,
I said:
> Thinking that an absolutely empty unbound.conf file
> would be the simplest, I tried it. It doesn't work.
However, unbound-checkconf likes it just fine.
$ unbound-checkconf /var/unbound/etc/unbound.conf
unbound-checkconf: no errors in /var/unbound/etc/unbound.conf
CONFIDENTIALIT
--- I said:
> Thinking that an absolutely empty unbound.conf file would be the
> simplest, I tried it. It doesn't work.
Nope. That is not true.
I don't know how it happened, but my box wound up without a default route.
An absolutely empty unbound.conf works just fine.
Thanks,
Ken
CONFID
14 matches
Mail list logo
