Differences

This shows you the differences between two versions of the page.

--- blocks:server:virtualized [2024-06-25 15:52] – Recommend to use net-blocks admin
+++ blocks:server:virtualized [2025-09-05 20:10] (current) – Deleted admin
@@ Line 1: / Line 1: @@
-======Virtual Server Installation======
-Blocks works well on virtual servers, whether "in the cloud" or on premise. For such environments, you generally don't want the graphical user interface provided by our standard Linux server image. Running Blocks in a virtualized environment often have different priorities than those using a stand-alone server. Furthermore, some of the features included in the full server Linux image (such as the DHCP server) are then typically managed by other parts of the infrastructure.
-There are two methods available for getting Blocks up and running in a virtual environment:
-  - Installation from scratch using our cloud server installation scripts (recommended).
-  - Installing a bare-bones Blocks server based on a OVA server image file (described below).
-In most cases, installing the server using our [[https://github.com/pixilab/net-blocks|server installation scripts]] offers the best mix of features, flexibility and control. Hence, this is the recommended method.
-The method described below uses an standard "virtual application file" for installing a bare-bones Blocks server in a virtual environment such as Oracle VirtualBox or VMWare. This is suitable for internal testing purposes, if you're running virtual machines on your laptop or similar.
-:!: This is an advanced guide, descibing an unsupported method for running Blocks. If you don't feel at home in a Linux terminal window, you're strongly advised to use our [[blocks:linux|standard Linux server image]] instead.
-===Minimal Server OS===
-The virtual server image discussed here runs is based on Debian, without any desktop environment. Thus, all system management and maintenance must be done from the command line. Most of the additional functions included with our standard Linux serve rimage are not included here.
-===No Webmin interface===
-The user-friendly, web-based //webmin// frontend is not included. While you may install webmin also on a virtual server, the assumption is that you likely prefer configuring the server directly, using the various configuration files traditionally used by server administrators.
-===No DHCP server===
-There's no pre-configured DHCP server. When used as part of a virtualized server infrastructure, you likely already have a DHCP server in your system, and don't want the Blocks server to act as one.
-===No DNS server===
-The same applies for the DNS server. While the software is included also in the virtualized server image, it has not been pre-configured and is not enabled.
-=====Virtual Environment=====
-This image is designed to be used in a virtualized environment. It is distributed as an [[https://pixilab.se/outgoing/blocks/virtualized/Blocks6-Debian10.ova|OVA file]], compatible with most virtual hosts from VMWare, Oracle, Synology and QNAP. The image is based on Debian 10, and includes Blocks software and all components required to run Blocks. For testing purposes, you can use one of the following:
-  * Oracle [[https://www.virtualbox.org/wiki/Downloads|VirtualBox]] – a free virtual machine available for most operating systems
-  * VMWare's popular "VMWare Fusion" application.
-After importing the OVA file into your virtualizer of choice, start it up and wait for the login screen to appear.
-=====Users and Passwords=====
-For full system access, log in with the user name **root**, with password //pixi//. This **root** user can do anything without restrictions, so be careful. Use this user for for system software installation, upgrades, etc requiring super-user privileges. The password can be changed using the //passwd// command.
-User name **blocks**, with default password //PixiServer!// is the account under which the Blocks server is run. This user has limited rights, and can not use the sudo command to escalate its privileges (you can, however, use the //su// command to switch to the root user). The password can be changed by the root user using the //passwd blocks// command.
-=====Network Configuration=====
-On the Host computer, running VirtualBox (or other preferred virtualizer), add a Bridged adapter as the primary one. You may need to shut down the Blocks server while changing network settings.
-====Guest Linux OS terminal window====
-Find the network interface name and verify connectivity.
-  * Use the command //ip addr// to see all network interfaces with their names. Ignore the //lo// loopback interface.
-  * The name is typically something like //enp0s3//.
-  * If the interface is already UP, and you have internet access, you're done
-  * Verify internet access by using the command //ping 1.1.1.1//, that should show the turn-around time in mS repeatedly if OK.
-===Verify/Add Network Adapter Settings===
-If you didn't automatically get network access, you need to configure networking inside the virtual Blocks server. Settings are specified in the **/etc/network/interface.d** directory.
-If required, add a file there and name it //primary// (although the actual file name isn't important). Enter the following data into the file. You can do so using the simple terminal text editor //nano//.
-<code>
-auto enp0s3
-allow-hotplug enp0s3
-iface enp0s3 inet dhcp
-</code>
-Use the actual name of your interface in the file instead of //enp0s3//, if different.
-These settings result in a dynamic address, suitable for testing purposes. Since the interface is bridged, the virtual machine will get a network address from your local network, assuming there's a DHCP server. For real server purposes, you should change this file to assign a static address instead (see below).
-:!: Do not use a wifi network interface, since that will typically not provide a dynamic address to the virtual machine.
-Alternatively, to use a fixed IP address instead, edit the //primary// file discussed above to read something like this (specifying IP addresses and subnet width as appropriate for your network):
-<code>
-auto enp0s3
-allow-hotplug enp0s3
-iface enp0s3 inet static
-    address 192.168.0.31/24
-    gateway 192.168.0.1
-    dns-nameservers 1.1.1.1 8.8.8.8
-</code>
-After making changes, restart the virtual machine using //reboot now// or merely restart the networking stack by
-//systemctl restart networking//.
-=====License Access=====
-Blocks server software requires a license to be operational. Either connect a physical license key to a USB port or request a cloud-based license (requires internet access). A physical license key can be accessed either directly from a USB port attached to the virtual machine or over the local network.
-[[blocks:wibu|Install a Blocks license.]]
-=====Blocks Configuration=====
-There's no [[blocks:server_configuration_file|configuration file]] included for Blocks in the VM image. This means that Blocks defaults to HTTP over port 8080. Add a configuration file if you need to adjust Blocks' server settings. Note that since Blocks runs under a limited user account, ports below 1024 (thus including the default HTTP port 80) can't be directly specified in the configuration file. However, the included //nginx// program – acting as a reverse proxy – provides access to Blocks on the customary ports (80 and 443 if you have HTTPS enabled). More on //nginx// and HTTPS below.
-=====Starting and Stopping Blocks=====
-Assuming that the license key is accessible, Blocks should start automatically. Blocks is started and stopped by an operating system service known as //[[https://wiki.debian.org/systemd|systemd]]//, which is controlled by the //systemctl// command line program. Since Blocks runs under the //blocks// user account, you must be logged in as the //blocks// user in order to control Blocks using //systemctl//. Use this command to determine whether Blocks is currently active:
-<code>
-systemctl --user status blocks
-</code>
-If Blocks is currently active, you should see the text "Active: active (running)" as part of the status. To enable and start Blocks, use this command:
-<code>
-systemctl --user enable --now blocks
-</code>
-To stop and disable Blocks:
-<code>
-systemctl --user disable --now blocks
-</code>
-Note that //systemd// differentiates between //starting// and //enabling// a service. The command shown above will do both. An //enabled// service will automatically be started as the server computer is started, which is useful f you for some reason need to restart your Blocks server (e.g., as the result of a power outage). To merely start or stop a service, without changing its enablement, use the //start// and //stop// sub-commands instead. See the //systemd// documentation for details.
-If you run into trouble launching Blocks, and the //status// command doesn't provide sufficient details, you can use the //journalctl// command to obtain more details:
-<code>
-journalctl -n 20 --no-pager --user-unit blocks
-</code>
-This will show the 20 most recent //systemd// log messages related to blocks. Again, you must be logged in as the //blocks// user in order to use this command.
-=====Using HTTPS with Blocks=====
-The server image includes [[http://nginx.org|nginx]], acting as a reverse proxy in front of Blocks. This can be configured to manage secure HTTPS connections, as described [[blocks:server:nginx|here]].
-=====Security Considerations=====
-This section describes some security considerations. You don't need to do any of this to get a functioning Blocks system.
-===Secure Shell Remote Access (SSH)===
-Secure Shell is not enabled in the VM image. SSH may be useful for many system configuration and remote access purposes. If desired, enable SSH in the VM's console window using the command //systemctl enable ssh// while running as the root user. Before enabling SSH, set a strong password for the blocks user account. The root account is not enabled for SSH access. This can be changed in the file /etc/ssh/sshd_config (not recommended).
-===Firewall===
-The firewall is not enabled in the VM image. Very few services are enabled, so you may not need a firewall since only the required ports are exposed. Feel free to [[https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu-20-04|configure and enable]] the pre-installed //ufw// firewall if desired. Or, even better, use an external firewall in your IT infrastructure.