Compare commits
7 Commits
fb2eed3cce
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
| e6e8f489ae | |||
| d682e0b54f | |||
| 6921fd4b3f | |||
| 1f5b2c89e0 | |||
| fb67ebe7f5 | |||
| 052de21dd0 | |||
| 94006a45d4 |
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Blog
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Blog
|
||||
## Purpose
|
||||
Narrative posts for lessons learned, experiments, and updates.
|
||||
|
||||
@@ -7,10 +7,11 @@ authors:
|
||||
categories:
|
||||
- General
|
||||
tags:
|
||||
- Windows Server
|
||||
- Power Profiles
|
||||
- Virtualization
|
||||
- Blog
|
||||
- Hyper-V
|
||||
- Veeam
|
||||
- Windows
|
||||
- Backup
|
||||
---
|
||||
|
||||
# Windows Power Profiles Causing Notable CPU Performance Loss
|
||||
|
||||
@@ -7,11 +7,11 @@ authors:
|
||||
categories:
|
||||
- General
|
||||
tags:
|
||||
- Infrastructure as Code
|
||||
- Gitea Act Runners
|
||||
- Blog
|
||||
- Containers
|
||||
- Docker
|
||||
- GitOps
|
||||
- CI/CD
|
||||
- Portainer
|
||||
- Ansible
|
||||
---
|
||||
|
||||
# Learning to Leverage Gitea Runners
|
||||
|
||||
@@ -8,7 +8,9 @@ categories:
|
||||
- General
|
||||
- Documentation
|
||||
tags:
|
||||
- MKDocs
|
||||
- Blog
|
||||
- Rocket.Chat
|
||||
- MkDocs
|
||||
- Material MkDocs
|
||||
- Documentation
|
||||
---
|
||||
|
||||
@@ -11,7 +11,10 @@ categories:
|
||||
- Virtualization
|
||||
- Containers
|
||||
tags:
|
||||
- Blog
|
||||
- OpenStack
|
||||
- Hyper-V
|
||||
- Containers
|
||||
- Ansible
|
||||
---
|
||||
|
||||
|
||||
2
index.md
2
index.md
@@ -1,6 +1,6 @@
|
||||
# Home
|
||||
## Homelab Documentation Structure
|
||||
This documentation details the design, setup, and day-to-day management of my homelab environment. The goal is to keep it deterministic, CLI-first, and easy to audit or reproduce.
|
||||
This documentation details the design, setup, and day-to-day management of my homelab environment. The goal is to keep it deterministic, CLI-first, and easy to audit or reproduce. Some of the decisions made may not involve using the best security practices. Use your own discretion when following this documentation.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Disk Arrays
|
||||
- Storage
|
||||
- Hardware
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document is meant to help keep track disks and their associated serial numbers for replacement and recordkeeping purposes.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Disk Arrays
|
||||
- Storage
|
||||
- Hardware
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document is meant to help keep track disks and their associated serial numbers for replacement and recordkeeping purposes.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Disk Arrays
|
||||
- Storage
|
||||
- Hardware
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document is meant to help keep track disks and their associated serial numbers for replacement and recordkeeping purposes.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Infrastructure
|
||||
- Hardware
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Hardware
|
||||
## Purpose
|
||||
Physical assets, node inventories, storage layouts, and power topology for the lab.
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- TrueNAS
|
||||
- Disk Arrays
|
||||
- Storage
|
||||
- Hardware
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document is meant to help keep track disks and their associated serial numbers for replacement and recordkeeping purposes.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- TrueNAS
|
||||
- Storage
|
||||
- Hardware
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document acts as a workflow to understand how to replace a drive on TrueNAS Core when it is hosted on an HPE Proliant server with HBA / IT Mode enabled. This enables you to hot-swap drives without rebooting TrueNAS Core.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- TrueNAS
|
||||
- Disk Arrays
|
||||
- Storage
|
||||
- Hardware
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document is meant to help keep track disks and their associated serial numbers for replacement and recordkeeping purposes.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- UniFi
|
||||
- Networking
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: The UniFi® Controller is a wireless network management software solution from Ubiquiti Networks™. It allows you to manage multiple wireless networks using a web browser.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- UniFi
|
||||
- Networking
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
If you need to deploy Unifi Controller bare-metal into a virtual machine, you can do so with a few simple commands. You can feel free to reference the [original documentation](https://help.ui.com/hc/en-us/articles/220066768-Updating-and-Installing-Self-Hosted-UniFi-Network-Servers-Linux) if additional clarity is needed.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Docker
|
||||
- Macvlan
|
||||
- Networking
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
You may find that you only have one network adapter on a server / VM and need to have multiple virtual networks associated with it. For example, Home Assistant exists on the `192.168.3.0/24` network but it needs to also access devices on the `192.168.4.0/24` surveillance network. To facilitate this, we will make a MACVLAN Sub-Interface. This will make a virtual interface that is parented to the actual physical interface.
|
||||
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Docker
|
||||
- Networking
|
||||
---
|
||||
|
||||
### Configure Docker Network
|
||||
We want to use a dedicated subnet / network specifically for containers, so they don't trample over the **SERVER** and **LAN** networks. If you are unsure of the name of the network adapter, in this case `eth0`, just type `ipaddr` in the terminal to list the network interfaces to locate it.
|
||||
```
|
||||
|
||||
@@ -1,3 +1,12 @@
|
||||
---
|
||||
tags:
|
||||
- Sophos
|
||||
- Firewall
|
||||
- Routing
|
||||
- LAN
|
||||
- Networking
|
||||
---
|
||||
|
||||
**Purpose**: You may have a Sophos XGS appliance and need more than one interface to act as additional LAN ports. You can achieve this with bridges.
|
||||
|
||||
!!! info "Assumptions"
|
||||
|
||||
@@ -1,3 +1,12 @@
|
||||
---
|
||||
tags:
|
||||
- Sophos
|
||||
- IPsec
|
||||
- VPN
|
||||
- Firewall
|
||||
- Routing
|
||||
---
|
||||
|
||||
**Purpose**: Generally speaking, when you have site-to-site VPN tunnels, you have to ensure that the *health* of the tunnel is operating as-expected. Sometimes VPN tunnels will report that they are online and connected, but in reality, no traffic is flowing to the remote side of the tunnel. In these instances, we can create a script that pings a device on the remote end, and if it does not respond in a timely manner, the script restart the VPN tunnel automatically.
|
||||
|
||||
!!! note "Assumptions"
|
||||
|
||||
@@ -1,3 +1,12 @@
|
||||
---
|
||||
tags:
|
||||
- Sophos
|
||||
- IPsec
|
||||
- VPN
|
||||
- Firewall
|
||||
- Routing
|
||||
---
|
||||
|
||||
**Purpose**: You may have two Sophos XGS appliances (or a mixed configuration) and need to set up a site-to-site VPN tunnel between two remote locations. You can achieve this with a simple passphrase-based IPSec VPN tunnel.
|
||||
|
||||
!!! info "Assumptions"
|
||||
|
||||
@@ -1,3 +1,12 @@
|
||||
---
|
||||
tags:
|
||||
- Sophos
|
||||
- RDP
|
||||
- SSL VPN
|
||||
- VPN
|
||||
- Firewall
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document exists to outline the generalized process to configuring remote access in a Sophos XGS Firewall to allow a VPN user to RDP into a workstation. *Setting up Remote SSL VPN Access is not covered in this document.*
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Infrastructure
|
||||
- Networking
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Networking
|
||||
## Purpose
|
||||
Network topology, addressing, firewalling, VPN, and network service dependencies.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Sophos
|
||||
- iptables
|
||||
- Networking
|
||||
---
|
||||
|
||||
### IP Addresses
|
||||
Documented IP addresses of Hyper-V Failover Cluster VMs that exist behind the Sophos XG Firewall VM. All of these machines are funneled through the Sophos XG Firewall VM before they are allowed to communicate on the physical network with other devices.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Containers
|
||||
- iptables
|
||||
- Networking
|
||||
---
|
||||
|
||||
### IP Addresses
|
||||
Documented IP addresses of containers.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- iptables
|
||||
- Networking
|
||||
- Docker
|
||||
---
|
||||
|
||||
## Overview
|
||||
All servers (physical and virtual) are documented within this specific page. They are written in a specific annotated manner in order to make them copy/paste ready for the Ansible AWX Operator server that interacts with devices in the homelab over `SSH` and `WinRM` protocols. This allows me to automate functions such as updates across the entire homelab declaratively versus individually.
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Linux
|
||||
- Networking
|
||||
---
|
||||
|
||||
**Purpose**: This is a scaffold document outlining the high level of changing an IP address of a server in either Debian or RHEL based operating systems.
|
||||
|
||||
=== "Ubuntu / Debian"
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Tuya
|
||||
- Networking
|
||||
---
|
||||
|
||||
### pfSense DHCP Reservations for Tuya-Based Smart Devices
|
||||
| **Description** | **IP Address** | **MAC Address** | **Hostname** | **Device ID** | **Local Key** |
|
||||
| :--- | :--- | :--- | :--- | :--- | :--- |
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- NetBird
|
||||
- VPN
|
||||
- Networking
|
||||
- Docker
|
||||
---
|
||||
|
||||
## Purpose
|
||||
Netbird is a free and open-source VPN server and client platform. The following document will illustrate how to deploy Netbird into a homelab or business environment.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- AWX
|
||||
- Kerberos
|
||||
- Automation
|
||||
---
|
||||
|
||||
## Kerberos Implementation
|
||||
You may find that you need to be able to run playbooks on domain-joined Windows devices using Kerberos. You need to go through some extra steps to set this up after you have successfully fully deployed AWX Operator into Kubernetes.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- AWX
|
||||
- Gitea
|
||||
- Automation
|
||||
---
|
||||
|
||||
**Purpose**: Once AWX is deployed, you will want to connect Gitea at https://git.bunny-lab.io. The reason for this is so we can pull in our playbooks, inventories, and templates automatically into AWX, making it more stateless overall and more resilient to potential failures of either AWX or the underlying Kubernetes Cluster hosting it.
|
||||
|
||||
## Obtain Gitea Token
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- AWX
|
||||
- Automation
|
||||
---
|
||||
|
||||
# Deploy AWX on Minikube Cluster
|
||||
Minikube Cluster based deployment of Ansible AWX. (Ansible Tower)
|
||||
!!! note Prerequisites
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- AWX
|
||||
- Automation
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Deploying a Rancher RKE2 Cluster-based Ansible AWX Operator server. This can scale to a larger more enterprise environment if needed.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- AWX
|
||||
- Automation
|
||||
---
|
||||
|
||||
## Upgrading from 2.10.0 to 2.19.1+
|
||||
There is a known issue with upgrading / install AWX Operator beyond version 2.10.0, because of how the PostgreSQL database upgrades from 13.0 to 15.0, and has changed permissions. The following workflow will help get past that and adjust the permissions in such a way that allows the upgrade to proceed successfully. If this is a clean installation, you can also perform this step if the fresh install of 2.19.1 is not working yet. (It wont work out of the box because of this bug). `The developers of AWX seem to just not care about this issue, and have not implemented an official fix themselves at this time).
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- WinRM
|
||||
- Automation
|
||||
---
|
||||
|
||||
# WinRM (Kerberos)
|
||||
**Name**: "Kerberos WinRM"
|
||||
|
||||
|
||||
@@ -1,6 +1,10 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
tags:
|
||||
- Ansible
|
||||
- Automation
|
||||
---
|
||||
|
||||
# AWX Credential Types
|
||||
When interacting with devices via Ansible Playbooks, you need to provide the playbook with credentials to connect to the device with. Examples are domain credentials for Windows devices, and local sudo user credentials for Linux.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- WinRM
|
||||
- Windows
|
||||
- Automation
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
You will need to enable secure WinRM management of the Windows devices you are running playbooks against, as compared to the Linux devices. The following powershell script needs to be ran on every Windows device you intend to run Ansible playbooks on. This script can also be useful for simply enabling / resetting WinRM configurations for Hyper-V hosts in general, just omit the Powershell script remote signing section if you dont plan on using it for Ansible.
|
||||
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- Automation
|
||||
---
|
||||
|
||||
# Host Inventories
|
||||
When you are deploying playbooks, you target hosts that exist in "Inventories". These inventories consist of a list of hosts and their corresponding IP addresses, as well as any host-specific variables that may be necessary to declare to run the playbook. You can see an example inventory file below.
|
||||
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- Automation
|
||||
---
|
||||
|
||||
!!! warning "DOCUMENT UNDER CONSTRUCTION"
|
||||
This document is a "scaffold" document. It is missing significant portions of several sections and should not be read with any scrutiny until it is more feature-complete down-the-road. Come back later and I should have added more to this document hopefully by then.
|
||||
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- Automation
|
||||
---
|
||||
|
||||
# AWX Projects
|
||||
When you want to run playbooks on host devices in your inventory files, you need to host the playbooks in a "Project". Projects can be as simple as a connection to Gitea/Github to store playbooks in a repository.
|
||||
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- Automation
|
||||
---
|
||||
|
||||
# Templates
|
||||
Templates are basically pre-constructed groups of devices, playbooks, and credentials that perform a specific kind of task against a predefined group of hosts or device inventory.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Operations
|
||||
- Automation
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Automation
|
||||
## Purpose
|
||||
Infrastructure automation, orchestration, and workflow tooling.
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Puppet
|
||||
- Automation
|
||||
---
|
||||
|
||||
**Purpose**: Puppet Bolt can be leveraged in an Ansible-esque manner to connect to and enroll devices such as Windows Servers, Linux Servers, and various workstations. To this end, it could be used to run ad-hoc tasks or enroll devices into a centralized Puppet server. (e.g. `LAB-PUPPET-01.bunny-lab.io`)
|
||||
|
||||
!!! note "Assumptions"
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Puppet
|
||||
- Automation
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Puppet is another declarative configuration management tool that excels in system configuration and enforcement. Like Ansible, it's designed to maintain the desired state of a system's configuration but uses a client-server (master-agent) architecture by default.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
**Purpose**: You may find that you need to adopt a device that was onboarded by a different Veeam Backup & Replication server. Maybe the old server died, or maybe you are restructuring your backup infrastructure, and want a new server taking over the backup responsibilities for the device.
|
||||
|
||||
If this happens, Veeam will complain that the device is managed by a different server. To circumvent this, perform the following changes in the Windows Registry based on the version of Veeam Backup & Replication you are currently using, then try to Update the Agent / Backup the agent again, and it should be successful after the registry changes are made.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
The purpose of this document is to explain the core concepts / terminology of things seen in Veeam Backup & Replication from a relatively high-level. It's more of a quick-reference guide than a formal education.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
There may come a time that you need to free up space in a Veeam Backup & Replication backup repository because you are running out of space. In these cases, you need to manually trim the older backups in a specific way to ensure this is non-destructive.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Proxmox
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
When you migrate virtual machines from Hyper-V (and possibly other platforms) to ProxmoxVE, you may run into several issues, from the disk formats being in `.raw` format instead of `.qcow2`, among other things. One thing in particular, which is the reason for this document, is that if you migrate Rocky Linux from Hyper-V into ProxmoxVE using Veeam Backup & Replication, it will break the storage system so badly that the operating system will not boot.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
## Purpose
|
||||
If you find that you need to migrate cloud backups that are being sent to a server running the Veeam VSCP due to issues like exhausted storage space on existing repositories.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
This is meant as a high-level generally-speaking best practice retention policy in most use-cases. This document will generally be pretty bare-bones, but the general idea is the following advanced GFS retention period is generally configured on backup copy jobs, specifically ones that have off-site backups, but can also be used for local backup repositories.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
### Symptoms
|
||||
When you try to run a backup to a remote backup server, the backup job fails and gives the following error:
|
||||
|
||||
|
||||
@@ -1,12 +1,21 @@
|
||||
---
|
||||
tags:
|
||||
- Documentation
|
||||
- Markdown
|
||||
- Style Guide
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document defines the **authoritative documentation style contract** used throughout the Bunny Lab homelab documentation.
|
||||
|
||||
It is intended to be provided to:
|
||||
|
||||
- AI assistants
|
||||
- Automation tools
|
||||
- Contributors
|
||||
|
||||
The goal is to ensure all documentation is:
|
||||
|
||||
- Technically precise
|
||||
- CLI-first
|
||||
- Easy to audit
|
||||
@@ -15,6 +24,7 @@ The goal is to ensure all documentation is:
|
||||
---
|
||||
|
||||
## General Writing Principles
|
||||
|
||||
- Write for experienced operators, not beginners
|
||||
- Prefer **explicit commands** over descriptive prose
|
||||
- Avoid narrative filler
|
||||
@@ -24,6 +34,7 @@ The goal is to ensure all documentation is:
|
||||
|
||||
## Document Flow and Structure
|
||||
Documentation is written with the assumption that the reader:
|
||||
|
||||
- Reads **top to bottom**
|
||||
- Executes actions within the **current section**
|
||||
- Does not require explicit step numbering
|
||||
@@ -35,11 +46,13 @@ Ordering is implicit and intentional.
|
||||
|
||||
## Core Sections (Recommended)
|
||||
Most documents should include, at minimum:
|
||||
|
||||
- **Purpose** (why this doc exists)
|
||||
- **Assumptions** (platform, privileges, prerequisites)
|
||||
- **Procedure** (commands and configuration)
|
||||
|
||||
Include these when applicable:
|
||||
|
||||
- **Architectural Overview** (diagram or flow)
|
||||
- **Validation** (explicit checks with expected output)
|
||||
- **Troubleshooting** → **Symptoms** / **Resolution**
|
||||
@@ -47,6 +60,7 @@ Include these when applicable:
|
||||
---
|
||||
|
||||
## Headings
|
||||
|
||||
- `#` — Document title (one per document)
|
||||
- `##` — Major logical phases or topics
|
||||
- `###` — Subsections only when needed
|
||||
@@ -61,6 +75,7 @@ Avoid over-fragmentation.
|
||||
Admonitions are **intentional and sparse**, not decorative.
|
||||
|
||||
Use them to:
|
||||
|
||||
- Highlight irreversible actions
|
||||
- Call out one-time decisions
|
||||
- Enforce safety boundaries
|
||||
@@ -81,6 +96,7 @@ Do **not** restate obvious information inside admonitions.
|
||||
Code blocks are the **primary instructional vehicle**.
|
||||
|
||||
### Rules
|
||||
|
||||
- Always fenced
|
||||
- Always copy/paste-ready
|
||||
- Prefer fewer, larger blocks over many small ones
|
||||
@@ -98,6 +114,7 @@ Avoid explanatory prose between every command.
|
||||
---
|
||||
|
||||
## Shell Fencing
|
||||
|
||||
- Use ```sh for shell commands
|
||||
- Use ``` for diagrams or pseudo-structure
|
||||
- Do not mix command output with commands unless explicitly labeled
|
||||
@@ -106,6 +123,7 @@ Avoid explanatory prose between every command.
|
||||
|
||||
## Inline Code
|
||||
Use backticks for:
|
||||
|
||||
- Dataset names
|
||||
- Volume groups
|
||||
- Filenames
|
||||
@@ -118,6 +136,7 @@ Example:
|
||||
---
|
||||
|
||||
## Lists
|
||||
|
||||
- Use bullet lists for inventories, criteria, and checks
|
||||
- Avoid numbered lists for procedures
|
||||
- Ordering is conveyed by section layout, not numbering
|
||||
@@ -125,6 +144,7 @@ Example:
|
||||
---
|
||||
|
||||
## Diagrams
|
||||
|
||||
- ASCII diagrams only
|
||||
- Used to describe hierarchy or flow
|
||||
- Must reinforce understanding, not decorate
|
||||
@@ -133,6 +153,7 @@ Example:
|
||||
|
||||
## Validation Sections
|
||||
Validation is **mandatory** for any procedure that affects:
|
||||
|
||||
- Storage
|
||||
- Networking
|
||||
- Virtualization
|
||||
@@ -145,12 +166,14 @@ For lower-risk or informational documents, validation is optional.
|
||||
---
|
||||
|
||||
## Tone and Voice
|
||||
|
||||
- Neutral
|
||||
- Operational
|
||||
- Conservative
|
||||
- “Boring is correct”
|
||||
|
||||
Avoid:
|
||||
|
||||
- Marketing language
|
||||
- Storytelling
|
||||
- Over-explanation
|
||||
@@ -158,6 +181,7 @@ Avoid:
|
||||
---
|
||||
|
||||
## Anti-Patterns (Do Not Use)
|
||||
|
||||
- Numbered procedural steps
|
||||
- GUI-only workflows when CLI exists
|
||||
- Excessive screenshots
|
||||
@@ -169,6 +193,7 @@ Avoid:
|
||||
|
||||
## Summary
|
||||
Bunny Lab documentation prioritizes:
|
||||
|
||||
- Determinism
|
||||
- Safety
|
||||
- Reproducibility
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Operations
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Foundations
|
||||
## Purpose
|
||||
Defines the baseline documentation standards, shared references, and structural conventions used everywhere else in this knowledgebase.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Documentation
|
||||
- Templates
|
||||
- Markdown
|
||||
---
|
||||
|
||||
**Purpose**: PLACEHOLDER
|
||||
|
||||
## Docker Configuration
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- iLO
|
||||
- Hardware
|
||||
- Licensing
|
||||
---
|
||||
|
||||
!!! info "Assumptions of Usage"
|
||||
It should go without saying, using one of these keys does not entitle you to support by Hewlett-Packard Enterprise. These are meant for homelab environments where licensing / auditing does not matter.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Operations
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Operations
|
||||
## Purpose
|
||||
Runbooks for maintenance, troubleshooting, backups, and day-2 operations.
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- ZFS
|
||||
- iSCSI
|
||||
- Linux
|
||||
- Filesystems
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
The purpose of this workflow is to illustrate the process of expanding storage for a Linux server that uses an iSCSI-based ZFS storage. We want the VM to have more storage space, so this document will go over the steps to expand that usable space.
|
||||
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Linux
|
||||
- Filesystems
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
The purpose of this workflow is to illustrate the process of expanding storage for a RHEL-based Linux server acting as a GuestVM. We want the VM to have more storage space, so this document will go over the steps to expand that usable space.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Fedora
|
||||
- Linux
|
||||
- Workstation
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
This document serves as a general guideline for my workstation deployment process when working with Fedora Workstation 41 and up. This document will constantly evolve over time based on my needs.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Fedora
|
||||
- Linux
|
||||
- Desktop Environment
|
||||
- Workstation
|
||||
---
|
||||
|
||||
## Purpose
|
||||
You may find that you need to install an XFCE desktop environment or something into Fedora Server, if this is the case, for installing something like Rustdesk remote access, you can follow the steps below.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Fedora
|
||||
- Linux
|
||||
- Flatpak
|
||||
- Workstation
|
||||
---
|
||||
|
||||
## Purpose
|
||||
You may need to install flatpak packages like Signal in your workstation environment. If you need to do this, you only need to run a few commands.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Fedora
|
||||
- Linux
|
||||
- Workstation
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
If you want to upgrade Fedora Workstation to a new version (e.g. 41 --> 42) you can run the following commands to do so. The overall process is fairly straightforward and requires a reboot.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- UPS
|
||||
- APC
|
||||
- Power
|
||||
---
|
||||
|
||||
**Purpose**: When an APC battery backup's battery dies, you can manually replace the cells and 'refurbish' the battery. The following diagram is how you rewire the cells.
|
||||
|
||||
!!! warning "Work in Progress"
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- UPS
|
||||
- Backup
|
||||
- Power
|
||||
---
|
||||
|
||||
| **Battery Backup** | **Status** | **Connected Device(s)** | **Estimated Runtime** | **Shutdown Threshold** | **UPS Web Management** |
|
||||
| :--- | :--- | :--- | :--- | :--- | :---: |
|
||||
| Outer-Left `#1` | /uptimes/7d/badge.svg) | - VIRT-NODE-01<br>- 10-Port 10GbE Network Switch<br>- pfSense Firewall | 10 Minutes | 3 Minutes Remaining | [:fontawesome-solid-car-battery: Manage](http://192.168.3.4:3052){ .md-button } |
|
||||
|
||||
@@ -1,3 +1,12 @@
|
||||
---
|
||||
tags:
|
||||
- SSH
|
||||
- Bash
|
||||
- Authentication
|
||||
- Scripting
|
||||
- Linux
|
||||
---
|
||||
|
||||
*Purpose*: Sometimes you need two linux computers to be able to talk to eachother without requiring a password. Passwordless SSH can be achieved by running the following commands:
|
||||
|
||||
!!! note "Non-Root Key Storage Considerations"
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Linux
|
||||
- Bash
|
||||
- Scripting
|
||||
---
|
||||
|
||||
``` sh
|
||||
xrandr --auto
|
||||
xrandr --setprovideroutputsource 4 0
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Bash
|
||||
- Scripting
|
||||
- Linux
|
||||
---
|
||||
|
||||
# Git Repo Updater (Script)
|
||||
## Purpose
|
||||
Standalone `repo_watcher.sh` script used by the Git Repo Updater container. This script clones or pulls one or more repositories and rsyncs them into destination paths.
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Bash
|
||||
- QEMU
|
||||
- Scripting
|
||||
- Linux
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
You may need to install the QEMU guest agent on linux VMs manually, while Windows-based devices work out-of-the-box after installing the VirtIO guest tools installer.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- XRDP
|
||||
- Bash
|
||||
- Scripting
|
||||
- Linux
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
If you need to set up RDP access to a Linux environment, you will want to install XRDP. Once it is installed, you can leverage other tools such as Apache Guacamole to remotely connect to it.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- RAID
|
||||
- Bash
|
||||
- Scripting
|
||||
- Linux
|
||||
---
|
||||
|
||||
https://www.digitalocean.com/community/tutorials/how-to-create-raid-arrays-with-mdadm-on-ubuntu-16-04
|
||||
``` sh
|
||||
sudo mdadm --grow /dev/md0 -l 5
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Bash
|
||||
- Ports
|
||||
- Scripting
|
||||
- Linux
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
If you want to check if a certain TCP port is open on a server.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Proxmox
|
||||
- Bash
|
||||
- Scripting
|
||||
- Linux
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This script is ran via cronjob on `cluster-node-02` at midnight to rollback the deeplab environment automatically to a previous snapshot nightly.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Bash
|
||||
- Time Sync
|
||||
- Scripting
|
||||
- Linux
|
||||
---
|
||||
|
||||
The commands outlined in this short document are meant to be a quick-reference for setting the timezone and date/time of a Linux-based server.
|
||||
|
||||
### Set Timezone:
|
||||
|
||||
@@ -1,3 +1,12 @@
|
||||
---
|
||||
tags:
|
||||
- Containers
|
||||
- Docker
|
||||
- Bash
|
||||
- Scripting
|
||||
- Linux
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
If you find that you need to migrate a container, along with any supporting files, permissions, etc from an old server to a new server, rsync helps make this as painless as possible.
|
||||
Be sure to perform the following steps to make sure that you can copy the container's files.
|
||||
|
||||
@@ -1,3 +1,12 @@
|
||||
---
|
||||
tags:
|
||||
- Bash
|
||||
- Netcat
|
||||
- File Transfer
|
||||
- Scripting
|
||||
- Linux
|
||||
---
|
||||
|
||||
**Purpose**: You may find that you need to transfer a file, such as a public SSH key, or some other kind of file between two devices. In this scenario, we assume both devices have the `netcat` command available to them. By putting a network listener on the device recieving the file, then sending the file to that device's IP and port, you can successfully transfer data between computers without needing to set up SSH, FTP, or anything else to establish initial trust between the devices. [Original Reference Material](https://www.youtube.com/shorts/1j17UBGqSog).
|
||||
|
||||
!!! warning
|
||||
|
||||
@@ -1,3 +1,12 @@
|
||||
---
|
||||
tags:
|
||||
- Blue Iris
|
||||
- Batch
|
||||
- Monitoring
|
||||
- Scripting
|
||||
- Windows
|
||||
---
|
||||
|
||||
``` batch
|
||||
@echo off
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Robocopy
|
||||
- Batch
|
||||
- Scripting
|
||||
- Windows
|
||||
---
|
||||
|
||||
Robocopy is a useful tool that can be leveraged to copy files and folders from one location to another (e.g. Over the network to another server) without losing file and folder ACLs (permissions / ownership data).
|
||||
|
||||
!!! warning "Run as Domain Admin"
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Operations
|
||||
- Reference
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Reference
|
||||
## Purpose
|
||||
Quick-use scripts and snippets for day-to-day operations.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Email
|
||||
- Scripting
|
||||
---
|
||||
|
||||
!!! info "Prerequesite: [Connect to Azure AD](./connect-to-azure-ad.md)"
|
||||
|
||||
The uppercase `SMTP` address is the primary address, while lowercase `smtp` are aliases. You can find the value in active directory in **"User > Attribute Editor > proxyAddresses"**.
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**: Sometimes you will need to connect to Azure AD via powershell in order to perform troubleshooting / automation.
|
||||
|
||||
## Update Nuget Package Manager
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Exchange Online
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**: Sometimes you will need to connect to Office365 via powershell in order to perform troubleshooting / automation that either is too complex to do via the website, or is not exposed / possible to do via the website.
|
||||
|
||||
## Update Nuget Package Manager
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Sometimes you just need a basic script that outputs a pretty directory and file tree. This script offers files and folders to ignore, and outputs a fancy directory tree.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- DNS
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
## Purpose
|
||||
When it comes to best-practices with Windows-based DNS servers, you never want to have `127.0.0.1` or the IP of the server itself as the primary DNS server, you want to have a *different* DNS server as primary, and `127.0.0.1` as the secondary or tertiary DNS server instead.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- File Management
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Locate specific files, and copy them with a renamed datestamp appended to a specific directory.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Windows
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
## Purpose
|
||||
Sometimes when you try to run Windows Updates, you may run into issues where updates just fail to install for seemingly nebulous reasons. You can run the following commands (in order) to try to resolve the issue.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Group Policy
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
``` powershell
|
||||
$computers = Get-ADComputer -Filter * -SearchBase "OU=Computers,DC=bunny-lab,DC=io"
|
||||
$computers | ForEach-Object -Process {Invoke-GPUpdate -Computer $_.name -RandomDelayInMinutes 0 -Force}
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This script is designed to iterate over every computer device within an Active Directory Domain. It then reaches out to those devices over the network and iterates upon every local user profile on those devices, and using CIM, determines which profiles have not been logged into in X number of days. If executed in a non-dry-run nature, it will then delete those profiles (*this does not delete local or domain users, it just cleans up their local profile data on the workstation*).
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Rclone
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
Rclone is a command-line program to manage files on cloud storage. It is a feature-rich alternative to cloud vendors' web storage interfaces. Over 70 cloud storage products support rclone including S3 object stores, business & consumer file storage services, as well as standard transfer protocols.
|
||||
|
||||
!!! warning "Be Mindful of Sync Type"
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Sometimes you need to restart a service across every computer in an Active Directory Domain. This powershell script will restart a specific service by name domain-wide. Each device will be processed in a serialized nature, one-by-one.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Windows 11
|
||||
- Windows
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
You may need to upgrade a device to Windows 11 using an ISO stored on a UNC Network Share, the script below handles that.
|
||||
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
## Purpose
|
||||
Sometimes things go awry with backup servers and Hyper-V and a bunch of extra `.avhdx` virtual differencing disks are created, taking up a ton of space. This can be problematic because if you run out of space, the virtual machines running on that underlying storage will stop working. Sometimes this can involve dozens or even hundreds of differencing disks in rare cases that need to be manually merged or "collapsed" down to reclaim the lost space.
|
||||
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
You may find that you cannot delete a VHDX file for a virtual machine you removed from Hyper-V and/or Hyper-V Failover Cluster, and either cannot afford to, or do not want to reboot your virtualization host(s) to unlock the file locked by `SYSTEM`.
|
||||
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**: Sometimes a Hyper-V Failover Cluster node does not want to shut down, or is having issues preventing you from migrating VMs to another node in the cluster, etc. In these situations, you can run this script to force a cluster node to reboot itself.
|
||||
|
||||
!!! warning "Run from a Different Server"
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
This script *bumps* any replication that has entered a paused state due to a replication error. The script will record failed attempts at restarting the replication. The logs will rotate out every 5-days.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Minecraft
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**: This script was purpose-built for the homelab Minecraft servers in my homelab. It may need to be ported based on your own needs.
|
||||
|
||||
```powershell
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Nextcloud
|
||||
- PowerShell
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**: In some unique cases, you want to be able to either perform backups of data or exfiltrate data to Nextcloud from a local device via the use of a script. Doing such a thing with Nextcloud as the destination is not very documented, but you can achieve that result by running a script like what is seen below:
|
||||
|
||||
## Windows
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Reporting
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Sometimes you need a report of every user in a domain, and if/when their passwords will expire. This one-liner command will help automate that reporting.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Reporting
|
||||
- Scripting
|
||||
---
|
||||
|
||||
``` powershell
|
||||
$DaysInactive = 30
|
||||
$time = (Get-Date).Adddays(-($DaysInactive))
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- PowerShell
|
||||
- Reporting
|
||||
- Scripting
|
||||
---
|
||||
|
||||
``` powershell
|
||||
InactiveDays = 30
|
||||
$Days = (Get-Date).Adddays(-($InactiveDays))
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- SMB
|
||||
- PowerShell
|
||||
- Permissions
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
This script will iterate over all network shares hosted by the computer it is running on, and will give *recursive* permissions to all folders, subfolders, and files, including hidden ones. It is very I/O intensive given it iterates recursively on every file/folder being shared.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- SMB
|
||||
- PowerShell
|
||||
- Permissions
|
||||
- Scripting
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
This script will iterate over all network shares hosted by the computer it is running on, and will give *top-level* permissions to all the shared folders. It will not navigate deeper than the top-level in its report. Very I/O friendly.
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user