I am trying to use the Openldap dynamic configuration. I have an error being displayed as I try and add in the following :
add: olcMirrorMode
olcMirrorMode: TRUE
error(80)
additional info: <olcMirrorMode> database is not a shadow
Can anyone explain how to rid this error and what I need setup in order for the olcMirrorMode to be added in the daemon configuration?
Thanks :-)
I had similar problems, so hopefully this might help.
Mirrormode should be set up only on databases that you want to replicate, and the olcMirrorMode should be set after you've set up any and all syncrepl commands.
Assuming you're trying to do n-master replication
Set up your syncrepl statments.
Once thats done turn on mirrormode. The catch for me was that I had to do a modify/add rather than a straight add to get it to accept mirrormode:
dn: olcDatabase={1}bdb,cn=config
changetype: modify
add: olcMirrorMode
olcMirrorMode: TRUE
Configure OpenLDAP like below on first Server.
[root#dhcp200 ~]# cat /etc/openldap/slapd.conf |grep -v '^#' |grep -v '^$'
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/ppolicy.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
modulepath /usr/lib64/openldap
moduleload syncprov.la
loglevel sync
database bdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index entryCSN eq
index entryUUID eq
serverID 2
syncrepl rid=001
provider=ldap://192.168.122.204:389
bindmethod=simple
binddn="cn=Manager,dc=example,dc=com"
credentials=secret
searchbase="dc=example,dc=com"
attrs=",+"
schemachecking=off
type=refreshAndPersist
retry="1 +"
mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
Configure slapd.conf like below in Second server.
[root#test6 ~]# cat /etc/openldap/slapd.conf |grep -v '^#' |grep -v '^$'
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/ppolicy.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
modulepath /usr/lib64/openldap
moduleload syncprov.la
loglevel sync
database bdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index entryCSN eq
index entryUUID eq
serverID 1
syncrepl rid=001
provider=ldap://192.168.122.200:389
bindmethod=simple
binddn="cn=Manager,dc=example,dc=com"
credentials=secret
searchbase="dc=example,dc=com"
attrs=",+"
schemachecking=off
type=refreshAndPersist
retry="1 +"
mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
If you want to use cn=config method, then convert it to cn=config format using
# rm -rvf /etc/openldap/slapd.d/
# mkdir /etc/openldap/slapd.d/
# slaptest -f slapd.conf -F /etc/openldap/slapd.d/
# rm slapd.conf
# chown -R ldap:ldap /etc/openldap/slapd.d/
Start service of slapd on both servers.
# service slapd start
Related
I am planning to reinstall CentOS 6 system on dedicated server which was running Wordpress websites at Plesk 11.5 hosting program. Due to removal of php files ($##% php update...), some Plesk dependant files have been removed and I am unable to access Plesk administration panel (to backup files via GUI). I have copied all files from /var/lib/psa/dumps to FTP server.
According to this information all of backup files are located there by default. If I copy them after reinstalling, to the same location, is it possible to completely restore websites with corresponding databases?
There is a comprehensive guide on how to restore Plesk for Linux installation on another server after a disaster in Plesk help center.
Plesk Onyx and Plesk 12.5
1. Important: This step is only possible if the version of MySQL server matches for both the original and new server's one.
Start the MySQL server with the datadir parameter in /etc/my.cnf pointing to the MySQL database location on the old drive ( /old/var/lib/mysql):
# cat /etc/my.cnf | grep datadir
datadir=/old/var/lib/mysql
and dump the databases:
# MYSQL_PWD=`cat /old/etc/psa/.psa.shadow` mysql -u admin psa -Ns -e"select name from data_bases where type = 'mysql'" | while read dbname ; do MYSQL_PWD=`cat /old/etc/psa/.psa.shadow` mysqldump -u admin --databases $dbname > $dbname.sql ; done
Stop MySQL, revert the datadir parameter in /etc/my.cnf to its original value:
# service mysqld stop
# cat /etc/my.cnf | grep datadir
datadir=/var/lib/mysql
Start MySQL and restore the databases:
# service mysqld start
# for f in .sql ; do dbname=$(echo $f | sed -e 's/\(.sql\)$//g'); MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin -D$dbname < $f; echo "$dbname restored" ; done
2. Restore the Plesk databases from the available dump:
Stop the Plesk service:
# service psa stopall
Import the database dump:
# zcat /old/var/lib/psa/dumps/mysql.daily.dump.0.gz | MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin
3. Copy the Plesk database password file:
# cp -rpf /old/etc/psa/.psa.shadow /etc/psa/.psa.shadow
4. Copy the encryption key to the new server, set the correct permissions and restart MySQL service:
# cp /etc/psa/private/secret_key /etc/psa/private/secret_key.save
# cp -rpf /old/etc/psa/private/secret_key /etc/psa/private/secret_key
# chmod 0600 /etc/psa/private/secret_key
# chown psaadm:root /etc/psa/private/secret_key
# service mysqld restart
Note: make sure that MySQL is accessible using MYSQL_PWD=cat /etc/psa/.psa.shadow mysql -u admin
5. Restore domain content:
# rsync -av /old/var/www/vhosts/ /var/www/vhosts/
6. Restore Plesk system users:
# MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin -Dpsa -Ns -e"select s.login, a.password, s.home, s.shell from sys_users s, accounts a where a.id = s.account_id" | awk '{ print "PSA_PASSWD=\\x27" $2 "\\x27 /usr/local/psa/admin/sbin/usermng --add-user --user=" $1 " --homedir=" $3 " --shell=" ($4?$4:"/bin/false")}' | sh -x
7. Restore the mailnames directory (mail content):
# rsync -av /old/var/qmail/mailnames/ /var/qmail/mailnames/
# chown -R popuser:popuser /var/qmail/mailnames/*
8. For Plesk Onyx and Plesk 12.5, run fully automated reconfiguration utility:
# plesk repair all -y
9. Start the Plesk service:
# service psa start
Plesk 9.x - 12.0
1. Important: This step is only possible if the version of MySQL server matches for both the original and new server's one.
Start the MySQL server with the datadir parameter in /etc/my.cnf pointing to the MySQL database location on the old drive ( /old/var/lib/mysql):
# cat /etc/my.cnf | grep datadir
datadir=/old/var/lib/mysql
and dump the databases:
# MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin psa -Ns -e"select name from data_bases where type = 'mysql'" | while read dbname ; do MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysqldump -u admin --databases $dbname > $dbname.sql ; done
Stop MySQL, revert the datadir parameter in /etc/my.cnf to its original value:
# service mysqld stop
# cat /etc/my.cnf | grep datadir
datadir=/var/lib/mysql
Start MySQL and restore the databases:
# service mysqld start
# for f in .sql ; do dbname=$(echo $f | sed -e 's/\(.sql\)$//g'); MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin -D$dbname < $f; echo "$dbname restored" ; done
2. Restore the Plesk databases from the available dump:
Stop the Plesk service:
# service psa stopall
Import the database dump:
# zcat /old/var/lib/psa/dumps/mysql.daily.dump.0.gz | MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin
3. Copy the Plesk database password file:
# cp -rpf /old/etc/psa/.psa.shadow /etc/psa/.psa.shadow
4. Copy the encryption key to the new server:
# cp /etc/psa/private/secret_key /etc/psa/private/secret_key.save
# cp -rpf /old/etc/psa/private/secret_key /etc/psa/private/secret_key
Note: it also may be necessary to chmod and chown the file:
# chmod 0600 /etc/psa/private/secret_key
# chown psaadm:root /etc/psa/private/secret_key
These are the correct permissions for this file:
# stat /etc/psa/private/secret_key
File: `/etc/psa/private/secret_key'
Size: 16 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 49938531 Links: 1
Access: (0600/-rw-------) Uid: ( 501/ psaadm) Gid: ( 0/ root)
Note: if after this, MySQL is not accessible with Plesk credentials ( MYSQL_PWD=cat /etc/psa/.psa.shadow mysql -u admin ), try restarting the MySQL server using service mysqld restart command.
5. Restore domain content:
# rsync -av /old/var/www/vhosts/ /var/www/vhosts/
6. Restore Plesk system users:
For Plesk 11.x-12.0, execute the following command:
# MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin -Dpsa -Ns -e"select s.login, a.password, s.home, s.shell from sys_users s, accounts a where a.id = s.account_id" | awk '{ print "PSA_PASSWD=\\x27" $2 "\\x27 /usr/local/psa/admin/sbin/usermng --add-user --user=" $1 " --homedir=" $3 " --shell=" ($4?$4:"/bin/false")}' | sh -x
For Plesk 10.x, execute the following command:
# MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin -Dpsa -Ns -e"select s1.login, s2.login from sys_users s1 left join sys_users s2 on s2.id = s1.mapped_to where s2.login is not null" | awk '{print "/usr/local/psa/admin/sbin/usermng --map-user --user=" $1 " --mapped-to=" $2}' | sh -x
7. Restore SSL certificates:
# cp -p /old/usr/local/psa/var/certificates/* /usr/local/psa/var/certificates/
8. Restore the mailnames directory (mail content):
# rsync -av /old/var/qmail/mailnames/ /var/qmail/mailnames/
# chown -R popuser:popuser /var/qmail/mailnames/*
9. Repair ownership on the virtual hosts' content to fix files and directories owned by non-existent users:
# MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin -Dpsa -Ns -e"SELECT s.home, h.www_root, s.login FROM hosting h, sys_users s WHERE s.id = h.sys_user_id" | while read home www_root login ; do content_uid=`stat --format=%u "$www_root"` ; find $home -uid $content_uid -exec chown $login '{}' + ; done
For Plesk 9.x and earlier:
# MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin -Dpsa -Ns -e"SELECT home, login FROM sys_users" | while read home login ; do content_uid=`stat --format=%u "$home/httpdocs"` ; find $home -uid $content_uid -exec chown $login '{}' + ; done
10. Regenerate the web server configuration:
For Plesk 10.x-12.0:
# /usr/local/psa/admin/sbin/httpdmng --reconfigure-all
For Plesk 8.x and 9.x:
# /usr/local/psa/admin/sbin/websrvmng –a -v
11. Repair the mail configuration:
# /usr/local/psa/admin/sbin/mchk –-with-spam
12. Restore DNS zones:
# MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin psa -Ns -e "select name from dns_zone" | awk '{ print "/usr/local/psa/admin/sbin/dnsmng --update " $1 }' | sh -x
13. Start the Plesk service:
# service psa start
I am deploying my Symfony2 web app onto an Apache web server, on an Ubuntu machine, hosted on AWS, using Capifony multistage deploy.
I have user set
set :user, "ubuntu"
And writable directory for cache set like so
set :writable_dirs, ["app/cache"]
set :webserver_user, "www-data"
set :use_set_permissions, true
set :permission_method, :acl
Everything is deploying fine apart from when this is run
executing "setfacl -R -m u:ubuntu:rwx -m u:www-data:rwx /var/www/releases/20140310012814/app/cache"
I get multiple Operation not permitted errors such as
setfacl: /var/www/releases/20140310012814/app/cache/prod/classes.php: Operation not permitted
It seems that the user, presumably 'www-data', cannot set permissions on files created by 'ubuntu'. However, I have run the following on the server from the /var/www/current directory, but I'm not entirely sure what they do:
sudo setfacl -R -m u:www-data:rwX -m u:`whoami`:rwX app/cache
sudo setfacl -dR -m u:www-data:rwx -m u:`whoami`:rwx app/cache
Here is some acl info
getfacl app/cache
# file: app/cache
# owner: ubuntu
# group: ubuntu
user::rwx
user:www-data:rwx
user:ubuntu:rwx
group::rwx
mask::rwx
other::rwx
default:user::rwx
default:user:www-data:rwx
default:user:ubuntu:rwx
default:group::rwx
default:mask::rwx
default:other::rwx
I have had a look at a similar issue here Should I run something similar? such as:
sudo sh -c 'setfacl -R -m u:ubuntu:rwX -m u:www-data:rwX /var/www/current/app/cache'
Thanks
Capifony has a cookbook entry explaining how to automatically set proper permissions. Basically what you need is this:
set :writable_dirs, ["app/cache", "app/logs"]
set :webserver_user, "www-data"
set :permission_method, :acl
set :use_set_permissions, true
:use_sudo doesn't need to be true as long as the :writable_dirs are owned by :user.
The problem
setfacl: /var/www/releases/20140310012814/app/cache/prod/classes.php: Operation not permitted
This message indicates that the cache directory isn't empty when the task is run (setfacl operates on prod/classes.php in that directory), which is not owned by :user (setfacl is not permitted).
The fact that the file is not owned by :user is quite normal because the webserver will create a lot of cache files, which make them owned by :webserver_user.
The strange thing here is that the cache directory isn't empty. Normally a new release should have an empty cache directory. A common cause for this is that the cache directory is shared, meaning you've added it to :shared_children. If so, please remove it. The cache directory shouldn't be shared.
If this is not the case, then try to find out why the cache directory isn't empty when the setfacl task is run. Maybe other tasks are running to soon.
Writable shared children
What if you actually want a shared directory to be writable for the webserver? This is actually very common, think of a media or uploads directory that should be shared.
The permissions should be set on the actual shared directory, not the symlink in the release directory. Capifony takes care of this for you, as long as the exact same phrase in :writable_dirs is also in :shared_children.
# this will work:
set :shared_children, ["web/uploads"]
set :writable_dirs, ["web/uploads"]
# this will also work:
set :web_path, "web" # is default
set :shared_children, [web_path + "/uploads"]
set :writable_dirs, ["web/uploads"]
# this will not:
set :web_path, "web" # is default
set :shared_children, [web_path + "/uploads"]
set :writable_dirs, ["web/uploads/"] # trailing /
Please check if the directory mentioned in the error is the actual shared directory (not the symlink).
The owner of the shared directory must be the user that will run the setfacl command. In other words, it must be :user. When you've changed the value of :user, or have had :use_sudo enabled in the past, this could cause issues. Please check if the directories (as set in :writable_dirs) are indeed owned by :user.
Capifony will perform a check if the permissions are already set. If so, it won't try to do it again. This is done with the following command:
getfacl --absolute-names --tabular #{dir} | grep #{webserver_user}.*rwx | wc -l"
Try to run this command manually (replace #{dir} and #{webserver_user} with the actual values) to see the outcome. If it yields no results, then Capifony assumes the permissions have not yet been set, and will try to do so.
In that case, manually check the permissions with getfacl. If they are indeed incorrect, manually set them (again, replace #{user}, #{webserver_user} and #{dir}) using "the power of root":
sudo setfacl -R -m u:#{user}:rwX -m u:#{webserver_user}:rwX #{dir}
sudo setfacl -dR -m u:#{user}:rwx -m u:#{webserver_user}:rwx #{dir}
Then run Capifony again. If all is well, it should succeed this time!
You have run the sudo setfacl on the current directory, but you are receiving the errors on the single releases folders. Anyway, www-data should be the right owner of the cache folder, it is the main user of that dir, in the end!
In our deploy script, we use this:
set :permission_method, :acl
set :writable_dirs, ["app/cache"]
set :webserver_user, "www-data"
set :use_set_permissions, false
set :use_sudo, false
I think this is the right solution.
I have two questions:
Is there a difference between: nginx -s reload and pkill -HUP -F nginx.pid
What's the simplest way to watch the Nginx conf file and upon changes test the conf file (nginx -t), and if it passes reload Nginx. Can that be done with runit or a process manager like Supervisor?
#!/bin/bash
# NGINX WATCH DAEMON
#
# Author: Devonte
#
# Place file in root of nginx folder: /etc/nginx
# This will test your nginx config on any change and
# if there are no problems it will reload your configuration
# USAGE: sh nginx-watch.sh
# Set NGINX directory
# tar command already has the leading /
dir='etc/nginx'
# Get initial checksum values
checksum_initial=$(tar --strip-components=2 -C / -cf - $dir | md5sum | awk '{print $1}')
checksum_now=$checksum_initial
# Start nginx
nginx
# Daemon that checks the md5 sum of the directory
# ff the sums are different ( a file changed / added / deleted)
# the nginx configuration is tested and reloaded on success
while true
do
checksum_now=$(tar --strip-components=2 -C / -cf - $dir | md5sum | awk '{print $1}')
if [ $checksum_initial != $checksum_now ]; then
echo '[ NGINX ] A configuration file changed. Reloading...'
nginx -t && nginx -s reload;
fi
checksum_initial=$checksum_now
sleep 2
done
At least on Unix, both "reload" action and HUP signal are treated as one thanks to the declaration code
ngx_signal_t signals[] = {
{ ngx_signal_value(NGX_RECONFIGURE_SIGNAL),
"SIG" ngx_value(NGX_RECONFIGURE_SIGNAL),
"reload",
ngx_signal_handler },
in src/os/unix/ngx_process.c. In ngx_signal_handler() the same comnmon code
case ngx_signal_value(NGX_RECONFIGURE_SIGNAL):
ngx_reconfigure = 1;
action = ", reconfiguring";
break;
is executed, that prepares for a common reconfiguration.
To trigger an action when a file is modified, you could either make a crontab and decide of a check-periodicity, or use inotifywait.
To determine if nginx -t is in error, check the return code in a bash file, $?
nginx -t
if [ $? -eq 0 ] then;
nginx -s reload
fi
Note: you may also use service nginx reload
(See return code check examples here)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm running OpenLDAP 2.4-28 on XUBUNTU 12.04.
I'm reading "Mastering OpenLDAP" and configuring along with the book.
When I try to perform the following search (page 47):
$ ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base
I am prompted for the password. Then I enter "secret" but I get the following error:
ldap_bind: Invalid Credentials (49).
The following is my slapd.conf:
# slapd.conf - Configuration file for LDAP SLAPD
##########
# Basics #
##########
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel none
modulepath /usr/lib/ldap
# modulepath /usr/local/libexec/openldap
moduleload back_hdb
##########################
# Database Configuration #
##########################
database hdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
directory /var/lib/ldap
# directory /usr/local/var/openldap-data
index objectClass,cn eq
########
# ACLs #
########
access to attrs=userPassword
by anonymous auth
by self write
by * none
access to *
by self write
by * none
and here is the ldap.conf:
# LDAP Client Settings
URI ldap://localhost
BASE dc=example,dc=com
BINDDN cn=Manager,dc=example,dc=com
SIZELIMIT 0
TIMELIMIT 0
I don't see an obvious problem with the above.
It's possible your ldap.conf is being overridden, but the command-line options will take precedence, ldapsearch will ignore BINDDN in the main ldap.conf, so the only parameter that could be wrong is the URI.
(The order is ETCDIR/ldap.conf then ~/ldaprc or ~/.ldaprc and then ldaprc in the current directory, though there environment variables which can influence this too, see man ldapconf.)
Try an explicit URI:
ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base -H ldap://localhost
or prevent defaults with:
LDAPNOINIT=1 ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base
If that doesn't work, then some troubleshooting (you'll probably need the full path to the slapd binary for these):
make sure your slapd.conf is being used and is correct (as root)
slapd -T test -f slapd.conf -d 65535
You may have a left-over or default slapd.d configuration directory which takes preference over your slapd.conf (unless you specify your config explicitly with -f, slapd.conf is officially deprecated in OpenLDAP-2.4). If you don't get several pages of output then your binaries were built without debug support.
stop OpenLDAP, then manually start slapd in a separate terminal/console with debug enabled (as root, ^C to quit)
slapd -h ldap://localhost -d 481
then retry the search and see if you can spot the problem (there will be a lot of schema noise in the start of the output unfortunately). (Note: running slapd without the -u/-g options can change file ownerships which can cause problems, you should usually use those options, probably -u ldap -g ldap )
if debug is enabled, then try also
ldapsearch -v -d 63 -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base
I almost been stuck a day on the following issue,
I installed LDAP using: apt-get install slapd
and use the following configuration:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
allow bind_v2
loglevel 0
moduleload back_sbdb.la
database bdb
suffix "dc=test,dc=nl"
rootdn "cn=Directory Manager,dc=test,dc=nl"
rootpw test
directory /var/lib/ldap
index objectClass eq
index userPassword eq,pres
index givenName,mail,mobile,sn,title,cn,description eq,sub,pres
index displayName eq,sub,pres
index postalAddress,facsimileTelephoneNumber pres
access to *
by self write
by * read
and I then try to bind using
ldapsearch -D cn=Directory Manager,dc=test,dc=nl -w test
but I still recieve the error ldap_bind: Invalid Credentials (49)
Anyone has any idea or clues what this could be?
Thanks in forward
Try it using quotes like;
ldapsearch -D "cn=Directory Manager,dc=test,dc=nl" -w test
Space character in Directory Manager may cause the problem.
Edit: Also, are you sure you don't need -h -p parameters?
-h The host name of the directory server
-p The port number of the directory server
Edit2: Just figured out what is wrong. You are using rootpw unencrypted in your slapd config file. You should use an encrypted password created by slappasswd tools output. This may cause problems under special circumstances.
Check this link for details: http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ldap-quickstart.html
A few things you could try:
Turn on more verbose logging (loglevel 255), and see if anything shows up in the log file.
Verify that the server really is reading the configuration file you think by checking the access time on the slapd.conf file (ls -lu slapd.conf)
Try binding using an invalid dn (ldapsearch -D cn=no-such-user -w test) and see if the error message changes (if so, that confirms that the problem is with the password, not the dn).
Try man ldapsearch.
I'm not really sure on debian/ubuntu, but in FreeBSD you need to add a -x to use simple authentication instead of SASL. I think this might be your issue?
Also, you could use -W instead of passing the password plain text on the commmand line.