1 of 1 people found this helpful
try to check this (required) conditions:
- User account needs to be configured to allow remote telnet or SSH access to BIND machine
- Read and write file access is required for all BIND configuration files
- /etc/named.conf, and all included files
- all zone data files
- Read and write access to system temp directory /tmp
I'm working with info dev on fixing the help link.
also, just FYI, this also needs to be supported in your environment:
IPAM utilizes both standard Linux commands (POSIX) and BIND specific commands that are required for IPAM BIND management functionality.
- if [ -r "filepath" ] ; then echo 'true'; else echo 'false'; fi
- if [ -w "filepath" ] ; then echo 'true'; else echo 'false'; fi
- if [ $? -eq 0 ] ; then echo 'true'; else echo 'false'; fi
I've verified all this. I'm able to edit the named.conf file and all files in the bind directory, I've created a file in /tmp to verify write access, and I'm able to SSH in remotely from the Orion server. I've also verified that the user account can run all the commands shown in the documentation. One thing I will mention is that my particular BIND install is in a jailed setup on Ubuntu, so the location is actually /var/lib/named. However, I have a symlink setup for named.conf at /etc/named.conf. I'm wondering now if I need symlinks for all the files in /etc that it's expecting to see.
of you have read/write access to /var/lib/named it should work. The best way to go is now contact our support and they may get diagnostics from your machine.
I'm running into a very similar issue with a jailed environment, except I'm getting the error 'Syntax Error in BIND configuration'. It works fine if I use the root user. What I've found is that when you attempt to test the BIND credentials from the setup wizard, IPAM will login to your box as the specified user, and runs these commands:
ps -A -o comm,pid,args | grep ^named
if [ -r "/var/named/chroot/etc/named.conf" ] ; then echo 'true'; else echo 'false'; fi
if [ -w "/var/named/chroot/etc/named.conf" ] ; then echo 'true'; else echo 'false'; fi
named-checkconf -z -t "/var/named/chroot" "/etc/named.conf"
if [ $? -eq 0 ] ; then echo 'true'; else echo 'false'; fi
In my case, IPAM is getting down to the command named-checkconf -z -t "/var/named/chroot" "/etc/named.conf" and then receiving the error: isc_dir_chroot: permission denied
I'm still not exactly clear why this fails, but I think it's because a non-root user is attempting to run a chroot command, which is not allowed. michal.hrncirik -- Is the '-t' option necessary for the verification?
I apologize for the reply to an apparently old question. I worked for a few months with various engineers and ended up with Michal and a second set of developers.
We found that after all permissions on files are correct the "insufficient read access privileges to /etc/named.conf" is still encountered.
In the end the problem is that IPAM cannot handle special characters in the bash prompt (~ [ ] etc.)
This is why running the commands by hand gives expected reults.
When using an account configured just for IPAM, I just changed the bash prompt and it started working the prompt I used:
export PS1="\u$ "
Apparently, the $ is an acceptable special character.