Cat: Wow this snow is cold! Ahhhh, this is SO COLD!!!
It does have that slightly preoccupied look that suggests it wishes it had more insulation in certain areas, but it's determined to pose for the photo anyway.
It might already be packaged for whichever OS you're running, and it comes with a utility to do the conversion. On Debian or Ubuntu it should be as simple as installing the pst-utils package and running something like readpst <path to .pst file> and it'll leave an mbox file for you. It's been a fair few years since I used it, so reading the documentation would probably be wise, but I remember it being pretty straightforward.
I don't have a Redhat machine handy right now, but it looks like the package is called libpst there. On a Mac you'd need to follow the build instructions in the git repository, but it's not python, the main library and utils are written in C. The tarball they refer to it just a tar of the source, that you can download form the releases page. I can't help you if your running windows, I don't have a machine running it, and haven't used it in many years.
You... you don't? Surely there's some mistake, have you checked down the back of your cupboard? Sometimes they fall down there. Where else do you keep your internet?
Appologies, I'm tired and that made more sense in my head.
I've used libpst to be this in the past. On Debian it's packaged as pst-utils. The readpst util will convert your PST to a variety of formats including MBOX.
Before you can decide on how to do this, you're going to have to make a few choices:
Authentication and Access
Theres two main ways to expose a git repo, HTTPS or SSH, and they both have pros and cons here:
HTTPS
A standard sort of protocol to proxy, but you'll need to make sure you set up authentication on the proxy properly so that only only thise who should have access can get it. The git client will need to store a username and password to talk to the server or you'll have to enter them on every request. gitweb is a CGI that provides a basic, but useful, web interface.
SSH
Simpler to set up, and authentication is a solved problem. Proxying it isn't hard, just forward the port to any of the backend servers, which avoids decrypting on the proxy. You will want to use the same hostkey on all the servers though, or SSH will refuse to connect. Doesn't require any special setup.
Replication
Git is a distributed version control system, so you could replicate it at that level, alternatively you could use a replicated file system, or a simple file based replication. Each has it's own trade-offs.
Git replication
Using git pull to replicate between repositories is probably going to be your most reliable option, as it's the job git was built for, and doesn't rely on messing with it's underlying files directly. The one caveat is that, if you push to different servers in quick suscession you may cause a merge confict, which would break your replication. The cleanest way to deal with that is to have the load balancer send all requests to server1 if it's up, and only switch to the next server if all the prior ones are down. That way writes will alk be going to the same place. Then set up replication in loop, with server2 pulling from server1, server3 pulling from server2, and so on up to server1 pulling from server5. With frequent pulls changes that are commited to server1 will quickly replicate to all the other servers. This would effectively be a shared nothing solution as none of the servers are sharing resources, which would make it easier to geigraphically separate them. The load balancer could be replaced by a CNAME record in DNS, with a daemon that updates it to point to the correct server.
Replicated filesystem
Git stores its data in a fairly simple file structure, so placing that on a replicated filesystem such as GlusterFS or Ceph would mean multiple servers could use the same data. From experience, this sort of thing is great when it's working, but can be fragile and break in unexpected ways. You don't want to be up at 2am trying to fix a file replication issue if you can avoid it.
File replication.
This is similar to the git replication option, in that you have to be very aware of the risk of conflicts. A similar strategy would probably work, but I'm not sure it brings you any advantages.
I think my prefered solution would be to have SSH access to the git servers and to set up pull based replication on a fairly fast schedule (where fast is relative to how frequently you push changes). You mention having a VPS as obe of the servers, so you might want to push changes to that rather than have be able to connect to your internal network.
A useful property of git is that, if the server is missing changesets you can just push them again. So if a server goes down before your last push gets replicated, you can just push again once the system has switched to the new server. Once the first server comes back online it'll naturally get any changesets it's missing and effectively 'heal'.
Parks are great, but unless they're directly outside the houses where I can keep an eye on what's happening they're not as safe or convenient. Being able to send the kids into the garden to run off some energy whilst I'm in the house doing something, and being reasonably confident that they're safe is a huge benefit.
That's certainly not impossible with a bit of sensible planning around how housing is laid out, putting clusters of housing directly around a shared green space, but it is rather challenging to retrofit in existing conurbations, and impossible in more spread out communities. The American style of huge featureless lawns surrounding the house right up to the property boundary are pretty awful, but the more European style of a bit of lawn surrounded by flower beds and maybe trees is rather better.
If you have kids It's helpful to have an open, flat area for them to run around on. It doesn't need to be (just) grass, but that's probably the most robust, and least likely to have sharp surprises, option.
We didn't steal the balls, but where computers were back to back we'd swap the mice over. Cue much confusion for the next class when the pointer seemed to move on it's own. Fun times.
Here's a crazy thought: stop driving whilst under the influence of alcohol, or any other intoxicant for that matter. People who do that are a danger to themselves and everyone around them, and need removing from the road as swiftly as possible.
It's not exactly what you're talking about, but it looks like there is a way to do this over PCIe 5.0: CXL 1.1. The m.2 bus exposes up to 4 PCIe lanes, so it may be possible, with the right combination of motherboard that supports CXL, and a CXL module with an m.2 interface, to do what you want. I haven't dug much deeper than that, but maybe it'll be of some help.
Modem noises intensify.