Closed Bug 790415 Opened 12 years ago Closed 12 years ago

Flows from HCI to Zimbra

Categories

(Infrastructure & Operations Graveyard :: NetOps: DC ACL Request, task)

x86_64
Linux
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jd, Assigned: adam)

Details

Hi,

Can I please get flows to Zimbra from the web servers in HCI?

From:
intranet1.webapp.corp.phx1.mozilla.com (10.20.81.16)
intranet2.webapp.corp.phx1.mozilla.com (10.20.81.17)
intranet3.webapp.corp.phx1.mozilla.com (10.20.81.18)

To:
zmproxy1.mail.corp.phx1.mozilla.com (10.20.77.22)
cn-mail01.cn.mozilla.com (10.6.72.9)

Port:
7071

Thanks
Assignee: network-operations → adam
Part 1 of this is completed:


[root@intranet1.webapp.corp.phx1 ~]# nc -vz 10.20.77.22 7071
Connection to 10.20.77.22 7071 port [tcp/*] succeeded!


cn-mail01.cn.mozilla.com (10.6.72.9) doesn't exist. 10.6 was decommissioned with the move to the pek1.mozilla.com DC. let me know the 10.24 address and I'll work out the flow for that one. Holding open.

-Adam
If you need access to the zimbra proxy servers in pek1 its 10.24.77.23
Question: what's the purpose of this?
The reason I'm asking: If you're connecting just in order to use the SOAP API, you shouldn't need access to pek1 at all.  A connection to any Zimbra server that offers SOAP access is as good as any other, since they will all forward requests to each other internally if needed.
Dave,

First let me say that I am simply migrating a web app from one cluster to another and as part of that process I have requested network flows based on what the app in its current location has (https://infra.etherpad.mozilla.org/104). For a detailed explanation of the reasons these flows are necessary you will need to talk to Rob Tucker who built the app, however I will attempt to give an explanation as I understand it from reading the code for the app.

It looks like the access to zimbra is only for the SOAP API for creating and modifying users. Also it looks like the China portion is commented out in the app code which makes this point mute (I suspected this might be the case upon being given the information that the hostname was no longer valid). What the reasons were for this originally (why the app needed direct and specific access to China Zimbra) I have no clue.

As to your point (here and in email) about trust. I have been told (rather specifically and several times) that when migrating or upgrading existing apps that there is no reason to involve the security folks and more to the point that I should not. As I am just migrating the app I must work under the assumption that it was evaluated properly when it was initially set up. Further I do not really have the time nor the inclination to dig through the code of every app I migrate in an attempt to determine exactly what it is doing and weather or not it is valid. As I understand it that is the role that security plays on code review for initial app deployment.

In your email you say that you are "just questioning procedure" so I am trying to outlay the procedure for you here. Which is to say there is no procedure that I am aware of other than having been told that when migrating I can simply assume the existing apps are okay and to set them up "as is" in their new locations (AKA don't bug the security folks). If you feel that there should be additional measures taken I am certainly open to having that discussion.


Adam,

Given my discovery that the code which uses the China server is commented out, I am going to comment out the variable declaration in the settings file. In other words I do not need a flow opened for this and therefore will close this bug out.

Thank you for your help.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
(In reply to Jason Crowe [:jd] from comment #5)
> As I am just migrating the app I must work under the assumption that it was
> evaluated properly when it was initially set up.

And saying as much in the bug when you filed it is all you needed to do to make me happy. :) "I'm migrating this existing app that uses this flow, so the flow needs to be moved to the app's new home."
Okay,I'll try to be more explicate in the future. I assumed that the association to the bug this one blocks made that clear, guess that is what comes from me assuming :)
(In reply to Jason Crowe [:jd] from comment #7)
> I assumed that the association to the bug this one blocks made that clear, guess
> that is what comes from me assuming :)

And actually it should have...  I hadn't even noticed it had a dependency set :(  Getting blind in my old age doesn't help :(
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.