Securedrop: Staging environment broken

Created on 28 Apr 2018  路  7Comments  路  Source: freedomofpress/securedrop

Description

Staging VMs are broken on macOS due to the lack of /bin/ip

Steps to Reproduce

  1. Have a Mac
  2. make build-debs
    3.vagrant up /staging

Expected Behavior

All is merry and well

Actual Behavior

TASK [restrict-direct-access : Determine admin network - first find admin net dev] ***
/bin/sh: /bin/ip: No such file or directory
fatal: [app-staging]: FAILED! => {"msg": "An unhandled exception occurred while running the lookup plugin 'pipe'. Error was a <class 'ansible.errors.AnsibleError'>, original message: lookup_plugin.pipe(/bin/ip r get 10.0.1.2) returned 127"}
/bin/sh: /bin/ip: No such file or directory
fatal: [mon-staging]: FAILED! => {"msg": "An unhandled exception occurred while running the lookup plugin 'pipe'. Error was a <class 'ansible.errors.AnsibleError'>, original message: lookup_plugin.pipe(/bin/ip r get 10.0.1.3) returned 127"}

Comments

This is because /bin/ip is not present on mac

bug priorithigh staging VMs

Most helpful comment

Staging environment does not work on GNU/Linux. Steps to reproduce:

...
TASK [Reboot if required due to security updates.] *****************************
changed: [app-staging] => {"changed": true, "cmd": ["shutdown", "-r", "now"], "delta": "0:00:00.016358", "end": "2018-05-05 10:39:41.092850", "rc": 0, "start": "2018-05-05 10:39:41.076492", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}
changed: [mon-staging] => {"changed": true, "cmd": ["shutdown", "-r", "now"], "delta": "0:00:00.014207", "end": "2018-05-05 10:39:41.063773", "rc": 0, "start": "2018-05-05 10:39:41.049566", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}

TASK [Wait for server to come back.] *******************************************
fatal: [app-staging -> localhost]: FAILED! => {"changed": false, "elapsed": 301, "msg": "Timeout when waiting for search string OpenSSH in 192.168.121.238:22"}
fatal: [mon-staging -> localhost]: FAILED! => {"changed": false, "elapsed": 301, "msg": "Timeout when waiting for search string OpenSSH in 192.168.121.109:22"}

The same steps on 0.6 work as expected. It also works as of d5a2b3eed65e590e97bb67f5797cf2f043650333 which is right before https://github.com/freedomofpress/securedrop/pull/2592 was merged.

All 7 comments

Staging environment does not work on GNU/Linux. Steps to reproduce:

...
TASK [Reboot if required due to security updates.] *****************************
changed: [app-staging] => {"changed": true, "cmd": ["shutdown", "-r", "now"], "delta": "0:00:00.016358", "end": "2018-05-05 10:39:41.092850", "rc": 0, "start": "2018-05-05 10:39:41.076492", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}
changed: [mon-staging] => {"changed": true, "cmd": ["shutdown", "-r", "now"], "delta": "0:00:00.014207", "end": "2018-05-05 10:39:41.063773", "rc": 0, "start": "2018-05-05 10:39:41.049566", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}

TASK [Wait for server to come back.] *******************************************
fatal: [app-staging -> localhost]: FAILED! => {"changed": false, "elapsed": 301, "msg": "Timeout when waiting for search string OpenSSH in 192.168.121.238:22"}
fatal: [mon-staging -> localhost]: FAILED! => {"changed": false, "elapsed": 301, "msg": "Timeout when waiting for search string OpenSSH in 192.168.121.109:22"}

The same steps on 0.6 work as expected. It also works as of d5a2b3eed65e590e97bb67f5797cf2f043650333 which is right before https://github.com/freedomofpress/securedrop/pull/2592 was merged.

Sorry I totally missed this. I can try to work on this sooner.... @eloquence ?

@msheiny, yes, absolutely given the priority; it's on our current sprint backlog so ready to work on whenever you can.

Yes, I can confirm the same results that @dachary reports: staging VMs aren't coming back up after final reboot.

hey @redshiftzero - do you think advising Mac users to install iproute2mac is going to be problematic work-around ?

nm scratch that idea... that software isnt being actively worked on

We are seeing two different issues here btw...

  • Linux users are getting bit by the primary_network_iface being set to eth1 instead of eth0 (easily fixable with a conditional jinja statement)
  • @redshiftzero is being bit by my over-reliance on the ip tooling that exists on linux but not on mac :(

I gotta split for the day so I'm dumping the output provided to me out of band for tomorrow's follow up

$ route -n get 8.8.8.8
  route to: 8.8.8.8
destination: default
      mask: x.x.x.x
   gateway: x.x.x.x
 interface: utun1
     flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
      0         0         0         0         0         0      1500         0 
$ vagrant ssh app-staging -c "ip a"
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether 08:00:27:ca:da:ee brd ff:ff:ff:ff:ff:ff
   inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
      valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
   link/ether 08:00:27:40:84:9d brd ff:ff:ff:ff:ff:ff
   inet 10.0.1.2/24 brd 10.0.1.255 scope global eth1
      valid_lft forever preferred_lft forever
Connection to 127.0.0.1 closed.
Was this page helpful?
0 / 5 - 0 ratings