Per bug 1172191 the code running on triage1.dmz.scl3.mozilla.com has passed secreview and is ready to face the nation. If I could have triagebot.mozilla.com (port 80 only) point to port 80 on triage1.dmz.scl3.mozilla.com, that would be lovely.
Why is this non-SSL?
Also, why .com instead of .org ?
Summary: Make → Expose triagebot publicly at triagebot.mozilla.com
If .org is the right place for this, I'd be perfectly happy for it to be .org. I'd also be happy for it to be SSL, but I don't think that I'm empowered to set that up in our environment.
OK, so http or https? Please let me know which port(s) I should be configured as open. Thanks.
Assignee: network-operations → dcurado
Status: NEW → ASSIGNED
Moving forward on this: I have assigned 184.108.40.206, and have added an A and PTR record for triagebot.mozilla.org triagebot.mozilla.org A 220.127.116.11 18.104.22.168 PTR triagebot.mozilla.org I'll set up the NAT on the firewall now, but will hold off on installing a security policy allowing access to the server, until you determine which port(s) you'd like open. e.g. 80 or 443 Thanks -- Dave
I'd like https, with the caveat that I'll need guidance about what if anything I'll need to do on my end to make that work properly.
OK, I will configure a security policy on the firewall that allows packets in to port 443/tcp to your server. Sorry, I can not help you in setting up https on the server. I just don't know anything about that. I can ask the infra team of sysadmins in order to get you pointed in the right direction, if you'd like. (at least they would know who you can work with)
OK, I have set up the security policy allowing https inbound to your server. (don't worry that the private IP address shows up in the policy shown below, the firewall takes care of the inbound NAT translation before the packet hits this security policy) From zone: untrust, To zone: dmz Source addresses: any-ipv4: 0.0.0.0/0 any-ipv6: ::/0 Destination addresses: triagebot.dmz.scl3: 10.22.74.153/32 Application: junos-https IP protocol: tcp, ALG: 0, Inactivity timeout: 1800 Source port range: [0-0] Destination port range: [443-443] Thanks -- Dave
OK, I think the netops part of this request is done. I asked some folks in the systems group who you could get help from vis-a-vis setting up https. The suggestion I got back was "WebOps" So, would it be OK to suggest to you to open a bug for that group, and reference this bug? The Bugzilla category is Infrastructure and Operations, then Webops:xxxx where xxxx is the sub category that best describes your situation. Please let me know what you think? Thanks -- Dave
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
This was supposed to go through webops for a Zeus setup for the site rather than NAT :/
Component: NetOps → WebOps: Other
QA Contact: jbarnell → smani
<sigh>. I'll undo the firewall configuration.
I have un-configured the stuff I did on the SCL3 firewall.
Summary: Expose triagebot publicly at triagebot.mozilla.com → Expose triagebot publicly at triagebot.mozilla.org
Mike: I believe things are working. Can you please verify that everything looks like it is working from your perspective? Based on feedback in IRC, triagebot.mozilla.org is set up to automatically redirect HTTP traffic to HTTPS. For right now, there is no need to set any of the usual "forwarded for" headers. I've also created a service entry in Inventory which lists the technical owner of the service (AKA "who should be poked if the underlying server is having issues") as Mike Hoye with a business owner (AKA "who makes money-related decisions about this") as Brian Smedberg.  $ curl -I http://triagebot.mozilla.org HTTP/1.1 301 Moved Permanently Content-Type: text/html Date: Mon, 13 Jul 2015 21:29:53 GMT Location: https://triagebot.mozilla.org/ Connection: Keep-Alive Content-Length: 0 $ curl -I https://triagebot.mozilla.org HTTP/1.1 200 OK Server: lighttpd/1.4.28 Content-type: text/html Date: Mon, 13 Jul 2015 21:30:02 GMT Transfer-Encoding: chunked Connection: Keep-Alive
Looks good from here, and I'll double-check when I get home. Thanks so much for not only setting this up, but for finding Benjamin's long-lost twin brother in the process! Who would have suspected Brian was working for Mozilla all along?
Ah, the joys of freely editable text fields rather than drop-downs. Name fixed.
(Thanks again, for real.)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.