State of the Network - September 2024

I haven't posted in a while so I thought I might get the blog up to speed.  I have been busily pushing things in the rack to an everyday state.  To do that I had an epihany about the connection between the living room manaaged switch (GS108Tv2) and the back bedroom managed switch (GS116Tv2).  It turns out that instead of using a Powerline adapter, I would be able to use a 35 foot flat Ethernet cable to accomplish the same thing.  So I obtained a flat Ethernet cable, ran it along the floorboard, through the balcony door, around the back of the balcony, through the bedroom door, and plugged into an extension Ethernet cable coming from the back bedroom managed switch.  In doing that, I managed to get the speedtest to triple on downlink (at times) and double the upload speed (at times) [201.9/237 Mbps].  I assume that this means I am approaching the 1Gbps speed between the two managed switches.  This also means that I am not susceptable to power fluctuations on the Ethernet line between the Powerline adapters.

I have also been busily rearranging the rack equipment to use the Netgear M4100-26 and Ubiquity Edgerouter-12.  The Netgear and Edgerouter have been changed to always power on when the rack has power.  This simplifies the overall structure of the rack and eliminates the need for using the two Edgerouter-X routers and another GS108Tv2 switch.  I can now power off those three components until I might need them again.  I left them plugged into the Ethernet patch panel on the bottom.  The only disadvantage is that the Netgear M4100-26 now runs hotter; but the fans at the top are putting out cold air which indicates that it is not as hot as I might assume in the rack; currently at 104 degrees F.

I am now trying to configure a monitor system that can gather statistics and send out commands to update, reboot, shutdown, etc. equipment in the rack.  I hope to continue to get closer to an automatic mode int he rack which will support experiments in the future.

State of the Network - April 2024

Lately I have been working some electronics projects, genealogy, and really haven’t had time to really work on my HomeLab.  Sensing that I haven’t posted for some time I thought I might post about the HomeLabs current condition.  While I am working on the electronics projects most of the equipment is turned off.  In fact, I normally have only the Edgerouter-12 and the Netgear M4100-26g turned on since my laptop is pretty much permanently connected to the Server Admin vlan. So here are some bullit points  to explain where the HomeLab sits:

• I now have a managed switch at the top of the rack to connect to the outside (powered on with the rack)
• I have pushed the two Edgerouter-X routers and one managed switch into the back of the rack with their ports coming out to the front
• I now have a 24 port patch panel that connects to some ports on the top 24 port patch panel, the two ER-Xs, the managed switch, and to the 5 input ports on the Proxmox server
• I can now power the xPod, Monitor Network, Proxmox server, some specific rack RPis, and the ER-12/M4100-26g separately
• The external managed switch behind the rack has been wired differently to accomodate the changes and additional experiments on the HomeLab table
• I now have two LED strips on the front of the rack to illuminate the patch wiring
• I also have two LED strips under my laptop holder on the HomeLab table to illuminate electronic circuits on the table
• I have incorporated an UAP-AC-AD to output four specific vlan connections; one of which goes to my development vlan

These are items that I have changed but I still have items that I haven’t implemented yet. My thoughts about what I want keep changing as I come up with other ideas.  So here are some future items that I want to implement:

• I recently obtained an Edgerouter-12P which will provide POE capability in the rack and beyond; I need to determine how I will use it
• I also obtained a couple of UAP-AP-LR WAPs which I hope to use to form a wi-fi link to the back bedroom (I am unable to get an Ethernet cable pulled from the living room to my back bedroom) because the Power adapters only give me 130 Mbps throughput.
• I hope to spin up two RPi Zero Ws at opposite ends of the Ethernet over power link to monitor failures
• I hope to spin up a RPi 4B in the living room as a PiHole to be the definition of connections within my network
• I hope to be able to use my SLATE router, connected to a 2.4 GHz wi-fi connection as a fall over from the FLINT router
• I also hope to figure out how to integrate Midi into my HomeLab including a new Zynthian Synthisizer on an RPi 3B+

I have now moved the Experiment Pod to my HomeLab rack

 I decided to drop my participation in the community sub-committee and focus on other things.  In so doing, I have moved the Experiment Pod to the HomeLab rack.  I decided to change out the rack and put the entire Experiment Pod panel into the rack as well as an Edgerouter-X to give the ExPod vlan a dhcp source and isolate it from the rest of the network.  The unmanaged 8 port switch is there as well to connect to each of the ExPod RPis.

In addition, I have added a managed switch (GS108Tv3) to offload the number of connections to the key managed switch outside of the HomeLab rack.

I have re-arranged the HomeLab rack to allow for four different systems

 I decided to change out the HomeLab rack and concentrate on four sub-systems: (1) Experiment Pod; (2) Proxmox; (3) Edgerouter-12/M4100-26g; and (4) Monitor sub-system.  Each one of these sub-systems can now be independently booted up and used.

I added a GS108Tv3 managed switch to the top of the rack so that I could change out the cables going from the HomeLab rack to only need one connection to the external GS108Tv2 switch behind the rack.  This frees up some of the ports on that switch to be used for experiments on the table.  The ExPod is now behind an Edgerouter-X connected to that top switch, with all components able to be turned off at the same time from a single switch on the power switch panel.  The Proxmox server is also connected to that top switch for all of its external ports and is powered through a single switch on the power switch panel.  The Edgerouter-12/M4100-26g combination is powered down from a single switch on the same power switch panel; external connections go through the top switch.  The monitor sub-system is also turned on and off through a single switch on the power switch panel and is behind an Edgerouter-X connected to the top switch.

I also added an RGB led lighting on the sides of the HomeLab rack.

Issue: the vlans for server admin and servers still require the Edgerouter-12 to be running since the DHCP servers are on that device.  This will need to be dealt with int the future.

Why would it be important to keep a HomeLab network after you retire?

Adapted from NoteAI.com on 2023-09-25

Summary: A HomeLab is a server setup that resides in your home and allows you to host applications and virtualized systems for testing, development, or personal use. It can be a simple tower PC, a Raspberry Pi, or a repurposed professional server. Having a HomeLab has several advantages, including providing a playground for learning and experimentation, allowing you to work on projects that you can't try on the job, and enabling you to create projects that would otherwise be costly. It can also be used for hosting media, testing websites, building a DVR system, and accessing remote systems.

Why it Matters:

• A HomeLab provides a safe and controlled environment for learning and experimenting with technology.
• It allows individuals to gain hands-on experience with enterprise equipment and software.
• It can be used for personal projects, professional development, and staying current in the industry.
• A HomeLab offers flexibility and customization options that may not be available in a production environment.
• It can be a cost-effective solution for hosting services and self-hosted options.

Significance and Potential Impact:

• Keeping a HomeLab network after retirement can provide a continued opportunity for learning and staying engaged with technology.
• It allows retirees to pursue personal projects, explore new technologies, and maintain their technical skills.
• A HomeLab can serve as a hobby and a way to stay connected with the tech community.
• It provides retirees with a platform to share their knowledge and experiences with others.
• Keeping a HomeLab network can contribute to personal growth, mental stimulation, and a sense of purpose in retirement.

Implications:

• Retirees who maintain a HomeLab network can continue to contribute to the tech industry and stay relevant in their field.
• It can be a fulfilling and enjoyable hobby that provides intellectual stimulation and a sense of accomplishment.
• Retirees with a HomeLab network can share their knowledge and experiences with others, mentoring and inspiring the next generation of tech enthusiasts.
• It can be a way to stay connected with the tech community and continue learning from others in the field.
• Keeping a HomeLab network can contribute to a fulfilling and meaningful retirement by providing a platform for personal growth and exploration.

Using pfSense as a Multi-WAN interface for Monitoring within the HomeLab

 I am back.  I started playing with pfSense in my Proxmox server in order to have a multi-headed connection into vlans within my network.  The purpose is to have an isolated vlan (isolated in the sense that the other vlans cannot get to it) to use as a monitoring point.  My thought is this: let pfSense become the DNS/DHCP source for a number of hardware and VM/LXC components to provide monitoring and automation activities.  I would eventually use Ansible to automate setups within the HomeLab and would use Observium/collectd to monitor the different HW components.  I could also use a component to provide CA capabilities.  The steps needed include:

1. download a tar.gzip of pfSense Community Edition from the pfSense website
2. create a VM of pfSense on the Proxmox server
3. setup the VM to link to an existing vlan in the HomeLab on the WAN side and to an isolated vlan on the LAN side
4. check the pfSense console to make sure that the ports are configured correctly
5. add a Raspberry Pi w/SSD to the isolated vlan and bring it up; helps if it is already setup to integrate with the tailscale network
6. check that the Raspberry Pi can communicate through pfSense to the WAN side and that it has an IP within the subnet of the LAN; this will become the seat of monitoring and automation for the HomeLab
7. add XRDP to the Raspberry Pi so that I can access the GUI
8. setup Putty on my Windows laptop as an SSH tunnel to the web interface to pfSense through the Raspberry Pi; repeat with other things that I wish to monitor

Seemed like a good idea at the time.  Not sure why this would be frowned upon security wise.  I just need to be sure that I am always aware of new and clever attacks that might be possible within the network.

I'm wondering if the same thing can be done with one of my spare Edgerouter-X routers.

Update: I was able to do the same thing with the Edgerouter-X router.  So in retrospect, I have spun down the Proxmox pfSense router for use later.  I don't think that I will be getting rid of it anytime soon.  It's nice to know that I now have the ability to change the different routers that I have to give a multi-head ability to my HomeLab.

Ran Another Test by Connecting to a Different Room Power Outlet

 I ran a different test with the AV2 Powerlines.  This time I purposefully plugged a different AV2000 into my small bedroom outlet to see what the increase in bandwidth would be from the living room to the small bedroom.  Unfortunately, the increase was only about doubling the speed.  I was getting around 93 Mbit/sec throughput instead of 35 Mbit/sec.

The test was composed of putting a new Powerline adapter into the small bedroom, connecting the new Powerline adapter to my HomeLab switch, and running some iperf tests.  The small bedroom circuit breaker is on the opposite side of the breaker box from my large bedroom circuit breaker; and on the same side as the circuit breaker for the living room.  Again this is 25 year old wiring.  I guess in the grand scheme of things I could have an electrician move the wires between the two breakers to get the large bedroom circuit breaker on the same side of the breaker box as the living room circuit breaker.  But, is the increase in speed worth it?  It will cost me money but in the end I will have more bandwidth.

Update: I am now trying to see if there is a different way of putting my Travel Routers and arranging my network in the back bedroom that will increase my throughput to the HomeLab.

Added a new 802.11ax Router to the Apartment

So I have purchased a new router, the Gl-iNet FLINT (GL-AX1800).  The reason that I did this was to optimize the connection between my HomeLab equipment and the apartment WiFi end point.  The FLINT is located 17 and a half feet from the end point and has 4 external antenna.  In addition, the FLINT is based on OpenWRT, which the SLATE was also based on.  Right now, being a new product, the software load is not quite up to the current edition of OpenWRT, but the beta test versions are promising.  I have downloaded the latest Beta and will be updating this router prior to the full software release.  The reason is to be able to setup vlans so that I can also plug in my TV and DVD player without interfering with the HomeLab connection.

After setting up the router in the space in the living room, I am measuring a speed of 400Mbps/400Mbps to the end point when setup as a repeater.  This is the kind of speed gain that I am hoping for.  The WiFi connection is continuing to reset itself and I need to know why.  I have noticed that the main indication of failure is that the DNS is no longer able to work through the connection and that the Weather Station is no longer pushing out information.

Update: so now the FLINT router has crapped out, possibly because I did some setting I shouldn’t have.  I have updated to the latest v4.1.0 beta without any custom values and now it works.  Go figure.

Update2: the problem with the WiFi connection stopping appears to be related to a DNS issue.  I can still ping IPs but just can't use DNS names.  Is this some setting somewhere?

Experiments Show PowerLine Adapters Often Don’t Work Like You Think They Should

The IT department here in the Retirement Community keeps making changes to make things good.  So it occurred to me that maybe things might have changed in my back bedroom for the good.  So I set out to find out what kind of speeds that I was getting between my input setup and my back bedroom where my HomeLab rack resides.  So I set up some speed tests using iperf on opposite sides of the input flow.  Much to my surprise, I found out that I was only getting around 38 Mbps throughput.  I had thought I was getting closer to 1 Gbps, given the type of AV2 units that I was using.  I tried different things like getting the managed switches out of the way, but still was achieving only the 38 Mbps that I had first measured.  I also tried using Speedtest.net and found that this was the max speed that I could get.

I downloaded the TP-Link app so that I could tell what the system was saying that it was getting between units.  It was displaying around 100 Mbps speed between the units, so I started looking into what kind of speeds I could expect with different wall outlets.  I brought in a different unit and added it to the mix and started moving it about the apartment to see what I could find out.  When it was plugged into a circuit that was near one of the two AV2000 units, it would register a speed of 1300-1400 Mbps, but would still measure the 100 Mbps to the other AV2000 unit.  As I was swapping them around, I could see patterns that identified a good vs bad line.  The low bandwidth is probably due to the age of the wiring in this apartment and having to go through an old breaker box.  Nothing I can do about that right now.

I am still trying to find the “sweet” spot to have equipment in the living room, but so far have not found it.

Update: so I have discovered that there are three circuit breakers that the signal is probably passing through.  One for the living room, one for the small bedroom, and one for the large bedroom.  They also appear to be on opposite sides of the mains, so much for finding a "sweet" spot to use.  I am stuck with what I have then.

The New Input Architecture to my HomeLab

 I think I may have solved my problem with the WiFi system here at the Retirement Community.  As I said before, this is a WiFi only environment; I can run Ethernet but not through the walls and not connected to the WiFi equipment and I have no control over the WiFi system.  The WiFi equipment has two main SSIDs, SSID1 and SSID2 in the following diagram.

The Incoming WiFi Architecture

Notice that there are a number of additional elements to the architecture.  The main input to the MainRouter in my HomeLab is through the WiFi Bridge, a Gl-iNet SLATE router.  That in turn goes into a managed switch, RemoteSwitch, which has a trunk line to my MainSwitch through Two TP-Link AV2000s.  The MainSwitch in turn poses the flow as the [WAN] vlan to the WAN port of my MainRouter.  Having the trunk line between two managed switches gives me great flexibility in how I arrange items in my HomeLab.  In fact I can put part of my [SRV] vlan in the living room where the main input equipment goes.  The MainSwitch also connects to other equipment in my HomeLab as necessary.  Normally I have almost a 30 dBm signal drop between the WiFi Access Point in the living room and my large back bedroom.  This input architecture resolves that.

I have an RPiGateway which is being primed to host input ports into my HomeLab from the outside.  As it turns out I can access RPiGateway from anywhere on the Retirement community campus; I just can't access it from the outside (and I don't need to, I'm not working now).  

Over on the right of the diagram is a problem that was solved through the use of a simple switch.  I have a Sleep-Number bed and it requires a WPA/WPA2 shared key encryption setup on 2.6GHz.  It is also a bit fussy on the level of the signal that it connects to.  So in that respect I have a DIR-505L which is connected to the SSID1 and retransmits a WPA/WPA2 shared key setup to the Sleep-Number bed since WPA/WPA2 is not available from the main WiFi setup.

I have a Tempest Weather station on my balcony which has a hub that was not able to receive the WPA/WPA2 shared key setup from the small bedroom, so it is now connected to a NEWIOTSSID coming from my Unifi AP AC Pro access point.  I also have a SRVSSID broadcast from that access point that I can connect to with my personal laptop in order to perform admin functions on my HomeLab while on my balcony.

I am also using the NEWIOTSSID to connect to a series of Tasmota switches mounted in my HomeLab Rack for the purpose of controlling power to several devices, since I may only have need of a couple at a time.

Setting up the RPiGateway into my HomeLab

So now that I have a better handle on how the wifi works at GSV, I want to provide myself a way into the HomeLab through a portal.  I have a Raspberry Pi, RPiGateway, that is connected to the GSV portal wifi network that I can get to from my iPad.  I have the luxury of being able to get out that Raspberry Pi from anywhere on campus using my iPad through the wifi network. I want to be able to get to applications, update my HomeLab services, change things within my HomeLab, and do other types of things remotely.  I can do this by setting up the RPiGateway for access.  I will need to control access to the RPiGateway to ensure that only known entities should be able to access the information.  That means that my personal laptop or any iPhone/iPad device that I own should be able to get into the network.  Access control can be done via encryption and known certificates.  So the following items may need to be considered:

• Use certificates validated through Lets Encrypt and their process of 90 days
• Use synchronous certificates that are self certified including a local CA
• Provide both SSH and VPN access into the HomeLab through RPiGateway
• SSH should rely on the synchronous certificates
• VPN should rely on the Lets Encrypt certificates
• I have the following protocols that need to be addressed over each HomeLab service: RDP, HTTP/HTTPS, SSH
• May have to include some NGINX and Apache Guacamole interfaces to equipment
• Might need to decide if this is a service through the Proxmox server, or on the RPiGateway
• Security might need to be offloaded from RPiGateway
• What needs to be done to the HomeLab side of RPiGateway to decrease risk if RPiGateway is compromised

All of these elements need to be considered.  Right now I can start setting things up that are accessible via the SSH port on RPiGateway, even though this would mean some special Apps on the iPhone/iPad.

Update: it turns out that getting a Lets Encrypt cert is a pain if you don’t have internet access to your web server.  This is not my case, so I will have to rely on a local CA to do certificates.  I am also realizing that I may want to move RPiGateway further into the HomeLab in the future, so I need to adjust for that.

History - The Current Setup of the GSV HomeLab

Environment - I live in an apartment in a wifi only environment.  There are two SSIDs for the tenants which allow connection of most devices. One SSID is open but is MAC address enabled based on a list, the other is encrypted and requires authentication.  The two wifi services are keyed to the resident accounts so that communication can happen between them for a single resident; but not to other resident computers using the same network topology.  The biggest problem for me having a HomeLab is to be able to do things in this environment.  In addition, the construction of the apartments are done with a view to fire safety, not to the transmission of wifi signals.  I experience a drop of almost 30 dBm from the living room to the back bedroom in signal level.  But, my HomeLab equipment is in the back bedroom and the wifi end point is in the living room, hence my dilemma.

Desires - Within the HomeLab, I have things that I want to accomplish in the living room, as well as the back bedroom.  In addition, I need the opportunity to move around the apartment at will and still do things on my HomeLab vlans.  I have no need to leave the apartment on a regular basis since I am retired.  So having a VPN connecting into my HomeLab is not necessary, unless I go on a trip.  I have no control over the wifi environment, nor can I tunnel through walls to pull Ethernet cable.  So, my HomeLab setup has to be coordinated with the circumstances.

Setup - I have to have a way into my HomeLab which is connected to the wifi environment.  I do this through a GL-iNet SLATE router which acts as a wifi bridge to my rack of equipment.  Early on I had the SLATE on top of the rack of equipment connected into the wifi environment on the encrypted side and the LAN of the SLATE plugged into the WAN port of my Ubiquiti Edgerouter-12 (ER-12).  However, I discovered that the signal level was about -78 dBm with a noise floor of around -71 dBm.  So my signal was below the noise floor; not a good situation if you want to get maximum speed.  What I then decided to do was put the SLATE in the living room, with a connection through a couple of Powerline adapters to the back bedroom where my rack of equipment resided.  That worked very well since I was getting essentially the maximum level of wifi signal that I could get in the environment.  But, as I started getting my HomeLab organized, it was apparent that I needed to get some additional equipment into the living room.  

I decided to change out the single channel through the Powerline adapters into a trunk line between two managed switches.  I placed a Netgear GS108Tv2 switch in the living room with a port configured as a trunk line with all of my defined vlans (13 in all).  That was plugged into the living room Powerline adapter and in the back bedroom the Powerline adapter was plugged into a port on a Netgear M4100-26g switch port configured with the same trunk line.  The untagged vlan on each trunk port was a dummy that only exists between the two switches.  I then configured an untagged vlan port on the two switches that would be used to pass Ethernet signals in the direction of SLATE to ER-12.  I plugged the SLATE into the resultant unmanaged port on the GS108Tv2.  The other resultant unmanaged port on the M4100-26g was then plugged into the WAN port of my ER-12.  I placed a Raspberry Pi in the living room and plugged it into a different untagged port on the GS108Tv2 which led back to the M4100-26g via the trunk to other things I was doing.  This setup now allows me to bring other equipment into the living room and place them on different vlans as I see fit.

An additional need was presented when I discovered that my Sleep Number bed needed connection to the internet but would only work with a WPA/WPA2 enabled wifi setup.  Neither of the two wifi SSIDs allowed this capability. I had to add an additional router, a D-Link DIR-505L, setup as a wifi repeater connected into the open SSID on the WAN side and presenting a WPA/WPA2 wifi signal on the LAN side.  I was then able to connect my Sleep Number bed once I added it to the small bedroom near the bed itself.  Since the DIR-505L is a wall-wart it was easily concealed under a vanity.  The WPA/WPA2 signal was also used by my Tempest Weather Station hub for connection to the internet.  In addition, I have a Raspberry Pi which is connected into the WPA/WPA2 signal and also to one of the vlans in my HomeLab rack.

I had brought a couple of my wifi access ports with me to the retirement apartment.  I set one of them up with 4 SSIDs (two disabled for now), one of them for use with my personal laptop to connect within my HomeLab and the other connected into the vlan used for controlling my Tasmota switches.  The Tasmota switches are currently used to turn on/off equipment in the HomeLab rack remotely.

Thus the saga of my changes to my HomeLab as a result of the wifi environment ends.

Alteration to the Network Input to/from the Rack

 I have been contemplating how to provide an interface into the rack that would allow me to provide an interface to the RPis and the Proxmox server on the rack.  So far I have had an interface to the Edgerouter-12 (ER-12) through a SLATE router.  However, I found out that the rule set that is being used here in the retirement community doesn’t allow me to access ports on the SLATE unless I am connected to their portal vlan.  I decided to start some experiments to find out what I can actually do with the network.  Be aware that all IP addresses within the retirement community are RFC1918 private addresses.

I had previously connected the SLATE router to the ER-12 through two AV2000 Ethernet over power interfaces, each with two Ethernet ports apiece.  So it was SLATE LAN -> AV2000 -> AV2000 -> ER-12 WAN.  The SLATE was connected into the resident vlan which does not allow conversation between hosts on the resident vlan.  However, I have been able to connect between a host on the resident vlan and a host on the portal vlan.  I decided to put an RPi connected to the portal vlan, but also connected to a vlan within the rack.  That way, I can connect my laptop, or iPhone/iPad to any port on the RPi.  To do this, I decided to implement a trunk line between the two AV2000s.

I resurrected one of the managed switches from the tubs that I brought to the community and configured a trunk port and an untagged port to a vlan (vlan32) specifically for traffic between the SLATE and the ER-12.  I configured the same vlan (vlan32) on my M4100-26G switch along with a trunk port that had the same setup as the trunk port on the managed switch from my tub stores.  By connecting these up I now have the following:  SLATE LAN (vlan32) -> managed switch -[T]-> AV2000 -> AV2000 -[T]-> M4100-26G -[vlan32]-> ER-12 WAN (vlan32).

Since I can get to the managed switch within the rack from the Admin vlan, I was able to set other vlans so that I can add an RPi Gateway (ServerNet vlan/portal vlan).  This allows me to setup a firewall with open ports to the ServerNet vlan from the portal vlan which is wifi facing.  Next up is the configuration of the RPi Gateway.

HomeLabUpdate #03 - The more things stay the same, the more they change

 So here I am, a month longer into the process of updating my HomeLab, changing what I am going to do with the Proxmox server.  I have been able to add an additional 1TB SSD to the Proxmox server chassis and am now focusing in on what kinds of programs that I will be doing.  I have discovered that ZFS does indeed take a lot of memory, something that I don’t have a lot of.  I have also discovered that decent backups alleviate the need to have redundant drives that don’t contain critical information.  I have enough backups of critical information on different media that in my estimation preclude the need for redundancy like Raid1.  My critical information now resides on laptops that I backup on a regular basis and have nothing to do with the HomeLab structure in the rack.  The new 1TB SSD will become an LVM-thin component to complement the LVM-thin on the original 1TB SSD that the system resides on.  I can watch the statistics on the drives to know if they are ready to be replaced or not.  The UPS will take the shock of brownouts, spikes, and blackouts that will arrive this summer.  I have also discovered that I will not be able to force the on-board GPU to  a specific VM on the Proxmox server, so that is now off the table.

What this means is that I will be extending the current Proxmox configuration and will probably not be updating the version to 7.2.

I have decided to center on one program that I can focus my attention on and that allows me to achieve many of the goals that I have for my HomeLab.  That program will be an implementation of a Weather data gatherer focused on Docker and Node-Red.  I have already determined that I can spin up a Node-Red instance in Docker and duplicate it multiple times on the same host.  That will be the starting point for both implementing the Weather Data Gatherer and playing around with DevOps.

I recently came across some information on Microservices which seems to fit in nicely with the idea of DevOps in that you break an application down into several different parts, all communicating with each other.  It allows for spinning up new versions of the Microservice without having to stop the rest of the microservices, as well as allowing the full CI/CD chain to be implemented in development.  This should give me a software means of learning new development techniques.

HomeLabUpdate #02 - What am I going to do with the Proxmox server?

After some starts and stops with the Proxmox server, I am determined to change it to allow some additional capabilities.  I have had heat problems that were solved when I put a second fan in the case and connected it to the power supply.  The problem is I only have 360 watts coming from the power supply and I have to work within that limit.  I think I have come to the end of what I can do with a 1TB SSD drive and two 4TB drives.  I may be able to add an additional 1TB SSD drive, but that remains to be seen.  I want to maintain the motherboard and the drives at a temperature value that will not cause early failure.  I am thinking of the following:

• Add an additional 1 TB SSD drive and use ZFS for the file system for redundancy
• Move the files off of one of the 4TB drives and use ZFS for the combination 2@4TB drives for redundancy
• Setup the 4TB ZFS redundant drive to allow spill over of the LVM-thin components as well as use for general storage from the NFS server
• Update Proxmox to version 7
• Update Proxmox to use OVS as the bridging mechanism (might require addition of ifupdown2)
• Install Mac OS and Windows 10 in two different VMs
• Add an additional display card to allow iGPU passthrough for the Windows 10 VM / Ubuntu VM
• Start integrating the outside RPis with the Proxmox server

This is the short list as it stands now.  First off I want to keep things below about 60 degrees C within the cabinet and work within the 360 watt budget.  Currently, the temperature of components within the Proxmox cabinet range between 35 to 45 degrees C.

HomeLabUpdate #01 - Initial Rack Setup

 As I came into the Apartment, I had setup the rack to have (from top to bottom):

• 24 port patch panel
• Ubiquiti Edgerouter-12 Router
• Short shelf for KVM and regular switch/ER-X
  
• Netgear M4100-26g Switch
  
• Panel with 4 Raspberry Pi 4s (RPiInject, RPiCICD, RPiLDAP, RPiPlex)
  
• Panel with 4 Raspberry Pi 3Bs (RPiSecure, RPiPower3, RPiPower2, RPiPower1)
• Shelf for containing WDMyCloud drives
• Open area (2U) TBD on contents
  
• Proxmox Server (2U case)
• APC UPS (1U)

I had left 6 Ethernet cables connected, numbered #8-1 through #8-6.  When I got to the apartment, I added the GL-iNet SLATE router (in Repeater mode, without second SSID) as the input to the apartment's wifi system.  My printer is connected to the wifi system and I have connected the HA-IOT server to the back of my Acer Monitor with connections through the 4-way KVM switch.

Project #25 - Changing the HomeLab for Retirement

I need to be able to convert my HomeLab equipment for transfer to the new Retirement apartment. The equipment around the house needs to be put into a rack with extra equipment relegated to some auxiliary tubs.

NetUpdate #01 - Review of the Current State of the Network

 As I sit here, now retired, I have been going over what components my network has and how I want to continue on with this HomeLab hobby.  Whether I want to admit it or not I have decided that making changes to this network is a sort of hobby in and of itself.  I enjoy trying out new things and making changes here and there to better how I use the network.  Since I am now retired, I have time to do things that I have been putting off in the network, i.e. to completion. Currently I have a number of home network things that I want to incorporate, such as:

• Cover the entire house with wifi 
• Bring in a Kanban board to be hosted on my HomeLab, instead of relying on Trello
• Make the Kanban board accessible from the outside by incorporating a VPN into the house
• Further isolate different portions of the network that do not need to be touching each other
• Have some built in redundancy in case things go south in the network
• Work up the security on the HomeLab, including isolation of an Admin vlan for the infrastructure
• Incorporate more Raspberry Pi units into the HomeLab that are on continuously
• Get back into Home Automation
• Get into CI/CD for developing software on the HomeLab
• Go with the Zero Trust Network theme throughout (encryption becomes important now)

These items will of course take time over the next few months and years to come.  I am reasonably happy with how things have turned out so far.

Tips #10 - Network Setup for Raspberry Pi Static Experiments

After some time working with Raspberry Pis (RPi) I have been able to figure out the kind of network setup that makes sense when you develop over a period of time.  Here are some particulars of what I have found:

• Use of a Managed Switch with a trunk line to all of the vlans in the house saves a lot of running around.
• Use of Tasmota controlled extension cables can give you control of power to the RPis in case there are moments when you only want to concentrate on specific RPis for an experiment
• The managed switch on the desk where you wire up experiments gives you extra network connections when needed.
• The key is to be able to work on just what you want without having other thins on when you don’t need them to be on.