KitsNet - User contributions [en]

KitsNet Operations:Services:LDAP:Authentication Troubleshooting

2026-09-27T18:22:35Z

Psmode:

KitsNet applications such as MediaWiki and Grafana authenticate users against the KNADA Active Directory domain using LDAP/LDAPS.
A failed login does ‘’‘not’’’ necessarily indicate an LDAP server, TLS, CA, or application configuration problem. In particular, an expired KNADA user password may be presented by applications only as a generic authentication failure.
=== Recommended Diagnostic Order ===
When one or more LDAP-authenticated applications reject a user’s credentials, use the following sequence before changing application configuration.
==== Check the affected KNADA user account ====
On a Samba AD domain controller, such as frangelico:
<syntaxhighlight lang="bash">
sudo samba-tool user show USERNAME
</syntaxhighlight>
Review the account state and password information for indications that the password has expired or that the account is otherwise restricted.
==== Test the user’s password directly over LDAPS ====
From a system with the KNADA CA installed:
<syntaxhighlight lang="bash">
ldapwhoami \
-x \
-H ldaps://frangelico.knada.lan.kitsnet.us:636 \
-D 'USERNAME@knada.lan.kitsnet.us' \
-W
</syntaxhighlight>
A successful authentication returns the authenticated LDAP identity.
If this fails, do not immediately assume that TLS or LDAP connectivity is broken. Check the user’s password expiration and account state first.
==== Test Kerberos authentication ====
A direct Kerberos test provides an additional check of the user’s KNADA credential:
<syntaxhighlight lang="bash">
kdestroy 2>/dev/null || true
kinit USERNAME@KNADA.LAN.KITSNET.US
klist
</syntaxhighlight>
A successful kinit followed by a valid TGT in klist confirms that the user’s password is accepted by Active Directory.
==== Verify application service-account LDAP access ====
Applications normally use a service account to search Active Directory before authenticating the individual user.
For the Wiki, the service account is:
<syntaxhighlight lang="text">
CN=svc-wiki-ldap,CN=Users,DC=knada,DC=lan,DC=kitsnet,DC=us
</syntaxhighlight>
Verify that the application service account can:
establish an LDAPS connection;
validate the KNADA server certificate;
bind successfully;
search the KNADA directory.
A successful service-account bind proves that the application’s LDAP infrastructure is substantially healthy, but it does ‘’‘not’’’ prove that an individual user’s password is valid.
==== Verify TLS and CA trust only if necessary ====
The current KNADA LDAP CA is:
<syntaxhighlight lang="text">
O=KitsNet
OU=KNADA LDAP
CN=KitsNet KNADA LDAP CA 2026
</syntaxhighlight>
SHA-256 fingerprint:
<syntaxhighlight lang="text">
A1:26:57:8E:37:05:52:65:2E:26:7E:48:B0:66:7A:5D:04:4F:C8:BB:A3:4E:E8:B7:12:97:A1:3F:A3:28:15:4F
</syntaxhighlight>
The application-specific CA bundle used by Wiki and other Swarm services contains three certificates:
Historical Frangelico Samba-generated CA
Historical Emperador Samba-generated CA
Current KitsNet KNADA LDAP CA 2026
When inspecting a multi-certificate PEM bundle, note that:
<syntaxhighlight lang="bash">
openssl x509 -in bundle.pem -noout -subject -issuer
</syntaxhighlight>
displays only the ‘’‘first certificate’’’ in the file.
Do not conclude that the bundle lacks the current CA based solely on that command. Split or enumerate all certificates in the bundle before diagnosing it as stale.
=== September 2026 Incident ===
In September 2026, KNADA authentication failed simultaneously in MediaWiki and Grafana.
Initial investigation verified:
IPv4 and IPv6 connectivity to both KNADA domain controllers;
LDAP and LDAPS availability;
successful TLS certificate validation;
correct application CA bundles;
successful Wiki service-account binds to both Frangelico and Emperador;
successful LDAP directory searches from the running Wiki container.
The actual cause was that the affected user’s KNADA password had expired.
Neither MediaWiki nor Grafana clearly reported the password-expired condition to the user. Both presented the condition as a generic login/authentication failure.
This incident established the following troubleshooting rule:
‘’‘When multiple LDAP-authenticated applications reject the same user’s otherwise known-good credentials, check that user’s AD password/account state before changing LDAP, TLS, CA, or application configuration.’’’
=== Host CA Trust Note ===
During the same investigation, it was discovered that several Rocky Linux systems did not have the current KNADA LDAP CA installed in their system trust store.
This was corrected separately through the KitsNet Ansible CA-distribution process.
That host-trust issue was a valid configuration defect, but it was ‘’‘not’’’ the cause of the MediaWiki and Grafana login failures in this incident because those applications already used their own correct KNADA CA bundles.

[[Category:LDAP]]

KitsNet Operations:Services:LDAP:Authentication Troubleshooting

2026-09-27T18:22:16Z

Psmode:

== LDAP Authentication Troubleshooting ==
KitsNet applications such as MediaWiki and Grafana authenticate users against the KNADA Active Directory domain using LDAP/LDAPS.
A failed login does ‘’‘not’’’ necessarily indicate an LDAP server, TLS, CA, or application configuration problem. In particular, an expired KNADA user password may be presented by applications only as a generic authentication failure.
=== Recommended Diagnostic Order ===
When one or more LDAP-authenticated applications reject a user’s credentials, use the following sequence before changing application configuration.
==== Check the affected KNADA user account ====
On a Samba AD domain controller, such as frangelico:
<syntaxhighlight lang="bash">
sudo samba-tool user show USERNAME
</syntaxhighlight>
Review the account state and password information for indications that the password has expired or that the account is otherwise restricted.
==== Test the user’s password directly over LDAPS ====
From a system with the KNADA CA installed:
<syntaxhighlight lang="bash">
ldapwhoami \
-x \
-H ldaps://frangelico.knada.lan.kitsnet.us:636 \
-D 'USERNAME@knada.lan.kitsnet.us' \
-W
</syntaxhighlight>
A successful authentication returns the authenticated LDAP identity.
If this fails, do not immediately assume that TLS or LDAP connectivity is broken. Check the user’s password expiration and account state first.
==== Test Kerberos authentication ====
A direct Kerberos test provides an additional check of the user’s KNADA credential:
<syntaxhighlight lang="bash">
kdestroy 2>/dev/null || true
kinit USERNAME@KNADA.LAN.KITSNET.US
klist
</syntaxhighlight>
A successful kinit followed by a valid TGT in klist confirms that the user’s password is accepted by Active Directory.
==== Verify application service-account LDAP access ====
Applications normally use a service account to search Active Directory before authenticating the individual user.
For the Wiki, the service account is:
<syntaxhighlight lang="text">
CN=svc-wiki-ldap,CN=Users,DC=knada,DC=lan,DC=kitsnet,DC=us
</syntaxhighlight>
Verify that the application service account can:
establish an LDAPS connection;
validate the KNADA server certificate;
bind successfully;
search the KNADA directory.
A successful service-account bind proves that the application’s LDAP infrastructure is substantially healthy, but it does ‘’‘not’’’ prove that an individual user’s password is valid.
==== Verify TLS and CA trust only if necessary ====
The current KNADA LDAP CA is:
<syntaxhighlight lang="text">
O=KitsNet
OU=KNADA LDAP
CN=KitsNet KNADA LDAP CA 2026
</syntaxhighlight>
SHA-256 fingerprint:
<syntaxhighlight lang="text">
A1:26:57:8E:37:05:52:65:2E:26:7E:48:B0:66:7A:5D:04:4F:C8:BB:A3:4E:E8:B7:12:97:A1:3F:A3:28:15:4F
</syntaxhighlight>
The application-specific CA bundle used by Wiki and other Swarm services contains three certificates:
Historical Frangelico Samba-generated CA
Historical Emperador Samba-generated CA
Current KitsNet KNADA LDAP CA 2026
When inspecting a multi-certificate PEM bundle, note that:
<syntaxhighlight lang="bash">
openssl x509 -in bundle.pem -noout -subject -issuer
</syntaxhighlight>
displays only the ‘’‘first certificate’’’ in the file.
Do not conclude that the bundle lacks the current CA based solely on that command. Split or enumerate all certificates in the bundle before diagnosing it as stale.
=== September 2026 Incident ===
In September 2026, KNADA authentication failed simultaneously in MediaWiki and Grafana.
Initial investigation verified:
IPv4 and IPv6 connectivity to both KNADA domain controllers;
LDAP and LDAPS availability;
successful TLS certificate validation;
correct application CA bundles;
successful Wiki service-account binds to both Frangelico and Emperador;
successful LDAP directory searches from the running Wiki container.
The actual cause was that the affected user’s KNADA password had expired.
Neither MediaWiki nor Grafana clearly reported the password-expired condition to the user. Both presented the condition as a generic login/authentication failure.
This incident established the following troubleshooting rule:
‘’‘When multiple LDAP-authenticated applications reject the same user’s otherwise known-good credentials, check that user’s AD password/account state before changing LDAP, TLS, CA, or application configuration.’’’
=== Host CA Trust Note ===
During the same investigation, it was discovered that several Rocky Linux systems did not have the current KNADA LDAP CA installed in their system trust store.
This was corrected separately through the KitsNet Ansible CA-distribution process.
That host-trust issue was a valid configuration defect, but it was ‘’‘not’’’ the cause of the MediaWiki and Grafana login failures in this incident because those applications already used their own correct KNADA CA bundles.

[[Category:LDAP]]

KitsNet Operations:Services:LDAP:Authentication Troubleshooting

2026-09-27T18:20:25Z

Psmode:

== LDAP Authentication Troubleshooting ==
KitsNet applications such as MediaWiki and Grafana authenticate users against the KNADA Active Directory domain using LDAP/LDAPS.
A failed login does ‘’‘not’’’ necessarily indicate an LDAP server, TLS, CA, or application configuration problem. In particular, an expired KNADA user password may be presented by applications only as a generic authentication failure.
=== Recommended Diagnostic Order ===
When one or more LDAP-authenticated applications reject a user’s credentials, use the following sequence before changing application configuration.
==== 1. Check the affected KNADA user account ====
On a Samba AD domain controller, such as frangelico:
<syntaxhighlight lang="bash">
sudo samba-tool user show USERNAME
</syntaxhighlight>
Review the account state and password information for indications that the password has expired or that the account is otherwise restricted.
==== 2. Test the user’s password directly over LDAPS ====
From a system with the KNADA CA installed:
<syntaxhighlight lang="bash">
ldapwhoami \
-x \
-H ldaps://frangelico.knada.lan.kitsnet.us:636 \
-D 'USERNAME@knada.lan.kitsnet.us' \
-W
</syntaxhighlight>
A successful authentication returns the authenticated LDAP identity.
If this fails, do not immediately assume that TLS or LDAP connectivity is broken. Check the user’s password expiration and account state first.
==== 3. Test Kerberos authentication ====
A direct Kerberos test provides an additional check of the user’s KNADA credential:
<syntaxhighlight lang="bash">
kdestroy 2>/dev/null || true
kinit USERNAME@KNADA.LAN.KITSNET.US
klist
</syntaxhighlight>
A successful kinit followed by a valid TGT in klist confirms that the user’s password is accepted by Active Directory.
==== 4. Verify application service-account LDAP access ====
Applications normally use a service account to search Active Directory before authenticating the individual user.
For the Wiki, the service account is:
<syntaxhighlight lang="text">
CN=svc-wiki-ldap,CN=Users,DC=knada,DC=lan,DC=kitsnet,DC=us
</syntaxhighlight>
Verify that the application service account can:
establish an LDAPS connection;
validate the KNADA server certificate;
bind successfully;
search the KNADA directory.
A successful service-account bind proves that the application’s LDAP infrastructure is substantially healthy, but it does ‘’‘not’’’ prove that an individual user’s password is valid.
==== 5. Verify TLS and CA trust only if necessary ====
The current KNADA LDAP CA is:
<syntaxhighlight lang="text">
O=KitsNet
OU=KNADA LDAP
CN=KitsNet KNADA LDAP CA 2026
</syntaxhighlight>
SHA-256 fingerprint:
<syntaxhighlight lang="text">
A1:26:57:8E:37:05:52:65:2E:26:7E:48:B0:66:7A:5D:04:4F:C8:BB:A3:4E:E8:B7:12:97:A1:3F:A3:28:15:4F
</syntaxhighlight>
The application-specific CA bundle used by Wiki and other Swarm services contains three certificates:
Historical Frangelico Samba-generated CA
Historical Emperador Samba-generated CA
Current KitsNet KNADA LDAP CA 2026
When inspecting a multi-certificate PEM bundle, note that:
<syntaxhighlight lang="bash">
openssl x509 -in bundle.pem -noout -subject -issuer
</syntaxhighlight>
displays only the ‘’‘first certificate’’’ in the file.
Do not conclude that the bundle lacks the current CA based solely on that command. Split or enumerate all certificates in the bundle before diagnosing it as stale.
=== September 2026 Incident ===
In September 2026, KNADA authentication failed simultaneously in MediaWiki and Grafana.
Initial investigation verified:
IPv4 and IPv6 connectivity to both KNADA domain controllers;
LDAP and LDAPS availability;
successful TLS certificate validation;
correct application CA bundles;
successful Wiki service-account binds to both Frangelico and Emperador;
successful LDAP directory searches from the running Wiki container.
The actual cause was that the affected user’s KNADA password had expired.
Neither MediaWiki nor Grafana clearly reported the password-expired condition to the user. Both presented the condition as a generic login/authentication failure.
This incident established the following troubleshooting rule:
‘’‘When multiple LDAP-authenticated applications reject the same user’s otherwise known-good credentials, check that user’s AD password/account state before changing LDAP, TLS, CA, or application configuration.’’’
=== Host CA Trust Note ===
During the same investigation, it was discovered that several Rocky Linux systems did not have the current KNADA LDAP CA installed in their system trust store.
This was corrected separately through the KitsNet Ansible CA-distribution process.
That host-trust issue was a valid configuration defect, but it was ‘’‘not’’’ the cause of the MediaWiki and Grafana login failures in this incident because those applications already used their own correct KNADA CA bundles.
[[Category:LDAP]]

KitsNet Operations:Services:LDAP:Authentication Troubleshooting

2026-09-27T18:19:22Z

Psmode: Created page with "== LDAP Authentication Troubleshooting == KitsNet applications such as MediaWiki and Grafana authenticate users against the KNADA Active Directory domain using LDAP/LDAPS. A failed login does ‘’‘not’’’ necessarily indicate an LDAP server, TLS, CA, or application configuration problem. In particular, an expired KNADA user password may be presented by applications only as a generic authentication failure. === Recommended Diagnostic Order === When one or more LD..."

== LDAP Authentication Troubleshooting ==
KitsNet applications such as MediaWiki and Grafana authenticate users against the KNADA Active Directory domain using LDAP/LDAPS.
A failed login does ‘’‘not’’’ necessarily indicate an LDAP server, TLS, CA, or application configuration problem. In particular, an expired KNADA user password may be presented by applications only as a generic authentication failure.
=== Recommended Diagnostic Order ===
When one or more LDAP-authenticated applications reject a user’s credentials, use the following sequence before changing application configuration.
==== 1. Check the affected KNADA user account ====
On a Samba AD domain controller, such as frangelico:
<syntaxhighlight lang="bash">
sudo samba-tool user show USERNAME
</syntaxhighlight>
Review the account state and password information for indications that the password has expired or that the account is otherwise restricted.
==== 2. Test the user’s password directly over LDAPS ====
From a system with the KNADA CA installed:
<syntaxhighlight lang="bash">
ldapwhoami \
-x \
-H ldaps://frangelico.knada.lan.kitsnet.us:636 \
-D 'USERNAME@knada.lan.kitsnet.us' \
-W
</syntaxhighlight>
A successful authentication returns the authenticated LDAP identity.
If this fails, do not immediately assume that TLS or LDAP connectivity is broken. Check the user’s password expiration and account state first.
==== 3. Test Kerberos authentication ====
A direct Kerberos test provides an additional check of the user’s KNADA credential:
<syntaxhighlight lang="bash">
kdestroy 2>/dev/null || true
kinit USERNAME@KNADA.LAN.KITSNET.US
klist
</syntaxhighlight>
A successful kinit followed by a valid TGT in klist confirms that the user’s password is accepted by Active Directory.
==== 4. Verify application service-account LDAP access ====
Applications normally use a service account to search Active Directory before authenticating the individual user.
For the Wiki, the service account is:
<syntaxhighlight lang="text">
CN=svc-wiki-ldap,CN=Users,DC=knada,DC=lan,DC=kitsnet,DC=us
</syntaxhighlight>
Verify that the application service account can:
establish an LDAPS connection;
validate the KNADA server certificate;
bind successfully;
search the KNADA directory.
A successful service-account bind proves that the application’s LDAP infrastructure is substantially healthy, but it does ‘’‘not’’’ prove that an individual user’s password is valid.
==== 5. Verify TLS and CA trust only if necessary ====
The current KNADA LDAP CA is:
<syntaxhighlight lang="text">
O=KitsNet
OU=KNADA LDAP
CN=KitsNet KNADA LDAP CA 2026
</syntaxhighlight>
SHA-256 fingerprint:
<syntaxhighlight lang="text">
A1:26:57:8E:37:05:52:65:2E:26:7E:48:B0:66:7A:5D:04:4F:C8:BB:A3:4E:E8:B7:12:97:A1:3F:A3:28:15:4F
</syntaxhighlight>
The application-specific CA bundle used by Wiki and other Swarm services contains three certificates:
Historical Frangelico Samba-generated CA
Historical Emperador Samba-generated CA
Current KitsNet KNADA LDAP CA 2026
When inspecting a multi-certificate PEM bundle, note that:
<syntaxhighlight lang="bash">
openssl x509 -in bundle.pem -noout -subject -issuer
</syntaxhighlight>
displays only the ‘’‘first certificate’’’ in the file.
Do not conclude that the bundle lacks the current CA based solely on that command. Split or enumerate all certificates in the bundle before diagnosing it as stale.
=== September 2026 Incident ===
In September 2026, KNADA authentication failed simultaneously in MediaWiki and Grafana.
Initial investigation verified:
IPv4 and IPv6 connectivity to both KNADA domain controllers;
LDAP and LDAPS availability;
successful TLS certificate validation;
correct application CA bundles;
successful Wiki service-account binds to both Frangelico and Emperador;
successful LDAP directory searches from the running Wiki container.
The actual cause was that the affected user’s KNADA password had expired.
Neither MediaWiki nor Grafana clearly reported the password-expired condition to the user. Both presented the condition as a generic login/authentication failure.
This incident established the following troubleshooting rule:
‘’‘When multiple LDAP-authenticated applications reject the same user’s otherwise known-good credentials, check that user’s AD password/account state before changing LDAP, TLS, CA, or application configuration.’’’
=== Host CA Trust Note ===
During the same investigation, it was discovered that several Rocky Linux systems did not have the current KNADA LDAP CA installed in their system trust store.
This was corrected separately through the KitsNet Ansible CA-distribution process.
That host-trust issue was a valid configuration defect, but it was ‘’‘not’’’ the cause of the MediaWiki and Grafana login failures in this incident because those applications already used their own correct KNADA CA bundles.

KitsNet Services

2026-09-22T12:58:07Z

Psmode:

__NOTOC__

This page provides the hierarchical index of KitsNet service documentation.

<categorytree mode="pages" depth="5" hideroot="on" showcount="off">
KitsNet Services
</categorytree>

KitsNet Operations:Services:Mail Gateway:No-Subscription Warning Suppression

2026-09-22T12:54:52Z

Psmode:

__FORCETOC__
== Purpose ==

This local customization suppresses Proxmox Mail Gateway (PMG) '''"No valid subscription"''' warnings in the web interface without pretending that the system has a valid subscription and without changing PMG mail filtering, repository configuration, licensing state, or subscription data.

The customization is intended for the KitsNet PMG host '''dusse'''.

Initially tested with:

{| class="wikitable"
! Component
! Version
|-
| proxmox-mailgateway
| 9.1
|-
| pmg-api
| 9.1.2
|-
| pmg-gui
| 5.2.2
|-
| proxmox-widget-toolkit
| 5.2.8
|-
| pmg-mobile-quarantine-ui
| 0.5.3
|}

== Files Installed ==

; Main patcher
: <code>/usr/local/sbin/kitsnet-pmg-nosub-patch</code>

; APT/DPKG wrapper
: <code>/usr/local/sbin/kitsnet-pmg-nosub-apt-hook</code>

; APT hook
: <code>/etc/apt/apt.conf.d/99-kitsnet-pmg-nosub</code>

; Log
: <code>/var/log/kitsnet-pmg-nosub-patch.log</code>

== Files Modified by the Patcher ==

=== Proxmox Widget Toolkit ===

File:

<pre>
/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
</pre>

Modification:

<code>Proxmox.Utils.checked_command()</code> is changed so that the requested command executes immediately instead of displaying the generic '''"No valid subscription"''' warning.

=== PMG GUI ===

File:

<pre>
/usr/share/javascript/pmg-gui/js/pmgmanagerlib.js
</pre>

Modifications:

* The PMG dashboard subscription-warning panel is hidden.
* The explicit subscription check performed while changing into a logged-in/user view is suppressed.

The actual PMG '''Subscription''' configuration page remains available and continues to report the real subscription state.

== Normal Use ==

The patch is normally reapplied automatically after Debian/Proxmox package operations by the APT post-invoke hook.

No routine manual action should be required.

== Manual Check ==

To verify that all expected KitsNet modifications are currently present:

<syntaxhighlight lang="bash">
sudo /usr/local/sbin/kitsnet-pmg-nosub-patch --check
</syntaxhighlight>

Expected successful output:

<pre>
OK: all KitsNet PMG subscription-suppression patches are present.
</pre>

A nonzero return code means one or more expected modifications are absent.

== Manual Apply / Reapply ==

To apply or reapply the customization manually:

<syntaxhighlight lang="bash">
sudo /usr/local/sbin/kitsnet-pmg-nosub-patch
</syntaxhighlight>

The patcher is '''idempotent'''. Running it when all patches are already present does not make additional changes.

== After Applying the Patch ==

Browser JavaScript may remain cached.

After applying or reapplying the patch, hard-refresh PMG browser sessions:

<pre>
Ctrl+Shift+R
</pre>

Do this for both:

* administrator sessions
* quarantine / ordinary-user sessions

== Automatic Reapplication After Updates ==

APT runs:

<pre>
/usr/local/sbin/kitsnet-pmg-nosub-apt-hook
</pre>

after package operations.

That wrapper runs:

<pre>
/usr/local/sbin/kitsnet-pmg-nosub-patch
</pre>

and records the result in:

<pre>
/var/log/kitsnet-pmg-nosub-patch.log
</pre>

The wrapper always exits successfully so that a cosmetic local PMG GUI customization can never cause an APT or Proxmox package upgrade to fail.

== Safe Failure Behavior ==

The patcher only modifies files when the expected source-code structures are found exactly.

If a future Proxmox release changes the relevant JavaScript enough that the known patterns no longer match, the patcher:

* makes no speculative modification
* reports the mismatch
* returns an error
* records the problem in the log when run automatically
* allows the package upgrade itself to complete normally

This is intentional.

After a major PMG or <code>proxmox-widget-toolkit</code> update, inspect the new source before changing the patcher to match the new implementation.

== Checking the Log ==

Recent results:

<syntaxhighlight lang="bash">
sudo tail -100 /var/log/kitsnet-pmg-nosub-patch.log
</syntaxhighlight>

Search the system journal for automatic-patch warnings:

<syntaxhighlight lang="bash">
sudo journalctl -t kitsnet-pmg-nosub-patch
</syntaxhighlight>

== Backups ==

Whenever the patcher modifies one of the PMG JavaScript files, it creates a timestamped backup alongside that file.

Examples:

<pre>
/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js.kitsnet-prepatch-YYYYMMDD-HHMMSS

/usr/share/javascript/pmg-gui/js/pmgmanagerlib.js.kitsnet-prepatch-YYYYMMDD-HHMMSS
</pre>

Earlier manual backups may also exist with names such as:

<pre>
*.kitsnet-nosub-backup-YYYYMMDD-HHMMSS
</pre>

These backups are intended for troubleshooting and rollback.

== Removing / Disabling Automatic Reapplication ==

To stop automatically reapplying the customization after package updates, remove or rename the APT hook:

<syntaxhighlight lang="bash">
sudo rm /etc/apt/apt.conf.d/99-kitsnet-pmg-nosub
</syntaxhighlight>

This does '''not''' restore the original JavaScript files. It only disables the automatic post-package invocation.

== Restoring Stock Proxmox Files ==

The cleanest way to restore current package-provided versions is normally to reinstall the packages that own the modified files.

First identify the installed package versions:

<syntaxhighlight lang="bash">
dpkg-query -W proxmox-widget-toolkit pmg-gui
</syntaxhighlight>

Disable the KitsNet APT hook before reinstalling packages, otherwise the patch will be reapplied immediately:

<syntaxhighlight lang="bash">
sudo mv /etc/apt/apt.conf.d/99-kitsnet-pmg-nosub \
/etc/apt/apt.conf.d/99-kitsnet-pmg-nosub.disabled
</syntaxhighlight>

Then reinstall the affected packages using the normal Proxmox/Debian package-management procedure.

Afterward, hard-refresh the browser.

== What This Patch Does NOT Do ==

This customization does '''not''':

* install or emulate a Proxmox subscription
* alter the PMG API subscription result
* enable the enterprise repository
* disable repository warnings unless separately customized
* change SpamAssassin, ClamAV, SMTP, quarantine, filtering, or delivery
* alter licensing or support entitlement
* modify the PMG mobile quarantine bundle unless explicitly extended

== Known Separate Warning ==

The yellow dashboard message:

<blockquote>
Non production-ready repository enabled!
</blockquote>

is a separate repository-status warning. It is not part of the no-subscription suppression described here.

== Source Markers ==

The installed JavaScript modifications are intentionally marked with '''KITSNET''' comments so they are easy to locate.

Examples:

<pre>
KITSNET: suppress no-subscription warning

KITSNET: hide no-subscription dashboard panel

KITSNET: suppress subscription check when changing views
</pre>

== Quick Reference ==

{| class="wikitable"
! Task
! Command
|-
| Check patch status
| <code>sudo /usr/local/sbin/kitsnet-pmg-nosub-patch --check</code>
|-
| Apply / reapply
| <code>sudo /usr/local/sbin/kitsnet-pmg-nosub-patch</code>
|-
| View log
| <code>sudo tail -100 /var/log/kitsnet-pmg-nosub-patch.log</code>
|-
| Hard-refresh browser
| <code>Ctrl+Shift+R</code>
|}

== Maintenance Note ==

This is a local KitsNet customization to package-managed JavaScript files.

Proxmox updates are expected to replace those files. The patcher and APT hook exist specifically so the customization can be safely and repeatably reapplied after updates.

KitsNet Operations:Services:Mail Gateway:No-Subscription Warning Suppression

2026-09-22T12:54:15Z

Psmode:

__NOTOC__

== Purpose ==

This local customization suppresses Proxmox Mail Gateway (PMG) '''"No valid subscription"''' warnings in the web interface without pretending that the system has a valid subscription and without changing PMG mail filtering, repository configuration, licensing state, or subscription data.

The customization is intended for the KitsNet PMG host '''dusse'''.

Initially tested with:

{| class="wikitable"
! Component
! Version
|-
| proxmox-mailgateway
| 9.1
|-
| pmg-api
| 9.1.2
|-
| pmg-gui
| 5.2.2
|-
| proxmox-widget-toolkit
| 5.2.8
|-
| pmg-mobile-quarantine-ui
| 0.5.3
|}

== Files Installed ==

; Main patcher
: <code>/usr/local/sbin/kitsnet-pmg-nosub-patch</code>

; APT/DPKG wrapper
: <code>/usr/local/sbin/kitsnet-pmg-nosub-apt-hook</code>

; APT hook
: <code>/etc/apt/apt.conf.d/99-kitsnet-pmg-nosub</code>

; Log
: <code>/var/log/kitsnet-pmg-nosub-patch.log</code>

== Files Modified by the Patcher ==

=== Proxmox Widget Toolkit ===

File:

<pre>
/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
</pre>

Modification:

<code>Proxmox.Utils.checked_command()</code> is changed so that the requested command executes immediately instead of displaying the generic '''"No valid subscription"''' warning.

=== PMG GUI ===

File:

<pre>
/usr/share/javascript/pmg-gui/js/pmgmanagerlib.js
</pre>

Modifications:

* The PMG dashboard subscription-warning panel is hidden.
* The explicit subscription check performed while changing into a logged-in/user view is suppressed.

The actual PMG '''Subscription''' configuration page remains available and continues to report the real subscription state.

== Normal Use ==

The patch is normally reapplied automatically after Debian/Proxmox package operations by the APT post-invoke hook.

No routine manual action should be required.

== Manual Check ==

To verify that all expected KitsNet modifications are currently present:

<syntaxhighlight lang="bash">
sudo /usr/local/sbin/kitsnet-pmg-nosub-patch --check
</syntaxhighlight>

Expected successful output:

<pre>
OK: all KitsNet PMG subscription-suppression patches are present.
</pre>

A nonzero return code means one or more expected modifications are absent.

== Manual Apply / Reapply ==

To apply or reapply the customization manually:

<syntaxhighlight lang="bash">
sudo /usr/local/sbin/kitsnet-pmg-nosub-patch
</syntaxhighlight>

The patcher is '''idempotent'''. Running it when all patches are already present does not make additional changes.

== After Applying the Patch ==

Browser JavaScript may remain cached.

After applying or reapplying the patch, hard-refresh PMG browser sessions:

<pre>
Ctrl+Shift+R
</pre>

Do this for both:

* administrator sessions
* quarantine / ordinary-user sessions

== Automatic Reapplication After Updates ==

APT runs:

<pre>
/usr/local/sbin/kitsnet-pmg-nosub-apt-hook
</pre>

after package operations.

That wrapper runs:

<pre>
/usr/local/sbin/kitsnet-pmg-nosub-patch
</pre>

and records the result in:

<pre>
/var/log/kitsnet-pmg-nosub-patch.log
</pre>

The wrapper always exits successfully so that a cosmetic local PMG GUI customization can never cause an APT or Proxmox package upgrade to fail.

== Safe Failure Behavior ==

The patcher only modifies files when the expected source-code structures are found exactly.

If a future Proxmox release changes the relevant JavaScript enough that the known patterns no longer match, the patcher:

* makes no speculative modification
* reports the mismatch
* returns an error
* records the problem in the log when run automatically
* allows the package upgrade itself to complete normally

This is intentional.

After a major PMG or <code>proxmox-widget-toolkit</code> update, inspect the new source before changing the patcher to match the new implementation.

== Checking the Log ==

Recent results:

<syntaxhighlight lang="bash">
sudo tail -100 /var/log/kitsnet-pmg-nosub-patch.log
</syntaxhighlight>

Search the system journal for automatic-patch warnings:

<syntaxhighlight lang="bash">
sudo journalctl -t kitsnet-pmg-nosub-patch
</syntaxhighlight>

== Backups ==

Whenever the patcher modifies one of the PMG JavaScript files, it creates a timestamped backup alongside that file.

Examples:

<pre>
/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js.kitsnet-prepatch-YYYYMMDD-HHMMSS

/usr/share/javascript/pmg-gui/js/pmgmanagerlib.js.kitsnet-prepatch-YYYYMMDD-HHMMSS
</pre>

Earlier manual backups may also exist with names such as:

<pre>
*.kitsnet-nosub-backup-YYYYMMDD-HHMMSS
</pre>

These backups are intended for troubleshooting and rollback.

== Removing / Disabling Automatic Reapplication ==

To stop automatically reapplying the customization after package updates, remove or rename the APT hook:

<syntaxhighlight lang="bash">
sudo rm /etc/apt/apt.conf.d/99-kitsnet-pmg-nosub
</syntaxhighlight>

This does '''not''' restore the original JavaScript files. It only disables the automatic post-package invocation.

== Restoring Stock Proxmox Files ==

The cleanest way to restore current package-provided versions is normally to reinstall the packages that own the modified files.

First identify the installed package versions:

<syntaxhighlight lang="bash">
dpkg-query -W proxmox-widget-toolkit pmg-gui
</syntaxhighlight>

Disable the KitsNet APT hook before reinstalling packages, otherwise the patch will be reapplied immediately:

<syntaxhighlight lang="bash">
sudo mv /etc/apt/apt.conf.d/99-kitsnet-pmg-nosub \
/etc/apt/apt.conf.d/99-kitsnet-pmg-nosub.disabled
</syntaxhighlight>

Then reinstall the affected packages using the normal Proxmox/Debian package-management procedure.

Afterward, hard-refresh the browser.

== What This Patch Does NOT Do ==

This customization does '''not''':

* install or emulate a Proxmox subscription
* alter the PMG API subscription result
* enable the enterprise repository
* disable repository warnings unless separately customized
* change SpamAssassin, ClamAV, SMTP, quarantine, filtering, or delivery
* alter licensing or support entitlement
* modify the PMG mobile quarantine bundle unless explicitly extended

== Known Separate Warning ==

The yellow dashboard message:

<blockquote>
Non production-ready repository enabled!
</blockquote>

is a separate repository-status warning. It is not part of the no-subscription suppression described here.

== Source Markers ==

The installed JavaScript modifications are intentionally marked with '''KITSNET''' comments so they are easy to locate.

Examples:

<pre>
KITSNET: suppress no-subscription warning

KITSNET: hide no-subscription dashboard panel

KITSNET: suppress subscription check when changing views
</pre>

== Quick Reference ==

{| class="wikitable"
! Task
! Command
|-
| Check patch status
| <code>sudo /usr/local/sbin/kitsnet-pmg-nosub-patch --check</code>
|-
| Apply / reapply
| <code>sudo /usr/local/sbin/kitsnet-pmg-nosub-patch</code>
|-
| View log
| <code>sudo tail -100 /var/log/kitsnet-pmg-nosub-patch.log</code>
|-
| Hard-refresh browser
| <code>Ctrl+Shift+R</code>
|}

== Maintenance Note ==

This is a local KitsNet customization to package-managed JavaScript files.

Proxmox updates are expected to replace those files. The patcher and APT hook exist specifically so the customization can be safely and repeatably reapplied after updates.

KitsNet Operations:Services:Mail Gateway:No-Subscription Warning Suppression

2026-09-22T12:54:03Z

Psmode: Created page with "__NOTOC__ = KitsNet PMG No-Subscription Warning Suppression = == Purpose == This local customization suppresses Proxmox Mail Gateway (PMG) '''"No valid subscription"''' warnings in the web interface without pretending that the system has a valid subscription and without changing PMG mail filtering, repository configuration, licensing state, or subscription data. The customization is intended for the KitsNet PMG host '''dusse'''. Initially tested with: {| class="wiki..."

__NOTOC__
= KitsNet PMG No-Subscription Warning Suppression =

== Purpose ==

This local customization suppresses Proxmox Mail Gateway (PMG) '''"No valid subscription"''' warnings in the web interface without pretending that the system has a valid subscription and without changing PMG mail filtering, repository configuration, licensing state, or subscription data.

The customization is intended for the KitsNet PMG host '''dusse'''.

Initially tested with:

{| class="wikitable"
! Component
! Version
|-
| proxmox-mailgateway
| 9.1
|-
| pmg-api
| 9.1.2
|-
| pmg-gui
| 5.2.2
|-
| proxmox-widget-toolkit
| 5.2.8
|-
| pmg-mobile-quarantine-ui
| 0.5.3
|}

== Files Installed ==

; Main patcher
: <code>/usr/local/sbin/kitsnet-pmg-nosub-patch</code>

; APT/DPKG wrapper
: <code>/usr/local/sbin/kitsnet-pmg-nosub-apt-hook</code>

; APT hook
: <code>/etc/apt/apt.conf.d/99-kitsnet-pmg-nosub</code>

; Log
: <code>/var/log/kitsnet-pmg-nosub-patch.log</code>

== Files Modified by the Patcher ==

=== Proxmox Widget Toolkit ===

File:

<pre>
/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
</pre>

Modification:

<code>Proxmox.Utils.checked_command()</code> is changed so that the requested command executes immediately instead of displaying the generic '''"No valid subscription"''' warning.

=== PMG GUI ===

File:

<pre>
/usr/share/javascript/pmg-gui/js/pmgmanagerlib.js
</pre>

Modifications:

* The PMG dashboard subscription-warning panel is hidden.
* The explicit subscription check performed while changing into a logged-in/user view is suppressed.

The actual PMG '''Subscription''' configuration page remains available and continues to report the real subscription state.

== Normal Use ==

The patch is normally reapplied automatically after Debian/Proxmox package operations by the APT post-invoke hook.

No routine manual action should be required.

== Manual Check ==

To verify that all expected KitsNet modifications are currently present:

<syntaxhighlight lang="bash">
sudo /usr/local/sbin/kitsnet-pmg-nosub-patch --check
</syntaxhighlight>

Expected successful output:

<pre>
OK: all KitsNet PMG subscription-suppression patches are present.
</pre>

A nonzero return code means one or more expected modifications are absent.

== Manual Apply / Reapply ==

To apply or reapply the customization manually:

<syntaxhighlight lang="bash">
sudo /usr/local/sbin/kitsnet-pmg-nosub-patch
</syntaxhighlight>

The patcher is '''idempotent'''. Running it when all patches are already present does not make additional changes.

== After Applying the Patch ==

Browser JavaScript may remain cached.

After applying or reapplying the patch, hard-refresh PMG browser sessions:

<pre>
Ctrl+Shift+R
</pre>

Do this for both:

* administrator sessions
* quarantine / ordinary-user sessions

== Automatic Reapplication After Updates ==

APT runs:

<pre>
/usr/local/sbin/kitsnet-pmg-nosub-apt-hook
</pre>

after package operations.

That wrapper runs:

<pre>
/usr/local/sbin/kitsnet-pmg-nosub-patch
</pre>

and records the result in:

<pre>
/var/log/kitsnet-pmg-nosub-patch.log
</pre>

The wrapper always exits successfully so that a cosmetic local PMG GUI customization can never cause an APT or Proxmox package upgrade to fail.

== Safe Failure Behavior ==

The patcher only modifies files when the expected source-code structures are found exactly.

If a future Proxmox release changes the relevant JavaScript enough that the known patterns no longer match, the patcher:

* makes no speculative modification
* reports the mismatch
* returns an error
* records the problem in the log when run automatically
* allows the package upgrade itself to complete normally

This is intentional.

After a major PMG or <code>proxmox-widget-toolkit</code> update, inspect the new source before changing the patcher to match the new implementation.

== Checking the Log ==

Recent results:

<syntaxhighlight lang="bash">
sudo tail -100 /var/log/kitsnet-pmg-nosub-patch.log
</syntaxhighlight>

Search the system journal for automatic-patch warnings:

<syntaxhighlight lang="bash">
sudo journalctl -t kitsnet-pmg-nosub-patch
</syntaxhighlight>

== Backups ==

Whenever the patcher modifies one of the PMG JavaScript files, it creates a timestamped backup alongside that file.

Examples:

<pre>
/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js.kitsnet-prepatch-YYYYMMDD-HHMMSS

/usr/share/javascript/pmg-gui/js/pmgmanagerlib.js.kitsnet-prepatch-YYYYMMDD-HHMMSS
</pre>

Earlier manual backups may also exist with names such as:

<pre>
*.kitsnet-nosub-backup-YYYYMMDD-HHMMSS
</pre>

These backups are intended for troubleshooting and rollback.

== Removing / Disabling Automatic Reapplication ==

To stop automatically reapplying the customization after package updates, remove or rename the APT hook:

<syntaxhighlight lang="bash">
sudo rm /etc/apt/apt.conf.d/99-kitsnet-pmg-nosub
</syntaxhighlight>

This does '''not''' restore the original JavaScript files. It only disables the automatic post-package invocation.

== Restoring Stock Proxmox Files ==

The cleanest way to restore current package-provided versions is normally to reinstall the packages that own the modified files.

First identify the installed package versions:

<syntaxhighlight lang="bash">
dpkg-query -W proxmox-widget-toolkit pmg-gui
</syntaxhighlight>

Disable the KitsNet APT hook before reinstalling packages, otherwise the patch will be reapplied immediately:

<syntaxhighlight lang="bash">
sudo mv /etc/apt/apt.conf.d/99-kitsnet-pmg-nosub \
/etc/apt/apt.conf.d/99-kitsnet-pmg-nosub.disabled
</syntaxhighlight>

Then reinstall the affected packages using the normal Proxmox/Debian package-management procedure.

Afterward, hard-refresh the browser.

== What This Patch Does NOT Do ==

This customization does '''not''':

* install or emulate a Proxmox subscription
* alter the PMG API subscription result
* enable the enterprise repository
* disable repository warnings unless separately customized
* change SpamAssassin, ClamAV, SMTP, quarantine, filtering, or delivery
* alter licensing or support entitlement
* modify the PMG mobile quarantine bundle unless explicitly extended

== Known Separate Warning ==

The yellow dashboard message:

<blockquote>
Non production-ready repository enabled!
</blockquote>

is a separate repository-status warning. It is not part of the no-subscription suppression described here.

== Source Markers ==

The installed JavaScript modifications are intentionally marked with '''KITSNET''' comments so they are easy to locate.

Examples:

<pre>
KITSNET: suppress no-subscription warning

KITSNET: hide no-subscription dashboard panel

KITSNET: suppress subscription check when changing views
</pre>

== Quick Reference ==

{| class="wikitable"
! Task
! Command
|-
| Check patch status
| <code>sudo /usr/local/sbin/kitsnet-pmg-nosub-patch --check</code>
|-
| Apply / reapply
| <code>sudo /usr/local/sbin/kitsnet-pmg-nosub-patch</code>
|-
| View log
| <code>sudo tail -100 /var/log/kitsnet-pmg-nosub-patch.log</code>
|-
| Hard-refresh browser
| <code>Ctrl+Shift+R</code>
|}

== Maintenance Note ==

This is a local KitsNet customization to package-managed JavaScript files.

Proxmox updates are expected to replace those files. The patcher and APT hook exist specifically so the customization can be safely and repeatably reapplied after updates.

Linux:Tips and Tricks

2026-09-18T21:40:06Z

Psmode:

__NONUMBERHEADINGS__
====Find files modified in past N days====
<code>find ''path'' -mtime -''N'' -ls</code><syntaxhighlight lang="shell-session">
[psmode@wort ~]$ find /kvm/ -mtime -3 -ls
102090127 4 drwxr-xr-x 7 root root 4096 Jan 3 09:46 /kvm/
2038539 4 drwxr-xr-x 2 root kitsnet_adm 4096 Jan 3 09:13 /kvm/socat-kvm
2038573 4 -rw-r--r-- 1 root root 5 Jan 3 09:13 /kvm/socat-kvm/uv040
101237691 8 -rw-r--r-- 1 root kitsnet_adm 6370 Jan 3 09:46 /kvm/uv034.xml
102163845 12 -rw-r--r-- 1 root root 9096 Jan 3 09:46 /kvm/uv039.xml
102090129 12 -rw-r--r-- 1 root root 8303 Jan 3 09:46 /kvm/uv040.xml
</syntaxhighlight>

==== Search files modified in past N days ====
<code>find ''path'' -mtime -''N'' -type f -exec grep ''pattern'' {} /dev/null \;</code><syntaxhighlight lang="shell-session">
[psmode@ciroc ~]$ sudo find /etc -mtime -9 -type f -exec grep mailroom1 {} /dev/null \;
/etc/httpd/conf/httpd.conf: DocumentRoot "/var/www/virt-html/mailroom1.kitsnet.us"
/etc/httpd/conf/httpd.conf: ServerName mailroom1.kitsnet.us
/etc/httpd/conf/httpd.conf:#RewriteCond %{SERVER_NAME} =mailroom1.kitsnet.us
</syntaxhighlight>

====Shell script debugging modes====
A good explanation of the debugging modes is given by [https://www.tecmint.com/enable-shell-debug-mode-linux/ How To Enable Shell Script Debugging Mode in Linux]. Basically, there are three modes

*<code>-v</code> (short for verbose) – tells the shell to show all lines in a script while they are read, it activates verbose mode.
*<code>-n</code> (short for noexec or no execution) – instructs the shell read all the commands, however doesn’t execute them. This options activates syntax checking mode.
*<code>-x</code> (short for xtrace or execution trace) – tells the shell to display all commands and their arguments on the terminal while they are executed. This option enables shell tracing mode.

Which may be invoked by any of three different ways:

#Modifying the first line of a shell script: <code>#!/bin/sh ''option(s)''</code>
#Invoking shell with debugging options: <code>$ /bin/bash ''option(s)'' ''script_name'' ''argument1 ... argumentN''</code>
#Using set shell built-in command in the middle of the script: <code>$ set -''option''</code> to enable or <code>$ set +''option''</code> to disable

====Network Diagnostics====
See also [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configuring_ip_networking_with_nmcli Red Hat 7 Networking Guide 3.3. Configuring IP Networking with nmcli] and [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/index RED HAT ENTERPRISE LINUX 8 Configuring and managing networking] and [https://docs.rockylinux.org/guides/network/basic_network_configuration/ Network Configuration - Rocky Linux 9] and [https://opensource.com/article/22/8/migrate-networkmanager-keyfiles-configuration How I migrated to NetworkManager keyfiles for configuration]<syntaxhighlight lang="shell-session">
# ip address
# ip link
# ip route
# ip -6 route
# firewall-cmd --list-all --zone=... (replace ... with whatever zones you are working with)
# nmcli connection show
# nmcli connection show --active
# nmcli device status
# nmcli connection show <device>
# sysctl -a | grep -E 'forwarding'
</syntaxhighlight>

====How to use diff and patch====
The diff utility can be used to generate a patch file. Basically, the differences are put togetehr with syntax from the patch utility so that the resulting file can be used to turn another copy of the original file into the desired final state file. A good reference article is [https://www.pair.com/support/kb/paircloud-diff-and-patch/ available online] The high level syntax is:<syntaxhighlight lang="shell-session">
# diff -u file1.html file2.html > patchfile.patch
# patch file1.html patchfile.patch
</syntaxhighlight>To reverse the patch, use:<syntaxhighlight lang="shell-session">
# patch -p0 -R -i patchfile.patch
</syntaxhighlight>

====Explore filesystem utilization====
I have installed [https://dev.yorhel.nl/ncdu NCurses Disk Usage] (ncdu ) on all KitsNet Linux systems.

====Time coordination with chrony====
<syntaxhighlight lang="shell-session">
yum install -y chrony # to install
systemctl enable chronyd # to enable
systemctl start chronyd # to start
chronyc tracking # To get information about the main time reference
chronyc sources -v # equivalent information to the ntpq
ntpdate pool.ntp.org # To quickly synchronize a server
timedatectl # display time and synchronization status
chronyc -m 'burst 3/3' 'makestep 0.1 3' # sync time using timesources NOW

</syntaxhighlight>If for some reason the clock is thrown off (e.g. after VM migration), you can force an immediate resync, but <code>makestep</code> just allows the clock to be corrected by step instead of slow slew. You should add the <code>burst</code> command to make a new set of measurements.

====How to mount a multi-partition disk image in Linux====

You can use '''kpartx''' or '''partx''' to create loop devices for the partitions on the image, and then mount them. So either:
<syntaxhighlight lang="shell-session">$ sudo kpartx -v -a file.iso
add map loop0p1 (253:17): 0 8382464 linear 7:1 2048
$ mount /dev/mapper/loop0p1 ./mnt_point
... do something with the partition ...
$ umount ./mnt_point
$ kpartx -d -v file.iso
del devmap : loop0p1
loop deleted : /dev/loop0</syntaxhighlight>
or:<syntaxhighlight lang="shell-session">
$ sudo partx -a -v file.iso
partition: none, disk: file.iso, lower: 0, upper: 0
Trying to use '/dev/loop0' for the loop device
/dev/loop0: partition table type 'dos' detected
range recount: max partno=1, lower=0, upper=0
/dev/loop0: partition #1 added
$ mount /dev/loop0p1 ./mnt_point
... do something with the partition ...
$ umount /dev/loop0p1 ./mnt_point
$ sudo partx -d -v /dev/loop0
partition: none, disk: /dev/loop0, lower: 0, upper: 0
/dev/loop0: partition #1 removed
</syntaxhighlight>

====DHCP Lease Renewal====

[https://www.cyberciti.biz/faq/howto-linux-renew-dhcp-client-ip-address/ Linux Force DHCP Client (dhclient) to Renew IP Address] covers this in greater detail for a number of platforms and environments. For KitsNet, the two methods that work are based on <code>dhclient</code> or <code>nmcli</code>

=====dhclient=====
The <kbd>-r</kbd> flag explicitly releases the current lease, and once the lease has been released, the client exits. For example, open terminal application and type the command:

<code>$ sudo dhclient -r</code>

Now obtain fresh IP address using DHCP on Linux:

<code>$ sudo dhclient</code>

=====nmcli=====
The NetworkManager daemon attempts to make networking configuration and operation as painless and automatic as possible by managing the primary network connection and other network interfaces, like Ethernet, WiFi, and Mobile Broadband devices command-line tool for controlling NetworkManager. The <code>nmcli</code> is a command-line tool for controlling NetworkManager and getting its status. To renew IP address using nmcli for connection named ‘nixcraft_5G’ (use ‘<code>nmcli con</code>‘ command to get list of all connections):
nmcli con
nmcli con down id 'nixcraft_5G'
nmcli con up id 'nixcraft_5G'
# Attempt to update device with changes to the currently active
# connection made since it was last applied and then try it again
nmcli device reapply 'nixcraft_5G'

====GRUB2====
[[Media:Grub.pdf|the GNU GRUB manual - The GRand Unified Bootloader, version 2.12]], originally downloaded from [https://www.gnu.org/software/grub/manual/grub/grub.pdf here]

=====Booting into Rescue mode or Emergency Mode=====
[https://www.thegeekdiary.com/how-to-boot-into-rescue-mode-or-emergency-mode-through-systemd-in-centos-rhel-7-and-8/ How to Boot into Rescue Mode or Emergency Mode Through Systemd in CentOS/RHEL 7 and 8]<blockquote>Rescue mode is equivalent to single user mode and requires the root password. Rescue mode allows you to repair your system in situations when it is unable to complete a regular booting process. Rescue mode will try to mount all local file systems and start some important system services, but it does not activate network interfaces neither allow multiple users to be logged in.

Emergency mode provides the most minimal environment possible and allows you to repair your system even in situations when the system is unable to enter rescue mode. In emergency mode, the system mounts the root file system as read-only, does not attempt to mount any other local file systems, does not activate network interfaces.</blockquote>

#During bootup, when the GRUB2 menu shows up, press the <code>'''e'''</code> key for edit.
#Add a parameter to the end of the linux16 line. For rescue mode add <code>systemd.unit=rescue.target</code>, for emergency mode add <code>systemd.unit=emergency.target</code>
#Press <code>'''Ctrl+x'''</code> to boot the system with the parameter.

===== Change Default Boot Selection (or, how to downgrade the OS) =====
<syntaxhighlight lang="shell-session">
sudo grubby --info=ALL | grep ^kernel #which versions are on the menu
sudo grubby --grub2 --default-title #which is the current default
sudo grubby --set-default "/boot/vmlinuz-5.14.0-362.13.1.el9_3.x86_64" #Set the default to this by path
sudo grubby --set-default 0 #reset the default to the top (most recent) choice)
</syntaxhighlight>

==== MegaRAID ====
Copy of [[Media:51530-00 RevP MegaRAID SAS SW UserGd.pdf|MegaRAID SAS Software User Guide]] (August 2014) from Avago Technologies

===== CLI =====
{| class="wikitable"
|+Handy CLI Commands
!Task
!Command
|-
|Show VD reconstruction/migration status
|<code>storcli64 /c0 /vall show migrate</code>
|-
|Show VD rebuild status
|<code>storcli64 /c0 /eall /sall show rebuild</code>
or

<code>storcli64 -PDRbld -ShowProg -PhysDrv[''252:3''] -a0</code>
|-
|Show PD detailed status
|<code>storcli64 -pdlist -aALL</code>
|-
|Silence alarm
|<code>storcli64 /c0 set alarm=silence</code>
|-
|Show VD detailed status
|<code>storcli64 -LDInfo -Lall -a0</code>
|}
it seems that either <code>'''-'''</code> or <code>'''/'''</code> may be used to introduce command switches.

===== Replacing a failed or failing disk =====
See [https://www.advancedclustering.com/act_kb/replacing-a-disk-with-megacli/ REPLACING AN LSI RAID DISK WITH MEGACLI]

# Check is the status of the VD and of the PDs
#Set the original disk offline if an error has not already cause the controller to set it offline: <code>storcli64 -pdoffline -physdrv[''252:3''] -a0</code>
#Mark the failed disk as missing: <code>storcli64 -pdmarkmissing -physdrv[''252:3''] -aAll</code>
#Mark the failed disk as prepared for removal: <code>storcli64 -pdprprmv -physdrv[''252:3''] -a0</code>
#Replace the faulty disk (in other systems, pdlocate can be helpful)
#If you don’t use hot spares you will need to add the disk to the array and start the rebuild manually: <code>storcli64 -PdReplaceMissing -PhysDrv[''252:3''] -Array0 -row0 -a0</code> and <code>storcli64 -PDRbld -Start -PhysDrv[''252:3''] -a0</code>

====Systemctl====
{| class="wikitable"
|+Commands to show and manipulate services
!
!
|-
|List all the <code>systemd</code> service which are in <code>state=active</code> and <code>sub=running</code>
|<code>systemctl list-units --type=service --state=running</code>
|-
|List all the <code>systemd</code> serice which are in <code>state=active</code> and sub either running or exited
|<code>systemctl list-units --type=service --state=active</code>
|-
|To enable and start a service at the same time
|<code>systemctl enable --now ''service''</code>
|-
|Show enabled units
|<code>systemctl list-unit-files --state=enabled</code>
|}

==== Manual SMTP session ====
Not exactly an Linux tip, but close enough. I got tired of re-inventing this, so I asked ChatGPT. Additional information is available from [https://mailtrap.io/blog/smtp-commands-and-responses/ SMTP Commands and Response Codes Guide]

* Open a terminal and type: <code>telnet <SMTP_server_address> 25</code>
* Once connected, you'll see a response from the server. Typically, it will start with something like<code>220 <SMTP_server_address> ESMTP</code>
* Enter the following commands to send an email:
<syntaxhighlight lang="text">
HELO <smtp_client_domain>
MAIL FROM:<sender_email_address>
RCPT TO:<recipient_email_address>
DATA
Subject: Your subject here
Your email body here.
.
QUIT
</syntaxhighlight>

* After typing <code>DATA</code>, you'll be prompted to enter the body of your email. After composing your message, end it with a period . on a new line.
* Finally, type <code>QUIT</code> to close the connection.

==== Monitoring utilities on wort ====
Aside from systat, iostat, top and glances, wort has some additional utilities installed that can be used to capture information about disk IO performance amongst other things.

* [https://htop.dev/ htop] is an interactive process viewer
* [https://github.com/dstat-real/dstat/blob/master/README.adoc dstat] has been forked to [https://github.com/scottchiefbaker/dool dool] because RedHat hijacked the name
** Try <code>dstat -tcdD total,nvme0n1,sda,sdb,sdc,sdd,sde,sdf --disk-wait --disk-util 30</code>
* [https://pcp.io/ pcp] (Performance Co-Pilot) supports [https://access.redhat.com/articles/2450251 storage performance analysis] and other things

==== After installtion of microcode_ctl, initramfs hasn't been re-generated for all the installed kernel packages ====
Need to run <code>dracut</code> against all installed kernels to make sure they all get the updated microocde. <syntaxhighlight lang="shell">
find /lib/modules -name "*.dep" | awk -v FS=/ ' {system("sudo dracut -f --kver " $4)}'
</syntaxhighlight>

==== Bash functions with parameters instead of alias ====
See https://askubuntu.com/questions/666130/bash-alias-with-parameters for background. Basically, aliases cannot part out parameters positionally as with a shell script; bash just expands the alias and anything else on the command line is parsed subsequently. So doing clever things like using a parameter twice in the exmpansion is not going to work with just an alias. If a script is not wanted, an alias is the way to go.

Here is one used to do XML dumps of VMs to a file named for the VM:<syntaxhighlight lang="shell">
dxml() { virsh dumpxml $1 > $1.xml ;}
</syntaxhighlight>As with bash scripts, the <code>$@</code> macro can be used to substiture for "rest of line"

=== Rescue physical disk ===
Once physical disks start throwing bad blocks consistently, it may be best to take an image of the disk and use that to restore to a new volume. However, traditional usage od the <code>dd</code> command will probably not work, since it will give up at the first read error. The best tool for the job is thus <code>[https://www.gnu.org/software/ddrescue/ ddrescue]</code> . This tool implmenets direct, non-cached reads, multiple passes, selectable retries a logging mechaism, generation of a graphical map, detailed progress and more. Until i can make it more generic, here is the script used to rescue the SD card on the PictureFrame Raspberry Pi; the SD card was 12 years old by the time it failed.<syntaxhighlight lang="bash">
#!/bin/bash

# CONFIGURATION
SOURCE_DEVICE="/dev/sdf" # Replace with your source device
DEST_IMAGE="/mnt/rpi/pictureframe/rescue-sdf.img" # Output disk image
LOGFILE="/mnt/rpi/pictureframe/rescue-sdf.log" # Persistent log file
MAX_RETRIES=5 # Number of retry passes
BLOCK_SIZE="512" # Use small blocks to isolate errors

# COLORS (optional for nice output)
GREEN="\e[32m"
YELLOW="\e[33m"
RED="\e[31m"
RESET="\e[0m"

# Check if running as root
if [ "$EUID" -ne 0 ]; then
echo -e "${RED}Please run as root.${RESET}"
exit 1
fi

# Confirm device
echo -e "${YELLOW}About to recover from: ${SOURCE_DEVICE}"
echo -e "Output image: ${DEST_IMAGE}"
echo -e "Log file: ${LOGFILE}${RESET}"
read -rp "Continue? [y/N]: " confirm
[[ "$confirm" != "y" && "$confirm" != "Y" ]] && exit 0

# Initial fast pass: skip errors for speed
echo -e "${GREEN}Starting initial fast copy pass...${RESET}"
ddrescue -f -n -b "$BLOCK_SIZE" "$SOURCE_DEVICE" "$DEST_IMAGE" "$LOGFILE"

# Retry pass: go over bad areas
echo -e "${YELLOW}Retrying failed sectors up to $MAX_RETRIES times...${RESET}"
ddrescue -d -r"$MAX_RETRIES" -b "$BLOCK_SIZE" "$SOURCE_DEVICE" "$DEST_IMAGE" "$LOGFILE"

# Done
echo -e "${GREEN}Recovery completed. Image saved to ${DEST_IMAGE}${RESET}"
</syntaxhighlight>
The utility [https://sourceforge.net/projects/ddrescueview/ ddrescueview] may be used to visualize the map generated in the log file from the run.

[[File:Rescue-sdf-vierw.png|thumb|left|Visualization of rescued volume with some unrecoverable blocks]]

KitsNet Network:LAN:absolut:CAPsMAN Troubleshooting Guide

2026-09-18T21:38:28Z

Psmode:

This guide documents troubleshooting procedures for the KitsNet wireless
infrastructure using MikroTik CAPsMAN.

Controller: '''absolut (CHR)'''
Edge router: '''courvoisier'''
CAP devices: '''able''', '''baker'''

----

== Quick Diagnostic Checklist ==

When wireless problems occur, check the following first:

# Are the CAP devices connected to CAPsMAN?
# Are radios provisioned correctly?
# Are datapaths correct?
# Are clients completing WPA authentication?
# Are DHCP leases being issued?

----

== Verify CAP Registration ==

On the CAPsMAN controller (absolut):

<pre>
/caps-man remote-cap print
</pre>

Expected output:

* able – Run
* baker – Run

If a CAP is missing:

Possible causes:

* wrong controller IP
* CAP locked to another controller
* CAP discovery blocked
* certificate mismatch

----

== Verify Radios and Provisioning ==

Check radio provisioning:

<pre>
/caps-man interface print
</pre>

Expected radios:

* able 2.4 GHz
* able 5 GHz
* baker 2.4 GHz
* baker 5 GHz

If radios are missing:

Check provisioning rules:

<pre>
/caps-man provisioning print
</pre>

Common causes:

* incorrect radio MAC match
* wrong provisioning rule order
* configuration name mismatch

----

== Check Client Associations ==

On the controller:

<pre>
/caps-man registration-table print
</pre>

This shows connected wireless clients.

Important fields:

* signal strength
* TX/RX rate
* interface name

If clients are not appearing:

Possible causes:

* WPA authentication failure
* incorrect security profile
* wrong SSID configuration

----

== Diagnosing 4-Way Handshake Failures ==

Symptoms:

* clients see the SSID but cannot connect
* repeated authentication attempts
* log entries referencing handshake failures

Check controller log:

<pre>
/log print where message~"handshake"
</pre>

Possible causes:

{| class="wikitable"
! Cause !! Description
|-
| Security profile mismatch
| SSID uses wrong WPA2/WPA3 configuration
|-
| Datapath misconfiguration
| bridge or VLAN incorrect
|-
| CAP not synchronized
| radio using stale configuration
|-
| client compatibility issue
| older devices cannot use WPA3
|}

Recommended test:

Temporarily force WPA2 only.

----

== CAP Cannot Discover Controller ==

Check CAP configuration:

On the CAP:

<pre>
/interface wireless cap print
</pre>

Important values:

* enabled: yes
* discovery interface correct
* caps-man-addresses correct

Example:

<pre>
caps-man-addresses: 192.168.15.x
</pre>

Test connectivity:

<pre>
ping 192.168.15.x
</pre>

----

== CAP Locked to Wrong Controller ==

CAPs can be locked to a specific controller.

Check:

<pre>
/interface wireless cap print
</pre>

If necessary unlock:

<pre>
/interface wireless cap set lock-to-caps-man=no
</pre>

----

== Certificate Problems ==

If certificates are used for CAP authentication:

Check controller certificate:

<pre>
/caps-man manager print
</pre>

Check CAP certificate usage:

<pre>
/interface wireless cap print
</pre>

Common issues:

* certificate not copied during migration
* CA mismatch
* expired certificate

----

== Datapath Problems ==

Datapaths determine how traffic flows.

Check datapaths:

<pre>
/caps-man datapath print detail
</pre>

Important field:

* local-forwarding

Interpretation:

{| class="wikitable"
! Value !! Meaning
|-
| yes
| traffic stays on CAP
|-
| no
| traffic tunnels to controller
|}

For KitsNet architecture:

* client traffic should be '''local-forwarded'''
* controller should not carry client traffic

----

== DHCP Problems ==

If clients connect but cannot obtain an IP address:

Check DHCP leases.

On Courvoisier (Guest network):

<pre>
/ip dhcp-server lease print
</pre>

On Radix (main network):

Check LAN DHCP server.

If no leases appear:

Possible causes:

* datapath bridging incorrect
* VLAN mismatch
* firewall blocking broadcast

----

== Signal and RF Issues ==

Check client signal:

<pre>
/caps-man registration-table print stats
</pre>

Key metrics:

* signal
* tx-rate
* rx-rate

Poor signal can cause authentication failures.

----

== CAP Offline ==

If a CAP disappears entirely:

Check device:

<pre>
/system resource print
</pre>

Verify:

* device powered
* Ethernet link up
* bridge port active

----

== Fast Recovery Commands ==

Force CAP reconnection:

On CAP:

<pre>
/interface wireless cap disable
/interface wireless cap enable
</pre>

Restart CAPsMAN:

On controller:

<pre>
/caps-man manager set enabled=no
/caps-man manager set enabled=yes
</pre>

----

== Emergency Fallback ==

If CAPsMAN fails completely, a CAP can run standalone.

On CAP:

<pre>
/interface wireless cap disable
</pre>

Then configure local wireless interfaces.

This restores temporary connectivity until CAPsMAN is repaired.

----

== Monitoring Commands ==

Useful commands during operations:

Controller:

<pre>
/caps-man remote-cap print
/caps-man interface print
/caps-man registration-table print
</pre>

CAP device:

<pre>
/interface wireless cap print
/interface wireless print
/log print
</pre>

----

== Preventative Practices ==

To reduce wireless failures:

* keep RouterOS versions synchronized
* maintain symmetric CAP provisioning
* avoid overlapping channels
* document datapath design
* test migrations on one CAP first

----

== Related Documentation ==

* Wireless Architecture
* CAPsMAN Migration Procedure

KitsNet Network:LAN:absolut:CAPsMAN Operational Commands Cheat Sheet

2026-09-18T21:37:55Z

Psmode:

This page contains the most commonly used RouterOS commands for operating
the KitsNet CAPsMAN wireless infrastructure.

Controller: '''absolut'''
CAP devices: '''able''', '''baker'''

The commands below are intended for quick diagnostics and operational use.

----

== Controller Health ==

Verify CAPsMAN service:

<pre>
/caps-man manager print
</pre>

Expected:

* enabled: yes

Restart CAPsMAN service:

<pre>
/caps-man manager set enabled=no
/caps-man manager set enabled=yes
</pre>

----

== CAP Connectivity ==

List CAP devices connected to the controller:

<pre>
/caps-man remote-cap print
</pre>

Detailed view:

<pre>
/caps-man remote-cap print detail
</pre>

Expected:

* able – Run
* baker – Run

----

== Radio Interfaces ==

View radios managed by CAPsMAN:

<pre>
/caps-man interface print
</pre>

Useful fields:

* radio-mac
* channel
* configuration

----

== Client Associations ==

Show connected wireless clients:

<pre>
/caps-man registration-table print
</pre>

Extended statistics:

<pre>
/caps-man registration-table print stats
</pre>

Important metrics:

* signal
* tx-rate
* rx-rate

----

== Provisioning Rules ==

Check provisioning configuration:

<pre>
/caps-man provisioning print
</pre>

Provisioning determines:

* which SSIDs appear on each radio
* how CAP radios are configured

----

== Wireless Configurations ==

List configuration profiles:

<pre>
/caps-man configuration print
</pre>

Each configuration includes:

* SSID
* channel
* security profile
* datapath

----

== Datapath Verification ==

View datapaths:

<pre>
/caps-man datapath print detail
</pre>

Key field:

* local-forwarding

Interpretation:

{| class="wikitable"
! Value !! Meaning
|-
| yes
| client traffic stays on CAP
|-
| no
| client traffic tunnels to controller
|}

For KitsNet architecture:

* traffic should normally be '''local-forwarded'''

----

== Security Profiles ==

List security settings:

<pre>
/caps-man security print
</pre>

Check for:

* WPA2 / WPA3 settings
* passphrase configuration

----

== Channel Configuration ==

View channel definitions:

<pre>
/caps-man channel print
</pre>

These define:

* frequency
* channel width
* band

----

== Log Monitoring ==

Look for wireless errors:

<pre>
/log print where topics~"caps"
</pre>

Search authentication failures:

<pre>
/log print where message~"handshake"
</pre>

----

== CAP Device Commands ==

Run these on '''able''' or '''baker'''.

Check CAP configuration:

<pre>
/interface wireless cap print
</pre>

Restart CAP mode:

<pre>
/interface wireless cap disable
/interface wireless cap enable
</pre>

Verify wireless interfaces:

<pre>
/interface wireless print
</pre>

----

== DHCP Verification ==

Main WLAN DHCP (Radix):

Verify clients receive leases from Radix.

Guest WLAN DHCP (Courvoisier):

<pre>
/ip dhcp-server lease print
</pre>

----

== RF Diagnostics ==

Check signal quality:

<pre>
/caps-man registration-table print stats
</pre>

Typical signal values:

{| class="wikitable"
! Signal !! Quality
|-
| -40 dBm
| excellent
|-
| -55 dBm
| very good
|-
| -65 dBm
| acceptable
|-
| -75 dBm
| poor
|}

----

== CAP Discovery ==

Verify CAP discovery configuration:

On CAP:

<pre>
/interface wireless cap print
</pre>

Check:

* discovery interface
* caps-man-addresses

----

== Quick Status Dashboard ==

These commands give a quick operational snapshot.

<pre>
/caps-man remote-cap print
/caps-man interface print
/caps-man registration-table print
/caps-man datapath print
</pre>

----

== Safe Recovery Steps ==

If wireless service fails:

1. Restart CAPsMAN
2. Restart CAP radios
3. Verify CAP connectivity
4. Check DHCP leases
5. Review logs

----

== Related Documentation ==

* Wireless Architecture
* CAPsMAN Migration Procedure
* CAPsMAN Troubleshooting Guide

KitsNet Network

2026-09-18T21:36:07Z

Psmode:

__NONUMBERHEADINGS__
Landing page for Network-related material

===Diagrams===

* [http://wiki.kitsnet.us/instaweb/KitsNet_Network.html Network diagram]
* [[KitsNet Network:Diagram2]]

===Wide Area Network===
{{Special:Prefixindex/KitsNet_Network:WAN}}

===Local Area Network===
{{Special:Prefixindex/KitsNet_Network:LAN}}

File:KitsNet Network Diagram.png

2026-09-18T21:32:54Z

Psmode: DrawioEditor

KitsNet Network:Diagram2

2026-09-18T20:54:19Z

Psmode: Created page with "<drawio filename="KitsNet Network Diagram" editmode="inline" alignment="center" alt="v2.0" />"

KitsNet Operations:Builds:Linux:galliano

2026-09-18T20:35:22Z

Psmode: (username removed) (log details removed)

#REDIRECT [[KitsNet Operations:Retired Builds:Linux:galliano]]

KitsNet Operations

2026-09-18T20:31:01Z

Psmode: __NONUMBERHEADINGS__ is the correct directive

__NONUMBERHEADINGS__
=== External Packages ===
{{Special:Prefixindex/KitsNet_Operations:External Packages}}

=== System Build Documents ===
{{Special:Prefixindex/KitsNet_Operations:Builds|hideredirects=yes}}

=== Monitoring the Environment ===
{{Special:Prefixindex/KitsNet_Operations:Monitoring}}

=== Hardware and Physical Assets ===
{{Special:Prefixindex/KitsNet_Operations:HW}}

=== Planning ===
{{Special:Prefixindex/KitsNet_Operations:Planning}}

=== Retired System Build Documents ===
{{Special:Prefixindex/KitsNet_Operations:Retired Builds}}

=== Network stuff ===
[http://wiki.kitsnet.us/instaweb/KitsNet_Network.html Network diagram]

KitsNet Operations

2026-09-18T20:29:21Z

Psmode: Added __NONUMBEREDHEADINGS__

__NONUMBEREDHEADINGS__
=== External Packages ===
{{Special:Prefixindex/KitsNet_Operations:External Packages}}

=== System Build Documents ===
{{Special:Prefixindex/KitsNet_Operations:Builds|hideredirects=yes}}

=== Monitoring the Environment ===
{{Special:Prefixindex/KitsNet_Operations:Monitoring}}

=== Hardware and Physical Assets ===
{{Special:Prefixindex/KitsNet_Operations:HW}}

=== Planning ===
{{Special:Prefixindex/KitsNet_Operations:Planning}}

=== Retired System Build Documents ===
{{Special:Prefixindex/KitsNet_Operations:Retired Builds}}

=== Network stuff ===
[http://wiki.kitsnet.us/instaweb/KitsNet_Network.html Network diagram]

Main Page

2026-09-18T20:21:52Z

Psmode:

__NOTOC__
<div style="width:100%; max-width:none; margin:0;">

<div style="padding:.75rem 1rem; margin:0 0 .8rem 0; border:1px solid #d8dee9; border-radius:8px; background:#f8fafc;">
<div style="font-size:1.8rem; font-weight:600; line-height:1.15;">KitsNet</div>
<div style="margin-top:.2rem; color:#4b5563; line-height:1.4;">
Architecture, build standards, operations, services, networking, and system records.
</div>
</div>

<div style="display:flex; flex-wrap:wrap; gap:.7rem; align-items:stretch;">

<div style="flex:1 1 290px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">VIRTUALIZATION</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KVM|KVM Infrastructure]]</div>
<div style="line-height:1.4; color:#374151;">
KVM architecture, guest creation, operating procedures, and OS-specific Wort build and change records.
</div>
</div>

<div style="flex:1 1 290px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">LINUX PLATFORM</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[Linux|Linux]]</div>
<div style="line-height:1.4; color:#374151;">
KitsNet Linux standards, the [[Linux:Samba AD Factory|AD Factory]], Samba AD DC builds, AD authentication, Veeam integration, and Linux techniques.
</div>
</div>

<div style="flex:1 1 290px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">SYSTEM RECORDS</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KitsNet Operations|KitsNet Operations]]</div>
<div style="line-height:1.4; color:#374151;">
Operational procedures plus the detailed build, configuration, maintenance, monitoring, and change record for individual KitsNet systems and VMs.
</div>
</div>

<div style="flex:1 1 290px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">SERVICE ARCHITECTURE</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KitsNet Services|KitsNet Services]]</div>
<div style="line-height:1.4; color:#374151;">
Higher-level documentation for KitsNet services: what each service does, how it is structured, and which systems implement it.
</div>
</div>

<div style="flex:1 1 290px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">NETWORK</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KitsNet Network|KitsNet Network]]</div>
<div style="line-height:1.4; color:#374151;">
Routing, switching, addressing, DNS, DHCP, wireless, firewalling, remote access, and network topology.
</div>
</div>

<div style="flex:1 1 290px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">VMS / OPENVMS</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[VMS|VMS]]</div>
<div style="line-height:1.4; color:#374151;">
KitsNet VMS and OpenVMS systems, configuration, operating procedures, and system-specific documentation.
</div>
</div>

</div>

<div style="display:flex; flex-wrap:wrap; gap:.45rem; margin-top:.8rem; padding:.65rem .75rem; border:1px solid #d8dee9; border-radius:8px; background:#f8fafc; font-size:.92rem;">
<div style="white-space:nowrap;">[[Linux:Tips and Tricks|'''Linux Tips & Tricks''']]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[[Special:AllPages|All pages]]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[[Special:RecentChanges|Recent changes]]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[[Our Home|Our Home]]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[https://wiki.kitsnet.us/internet Internet Connectivity Status]</div>
</div>

</div>

Main Page

2026-09-18T20:20:50Z

Psmode:

__NOTOC__
<div style="width:100%; max-width:none; margin:0;">

<div style="padding:.75rem 1rem; margin:0 0 .8rem 0; border:1px solid #d8dee9; border-radius:8px; background:#f8fafc;">
<div style="font-size:1.8rem; font-weight:600; line-height:1.15;">KitsNet</div>
<div style="margin-top:.2rem; color:#4b5563; line-height:1.4;">
Architecture, build standards, operations, services, networking, and system records.
</div>
</div>

<div style="display:flex; flex-wrap:wrap; gap:.7rem; align-items:stretch;">

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">VIRTUALIZATION</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KVM|KVM Infrastructure]]</div>
<div style="line-height:1.4; color:#374151;">
KVM architecture, guest creation, operating procedures, and OS-specific Wort build and change records.
</div>
</div>

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">LINUX PLATFORM</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[Linux|Linux]]</div>
<div style="line-height:1.4; color:#374151;">
KitsNet Linux standards, the [[Linux:Samba AD Factory|AD Factory]], Samba AD DC builds, AD authentication, Veeam integration, and Linux techniques.
</div>
</div>

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">SYSTEM RECORDS</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KitsNet Operations|KitsNet Operations]]</div>
<div style="line-height:1.4; color:#374151;">
Operational procedures plus the detailed build, configuration, maintenance, monitoring, and change record for individual KitsNet systems and VMs.
</div>
</div>

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">SERVICE ARCHITECTURE</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KitsNet Services|KitsNet Services]]</div>
<div style="line-height:1.4; color:#374151;">
Higher-level documentation for KitsNet services: what each service does, how it is structured, and which systems implement it.
</div>
</div>

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">NETWORK</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KitsNet Network|KitsNet Network]]</div>
<div style="line-height:1.4; color:#374151;">
Routing, switching, addressing, DNS, DHCP, wireless, firewalling, remote access, and network topology.
</div>
</div>

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">VMS / OPENVMS</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[VMS|VMS]]</div>
<div style="line-height:1.4; color:#374151;">
KitsNet VMS and OpenVMS systems, configuration, operating procedures, and system-specific documentation.
</div>
</div>

</div>

<div style="display:flex; flex-wrap:wrap; gap:.45rem; margin-top:.8rem; padding:.65rem .75rem; border:1px solid #d8dee9; border-radius:8px; background:#f8fafc; font-size:.92rem;">
<div style="white-space:nowrap;">[[Linux:Tips and Tricks|'''Linux Tips & Tricks''']]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[[Special:AllPages|All pages]]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[[Special:RecentChanges|Recent changes]]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[[Our Home|Our Home]]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[https://wiki.kitsnet.us/internet Internet Connectivity Status]</div>
</div>

</div>

Main Page

2026-09-18T20:18:43Z

Psmode:

__NOTOC__
<div style="max-width:1080px; margin:0 auto;">

<div style="padding:.75rem 1rem; margin:0 0 .8rem 0; border:1px solid #d8dee9; border-radius:8px; background:#f8fafc;">
<div style="font-size:1.8rem; font-weight:600; line-height:1.15;">KitsNet</div>
<div style="margin-top:.2rem; color:#4b5563; line-height:1.4;">
Architecture, build standards, operations, services, networking, and system records.
</div>
</div>

<div style="display:flex; flex-wrap:wrap; gap:.7rem; align-items:stretch;">

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">VIRTUALIZATION</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KVM|KVM Infrastructure]]</div>
<div style="line-height:1.4; color:#374151;">
KVM architecture, guest creation, operating procedures, and OS-specific Wort build and change records.
</div>
</div>

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">LINUX PLATFORM</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[Linux|Linux]]</div>
<div style="line-height:1.4; color:#374151;">
KitsNet Linux standards, the [[Linux:Samba AD Factory|AD Factory]], Samba AD DC builds, AD authentication, Veeam integration, and Linux techniques.
</div>
</div>

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">SYSTEM RECORDS</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KitsNet Operations|KitsNet Operations]]</div>
<div style="line-height:1.4; color:#374151;">
Operational procedures plus the detailed build, configuration, maintenance, monitoring, and change record for individual KitsNet systems and VMs.
</div>
</div>

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">SERVICE ARCHITECTURE</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KitsNet Services|KitsNet Services]]</div>
<div style="line-height:1.4; color:#374151;">
Higher-level documentation for KitsNet services: what each service does, how it is structured, and which systems implement it.
</div>
</div>

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">NETWORK</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[KitsNet Network|KitsNet Network]]</div>
<div style="line-height:1.4; color:#374151;">
Routing, switching, addressing, DNS, DHCP, wireless, firewalling, remote access, and network topology.
</div>
</div>

<div style="flex:1 1 250px; border:1px solid #d8dee9; border-radius:8px; padding:.8rem .9rem; background:#fff;">
<div style="font-size:.72rem; letter-spacing:.07em; color:#64748b; font-weight:700;">VMS / OPENVMS</div>
<div style="font-size:1.18rem; font-weight:600; margin:.15rem 0 .3rem 0;">[[VMS|VMS]]</div>
<div style="line-height:1.4; color:#374151;">
KitsNet VMS and OpenVMS systems, configuration, operating procedures, and system-specific documentation.
</div>
</div>

</div>

<div style="display:flex; flex-wrap:wrap; gap:.45rem; margin-top:.8rem; padding:.65rem .75rem; border:1px solid #d8dee9; border-radius:8px; background:#f8fafc; font-size:.92rem;">
<div style="white-space:nowrap;">[[Linux:Tips and Tricks|'''Linux Tips & Tricks''']]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[[Special:AllPages|All pages]]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[[Special:RecentChanges|Recent changes]]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[[Our Home|Our Home]]</div>
<div style="color:#9ca3af;">•</div>
<div style="white-space:nowrap;">[https://wiki.kitsnet.us/internet Internet Connectivity Status]</div>
</div>

</div>

KitsNet Operations:Planning:Projects

2026-09-16T20:26:57Z

Psmode: Internal IPv6 done

{| class="wikitable sortable col-1-center col-7-center col-8-center col-9-center"
|+
!Priority Tier
!New Server
!Based on
!Activity
!Imperatives
!Notes
!Target Quarter
!Actual Start
!Actual End
|- style="background: #90ee90;" |
|1
|N/A
|[[KVM:host:Wort Operations|Wort]]
|Upgrade to RL 9
|
* Hypervisor at RL 9 could improve guest RL 9 performance
* Hypervisor gets all patches
|
* MegaRAID disks not discoverable by Zabbix-Aget2 due to known bug in old version. Cannot upgrade agent until Zabbix server is upgraded.
|24q4.1
|25q1
|25q1
|- style="background: #90ee90;" |
|9
|N/A
|[[KVM:host:Wort Operations|Wort]]
|CPU upgrade to 5800X
|
|
*Swap 3600X to Kaliber OR
*<s>Take Lafite's CPU after upgrading it with [https://www.amazon.com/AMD-Ryzen-5700X3D-16-Thread-Processor/dp/B0CQ4H4H7X/ref=asc_df_B0CQ4H4H7X/?tag=hyprod-20&linkCode=df0&hvadid=691748717271&hvpos=&hvnetw=g&hvrand=7035893699707595636&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9073502&hvtargid=pla-2275433404761&psc=1&mcid=4551c53272fc349e92b6c0640e115a34&gad_source=4 5800X3D]</s>
|24q4.9
|24q4
|25q1
|- style="background: #90ee90;" |
|4
|[[KitsNet Operations:Builds:Linux:zaya|Zaya]]
|[[KitsNet Operations:Builds:Linux:zoco|Zoco]]
|Upgrade to RL 9
and [https://www.zabbix.com/roadmap Zabbix 7.0 LTS]
|
* Planned release date for Zabbix 7.4 is 2025q2
* Planned release date for Zabbix 8.0 LTS is 2025q4
*See Get Zabbix at https://www.zabbix.com/download?zabbix=7.0&os_distribution=rocky_linux&os_version=9&components=server_frontend_agent&db=mysql&ws=apache
*See Zabbix upgrade procedures at https://www.zabbix.com/documentation/current/en/manual/installation/upgrade
|
|25q2.1
|25.q1
|25.q2
|-
|5
|Zuidam
|[[KitsNet Operations:Builds:Linux:zaya|Zaya]]
|Upgrade to RL 10
and [https://www.zabbix.com/roadmap Zabbix 8.0 LTS]
|
*[https://www.zabbix.com/life_cycle_and_release_policy Zabbix Life Cycle and Release Policy]
**Planned release date for Zabbix 8.0 LTS is 2026q3
* See Zabbix upgrade procedures at https://www.zabbix.com/documentation/current/en/manual/installation/upgrade
|
|26q3.1
|
|
|- style="background: #90ee90;" |
|9
|[[KitsNet Operations:Builds:Linux:delamain|Delamain]]
|[[KitsNet Operations:Retired Builds:Linux:quadsec|Quadsec]]
|Upgrade to RL 10
|
|
*vnstat and glances not yet available
*installed v7 zabbix-agent2 from rehl 9 release
|25q3.2
|25q2
|25q2
|- style="background: #90ee90;" |
|2
|[[KitsNet Operations:Builds:Linux:barcardi|Barcardi]]
|[[KitsNet Operations:Builds:Linux:hendrick|Hendrick]]
|Upgrade to RL 9
|
*Samba Factory should be on RL 9 to build Samba for RL9 systems
|
|24q4.2
|24q3
|24q4
|- style="background: #90ee90;" |
|2
|[[KitsNet Operations:Builds:Linux:galliano|Galliano]]
|[[KitsNet Operations:Retired Builds:Linux:chivas|Chivas]]
|Upgrade to RL 9 and MediaWiki 1.39.12 LTS
|
*MediaWiki 1.35 LTS became end-of-life 21 December 2023.
*See https://www.mediawiki.org/wiki/Manual:Moving_a_wiki
|
|25q1.2
|25q1
|25q2
|- style="background: #90ee90;" |
|2
|[[KitsNet Operations:Builds:Linux:frangelico|Frangelico]]
|[[KitsNet Operations:Builds:Linux:camus|Camus]]
|Upgrade to RL 9
|
*After Hendrick. At same time as Cristal
|Samba upgrade entirely separate, though work included installing a slightly higher version of Samba and joining to the doman.
|24q4.2
|24q3
|24q4
|- style="background: #90ee90;" |
|2
|[[KitsNet Operations:Builds:Linux:emperador|Emperador]]
|[[KitsNet Operations:Retired Builds:Linux:cristal|Cristal]]
|Upgrade to RL 9
|
*After Hendrick. At same time as Camus
|Samba upgrade entirely separate
|24q4.2
|24q3
|25q1
|- style="background: #90ee90;" |
|3
|[[KitsNet Operations:Builds:Linux:frangelico|Frangelico]]
|[[KitsNet Operations:Builds:Linux:camus|Camus]]
|Upgrade to latest Samba
|
*<s>Fix Mac password changing issue (hopefully)</s>
|*Need to create Protected Users security group (https://www.samba.org/samba/history/samba-4.17.0.html)
*Fucntional level (https://www.samba.org/samba/history/samba-4.20.0.html and https://wiki.samba.org/index.php/AD_Schema_Version_Support)<syntaxhighlight lang="shell-session">
To raise the domain functional level of an existing domain, after
updating the smb.conf and restarting Samba run
samba-tool domain schemaupgrade --schema=2019
samba-tool domain functionalprep --function-level=2016
samba-tool domain level raise --domain-level=2016 --forest-level=2016
</syntaxhighlight>
|25q1.2
|25q1
|25q1
|- style="background: #90ee90;" |
|3
|[[KitsNet Operations:Builds:Linux:emperador|Emperador]]
|[[KitsNet Operations:Retired Builds:Linux:cristal|Cristal]]
|Upgrade to latest Samba
|
*<s>Fix Mac password changing issue (hopefully)</s>
|
|25q1.2
|25q1
|25q1
|- style="background: #90ee90;" |
|3
|[[KitsNet Operations:Builds:Linux:cinzano|Cinzano]]
|[[KitsNet Operations:Builds:Linux:ballantine|Ballantine]]
|Upgrade to RL 9 and eFa 5.0
|
|
|25q1.3
|25q1
|25q2
|- style="background: #90ee90;" |
|3
|[[KitsNet Operations:Builds:Linux:tito|Tito]]
|[[KitsNet Operations:Builds:Linux:campari|Campari]]
|Upgrade to RL 9 and latest Samba
|
|
* SSO access is via Samba itself, including automatic directory creation
|25q2.3
|25q1
|25q1
|- style="background: #90ee90;" |
|3
|[[KitsNet Operations:Builds:Linux:hennessy|Hennessy]]
|[[KitsNet Operations:Builds:Linux:martell|Martell]]
|Upgrade to RL 9 and latest Samba
|
*Frequent error messages regarding chdir actions appear with execution of Windows backup operations. Supposed to be addressed with newer Samba version.
|
*Setup as an AD member server along with NFS exports
*VM NIC needs be built over kvm-bkup bridge
|25q2.3
|25q1
|25q1
|- style="background: #90ee90;" |
|3
|[[KitsNet Operations:Builds:Linux:sinfire|Sinfire]]
|[[KitsNet Operations:Builds:Linux:fireball|Fireball]]
|Upgrade to RL 9 and latest Samba
|
|Did get Emby upgrade as well
|25q2.3
|25q1
|25q1
|- style="background: #90ee90;" |
|4
|[[KitsNet Operations:Builds:Linux:empress|Empress]]
|[[KitsNet Operations:Builds:Linux:okeefe|Okeefe]]
|Upgrade to RL 10
|
|ConsoleWorks server v5.6-4u0 does not really support Rocky LInux 10. Some hacking of TDI scripts was required.
| 25q2,z
| 25q2
| 25q2
|- style="background: #90ee90;" |
|4
|[[KitsNet Operations:Builds:Linux:maddog|Maddog]]
|[[KitsNet Operations:Retired Builds:Linux:ripple|ripple]]
|Upgrade to RL 9
|
|simh build/run server for VAX
|25q2.4
|25q2
|25q2
|- style="background: #90ee90;" |
|2
|
| [[KitsNet Network:WAN:radix|Radix]]
| Upgrade to OpenWrt 24.10 stable version
|
*Currently OpenWrt 22.03.05 stable version
|Updated to 24.1.2
|25q4.2
|25q3
|25q4
|- style="background: #90ee90;" |
|9
|
|DONQ
|<s>decommission AlphaServer</s>
|
*VSI shutdown hobbyist program for Alpha and HP licenses won't run on VSI OpenVMS for Alpha
|<s>Could consider VAX-only VAXcluster</s>
Dealt with license issue
|24q4.z
|24q4
|24q4
|- style="background: #90ee90;" |
|6
|
|
|Establish docker farm
|
*Could recast most servers as Docker containers
|ChatGPT design and deployment plan built
|26q1.6
|26q1
|26q3
|- style="background: #90ee90;" |
|5
|[[KitsNet Operations:Builds:Linux:fox|fox]]
[[KitsNet Operations:Builds:Linux:anchor|anchor]]
|
|HA NAS storage for Docker farm
|
* Needed as portable HA storage solution for container instances
|ChatGPT design and deployment plan built based on one set of vdisks on KVM host being presented by one of two NFS servers with coordinated failover. This will support continuous availability so as to support server maintenance operations, without doubling storage requirements.
|26q1.5
|26q1
|26q1
|- style="background: #90ee90;" |
|3
|
|[[KVM:host:Wort Operations|Wort]]
|Storage expansion
|
* Only about 1 TB remains available and Docker farm will need at least that much
* T0 pool is too small at 512MB as most has been used
|
* <s>Expansion of T0 to 2TB NVMe likely to cost about $170 with Samsung 990 EVO Plus 2TB .</s> T0 expansion cancelled due to drive cost explosion

* T1 expansion will aim for a matched pair of 4TB Seagate Seagate Iron Wolf Pro drives
* T3 expansion used surplut WD Red Pro
|26q1.3
|26q1
|26q1
|- style="background: #90ee90;" |
|4
|
|[[KVM:host:Wort Operations|Wort]]
|Storage expansion cabinet
|
* Current plans call for using up all available drive slots but one
* Design accounted for cabinet based on Jonsbo N4 - need to buy this before product is retired
* Could only implement single SAS link between cabinets due to available port shortage in main cabinet
|Current wort will need added:

* Dual Mini SAS SFF-8088 to SAS36P SFF-8087 Adapter in PCI Bracket
* SFF-8087 to SFF-8087 internal SAS cables (2)

External cables

* SFF-8088 to SFF-8088 external SAS cables (2)

The new cabinet will be the Jonsbo N4 outfitted with:

* Dual Mini SAS SFF-8088 to SAS36P SFF-8087 Adapter in PCI Bracket
* Mini SAS to 4 SATA Cable, 36 Pin SFF 8087 Host/Controller to 7 Pin SATA Target/Backplane connection
* modest power supply
|26q2.4
|26q1
|26q1
|- style="background: #90ee90;" |
|1
|Lafite
|Lafite
|Windows 11
|
*Windows 10 EOL October 2025
|Need to upgrade before Kaliber so I can support Mandy
|24q2.1
|24q4
|24q4
|- style="background: #90ee90;" |
|2
|N/A
|Kaliber
|Windows 11
|
*Windows 10 EOL October 2025
|Upgrade storage to 1TB NVMe prior to upgrade
Profiles hosted off of C: drive blocked upgrade
Still need to reinstall RGB utilities
|25q2.2
|25q1
|25q3
|- style="background: #90ee90;" |
|2
|N/A
|Sriracha
|Windows 11
|
*Windows 10 EOL October 2025
|Might move this up or down
|25q2.2
|25q4
|25q4
|- style="background: #90ee90;" |
|1
|N/A
|[[KVM:host:Wort Operations|Wort]]
|New chasis
|
*new case will allow for 12 drives without need for second case
|
*Jonsbo n5 chasis
*RAID expander card
*For T3b volume
**add fourth disk
**<s>convert Raid 5 to RAID 10</s>
*Cannot start unitl n5 case delivered. Scheduled for 3rd week of January 2025
|25q1.1
|25q1
|25q1
|- style="background: #90ee90;" |
|1
| N/A
|Lafite
|Replumb loop
|
* add drain port and reroute piping for better circulation through reservoir
|
|24q4.1
|25q1
|25q1
|- style="background: #90ee90;" |
|2
|Absolut
|
|Standalone CAPSMAN
|
*Will allow for removal of the Wireless package from Courvoisier and free up storage space
*Upcoming RouterOS updates my not fit without this relief
|New deployment plan developed with ChatGPT
| 26q1.2
|25q3
|26q1
|- style="background: #90ee90;" |
|5
|[[KitsNet Network:WAN:radix|Radix]]
|
|Tailscale VPN
|
* Supported VPN solution for full remote access. Improvement over SSH and will allow devices full KitsNet access remotely.
|
|26q2.5
|26q3
|26q3
|- style="background: #90ee90;" |
|4
|
|[[KitsNet Network:WAN:radix|Radix]]
|Internal IPv6 support
|
*The LAN simply uses automatic configuration at Layer 2. Before we can implement external support for IPv6, IPv6 on the LAN needs to be cleaned up and fully implemented.
|Need to setup a full internal support of IPv6 router announcements, explicit DHCP support of the ULA and delegated prefix, DUID (???) and more. This will also include implementation of RA Guard to block the Apple TV and HomePod Mini to advertising themselves as IPv6 routers. I have a deployment design and a multi-stage implementation plan supplied by ChatGPT.
|26q1.4
|26q3
|26q3
|-
|5
|
|[[KitsNet Network:WAN:radix|Radix]]
|External IPv6 support
|
*Implement NAT66 and DDNS updates so that KitsNet services may be addressed vi IPV4 or IPv6.
|Dependant upon Internal IPv6 support
|26q2.5
|
|
|- style="background: #90ee90;" |
|2
|[[KitsNet Operations:Builds:Linux:cinzano|Cinzano]]
|
|Migrate from eFa-Project to Promox Mail Gateway
|
*eFa-Project went end of life in 2025. Maintainer has shut it down
*[https://www.proxmox.com/en/products/proxmox-mail-gateway/overview Promox Mail Gateway] is closest to a drop-in replacement
*will deploy as Debian VM appliance
|
|26q2.2
|26q2
|26q3
|}