# Metasploit installation problems

## Benim

I have been trying to install metasploit for a month on and off now, but I seem to run into problems with Ruby dependencies.

After installing the gems manually that seemed missing, many of them still weren't found by emerge.

Emerge-info:

https://pastebin.com/VYpHX95A

Build log:

https://pastebin.com/2d5KT82Z

Today I tried to install both the 9999 version as the 4.17 version, but emerge said:

emerge: there are no ebuilds to satisfy "=metasploit-4.17"

Any idea what the problem might be?

----------

## fedeliallalinea

Welcome to gentoo forums!

 *Benim wrote:*   

> Today I tried to install both the 9999 version as the 4.17 version, but emerge said:
> 
> emerge: there are no ebuilds to satisfy "=metasploit-4.17"

 

Correct way to install 4.17 version is

```
# emerege =metasploit-4.17.21-r5
```

or

```
# emerge metasploit:4.17
```

----------

## Benim

 *fedeliallalinea wrote:*   

> Welcome to gentoo forums!
> 
>  *Benim wrote:*   Today I tried to install both the 9999 version as the 4.17 version, but emerge said:
> 
> emerge: there are no ebuilds to satisfy "=metasploit-4.17" 
> ...

 

Thank you very much for responding. Another problem arose with the 4.17 install.

Here is the output log of emerge:

https://pastebin.com/fVDiBmQ7

----------

## alamahant

I had sandbox violations twice when emerging perl and more recently with cdrtools.

I used a dirty and apparently 'not recommended" solution.

Try this:

```

FEATURES="-sandbox -usersandbox" emerge -DNaq metasploit:4.17

```

This will "turn off" the sandbox just for emerging metasploit.

I dont know the exact security implications and maybe some adept members will totally disapprove but this is how I emerged things that would simply not emerge.

Admittedly the ideal would be to find out and rectify why the compilation violates the sandbox but this calls for a maintainer or a developer who would maybe apply a patch or something....... 

 :Smile: 

----------

## Hu

Yes, that is a dirty hack and I disapprove.  You should only turn off the sandbox when you can explain why the sandbox is wrong to block the package.  If you don't understand whether it is wrong, you should leave it on until you can investigate and understand.  The consequences of disabling the sandbox range from irrelevant to a package installing unmanaged files or mangling your existing files.  Forum regulars routinely warn people about the future problems created by leaving unmanaged files lying around, since those are invisible to dependency analysis.

----------

## alamahant

But practically speaking what should one do when he can not update the system for example because of a perl update?????

How can one investigate the reasons and correct the problem???

Will it not involve going into the extracted dir and doing a manual intervention in the make file of a particular package?

----------

## fedeliallalinea

 *alamahant wrote:*   

> But practically speaking what should one do when he can not update the system for example because of a perl update?????
> 
> How can one investigate the reasons and correct the problem???

 

Generally a sandbox problem is caused by wrong package install system and the ebuild should workaround the problem. 

If isn't the case open a new bug report is correct way.

For return on topic see https://bugs.gentoo.org/688546

----------

## alamahant

fedeliallalinea

Thank you thank you for the clarity..

It makes more sense now.

I have 2 sandbox violation bugs to report.

Should I reemerge  the offenders without the FEATURES thing and report them now or should I wait for their next update?

Thanks  

 :Smile: 

----------

## fedeliallalinea

 *alamahant wrote:*   

> Should I reemerge  the offenders without the FEATURES thing and report them now or should I wait for their next update?

 

If problem persist for more than  24h you can report as bug following https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide

----------

