Unknown Authn provider: ldap
a2enmod authnz_ldap
apache2ctl restart
Unknown Authn provider: ldap
a2enmod authnz_ldap
apache2ctl restart
On Ubuntu or Debian:
apt-cache search php|egrep ^php5-
apt-get install php5-mcrypt
bind9 runs in a chroot environment on lenny. The service can be started as usual:
# /etc/init.d/bind9 start
Starting domain name service...: bind9.
Let’s check bind9 status:
# /etc/init.d/bind9 status
bind9 is not running failed!
Well, the first thing I did was to check the log file, in which I found no error related to named. So I tried another way to check the status:
# rndc status
version: 9.6-ESV-R3
CPUs found: 1
worker threads: 1
number of zones: 17
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
I was convinced that dns service was running. So what went wrong? It must be something in the /etc/init.d/bind9 script that incorrectly reports bind9 status. Opened up this file, I found:
...
PIDFILE=/var/run/bind/run/named.pid
...
Ah ha, the default location of named.pid is in /var/run/bind/run. In my case, named.pid is located in /var/chroot/var/run/bind/run/named.pid. Therefore in order to fix this, we just need to point PIDFILE to the correct file.
PIDFILE=/var/chroot/var/run/bind/run/named.pid
Save bind9 script, and check bind9 status again:
# /etc/init.d/bind9 status
bind9 is running.
On Debian:
# apt-get install libnet-ldap-perl
$ sudo visudo
Look for line begins with Defaults, and append insults to the end.
Defaults env_reset,insults
Save it, and clear the sudo session (sudo -K), and try sudo with a wrong password.