Updating pretty old director results in error: "Director is not configured correctly"

Icinga Director
1

Hi folks,

I am running a pretty outdated version of the director ( commit 50591213 from Jul’18 ) which I updated yesterday to the latest version of the master-branch ( commit fe53dee2 ).

What I did is moving the outdated director-folder in /usr/share/icingaweb2/modules/ to a save place and clone the repository from github in there (again). That worked so far and the director tells men that There are 12 pending schema migrations.

When I start the migration-command I get the following error - does anybody know how to fix this?

icingacli director migration run --verbose
ERROR: RuntimeException in /usr/share/icingaweb2/modules/director/library/Director/Cli/Command.php:114 with message: Director is not configured correctly
2

Moving from git master to git master is a pretty bad idea, there’s no-one testing this procedure compared to released and tagged versions.

I’d try to use 1.6.2 being the latest release instead.

Cheers,
Michael

3

OK, I just recloned the repo and specified the tag for version 1.6.2 but the error stays the same :slightly_frowning_face:

BTW: There are only 9 Pending migrations left by now…

4

No idea, sorry. I don’t use git master for that very reason of breaking things on upgrade. Maybe @tgelf knows more about this specific commit, or changes in git master causing this.

Cheers,
Michael

5

This basically means that no DB connection is configured for Director.

Please show us the contents of /etc/icingaweb2/modules/director/config.ini

The thing is, if your Webinterface is showing pending migrations, but your CLI tool brings this error, there must be something wrong with your setup…

How did you install Icinga Web 2, OS Environment, any special paths?

6

Or just: Which user is running icingacli? Is this user able to read/write /etc/icingaweb2?

7

Guys, I figured it out. It was in fact a DB-Issue. The standard-User, configured in the backend had no owner-rights on the scheme.
Confing the db-owner in the connection-settings (had to make sure director-db is default schema) resulted in success.