LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   Failed to start BIND (https://www.linuxquestions.org/questions/linux-server-73/failed-to-start-bind-665266/)

ciberrust 08-25-2008 11:47 AM

Failed to start BIND
 
Starting named: /bin/chown: cannot access `/var/named/run-root/var/named': No such file or directory Error in named configuration: none:0: open: /etc/named.conf: file not found [FAILED]



i have that error after following this "tutorial"
http://www.howtoforge.com/creating-y...apache-centos5

the server was already running for quite time now so i really have no idea what it has on it

Actually i've problems with bind, i don't have much knowledge on how to install it.
I;ve always use the name servers that provides the domain sellers...

salasi 08-25-2008 12:53 PM

Are you trying to run Bind 'chrooted'? (Chrooting is more difficult to set up initially for the uninitiated, but is potentially more secure.)

One common problem with running chrooted is that all path are relative to the chroot directory and it is the files relative to this path that the permissions have to be correct.

Have you tried running from the command line so you can see all of the error messages?

And I'm not sure what you are trying to achieve - you want to run bind for apache but is this serving internal clients only or are you trying to create a web site for external clients (as well)? Hosting a web site for the outside world is not something to be taken lightly.

ciberrust 08-25-2008 12:59 PM

well this is the output from console

[root@alpha etc]# service named start
Starting named: /bin/chown: cannot access `/var/named/run-root/var/named': No such file or directory

Error in named configuration:
none:0: open: /etc/named.conf: file not found
[FAILED]
[root@alpha etc]#


what we need to do is provide a name server to the client who has his domain. could be something like ns1.alpha.com


the page is also hosted in the server.


now i checked all i could and all the files i can look for are in the rigth place

[root@alpha etc]# cd /var/named
[root@alpha named]# ls
chroot alpha.com.db localhost.zone named.ca named.local run-root
data localdomain.zone named.broadcast named.ip6.local named.zero slaves
[root@alpha named]#


except for this


[root@alpha var]# ls
212.146.220.in-addr.arpa localhost.rev make-localhost PROTO.localhost.rev
f-in.com localhost.rev.saved_by_psa named.root run
[root@alpha var]# pwd
/var/named/run-root/var
[root@alpha var]#

trickykid 08-25-2008 01:42 PM

Quote:

Originally Posted by salasi (Post 3259220)
(Chrooting is more difficult to set up initially for the uninitiated, but is potentially more secure.)

chroot being more secure is a usual misconception. Sure it's one more tedious task that frustrates a possible cracker but most don't realize that if someone gains unauthorized access to a system, most of the time they somehow manage to become root and chroot really doesn't apply at that point as it's easy to circumvent around the chroot'd environment setup.

Just thought I'd throw that out there for anyone that wasn't aware.

chort 08-25-2008 03:04 PM

When BIND runs chroot'd it revokes it's privileges, so yes, chrooting BIND is more secure.

trickykid 08-25-2008 04:03 PM

Quote:

Originally Posted by chort (Post 3259400)
When BIND runs chroot'd it revokes it's privileges, so yes, chrooting BIND is more secure.

Yeah but if someone gains access as root user, what's preventing them from reconfiguring, that's the whole point, not just BIND related vulnerabilities, etc. ;)

chort 08-25-2008 04:34 PM

Well if they gained root, they wouldn't have done it through BIND... the whole point of putting BIND in a chroot is that if someone manages to compromise BIND they won't get root.

trickykid 08-25-2008 04:43 PM

Quote:

Originally Posted by chort (Post 3259485)
Well if they gained root, they wouldn't have done it through BIND... the whole point of putting BIND in a chroot is that if someone manages to compromise BIND they won't get root.

Understood, I was just trying to present those that believe chroot is a full way of securing a service, etc. I've met people who thought otherwise.

chort 08-25-2008 05:39 PM

I'm slightly baffled why you would bring that up since it's irrelevant in this case.

trickykid 08-25-2008 09:18 PM

Quote:

Originally Posted by chort (Post 3259539)
I'm slightly baffled why you would bring that up since it's irrelevant in this case.

I replied specifically to #2 as I quoted the specifics in my post #4, that's why it was brought up cause I don't believe chroot makes it any more secure in most cases. I'm just sharing information for crying out loud, geez!

chort 08-25-2008 09:40 PM

And I'm pointing out that in the case of BIND, which is what the OP is actually trying to chroot, it does make a difference, so don't discourage them from setting up their service securely. Maybe other services run as root inside their chroot, but BIND does not.

Any way, to the OP, have you tried
Code:

# mkdir -p /var/named/run-root/var/named
?

PS What OS are you setting this up on? Centos doesn't create a /var/named/run-root by default.

trickykid 08-25-2008 09:46 PM

Quote:

Originally Posted by chort (Post 3259718)
And I'm pointing out that in the case of BIND, which is what the OP is actually trying to chroot, it does make a difference, so don't discourage them from setting up their service securely. Maybe other services run as root inside their chroot, but BIND does not.

I'm not trying to discourage as I wasn't quoting the OP, but the first responder and their "potentially more secure" quote as I feel chroot is not a security tool, it's not what it was intended for. It's almost like security through obscurity in a sense.

Okay, I'm done, let's move on now, sorry I brought up the information, I'll keep such info to myself now instead of maybe sharing info that some might benefit from knowing that chroot isn't a total fool proof way to secure a service or a machine.

salasi 08-26-2008 05:27 AM

Quote:

Originally Posted by trickykid (Post 3259725)
I'm not trying to discourage as I wasn't quoting the OP, but the first responder and their "potentially more secure" quote as I feel chroot is not a security tool, it's not what it was intended for. It's almost like security through obscurity in a sense.

I'm sticking with 'potentially more secure'. At no point did I claim that chroot was a security tool, per se, just that bind was potentially more secure set up that way. Its not the be-all and end-all of security, but no one thing ever is and it can be somewhat helpful in certain circumstances. And I was trying to avoid confusing the OP with too much detail that I was concerned that would just confuse... that turned out not to be at all helpful, so I am sorry for that.

the usual problems with a chrooted installation are:
  • The set of files that need to be duplicated to the new chrooted location aren't all there
  • Permissions. The effective user (the user that Bind runs as, once it has thrown off root permissions) needs to have appropriate permissions. that can be read and write access to files or it can be access to directories.
This is easier if you can log in as the effective user, but you need to look at the error messages one by one, find out whether it is file permissions or directory permissions that have caused it, and put it right. You may even have to 'touch' the odd file to bring it into existence so that Bind can then modify them. But that's it for getting Bind running.

trickykid 08-26-2008 08:04 AM

Quote:

Originally Posted by salasi (Post 3260012)
At no point did I claim that chroot was a security tool, per se, just that bind was potentially more secure set up that way. Its not the be-all and end-all of security, but no one thing ever is and it can be somewhat helpful in certain circumstances.

Understood and I wasn't making any claims that you were saying otherwise. I simply wanted to point out to anyone reading this thread that chroot is not a fool proof security tool. When I reply to a post in this type of sense, I'm not directing it at anyone, I'm speaking to potentially all members and guests on this site. ;)

ciberrust 08-26-2008 10:56 AM

Quote:

Originally Posted by chort (Post 3259718)
PS What OS are you setting this up on? Centos doesn't create a /var/named/run-root by default.

CentOS release 4.6 (Final)

ok i ran the command to create the dir

mkdir -p /var/named/run-root/var/named

and now i got this error

Failed to start BIND : Starting named: Error in named configuration: none:0: open: /etc/named.conf: file not found [FAILED]

but i have that file on that dir...

so i have no clue what's happening.


All times are GMT -5. The time now is 12:23 AM.