scl3 based build vpn doesn't play well with ldap magic on the clobberer



7 years ago
5 years ago


(Reporter: jhford, Assigned: dustin)



when I load while connected to the scl3 based vpn host, I am not asked for ldap which means that I can't set release clobberers

This is kind of important for me to be able to do releases once the old build vpn server shuts down.  I am able to set the clobberers by disconnecting from VPN, but that interrupts my other work.
fyi: this was also raised by coop in email on 20apr; not sure if/how that was ever resolved. 

linking to tracking bug for RelEng systems in scl3
Blocks: 735369
(In reply to John O'Duinn [:joduinn] from comment #1)
> fyi: this was also raised by coop in email on 20apr; not sure if/how that
> was ever resolved. 

No, and thank you for filing it.
Yep, and from my email response:
On 4/20/12 2:05 PM, Chris Cooper wrote:
> There are meant to be two sections to that page for releng folk: one at
> the top titled "Release Clobbers" and one underneath for "Regular
> Clobbers." Are you seeing both?
No, but I'm not on that list.  That's based on a list of allowed LDAP
logins in the script, IIRC (rather than source IP).

You're on that list:

I bet it didn't require LDAP auth from you because this VPN server is in
the releng network, whereas the other was in another VLAN that had
special access to the build network?  This may be something easier to
work out once the new relengweb1 is in place.  Can you file a bug so I
follow up?


so, thanks for the bug :)
Assignee: server-ops-releng → dustin
I'll take a look at this soon.

My *preferred* solution here will be to use for the UI, and http://clobberer.pvt.b.m.o for the API.  Those can be served from the same directory - useful since they're implemented in the same file (index.php), but that will mean that humans and machines are hitting different URLs, so there's no need to try to disambiguate the two via source IP.
the working VPN goes away in 6 days (2 of them weekend).  Please fix this before the working VPN goes away.
Severity: normal → major
This should be working for the new VPN now - I added a Deny line for its IP.  I'm a little surprised that worked!

I'm going to proceed with my plans in comment 4, but this should alleviate the concern here.
OK, better solution is in place:

The API is now at

The UI is at (302 to..) (and -stage)
The old http(s)://* still work as they always have.

The API hosts have the same ACLs are are currently on the non-https versions, so those should be fine.
Last Resolved: 7 years ago
Resolution: --- → FIXED
Component: Server Operations: RelEng → RelOps
Product: → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.