1443907 - Need SSH access to Vertica Staging and Dev

Status: RESOLVED FIXED

(Infrastructure & Operations :: Infrastructure: LDAP, task)

Description

[Nancy Wong]

Can you please provide SSH access for user nawong for following servers:

vertica[4-6].stage.metrics.scl3.mozilla.com
vertica[7-9].stage.metrics.scl3.mozilla.com

Comment 1

[Salvador Espinoza [:sal]]

Getting someone to look at this.

Comment 2

[Justin Dow [:jabba]]

It looks like you are already a member of vpn_vertica, and it looks like this should provide access to the vertica hosts, but I'm not too familiar with the puppet module for this and it looks a little different than I'm used to. Is access not working?

Comment 3

[Nancy Wong]

Access is not working for Vertica staging/dev servers but I am able to getting into Vertica prod.  
I should have same access as cvalaas who is able to ssh into Vertica staging/dev.



mozpdx-20874:Downloads nawong$ ping 10.22.72.136
PING 10.22.72.136 (10.22.72.136): 56 data bytes
64 bytes from 10.22.72.136: icmp_seq=0 ttl=64 time=23.065 ms
64 bytes from 10.22.72.136: icmp_seq=1 ttl=64 time=22.937 ms
64 bytes from 10.22.72.136: icmp_seq=2 ttl=64 time=23.352 ms
64 bytes from 10.22.72.136: icmp_seq=3 ttl=64 time=22.826 ms
64 bytes from 10.22.72.136: icmp_seq=4 ttl=64 time=23.888 ms
64 bytes from 10.22.72.136: icmp_seq=5 ttl=64 time=23.224 ms
64 bytes from 10.22.72.136: icmp_seq=6 ttl=64 time=23.618 ms

mozpdx-20874:Downloads nawong$ traceroute vertica9.stage.metrics.scl3.mozilla.com
traceroute to vertica9.stage.metrics.scl3.mozilla.com (10.22.31.60), 64 hops max, 52 byte packets
 1  10.22.248.1 (10.22.248.1)  22.939 ms  22.542 ms  22.747 ms
 2  * * *
 3  * * *

mozpdx-20874:Downloads nawong$ ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
	inet 127.0.0.1 netmask 0xff000000 
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
XHC20: flags=0<> mtu 0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 3c:15:c2:ca:1b:ec 
	inet6 fe80::1495:7cc8:e5fa:c0ac%en0 prefixlen 64 secured scopeid 0x5 
	inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
	ether 0e:15:c2:ca:1b:ec 
	media: autoselect
	status: inactive
awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484
	ether ba:2a:51:e2:27:74 
	inet6 fe80::b82a:51ff:fee2:2774%awdl0 prefixlen 64 scopeid 0x7 
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	options=60<TSO4,TSO6>
	ether 72:00:03:75:63:80 
	media: autoselect <full-duplex>
	status: inactive
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	options=60<TSO4,TSO6>
	ether 72:00:03:75:63:81 
	media: autoselect <full-duplex>
	status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=63<RXCSUM,TXCSUM,TSO4,TSO6>
	ether 72:00:03:75:63:80 
	Configuration:
		id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
		maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
		root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
		ipfilter disabled flags 0x2
	member: en1 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 8 priority 0 path cost 0
	member: en2 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 9 priority 0 path cost 0
	nd6 options=201<PERFORMNUD,DAD>
	media: <unknown type>
	status: inactive
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
	inet6 fe80::6ad9:e9db:7b0:6015%utun0 prefixlen 64 scopeid 0xb 
	nd6 options=201<PERFORMNUD,DAD>
utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
	inet 10.22.248.102 --> 10.22.248.101 netmask 0xffffffff

Comment 4

[Justin Dow [:jabba]]

I couldn't find an existing vpn group that these hosts were part of, I'm guessing they were traditionally accessed via vertica-gw or via vpn_admin rights. I went ahead and added them all to vpn_vertica group, so it should work now, after you restart your vpn client.