Hi,
I am using sonarqube version 8.4.1.35646 (from docker image docker.io/library/sonarqube).
I am trying to get users and groups from LDAP but none of the combinations I tried give me a working result:
I get an instance of SQ that is stuck with “SonarQube is starting” and never proceeds.
My log (with level DEBUG) ends with
2020.08.10 15:15:56 INFO web[][o.s.a.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn="cn=users,cn=accounts,dc=intgdc,dc=com", request=(&(objectClass=inetOrgPerson)(uid={0})), realNameAttribute=cn, emailAttribute=mail}
2020.08.10 15:15:56 INFO web[][o.s.a.l.LdapSettingsManager] Groups will not be synchronized, because property 'ldap.group.baseDn' is empty.
I tried to debug network with tcpdump but I can only confirm that communication happens (2 packates in one direction, 2 back) but stops pretty early and nothing is happening.
Full DEBUG log:
I also tried this combination (+also imported certificate of the freeipa server and root certificate of the corresponding CA):
Debug-level actually makes this rather difficult to look at. Any time you’re dealing with a startup failure, you should get everything you need at the ERROR level (i.e. by default).
When I plopped your log into a text editor and stripped out all the debug lines, I was able to see that the connection to port 9001 is being refused. That’s significant because it’s the port that SonarQube runs ElasticSearch on by default. My guess is that
a) you’ll find more detail in some of the other server logs
b
b) you started up SonarQube, configured LDAP and then tried to restart but not all of the processes from the first run shut down & so now your second run is blocked trying to get the ES port.
Hi Ann,
thank you for your reply. The problem with port 9001 is indeed from my various tests where I didn’t shut down the container properly. If I do the same again from scratch (+switch off the DEBUG output) I still get the same result:
stuck start with
ldap.StartTLS=true
ldap.url=ldap://na1-freeipa01.intgdc.com:636
With the help of LDAP logs I was able to find out that the bindDn option was wrong. It was passed on quite literally. So it included double quotes “” I had put around the dn=… string.
After removing those I was able to use ldap(389)+startTLS and also ldaps(636)+no startTLS