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

help-circle




  • darkan15@lemmy.worldtoSelfhosted@lemmy.worldHelp? Caddy reverse proxy
    link
    fedilink
    English
    arrow-up
    9
    ·
    edit-2
    3 months ago

    I’ve installed caddy directly on my unbuntu server, but I admin my Jellyfin (and eventually Nextcloud) with Docker via CasaOS interface… is this a problem? Do I need to run Caddy in docker too?

    The difference between having caddy or any other reverse proxy in docker alongside other apps/services, is that instead of having to expose ports for every container to the host, and then linking every service/app as, localhost:<host-port> to caddy, you can have them on the same docker network and use <container-name>:<container-port> and only expose 80 443 to the host, meaning that the only way to access app/services is through caddy, that way if you disable port 80 after configuring SSL certificates, you can only access services with HTTPS.


  • The TL, DR version of sharing with No License, is that technically speaking you are not explicitly permitting others to use your code in any way, just allowing them to look, a license is a formal way to give permissions to others to copy, modify, or use your code.

    You don’t need an extra file for the license, you can embed it on a section at the top of your file, as you did with the description, just add a # License section at the very top, if you want the most permissive one you can just use MIT, just need to replace the year of publication of the code, and you can use a pseudonym/username like ‘hereforawhile@lemmy.ml’ if you don’t want to use something like email, username on another site or real name, that can be used to identify you, if that’s a concern



  • The simplest (really the simplest) would be to do a git init --bare in a directory on one machine, and that way you can clone, push or pull from it, with the directory path as URL from the same machine and using ssh from the other (you could do this bare repo inside a container but really would be complicating it), you would have to init a new bare repo per project in a new directory.

    If a self-hosted server meaning something with a web UI to handle multiple repositories with pull requests, issues, etc. like your own local Github/Gitlab. The answer is forgejo (this link has the instructions to deploy with docker), and if you want to see how that looks like there is an online public instance called codeberg where the forgejo code is hosted, alongside other projects.


  • As others have already commented, what you need is a Dynamic DNS service, where you register a subdomain, and setup a small program or script on your computer that pings the DDNS server every few minutes, that way you leave that running on the background, and if the program detects that the IP with the request changes, it will update the subdomain to point to it automatically.

    You could access the blog from the subdomain of the DDNS directly or if you get your own domain, you can point it to the DDNS.

    If you want a recommendation, I have been using DuckDNS for years, and it has been pretty reliable.




  • Yeah, these are pretty solid advice, would say that you should be safe with patch version updates, like from 1.17.1 to 1.17.4

    Should be able to jump from 1.17.4 to 2.0.1 and from 2.0.1 to 2.1.3, etc. going straight to the last patch of the next version, but should go one by one minor version, paying close attention to those versions that have breaking changes in the release notes. And always backup and test before each version jump.


  • This probably is the issue, when you download a script or binary from the internet it doesn’t have execution permission, you would have to right click on folder to open in terminal (that way don’t have to cd to it), and check permissions with ls -la if it doesn’t have permission, change it with chmod


  • As far as I know, CasaOS (same as Cockpit) is installed on top of a default OS install, so you could always access the OS directly to install/configure things outside of it, if the need arises.

    I would not say you would be held back by it, if it does what you need. And for what I can see online, you can install any docker container even if it’s not on the default catalog of CasaOS, or access the OS.

    If you want to grow your knowledge of how things work, or how to deploy services without CasaOS, you can always do so in parallel of using CasaOS, so I don’t see where the issue could be.


  • I’m going to mention Ansible as I haven’t seen it mentioned, and it can be used to locally manage a reproducible build.

    It has already been mentioned, but as a minimum to replicate your system you need two things:

    • Transfer/copy your entire /home directory as there is where the majority of the configuration files of your system pertaining the software you use (there could be configs you could need on /etc and on /usr/local or other dir), that is why it is recommended to partition your disk on installation of your distro, so the /home directory is already separated, as if you reinstall in the same machine you don’t lose any configuration in addition to your personal documents/pictures/etc
    • Have a way to automatically install a list of programs/apps/drivers/libraries, and that is what something like a bash script, Ansible, nixOs, etc. could help you with.

    The truth is that using any of the tools in the second point requires learning a bunch, so if your skill level is still not there, there is some work to do to get there.