Canadian here, could you share the name of the provider? I'd love to move to something more local and just need a basic small vps for a simple apache host. I know of a couple providers but never talked to anyone actually using one.
Last year, I moved from DigitalOcean to FullHost (their Vancouver datacentre) for hosting a small SaaS and a bunch of personal projects. It's cheaper and FAR better performance.
It was ServaRICA as someone else suggested. It was a Black Friday hybrid VPS deal from a few years ago, looks like they still have comparable stuff on their site. For the cost I would generally assume anything important needs to be duplicated in case the company folds or a fire unless you pay them for such a service. (I don't have any vested interest in suggesting them.)
Thanks! Nothing important, personal site with the source stored in a git repo replicated to a few places, so them folding would just be a minor inconvenience.
As a child I loved watching construction sites! I'd literally plop myself on the group and couldn't be moved until I was done. This would be ideal retirement for me. Though as I am a house spouse, I won't really get a retirement, gotta keep cooking meals, doing laundry, dishes and cleaning. At least I'll have no deathbed regrets about not spending enough time with my daughter though!
I do this but for music with Home Assistant. I haven't dug around much to see if it's possible to cast video from Jellyfin the same way. From what I read (and it's been a while) the Jellyfin API was more limited, but maybe that's changed by now.
Right, you don't just "good person" yourself into billions of dollars. There will always be a trail of people screwed over, or taken advantage of along the way. Or you can go the more modern way and externalize all the negative impacts of your business (e.g. scooter rental companies).
OEM licenses are for the computer, not the motherboard. The online activation historically hasn't worked if you change motherboard, but the phone line folks would always activate it for you if you explained that it was the same computer with a different motherboard.
i bought a builder license from newegg in 2017. unfortunately i was not diligent about saving the product key. this was actually the third time i had been in this scenario after changing hardware. no idea why it wouldn’t work this time around.
Without nat, my understanding is the right way in v6 is to issue addresses of every network and then send a message to each end device asking it to use a specific ip address to route traffic and hope every client implements RFC 4191 in the right way.
The "proper" way would be to get your own ASN and use BGP to route the traffic.
If you're wanting to use a secondary WAN link as a backup for when the other goes down you could have the backup link's LAN have a lower priority. (So I guess hope everything implements RFC 4191 like you said).
You can use NAT66/NPTv6 if you want (though it's icky I guess).
Nat 4, it’s trivial. But IPv6 tell me how terrible nat is despite it being the only solution in both the v6 and v4 world.
Sadly my 4g provider will not peer via bgp with me, even if I could provide an AS and Sufficiently large IP range.
I think my home ISP will actually peer with me, but I’d have to tunnel to them over my non-fibre connection, and there’s reduced resilience in that case.
At work that wouldn’t help at all, there are very few providers for many of our branch offices.
So once again ipv6 only works with “icky” nat, or on simple 1990s style connections, and not in the real world of multiple providers. Now sure I can do npt which means I don’t need to keep track of state, but then if I didn’t keep track of state I lose the benefits of a stateful firewall.
As such the only benefits of nat on v6 is that source ports will never need to change even if client 1 and client 2 both send to server 1 port 1234 from source port 5555. This helps with a handful of crappy protocols which embed the layer 4 data (port number) in a layer 6 or 7 protocol.
The amount of ignorance in these ipv6 posts is astounding (seems to be one every two months). It isn't hard at all, I'm just a homelabber and I have a dual-stack setup for WAN access (HE Tunnel is set up on the router since Bell [my isp] still doesn't give ipv6 address/prefixes to non-mobile users), but my OpenStack and ceph clusters are all ipv6 only, it's easy peasy. Plus subnetting is a heck of a lot less annoying that with ipv4, not that that was difficult either.
“it’s easy peasy” says guy who demonstrably already knows and has time to learn a bunch of shit 99.9% of people don’t have the background or inclination to.
People like you talking about IPv6 have the same vibe as someone bewildered by the fact that 99.9% of people can’t explain even the most basic equation of differential or integral calculus. That bewilderment is ignorance.
"The shit about IPv4" was easy to learn and well documented and supported.
"The shit about IPv6" is a mess of approaches that even the biggest fanboys can't agree on and are even less available on equipment used by people in prod.
IPv6 has failed wide adoption in 30 decades, calling it "easy" is outright denying the reality and shows the utter dumb obliviousness of people trying to push it and failing to realize where the issues are.
Could you share a list of IPv6 issues that IPv4 does not exhibit? Something that becomes materially harder with IPv6? E.g., "IPv6 addresses are long and unwieldy, hard to write down or remember". What else?
Traffic shapping in v6 is harder than v4. At least it was for me, because NDP messages were going into the shaping queue, but then getting lost since the queue only had a 128 bit address field, and 128 bits isn't actually enough for local addresses. When the traffic shaping allowed traffic immediately, the NDP traffic would be sent, but if it needed to be queued, the adapter index would get lost (or something) and the packets disappeared. So I'd get little bursts of v6 until NDP entries timed out and small queues meant a long time before it would work again.
Not an issue in ipv4 because ARP isn't IPv4 so IP traffic shaping ignores it automatically.
Software support is a big one. I ran pfSense. It did not support changing IPv6 prefixes. It still barely does. So something as simple has having reliable IPv6 connectivity and firewall rules with pfSense was impossible just a few years ago for me.
Android doesn't support DHCPv6 so I can't tell it my preferred NTP server, and Android silently ignores your local DNS server if it is advertised with a IPv4 address and the Android device got a IPv6 address.
Without DHCPv6 then dynamic DNS is required for all servers. Even a 56 bit prefix is too much to remember, especially when it changes every week. So then you need to install and configure a dynamic DNS client on all servers in your network.
"I already know enough to be productive, can the rest of the world please freeze and stop changing?"
This is not even that unreasonable. Sadly, the number of IP devices in the world by now far exceeds the IPv4 address space, and other folks want to do something about that. They hope the world won't freeze but would sort of progress.
Network engineering is a profession requiring specific education. At a high level it’s not different from calculus. You learn certain things and then you learn how to apply them in the real life situations.
It’s not hard for people who get an appropriate education and put some effort into it. Your lack of education is not my ignorance.
company where i work has deployments across the world with few hundreds of thousands of hardware hosts (in datacenters), vms and containers + deployments in a few clouds. also a bunch of random hardware from multitude of vendors. multiple lines for linking datacenters and clouds. also some lines to more specific service providers that we are using.
all of it ipv4 based. ipv6 maybe in distant future somewhere on the edge in case our clients will demand in.
I find this completely fine. I don't see much (if any) upside in migrating a large existing network to anything new at all, as long as the currently deployed IPv4 is an adequate solution inside it (and it obviously is).
Public-interfacing parts can (and should) support IPv6, but I don't see much trouble exposing your public HTTP servers (and maybe mail servers) using IPv6, because most likely your hosting / cloud providers do 99.9% of it already, out of the box (unless it's AWS, haha), and the rare remaining cases, like, I don't know, a custom VPN gateway, are not such a big deal to handle.
I ran network team at an organization with hundreds of thousands hardware hosts in tens-of-megawatts large data centers, millions of VMs and containers, links between data centers, links to ISPs and IXes. We ran out of RFC1918 addresses at around 2011-2012 and went IPv6-only. IPv4 is delivered as a service to nodes requiring it via an overlay network. We intentionally simplified network design by doing so.
I should have been gentler and less arrogant, yes. Sincerely though, please explain how ipv6 is in anyway more difficult than a properly set up ipv4 enterprise. What tools are not available?
I left my job as a NE/architect over a 15 years ago, but the show stopper back then revolved around how to handle routing with firewalling. Firewalling being biggest roadblock due to needing traffic symmetry. I'm doing my best to remember why we stopped at just providing v6 at the edge for site-specific Internet hosted services and never pushed it further.
Mind you, our team discussed this numerous times over a few years and never came up with a solution that didn't look like it would require us to completely fork-lift what we were doing. The whole team was FOR getting us to v6, so there was no dogmatic opposition.
Consider this:
25k employee company. Four main datacenter hubs spread out across the USA with 200 remote offices evenly dual-homed into any two of the four.
All four of the DCs had multi-ISP Internet access advertising their separate v4 blocks and hosting Internet services. The default-route was redistributed into the IGP from only two locations, site A and B. e.g. two of the four DCs were egress for Internet traffic from the population of users and all non-internet-facing servers. IGP metrics were gently massaged as to fairly equally use of both sites.
All outbound traffic flowed naturally out of the eastern or western sites based on IGP metrics. This afforded us a tertiary failover for outbound traffic in the event that both of the Internet links into one of the two egress sites was down. e.g., if both of site A's links (say, level-3 and att) were down, the route through site A was lost, and all the egress traffic was then routed out site B (and vice-versa). This worked well with ipv4 because we used NAT to masquerade all the internal v4 space as site X's public egress block. Therefore all the return traffic was routed appropriately.
BGP advertisements were either as-path prepended or supernetted (don't remember which) such that if site A went down, site B, C, or D would get its traffic, and tunnel it via GRE to the appropriate DC hub's external segment.
The difficulty was that traffic absolutely had to flow symmetrically because of the firewalls in place, and easily could for v4 because NAT was happening at every edge.
With v6 it just didn't seem like there was any way to achieve the same routing architecture / flexibility, particularly with multi-homing into geographically disparate sites.
I'm not sure anymore where we landed, but I remember it being effectively insurmountable. I don't think it was difficult for Internet-hosted services, but the effort seemed absolutely not worth it for everything on the inside of the network.
reply