The projected income shown in the annual Your Social Security Statement assumes that the money being promised will also be available to be paid from the balance of the Social Security Trust Fund. Problem is, it looks clear that there will be challenges maintaining the balance in that fund in the coming years.

The main drivers affecting social security during our planned retirement years are:

• Boomers retiring + longer lifespans. Results in more people collecting benefits for more years.
• Lower birth rates in the post-boomer decades. Results in fewer payroll-tax payers supporting the retired population.

The Social Security Administration releases occasional projections of the trust fund balance. Based on the 2024 Social Security and Medicare Boards of Trustees Statement, the retirement fund (OASI) will run out of money in 2033 (the combined trust funds – OASDI lasts till 2034). Once the fund is exhausted, benefit payments become limited to current payroll taxes, which are projected to be 79% of scheduled benefits. Even more significant cuts are on the table in subsequent years without action.

What’s the trend on trust fund projections? Well, the 2033 exhaustion moves the year from a previous prediction of 2036 made in 2021. That sounds alarming. But this at least doesn’t appear to be something that will continue. There was lower-than-expected payroll tax revenue post-COVID, and labor force partipation didn’t rebound quickly, and many people retired early. There were also higher COLAs with the sudden spike in inflation (which rachets up benefits permanently). Finally there was also a decrease in life expectancy post-COVID and that shaped forecasts, but the real effect has been temporary so people are actually collecting benefits for longer.

So are cuts of the magnitude indicated by trust fund balances invevitable? No. That’s what will happen with no action by congress. Will congress act? Yes. It’s virtually inevitable. Allowing cuts of this size to current and near-term retiree benefits will be unthinkable politically. Will congress eliminate the cuts altogether? No. The funding challenge and its impact to the rest of the population is what they’ll be up against, and it’s big.

So what might congress do other than cut benefits?

• Increase payroll taxes, currently at 12.4% (6.2 employee, 6.2 employer). A 1% increase (0.5 on each side) would bring in a lot of money. The longer this doesn’t happen, the more dramatic the fix needs to be as opposed to taxes phased in over several years.
• Raise or eliminate the taxable wage cap. Right now contributions cap at a $176K income level. Congress might change this by raising that cap, or by reapplying FICA to earnings above $400K (i.e. the “donut hole”) such as that proposed in the Social Security 2100 Act.
• Tax certain non-wage income. Taxes might close self-employment loopholes, tax some fringe benefits, or possibly investment income (politically difficult).
• Raise full retirement age.
• Other, including modify wage indexing, reduce COLA, means testing.

Most likely, what’s done will be a combination of these things, and only a partial job of restoring 100% of benefits. Each of these actions will see political push-back from large numbers of affected individuals. How all that shakes out is uncertain.

To think there will be no cuts appears to be an unwise stragegy.

How big will the cuts be?

That’s the million dollar question. Who knows? Predicting nothing doesn’t make sense. Predicting the full default cuts (at least for current/near-term retirees) is probably overly conservative.

In the table below, the default cuts reflect what current law requires if Congress does nothing. Once the trust fund is depleted around 2033, benefits must be limited to annual payroll tax, producing an immediate cut of roughly 20% that slowly worsens over time as demographic trends continue (these figures are less certain than the trust fund projection but are heading in the right direction). This path assumes zero political intervention, no additional revenue, and no changes to benefit formulas. Cuts on this scale have never occurred when a large, well-understood cliff was visible years in advance.

The predicted cuts, assume Congress behaves as it historically has: acting late but not allowing an abrupt, permanent reduction of the default magnitude for current and near-term retirees. In practice this usually means a combination of measures – raising the taxable wage cap, modest payroll tax increases, and slowing benefit growth for higher earners and future retirees. That should partially restore solvency, but may well not fully return benefits to 100% of scheduled levels. The result is a smaller, temporary shortfall around the depletion date that gradually stabilizes at a lower but politically tolerable level.

To simplify planning it might make sense to assume a permanent cut of about 12% in 2033.

I’m just an individual sharing my thoughts and analysis, not a financial professional. Do your own research or consult a qualified advisor before making financial decisions.

The post Projecting Social Security Benefits appeared first on Walter's Little World.

The post Going to the Hands Off march was mandatory appeared first on Walter's Little World.

There are two main components to this project. One of those (the most critical in my opinion) is to extend the Silver Comet down to the Chattahoochee River. The above image shows the path the trail will take. The other piece is to see the City of Atlanta complete a trail that improves the “bicycle experience” south of the river towards Atlanta.

The reason I emphasize the Cobb extension is just based on my experience trying to ride to the start of the Silver Comet, from downtown Atlanta. Atlanta’s trails get a good start towards the Silver Comet with the recently completed Woodall Rail Trail that enables a nice bicycle ride from downtown, up to Westside Park on offroad trails. From there, bicycle friendly roads (like Gun Club Road, Hollywood Road) make for easy/pleasant riding to Atlanta Road and then across the Chattahoochee. At that point there’s abruptly, no more trails or bicycle lanes. Your only choice is to ride on a busy 4-lane with fast traffic and no buffer next to the road. It’s enough to shut me down – not my idea of fun.

Those last couple miles to the Silver Comet

The south end of the Silver Comet currently ends close to the East-West Connector. This will be extended mainly by paving a previous CSX railroad corridor to facilitate offroad travel down to Church Road. From there, the trail continues as a sidepath to Atlanta Road and down to the Chattahoochee River.

See overview of the extension and more detail on segments

Extending towards the Beltline

Picking up at the Chattahoochee, the City of Atlanta has embraced a project that continues the trail from the river with a new offroad path under Marrieta Blvd to Standing Peachtree Park, and down to Marrietta Road.

The trail from the river to Marietta Blvd is a small part of plans for 100 miles of trails expected to take a couple decades to complete.

When will it be done?

Both the Silver Comet Extension, and connecting the Chattahoochee to downtown are expected to be complete by the end of 2025, hopefully well ahead of the 2026 World Cup. I’ve never been one to put an emphasis on “showing off” for sporting events, but whatever works! I’m reminded of the Summer Olympics in 1996 being a big motivator for many to complete the Stone Mountain Trail nearly 30 years ago. Atlanta had virtually no good bicycle trails before that. What a transformation it’s been since then!

The post Atlanta and Cobb County join forces to extend the Silver Comet to downtown Atlanta appeared first on Walter's Little World.

Railroads were designed to be out of sight, and with minimal interruption to pedestrians and street traffic. Quite a lot of expensive construction and landscaping went into that, more and more as you get into most densely populated areas. Ask yourself while driving through Atlanta and nearby, where do you sit and wait for trains to pass? Not a lot of places I’d imagine. But trains are getting around nonetheless. Freight trains remain an important part of our transportation grid. As population density goes up, trains more often go over dedicated bridges. When it goes up more, the trains in Atlanta usually go under the roads thru tunnels. If you’re looking ahead of you, you don’t even know they’re there. While railroads remain important, their role has certainly declined from it’s heyday in the early to mid-1900s. Economic realities in the changing landscape of transportation technology have resulted in more and more rail lines getting abandoned and left just sitting there.

While that opens a “land of opportunity” for me as a bicyclist riding the repurposed lines, happiness is not the only emotion I’m left with. My family was instrumental in helping build up railroads from the early days, to their rise in both passenger and freight transportation, and ultimately their decline, as trucks, automobiles, air travel, and (as always) water transport dominated. My father, Robert Stovall Jr, was the president of the Columbus and Greenville (C&G) railroad company. His father, Robert Stovall Sr, was the president before him, and his father, Adam Tonquin Stovall founded the C&G. I came along when railroads were in decline. My first employment was at the railroad when I was ten years old. Most of what I remember about that is unloading railcars used to transport damaged groceries (like dented cans of food or bags or flour busted open). The C&G would sell this food to farmers to feed their livestock, and I was there to help load it for them. Ultimately the C&G was sold to Illinois Central in about 1972, as they couldn’t continue given the economic conditions, as small operations like ours got bought up in big mergers.

But today I’m out on my bicycle, and feeling a special kinship with the railroad as I ride the Southside Beltline Trail towards downtown Atlanta. Guthrie’s song rings in my head as I cruise along, rolling past houses, farms, and fields. Riding mile after mile, the landscape and views change constantly. There’s no need to hurry or get out of anybody’s way. The scenery includes riding alongside the backyards of neighborhoods, the backside of factories and other industry, and with a up-close and personal view of city infrastructure like big powerplants and other stuff you’re not meant to see. The advertising you see is not there for you. It’s a show of pride by the small business owners that built that place. In some cases what you see ahead might as well be rural. And all the while, you breeze past big and small roads and interstates as though they’re not even there, increasingly thru long tunnels that seem like they were all constructed just for your enjoyment. They were in fact built at great monetary cost and labor that was expended for a completely different reason of course. There’s something sort perfect about that for me. A chance to be both sad and happy, and with uninterrupted solitude in which to experience that to the fullest.

The post Let’s give some thanks for the railroad appeared first on Walter's Little World.

Running a home lab with public facing services, you run into the problem of Split DNS. Any name, like my home.stovallhut.online webpage, needs to be registered with a public IP address to reach it over the internet. Problem is, if you’re at home then you should be contacting a local address on your network (some routers let you use reflection/hairpinning to get around that but this has its own issues). My OPNsense router makes this pretty easy to manage with its Unbound DNS service and dns overrides.

That all works pretty good but the icing on the cake came when I figured out (with the help of a Great Guide) how to forward queries to my local DNS even when the client software specifically requested a different DNS server. Like if the client sends DNS queries to google’s public DNS at 8.8.8.8, then my router will now STILL handle the request if it can locally without contacting google. And if it does contact a public server, it won’t be google, and it will go out using DNS over TLS so my searches are private (at least to third parties like my ISP).

Amazing device

The post Split DNS done right using opnsense appeared first on Walter's Little World.

I’m not running a github server in my lab, and I’d rather not store this on the public github server even if my account is supposedly secure (anything can be compromised). The configuration is very sensitive, including security certificates, user accounts and passwords, firewall rules and more. I’d prefer to backup the configuration to my Synology NAS via SFTP. But the opnsense Command prompt offers no such selection. Github is it!

Stuck right? No! While it looks like I’m captive to what’s available in the gui, I figured out how to pull this off after a good bit of hunting and educating myself on some internals of opnsense and the FreeBSD OS it runs on top of. One avenue (that is in fact a dead-end) is to make a SSH connection with the opnsense router and setup a cron job using the command line crontab -e. This will appear successful at first, but if you modify ANY cron job settings in the opnsense gui, your cron job will be removed!

There’s actually a way to pretty easily extend the picklist of Commands you see in the opnsense GUI to include a custom job that does exactly what I want. This post describes the steps to do that.

Objectives

The steps I show below will first configure the Synology to accept SFTP connections for the purpose of sending it XML configuration backups from opnsense. We’ll setup a new user on the NAS called opnsense_backup. This user has limited privileges, allowing it only read/write access to a new folder where the backups will be stored. For security, the SFTP login that opnsense executes will authenticate thru SSH keys (password prompts would not work, there’s nobody to type it in). The backup is done by a script that you can install on opnsense and register as a new cron-job type that the opnsense gui recognizes. Finally, in the opnsense gui we’ll setup the cron job to execute the backup with the desired frequency.

Skills you need

To execute the steps in this post you need be just basically familiar with the DSM gui at the NAS, and also the opnsense gui for the router. You need to be able to make a SSH connection to the NAS with admin privileges, and also a SSH connection to the opnsense router with root access. You need just a basic understanding of using vi (no editing of files, just create new ones).

Create NAS backup destination and user account

In DSM at the NAS, go to Control Panel -> Shared Folder and create a new shared folder called opnsense_backup. This folder will collect the XML backup files from opnsense. As shown later, the files are all time-stamped with unique names that identify the date/time of the backup, and we’ll setup file-rotation so backups older than 30 days get deleted. Remember to add this new share to your HyperBackup/other backup software to further protect these files.

At Control Panel -> File Services -> FTP make sure the SFTP service is enabled. At Control Panel -> Users and Groups make sure user homes are enabled, then create a new opnsense_backup user account. Give the user a strong password. For privileges, give this account access to its own home folder, the opnsense_backup share created above, and the SFTP application itself. This will all “limit the damage” should this login ever be compromised.

At a SSH prompt on the NAS, execute the following commands to create a destination for SSH keys.

# Create location to store opnsense_backup user's keys
mkdir /var/services/homes/opnsense_backup/.ssh
touch /var/services/homes/opnsense_backup/.ssh/authorized_keys

Configure opnsense to make secure SFTP connections

At a SSH prompt on opnsense, generate a new SSH key using the keygen command.

# Generate a key
ssh-keygen
# accept default filename /root/.ssh/id_rsa at prompt, supply no passphrase

When keygen runs it will prompt you for a filename to store the key in. I accepted the default of /root/.ssh/id_rsa. Take note of the name and use it below if yours is different. You’ll also be prompted to enter a passphrase. Do NOT do that – just press enter. Passphrases are generally a good idea, but not in this case where the job is automated, with nobody to anwer a passphrase-prompt.

Now enter the following command to copy the generated key to the NAS. You’ll be prompted for a password – supply the password created on the NAS for the opnsense_backup user. Note my use of port 22 below – if your SFTP is configured with a different port then use that. Replace <your-NAS-hostname> with the hostname or IP address of your NAS.

# Copy key to NAS
scp -P 22 /root/.ssh/id_rsa.pub opnsense_backup@<your-NAS-hostname>:/home/

When that command completes, you should find the id_rsa.pub file in the opnsense_backup user’s home folder on the NAS.

Register SSH key at the NAS

We’ve stored the id_rsa.pub on the NAS above, now it needs to be properly registered as a SSH key for this user on the NAS.

In a SSH session on the NAS, login as admin and execute the following commands to append the new key to the authorized_keys file we created earlier. Also, it’s critically important to set the file permissions and ownership (chmod/chown below). SFTP will NOT accept the connection if you don’t do this!

# Save the key into authorized_keys file then remove and set permissions
cat /volume1/homes/opnsense_backup/id_rsa.pub >> /volume1/homes/opnsense_backup/.ssh/authorized_keys
rm /volume1/homes/opnsense_backup/id_rsa.pub
chmod 700 /volume1/homes/opnsense_backup/.ssh
chmod 600 /volume1/homes/opnsense_backup/.ssh/authorized_keys
chown -R opnsense_backup:users /volume1/homes/opnsense_backup/.ssh

Note that similar steps are shown in the Synology knowledge-base article for managing SSH keys where you just use File Station and no SSH work like I have above. The problem is the documented steps only work for SFTP logins by a admin user! Do what I show above for preparing .ssh and authorized_keys, and it will work for any user.

Test doing the backup

At a SSH prompt in opnsense, store the following script into a backup_opnsense.sh file. The location of the script is not important yet – just put it in your user home.

#!/bin/sh
DATE=$(date +%Y-%m-%d-%H%M)
BACKUP_FILE="/root/config-backup-$DATE.xml"
cp /conf/config.xml $BACKUP_FILE
scp $BACKUP_FILE opnsense_backup@stovallhut.online:/opnsense_backup/
rm $BACKUP_FILE

Remember to make the script executable:

chmod +x backup_opnsense.sh

Execute the script as a test.

./backup_opnsense.sh

On this first run you’ll probably see a warning about the unknown ssh signature – press enter to ignore the warning and accept the SSH connection. This won’t show when you run the script again in the future.

You should NOT be prompted for a password. If you are, then something is not right with the above steps when it comes to properly registering the key on the NAS. Review and debug before moving forward.

If all went well, you’ll find a new XML backup in the opnsense_backup share on your NAS!

Add new cron job type recognized by the opnsense gui

We have a script that can backup the configuration now, but it does not run automatically on a schedule. Let’s fix that. We’ll use the above script as the basis for a new type of cron command we can schedule in the opnsense gui.

At a SSH connection as root on opnsense, execute the steps below. This will relocate the script in the FreeBSD file system to the /usr/local/etc folder so it’s part of the opnsense environment. File permissions are set as required. Then we’ll create an actions_sftp_backup.conf file to register our script as a cron job.

# Move script...
mv backup_opnsense.sh /usr/local/etc/backup_opnsense.sh
# Set file permissions
chmod 700 /usr/local/etc/backup_opnsense.sh
# Add as opnsense action
vi /usr/local/opnsense/service/conf/actions.d/actions_sftp_backup.conf

Paste the following content into the actions_sftp_backup.conf at the vi prompt.

[sftp_backup]
command:/usr/local/etc/backup_opnsense.sh
parameters:
type:script
message:Starting backup script
description:Backup config to NAS

Finally, restart the configd service so the new cron job will be recognized in the gui.

# Restart configd service to expose new config
service configd restart

Create cron job to periodically backup opnsense configuration

At this point we’re nearly done. In the opnsense web console, go to System -> Settings -> Cron and press the plus (+) button to add a new job.

Fill in the time to run the job. In my example I’m executing the script at 11:28 every night.

On the above Command picklist, you should see a new Backup config to NAS you can pick. Choose that and it will execute the SFTP backup script we prepared above.

To test the cron job, see in the gui how you can clone your job – this is an easy way to create a job that will run in about one minute so you can make sure this works. Let that happen, confirm you get a new backup in the opnsense_backup network share on the NAS. Then just delete your clone when you’ve seen it work.

Trim the backups so only the last 30 days are saved

With backups happening every day, the opnsense_backup share on the NAS will consume more and more space over time. See steps below that will fix that by running a script on the NAS each day that deletes backups that are older than 30 days.

On the NAS go to Control Panel -> Task Scheduler. Create a new task based on a user-defined script. Select to execute the job as root. On the schedule tab, set the frequency you want to run the task such as daily. On the task tab, paste the following content:

#!/bin/sh
# Path to the backup directory
BACKUP_DIR="/volume1/opnsense_backup"

# Delete files older than 30 days
find $BACKUP_DIR -name "*.xml" -mtime +30 -exec rm {} \;

We’re done! Like anything, test this for proper behavior. You should see backups getting saved every day into the new opnsense_backup share on the NAS. Make a point to come back later and make sure old ones are getting deleted as expected.

The post Automatically backup your opnsense router to a Synology NAS via SFTP appeared first on Walter's Little World.

In the early ’80s after a few years of obsessing at home writing video games and the like, I managed to get a job at Scientific Atlanta (2nd job) through a lab-tech friend of mine that I had been interacting with, learning more about digital electronics. At the time, Scientific Atlanta (and most of the world) was early in the process of using microprocessors in the devices they manufactured. I was tasked with writing the firmware for a new antenna position tracking device. Like the name implies, this was a seemingly simple device with a digital display that showed the angle of rotation for a microwave antenna. Position indicators were used primarily during construction of new microwave antennas, where prototypes would receive signals while being positioned at virtually all possible azimuth and elevation angles, while recording equipment would store amplitude modulation data that was also correlated with the position in an antenna test range.

The work was led primarily by Bob Hyers who was the principal engineer. Beyond Bob’s detailed work on the high level design, the real work was done by two engineers Steve and Charles. We quickly became good friends, and they taught me how to work with the prototypes they were building in the lab, as we worked on getting things working a little more every day. Steve and Charles were responsible for defining exactly what components to put in the unit, and they laid out circuit boards and all interconnections. Then came me – the unit was not going to do anything at all in the way of indicating or transmitting antenna positions without somebody to write the necessary software. I learned from the ground-up how to debug code in a lab environment with no user interface, just an oscilloscope and some pretty amazing debugging tools (logic analyzer) that were more powerful than anything I used before or since on traditional computers. My software handled every button press, changing display modes, actually calculating the position of the antenna as a decimal angle of degrees, and displaying the position or transmitting it to other test-range equipment in a timely manner.

It was on the last point of having timely position that was at the heart of most of the complexity in the design. Scientific Atlanta already had a position indictor at the time and used it heavily. The positions it indicated were perfectly accurate too. The problem was that the position was not calculated frequently enough. Since the antenna in the test range is moving, by the time you get position data it’s already out of date due to group delay. So to make a good graph of position vs. amplitude modulation, the antenna had to be moved very very slowly as thousands of data points were recorded. This took a long time to do. Then the antenna might undergo some changes to make improvements, and the whole process had to be repeated. The problem was further complicated when the signals being transmitted were distant from the antenna receiving the data. The new position indicator would radically improve on these problems.

None of the engineers knew a thing about writing computer code. So in that sense I had a blank slate. But the algorithm was still well conceived before I came onboard. The goal was to generate accurate position data every 200 nanoseconds (ns). When I first heard this, it sounded like an impossible problem for a microprocessor of the day. The hardware design was based around an Intel CPU with a hardware clock ticking at 5 MHZ, which happens to be every 200 ns. But it was in fact impossible for the processor to calculate anything in just one tick of the clock! Even a single microcode instruction can’t execute in a single tick. But learning more, I discovered that the design was not as crazy as it sounded. It was also an opportunity for me to let my programming abilities expand a lot given the nontrivial behavior that would be called for to pull it off.

The hardware of the 1885/86 Antenna Position Indicator as this model was known, included a “rate counter”. This was a device that could indicate a changing angle, and steadily increment that value by perhaps a few thousands of a degree every 200 ns. – all with literally no action taken by the microprocessor. As intelligent as the rate counter was (including wrapping a 359.9999 position to 0.0000 at the next increment), the rate counter did not know what angle to display and did not know what increment to apply to it at the next clock tick. Telling the rate counter what to do was the job of the firmware I was to write. But in order to save manufacturing costs, my ability to control the rate counter was very limited. I could in fact not even tell the counter what angle to display! All my software could do was to change the increment that the rate counter would apply at each clock tick. Essentially, I could find out what position the counter was indicating “now” (more on that later). And I knew what increment it was currently applying at each tick (by remembering what I last told it to use). And finally, I knew the current position of the antenna. So I have these three inputs: the angle being displayed, the actual angle of the antenna, and the increment being used currently. It was up to my software to now generate one little piece of information – what should be the new increment the rate counter was using? That was my single means of controlling the position output. So it was up to me to see that the indicated position would reasonably quickly converge on an accurate indication of antenna angle.

While the hardware seemingly tied my hands behind my back, this was my favorite kind of thing to code. I want nothing more than a seemingly impossible problem that in fact has a solution. Don’t get me wrong though, the problem had been figured out already, including very detailed mathematics that my software should apply in the solution. But as always, there’s a million miles between a concept and a working device. A successful project takes competent engineers building the device and for a reasonable cost that turns a profit for the manufacturer.

The firmware I designed to do this was organized around a core software routine that was interrupt driven. Every 16 milliseconds (ms) the hardware would raise the interrupt-line on the CPU. Doing so would cause the CPU to execute an INT instruction. This meant the CPU would save its current instruction address (i.e. the address of the next instruction it plans to execute) on the system stack. Then it would immediately jump to the address of the interrupt handler (pointed to by a table in the first page of RAM). There, was a tight little piece of code I wrote in assembly language (but most of the code was written in C-language). The function of the interrupt handler was to schedule the most high priority task defined in my self-designed SAMOS (Scientific Atlanta Multitasking Operating System). There were various tasks for the software to regularly perform, including updating the display, responding to button presses by the operator, transmitting position output to the front panel or other devices on the serial I/O bus, and miscellaneous maintenance and diagnostics tasks.

As its last step the interrupt handler transferred control to the SAMOS scheduler to execute the current highest-priority task and that happened to pretty much always be updating the position. To calculate the angle, the code would read a couple values from the synchro that was attached to the base of the antenna. These values were not in constant motion, like the antenna itself. Instead they were latched at the time of the interrupt immediately beforehand. By applying some trigonometry to ratios from the synchro, it was possible to generate a digital angle in degrees. Like many things though, even that was a lot harder than it sounds given the real-time requirements of the device. The trigonometry calculations could naturally be done with floating point math. But to do that would mean using a floating point library, given the limits of the instruction set on the 8088 processor. That would have been way too slow. If, in the execution of this task, the software takes too long to calculate the angle and the new rate and along comes another interrupt signal then you’ve failed! That’s an overspeed-condition. It’s absolutely essential to prevent that. Downrange measurements will be wrong to a degree that’s supposed to be impossible.

Various techniques were used to multiply or divide without using floating point arthmetic. In some cases the code just looked up a number in say a 1KB table stored in ROM (truncating index bits as necessary, but also often using them to skew the looked-up table entry). Another simple example would be to use the processor’s shift-left instruction to shift a variable by a small number of bits (where each shift is a multiply-by-2), then multiply or divide integer variables (usually by a pre-calculated constant that’s also been shifted). That generates an integer result, then finally use the shift-right (divide by 2) to get the result back in the intended scale. It takes a lot of care with the scale of the numbers to avoid overflow conditions, while still achieving accuracy requirements.

As always, latching was key to synchronizing the calculations done in the firmware with the time of the moving antenna. Input latching means that the software is always calculating using numbers that are now obsolete given the moving antenna, but were known to be accurate at a specific moment in the recent past. Output latching means the software calculates updated rate values the equipment should now apply, but the change is only applied at a well defined moment in the near future. All this makes it possible to make precise measurements and control, in spite of the variable response times in the software.

As a point of real pride, I was named on the United States Patent 4,853,839 for Antenna Position Tracking Apparatus and Methods. The basis for calling this a new invention, is that for the first time this results in a position indicator with zero group delay for an antenna moving at a constant velocity. It does that essentially by predicting where the antenna will be in the near future, rather than always showing obsolete position data. I’m named as one of four inventors – Steven Nichols, Robert Hyers, Walter Stovall, and Charles Trawick. Good times I’ll always remember fondly.

(use the tool-bar for full-screen and zoom/turn pages, how it all works is on pages 20 & 21)

The post My early days grokking the wonder of microprocessors appeared first on Walter's Little World.

It takes a lot of engines to power the StarShip – 33 engines in the first stage and then six more in the second stage. Producing an engine per day is a big confidence booster when it comes to the risks associated with using the StarShip as planned. For perspective on what that rate means, compare this to just a few years ago when production of a comparable engine was targeted at four per year.

In 2015, NASA gave Aerojet Rocketdyne a contract worth $1.16 billion to “restart the production line” for the RS-25 engine. Again, that was money just to reestablish manufacturing facilities, not actually build the engines. NASA is paying more than $100 million for each of those. With this startup funding, the goal was for Aerojet Rocketdyne to produce four of these engines per year.

arstechnica.com

Moving ahead with StarShip testing and development

Production capabilities aside, the StarShip is far from proven. There’s yet to be an orbital launch. Although there have been successful static fire tests of the second stage, there’s yet to be a full static fire of all 33 engines in the first stage. When that will happen is guesswork, but any day now. A few weeks ago, it was going to happen in a few weeks.

I can’t wait. Seeing the static fire and orbital launch of StarShip, a rocket big enough to pack cargo to Mars, that will be sweet!

Late breaking news 11/3/2022…. SpaceX is pushing for an orbital test before the end of 2022 and NASA plans are in keeping with that!

The post SpaceX is churning out a Raptor per day now appeared first on Walter's Little World.

I’m going detail below some of how I’m managing this with a couple VMs I have deployed on a cluster of (two) servers. The details of how I do this on a Synology NAS are pretty specific to that hardware – the concepts are not.

Highlights of this framework include:

• Packaging services in a VM contains the scope of the damage when the “server” is compromised.
• Clustered hosts make it easy to move VMs to a new host or failover the VM if its host server is down.
• Snapshots of VMs can be created instantly as scheduled and then replicated to other hosts in the cluster.
• VMs can be exported to an external file system for off-site backup

How I put the pieces together

So much for the abstract, see below I’ll show you how I put this architecture together on my home network, clustering two servers that share two virtual machines.

The purpose of the virtual machines is not hugely relevant but as you’ll see in the screenshots here, the two virtual computers I have are hutbuddy_websites and Quicken_WindowsServer. The first is a virtual computer that runs a copy of Virtual DSM and hosts a few websites on my network. Websites can be notoriously vulnerable to attack. While I’m careful with security at those sites, it’s good to know that if the whole server went down it would still be only those websites and not my whole network. The second VM is something I use for running Quicken on a virtual Windows machine.

Now let’s start with VMs that exist, but they aren’t protected like I’ll outline. On a Synology server and many others, backing up virtual computers can get tricky and some of it gets downright philosophical with certain camps touting that you should just backup the VM from within the VM itself. Yeah that’s possible but recovering from a disaster requires rebuilding that VM from scratch starting by installing an operating system. It’s going to take hours with anything complex, and maybe days. I’m not settling for that because I don’t have to…

Clustering virtual computers

The redundancy starts by clustering hosts that each share the same virtual machines. Only one host at a time is designated to be the one that runs a given VM. But with a simple action in the Protection Plan it is possible to move the VM to another host, either for better loading or because a host is down. Note that on a Synology clustering requires a Virtual Machine Manager Pro license.

The key to redundancy is in the Protection Plan you choose for the VM. By clicking on Protection you get to this console.

In the protection plan you’ll schedule snapshots. A snapshot is a complete copy of the state of the virtual computer. Snapshots can be taken while the VM runs as filesystem-consistent snapshots at a point in time. Then you define a Retention Policy that says exactly when you want to release the space for old snapshots.

In the example policy above, the system retains snapshots for the last week and then keeps one snapshot per week for the last month.

Now that sounds like a lot of diskspace. My websites VM takes up about 250GB and I’m storing 15 or so copies of that?? Not really. Snapshots take advantage of the BTRFS file system and only store deltas. What it does mean is (unless you manually delete snapshots which you can do) if you delete a bunch of stuff it doesn’t go away immediately. That’s usually a good thing!

The outcome of clustering hosts like this is that if a host goes down, I can failover its VMs to the other host in just a few minutes. And if the VM crashes/other then I can restore from a snapshot made at various times that day, or less frequently for up to a month.

What’s missing?

OK so now we have two host servers that can each separately run the very same virtual machines. Not just sort of the same, but the same all the way down to the full content of the file system, the MAC address, everything. If a server goes down then I can almost instantly boot the VMs it hosted and they’re completely back in operation.

The only remaining problem is what if I lose both servers?? The two servers are in physical proximity. Theft, fire, or other might mean that both servers go down perhaps permanently. Obviously I won’t recover from that in just a few minutes, but the real problem is the fact that the servers were replicating snapshots to each other so now ALL the snapshots are gone!

One solution to this problem would be to periodically export the VM to a file. This is NOT a “snapshot” with only deltas, it’s a great big file that’s the whole state of the VM and everything in its internal file system.

The problems here are two-fold. For one thing, the export of a big VM might take several hours and the whole time it exports, you have to have your VM shutdown/offline. The other problem is that this is a manual action! I’m loath to have manual procedures that I can automate. But can I?

At first it seems like we’re stuck here – and that’s indeed where I stayed for months. But ultimately I got some help from a friend at reddit and found this German website that details a solution that includes using an internal utility we find in DSM (good thing google translates).

(I’m fine with using this even though not publically documented – be your own judge)

See my SSH session below (run it with root privilege i.e. sudo -i)

/volume1/@appstore/Virtualization/bin/vmm_backup_ova --help

Usage: /volume1/@appstore/Virtualization/bin/vmm_backup_ova [--dst] [--batch] [--host] [--guests] [--retent] [--retry]
        backup VM to shared folder on VMM

Options:
        --default       use default options to backup
        --dst           shared folder path for storing backup OVA
        --batch         the number of VMs exporting at a time (default: 5)
        --host|--guests mutually exclusive options
                        '--host' only backup VMs which repository is on the specified host (default: all)
                        '--guests' only backup specified VMs (default: not specified, use | for seperator if there are multiple targets)
        --retent        the number of backups for retention (default: 3)
        --retry         the number of times for backup retrying (default: 3)

Examples:
        Run backup script by default
                ./vmm_backup_ova --default
        Backup all guests which repository is on the host and store OVAs in certain shared folder
                ./vmm_backup_ova --dst=<share-name> --host="<host-name>"
        Backup all guests which repository is on the host and limit the number of VMs exporting at a time to avoid affecting performance
                ./vmm_backup_ova --batch=2 --host="<host-name>"
        Backup certain guests and store the last two OVAs per VM
                ./vmm_backup_ova --guests="<guest_name_1>|<guest_name_2>" --retent=2
root@HomeNAS2602:~#

The vmm_backup_ova utility is the cat’s meow here. I launch the program with a ssh script that reads as follows:

# clone/export VMs on this host for disaster recovery
#!/bin/bash
set -e
/volume1/@appstore/Virtualization/bin/vmm_backup_ova --dst=VMBackups --host="HomeNAS2602" --retent=1

In this case I’m telling vmm_backup_ova to export every VM running on that host and store the export in a shared folder called VMBackups and retain only one backup. A key advantage of this utility is that we do NOT have to shutdown the VM! Instead, vmm_backup_ova starts by making a temporary clone of the running VM, which happens in nearly an instant. Then it proceeds to export that clone (which is never run) while the real VM continues to run. The export of a large VM might take several hours, but it runs in the background while everything else continues to function and then the clone VM is automatically deleted.

Tip: Avoid spaces in your virtual computer names. My experience is the utility creates destination directories with the wrong names and then can’t populate them. See my use of underbars instead.

In practice I run a script like that on each of the two hosts. It’s nice that in the GUI of Virtual Machine Manager I can see and monitor the snapshot/export process even though I didn’t initiate it there. And although each NAS exports to its own file system, the VMBackups shared folder is replicated to the other host too via ShareSync, and the Hyper Backup program is used to make off-site copies of VMBackups. Finally, the VM backups share itself gets snapshot retaining content for up to a month (I snapshot nearly everything to protect it from ransomware if nothing else).

I’m currently exporting once per month as scheduled in the Task Scheduler. So if I lost BOTH hosts then I can still recover the VM from the latest export (with some hardware of course), then restore VM files from within the VM itself, as I’ll typically have made more recent file backups and not have to revert all the way back to the last export once I’m all done.

The post The Security and Redundancy of Clustered Virtual Machines appeared first on Walter's Little World.

What are these protections and why are they necessary? First let me cover a little background on how docker containers work. The code in the container executes as part of the docker engine. The docker engine by necessity, executes with root privilege and can therefore read or write any data in the file system whatsoever. To cause damage, malware in the container need only successfully submit a request to delete critical system files etc.

In addition to damaging the file system, containers can also carry out network attacks on other containers on your server. Containers normally run in the default bridge network. Being on the same subnet, the docker engine makes the containers visible to each other by name. So containers can discover other containers and get their IP address thru DNS. The requests they send to each other may be malicious and won’t be blocked by any firewall since they occur within the same docker subnet (which is not a real network – it’s a virtual LAN in the engine).

I recently went digging in this area when I got interested in installing the wiki.js container on my system to hold a wiki site. Wiki.js is a fully fledged web site/web publishing framework. Its JavaScript architecture and interfaces make it particularly susceptible to injection attacks. There’s also a history of quite a few bugs, and I’m not sure the codebase is clean of malware or poor security practices. That might be a reason to have second thoughts about using it all, but IMO that’s a little drastic if things are managed well.

But these concerns did spur me to learn about some controls that can be put in place, and how to use them. What I’m looking for here is to see that the attack surface within the docker engine, is limited to the wiki.js website itself – not my whole server. This means that an attacker might bring down wiki.js and might gain access to any information that’s been published there. But potentially numerous other services like my password manager, websites/sql databases, financial software, online movies, etc. remain unaffected.

Isolate Docker Containers

Docker provides a couple of ways to manage container security. You just have to make a point to use them when you have reason to be concerned about what a container might do (like uh…all the time I should have been doing this all along).

• Give the container its own network. Most people install containers on the default bridge network by simply not specifying otherwise. So usually examples you find on the web try to keep things simple and leave this out. Alternatively, you can isolate your container on its on network and this means it has its own subnet. Now, even if your container magically knew the IP address of another container, it would not be able to send it anything. The docker runtime would not route the request. This is why docker has this facility and why you should use it.
• Limit the logical file-system privilege of the container. As mentioned, the docker runtime runs with root privilege. That would seem to drive a nail into the coffin, for any goal of seeing your container have limited privileges as it executes file system code. But docker has a facility to address just this concern, that being the PUID/PGID arguments that tell docker to execute container requests as-though the request were executed by a specific user. So barring some kind of zero-day vulnerability in the runtime, this goes a long way to limiting the damage done by ill-formed or ill-intent code. Again, you don’t usually see these arguments getting used. They won’t protect you unless you use them.

How I went about container isolation by example

The details of applying the above docker facilities are system specific when you look at the details. But similar steps will apply regardless. In a broad sense, the problem is that of creating a dedicated bridge network for the container and then use that. Then also limit the file system privileges.

These are the specific steps I took to deploy the wiki.js container on my DS-1520+ NAS. There are lots of ways of doing the equivalent things, this is just a by-example for the steps I took based on what’s easy and familiar to me.

The first thing I’m going to do is create a network that I’ll call “wiki” where I’ll isolate the wiki.js container. I do that by running portainer, select my host and go to Networks and click on Add. Fill in the name of the network as “wiki”. Confirm the Driver is “bridge” and accept defaults on everything else and save this as a new network.

Now you can see your new network that’s setup on its own subnet.

With the network ready, I’ll now setup a user account for limiting the container’s privileges.

Start by creating a system user. On my system I just went to the Control Panel and setup a new user I call “docker_wikijs”. This user has file system privileges where the only directory it has any access to whatsoever, is the shared folder where the wiki.js maintains all its settings and data.

Getting the PUID/PGID takes executing the linux id command. If you’re comfortable with using SSH and you have SSH enabled on your server etc. then you can open a SSH prompt and get the output as shown by this example where I execute “id docker_wikijs”.

So what if you’re NOT so comfortable with SSH and you don’t have it setup? Well on a Synology don’t despair. You can actually execute the id command by setting up a task to do that in the Control Panel. The output will come to you as email. See this easy guide on doing that. (by the way you can use this same trick to execute any task such as docker run as root, just know that you need to take proper care doing so)

So take the uid and gid values that come from the id command and that’s all you need for making PUID and PGID arguments for the docker run command.

Having prepared the shared folders that wiki.js specifically wants, now I’m ready to execute docker run to install the container. See the following docker run command with highlighted arguments that isolate the container.

docker run -d --name=wikijs \
--network=wiki \
-e PUID=<uid value> \
-e PGID=<gid value> \
-p 3540:3000 \
-e TZ=America/New_York \
-v /volume1/docker/wikijs/config:/config \
-v /volume1/docker/wikijs/data:/data \
--restart always \
ghcr.io/linuxserver/wikijs

The network argument naturally puts the container on that bridge instead of the default. The PUID and PGID arguments look just like simple environment variables, but the docker runtime picks up on these and quietly applies those privileges.

Like anything though, test it out. For example reduce the user to read-only privilege and observe the wiki website failing to save files when you tell it to.

I execute the above docker run and then go to portainer and find wikijs installed as requested.

The post How to limit the possible damage done by docker container malware appeared first on Walter's Little World.