When I set up this new server, one of the things I really wanted to have was a way to make sure that everything was regularly backed up in the event of some system issue, a hardware failure, something I broke accidentally, etc. My old Mac based system used an excellent tool called Carbon Copy Cloner which would make a bootable backup copy on a scheduled basis.
A NAT Firewall is needed in many situations to allow a private network to communicate with the larger world, the most common example of this would be a home WiFi router that provides a private network space and then links to a WAN connection provided by an ISP.
I was recently setting up such a system at work to allow systems on a private network to be able to communicate with the internet for software updates, etc. There is a lot of info out there to set this up, many older guides focus on iptables rules, but I wanted something that used the newer firewall-cmd software. After some googling and piecing together some things, I came up with the following script.
I was recently working on a Linux system that was providing a NAT service for an environment. Initially, everything seemed to be working fine, but after some additional testing problems were discovered...
What was happening was that network traffic was coming into one interface, but this interface didn't have a route back to the source system, and so the reply traffic needed to go out the default network interface, as expected. The problem (feature!) though is that newer Linux versions have a feature called Strict Reverse Path Forwarding, which checks to be sure that the interface receiving traffic is able to also able respond to this traffic. For a local subnet, this is usually fine, but for traffic outside of the local subnet, this requires routing, quite possibly by another network interface. And with the Strict Reverse Path Forwarding enabled, if traffic needs to bounce to another interface, then the packet gets dropped. For more info on this, see this link: https://access.redhat.com/solutions/53031
After taking a few years off with nothing much to blog about, I've decided to jump back into this, mainly as a place to keep some notes on things I'm working on, which, among other things, includes the email/web server I run at home that hosts this site.
Gone is the old Mac Mini that served up this site the last 10+ years, and long gone the PowerMac G4 that originally ran the site. The current site at the time of this writing is running on a Dell OptiPlex 7050 Micro Form Factor with Rocky Linux 8.6, soon to be 9.0.
This looks to be my final wrapup on the iPod Shuffle RAID article I wrote a few weeks back that drew so much attention. Included are some final notes on installing OS X to a Shuffle, USB hub observations, and some USB 2.0 PCI card notes.
First, some comments on USB hubs. I received several questions from readers on why certain USB hubs were rejected, As several reviews of the iPod Shuffle have noted, the total width of the Shuffle is a tad larger than the average USB cable connector, consequently it has a tendency to block adjacent ports which are mounted side by side horizontally. Ports mounted vertically present less of an issue as the height of the Shuffle isn't significantly greater than a standard USB connector plug.
So, what do you do when you and some friends are all getting iPod Shuffles? You make a RAID array out of them, of course! Follow along as we explore new depths of geekery...
Special thanks to Justin, Melissa, and Shanea for the use of their iPod Shuffles. ;)
So, here we have our iPod Shuffles, all the top of the line 1Gb models. I'm sure that normal folks would probably take these home, install iTunes 4.7.1 from the CD in the box, and happily start putting music on the little things, but I had other plans for them...