I am installing openldap from scratch on a Centos7
I followed the quick start guide on the openldap.org website http://www.openldap.org/doc/admin24/quickstart.html
Everything worked fine up until step 7, I installed openldap in a customized directory without problem
below are the command I ran
cd /usr/local/src
mkdir openldap
cd openldap
cp /home/user/openldap/src/* . //copied everything in the tar ball to the directory
yum install gcc openssl libdb-devel libtool-ltdl-devel.x86_64 openssl-devel.x86_64 cyrus-sasl-devel.x86_64
//yum installed every required package, including devel package for make
./configure --prefix=/usr/local/src/openldap-install //configure to install in custom location
make depend
make
make test //all successful
make install
Then I tried to follow step 8, editing the slapd.ldif to put in my own domain, dc=adomain,dc=com , in my case, was in /usr/local/src/openldap-install/etc/openldap/slapd.ldif
I then added the /usr/local/src/openldap-install/sbin/ directory to the PATH environment, by inserting a openldap_path.sh in the profile.d dir, verified that it worked.
then I followed step 9, (I was running everything by root)
slapadd -F /usr/local/etc/cn=config -l /usr/local/etc/openldap/slapd.ldif
but it returned "available database(s) do not allow slapadd new server"
I don't understand, I am not migrating (as suggested in some other stackoverflow post), its a brand new server, but it just doesn't allow me to continue.
Any help would be appreciated, I just don't know what to do next.
#EJP
File as follow
#
# See slapd-config(5) for details on configuration options.
# This file should NOT be world readable.
#
dn: cn=config
objectClass: olcGlobal
cn: config
#
#
# Define global ACLs to disable default read access.
#
olcArgsFile: /usr/local/src/openldap-install/var/run/slapd.args
olcPidFile: /usr/local/src/openldap-install/var/run/slapd.pid
#
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#olcReferral: ldap://root.openldap.org
#
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 64-bit encryption for simple bind
#olcSecurity: ssf=1 update_ssf=112 simple_bind=64
#
# Load dynamic backend modules:
#
#dn: cn=module,cn=config
#objectClass: olcModuleList
#cn: module
#olcModulepath: /usr/local/src/openldap-install/libexec/openldap
#olcModuleload: back_bdb.la
#olcModuleload: back_hdb.la
#olcModuleload: back_ldap.la
#olcModuleload: back_passwd.la
#olcModuleload: back_shell.la
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
include: file:///usr/local/src/openldap-install/etc/openldap/schema/core.ldif
# Frontend settings
#
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
#
# Sample global access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
#
#olcAccess: to dn.base="" by * read
#olcAccess: to dn.base="cn=Subschema" by * read
#olcAccess: to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#
#######################################################################
# LMDB database definitions
#######################################################################
#
dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
**olcSuffix: dc=ldap,dc=domain,dc=com**
**olcRootDN: cn=Manager,dc=ldap,dc=domain,dc=com**
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd-config(5) for details.
# Use of strong authentication encouraged.
**olcRootPW: {SSHA}strong**
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
**olcDbDirectory: /usr/local/src/openldap-install/var/openldap-data**
# Indices to maintain
olcDbIndex: objectClass eq
only the last few lines were changed from the slapd.ldif.default file
and below is the file tree in the installation path output by ls -R
.:
bin etc include lib libexec sbin share var
./bin:
ldapadd ldapdelete ldapmodify ldappasswd ldapurl
ldapcompare ldapexop ldapmodrdn ldapsearch ldapwhoami
./etc:
openldap
./etc/openldap:
ldap.conf schema slapd.conf.default slapd.ldif.default
ldap.conf.default slapd.conf slapd.ldif
./etc/openldap/schema:
collective.ldif cosine.schema java.ldif openldap.schema
collective.schema duaconf.ldif java.schema pmi.ldif
corba.ldif duaconf.schema misc.ldif pmi.schema
corba.schema dyngroup.ldif misc.schema ppolicy.ldif
core.ldif dyngroup.schema nis.ldif ppolicy.schema
core.schema inetorgperson.ldif nis.schema README
cosine.ldif inetorgperson.schema openldap.ldif
./include:
lber.h ldap_cdefs.h ldap.h ldap_utf8.h slapi-plugin.h
lber_types.h ldap_features.h ldap_schema.h ldif.h
./lib:
liblber-2.4.so.2 libldap-2.4.so.2 libldap_r-2.4.so.2.10.7
liblber-2.4.so.2.10.7 libldap-2.4.so.2.10.7 libldap_r.a
liblber.a libldap.a libldap_r.la
liblber.la libldap.la libldap_r.so
liblber.so libldap_r-2.4.so.2 libldap.so
./libexec:
slapd
./sbin:
slapacl slapauth slapdn slappasswd slaptest
slapadd slapcat slapindex slapschema
./share:
man
./share/man:
man1 man3 man5 man8
./share/man/man1:
ldapadd.1 ldapdelete.1 ldapmodify.1 ldappasswd.1 ldapurl.1
ldapcompare.1 ldapexop.1 ldapmodrdn.1 ldapsearch.1 ldapwhoami.1
./share/man/man3:
ber_alloc_t.3 ldap_free_urldesc.3
blablablablabla
blablablablabla
blablablablabla
./share/man/man5:
ldap.conf.5 slapd-mdb.5 slapd-sql.5 slapo-ppolicy.5
blablablablabla
blablablablabla
blablablablabla
./share/man/man8:
blablablablabla
blablablablabla
./var:
run
./var/run:
EDIT
#EJP I sort of get what you mean. you are saying the default LDIF file is actually the cn=config database?
I am nearly giving up, 1 week of my time and not getting an ldap server starting. I don't see what is the problem, Perhaps cleaning up some concept of mine can actually solve the situation here?
How to define my own database? I thought I had already done that by changing the olcsuffix?
how is the cn=config database different from a "configuration database"?
what file do I edit / create to define my own database?
What does it mean in step 8 of the openldap quickstart guide contain a MDB database definition of the form ?
What does it mean in step 9 of the openldap quickstart guide import your configuration database? does it mean the installed openldap server had no configuration?
What does the slapd.conf file that came along with the installation do? does it contain "definition" or "configuration"?
I have tried to skip step 8 and 9 and directly tried to start SLAPD, but it always failed, should SLAPD be able to start on its own without me "importing my own configuration database?
Thankyou EJP for your great patience with me, I know I am missing something extremely trivial, but believe me I have dug through the internet for days (and book store for one day) failing to find definitive answer. Would be really great if you can clarify with me some concepts by answer my questions or perhaps your own explanation, or provide me with just a dummy ldif file that I can do slapadd then I can figure out whats wrong.
I attribute my difficulty to I reckon poorly done openldap guidance documentation:
They have stated that slapd.d is the new way to go, but the compiled source make does not generate the slapd.d/ directory, nor did I find options in the ./configure to switch to such
bdb and hdb seems fading out and replaced by mdb, but ./configure defaults enabled those two, requiring some extra libdb-devel package to correctly make them (I am using Centos 7).
the sub directory required by example setup files slapd.conf slapd.ldif(and until today I don't know if they are example files or working files) is not setup by make install, even /var/openldap-data
not even sub directory required by the quickstart guide command was created by make install script
I am not sure if that should be the right, but I believe SLAPD should be shipped at least "working out of the box" and subsequent configuration should be issued by ldapmodify / add / del command.
I didn't figure out why the slapadd command failed when I hit the same error. But,if what you want is to get your LDAP server works, I can share what I did.
Step 1: Configure your MDB in slapd.conf file directly.
When OpenLDAP is installed, a slapd.conf file under /usr/local/etc/openldap has already been created and configured with a MDB database. You can change the MDB setting according to your need. And this is the default setting :
#######################################################################
# MDB database definitions
#######################################################################
database mdb
maxsize 1073741824
suffix "dc=my-domain,dc=com"
rootdn "cn=Manager,dc=my-domain,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /usr/local/var/openldap-data
# Indices to maintain
index objectClass eq
Step 2: Start up slapd after configuration.
Command to start slapd:
/usr/local/libexec/slapd -d 1
If you see "slapd starting", it means slapd is started.
Step 3: Create DB entries.
You can refer to the process given in OpenLDAP Administrator guide :
1.Create an entries.ldif file like this:
# Organization for Example Corporation
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
dc: example
o: Example Corporation
description: The Example Corporation
# Organizational Role for Directory Manager
dn: cn=Manager,dc=example,dc=com
objectClass: organizationalRole
cn: Manager
description: Directory Manager
2.Create the entries with ldapadd tool:
ldapadd -f entries.ldif -x -D "cn=Manager,dc=example,dc=com" -w secret
Once you've done the upper 3 steps, the LDAP server is ready for use. You can add DIT for your use.
FYI, a good GUI client can help you a lot. I used Jarek Gawor’s excellent LDAP Browser/Editor v2.8.2
Hope this answer can help you or others in future.
Turns out this answer solves the problem Openldap naming context issue with Apache directory studio?.
I think I appreciate that people can answer some specifics of my question or provide an example for answer. Not all people learn by worded explanations, some learn by examples and reverse engineering. Read manuals and only ask question when you don't understand, I would think that is such a prior statement, and most have gone past that stage before actually asking any questions.
Yes, I think I should ask on serverfault, since stackoverflow is more geared towards programming.
I just ran into this using OpenLDAP 2.6.0 ; following "configure; make; make install" I wasn't able to run slapd, it failed server startup with "unknown file on line 72"
Turns out it didn't create a /usr/local/var/openldap-data/ directory.
mkdir /usr/local/var/openldap-data/ resolved it.
You should convert your default slapd.conf into new slapd.d directory format. Add config database definition in slapd.conf:
# before the first database definition
database config
# NOTE: the suffix is hardcoded as cn=config and
# MUST not have a suffix directive
# normal rules apply - rootdn can be anything you want
# but MUST be under cn=config
rootdn "cn=admin,cn=config"
# use any of the supported password formats e.g. {SSHA} etc
# or plaintext as shown
rootpw config
and then convert it using
slaptest -f /usr/local/etc/openldap/slapd.conf -F /usr/local/etc/openldap/slapd.d
and then delete slapd.conf. Then you can continue your configuration with slapadd. Take a look at Configuration Guide or http://www.zytrax.com/books/ldap/ch6/slapd-config.html.
Hope this will help you.
Related
Here's a transcript so far:
$ sbt new lagom/lagom-scala.g8
[info] Loading global plugins from /Users/abrahma/.sbt/1.0/plugins
[info] Set current project to lagomlife (in build file:/Users/abrahma/Bitbucket/Practice-Scala/LagomLife/)
[info] Set current project to lagomlife (in build file:/Users/abrahma/Bitbucket/Practice-Scala/LagomLife/)
ssh://git#github.com/lagom/lagom-scala.g8.git: Auth fail
I've verified authentication with
GitHub:
$ ssh -T git#github.com
Hi agam! You've successfully authenticated, but GitHub does not provide shell access.
Also verified that I can access the repo in question (i.e. I can do the following, in a separate location):
git clone ssh://git#github.com/lagom/lagom-scala.g8.git
Edit: fwiw I'm able to work around whatever the root cause is here:
git clone ssh://git#github.com/lagom/lagom-scala.g8.git
g8 file:///Users/abrahma/tmp/lagom-scala.g8
I ran into this problem as well, and solved it by removing the following from my ~/.gitconfig:
[url "git#github.com:"]
insteadOf = https://github.com/
Are you using OpenSSH 7.8 or newer, and have you recently created your private key?
If so you might be running into the issue described in “Invalid privatekey” when using JSch aka jsch#129.
The root cause was discovered to be the ssh private key mismatch.
The question has a workaround to convert the key file to an older format if that's the error you're seeing.
You need to add your SSH key to the agent:
ssh-add ~/.ssh/id_rsa
I am writing a build process for a WordPress installation using Ansible. It doesn't have a application-level build system at the moment, and I've chosen Ansible so that it can cleanly integrate with server build scripts, so I can bring up a working server at the touch of a button.
Most of my WordPress plugins are being installed with the unarchive feature, pointing to versioned plugin builds on the official wordpress.org installation server. I've encountered a problem with just one of these, which is that it is always being marked as "changed" even though the files are exactly the same.
Having examined the state of ls -Rl before and after, I noticed that this plugin (WordPress HTTPS) is the only one to use internal sub-directories, and upon each decompression, the modification time of folders is getting bumped.
It may be useful to know that this is a project build script, with a connection of local. I guess therefore that means that SSH is not being used.
Here is a snippet of my playbook:
- name: Install the W3 Total Cache plugin
unarchive: >
src=https://downloads.wordpress.org/plugin/w3-total-cache.0.9.4.1.zip
dest=wp-content/plugins
copy=no
- name: Install the WP DB Manager plugin
unarchive: >
src=https://downloads.wordpress.org/plugin/wp-dbmanager.2.78.1.zip
dest=wp-content/plugins
copy=no
# #todo Since this has internal sub-folders, need to work out
# how to preserve timestamps of the original folders rather than
# re-writing them, which forces Ansible to record a change of
# server state.
- name: Install the WordPress HTTPS plugin
unarchive: >
src=https://downloads.wordpress.org/plugin/wordpress-https.3.3.6.zip
dest=wp-content/plugins
copy=no
One hacky way of fixing this is to use ls -R before and after, using options to include file sizes but not timestamps, and then md5sum that output. I could then mark it as changed if there is a change in checksum. It'd work but it's not very elegant (and I'd want to do that for all plugins, for consistency).
Another approach is to abandon the task if a plugin file already exists, but that would cause problems when I bump the plugin version number to the latest copy.
Thus, ideally, I am looking for a switch to present to unarchive to say that I want the folder modification times from the zip file, not from playbook runtime. Is it possible?
Update: a commenter asked if the file contents could have changed in any way. To determine whether they have, I wrote this script, which creates a checksum for (1) all file contents and (2) all file/directory timestamps:
#!/bin/bash
# Save pwd and then change dir to root location
STARTDIR=`pwd`
cd `dirname $0`/../..
# Clear collation file
echo > /tmp/wp-checksum
# List all files recursively
find wp-content/plugins/wordpress-https/ -type f | while read file
do
#echo $file
cat $file >> /tmp/wp-checksum
done
# Get checksum of file contents
sha1sum /tmp/wp-checksum
# Get checksum of file sizes
ls -Rl wp-content/plugins/wordpress-https/ | sha1sum
# Go back to original dir
cd $STARTDIR
I ran this as part of my playbook (running it in isolation using tags) and received this:
PLAY [Set this playbook to run locally] ****************************************
TASK [setup] *******************************************************************
ok: [localhost]
TASK [jonblog : Run checksum command] ******************************************
changed: [localhost]
TASK [jonblog : debug] *********************************************************
ok: [localhost] => {
"checksum_before.stdout_lines": [
"374fadc4df1578f78fd60b1be6758477c2c533fa /tmp/wp-checksum",
"10d66f7bdbbdd3af531d1b11a3db3059a5868838 -"
]
}
TASK [jonblog : Install the WordPress HTTPS plugin] ***************
changed: [localhost]
TASK [jonblog : Run checksum command] ******************************************
changed: [localhost]
TASK [jonblog : debug] *********************************************************
ok: [localhost] => {
"checksum_after.stdout_lines": [
"374fadc4df1578f78fd60b1be6758477c2c533fa /tmp/wp-checksum",
"719c9da94b525e723b1abe188ee9f5bbaf121f3f -"
]
}
PLAY RECAP *********************************************************************
localhost : ok=6 changed=3 unreachable=0 failed=0
The debug lines reflect the checksum hash of the contents of the files (this is identical) and then the checksum hash of ls -Rl of the file structure (this has changed). This is in keeping with my prior manual finding that directory checksums are changing.
So, what can I do next to track down why folder modification times are incorrectly flagging this operation as changed?
Rather than overwriting all files each time and find a way to keep the same modification datetime, you may want to use the creates option of the unarchive module.
As you maybe already know, this tells Ansible that a specific file/folder will be created as a result of the task. Thus, next time the task will not be run again if that file/folder already exists.
See http://docs.ansible.com/ansible/unarchive_module.html#options
My solution is to modify the checksum script and to make that a permanent feature of the Ansible process. It feels a bit hacky to do my own checksumming, when Ansible should do it for me, but it works.
New answers that explain that I am doing something wrong, or that a new version of Ansible fixes the problem, would be most welcome.
If I get a moment, I will raise this as a possible bug with the Ansible team. However I do sometimes wonder about the effort/reward ratio when raising bugs on a busy tracker - I already have one item outstanding, it has been waiting a while, and I've chosen to work around that too.
Update (18 months later)
This Ansible build system never made it into live. It felt like I was always working around something. Recently, when I decided I needed to move my blog to another server, I finally Dockerised it. This took several weeks (since there is a surprising amount of things to think about in a real WordPress installation) but in general I found the process much nicer than using orchestration tools.
Showing currently applied configuration values
In v2.0+ of Riak there is a new command option: riak config effective
Which I read as it would tell you the current running values of riak.
At any time, you can get a snapshot of currently applied
configurations through the command line. For a listing of all of the
configs currently applied in the node
Config changes applied only on start of each node?
In multiple locations in Riak documentation there is reference like:
Remember that you must stop and then re-start each node when you
change storage backends or modify any other configuration
Problem:
However when I made a change to a setting (I've tested this in both riak.conf and advanced.conf), I see the newest value when running: riak config effective
ie:
Start node: riak start
View current setting for log level: riak config effective | grep log.console.level
log.console.level = info
Change the level to debug (something that will output a lot to console.log)
Re-run: riak config effective | grep log.console.level, we get:
log.console.level = debug
Checking the console log file for debug: cat /var/log/riak/console.log | grep debug give no results (indicating the config change has not been applied)
So the question is, how can I retrieve and verify what config setting each Riak node is running under?
When Riak starts, it creates two files: 'app..config' and 'vm..config'. The default location is in a 'generated.configs' directory under the platform data directory (usually /var/lib/riak).
These files will contain the settings that were in place when Riak was started. The command riak config effective processes the current riak.conf and advanced.config files.
Actually based on http://www.openldap.org/doc/admin24/slapdconf2.html said that i can converting slapd.conf to cn=config format.
So for this purpose i try to make slapd.conf file on server which have role provider like bellow:
database bdb
suffix dc=mydomain,dc=org
rootdn cn=admin,dc=mydomain,dc=org
directory /var/lib/ldap/db
index objectclass,entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
database config
rootpw mypassword
Then i try to convert that file using slaptest command, but i got error message like bellow :
$ slaptest -f slapd.conf -v
slapd.conf: line 2: <suffix> invalid DN 21 (Invalid syntax)
slaptest: bad configuration file
Actually my suffix is absolutely right, but why always "invalid DN"
How to solve this error ?
You probably have solved it by now, but for the benefit of the googles out there...
Your suffix is not absolutely right because it uses the domainComponent attribute "dc=" but you haven't added the schema that defines it. So until that is done the distinguished name is an unknown and "invalid DN".
Explanation: In the core.schema file (typically in /etc/openldap/schemas/, at least for RedHat/CentOS RPMs) you can find this (and much more that is needed):
# RFC 1274 + RFC 2247
attributetype ( 0.9.2342.19200300.100.1.25
NAME ( 'dc' 'domainComponent' )
DESC 'RFC1274/2247: domain component'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
What you have to do it to include this schema file to your configuration by adding this to the beginning (assuming the file is at this path, adjust as needed):
include /etc/openldap/schema/core.schema
You probably also need other schema files, but this will solve this error.
I had the same problem with too minimal of a file, I added a few extra details and it works
#slapd.conf
#schemas to use
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
#log
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
########################################
##### dbm database definitions ####
########################################
database bdb
suffix dc=server,dc=com
rootdn cn=Manager,dc=server,dc=com
rootpw secret
#database directory
directory /var/lib/ldap
#end
According to this you might only be missing the pidfile location as it changed between versions but you will eventually add the rest anyway.
well you should delete defaults files before run your test:
example on CentOS:
rm -rf /etc/openldap/slapd.d/*
and in database directory, should have a DB_CONFIG file
all archives with ldap-user-granted (chown ldap:ldap)
include this files in #schemas to use
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/dyngroup.schema
I want to be able to check if my site is up and monitor it by nagios locally.
So I went to this site http://www.linickx.com/nagios which made the following, now while I cant see hosts.cfg so I created it and also services.cfg I had to create as well:
hosts.cfg
# host definition for bonus
define host{
use generic-host ; Name of host template to use
host_name bonus
alias bonus
address 92.12.35.162
check_command check-host-alive
max_check_attempts 10
notification_interval 120
notification_period 24x7
notification_options d,u,r}
services config
The following should appended to the end of hosts.cfg (located in /etc/nagios or /usr/local/nagios/etc)
# Service definition for bonus
define service{
use generic-service ; Name of service template to use
host_name bonus
service_description HTTP
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 3
retry_check_interval 1
contact_groups technical,support
notification_interval 120
notification_period 24x7
notification_options w,u,c,r
check_command check_http
}
How can I get this to work please?
Nagios won't add new configuration files unless either the file or directory is specified in the main nagios.cfg. Also, the new object configurations won't be added until you restart the Nagios process. Can you give some more detail as to how you installed Nagios (source or package) and what linux distro you're on?
Here are some additional resources:
Nagios Core Documentation
http://nagios.sourceforge.net/docs/3_0/
Nagios Core Support Forum
http://support.nagios.com/forum/viewforum.php?f=7