Lychee - Revision history

Wikisailor: /* Introduduction */

2026-02-02T04:25:59Z

Introduduction

← Older revision		Revision as of 04:25, 2 February 2026
Line 2:		Line 2:

	Lychee is the Linux desktop that will be used as a '''[[Remote Access Terminal \| remote desktop]]'''. The host is on the '''[[Remote Access Terminal \| Terminals network]]''' with a IP address of x.x.x.10. The main purpose of the '''[[Virtual Machines \| Virtual Machine]]''' is to allow access to a desktop inside the '''[[Home Lab]]''' virtual network on Pear, using NoMachine.		Lychee is the Linux desktop that will be used as a '''[[Remote Access Terminal \| remote desktop]]'''. The host is on the '''[[Remote Access Terminal \| Terminals network]]''' with a IP address of x.x.x.10. The main purpose of the '''[[Virtual Machines \| Virtual Machine]]''' is to allow access to a desktop inside the '''[[Home Lab]]''' virtual network on Pear, using NoMachine.

			'''Update Feb 2026''' '''[[Lychee]]''' has been destroyed to make way for a new Linux desktop.

	===Upated Evolving Role===		===Upated Evolving Role===

Wikisailor: /* Introduduction */

2025-06-10T21:17:00Z

Introduduction

← Older revision		Revision as of 21:17, 10 June 2025
Line 1:		Line 1:
	==Introduduction==		==Introduduction==

	Lychee is the Linux desktop that will be used as a '''[[Remote Access Terminal \| remote desktop]]'''. The host is on the '''[[Remote Access Terminal \| ~~terminals~~ network]]''' with a IP address of x.x.x.10. The main purpose of the '''[[Virtual Machines \| Virtual Machine]]''' is to allow access to a desktop inside the '''[[Home Lab]]''' virtual network on Pear, using NoMachine.		Lychee is the Linux desktop that will be used as a '''[[Remote Access Terminal \| remote desktop]]'''. The host is on the '''[[Remote Access Terminal \| Terminals network]]''' with a IP address of x.x.x.10. The main purpose of the '''[[Virtual Machines \| Virtual Machine]]''' is to allow access to a desktop inside the '''[[Home Lab]]''' virtual network on Pear, using NoMachine.

	===Upated Evolving Role===		===Upated Evolving Role===

Wikisailor: /* Docker Installation with N8N & NPM leading to Letsencrypt Wildcard SSL Cert */

2025-06-10T13:04:40Z

Docker Installation with N8N & NPM leading to Letsencrypt Wildcard SSL Cert

← Older revision		Revision as of 13:04, 10 June 2025
Line 15:		Line 15:
	It was felt that N8N would be a good method of creating a few agents within the network. N8N is installed as a Docker image and we started to install on Walnut However, it quickly became apparent that we would need a separate proxy on the N8N host to terminate a SSL connection or at least it is not so easy to get N8N to terminate a SSL connection to satisfy Cloudflare's strict mode. the first solution was to have a separate revers proxy on walnut hat would be able to terminate a SSL connection. NPM was selected to do this so it was installed on walnut but the remote access still didn't work even from within the LAN. At this point it was becoming difficult to diagnose exactly where the fault/s were because we had walnut (a virtual machine) hosting docker over the Linus emulator that was in turn hosting N8N and NPM and then traffic was being fwd'ed from Walnut to NPM as SSL and NPM would be terminating that connection then calling N8N on a HTTP connection on port 80. So to simplify the install it was decided to use Lychee as the host for N8N.		It was felt that N8N would be a good method of creating a few agents within the network. N8N is installed as a Docker image and we started to install on Walnut However, it quickly became apparent that we would need a separate proxy on the N8N host to terminate a SSL connection or at least it is not so easy to get N8N to terminate a SSL connection to satisfy Cloudflare's strict mode. the first solution was to have a separate revers proxy on walnut hat would be able to terminate a SSL connection. NPM was selected to do this so it was installed on walnut but the remote access still didn't work even from within the LAN. At this point it was becoming difficult to diagnose exactly where the fault/s were because we had walnut (a virtual machine) hosting docker over the Linus emulator that was in turn hosting N8N and NPM and then traffic was being fwd'ed from Walnut to NPM as SSL and NPM would be terminating that connection then calling N8N on a HTTP connection on port 80. So to simplify the install it was decided to use Lychee as the host for N8N.

	The advantage of using Lychee as the N8N host is that it will support Docker directly with no WSL2 layer to complicate anything. Eventually it did become apparent that it would be a lot easier if there was a separate SSL cert to Cloudflare as we still got the termination issues and still extra problems caused by using Cloudflare's origin certs locally, so it was decided to obtain a SSL cert from Letsencrypt . Once the decision was made the follow on decision was made to make it a wildcard cert rather than do individual SAN certs as this would give a lot of flexibility in the future for other projects. The details of getting the a wildcard Letsencrypt cert can be found '''[[Letsencrypt Wildcard SSL Cert \| here]]'''. ~~the~~ details of installing Docker with N8N and NPM can be found '''[[Docker Installation with N8N & NPM \| here]]'''		The advantage of using Lychee as the N8N host is that it will support Docker directly with no WSL2 layer to complicate anything. Eventually it did become apparent that it would be a lot easier if there was a separate SSL cert to Cloudflare as we still got the termination issues and still extra problems caused by using Cloudflare's origin certs locally, so it was decided to obtain a SSL cert from Letsencrypt . Once the decision was made the follow on decision was made to make it a wildcard cert rather than do individual SAN certs as this would give a lot of flexibility in the future for other projects.
			* The details of getting the a wildcard Letsencrypt cert can be found '''[[Letsencrypt Wildcard SSL Cert \| here]]'''.
			* The details of installing Docker with N8N and NPM can be found '''[[Docker Installation with N8N & NPM \| here]]'''

Wikisailor: /* Docker Installation with N8N & NPM leading to Letsencrypt Wildcard SSL Cert */

2025-06-10T13:00:58Z

Docker Installation with N8N & NPM leading to Letsencrypt Wildcard SSL Cert

← Older revision		Revision as of 13:00, 10 June 2025
Line 15:		Line 15:
	It was felt that N8N would be a good method of creating a few agents within the network. N8N is installed as a Docker image and we started to install on Walnut However, it quickly became apparent that we would need a separate proxy on the N8N host to terminate a SSL connection or at least it is not so easy to get N8N to terminate a SSL connection to satisfy Cloudflare's strict mode. the first solution was to have a separate revers proxy on walnut hat would be able to terminate a SSL connection. NPM was selected to do this so it was installed on walnut but the remote access still didn't work even from within the LAN. At this point it was becoming difficult to diagnose exactly where the fault/s were because we had walnut (a virtual machine) hosting docker over the Linus emulator that was in turn hosting N8N and NPM and then traffic was being fwd'ed from Walnut to NPM as SSL and NPM would be terminating that connection then calling N8N on a HTTP connection on port 80. So to simplify the install it was decided to use Lychee as the host for N8N.		It was felt that N8N would be a good method of creating a few agents within the network. N8N is installed as a Docker image and we started to install on Walnut However, it quickly became apparent that we would need a separate proxy on the N8N host to terminate a SSL connection or at least it is not so easy to get N8N to terminate a SSL connection to satisfy Cloudflare's strict mode. the first solution was to have a separate revers proxy on walnut hat would be able to terminate a SSL connection. NPM was selected to do this so it was installed on walnut but the remote access still didn't work even from within the LAN. At this point it was becoming difficult to diagnose exactly where the fault/s were because we had walnut (a virtual machine) hosting docker over the Linus emulator that was in turn hosting N8N and NPM and then traffic was being fwd'ed from Walnut to NPM as SSL and NPM would be terminating that connection then calling N8N on a HTTP connection on port 80. So to simplify the install it was decided to use Lychee as the host for N8N.

	The advantage of using Lychee as the N8N host is that it will support Docker directly with no WSL2 layer to complicate anything. Eventually it did become apparent that it would be a lot easier if there was a separate SSL cert to Cloudflare as we still got the termination issues and still extra problems caused by using Cloudflare's origin certs locally, so it was decided to obtain a SSL cert from Letsencrypt . Once the decision was made the follow on decision was made to make it a wildcard cert rather than do individual SAN certs as this would give a lot of flexibility in the future for other projects. The details of getting the a wildcard Letsencrypt cert can be found '''[[Letsencrypt Wildcard SSL Cert \| here]]'''. the details of installing Docker with N8N and NPM can be found ''[[Docker Installation with N8N & NPM \| here]]'''		The advantage of using Lychee as the N8N host is that it will support Docker directly with no WSL2 layer to complicate anything. Eventually it did become apparent that it would be a lot easier if there was a separate SSL cert to Cloudflare as we still got the termination issues and still extra problems caused by using Cloudflare's origin certs locally, so it was decided to obtain a SSL cert from Letsencrypt . Once the decision was made the follow on decision was made to make it a wildcard cert rather than do individual SAN certs as this would give a lot of flexibility in the future for other projects. The details of getting the a wildcard Letsencrypt cert can be found '''[[Letsencrypt Wildcard SSL Cert \| here]]'''. the details of installing Docker with N8N and NPM can be found '''[[Docker Installation with N8N & NPM \| here]]'''

Wikisailor: /* Docker install with N8N & NPM leading to letsencrypt wildcard SSL Cert */

2025-06-10T12:52:12Z

Docker install with N8N & NPM leading to letsencrypt wildcard SSL Cert

← Older revision		Revision as of 12:52, 10 June 2025
Line 11:		Line 11:
	Nothing to add yet as the GPU is still on Walnut so not installed Jellyfin yet. Some of the the files will be copied over in anticipation.		Nothing to add yet as the GPU is still on Walnut so not installed Jellyfin yet. Some of the the files will be copied over in anticipation.

	==Docker ~~install~~ with N8N & NPM leading to ~~letsencrypt wildcard~~ SSL Cert==		==[[Docker Installation with N8N & NPM]] leading to [[Letsencrypt Wildcard SSL Cert]]==

	It was felt that N8N would be a good method of creating a few agents within the network. N8N is installed as a Docker image and we started to install on Walnut However, it quickly became apparent that we would need a separate proxy on the N8N host to terminate a SSL connection or at least it is not so easy to get N8N to terminate a SSL connection to satisfy ~~cloudflare~~'s strict mode. the first solution was to have a separate revers proxy on walnut hat would be able to terminate a SSL connection. NPM was selected to do this so it was installed on walnut but the remote access still didn't work even from within the LAN. At this point it was becoming difficult to diagnose exactly where the fault/s were because we had walnut (a virtual machine) hosting docker over the Linus emulator that was in turn hosting N8N and NPM and then traffic was being fwd'ed from Walnut to NPM as SSL and NPM would be terminating that connection then calling N8N on a HTTP connection on port 80. So to simplify the install it was decided to use Lychee as the host for N8N.		It was felt that N8N would be a good method of creating a few agents within the network. N8N is installed as a Docker image and we started to install on Walnut However, it quickly became apparent that we would need a separate proxy on the N8N host to terminate a SSL connection or at least it is not so easy to get N8N to terminate a SSL connection to satisfy Cloudflare's strict mode. the first solution was to have a separate revers proxy on walnut hat would be able to terminate a SSL connection. NPM was selected to do this so it was installed on walnut but the remote access still didn't work even from within the LAN. At this point it was becoming difficult to diagnose exactly where the fault/s were because we had walnut (a virtual machine) hosting docker over the Linus emulator that was in turn hosting N8N and NPM and then traffic was being fwd'ed from Walnut to NPM as SSL and NPM would be terminating that connection then calling N8N on a HTTP connection on port 80. So to simplify the install it was decided to use Lychee as the host for N8N.

	The advantage of using Lychee as the N8N host is that it will support Docker directly with no WSL2 layer to complicate anything. Eventually it did become apparent that it would be a lot easier if there was a separate SSL cert to Cloudflare as we still got the termination issues and still extra problems caused by using Cloudflare's origin certs locally, so it was decided to obtain a SSL cert from Letsencrypt. Once the decision was made the follow on ~~decicion~~ was made to make it a wildcard cert rather than do individual SAN certs as this would give a lot of flexibility in the future for other projects. The details of getting the a wildcard Letsencrypt cert can be found here. the details of installing Docker with N8N and NPM can be found here		The advantage of using Lychee as the N8N host is that it will support Docker directly with no WSL2 layer to complicate anything. Eventually it did become apparent that it would be a lot easier if there was a separate SSL cert to Cloudflare as we still got the termination issues and still extra problems caused by using Cloudflare's origin certs locally, so it was decided to obtain a SSL cert from Letsencrypt . Once the decision was made the follow on decision was made to make it a wildcard cert rather than do individual SAN certs as this would give a lot of flexibility in the future for other projects. The details of getting the a wildcard Letsencrypt cert can be found '''[[Letsencrypt Wildcard SSL Cert \| here]]'''. the details of installing Docker with N8N and NPM can be found ''[[Docker Installation with N8N & NPM \| here]]'''

Wikisailor: /* Docker install with N8N & NPM leading to letsencrypt wildcard SSL Cert */

2025-06-10T12:24:40Z

Docker install with N8N & NPM leading to letsencrypt wildcard SSL Cert

← Older revision		Revision as of 12:24, 10 June 2025
Line 13:		Line 13:
	==Docker install with N8N & NPM leading to letsencrypt wildcard SSL Cert==		==Docker install with N8N & NPM leading to letsencrypt wildcard SSL Cert==

	It was felt that N8N would be a good method of creating a few agents within the network. N8N is installed as a Docker image and we started to install on Walnut However, it quickly became apparent that we would need a separate proxy on the N8N host to terminate a SSL connection or at least it is not so easy to get N8N to terminate a SSL connection to satisfy		It was felt that N8N would be a good method of creating a few agents within the network. N8N is installed as a Docker image and we started to install on Walnut However, it quickly became apparent that we would need a separate proxy on the N8N host to terminate a SSL connection or at least it is not so easy to get N8N to terminate a SSL connection to satisfy cloudflare's strict mode. the first solution was to have a separate revers proxy on walnut hat would be able to terminate a SSL connection. NPM was selected to do this so it was installed on walnut but the remote access still didn't work even from within the LAN. At this point it was becoming difficult to diagnose exactly where the fault/s were because we had walnut (a virtual machine) hosting docker over the Linus emulator that was in turn hosting N8N and NPM and then traffic was being fwd'ed from Walnut to NPM as SSL and NPM would be terminating that connection then calling N8N on a HTTP connection on port 80. So to simplify the install it was decided to use Lychee as the host for N8N.

			The advantage of using Lychee as the N8N host is that it will support Docker directly with no WSL2 layer to complicate anything. Eventually it did become apparent that it would be a lot easier if there was a separate SSL cert to Cloudflare as we still got the termination issues and still extra problems caused by using Cloudflare's origin certs locally, so it was decided to obtain a SSL cert from Letsencrypt. Once the decision was made the follow on decicion was made to make it a wildcard cert rather than do individual SAN certs as this would give a lot of flexibility in the future for other projects. The details of getting the a wildcard Letsencrypt cert can be found here. the details of installing Docker with N8N and NPM can be found here

Wikisailor at 10:59, 10 June 2025

2025-06-10T10:59:19Z

← Older revision		Revision as of 10:59, 10 June 2025
Line 6:		Line 6:

	The Proxmox host, '''[[Proxmox Server \| Pear]]''' does have a fairly large CPU and RAM available it's resources are not infinite and as Lychee will be used for remote access it will need to have a better CPU and RAM added than the regular VMs it will need to be used for other things when not in use as a remote desktop. One of those extra roles will be as a Jellyfin server instead of Walnut, when Nvidia have GPU drivers available for Linux. Another role that it has already taken on is as a N8N server, more details can be found Here. The main additional facility that will be made available to the host is the GPU, when we can we will pass the PCIE to Lychee using the same notes as were used for doing that to Walnut, some notes have been made and are available '''[[GPU PCI Pass Through \| here]]'''. With the evolving role Lychee has moved to Production and has a new IP x.x.x.27		The Proxmox host, '''[[Proxmox Server \| Pear]]''' does have a fairly large CPU and RAM available it's resources are not infinite and as Lychee will be used for remote access it will need to have a better CPU and RAM added than the regular VMs it will need to be used for other things when not in use as a remote desktop. One of those extra roles will be as a Jellyfin server instead of Walnut, when Nvidia have GPU drivers available for Linux. Another role that it has already taken on is as a N8N server, more details can be found Here. The main additional facility that will be made available to the host is the GPU, when we can we will pass the PCIE to Lychee using the same notes as were used for doing that to Walnut, some notes have been made and are available '''[[GPU PCI Pass Through \| here]]'''. With the evolving role Lychee has moved to Production and has a new IP x.x.x.27

			==Jellyfin==

			Nothing to add yet as the GPU is still on Walnut so not installed Jellyfin yet. Some of the the files will be copied over in anticipation.

			==Docker install with N8N & NPM leading to letsencrypt wildcard SSL Cert==

			It was felt that N8N would be a good method of creating a few agents within the network. N8N is installed as a Docker image and we started to install on Walnut However, it quickly became apparent that we would need a separate proxy on the N8N host to terminate a SSL connection or at least it is not so easy to get N8N to terminate a SSL connection to satisfy

Wikisailor at 09:09, 10 June 2025

2025-06-10T09:09:44Z

← Older revision		Revision as of 09:09, 10 June 2025
Line 3:		Line 3:
	Lychee is the Linux desktop that will be used as a '''[[Remote Access Terminal \| remote desktop]]'''. The host is on the '''[[Remote Access Terminal \| terminals network]]''' with a IP address of x.x.x.10. The main purpose of the '''[[Virtual Machines \| Virtual Machine]]''' is to allow access to a desktop inside the '''[[Home Lab]]''' virtual network on Pear, using NoMachine.		Lychee is the Linux desktop that will be used as a '''[[Remote Access Terminal \| remote desktop]]'''. The host is on the '''[[Remote Access Terminal \| terminals network]]''' with a IP address of x.x.x.10. The main purpose of the '''[[Virtual Machines \| Virtual Machine]]''' is to allow access to a desktop inside the '''[[Home Lab]]''' virtual network on Pear, using NoMachine.

			===Upated Evolving Role===

	~~'''Update''' Lychee has moved to Production and has a new IP x.x.x.27~~		The Proxmox host, '''[[Proxmox Server \| Pear]]''' does have a fairly large CPU and RAM available it's resources are not infinite and as Lychee will be used for remote access it will need to have a better CPU and RAM added than the regular VMs it will need to be used for other things when not in use as a remote desktop. One of those extra roles will be as a Jellyfin server instead of Walnut, when Nvidia have GPU drivers available for Linux. Another role that it has already taken on is as a N8N server, more details can be found Here. The main additional facility that will be made available to the host is the GPU, when we can we will pass the PCIE to Lychee using the same notes as were used for doing that to Walnut, some notes have been made and are available '''[[GPU PCI Pass Through \| here]]'''. With the evolving role Lychee has moved to Production and has a new IP x.x.x.27

	~~==Evolving Role==~~

	The Proxmox host, '''[[Proxmox Server \| Pear]]''' does have a fairly large CPU and RAM available it's resources are not infinite and as Lychee will be used for remote access it will need to have a better CPU and RAM added than the regular VMs it will need to be used for other things when not in use as a remote desktop. One of those extra roles will be as a Jellyfin server instead of Walnut, when Nvidia have GPU drivers available for Linux. Another role that it has already taken on is as a N8N server, more details can be found Here. The main additional facility that will be made available to the host is the GPU, when we can we will pass the PCIE to Lychee using the same notes as were used for doing that to Walnut, some notes have been made and are available '''[[GPU PCI Pass Through \| here]]'''

Wikisailor: /* Evolving Role */

2025-06-09T21:07:41Z

Evolving Role

← Older revision		Revision as of 21:07, 9 June 2025
Line 8:		Line 8:
	==Evolving Role==		==Evolving Role==

	The Proxmox host, '''[[Proxmox Server \| Pear]]''' does have a fairly large CPU and RAM available it's resources are not infinite and as Lychee will be used for remote access it will need to have a better CPU and RAM added than the regular VMs it will need to be used for other things when not in use as a remote desktop. One of those extra roles will be as a Jellyfin server instead of Walnut, when Nvidia have GPU drivers available for Linux. Another role that it has already taken on is as a N8N server, more details can be found Here		The Proxmox host, '''[[Proxmox Server \| Pear]]''' does have a fairly large CPU and RAM available it's resources are not infinite and as Lychee will be used for remote access it will need to have a better CPU and RAM added than the regular VMs it will need to be used for other things when not in use as a remote desktop. One of those extra roles will be as a Jellyfin server instead of Walnut, when Nvidia have GPU drivers available for Linux. Another role that it has already taken on is as a N8N server, more details can be found Here. The main additional facility that will be made available to the host is the GPU, when we can we will pass the PCIE to Lychee using the same notes as were used for doing that to Walnut, some notes have been made and are available '''[[GPU PCI Pass Through \| here]]'''

Wikisailor: /* Introduduction */

2025-06-09T14:37:48Z

Introduduction

← Older revision		Revision as of 14:37, 9 June 2025
Line 1:		Line 1:
	==Introduduction==		==Introduduction==

	Lychee is the Linux desktop that will be used as a '''[[Remote Access Terminal \| remote desktop]]'''. The host is on the '''[[Remote Access Terminal \| terminals network]]''' with a IP address of x.x.x.10. The main purpose of the '''[[Virtual Machines \| Virtual Machine]]''' is to allow access to a desktop inside the virtual network on Pear, using NoMachine.		Lychee is the Linux desktop that will be used as a '''[[Remote Access Terminal \| remote desktop]]'''. The host is on the '''[[Remote Access Terminal \| terminals network]]''' with a IP address of x.x.x.10. The main purpose of the '''[[Virtual Machines \| Virtual Machine]]''' is to allow access to a desktop inside the '''[[Home Lab]]''' virtual network on Pear, using NoMachine.