Re: Big Sur on M1 - bind9 named daemon don't run

[Mark Lucas]

Having fixed the ownership and managed to manually startup named, the temp log 
produced cryptically ended by saying;
22-Sep-2022 16:44:15.726 general: critical: loading configuration: file not 
found
22-Sep-2022 16:44:15.727 general: critical: exiting (due to fatal error)
Turns out that for some reason the directory specified in the config supposed 
to contain the logs had been deleted.
You'd think named-checkconf might have picked that up.
Thanks for all the help.

> On 22 Sep 2022, at 16:50, Bill Cole 
>  wrote:
> 
> On 2022-09-22 at 10:27:16 UTC-0400 (Thu, 22 Sep 2022 10:27:16 -0400)
> Daniel J. Luke mailto:dl...@geeklair.net>>
> is rumored to have said:
> 
>>> On Sep 22, 2022, at 8:56 AM, Mark Lucas >> > wrote:
>>> I just updated to bind 9.18.7 (Intel mac mini - macOS 12.6 ) and despite 
>>> checking the config was ok, which it was, bind refuses to start.
>>> Looking at the contents of /opt/local/var/named/ mysteriously most of the 
>>> files were now listed as being owned by non existent user 511.
>>> e.g. -rw-r--r--   1 511named  -   3.2K  4 Aug  2021 named.root
>>> Tried uninstalling and reinstalling bind9 and changing 
>>> /opt/local/var/named/ files owner to named but the problem remains.
> 
> named.root is the historical name of the root cache for BIND. Identical to 
> what MacPorts installs as db.cache.dist. The directory /opt/local/var/named/ 
> and everything in it should be owned by user and group 'named'
> 
> It looks possible that you've somehow had the user 'named' deleted (and it 
> formerly had id 511.) That would cause permission problems.
> 
>> 
>> I think the permissions stuff is unrelated to the port - it only installs 
>> these files into /opt/local/var/named:
>> 
>> % port contents bind9 | grep /opt/local/var/named
>>  /opt/local/var/named/db.127.0.0.dist
>>  /opt/local/var/named/db.cache.dist
>>  /opt/local/var/named/db.localhost.dist
>> 
>> You can try to start named by hand with `-g` (and maybe add a -d # option) 
>> to try to get more information on why it's not starting for you.
>> 
>> -- 
>> Daniel J. Luke
> 
> 
> -- 
> Bill Cole
> b...@scconsult.com  or billc...@apache.org 
> 
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire

Re: Big Sur on M1 - bind9 named daemon don't run

[Bill Cole]

On 2022-09-22 at 10:55:06 UTC-0400 (Thu, 22 Sep 2022 15:55:06 +0100)
Mark Lucas 
is rumored to have said:

Sorry to probably ask the obvious but what command do I use to start 
it manually?


/opt/local/sbin/named -g -u named

That will start named in the foreground of your terminal and force all 
logging to the terminal on the 'standard error' file descriptor, so 
you'll see anything named emits as an error.


You can add a "-d #' option where '#' is a digit with higher numbers 
giving more detail. If running without that option does not give you 
anything helpful, start with '-d 1' and if you don't get anything, try 2 
then 3 etc. If mem ory serves me, there's a level (4? 5?) where the 
volume of output precludes eyeball analysis. You should not need that.





On 22 Sep 2022, at 15:27, Daniel J. Luke  wrote:


On Sep 22, 2022, at 8:56 AM, Mark Lucas  wrote:
I just updated to bind 9.18.7 (Intel mac mini - macOS 12.6 ) and 
despite checking the config was ok, which it was, bind refuses to 
start.
Looking at the contents of /opt/local/var/named/ mysteriously most 
of the files were now listed as being owned by non existent user 
511.
e.g. -rw-r--r--   1 511named  -   3.2K  4 Aug  2021 
named.root
Tried uninstalling and reinstalling bind9 and changing 
/opt/local/var/named/ files owner to named but the problem remains.


I think the permissions stuff is unrelated to the port - it only 
installs these files into /opt/local/var/named:


% port contents bind9 | grep /opt/local/var/named
 /opt/local/var/named/db.127.0.0.dist
 /opt/local/var/named/db.cache.dist
 /opt/local/var/named/db.localhost.dist

You can try to start named by hand with `-g` (and maybe add a -d # 
option) to try to get more information on why it's not starting for 
you.


--
Daniel J. Luke




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Big Sur on M1 - bind9 named daemon don't run

[Bill Cole]

On 2022-09-22 at 10:27:16 UTC-0400 (Thu, 22 Sep 2022 10:27:16 -0400)
Daniel J. Luke 
is rumored to have said:


On Sep 22, 2022, at 8:56 AM, Mark Lucas  wrote:
I just updated to bind 9.18.7 (Intel mac mini - macOS 12.6 ) and 
despite checking the config was ok, which it was, bind refuses to 
start.
Looking at the contents of /opt/local/var/named/ mysteriously most of 
the files were now listed as being owned by non existent user 511.
e.g. -rw-r--r--   1 511named  -   3.2K  4 Aug  2021 
named.root
Tried uninstalling and reinstalling bind9 and changing 
/opt/local/var/named/ files owner to named but the problem remains.


named.root is the historical name of the root cache for BIND. Identical 
to what MacPorts installs as db.cache.dist. The directory 
/opt/local/var/named/ and everything in it should be owned by user and 
group 'named'


It looks possible that you've somehow had the user 'named' deleted (and 
it formerly had id 511.) That would cause permission problems.




I think the permissions stuff is unrelated to the port - it only 
installs these files into /opt/local/var/named:


% port contents bind9 | grep /opt/local/var/named
  /opt/local/var/named/db.127.0.0.dist
  /opt/local/var/named/db.cache.dist
  /opt/local/var/named/db.localhost.dist

You can try to start named by hand with `-g` (and maybe add a -d # 
option) to try to get more information on why it's not starting for 
you.


--
Daniel J. Luke



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Big Sur on M1 - bind9 named daemon don't run

[Mark Lucas]

Sorry to probably ask the obvious but what command do I use to start it 
manually?

> On 22 Sep 2022, at 15:27, Daniel J. Luke  wrote:
> 
>> On Sep 22, 2022, at 8:56 AM, Mark Lucas  wrote:
>> I just updated to bind 9.18.7 (Intel mac mini - macOS 12.6 ) and despite 
>> checking the config was ok, which it was, bind refuses to start. 
>> Looking at the contents of /opt/local/var/named/ mysteriously most of the 
>> files were now listed as being owned by non existent user 511. 
>> e.g. -rw-r--r--   1 511named  -   3.2K  4 Aug  2021 named.root
>> Tried uninstalling and reinstalling bind9 and changing /opt/local/var/named/ 
>> files owner to named but the problem remains.
> 
> I think the permissions stuff is unrelated to the port - it only installs 
> these files into /opt/local/var/named:
> 
> % port contents bind9 | grep /opt/local/var/named
>  /opt/local/var/named/db.127.0.0.dist
>  /opt/local/var/named/db.cache.dist
>  /opt/local/var/named/db.localhost.dist
> 
> You can try to start named by hand with `-g` (and maybe add a -d # option) to 
> try to get more information on why it's not starting for you.
> 
> -- 
> Daniel J. Luke
> 

Re: Big Sur on M1 - bind9 named daemon don't run

[Daniel J. Luke]

> On Sep 22, 2022, at 8:56 AM, Mark Lucas  wrote:
> I just updated to bind 9.18.7 (Intel mac mini - macOS 12.6 ) and despite 
> checking the config was ok, which it was, bind refuses to start. 
> Looking at the contents of /opt/local/var/named/ mysteriously most of the 
> files were now listed as being owned by non existent user 511. 
> e.g. -rw-r--r--   1 511named  -   3.2K  4 Aug  2021 named.root
> Tried uninstalling and reinstalling bind9 and changing /opt/local/var/named/ 
> files owner to named but the problem remains.

I think the permissions stuff is unrelated to the port - it only installs these 
files into /opt/local/var/named:

% port contents bind9 | grep /opt/local/var/named
  /opt/local/var/named/db.127.0.0.dist
  /opt/local/var/named/db.cache.dist
  /opt/local/var/named/db.localhost.dist

You can try to start named by hand with `-g` (and maybe add a -d # option) to 
try to get more information on why it's not starting for you.

-- 
Daniel J. Luke

Re: Big Sur on M1 - bind9 named daemon don't run

[Daniel J. Luke]

On Aug 31, 2021, at 8:52 AM, FritzS GMX  wrote:
>>> But the named daemon don't run. 
>>> 
>>> All this commands don’t work:
>>> 
>>> sudo launchctl load -wF /Library/LaunchDaemons/org.macports.bind9.plist
>>> 
>>> sudo /opt/local/bin/port load bind9
>>> 
>>> sudo /opt/local/sbin/rndc reload
>>> 
>>> What must I do that the named daemon runs?
>> 
>> Why don't the above commands work? What happens?
> 
> No, there are no inputs in the own bind9 logging files, no logging files 
> available.

(sorry for the necro-thread) -

I saw similar behavior today (with bind 9.18.7), no logging, no debug output 
from named. Under the debugger I could see that there's a fork() and the parent 
doesn't get the response it expects from the child and so terminates. 

A little more digging showed me that my previously valid named.conf was now 
invalid (named-checkconf was able to point out exactly the problem). I updated 
named.conf and things are working as expected.

Just something to look at if you (or anyone looking at the list archive) sees 
random failures like above. It's really too bad that named doesn't generate 
some output to at least point you in the right direction for this case.

-- 
Daniel J. Luke

Re: Big Sur on M1 - bind9 named daemon don't run

[FritzS GMX]

> Am 31.08.2021 um 11:51 schrieb Ryan Schmidt :
> 
> On Aug 25, 2021, at 02:00, FritzS GMX wrote:
> 
>> after migration from my profile & apps from ElCapitan to Big Sur I 
>> reinstalled all the MacPorts programs,
>> bind9 are new compiled on my MacMini M1 too.
>> 
>> But the named daemon don't run. 
>> 
>> All this commands don’t work:
>> 
>> sudo launchctl load -wF /Library/LaunchDaemons/org.macports.bind9.plist
>> 
>> sudo /opt/local/bin/port load bind9
>> 
>> sudo /opt/local/sbin/rndc reload
>> 
>> What must I do that the named daemon runs?
> 
> Why don't the above commands work? What happens?
> 
> If you were expecting a process to be running after running those commands, 
> and that process is not running, is it crashing? Is the OS creating crash 
> logs in the usual directory? If so, show us one. Or, if no crash logs, does 
> the Console indicate that the process is being restarted every 10 seconds and 
> immediately quitting itself? Does the process write its own log file, and if 
> so, does it contain anything explaining why it isn't staying running?
> 

No, there are no inputs in the own bind9 logging files, no logging files 
available.

Named are allowed in the firewall.

/opt/local/var/run/named/session.key are available and have a actual timestamp

[code]
sudo /opt/local/sbin/rndc-confgen -a
wrote key file "/opt/local/etc/rndc.key“
[/code

named.pid are not seen on this path
[code]
dnssec-validation auto;

pid-file "/opt/local/var/run/named/named.pid";
[/code]

Hint from
https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

[code]
sudo spctl --assess --type execute /opt/local/sbin/named
objc[15229]: Class SPExecutionPolicy is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[15229]: Class AppWrapper is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[15229]: Class AppWrapperPolicyResult is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[15229]: Class AppWrapperPolicy is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[15229]: Class SPLog is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[15229]: Class MIS is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[15229]: Class SPExecutionHistoryItem is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[15229]: Class SPExecutionPolicyItem is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[15229]: Class SPDeveloperPolicy is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[15229]: Class GKScanResult is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
/opt/local/sbin/named: rejected
[/code]

[code]
spctl --assess --verbose=4  /opt/local/sbin/named   
  
objc[16419]: Class SPExecutionPolicy is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[16419]: Class AppWrapper is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[16419]: Class AppWrapperPolicyResult is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[16419]: Class AppWrapperPolicy is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
 and /usr/sbin/spctl. One of the two will be used. Which one is undefined.
objc[16419]: Class SPLog is implemented in both 
/System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPol

Re: Big Sur on M1 - bind9 named daemon don't run

[Ryan Schmidt]

On Aug 25, 2021, at 02:00, FritzS GMX wrote:

> after migration from my profile & apps from ElCapitan to Big Sur I 
> reinstalled all the MacPorts programs,
> bind9 are new compiled on my MacMini M1 too.
> 
> But the named daemon don't run. 
> 
> All this commands don’t work:
> 
> sudo launchctl load -wF /Library/LaunchDaemons/org.macports.bind9.plist
> 
> sudo /opt/local/bin/port load bind9
> 
> sudo /opt/local/sbin/rndc reload
> 
> What must I do that the named daemon runs?

Why don't the above commands work? What happens?

If you were expecting a process to be running after running those commands, and 
that process is not running, is it crashing? Is the OS creating crash logs in 
the usual directory? If so, show us one. Or, if no crash logs, does the Console 
indicate that the process is being restarted every 10 seconds and immediately 
quitting itself? Does the process write its own log file, and if so, does it 
contain anything explaining why it isn't staying running?


> Ist that a way for BigSur 11.5.2 on a Mac mini (M1, 2020)?
> https://trac.macports.org/wiki/howto/ShareArchives2

I'm not sure what the documentation about how to share archives between 
machines has to do with your present problem.

Big Sur on M1 - bind9 named daemon don't run

[FritzS GMX]

after migration from my profile & apps from ElCapitan to Big Sur I reinstalled 
all the MacPorts programs,
bind9 are new compiled on my MacMini M1 too.

But the named daemon don't run. 

All this commands don’t work:

sudo launchctl load -wF /Library/LaunchDaemons/org.macports.bind9.plist

sudo /opt/local/bin/port load bind9

sudo /opt/local/sbin/rndc reload

What must I do that the named daemon runs?

Ist that a way for BigSur 11.5.2 on a Mac mini (M1, 2020)?
https://trac.macports.org/wiki/howto/ShareArchives2

-- 
FritzS 
fri...@gmx.net