nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can I remove the trigger ip address requirement in Bamboo?

Brent Villalobo1

I'm testing out Bamboo v4.3 and I'm trying to get build triggering working. I have a plan set to "Repository triggers build when changes are committed." I then try to trigger the build and I see this error in the logs:

2012-11-28 15:32:05,933 INFO [qtp282106579-147] [TriggerRemoteBuild] Build request for plan "Z Bamboo Experiments - Accurev Plugin Test" originated from 10.67.4.196 which is not an allowed address (one of[]).

In the trigger configuration for the plan, there is a "Trigger IP Addresses" field that I left blank. If I enter the 10.67.4.196 IP address then the build triggering works fine. The problem is that I dont' want to go and enter that trigger IP address for all my plans nor do people want to remember to enter the IP address of the server that triggers the job. And there are a lot of other reasons why we don't want this check since we tend to change/move servers and things all the time within the company. We run the risk of those values going stale and there doesn't look like a way to bulk update them across all plans.

Can I disable the trigger IP address check? The note under that field says "(Optional) Bamboo ensures that triggers originate from IP addresses of the repository server(s). You can authorise additional IP addresses here, separated by a comma." What's optional? The IP address check entirely or just entering additional IP addresses to check?

Accepted answers

PiotrA

Hello Brent,

You can't currently disable the trigger IP address check. The (Optional) label is because Bamboo tries (by default) to determine the remote repository host itself, so in most cases there would be no need to input the IP address explicitly (like you know, some proxies between the repo and Bamboo, or even different server triggering the Bamboo). That said - auto-IP-detection should work for most cases, but AFAIK some repository types (namely: Mercuria and Git) have worse host IP detection support in Bamboo.

Which Bamboo version are you using? If this issue is a great pain to you I think I can stuff a "dark" system property in the next Bamboo version which would control the IP check. Just chime in (but be aware that this is a bit of security risk to allow triggering your builds from *any* IP, isn't it?)

regards,

All comments

PiotrA

Which SCM are you using? CVS?

PiotrA

Hello Brent,

regards,

Brent Villalobo1

Thanks for the reply. This is on Bamboo v4.3 using a custom AccuRev repository plugin. We worked around it by modifying the plugin itself and returning the requesting IP address in the getHost() method. I looked at the TriggerRemoteBuild.java file in the Bamboo source and saw that in the validateTriggerIp() method it adds the value returned by getHost() to the allowed triggering hosts list. And since our getHost method is doing the same logic as getRequestIpAddress() in TriggerRemoteBuild.java, they will always match up.

Just as a bit of commentary, while allowing triggering builds from any IP might be a security risk, all our infrastructure is behind a corporate firewall. So all triggering events will be logged anyway and we can find out if anyone is abusing the system and not following the best practice policies we've put in place.

Like I said in the original comment, we change servers and other parts of our SCM infrastructure occaisionally. Since we have hundreds of plans that have build triggers, we can't manually go through and change the allowed hosts every time there is a change. And we don't expect people creating plans to know the IP addresses or host names of our SCM servers. Nor do systems people want to coordinate with the software engineers to update the getHost() method whenver they need to make a change (I guess would could do something clever like look at an extrnal file for that information).

PiotrA

Hm... that makes sense.

Hacking the .getHost() method in your Repository is a neat idea. I like it.

cheers,

S_dgqn3s

A system wide setting would be really appreciated for our use (where everything sits behind a proxy). Ideally as an administrative setting which allows for creation of a whitelist.

Adrian Porter1

Agreed. I don't think I can easily change this parameter for the dozens of bamboo projects I administer. Now that bamboo has (recently) changed how they look at this variable, I have to go through and manually update them.