They finally added the last bit of data to this Session store that broke the whole application. 16MB of data being read/written from store on every http request. 50% of all http request processing was handling the Session middleware.
I hate developers who don’t spend the very minimum to understand the environment they work in.
When connected to your internal network, what is the results of:
nslookup sub.domain.tld AGH.IP.Address
This should respond authoritative with the IP you need to access NPM’s VIP IP address. If that is not the case, let us see your AGH configuration for your sub.domain.tld.
If that does return the correct IP, verify that it responds to https using curl on Linux or windows (replace curl with curl.exe)
curl -vvvI https://sub.domain.tld/
If this is not connecting or showing a cert error then there’s a misconfiguration on the NPM side. Screenshots of your site configuration for one of the sites would be helpful. The domain name should match sub.domain.tld (not your duckdns) and be bound to the let’s encrypt cert.
Instead of a default gateway you can configure just your VPN IP address to go to your gateway. You might also need DNS servers depending on your setup.
Example: ip route add 1.1.1.1/32 via 192.168.1.1 dev eth0
Note that without a script this may be flaky if you’re using DNS to resolve the VPN. It might be better to have a script that resolves the IP(s) of the VPN and then adds routes.
That being said, your VPN software is usually designed to install routes that have higher priority so that they will get used before the local network. One such way is by adding half-internet routes (0.0.0.0/1 and 128.0.0.0/1) which get preferred over the larger default route. If you run ip route once connected you may see those routes present.
While I’m not sure if it works in rootless, take a look at binhex/arch-delugevpn project which has scripts to set up a similar network isolation environment.
Clearly the Linux user just broke their prompt by updating. Classic.
I think NetworkChuck has a good set of tutorial videos about self hosting. For the most part you can search for what you want to find info on and he probably had a video on it. E.g. Nginx: https://m.youtube.com/@NetworkChuck/search?query=Nginx
I do a lot of Architecting for my company and it’s often easier to have direct access to DNS to make quick changes rather than wait one or more days for an engineer to go change records. If this is just going to be a test environment perhaps you could delegate a subdomain of your current domain. E.g. Add NS records for test.example.com that point to the NS of the contractors hosted zone. This gives you control to tear it down (delete the NS records) but allows the contractor the ability to build the environment out.
+1 for Backblaze. They have a convenient backup software too that works great. I backup my parents laptop using it, and use their S3 storage for my NAS backups.
This would depend on whether the limit is defined as ingress or egress or both. For example AWS has free ingress traffic from the internet but there is a cost for egress traffic to the internet.
A better solution would be to find a unmetered service, which means that you have a fixed transfer speed (e.g. 500 Mbit) but have unlimited bandwidth. OVH offers this in their VPS products.
Since Stargate is my go-to scifi I’m kinda offended at the “doesn’t take itself too seriously”. Sure it’s not as hard on the science as The Expanse (you know, except for the magic portals to other stars), but it feels like it takes itself pretty seriously. There are obvious bottle episodes that were probably written for other shows and shoe-horned in because they were cheap to buy and produce.
For #2, I think this would get pretty old pretty fast, not to mention that they have to fit everything into runtime constraints. Every new planet the team spends months researching the new language. Sure, you could handwave it (we found a Goa’uld translator just laying around), but that would be back to just one language. Since the Stargate presents an instant transportation rather than the days/months/years of starship travel it would make sense that languages stay fairly consistent as people move from planet to planet.
For #3, they pretty much handwave this in SG-1 as the majority of planets in the Milky Way were repopulated by the ancients in their image, and others were transferred from Earth.
Sadly, most of the ones I’ve found are too complicated, and getting all devices to accept the CA is more hassle than it’s worth for self hosting. I’ve given up and just buy my wildcard cert for 60$/yr and just put it on everything.
Here’s a snapshot of the memory of a running live cd of Ubuntu. I ran a script to load 0123456789abcdef over and over and it’s clearly readable. Nothing special is required for this, as the Hypervisor has access to anything that the VM does. If the VM loads the encryption key for your disk into memory it will be available to the provider.
Dunno what rock you were hiding under but this is absolutely possible in a hosted environment. There’s even ESXi documentation on how to do it. Taking a snapshot can be detected, but can’t be prevented. These memory dumps can include encryption keys, private keys (such as SSL certificates) and other sensitive data.
Unless you can physically touch the drive with your data on it, I would not store any sensitive data on it, encrypted or not.
The DNS-01 challenge can be used to generate a wildcard by creating the requested dns record in your public dns zone, then you can use that cert for internal servers/dns. With certain dns providers it can even be automated.
https://eff-certbot.readthedocs.io/en/stable/using.html#third-party-plugins
While this is a great writeup on Lemmy instances, the thread was specifically about Mastodon and it’s numerous forks. I believe they use the same tech but are vastly different things. The instance I found wasn’t quite Mastodon apparently, even though it works very similar and the app designed to connect to a Mastodon instance wouldn’t connect to it.
I’ve been looking for a new instance to join due to various reasons. Ended up setting up and account somewhere and spending 2 hours manually copying over various settings only to find my Moshidon client won’t even connect with that new instance. Normal people are just going to quit when that happens.
You mentioned ping. If you’re using Termux you may need to manually update its DNS settings (different from the system DNS). The file is /data/data/com.termux/files/usr/etc/resolv.conf
To make it roam you probably want your home dns first then some internet resolvers after that.
In the US they are usually governed as real estate legally. You can resell it, but most people aren’t interested in paying the maintenance fees. You’ll find all sorts of timeshares out there being resold for 1$ because they just don’t want to pay the maintenance fee anymore.
The -k argument on my openssl accepts a passphrase, not a file. You likely encrypted with the filename as the secret, not it’s contents. Perhaps you should use -kfile instead.
$ openssl aes-256-cbc -help
Usage: aes-256-cbc [options]
General options:
-help Display this summary
-list List ciphers
-ciphers Alias for -list
-e Encrypt
-d Decrypt
-p Print the iv/key
-P Print the iv/key and exit
-engine val Use engine, possibly a hardware device
Input options:
-in infile Input file
** -k val Passphrase**
-kfile infile Read passphrase from file
In days past some drive vendors had different sector layouts for drives and would cause issues with raid. Pretty sure most nowadays are all the same layout and you won’t run into any issues. I still look to get the same drive model anyways just to be perfectly sure that there are no issues.
Even then you may run into weird issues like one of my 1.2 TB enterprise ssd drives was reporting 1.12 TiB rather than 1.09 TiB the other 7 drives had. TrueNas refused to build a vdev with that drive and I had to return it to get a new one.
If I had to guess, the container station might be giving the docker container a new network/ip address, one that the NAS is not using so that port 443 works and doesn’t conflict with the NAS. If you start the container station then inspect the container you might see how they do it, but macvlan is typically how you would configure it.
services: my-lan-service: image: nginx:latest container_name: lan_container # 1. Attach the service to the custom macvlan network networks: lan_network: ipv4_address: 192.168.1.200 # The dedicated LAN IP for this container # 2. Ports are exposed directly to the LAN; do NOT use the "ports" block restart: unless-stopped networks: lan_network: driver: macvlan driver_opts: parent: eth0 # Change to your host's physical network interface name ipam: config: - subnet: 192.168.1.0/24 # Matches your physical local network setup gateway: 192.168.1.1 # Your physical router IP