first create the file /etc/sudoers.d/sudo_secure_path with these contents

# sudo secure path configuration
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

then to set the correct permissions run

sudo chmod 0440 /etc/sudoers.d/sudo_secure_path

Here is my Devuan project:
https://git.devuan.org/ovi/devuan-knowledge_base

I added what I had on my notes text files and my purpose is to be a generic information and maybe what people would general use.

You'd run into the same issue if you wanted to use slock or i3lock or any other screenlocker.

Gemini has this to say:

But it is far from neat enough to share for public use and the to-do-list is still long, so cleaning up has not reached top-prio.
I therefore applaud this effort to make knowledge available.

I will try to bring it to an usable form, in time. I have in mind users like me, that are new to Linux and Devuan especially, or migrated from another distribution and that want to know more about the Devuan Operating System, in general.
I know that Devuan has its own wiki, but it just doesn't fit for my project idea and also I don't like it, to be honest.

There are many good, general topics inside the forum that can have place in my devuan-knowledge_base. I will look for them and add them there.

So, who knows, maybe over one, two years if somebody from Devuan team consider that the content make sense for the general public, the repo will be always there.Just take the public folder, correct, throw away what is unecessary and that's all.
If somebody wants to have a look time to time, criticize, add corrections, ideas, etc. I would be glad to hear them. Is only one package to install.
But not so soon , there is nothing inside yet, just a sketch with some blank pages.

Finally, my strong opinion is that any good product needs to have a simple HandBook, accessible to anyone.

From the get-go, I was looking for a straightforward way to transfer files, preferably not involving Samba shares or complex server-client setups with encryption, compression etc. I researched several solutions, some of them seemed more feasible than others. To my surprise, finding a program capable of doing simple LAN transfers between different systems was not an easy task. Some of them could not be used because they were no longer supported on Windows 7 side, some worked but only one way (Win7 > Linux) because they detected wrong IP address due to a bug and had no manual way of setting up things. Some even required Internet access because they used a relay that could not be disabled!

Oh well. With patience and some trial and error, I eventually found a program called LanXchange, which works beautifully. It's not the prettiest or most featureful thing in existence, but it does its job very well.

To use it, you need to install Java Runtime Environment (JRE). You can get it via default-jre package in Excalibur repos, or from Eclipse Adoptium using this guide. I just got the repo version, while on Win7 I'm using the latter.

Unpack and launch LanXchange on both machines. On Windows, lxc.exe complained that I do not have Java installed, but the .jar file worked - so if you get the same error, just try that. On Linux side, use the provided lxc script. You can also run the .jar directly like this:

$ java -jar lanxchange.jar

but I noticed that it sometimes causes issues with incoming transfers not appearing until you unshare your previous files. Not a big problem, but I still recommend using the script.

Next, if you use a firewall like gufw, you will need to allow the following incoming ports: 27716, 27717, 27719. Create two separate 'Simple' rules both for TCP and UDP. On Windows, you probably don't need to do anything other than click 'Allow access' once.

So that's it! Now it should work - nothing beats sending files via a nice fat cable just like in the old days. Enjoy the speed and simplicity (and less wear for your USB Flash devices). Thanks to this wonderful program, I was able to forgo Samba entirely. I did not look into other solutions such as NFS, SFTP or a Python server - they do seem interesting though, so might experiment with them later as well.

It has on the desktop in prominent place :

* Release notes
* README_desktop-live.txt
* REAME.txt

Except from basic info they basically link to online help.

Devuan and Artix livecd that i tested they resort to plain text file as an entry help system. Interesting.

OS ▸  Debian GNU/Linux Trixie x86_64
       BD++++D+D+::::::+D                               Kernel ▸  Linux 6.19.14-2-liquorix-amd64
      D+-::::=D+::::::::+BBDD+                          Uptime ▸  1 hour, 52 mins
     D=::::::=B=-::::::=BB++=+D                         Processes ▸  327
     D-:::::=BDD=-::-=+B=-::::=D                        Packages ▸  2217
     B+--==+++===++BDD+:::::::-D                        Window Manager ▸  dwm (XLibre)
   DB+++==:::::::::-+D-:::::::=D                        Shell ▸  zsh 5.9
  D=:::::::::::::::::++:::::-+D                         Terminal ▸  xterm 409
D+::::::::::::::::::+D++==+BD+                         Terminal Font ▸  JetBrains Mono Nerd Font:style=Regular (11pt)
  D=:::::::::::::::::+BD+=--:-+D                        Terminal Theme ▸  ● ● ● ● ● ● ● ●
   B+=-::::::::::::::B+-::::::=D                        Brightness ▸  100% [Built-in]
    DBB++-::::::::::-D:::::::-+D                        CPU ▸  12 x AMD Ryzen 7 7445HS
        DB+:::::::::+D=-:::-=+D                         GPU ▸  GeForce RTX 4050 Max-Q / Mobile
          D=:::::::-D +BDBBD+                           GPU ▸  AMD Radeon 740M Graphics
           B+--::-=D                                    RAM ▸  2.39 GiB / 14.88 GiB (16%)
            +BDBDD+                                     Swap ▸  0 B / 7.45 GiB (0%)
                                                        Disk ▸  1.09 TiB / 1.78 TiB (61%) - ext4

To answer a few questions I see in this thread.  For me XLibre performance is about 6-7% better than with non-XLibre.  Like many here, I am not a fan of Wayland- I ran it for a year to give it a test... and if I only ran a single wm without conky, I could make it work.  But I run with dwm,i3wm,openbox and choose not survive with a crippled conky (maybe its fixed these days; I don't know).   Should I use systemd... just to answer that item, I need my stupid VRAM (nVidia) to work because I run a local AI on my machine- for lots of reasons that would probably get this note thrown off here.  Suffice it to say, nVidia is necessary for resilience and grandsons- not optional and nVidia is also blindingly painful, but I have it working. Yay.

In general, the politics alluded to here re: XLibre are a pretty obvious issue for some folks.  I have not personally encountered any problems.  So, it's alright so far.  For any who would like to see my stupid-simple XLibre install it's freely available here: 

https://codeberg.org/eirenicon/dwm-XLibre

btw. it is worth every penny you paid for it, as well.

To be fair this is not a definitive protection but another countermeasure to reduce drastically the risks from such attacks when using public IPs.

# As a complementary measure you should NOT allow ssh root login using password but using ssh key in worst case escenario, to do that change the settings for sshd:

sudo nano /etc/ssh/sshd_config

# Uncomment the #PermitRootLogin line like:
PermitRootLogin prohibit-password

# Install packages:

sudo apt install -y fail2ban lnav python3-pyinotify

# Verify connection attemps

sudo lnav /var/log/auth.log

# You will see very often lines like:
<date> - <time> <hostname> sshd[pid]: Failed password for root from xxx.xxx.xxx.xxx port xxxx ssh2 <--- Brute force attack

# and also when you connect you will see a line like this:
<date> - <time> <hostname> sshd[pid]: Accepted publikey for <youruser> from <your.isp.public.ip> port xxxxx ssh2: EDxxxx <--- If you are using ssh keys instead of password this is you.
<date> - <time> <hostname> sshd-session[pid]: Accepted password for <youruser> from <your.isp.public.ip> port 39284 ssh2 <--- Or if you still using password authentication.
# We will whitelist this IP <your.isp.public.ip> just in case since we will use a very strict ban criteria/time.

# Press q to exit

# Create Local Configuration to preserve settings during updates.

sudo nano /etc/fail2ban/jail.local

# Configure SSH Protection, we will use 3 attemps to block earlier than 5 attemps and for 3 hours but later you can increase the bantime if you notice the same IP addresses repeating again and again:
[DEFAULT]
# Whitelist your own IP address (space-separated)
ignoreip = 127.0.0.1/8 ::1 <your.isp.public.ip>

[sshd]
backend = auto
enabled = true
maxretry = 3
bantime = 3h
findtime = 10m   

# Restart fail2ban service

sudo service fail2ban restart

# Verify ssh jail status

sudo fail2ban-client status sshd

# You will see something like:

Status for the jail: sshd
|- Filter
|  |- Currently failed:	1
|  |- Total failed:	5
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	6
   |- Total banned:	6
   `- Banned IP list:	2.57.122.189 2.57.122.192 45.148.10.147 45.148.10.151 45.148.10.157 92.118.39.236

   
# Now if you verify connection attemps again
sudo lnav /var/log/auth.log

You will notice the attemps wont repeat from the same IP since the moment fail2ban was restarted, keep it running and eventually they will realize is not worthy to keep trying or they will run out of public IPS or you can also increase the time if the same IP address keep showing up.

To add an extra layer of protection you can also enable 2FA with oathtool to make ssh ask for 6 digits code before you can enter any password, that way the attack never even begins since the client gets disconnected and banned when doens't provide a valid 6 digits code to begin with the login attemp, link to guide below.

[HowTo] 2FA TOTPs for SSH without google-authenticator.

Edited on April-29-2026, steps above tested on Devuan 5, but for Devuan 6 these 2 changes below are required:
Added package to install: python3-pyinotify
Added: backend = auto

Navigate to the upstream repository

Navigate to the Hyprshot GitHub repository for the source files and installation instructions. This guide is based on that repository, customized for Devuan.

Install dependencies

Install the dependencies mentioned in the Hyprshot repository, alongside the dunst notification daemon.

$ su -
# apt install jq grim slurp wl-clipboard libnotify-bin dunst
# exit

Creating the optimal directory for manually installed user scripts

For a manual installation (downloading the script directly), place it in a directory that is in your user's $PATH. The most common and recommended location is ~/.local/bin.

$ mkdir -p ~/.local/bin

If this directory does not exist or is not in your PATH, you will need to create it and add it to your shell's configuration file (e.g., ~/.bashrc or ~/.zshrc).

Clone Hyprshot source code into created directory

$ git clone https://github.com/Gustash/hyprshot.git ~/.local/bin/Hyprshot

Symbolically make the script executable

Create a symbolic link to make the script executable from anywhere.

$ cd ~/.local/bin
$ ln -s $(pwd)/Hyprshot/hyprshot $HOME/.local/bin
$ chmod +x Hyprshot/hyprshot

Restarting your system and testing the command

After completing the installation, restart your system to ensure all changes, environment variables, and the PATH are properly loaded.

$ su -
# reboot

To test Hyprshot, log in, open a terminal and run a command to capture a specific element, such as:

$ hyprshot -m window

This command will change your cursor, allowing you to click on any window to take a screenshot. If successful, the screenshot will be saved to your XDG_PICTURES_DIR (typically ~/Pictures) and copied to the clipboard. You can test other modes like -m region for a custom area or -m output for a full monitor.

Login as a root user

su - cleanly resets all environment variables, changes the working directory to the target user's home directory, and sources the target user's profile scripts, simulating a fresh login as root:

su -

Enable 32-bit architecture support

Steam requires 32-bit architecture support libraries and proprietary components, so enable it:

dpkg --add-architecture i386

Enable non-free & contrib repository sources

The Steam installer package resides in the contrib repository, and the non-free repository provides the essential 32-bit (i386) graphics drivers, Mesa libraries, and other hardware-specific components required for Steam to function and for games to run correctly. Ensure that both repositories are active in your sources list for your release. Depending on which source list is currently active on your PC, fill in the following information on one of these files:

1. Within /etc/apt/sources.list:

deb http://deb.devuan.org/merged ceres main non-free non-free-firmware contrib

2. Within /etc/apt/sources.list.d/devuan.sources:

# Modernized from /etc/apt/sources.list
Types: deb
URIs: http://deb.devuan.org/merged/
Suites: ceres
Components: main non-free non-free-firmware contrib
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpg

Update repositories and install Steam

After enabling the required repositories, update your package lists:

sudo apt update

Install the steam-installer package using:

sudo apt install steam-installer

Install and set up xwayland

The Steam client requires xwayland to run on a Wayland session because the Steam client itself is an X11-only application and lacks native Wayland support. If you're experiencing a display crash or the "Could not open connection to X" error, it's likely because Steam cannot connect to an X server. Currently, under a Wayland session, this is handled by xwayland, which acts as a compatibility layer allowing X11 applications like Steam to run.

Install xwayland via:

sudo apt install xwayland

Verify xwayland is active by running by printing the value of the $DISPLAY enviroment variable. This should return :0:

echo $DISPLAY

If the DISPLAY variable is not set, you can set it manually. The command export DISPLAY=:0 sets the DISPLAY environment variable to :0, telling graphical (a la X11) applications to render their graphical interface on the first local display (screen 0) of the local X server:

export DISPLAY=:0

Restart Wayland session

Restart your Wayland session to ensure xwayland starts with the compositor; an easy way to do that for Hyprland specifically would be:

hyprctl dispatch exit
dbus-run-session start-hyprland

Launch Steam

Finally, launch Steam from the application menu or via the terminal:

steam

By following these steps, you should be able to install and run Steam on your Devuan system using a Wayland-based desktop environment like Hyprland.