binwiederhier / replbot

Slack/Discord bot for running interactive REPLs and shells from a chat.
Apache License 2.0
199 stars 8 forks source link

Update & add some included REPLs, update readme.md #31

Closed ghost closed 3 years ago

ghost commented 3 years ago

-Slightly modified some existing REPLs to use official images from Docker Hub. Feel free to leave out this change, Docker Hub pull limits aren't great.

-Added the following REPLs that we have been using in our server verified that they work without issue (and provide a ton of fun): Alpine, Amazon Linux, Arch Linux, CentOS, Debian & Fedora.

-Updated readme.md to reflect the added default REPLs.

These added REPLs are all things we found fun to play around with in our server so figured I'd share, and hopefully save someone a few seconds from having to create their own :smile: With that said, it is super easy to add your own.

codecov-commenter commented 3 years ago

Codecov Report

Merging #31 (0ade632) into main (c12079e) will decrease coverage by 0.14%. The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##             main      #31      +/-   ##
==========================================
- Coverage   37.04%   36.89%   -0.15%     
==========================================
  Files          10       10              
  Lines        1347     1347              
==========================================
- Hits          499      497       -2     
- Misses        779      780       +1     
- Partials       69       70       +1     
Impacted Files Coverage Δ
bot/util.go 54.28% <0.00%> (-2.86%) :arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update c12079e...0ade632. Read the comment docs.

binwiederhier commented 3 years ago

Slightly modified some existing REPLs to use official images from Docker Hub. Feel free to leave out this change, Docker Hub pull limits aren't great.

So the reason why I modified the official image is because I feel like 50+% of the time in the ubuntu image you spend on apt update (mostly) and apt install for the basics, which is why I think I'd like to keep my modified images. Could you remove those changes from your PR and then I'll merge it.

You could make "ubuntu-official" maybe if you really want, though that may be confusing and unweildy.

We could also make a docker image and make a way to pass arguments to a script, so I could just say @replbot docker:ubuntu for instance. That'd be kinda cool.

Also, I was looking into ways to automatically build and update them automatically via github actions, but that seems to be rather hard: https://github.com/binwiederhier/docker/

ghost commented 3 years ago

Ahh ok, that makes sense! I was trying to think of why it may have been done but didn't even think about that. That's a great point and there really isn't much you can do on the base image without updating the package repo + adding some basic packages.

I'll go ahead and revert those changes - certainly don't want to make things unnecessarily complex. Adding a feature such as being able to pull any Docker image would be awesome, I'll start tinkering around with that.

I've also been playing with setting --memory and --cpu flags on the containers to limit their available resources, hoping to maybe work that into the global config so there isn't a need to do it individually per each REPL script. (Makes it a bit harder to cripple the host the containers are running on when something goes wonky) I'll look into a mostly hands-off way of updating Docker images and publishing them, but a workflow integrated with Github would be definitely be awesome 🤔

binwiederhier commented 3 years ago

I've also been playing with setting --memory and --cpu flags on the containers to limit their available resources, hoping to maybe work that into the global config so there isn't a need to do it individually per each REPL script. (Makes it a bit harder to cripple the host the containers are running on when something goes wonky) I'll look into a mostly hands-off way of updating Docker images and publishing them, but a workflow integrated with Github would be definitely be awesome thinking

This is so funny. I literally just had a co-worker ask about fork bombs and I tried it and it more or less crashed the host. So I'll try to put some limits in place. I've had a ticket for this for a while (https://github.com/binwiederhier/replbot/issues/10).

binwiederhier commented 3 years ago

As for the common stuff, you could make a helpers/docker-run script.

binwiederhier commented 3 years ago

Apparently containers can also talk to each other, which I think is less of an issue than the memory and ulimit stuff.

210901 14-27-06 Selection 001

This is where I am right now: docker run --cpus=.5 --ulimit="nofile=200" --kernel-memory=10M --memory=100M -it binwiederhier/ubuntu

I was also looking at --cap-drop all and then re-adding caps manually, see https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html -- But I have to stop now for actual work

binwiederhier commented 3 years ago

I'm gonna merge and modify. Thanks for your contribution. Keep them coming.

binwiederhier commented 3 years ago

@axitedotdev See here: https://github.com/binwiederhier/replbot/commit/8b8220738d20b5ecaec4108b077e68348f7df699

This should make it safe against fork bombs and give it some sane defaults for ram and cpu. I'm gonna look into disk now.

binwiederhier commented 3 years ago

Here's another one https://github.com/binwiederhier/replbot/commit/ab17f83675f25072855deb6dc0e6b5faa345a604

ghost commented 3 years ago

I've also been playing with setting --memory and --cpu flags on the containers to limit their available resources, hoping to maybe work that into the global config so there isn't a need to do it individually per each REPL script. (Makes it a bit harder to cripple the host the containers are running on when something goes wonky) I'll look into a mostly hands-off way of updating Docker images and publishing them, but a workflow integrated with Github would be definitely be awesome thinking

This is so funny. I literally just had a co-worker ask about fork bombs and I tried it and it more or less crashed the host. So I'll try to put some limits in place. I've had a ticket for this for a while (#10).

LOL, my buddies fork bombed mine less than 5 minutes after setting it up. Good fun though. Thanks for the merge, and awesome to see the two changes for container resource limits & disk limits!! Good stuff. Hoping to spend some more time on this after the holiday weekend -- enjoy!