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...

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.

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]#

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.

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.

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.

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!

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 ?

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

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.

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.

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.

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.