Orthogonal Thinking

Tag: homelab

  • I Spent $800 on 2.5G Gear But Forgot One $50 Component

    Last month I finally pulled the trigger on upgrading my homelab network. New Synology NAS with 2.5GbE ports—check. WiFi 6 router with multi-gig backhaul—check. Shiny 2.5G PCIe NIC for my workstation—check. I was ready for blazing fast local transfers.

    First big test: copying my photo library (about 60GB) from PC to NAS. I opened the transfer window, expecting to see numbers around 280 MB/s. Instead: 112 MB/s. Exactly 112 MB/s.

    I sat there for a solid minute, confused. Checked NIC settings. Checked NAS configuration. Rebooted the router. Same result. Then my eyes drifted to the corner of my desk—to that old 5-port Gigabit switch I’d completely forgotten about. The one connecting everything together. The one still maxed out at 1Gbps.

    I had just spent $800 on multi-gig equipment and bottlenecked the entire setup with a $30 switch from 2019.

    The Bottleneck Nobody Talks About

    Here’s a dirty secret in the homelab community: we obsess over NAS specs, server processors, and storage speeds, but many of us are still running ancient Gigabit switches that throttle everything.

    Think about it:

    • Modern NAS devices come with 2.5GbE ports standard
    • WiFi 6 routers can push 2.4Gbps+ on the 5GHz band
    • 2.5G PCIe network cards cost less than $20
    • Yet we’re all connected through switches maxed out at 1Gbps

    I did the math on my setup. My 1Gbps theoretical max was actually limiting transfers to around 940Mbps (about 117 MB/s). Meanwhile, my NAS could handle 2.5Gbps, which should give me 295 MB/s—2.5 times faster.

    🔢 Quick Math: A 50GB video project takes 7+ minutes at Gigabit speeds. At 2.5GbE? Under 3 minutes. Over a year of regular transfers, that’s hours of my life I’ll never get back.

    The Hunt for the Perfect 2.5G Switch

    I went down the rabbit hole of 2.5G switches. Enterprise options from Ubiquiti and MikroTik were $200+, often with fan noise loud enough to wake my sleeping cat. Managed switches were overkill—I just needed fast, reliable, and quiet.

    Then I found something that checked all my boxes:

    🌟 My Pick: The NICGIGA 6-Port 2.5G Unmanaged Switch turned out to be exactly what my homelab needed. It has 4x 2.5G Base-T ports plus 2x 10G SFP+ slots—perfect for future-proofing when I eventually upgrade to 10G equipment.

    Why This Specific Switch?

    After researching dozens of options, here’s what made this switch stand out:

    1. The Port Configuration Makes Sense

    Four 2.5GbE ports handle my main devices: NAS, gaming PC, workstation, and WiFi 6 AP. The two 10G SFP+ ports (which also support 1G and 2.5G modules) give me room to grow. Most competing switches only offer 2.5G ports with no upgrade path.

    2. True Plug-and-Play

    No web interface to configure. No VLANs to set up. No firmware to update (unless you want to). Just plug in power, connect cables, done. For a secondary switch in my homelab rack, simplicity is a feature, not a limitation.

    3. Fanless = Silent Operation

    This is non-negotiable for me. My homelab is in a closet near my home office. The dual-side cooling holes keep it cool without the constant whir of tiny fans. Temperature range of -10°C to 50°C means it handles summer heatwaves without throttling.

    4. 60Gbps Switching Capacity

    This might sound like marketing speak, but it matters. It means all ports can run at full speed simultaneously without congestion. When I’m transferring files to my NAS while my kid is streaming 4K content and my backup job is running—everything stays fast.

    5. Built Like a Tank

    The full metal case isn’t just aesthetic—it provides 6KV lightning protection. Living in an area with frequent thunderstorms, I’ve lost equipment to power surges before. This small detail gave me peace of mind.

    The Installation Story

    Installing the switch took approximately 90 seconds:

    1. Unplugged old Gigabit switch
    2. Mounted new switch on rack (includes wall-mount hardware)
    3. Connected power adapter
    4. Reconnected 4 Ethernet cables
    5. Watched the LEDs light up green

    No configuration. No drivers. No firmware updates required. The LEDs immediately showed link speeds—I could see which devices were connecting at 2.5G versus 1G (my old laptop, time for an upgrade).

    The Results: Before and After

    I ran the same 50GB transfer test after the upgrade:

    Metric Old 1G Switch New 2.5G Switch
    Transfer Speed 112 MB/s 278 MB/s
    50GB Transfer Time 7m 26s 3m 0s
    Plex 4K Streaming Occasional buffering Smooth
    Multi-device Load Noticeable slowdown No impact

    The 2.48x improvement matched the theoretical upgrade perfectly. But the real win was the multi-device performance. During simultaneous NAS backup + 4K streaming + file transfer, everything just worked.

    Who Actually Needs 2.5G?

    Let me be honest—not everyone needs to upgrade. Here’s my breakdown:

    You SHOULD upgrade if:

    • Your NAS has 2.5GbE ports (most modern ones do)
    • You have a WiFi 6 router with multi-gig ports
    • You regularly transfer large files (video editing, photography, VMs)
    • Multiple people stream 4K content in your household
    • You run Plex/Jellyfin media server
    • Your gaming PC has 2.5G networking (many modern motherboards include this)

    You can wait if:

    • Your connected devices only support Gigabit
    • You mainly use cloud services rather than local storage
    • Your heaviest network use is web browsing and video calls
    💡 Pro Tip: Check your devices first! Look at your NAS specs, router ports, and PC network adapters. If at least 2-3 devices support 2.5GbE, upgrading your switch instantly unlocks that performance.

    Future-Proofing with 10G SFP+

    The two 10G SFP+ slots are what really sold me on this switch. Right now, I’m using them with 2.5G modules to connect my server and main workstation. But when 10GbE becomes more affordable, I won’t need to replace the switch again.

    The SFP+ ports support:

    • 10G modules (for future upgrades)
    • 2.5G modules (what I use now)
    • 1G modules (backwards compatible)

    A true “buy once, use for years” solution.

    Six Months Later

    I’ve had this switch running 24/7 for six months now. Zero issues. Zero restarts required. The metal case gets warm during heavy transfers but never hot. The LEDs accurately show connection status, and I can quickly spot if a cable goes bad.

    It’s the kind of infrastructure upgrade that you install once and forget about—which is exactly what network equipment should be.

    The Bottom Line

    For anyone running a homelab in 2026, your Gigabit switch is probably your biggest bottleneck. The jump to 2.5GbE provides a meaningful, noticeable improvement without the complexity or cost of full 10G infrastructure.

    The NICGIGA 6-Port 2.5G Switch hit the sweet spot for my needs: enough ports, 10G upgrade path, silent operation, and rock-solid reliability. If your homelab devices are waiting for faster networking, this might be the upgrade that finally lets them breathe.

    Now if you’ll excuse me, I have a 200GB VM backup to transfer. Should take about 12 minutes instead of 30. Progress.

    What’s your homelab network setup? Still running Gigabit, or have you made the jump to multi-gig? Share your experience in the comments!

  • How Dust Almost Killed My Homelab: A 3AM War Story

    How Dust Almost Killed My Homelab: A 3AM War Story

    The error made no sense. Again. My Proxmox server was throwing random kernel panics, containers were crashing like it was their full-time job, and the CPU temps were hotter than my coffee (and I drink it scalding). I did what any self-respecting homelabber would do: rebooted, swore at it, and Googled furiously. Nothing worked. Was my hardware dying? Was I cursed? Turns out, the culprit wasn’t some obscure bug or failing component—it was dust. Yes, dust. The silent killer of homelabs everywhere.

    If you’ve ever had your homelab betray you at the worst possible moment, this one is for you. Grab a coffee, because this is going to be a ride.

    The 3AM Proxmox Meltdown

    It was 3AM, and I was blissfully dreaming of perfectly balanced load balancers when my phone buzzed with a notification that no homelab enthusiast wants to see: critical Proxmox errors. My heart sank faster than a RAID array with a failed disk. I stumbled out of bed, half-blind, and made my way to the server rack, muttering something about how I should’ve just stuck to Raspberry Pis.

    The first thing I noticed was the sound—or rather, the lack of it. My trusty server, which usually hummed like a content robot, was eerily quiet. I logged into the Proxmox web interface, only to be greeted by a wall of red error messages that might as well have said, “You’re not sleeping tonight.” CPU temperatures were spiking, VMs were failing, and the logs were a cryptic mess of warnings. Great.

    After a few minutes of panic Googling and trying to decipher the logs, I decided to do what any self-respecting homelabber would do: open the case and poke around. That’s when I saw it—the true villain of this horror story.

    The Dust Bunnies Had Taken Over

    Not the cute, fluffy kind you’d see in a Pixar movie, but the kind that turn your server into a thermal disaster zone. Months of neglect had allowed these dusty fiends to clog up the CPU cooler and fans, turning my once-reliable server into a hotbox. It looked like a tumbleweed convention had taken up residence inside my chassis.

    I grabbed a can of compressed air and went to town, evicting the dust bunnies with the fury of someone who just realized they’re going to be up until sunrise. Pro tip: always wear a mask and ground yourself with an anti-static wrist strap when doing this. Trust me on both counts.

    After the cleanup, the server roared back to life, and the Proxmox errors disappeared like magic. Crisis averted. But as I sat there at 4AM, covered in dust and questioning my life choices, I realized something: this was going to keep happening unless I did something about the air quality in my server closet.

    Why Your Homelab is a Dust Magnet

    Here’s the deal: your homelab, with its fans spinning 24/7, is basically a vacuum cleaner for every particle in the room. Dust builds up over time, especially in setups with poor airflow or neglected maintenance. Once dust starts coating your components, it acts like a thermal blanket—except this blanket doesn’t keep your hardware cozy; it cooks it.

    The signs are easy to miss until it’s too late:

    • Fans that sound like they’re auditioning for a jet engine role
    • Unexplained errors or system crashes
    • Temperatures spiking higher than your anxiety during a failed RAID rebuild
    • That vague feeling that something smells… warm

    I knew I needed a better solution than quarterly “dust bunny eviction sessions.” So I went down the rabbit hole of air purification research. Because that’s what we do, right? Solve one problem by creating a new obsession.

    The HEPA Disappointment

    My first instinct was to grab a HEPA filter. They’re the go-to for air purification, the bouncers of the particle world. But after some research, I realized HEPA has a few problems for homelab use:

    • Filter replacement costs add up fast — We’re talking $50-100 every few months
    • They clog up quickly — Especially in dusty environments (like, you know, a server room)
    • Some generate ozone — Not great for electronics or your lungs
    • Airflow resistance — They can actually make your HVAC work harder

    I needed something better. Something that could handle the constant dust assault without turning into a money pit.

    Discovering TPA Technology

    That’s when I stumbled onto TPA (Two-Polar Active) technology. Instead of just passively filtering air like HEPA, TPA actively zaps particles using an electric field. Think of it as the difference between a fly swatter and a bug zapper. The particles get captured on collector plates that you can wash and reuse. No replacement filters. No ongoing costs. Just rinse, dry, and keep going.

    For a homelab, this was exactly what I needed:

    • Captures microscopic particles down to 0.0146μm (way smaller than HEPA can handle)
    • Reusable collector plates = no filter subscription
    • Less airflow resistance = servers can breathe easier
    • Silent operation = I can actually sleep in the same house as my rack

    Six Months Later

    I’ve been running the Airdog X5 in my server room for about six months now. The difference is… honestly kind of boring? And I mean that as the highest compliment. No more 3AM panics. No more dust bunny eviction parties. The inside of my server cases look almost clean when I do my quarterly inspections (old habits die hard).

    CPU temps dropped about 8-10°C on average. Fan noise is down because they’re not working overtime. And that vague burning smell? Gone.

    Was it cheap? No. At around $650, it hurt to click that buy button. But when I think about the cost of replacing fried hardware, or the value of my sanity at 3AM, it was worth it. Plus, there’s something deeply satisfying about cleaning those collector plates and seeing just how much gunk it’s captured. Gross, but satisfying.

    💡 Placement Tip: I put mine near the server rack intake. Some people say to keep it away from electronics due to potential EMI, but I’ve had zero issues. Your mileage may vary—start close and move it back if you notice any weirdness.

    Lessons Learned

    So what did this whole adventure teach me?

    1. Dust is a real threat. Not a “someday” problem—an “it will take down your cluster at 3AM” problem.
    2. Monitoring is key. Set up temperature alerts. I use a simple Python script with psutil to ping me when things get toasty.
    3. Prevention beats cure. Cleaning your servers is good. Not having to clean them as often is better.
    4. HEPA isn’t the only option. TPA technology is worth looking into for tech-heavy spaces.

    Your homelab is your kingdom. Don’t let dust bunnies stage a coup.

    If you’re dealing with similar dust issues and want to check out the Airdog X5 I mentioned, here’s where I got mine. Not sponsored, just a fellow homelabber sharing what worked for me.

  • Setup latest Elastic Search and Kibana on CentOS7 in April 2022

    Imagine this: your boss walks in and says, “We need real-time search and analytics. Yesterday.” You’ve got a CentOS 7 box, and you need Elasticsearch and Kibana running—fast, stable, and secure. Sound familiar? Good. Let’s get straight to business.

    Step 1: Prerequisites—Don’t Skip These!

    Before you touch Elasticsearch, make sure your server is ready. These steps aren’t optional; skipping them will cost you hours later.

    • Set a static IP:

      sudo vi /etc/sysconfig/network-scripts/ifcfg-ens3

      Tip: Double-check your network config. A changing IP will break your cluster.

    • Set a hostname:

      sudo vi /etc/hostname

      Opinion: Use meaningful hostnames. “node1” is better than “localhost”.

    • (Optional) Disable the firewall:

      sudo systemctl disable firewalld --now

      Gotcha: Only do this in a trusted environment. Otherwise, configure your firewall properly.

    • Install Java (Elasticsearch needs it):

      sudo yum install java-1.8.0-openjdk.x86_64 -y

      Tip: Elasticsearch 8.x bundles its own JVM, but installing Java never hurts for troubleshooting.

    Step 2: Install Elasticsearch 8.x

    Ready for the main event? Let’s get Elasticsearch installed and configured.

    1. Import the Elasticsearch GPG key:

      sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
    2. Add the Elasticsearch repo:

      sudo vi /etc/yum.repos.d/elasticsearch.repo
      [elasticsearch]
name=Elasticsearch repository for 8.x packages
baseurl=https://artifacts.elastic.co/packages/8.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=0
autorefresh=1
type=rpm-md

      Tip: Set enabled=0 so you only use this repo when you want to. Avoid accidental upgrades.

    3. Install Elasticsearch:

      sudo yum install --enablerepo=elasticsearch elasticsearch -y
    4. Configure Elasticsearch:

      sudo vi /etc/elasticsearch/elasticsearch.yml
      node.name: "es1"
cluster.name: cluster1
script.allowed_types: none

      Opinion: Always set node.name and cluster.name. Defaults are for amateurs.

    5. Set JVM heap size (optional, but recommended for tuning):

      sudo vi /etc/elasticsearch/jvm.options
      -Xms4g
-Xmx4g

      Tip: Set heap to half your available RAM, max 32GB. Too much heap = slow GC.

    6. Enable and start Elasticsearch:

      sudo systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service
    7. Test your installation:

      curl -X GET 'http://localhost:9200'

      Gotcha: If you get a permission error, check SELinux or your firewall.

    Step 3: Install and Configure Kibana

    Kibana is your window into Elasticsearch. Let’s get it running.

    1. Add the Kibana repo:

      sudo vi /etc/yum.repos.d/kibana.repo
      [kibana-8.x]
name=Kibana repository for 8.x packages
baseurl=https://artifacts.elastic.co/packages/8.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

      Tip: Keep enabled=1 for Kibana. You’ll want updates.

    2. Install Kibana:

      sudo yum install kibana -y
    3. Generate the enrollment token (for secure setup):

      bin/elasticsearch-create-enrollment-token -s kibana

      Gotcha: Save this token! You’ll need it when you first access Kibana.

    4. Reload systemd and start Kibana:

      sudo systemctl daemon-reload
sudo systemctl enable kibana.service
sudo systemctl restart kibana.service

      Tip: Use restart instead of start to pick up config changes.

    Final Thoughts: Don’t Get Burned

    • Security: Elasticsearch 8.x is secure by default. Don’t disable TLS unless you know exactly what you’re doing.
    • Memory: Monitor your heap usage. Elasticsearch loves RAM, but hates swap.
    • Upgrades: Always test upgrades in a staging environment. Elasticsearch upgrades can be breaking.

    If you followed these steps, you’re ready to build powerful search and analytics solutions. Don’t settle for defaults—tune, secure, and monitor your stack. Any questions? I’m Max L, and I don’t believe in half-measures.

  • How to move ZVol or Dataset to another pool

    Imagine this: your ZFS pool is running out of space, or perhaps you’ve just set up a shiny new storage array with faster drives. Now you’re faced with the challenge of migrating your existing ZVols or datasets to the new pool without downtime or data loss. If you’ve been there, you know it’s not just about running a couple of commands—it’s about doing it safely, efficiently, and with a plan. In this guide, we’ll dive deep into the process of moving ZVols and datasets between ZFS pools, with real-world examples, performance tips, and security considerations to help you avoid common pitfalls.

    🔐 Security Note: Before we dive in, remember that ZFS snapshots and transfers do not encrypt data by default. If you’re transferring sensitive data, ensure encryption is enabled on the target pool or use an encrypted transport layer like SSH.

    Understanding the Basics: ZVols, Datasets, and Pools

    Before we get into the nitty-gritty, let’s clarify some terminology:

    • ZVol: A block device created within a ZFS pool. It’s often used for virtual machines or iSCSI targets.
    • Dataset: A filesystem within a ZFS pool, typically used for storing files and directories.
    • Pool: A collection of physical storage devices managed by ZFS, which serves as the foundation for datasets and ZVols.

    When you move a ZVol or dataset, you’re essentially transferring its data from one pool to another. This can be done on the same system or across different systems. The key tools for this operation are zfs snapshot, zfs send, and zfs receive.

    Step 1: Preparing for the Migration

    Preparation is critical. Here’s what you need to do before starting the migration:

    1.1 Verify Available Space

    Ensure the target pool has enough free space to accommodate the ZVol or dataset you’re moving. Use the zfs list command to check the size of the source and target pools:

    # Check the size of the source dataset or ZVol
zfs list aaa/myVol

# Check available space in the target pool
zfs list bbb

    

    ⚠️ Gotcha: ZFS does not automatically compress data during transfer unless compression is enabled on the target pool. If your source dataset is compressed, ensure the target pool supports the same compression algorithm, or you may run out of space.
    

    1.2 Create a Snapshot
    

    Snapshots are immutable, point-in-time copies of your ZVol or dataset. They’re essential for ensuring data consistency during the transfer. Use the zfs snapshot command to create a recursive snapshot:
    

    # Create a snapshot of a ZVol
zfs snapshot -r aaa/myVol@relocate

# Create a snapshot of a dataset
zfs snapshot -r aaa/myDS@relocate

    

    💡 Pro Tip: Use descriptive snapshot names that indicate the purpose and timestamp, such as @relocate_20231015. This makes it easier to manage snapshots later.
    

    Step 2: Transferring the Data
    

    With your snapshot ready, it’s time to transfer the data using zfs send and zfs receive. These commands work together to stream the snapshot from the source pool to the target pool.
    

    2.1 Moving a ZVol
    

    To move a ZVol named myVol from pool aaa to pool bbb, run the following commands:
    

    # Send the snapshot to the target pool
zfs send aaa/myVol@relocate | zfs receive -v bbb/myVol

    

    The -v flag in zfs receive provides verbose output, which is helpful for monitoring the transfer progress.
    

    2.2 Moving a Dataset
    

    The process for moving a dataset is identical to moving a ZVol. For example, to move a dataset named myDS from pool aaa to pool bbb:
    

    # Send the snapshot to the target pool
zfs send aaa/myDS@relocate | zfs receive -v bbb/myDS

    

    💡 Pro Tip: If you’re transferring data over a network, use SSH to secure the transfer. For example: zfs send aaa/myDS@relocate | ssh user@remotehost zfs receive -v bbb/myDS.
    

    2.3 Incremental Transfers
    

    If the dataset or ZVol is large, consider using incremental transfers to reduce downtime. First, create an initial snapshot and transfer it. Then, create additional snapshots to capture changes and transfer only the differences:
    

    # Initial transfer
zfs snapshot -r aaa/myDS@initial
zfs send aaa/myDS@initial | zfs receive -v bbb/myDS

# Incremental transfer
zfs snapshot -r aaa/myDS@incremental
zfs send -i aaa/myDS@initial aaa/myDS@incremental | zfs receive -v bbb/myDS

    

    ⚠️ Gotcha: Incremental transfers require all intermediate snapshots to exist on both the source and target pools. Deleting snapshots prematurely can break the chain.
    

    Step 3: Post-Migration Cleanup
    

    Once the transfer is complete, you’ll want to clean up the old snapshots and verify the integrity of the data on the target pool.
    

    3.1 Verify the Data
    

    Use zfs list to confirm that the ZVol or dataset exists on the target pool and matches the expected size:
    

    # Verify the dataset or ZVol on the target pool
zfs list bbb/myVol
zfs list bbb/myDS

    

    3.2 Delete Old Snapshots
    

    If you no longer need the snapshots on the source pool, delete them to free up space:
    

    # Delete the snapshot on the source pool
zfs destroy aaa/myVol@relocate
zfs destroy aaa/myDS@relocate

    

    💡 Pro Tip: Keep the snapshots on the target pool for a few days to ensure everything is working as expected before deleting them.
    

    Performance Considerations
    

    Transferring large datasets or ZVols can be time-consuming, especially if you’re working with spinning disks or a slow network. Here are some tips to optimize performance:
    

      

    • Enable Compression: Use the -c flag with zfs send to compress the data during transfer.
      • 

    • Use Parallel Streams: For very large datasets, split the transfer into multiple streams using tools like mbuffer.
      • 

    • Monitor Resource Usage: Use zpool iostat to monitor disk activity and adjust the transfer rate if necessary.
      • 

    

    Conclusion
    

    Moving ZVols and datasets between ZFS pools is a powerful feature that allows you to reorganize your storage, upgrade hardware, or migrate to a new system with minimal hassle. By following the steps outlined in this guide, you can ensure a smooth and secure migration process.
    

    Key Takeaways:
    

      

    • Always create snapshots before transferring data to ensure consistency.
      • 

    • Verify available space on the target pool before starting the migration.
      • 

    • Use incremental transfers for large datasets to minimize downtime.
      • 

    • Secure your data during network transfers with SSH or encryption.
      • 

    • Clean up old snapshots only after verifying the migration was successful.
      • 

    

    Have you encountered any challenges while migrating ZFS datasets or ZVols? Share your experiences in the comments below, or let us know if there’s a specific topic you’d like us to cover next!

  • Setup k3s on CentOS 7

    Imagine this: you need a lightweight Kubernetes cluster up and running today—no drama, no endless YAML, no “what did I forget?” moments. That’s where k3s shines, especially on CentOS 7. I’ll walk you through the setup, toss in some hard-earned tips, and call out gotchas that can trip up even seasoned pros.

    Step 1: Prerequisites—Get Your House in Order

    Before you touch k3s, make sure your CentOS 7 box is ready. Trust me, skipping this step leads to pain later.

    • Set a static IP and hostname (don’t rely on DHCP for servers!):

      vi /etc/sysconfig/network-scripts/ifcfg-eth0
vi /etc/hostname

      Tip: After editing, restart networking or reboot to apply changes.

    • Optional: Disable the firewall (for labs or trusted networks only):

      systemctl disable firewalld --now

      Gotcha: If you keep the firewall, open ports 6443 (Kubernetes API), 10250, and 8472 (Flannel VXLAN).

    Step 2: (Optional) Install Rancher RKE2

    If you want Rancher’s full power, set up RKE2 first. Otherwise, skip to k3s install.

    1. Create config directory:

      mkdir -p /etc/rancher/rke2
    2. Edit config.yaml:

      token: somestringforrancher
tls-san:
  - 192.168.1.128

      Tip: Replace 192.168.1.128 with your server’s IP. The tls-san entry is critical for SSL and HA setups.

    3. Install Rancher:

      curl -sfL https://get.rancher.io | sh -
    4. Enable and start the Rancher service:

      systemctl enable rancherd-server.service
systemctl start rancherd-server.service
    5. Check startup status:

      journalctl -eu rancherd-server.service -f

      Tip: Look for “Ready” messages. Errors here usually mean a misconfigured config.yaml or missing ports.

    6. Reset Rancher admin password (for UI login):

      rancherd reset-admin

    Step 3: Install k3s—The Main Event

    Master Node Setup

    curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -
    • Tip: K3S_KUBECONFIG_MODE="644" makes /etc/rancher/k3s/k3s.yaml world-readable. Good for quick access, but not for production security!
    • Get your cluster token (needed for workers):

      sudo cat /var/lib/rancher/k3s/server/node-token

    Worker Node Setup

    curl -sfL https://get.k3s.io | \
  K3S_URL="https://<MASTER_IP>:6443" \
  K3S_TOKEN="<TOKEN>" \
  K3S_NODE_NAME="<NODE_NAME>" \
  sh -
    • Replace <MASTER_IP> with your master’s IP, <TOKEN> with the value from node-token, and <NODE_NAME> with a unique name for the node.
    • Gotcha: If you see “permission denied” or “failed to connect,” double-check your firewall and SELinux settings. CentOS 7 can be picky.

    Final Thoughts: What’s Next?

    You’ve got a blazing-fast Kubernetes cluster. Next, try kubectl get nodes (grab the kubeconfig from /etc/rancher/k3s/k3s.yaml), deploy a test workload, and—if you’re feeling brave—secure your setup for production. If you hit a snag, don’t waste time: check logs, verify IPs, and make sure your token matches.

    I’m Max L, and I never trust a cluster until I’ve rebooted every node at least once. Happy hacking!

  • Setup a used Aruba S2500 switch and remove stacking ports

    Imagine this: You’ve just scored a used Aruba S2500 switch for a fraction of its original price. It’s sitting on your desk, promising enterprise-grade performance for your home network. But as you power it on, you realize it’s not as plug-and-play as your typical consumer-grade hardware. What now? This guide will walk you through setting up the Aruba S2500, repurposing its stacking ports, and unlocking its full potential—all without breaking the bank.

    Why Consider Enterprise Hardware for Your Home Network?

    Unmanaged Gigabit Ethernet switches are sufficient for most households. They’re simple, reliable, and affordable. But if you’re looking to upgrade to multi-Gigabit speeds—perhaps for a home lab, 4K video editing, or a NAS—you’ll quickly find that consumer-grade options with 10Gbps capabilities are eye-wateringly expensive.

    That’s where used enterprise hardware like the Aruba S2500 comes in. These switches, often retired from corporate environments, offer robust performance and advanced features at a fraction of the cost of new consumer-grade alternatives. For instance, I picked up an Aruba S2500 48P-4SFP+POE for just $115 on eBay. This model includes four SFP+ ports, each capable of 10Gbps, making it perfect for high-speed setups.

    💡 Pro Tip: When buying used enterprise hardware, always check the seller’s reviews and confirm that the device is in working condition. Look for terms like “tested” or “fully functional” in the listing.

    Before We Begin: A Word on Security

    Before diving into the setup, let’s address the elephant in the room: security. Enterprise-grade switches like the Aruba S2500 are designed for managed environments, meaning they often come with default configurations that are not secure for home use. For example, default admin credentials like admin/admin123 are a hacker’s dream. Additionally, outdated firmware can leave your network exposed to vulnerabilities.

    🔐 Security Note: Always update the firmware and change default credentials during setup. Leaving these unchanged is akin to leaving your front door unlocked.

    Step 1: Perform a Factory Reset

    If you’ve purchased a used switch, it’s crucial to start with a clean slate. The previous owner’s configuration could interfere with your setup or, worse, leave security holes.

    To perform a factory reset on the Aruba S2500:

    1. Power on the switch and wait for it to boot up.
    2. Use the front-panel menu to navigate to the reset option.
    3. Confirm the reset and wait for the switch to reboot.

    Once the reset is complete, the switch will return to its default configuration, including default credentials and IP settings.

    Step 2: Access the Management Interface

    After the reset, the switch’s management interface will be accessible at its default IP address: 172.16.0.254. Here’s how to connect:

    1. Connect your computer to one of the switch’s Ethernet ports.
    2. Ensure your computer is set to obtain an IP address via DHCP.
    3. Open a web browser and navigate to http://172.16.0.254.
    4. Log in using the default credentials: admin / admin123.

    If everything is set up correctly, you should see the Aruba S2500’s web-based management interface.

    ⚠️ Gotcha: If you can’t connect to the management interface, double-check your computer’s IP settings and ensure the switch is properly reset.

    Step 3: Configure the Switch

    Now that you’re logged in, it’s time to configure the switch. Follow these steps:

    1. Complete the setup wizard to assign a static IP address for management. This ensures you can easily access the switch in the future.
    2. Update the firmware to the latest version. Aruba provides firmware updates on their support site, but you’ll need to create an account to download them.

    To update the firmware:

    # Example of updating firmware via CLI
copy tftp://<TFTP_SERVER_IP>/<FIRMWARE_FILE> system:partition0
reload
    

    Replace <TFTP_SERVER_IP> and <FIRMWARE_FILE> with the appropriate values for your setup.
    

    
💡 Pro Tip: Always update both firmware partitions to ensure you have a fallback in case of a failed upgrade.

    

    Step 4: Repurpose Stacking Ports
    

    The Aruba S2500 includes two dedicated stacking ports, which are typically used to connect multiple switches in a stack. However, in a home setup, you’re unlikely to need this feature. Instead, you can repurpose these ports for regular network traffic.
    

    To repurpose the stacking ports:
    

      

    1. Connect to the switch via SSH or a serial console. You can use tools like PuTTY or the built-in terminal on macOS/Linux.
      2. 

    2. Enter enable mode by typing en and providing your enable password.
      3. 

    3. Delete the stacking interfaces:
      4. 

    

    # Commands to repurpose stacking ports
delete stacking interface stack 1/2
delete stacking interface stack 1/3
    

    After running these commands, the stacking ports will function as standard SFP+ ports, capable of 10Gbps speeds.
    

    
⚠️ Gotcha: Repurposing stacking ports may require a reboot to take effect. Save your configuration before rebooting to avoid losing changes.

    

    Step 5: Test Your Setup
    

    With the configuration complete, it’s time to test your setup. Connect devices to the switch and verify that they can communicate with each other. Use tools like iperf to measure network performance and ensure you’re getting the expected speeds.
    

    # Example iperf command to test bandwidth
iperf3 -c <TARGET_IP> -P 4
    

    Replace <TARGET_IP> with the IP address of another device on your network.
    

    Alternative: Consider a Newer Model
    

    If the idea of configuring used enterprise hardware feels daunting, you might consider a newer model like the Aruba Instant On 1930. While more expensive, it offers similar performance with a more user-friendly interface.
    

    For example, the Aruba Instant On 1930 24-Port Gb Ethernet switch (JL683A#ABA) is currently available for $434.99. It includes 24 PoE ports and four SFP+ ports, making it a solid choice for small business or advanced home setups.
    

    Conclusion
    

    Setting up a used Aruba S2500 switch might seem intimidating at first, but with a little effort, you can unlock enterprise-grade networking at a fraction of the cost. Here are the key takeaways:
    

      

    • Enterprise hardware offers excellent value for high-performance home networks.
      • 

    • Always perform a factory reset and update firmware to secure your switch.
      • 

    • Repurposing stacking ports can maximize the utility of your hardware.
      • 

    • Testing your setup ensures you’re getting the performance you expect.
      • 

    

    Have you set up a used enterprise switch for your home network? Share your experiences and tips in the comments below!
Home · About · Privacy Policy · Terms of Service
© 2026 Orthogonal Info. All rights reserved.