darkan15

u/darkan15@lemmy.world
0 posts · 104 comments

Recent posts

No posts.

Recent comments

If you go with dual booting this is what worked for me when I have done dual boot, so windows doesn't mess with boot options:

  1. Window have to be installed first or already there.
  2. With a Live ISO use a tool like gparted and shrink windows main partition from the right.
  3. During installation, choose custom partitioning to manage the free space
  • Make a secondary /boot/efi partition so linux boot is installed there.
  • Make the / root partition for linux and optional make a partition for /home.
  • Finish the installation.
  1. Boot into UEFI and change boot order to that secondary /boot/efi.
  2. Reboot and profit.

That way grub will be running from the secondary /boot/efi, and it will detect and add windows and the primary /boot/efi

Windows only sees and care about the first /boot/efi and will only mess with that, so even if it does change something it doesn't matter.

As far as I know, Dockge, Portainer, Coolify, etc. can have different stacks folders, and they will not show, warn you or not let you manage stacks outside their designated paths.

For your main question, it is possible to build your image on the same system, you would need at least terminal access to do so, and then use the local image with docker compose or Dockge or other, you just would need to reference its image name instead of a URL (to differentiate images I build I prefix their name with local as 'local/service-name'), and it would not pull from anywhere but use the one you already built, you could do it on any folder on the system or inside the stacks folder you have with Dockge

If you do it on Dockge's stack folder, create a folder for your service, with a docker-compose.yml file inside (with just this it will appear in Dockge), then pull the repository on this folder, and make sure you have the proper Dockerfile to build the image, you can then either build the image first or reference the Dockerfile on your docker-compose.yml. This way when you do docker compose up or in Dockge you press the Start button, it will build the image with the Dockerfile and use it, if it doesn't find the image.

The other option I know is to have a local image registry (I have done this with Forgejo), so pull the repository on any folder on your system, build it and push it to your local registry, and then just use the local registry URL on your docker-compose-yml

then the easier method is to install Caddy as docker and use the containername:containerport method?... did I understand correctly?

Yes, if the only exposed port to the host or outside, is 443 from caddy container, then the only way to access any of those services is HTTPS through caddy.

on Help? Caddy reverse proxy · c/selfhosted · 19 pts · 275d

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.

on Jellyfin 10.11.0 Released · c/selfhosted · 50 pts · 288d

A friendly reminder that it is best to wait a bit before updating, in case there are any bugs still there, happened a few days ago with Forgejo, that a mayor bug was detected after initial release of v13.0

You could use aliases on your .bashrc for git (and a bare repo), that would let you manage your $HOME and /etc directly with git without using symlinks, only downside is having them separated in two aliases and two repos.

# user config repo
alias dotfiles='git --git-dir=$HOME/.dotfiles --work-tree=$HOME'

# system config repo
alias etcfiles='sudo git --git-dir=$HOME/.etcfiles --work-tree=/etc'

It is also recommended that you run:

<alias> config --local status.showUntrackedFiles no

in the terminal for both the dotfiles and etcfiles aliases (you can pick the aliases and git-dir names you want)

The aliases help you have a custom named folder instead of .git located in a custom path, and you can manage them without symlinks as you use git directly on the file's original location, this would solve your issue of other solutions that depend on symlinks

Note: you could technically have the root directory --work-tree=/ as a work tree to use only one command, but It is not recommended to give git the possibility to rewrite any file on the entire file system.

Some reference links:

Text

Video

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

You don't need to backup all your 24TB of data, you can have a copy of a subset of your important data on another device, if possible the best would be a 3-2-1 approach.

"RAID is not a backup", is something that is mentioned a lot, as you can still lose data on a RAID setup.

On your first part, clarifying your intent, I think that you are overcomplicating yourself by expecting traffic to come to the server via domain name (pass through proxy) from Router A network and by IP:Port from Router B network, you can access all, from anywhere through domains and subdomains, and avoid using numbers.

If you can't set up a DNS directly on Router A, you can set it per device you would want to access the server through port forwarding of Router B, meaning setting the laptop to use itself as primary DNS and as secondary use external, and any other device you would want in that LAN do the same (laptop as primary), It is a bit tedious to do per device instead but still possible.

Wouldn't this link to the 192.168.0.y address of router B pass through router A, and loop back to router B, routing through the slower cable? Or is the router smart enough to realize he's just talking to itself and just cut out `router A from the traffic?

No, the request would stop on Router B, and maintain all traffic, on the 10.0.0.* network it would not change subnets, or anything.

In other words any device on 10.0.0.* will do a DNS request, ask the Router where the DNS server is, then the DNS query itself is sent directly to the server on port 53, then when the response of the DNS is received, via domain, query the server again, but on port 80|443, and then receiving the HTTP/HTTPS response.

Remember that all my advice so far is so you don't use any IP or Port anywhere, and your experience is seamless on any device using domains, and subdomains, the only place where you would need to put IP or ports, is on the reverse proxy itself, to tell anything reaching it, where the specific app/service is, as those would need to be running on different ports but be reached through the reverse proxy on defaults 80 or 443, so that you don't have to put numbers anywhere.

If you decide on doing the secondary local DNS on the server on Router B network, there is no need to loop back, as that DNS will maintain domain lookup and the requests on 10.0.0.x all internal to Router B network.

On Router B then you would have as primary DNS the Server IP, and as secondary an external one like Cloudflare or Google.

You can still decide to put rules on the reverse proxy if the origin IP is from 192.168.0.* or 10.0.0.* if you see the need to differentiate traffic, but I think that is not necessary.