• 0 Posts
  • 32 Comments
Joined 3 years ago
cake
Cake day: June 20th, 2023

help-circle
  • For learning, VMs are fine. Spin up as many as you’d like. Install, duplicate, reinstall, delete at will. I would start there.

    Then, while you’re learning, set aside since money to get an SBC or mini pc. That will allow you to keep it running as a server continuously. Phones can work for this, but to act as servers you’ll probably need to root them.

    Computers are way more expensive than they used to be but within reach for most people if you can save up for it.

    Check thrift stores, Facebook, eBay, the usual suspects. Watch out for PCs stripped for RAM and other shenanigans, though.






  • It depends greatly on the game. For a shooter I probably just want to jump in for a little while and blast things. A lengthy intro will just be annoying.

    Even forced tutorials are annoying like that. I like when games give me the option to skip, and then to come crawling back to the tutorial when I clearly should have done it anyway.

    I think games that let you pick your own style and pace work best for me. Open world games, for example, where I can go discover the story for myself, but it’s just there in the background otherwise. I’m ok with some hints though, like overhearing NPC conversations or finding random notes.

    Even something we simple as Portal works. You’re solving puzzles, but you can discover the story behind it by looking for more clues. Half life, too, is really light on telling you what’s going on until you play through and discover more. But you could also just play it through without paying any attention to the story part.

    I don’t think I’ve bounced off a game because it was lacking a story, but I’ve definitely given up on games because there was too much fuss to get going. I have little tolerance for long unskippable cut scenes and dialogue as well.

    I have quit games I just couldn’t figure out or enjoy without taking a long time to learn how it works before even getting started. I like to learn things gradually.

    Don’t get me wrong: a good story that is revealed over time to be does add a lot to the game. I just want to feel like I’m paying a game, not watching a movie or reading a book


  • I don’t see anyone addressing the question from the post: whether it is a problem that Docker Desktop on Linux runs in a separate VM.

    The page says:

    Docker Desktop on Linux runs a Virtual Machine (VM) which creates and uses a custom docker context, desktop-linux, on startup. This means images and containers deployed on the Linux Docker Engine (before installation) are not available in Docker Desktop for Linux.

    To expand on what that means: If you install Docker as usual (the CLI) on Linux, it runs as a process (running as root). The process will isolate the container processes from the rest of the system using Linux kernel features, but you’re really just running processes on your host kernel that have limited access to the file system, network, etc.

    When you run in it a separate VM, which is how Docker Desktop is also run on Windows and MacOS, you are running it in a separate Linux instance (VM) that cannot communicate with the outside by default. So, if you’re running Docker on the host computer and inside a VM, those are separate Docker installs and can’t talk to each other. That is what the warning is about.

    You can absolutely expose the VM to the outside, the same as if you ran it on Windows. Docker will let you expose those ports and it handles the messy bits of the networking for you. You just have to tell Docker when you run the container (on the command line or in a docker compose file) which ports to expose. By default, nothing is exposed. To do that you can use the -p option. For example:

    docker run --rm -it -p 8080:80 httpd

    Will run an instance of Apache HTTPd and expose it on port 8080. The container itself listens to port 80, but on the outside it’s 8080. If you then hit http://localhost:8080/ you should see “It works!”.

    A note on Docker networking: from within the container, localhost is referring to the container itself, not the host. So if you try to do e.g. curl http://localhost:8080/ inside the container, your connection would be refused.

    Docker Desktop is often frowned upon because you have to pay to use it in a commercial setting (there was some backlash because it used to be free), it’s quite expensive, and they require a minimum license count for enterprise licenses (I know because we bought one at work). So, I suggest exploring free alternatives like Podman Desktop. However, note that they do not always have feature parity with Docker Desktop.

    I like Docker Desktop because it gives me a nice dashboard to see all my containers, resource usage, etc. I would not have requested it for work, though, if it weren’t for my IDE (Visual Studio) requiring it at the time (they have added Podman support since).

    Final note: I recommend just diving into using Docker from the command line and learn that. Docker complicates networking a little bit because it adds more layers, but understanding Docker is very useful if you’re into self hosting or software development.




  • I’m not a cyber security expert, but I think about it this way:

    First, consider your threat model. What could possibly go wrong? What do I do if the worst thing happens? What information do I need to protect? If everything is already public (like blog posts), maybe there isn’t much of a threat of information loss. If you keep your tax documents on there, maybe rethink that.

    Second: think defense in depth. None of these measures will make you totally safe, but every barrier is another thing that can make a hacker’s life more difficult. You move the ssh port and it’s not as easily found by someone who’s just literally scanning the entire Internet for open ssh ports. It’s trivial to find, sure, but at least you dodged one bullet.

    OK, they found your ssh port. Now they’re gonna start scanning for common username/password combinations. Fail2ban will stop this by blocking access after a few failures. If your credentials have leaked somewhere, the hackers may have a good guess at it though. But you’re OK because you’re using a key pair not your usual password (please don’t have a “usual password”).

    Bad luck: they guessed your password. Or maybe they exploited a bug in your web server software (must have been a zero-day because you kept things up to date). Their exploit needs to open a server port for them to talk to, though. You blocked it on your firewall so that didn’t work. They try a reverse shell, but you blocked outgoing connections, too. Well done.

    And on it goes.

    If they keep trying, they will eventually succeed, but they have to try a lot harder when you lock things down, and the longer they are at it, the more opportunity you have to notice.