Running Node App as systemd Service

In this post we will be using systemd to run a node application. This is helpful as it will automatically start the app when the server starts so we don’t have to manually. These steps can easily be modified to run a bash script, or any other application.

  • Create systemd file
  • Customize systemd file
  • Enable systemd file

We’ll be creating a service for the Simple Whisper Web Interface as an example. Chang things as needed.

Create systemd file

This is super simple. We create a .service file in /lib/systemd/system. When we enable the service, it will create a symlink to this file.

sudo vim /lib/systemd/system/whisperweb.service

Customize systemd file

Change the settings as appropriate. It would be a good idea to run any service as a limited user that only has the rights needed to get the job done. Do note that you will need to have any prerequisites installed and available for that user to use. I.e. libraries installed with npm etc.

[Unit]
Description=Simple Whisper Web Interface Service File
After=network.target

[Service]
Type=simple
User=whisperuser
ExecStart=/usr/bin/node mainssl.js
WorkingDirectory=/home/whisperuser/
Restart=on-failure

[Install]
WantedBy=multi-user.target

Enable systemd file

Enabling the service will create a symlink that will then run this service file on system boot.

sudo systemctl enable whisperweb.service

And now we can start the service.

sudo systemctl start whisperweb.service

We can verify that the service is running by running

sudo systemctl status whisperweb.service

The following article has some great explanations on what different options in the unit file mean and do.

https://nodesource.com/blog/running-your-node-js-app-with-systemd-part-1/

Creating a Simple systemd Service to Launch Shell Script on System Boot

We will setup a simple systemd service to automatically run a bash script on system boot.

Create systemd file

Create the service file with

vi /etc/systemd/system/multi-user.target.wants/bashscript.service

Now fill out the file. Change the Description and ExecStart. After= means only start this unit after the other units have finished. This is needed if we need to make a network connection. If our script runs before the network is up, the connection will fail.

[Unit]
Description=systemd Unit File to Launch Bash Script on System Boot
After=network.target
After=syslog.target

[Install]
WantedBy=multi-user.target

[Service]
ExecStart=/home/user/script.sh

Change the ExecStart to your bash script and save the file

Enable systemd file

Now that the file is created, we need to enable the service so it starts on system boot

systemctl enable bashscript.service

You should get the following output.

Created symlink /etc/systemd/system/multi-user.target.wants/bash.service → /etc/systemd/system/bash.service.

Now to test, reboot your system, or start the service with

systemctl start bashscript.service

How to Bypass NVIDIA NVENC Limits on RTX Cards on Linux

It appears that NVIDIA has limited the number of NVEncoding streams on consumer GPUs. Guess it is so people have to buy the more expensive professional cards.

Fortunately, the limit is only applied to the driver, and there is a patch available that let’s us bypass the limiter.

https://github.com/keylase/nvidia-patch

Install Patch

This assumes you already have the driver installed. If you do not, or run into issues with the commands below, refer to the above link.

Download the tool

https://github.com/keylase/nvidia-patch/archive/refs/heads/master.zip

wget https://github.com/keylase/nvidia-patch/archive/refs/heads/master.zip

Unzip the file

unzip nvidia-patch-master.zip

Run the patch script

cd nvidia-patch-master
sudo bash ./patch.sh

And we are finished!

Further reading

NVIDIA has a matrix of which cards support how many streams etc.

https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new

And while we are on the topic of artificial limits, check out the vGPU license bypass

https://github.com/KrutavShah/vGPU_LicenseBypass

Exim Troubleshooting Email Logs

The following is a great article explaining the main Exim log.

https://forums.cpanel.net/resources/reading-and-understanding-the-exim-main_log.383/

The following are some helpful tips from the post.

Search log by email address

You can search for specific addresses with the exigrep. Replace email@address with the email address of interest.

exigrep email@address /var/log/exim_mainlog

Message Direction

Looking at entries in the main log, some of the messages will have an indicator from the following table that tell us the status of the message and/or where it came from or went.

<=Indicates the arrival of a message to Exim for handling
=>Shows a normal message delivery
->Additional address for the same delivery, i.e. an Email forwarder.
>>cutthrough is a router precondition
This option requests delivery be attempted while the item is being received. It is usable in the RCPT ACL and valid only for single-recipient mails forwarded from one SMTP connection to another. If a recipient-verify callout connection is requested in the same ACL it is held open and used for the data, otherwise one is made after the ACL completes.
*>delivery suppressed by -N
**delivery failed; address bounced
==delivery deferred; temporary problem
<>For “<>” from the exim manual; Additionally, you will often find A bounce message is shown with the sender address “<>”, and if it is locally generated, this is followed by an item of the form
R=<message id>

Some other posts that may be helpful while troubleshooting mail deliveries.

View messages by ID

Bulk Delete Messages in Queue

Unable to launch Flatpaks on Fedora using Hardened Kernel

If you have installed the hardened Linux Kernel on Fedora, you may have encountered the following error when trying to launch Flatpak applications.

bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.
error: Failed to sync with dbus proxy

https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do

https://github.com/containers/bubblewrap/issues/324

The issue looks to arise from the fact that the hardened Linux Kernel disables unprivileged name space and Fedora does not have setuid on by default on the bubblewrap executable.

Enabling setuid on bubblewrap

You can set the setuid permission on the bubblewrap executable with

sudo chmod u+s /usr/bin/bwrap

Allow Unprivileged Name Space (Alternative work around)

You could also allow unprivileged name space by running

sysctl kernel.unprivileged_userns_clone=1

Note that setting the setuid seems the safer/recommended option.

It looks like using the setuid binary for bubblewrap would be better to use then enabling unprivileged user space.

https://madaidans-insecurities.github.io/guides/linux-hardening.html#sysctl-kernel

Remove setuid on bubblewrap

If you would like to remove the setuid permission for any reason, you can with the following command.

sudo chmod u-s /usr/bin/bwrap

Dual Zones in Firewalld (Public/Private or External/Internal)

In Firewalld we can use multiple zones for different types of traffic. For instance, we can setup an “internal” zone with our local IP addresses that are trusted, and then setup the public facing interface to the “drop” or “block” zone to block everything not from our internal network.

  1. Setup trusted IP addresses in the “internal” zone
  2. Configure services/ports that should be allowed on our “internal” zone
  3. Set “drop” zone as the default for all other traffic
  4. Reload firewall

1. Setup trusted IP addresses in “internal” zone

Add all of our trusted IP addresses to the internal zone. The following example adds all of the private IP addresses “RFC 1918” to the internal zone. Change as needed.

firewall-cmd --zone=internal --add-source=192.168.0.0/16 --add-source=172.16.0.0/12 --add-source=10.0.0.0/8 --permanent

2. Configure services/ports that should be allowed on our “internal” zone

Next we need to specify which services or ports should be accessible in our trusted zone.

Here is an example to allow https, ssh, and cockpit services

firewall-cmd --zone=internal --add-service=https --add-service=ssh --add-service=cockpit --permanent 

Here is an example to allow port 8080 tcp

firewall-cmd --zone=internal --add-port=8080/tcp --permanent

3. Set “drop” zone as the default for all other traffic

The final configuration piece we need to do is set the default zone. Anything not specified in other zones will get processed by the default zone.

firewall-cmd --set-default-zone=drop

The drop zone drops everything.

4. Reload firewall

Reload the firewall with

firewall-cmd --reload


Verifying changes

Let’s verify the changes with the firewall-cmd –get-active-zones command

# firewall-cmd --get-active-zones
drop
  interfaces: en0
internal
  sources: 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8

You can also use

firewall-cmd --list-all-zones

to list all the zones. Active zones show (active) next to them.

You can verify that your changes worked by doing an internal and external nmap scan.

If you have issues with services still being accessible from the outside, try disabling Network Manager for that specific interface

You can edit the ifcfg-eth0 file and add

NM_CONTROLLED=no

Invalid privacy protocol specified after -3x flag: DES

With REHL 9 and AlmaLinux 9 and presumably other RedHat derivative, DES is no longer available for net-snmp communication. DES or Data Encryption Standard is an old encryption standard and has been superseded by AES.

So when you try running snmpwalk with “-x DES” option, you get the following error

Invalid privacy protocol specified after -3x flag: DES
USAGE: snmpwalk [OPTIONS] AGENT [OID]

  Version:  5.9.1

To fix the issue, you’ll need to upgrade your devices to AES.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/considerations_in_adopting_rhel_9/assembly_shells-and-command-line-tools_considerations-in-adopting-rhel-9#ref_changes-to-system-management_assembly_shells-and-command-line-tools

https://serverfault.com/questions/1119288/snmp-des-algorithm-no-longer-working

Installing Basic Linux tools on AlmaLinux 9 (tar, wget, htop)

The local team wizard Mark, ran into some issues while trying to setup a system with AlmaLinux 9. Tar wasn’t installed! What?! No worries. We can solve this by just installing tar with dnf. While we are at it, lets install some other helpful utilities.

sudo dnf install -y tar wget htop

Tada! We are back in business.

CentOS – This system is not registered with an entitlement server. You can use subscription-manager to register.

If you are getting the following response when trying to use the yum or dnf command,

This system is not registered with an entitlement server. You can use subscription-manager to register.

Try editing the subscription-manager.conf file, and disable it by changing enable=1 to enable=0

sudo nano /etc/yum/pluginconf.d/subscription-manager.conf

After you may run

yum clean

That should take care of the problem.

https://serverfault.com/questions/764900/how-to-remove-this-warning-this-system-is-not-registered-to-red-hat-subscriptio

https://sahlitech.com/entitlement-server-fix/

Named Error “option ‘dnssec-enable’ no longer exists”

After a recent update, the named service stopped working. When manually trying to restart the service it would just fail.

Running the named-checkconf command

sudo /usr/bin/named-checkconf -z /etc/named.conf

Returned the following error.

/etc/named.conf:37: option 'dnssec-enable' no longer exists

Looks like what happened is they removed the dnssec-option, but enabled it by default

The dnssec-enable option has been obsoleted and no longer has any effect. DNSSEC responses are always enabled if signatures and other DNSSEC data are present. [GL #866]

https://bind9.readthedocs.io/en/v9_16/notes.html#id118

So the option is invalid now and not needed.

To fix the issue, simply open up the /etc/named.conf file and delete the line that has ‘dnssec-enable’