Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix permissions bug Gemfile.lock #12301

Merged
merged 1 commit into from Sep 10, 2019

Conversation

@matusso
Copy link
Contributor

commented Sep 9, 2019

There was an error while trying to write to /usr/src/metasploit-framework/Gemfile.lock. It is likely that you need to grant write permissions for that path.

#12300

fix permissions bug Gemfile.lock
There was an error while trying to write to /usr/src/metasploit-framework/Gemfile.lock. It is likely that you need to grant write permissions for that path.
@timwr

This comment has been minimized.

Copy link
Contributor

commented Sep 9, 2019

Seems reasonable, an alternative (temporary?) solution might be to update the Gemfile.lock so it doesn't get modified by the bundler, e.g:

diff --git a/Gemfile.lock b/Gemfile.lock
index 2a8b5d2bc6..fe794fecec 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -59,7 +59,7 @@ PATH
       rex-random_identifier
       rex-registry
       rex-rop_builder
-      rex-socket (= 0.1.17)
+      rex-socket
       rex-sslscan
       rex-struct2
       rex-text
@@ -115,7 +115,7 @@ GEM
     arel-helpers (2.10.0)
       activerecord (>= 3.1.0, < 7)
     aws-eventstream (1.0.3)
-    aws-partitions (1.208.0)
+    aws-partitions (1.210.0)
     aws-sdk-core (3.66.0)
       aws-eventstream (~> 1.0, >= 1.0.2)
       aws-partitions (~> 1.0)
@@ -351,7 +351,7 @@ GEM
       rubyntlm
       windows_error
     rubyntlm (0.6.2)
-    rubyzip (1.2.3)
+    rubyzip (1.2.4)
     sawyer (0.8.2)
       addressable (>= 2.3.5)
       faraday (> 0.8, < 2.0)

@DavHau

This comment has been minimized.

Copy link

commented Sep 9, 2019

Maybe adding a test to the build pipeline that checks if at least the program can be started without errors would be nice to prevent problems like that in the future. Also keeping the last few builds on docker hub could be useful. Only the latest build is available currently

@busterb busterb self-assigned this Sep 10, 2019

busterb added a commit that referenced this pull request Sep 10, 2019

@busterb busterb merged commit 9297809 into rapid7:master Sep 10, 2019

3 checks passed

Metasploit Automation - Sanity Test Execution Successfully completed all tests.
Details
Metasploit Automation - Test Execution Successfully completed all tests.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
msjenkins-r7 added a commit that referenced this pull request Sep 10, 2019
@busterb

This comment has been minimized.

Copy link
Member

commented Sep 10, 2019

Looks like somehow the Gemfile got updated without a commit on Gemfile.lock. The build pipelines do check if things can start without errors, but they also initially run 'bundle' and fixup the .lock file implicitly, which was hiding this when the first appeared last week. Will make a note of it to see if there's a better way to detect the mismatch in master.

@busterb

This comment has been minimized.

Copy link
Member

commented Sep 10, 2019

Thanks for the fix @matusso, I updated the committed Gemfile.lock as well, though belt and suspenders didn't hurt here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.