Warn the user if Icinga DB is used as configuration database #5208
Comments
|
Hi, thanks for reporting!
According to the error message you seem to be using PostgreSQL and apparently you've already imported the |
|
The authentication backend is supposed to be LDAP, as I did configure it in the wizard, not a database. And yes, I did have to import both the schema from /usr/share/icingadb/schema/pgsql/schema.sqland /usr/local/share/icinga2-ido-pgsql/schema/pgsql.sql. The icingadb setup usually fails when that schema isn't applied beforehand and the IDO setup explicitly requires setting up the schema, otherwise warning that the database doesn't have a schema. |
Sorry! I mean the
That is not why the wizard is complaining about, Icinga Web 2 requires its own database and also provides its own schema and if you use the Icinga DB database in the wizard, it will then conflict with Icinga DB's schema. This is the reason why it fails to create the |
Then the wizard may not be precise enough, or the setup guide for icingadb isn't. At what point during the setup would I need to place which database in the config (one for icingadb, one for icinga-ido and now the one for icinga-web)? |
|
I recommend reading this blog post as I cannot list all the steps of the wizard here. |
|
If a user chooses the IDO we issue a warning: We should probably do the same if it's the Icinga DB... |
I'll have a look in the next days, thanks. |
This helped. The package icingadb-web was missing. Adding this made Ido a separate, not needed option. Now the setup is done, but logging in doesn't work. I configured LDAP as authentication backend and limited it to only members of a certain group. I obviously am a member of that group as it's also used for various other tasks. Also, for some reason, the icinga2.log still contains Even though I didn't set up ido. EDIT: the browser console is showing these errors: icinga.log Could it be that enabling strict content policy in the wizard is causing these? If so, how do I solve the issue without needing to disable the strict content policiy? |
It's hard to guess what's going wrong when logging into Icinga Web 2, if you don't share the exact error you're experiencing.
This is probably because you have already installed the |
It simply claims username or password are incorrect. That's simply not possible. |
nilmerg
changed the title
|
I've now taken a further look. I can't see anything being wrong with the ldap config for icinga, also it did all pass the validations. But it looks like the ldap server is never contacted. When running slapd on the remote server with -d -1 (most verbose log level), it doesn't recognize any incomming connection from icinga. So no surprise icingaweb claims failed authentication. |
|
Well, what do the Icinga Web 2 logs say? You will find the logs in the appropriate places depending on how you have configured your logs via |
I obviously can't find it in the UI as I can't log in. The log file on the server doesn't say anything about it. |
You can also check the config in |
|
That doesn't provide any logs though. For logging I have these setting: |
This indicates that Icinga Web 2 is sending its logs to syslog. You should be able to find the logs in |
|
Also I would set "DEBUG" as severity so that you can see what Icinga Web is trying to do in order to authenticate. |
Can I force icingaweb to log to /var/log/icingaweb2/icingaweb2.log? |
Nothing there, even with DEBUG. The only icinga-related lines are these: |
You can replace the [logging]
log = "file"
level = "DEBUG"
file = "/var/log/icingaweb2/icingaweb2.log"And make sure that the sudo mkdir /var/log/icingaweb2
sudo chmod -R o+w /var/log/icingaweb2/ |
|
Thanks. But still I can't get icingaweb to produce any logs. |
Have you tried to log in once again after changing the config and log files? |
obviously yes |
Obviously it's not obvious to me, as I don't know exactly what steps you've taken and wouldn't be asking you such questions if it were that obvious. Anyway, if Icinga Web 2 is not logging anything, then it might not be trying to use LDAP as an authentication method at all. What does your |
If you think it's not obvious, then it's on you. You obviously can't test if login is working without actually logging in. And you can't (neccessarily) expect logs when nothing can happen that could be logged.
My point exactly, otherwise I should see that in the LDAP server logs, if it fails or not.
|
|
Is there any other way to get any additional logs from icinga? There's just nothing received by the LDAP server. |
|
Can you please show a screenshot of your Icinga Web 2 login page? Since you have Have you checked whether your ldap resource |
|
No. Why would I? Because with everything else that connects to this LDAP server, there's no need for that. So if that is actually necessary, it should be documented somewhere - I never came across this - and it's questionable if this should be needed when this is the only source for authentication set up.
As far as I can tell, yes. |
|
The screenshot doesn't help, I was just looking to get the error message you are facing after you entered the correct credentials.
I don't know if it's required, I was just asking, but if it's not needed by your LDAP server, then just remove it from the config. |
|
Can you also share the output of |
|
Good to know. I expected it to be necessary. This solves the issue, but I'll leave this open due to the changed title. |
Describe the bug
After going through the icinga web setup and finishing the command transport setup I'm greeted with this error message:
There aren't any entries in icingaweb2 logs though. Now how do I fix this?
To Reproduce
Provide a link to a live example, or an unambiguous set of steps to reproduce this bug. Include configuration, logs, etc. to reproduce, if relevant.
Your Environment
Include as many relevant details about the environment you experienced the problem in
icinga2 --version): r2.14.2-1icinga2 feature list):icinga2 daemon -C):zones.conffile (oricinga2 object list --type Endpointandicinga2 object list --type Zone) from all affected nodes: N.A.The text was updated successfully, but these errors were encountered: