Open alexvasseur opened 8 years ago
i think i understand your issue.
If you are leveraging haproxy to control the point of ingress, wouldn't it make sense to forward ssh through your HAProxy as well?
We would need to change the ssh port that OpsMan is using - as we can't change the ssh port that the HAProxy is using. So all in all would still require cfops change.
This is impact analysis of areas likely to change: This impacts github project cfbackup it seems.
https://github.com/pivotalservices/cfbackup/blob/develop/tiles/opsmanager/opsmanager.go https://github.com/pivotalservices/cfbackup/blob/develop/tiles/opsmanager/const.go
var NewOpsManager = func(opsManagerHostname string, adminUsername string, adminPassword string, opsManagerUsername string, opsManagerPassword string, opsManagerPassphrase string, target string, cryptKey string) (context *OpsManager, err error) {
...
Hostname: opsManagerHostname,
SSHPort: OpsMgrDefaultSSHPort,
...
OpsMgrDefaultSSHPort int = 22
https://github.com/pivotalservices/cfops/search?q=NewOpsManager
opsManager, err = opsmanager.NewOpsManager(tileSpec.OpsManagerHost, tileSpec.AdminUser, tileSpec.AdminPass, tileSpec.OpsManagerUser, tileSpec.OpsManagerPass, tileSpec.OpsManagerPassphrase, tileSpec.ArchiveDirectory, tileSpec.CryptKey)
TileSpec struct {
OpsManagerHost string
Concern I have is the ssh specific flag would make the flags and UX harder to understand, as this is a very specific edge case to accommodate.
What might allow us to achieve the same result but in a more generally applicable way is to make an additional flag for UAA Auth Host/IP
or something like that. When set, we use that to make the auth call to the uaa, if not set then we just use the regular ops manager host/ip...
The UAA only understanding a single host (which is a common support question) is something that a override flag would address nicely.
I believe this will also help you in your scenario. Let me know if this sounds workable.
Yes that makes sense if the UAA client can deal with a specific Host/IP header
cool, its in our backlog. Ill keep this issue up to date as it progresses.
Checking prioritization of this
there is a new product team that has been spun up within pivotal that now owns cfops. They are now the source for priority info. @kdudala1 can answer this for you, he is the PM.
We have PCF 1.7 and using cfops latest 2.2.29 The OpsMan is behind an HA proxy for security & network layout reasons. https://proxyIP forwards to OpsMan:443 The OpsMan UAA is therefore remembering that proxyIP is the access IP.
All fine for ER backup - but having issues for OpsMan backup with --opsmanagerhost we can target the UAA-aware proxyIP, but then we have ssh failing to access /var/tempest and do its work - as it goes ssh to proxyIP obviously. if we use OpsMan IP, then UAA does not authenticate.
Would it be possible to add an optional --opsmanagersshhost (--omssh) that if present would be the one used in calling https://github.com/pivotalservices/cfbackup/tree/develop/tiles/opsmanager especially https://github.com/pivotalservices/cfbackup/blob/develop/tiles/opsmanager/opsmanager.go
or would you propose something else?