Problem with running

Starting from messages I saw when running:

vagrant up infrastructure

I searched the internet, to find a solution to the problem of having the [vagrant@localhost ~]$ prompt instead of [vagrant@infrastructure ~]$, that should show up, when running:

vagrant ssh infrastructure

From what I found, I have modified the Vagrantfile, replacing: = "centos/7"

by: = "geerlingguy/centos7"

This fixes the issue of having the wrong prompt:

[vagrant@localhost ~]$

But does not solve the final problem of running the script; this is what I now get:

[vagrant@infrastructure ~] cd shared/ [vagrant@infrastructure shared] ls
[vagrant@infrastructure shared] ./ Redirecting to /bin/systemctl start slapd.service Failed to start slapd.service: Unit not found. sudo: ldapadd: command not found sudo: ldapadd: command not found sudo: ldapadd: command not found Traceback (most recent call last): File "/home/vagrant/shared/", line 4, in <module> import ldap ImportError: No module named ldap [vagrant@infrastructure shared]

I hope somebody can help me solve this quite annoying problem.

Good you were able to fix ssh prompt issue
But the new error may be again related to vagrant issue?
May be the required packages of LDAP not got installed
or permission issues?

The setup script takes care of everything to install openLDAP.We did not have to do anything

Can you see files under /etc/openldap?

Yes thanks, but I hope using geerlingguy/centos7 instead of centos/7 is not causing other issues.

The new error is not NEW, it is the one (or very similar) I already had before with the [vagrant@localhost ~]$ prompt.

You write:

The setup script takes care of everything to install openLDAP.

Well, if it is really taking care of everything, why do I have so many problems?

Concerning /etc/openldap/ this is what I can see:

[vagrant@infrastructure ~]$

[vagrant@infrastructure ~]$

[vagrant@infrastructure ~]$ ls /etc/openldap/

certs ldap.conf

[vagrant@infrastructure ~]$

[vagrant@infrastructure ~]$ ls /etc/openldap/certs/

cert8.db key3.db password secmod.db

[vagrant@infrastructure ~]$

[vagrant@infrastructure ~]$ cat /etc/openldap/ldap.conf

LDAP Defaults

See ldap.conf(5) for details

This file should be world readable but not world writable.

#BASE dc=example,dc=com
#URI ldap:// ldap://

#DEREF never

TLS_CACERTDIR /etc/openldap/certs

Turning this off breaks GSSAPI used with krb5 when rdns = false

[vagrant@infrastructure ~]$

[vagrant@infrastructure ~]$

======================= END-OF-FILE =======================

I hope this will help us find a solution to this issue.

TLS_CACERTDIR looks fine

Do you see the files under that certs dir?

Also do you see below in your shared dir
-rwxrwxrwx. 1 vagrant vagrant 972 Feb 17 16:33
-rwxrwxrwx. 1 vagrant vagrant 2003 Feb 17 16:33
drwxrwxrwx. 1 vagrant vagrant 0 Feb 17 16:34 ldap
[vagrant@infrastructure shared]$

sudo systemctl list-units|grep slapd
Sometimes python related issues also cause setup script to fail

I wrote in my message what I can see in the /etc/openldap/certs/ directory.
Please take a look at the result of this command (in the previous message):

ls /etc/openldap/certs/

There are four files.

The shared directory is not created, for some reason that I ignore.
I need to bring the files by hand to be able to run the script.
I already noticed before that the shared directory was created on the database VM but not on the infrastructure. I don’t know why.

If I run this as you suggest:

sudo systemctl list-units|grep slapd

This is what it gives:

[vagrant@infrastructure shared] sudo systemctl list-units|grep slapd [vagrant@infrastructure shared]

I don’t know if this means all is OK or it did not work. Please tell me if you know.

By the way, the message when trying to run says:

ldapadd: command not found

Couldn’t this be a PATH issue?

Running this:

[vagrant@infrastructure shared]$ sudo find / -name ldapadd

[vagrant@infrastructure shared]$

shows that the ldapadd is just not on the system.

Seems to be provisioning issue
I was not aware you had issues with shared dir
So you created the shared dir manually?

Your other threads also did not mention this.We were discussing only about ssh and prompt issues

You need to fix provisioning issue before proceeding with labs.Provisioning brings in all needed packages apart from creating shared dir
So unit not found & ldapdd not found errors could be due to that and not due to path issue
Did you try vagrant reload infrastructure ?

You were asking about alternate mirror
Please go through this link.It gives fix for missing shared folder also

M310 installation error - vagrant up infrastructure

I went to take a look and read the link you mention.

There are a lot of informations and I am trying to work from there, but some questions are left open. For example do you know if this user is using "centos/7", "geerlingguy/centos7" or maybe even something else for ?

I have followed what the user says using "geerlingguy/centos7" and I still do not have a “shared” folder on the VM. Maybe I should use the other option ("centos/7"), but I already know that in this case I have the [vagrant@localhost ~]$ prompt.

I have finally a VM up an running with a shared directory and its expected contents. And the shell prompt is:

[vagrant@infrastructure ~]$ 

I almost followed the instructions in your link.

Here are the steps that worked for me:

-1- Run:

    vagrant halt infrastructure
    vagrant destroy infrastructure -f

-2- Using a Vagrantfile containing: = "centos/7"


    vagrant up infrastructure

-3- Run:

    vagrant ssh infrastructure

    Here I get the wrong prompt [vagrant@localhost ~]$ but decide to ignore that for the time being.

    Inside the VM, run:

    sudo yum update -y

    when this done:

    exit the VM by running:


-4- Run:

    vagrant plugin install vagrant-vbguest
    vagrant reload infrastructure

-5- Run:

    vagrant ssh infrastructure

At this point the shared folder is there, where expected.
And the prompt is:

    [vagrant@infrastructure ~]$

Notice that I did not run this command (as did the other user):

    vagrant up infrastructure --provision

I do not know if this solution is perfect, but it seems like it allowed me to make significant progress.