Hi all,

Just to inform that I discovered a "bug" in :

/usr/local/buildmaster/service/agents/linux-x64/links.json

This file contains lines like:

"fr\\Microsoft.Data.SqlClient.resources.dll":  "fr\\Microsoft.Data.SqlClient.resources.dll",

From what I can understand, this file makes a mapping (link) between windows named path to Linux named path but in this case the value part should contain "/" instead of "\\"

Because of that, there is an error in server ssh connection as the file name is incorrect.

I changed the file with the help of a configMap replacing the faulty json with a correct one.

This file now contains line like:

"fr\\Microsoft.Data.SqlClient.resources.dll":  "fr/Microsoft.Data.SqlClient.resources.dll",

This should be patched in a future release...

Hope this helps,
Marc

Hi Alana,

THanks for your answer. However, in the GUI, I don't have the openLDAP choice:

V1: LDAP or Single Domain Active Directory (Legacy)
BuildMaster will use the user and group information of a single domain or a generic LDAP directory.

V2: Active Directory Domain Forest (Legacy)
BuildMaster will use the global catalog for the current forest, and also all domains which have an inbound trust. If you only have one domain, the LDAP directory should be used instead.

V3: Active Directory (Deprecated)
Queries the current domain, global catalog for trusted domains, or a specific list of domains for users and group membership.

V4: Active Directory/LDAP
Queries the current domain, global catalog for trusted domains, or a specific list of domains for users and group membership.

How can I have access to the openLDAP option?

Kind regards,
Marc

Is there a way to use LDAP authentication in Buildmaster when used in a Docker container (OpenShift)?

Hi @atripp ,

Thanks for the suggestions. Concerning the LogMessages table, we already have those messages displayed on the OpenShift console, but nothing suspect can be seen.

What I'll try is to test a fresh install of the last BuildMaster version and see what difference we have with our "updated" version.

I'll keep you in touch.
Marc

I already checked the console an didn't see anything bad, except those lines:

Unable to auto-activate license. Error was: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
Unable to auto-activate license. Error was: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
Request finished HTTP/1.1 GET http://mdw-deploy-bima-alpha.apps.gcloud-04.paas.services.gcloud.belgium.be/ - 302 0 - 100320.3875ms

As we do not have connection to the internet, even by proxy, those messages should be considered as "normal"

What is strange, is that we have listeners on ports, but a curl on those ports are failing in timeout...

Marc

Hi all,

We have a running Buildmaster v 7.0.23 on OpenShift that we want to upgrade to the last version (24.0.x)

Upgrading to 7.0.25 is working. But when I want to upgrade to 22.x or higher, I cannot access to the app: err 504: gateway timeout. A curl inside the container gives the same result.

I already had a look at the thread "[ProGet] Manual database upgrade (docker, kubernetes)", but the solution is using the arg "upgrade" of ProGet that is not existing for BuildMaster.

What hint do you suggest me to solve this problem?

Thanks in advance,
Marc

@atripp Thanks for your reply... This is a good reason to planify an upgrade!

Marc

I forgot to mention: this is an old version: 7.0.23

Hi all,

In BuildMaster, when I want to access an event in the Buildmaster event page, I get a window with :

Unexpected Error
(500) Server Error
Collection is not a wrapped Inedo.Web.Controls.SimpleHtml.Td collection. (Parameter 'collection')
For more information, visit the Error Log Page.

What can be the meaning of this message?

Kind regards,
Marc

Hello people!

We are currently using aan old version of BM (7.0.23) on OpenShift. Therefore the license is validated against a rather dumb host string.

But while I attempted to upgrade to a more recent version (22.0.15), I noticed that this string has changed to a more consistent value.

My question is: on which criteria this string is based on? In other words, what if we decide to move the pod to an other node, or rename the container/pod/project name?

Have a sunny day (just like here in Belgium)
Marc