Posts by kaiyel

kaiyel · Devuan

When exposing an SSH port to the Internet, I highly recommend a "security in layers" approach.

Layer 1 : Move the SSH service to a non-standard port to reduce some of the scan burden
Layer 2 : Start the SSH service via xinetd instead of initd with "only_from" source IP limits
Layer 3 : Disallow direct root login via SSH requiring the use of a lesser privileged intermediate account
Layer 4 : Create a "wheel" group and only allow lesser privileged "wheel" members to "su" or "sudo"

What other layers would you folks add?
--K

kaiyel · Other Issues

And for comparison ... SysVinit has 0 open issues : https://codeberg.org/thejessesmith/sysvinit/issues

"If it ain't broke, don't fix it"

--K

kaiyel · Devuan

I've read statements like this :

But the other half of that "harsh reality" is that SysV init is something for hobbyist

made elsewhere, and I continue to disagree emphatically. I've been a Linux system administrator, professionally, for decades ... not one, not two, but three. I cut my teeth on Slackware and evolved with RedHat. Now I use Devuan. Why am I here? Largely because SysVinit "just works". It's solid, stable, reliable, secure, and does the minimal amount required to achieve those goals. It "does one thing well" and is the gold standard by which all other init systems are measured even today.

If runit, or any of the others, rises to SysVinit's level, I happily encourage their use. But that is a high bar to reach.

Labeling SysVinit as a "hobbyist" tool is not remotely accurate in any Linux history book. It was, and is, bedrock upon which Linux emerged as a player in the arena. The "harsh reality", if there is one, is that SysVinit was foundational for every professional Linux sysadmin today having a little gray in his beard. It works as well today as it did then, and it still works better than many/most of its competing init systems depending upon the criteria being measured.

That being said, when RedHat replaced SysVinit with upstart, I hardly even noticed, and felt no inclination to move to another distribution. I immediately felt that inclination when systemd became the forced standard. RedHat forced me, a veteran sysadmin, to either start with a new distribution or abandon the stability, reliability, and security I was accustomed to. I was expecting to return to Slackware before Devuan arrived on the scene. And Devuan has been exceptionally good.

There is room for other quality init systems and maybe runit falls into that category as upstart did. I started reading this thread mainly to see if other gray beards felt it to be so.

Cheers,
--K

kaiyel · Desktop and Multimedia

"I stopped chasing perfection in favor of consistency."

Same here. I landed on Mate after stability issues with Cinnamon ages ago and have used it as my daily driver for years. I'm also a fan of XFCE. If I could get Mate to stop rearranging the icons in the desktop panel periodically between logins, it would be about perfect. Not much pizzazz, but everything I need to get work done with months (year?) between reboots.

Cheers,
--K

kaiyel · Documentation

When editing in "vi" it is common practice for me to hit "i"nsert, highlight a block of text, and click the middle-mouse button to paste the selected text at the insert position. That worked well during my years in the RedHat ecosystem. Transitioning to Devuan, I discovered the default vim installation intercepted mouse clicks to implement cursor movement inside the document. Clicking to highlight a block of text moved the cursor from the original insert point and made a mess of the document on paste.

My quick-n-dirty solution was to delete the "defaults.vim" from "/usr/share/vim/vimNN/" to reset to a barebones vim configuration that did not set a mouse mode. But that was not a robust solutions that survived updates, so I made it a goal to dig deeper and my solution evolved to create a "/etc/vim/vimrc.local" with the following contents :

" Tell Devuan to stop overriding this file with defaults.vim
let g:skip_defaults_vim = 1

" Eliminate source of RCE/malicious text file security/resource exploits
set nomodeline

" Prevent startup scripts from executing shell code or writing files
set secure

" Prevent leaking sensitive data into local directories via swap files
set noswapfile

" Turn syntax highlighting back on safely
if has("syntax")
  syntax on
endif

" Prevent vim from intercepting mouse events handled by X11/Wayland
if has("mouse")
  set mouse=
endif

" Global 2-space tab configuration
" Use :retab in vim to replace tabs with spaces in existing documents
set tabstop=2
set shiftwidth=2
set expandtab

" Core essential editing behaviors stripped by skipping defaults
" hlsearch:   Highlight all matches when searching text
" incsearch:  Show search matches instantly as you type
" backspace:  Make the Backspace key work normally over line breaks
" scrolloff:  Show context above/below cursor when scrolling
" nowrap:     Prevent line wrap with an infinitely long right edge
set hlsearch
set incsearch
set backspace=indent,eol,start
set scrolloff=3
set nowrap

If anyone has had similar experience and tweaked "/etc/vim/vimrc.local" further for safety, security, or efficiency please chime in.

This guide was very helpful to me discerning the settings : https://danmc.net/posts/2019/vim-config-1/

Cheers,
--K

kaiyel · Installation

Did you try editing :

/etc/pam.d/common-session
/etc/pam.d/common-session-noninteractive

and update the "pam_umask.so" line to read :

session optional pam_umask.so usergroups umask=077

I believe the default UMASK settings for sessions has been moved out of /etc/login.defs and into pam.d settings.
--K

kaiyel · Documentation

Thank you, abower! I look forward to one less tweak following an install

--K

kaiyel · Off-topic

In retrospect perhaps our "technology leaders" should not have taken the decentralized network we call the Internet and centralized the crap out of it. But will we have learned from this? Doubt it.

kaiyel · News & Announcements

Wonderful !!! Thanks Devuan Peeps !!!

kaiyel · Off-topic

Here's the kernel thread :

https://lore.kernel.org/lkml/2024102316 … ernel.org/

Of the comments, Borislav Petkov reveals the underlying concern and emerging challenge :

I just love it how this went in without a single x86 maintainer Ack, it broke
a bunch of things and then it is still there instead of getting reverted.
Let's not do this again please.
--
Regards/Gruss,
Boris.

We could do with a bit more of the old L.T. management style verbally smacking younglings doing dumb things. Boris was too kind.

Cheers,
--K

kaiyel · Other Issues

There are times when I need to clear DNS cache quickly as well ... which is not possible if you rely on an upstream resolver. So I generally always install "bind" on my systems and configure it as a local resolver. This article will provide a solid foundation on how to do that :

How To Configure BIND as a Private Network DNS Server on Ubuntu 14.04
https://www.digitalocean.com/community/ … untu-14-04

Then, when I need to flush the DNS resolver cache, it's as easy as :

# rndc flush

Cheers,
--K

kaiyel · Installation

If your working environment relies heavily on bash, you might consider replacing DASH with BASH as the default shell as I did. It "just works" and I've had no cause to reconsider the decision :

HOWTO : use bash instead of dash as the default shell in daedalus
https://dev1galaxy.org/viewtopic.php?id=5753

Cheers,
--K

kaiyel · Hardware & System Configuration

Heat makes things quirky. Back in the days when I would salvage my hardware upgrades from other peoples throwaways, I learned that cleaning off cheap factory thermal paste and replacing it with Arctic Silver paste was pretty much guaranteed to shave off degrees of temperature and add degrees of stability back on. Blow out the dust, clean off the cpu, gpu, and north bridge heatsinks using ArctiClean, and reapply thermal compound. Can't hurt. May help.

kaiyel · Other Issues

steve_v wrote:
The "systemd exists, so everything should use it somehow" bandwagon must grind ever onward.

Knowing that is to be expected, and thinking out loud, how does Devuan avert attack surface expansion while the upstream becomes more dependency permissive to accommodate systemd? Could it even be done without forking packages expressly for that purpose?

Devuan packaging may gain a tertiary goal beyond pruning systemd and maintaining user choice ... eliminating permissive bloat. I understand this is no small task and I imagine there are not yet enough packaging hands to accomplish this. Still, it feels that is the path Devuan will be given no choice but to follow.

Another caveat under the "Packaging Guide for Devuan" may be necessary under the section "Package Forking Policy" to welcome forks to eliminate permissive bloat as the manpower is found to do so. https://git.devuan.org/devuan/documenta … ngGuide.md

As a RedHat transplant, I'm not competent yet to provide another set of hands in that arena here. But I take this adventure with openssh as encouragement to plan ahead, learn more, and reach that level.

--K

kaiyel · Other Issues

Steve_V is on target :

This is not about diversity, or even systemd specifically. It's about dependency bloat.

That being said, as I read through the Openwall thread, I have the sense that the author of the backdoor specifically targeted dependency bloat accommodation as the vector for attack. As "do one thing, well" was set aside for systemd, increased dependencies are not only expected but required, and being non-paranoid about them widens the attack angle, nearly allowing a tangential xz/liblzma to be used as a tool to compromise openssh. Wow.

If xz/liblzma can be so used, what other dependencies have been introduced that are also tangential, but because they are not systemd specific their inclusion is not pruned out of Devuan? As Devuan evolves I fear it must not only guard against systemd in the upstream specifically, but also the dependency bloat the upstream has permitted in order to accommodate systemd.

Dependencies of dependencies ... it's a new kind of "dependency hell" :-)

--K

kaiyel · DIY

I too noticed https://github.com/OpenMATE-Desktop-Environment is now 404'd.

OpenMATE desktop environment is ... a fork of MATE, which in turn is a fork of the much-hailed GNOME 2. This new project abides to freedesktop.org standards and specifications, but it makes an explicit stance on the display server debate by not embracing the structurally-flawed Wayland protocol.

I love the sound of that. Was it too ambitious?
--K

kaiyel · Documentation

Not a bad idea, I reckon, to hold back the upgrade indefinitely to prevent accidentally upgrading until they fix some things :

apt-mark hold thunderbird

I think I will do that now. Thanks for the suggestion,
--K

kaiyel · Documentation

Tried to like the new Thunderbird Supernova ... twice ...

Downgraded today in three steps : delete compatibility.ini file, downgrade application software, downgrade configuration files

Open Thunderbird Supernova
Alt-H -> Troubleshooting information
Click Profile Folder -> Open folder
Close Thunderbird
Delete "compatibility.ini" from the open folder

Open command shell

su - root
apt install -y --allow-downgrades /var/cache/apt/archives/thunderbird_1%3a102.14.0-1~deb11u1_amd64.deb
exit
thunderbird --allow-downgrade
Close Thunderbird window

Exit command shell

Your mileage may vary, but the lazy loading of the email summary table as I scroll through it and the sluggishness when moving emails into subfolders make the new version unacceptable in my work flow. I feel they've taken a delightfully mature product and instead of preserving it, they've reverted it into an embryonic stage once more.

I've been using Thunderbird for decades, and will try to like the latest version again at some point in the future, but for now it just gets in the way of work that needs doing. If you feel the same, hope this helps,
--K

kaiyel · Documentation

Much appreciated info :-)

kaiyel · Documentation

As I recall, "dash = bash + posix_compliance - nonessential_libraries".

As the default system shell dash is superior, having fewer dependencies and application startup times improved by thousandths of seconds. No argument there. I can attest that as the superset, however, there is no fear in using bash as the default shell. It "just works".

If your working environment relies heavily on external applications for which you don't have authority (or time or desire) to rewrite the scripting glue, then bash is your best mate. And that is a reasonable scenario motivating a change in the default shell.

I absolutely do not mind Debian's move from bash to dash with Squeeze -- I think it was a good change and the gotchas have been worked out of the system. What surprised me while reviewing Daedalus was that the convenient method of exercising alternatives from one default shell to another was gone. Apparently it surprised a few people on the Debian forum too. I like alternatives and believe choice should remain part of the ecosystem. Removing ease-of-choice is detrimental ... which is kinda why we all meet up here for Devuan.

The purpose of my post was only to share the more verbose method of changing the default shell now that the shortcut has been removed. Hopefully it helps someone having real world constraints. Beyond that, there is little reason to switch back to bash.

Be well,
--K

kaiyel · Documentation

The ability to specify bash as the default shell instead of dash by running :

dpkg-reconfigure dash

has been removed from daedalus / bookworm apparently without explanation

The change can still be accomplished issuing dpkg-divert commands directly, but not nearly as conveniently. I found a post on the debian-users board to outline the steps (hat tip to Sven Joachim) :

https://lists.debian.org/debian-user/20 … 00382.html

# dpkg-divert --remove --no-rename /usr/share/man/man1/sh.1.gz
# dpkg-divert --remove --no-rename /bin/sh
# ln -sf bash.1.gz /usr/share/man/man1/sh.1.gz
# ln -sf bash /bin/sh
# dpkg-divert --add --local --no-rename /usr/share/man/man1/sh.1.gz
# dpkg-divert --add --local --no-rename /bin/sh

Cheers,
--K

kaiyel · Devuan

https://lists.debian.org/debian-devel-a … 00007.html

With the release date set, it's time to announce the Full Freeze [1]
date: Wednesday 2023-05-24. This means that from that moment on, every
package requires a manual unblock [2] by the release team if it needs
to migrate to bookworm. Please note that, as with all freezes, the new
rules apply for all packages that haven't migrated to testing yet (not
only for uploads after the freeze).

A hat-tip to the Devuan team as the dawning of Daedalus nears the horizon. Thank you for keeping Debian still Debian, even if using a new name, while preserving old freedoms and choices.

--K

kaiyel · Documentation

My Devuan Chimaera sendmail sm-mta installation was having issues performing an email hand-off to a small subset of email systems. The rejection message logged in /var/log/mail.log is "403 4.7.0 TLS handshake failed." which pointed me in the direction of a TLS error. So I tested the cipher negotiation with the target email system using :

openssl s_client -starttls smtp -connect TARGET.SYSTEM.HOSTNAME:25

Among the negotiation details I found the commentary :

140148764513600:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2157:

This indicates the Diffie-Hellman key on the target system is too short and therefore potentially susceptible to Logjam attacks. The default openssl security level on my Chimaera install is set to level 2 ... which will not negotiate with such systems.

For the administrators I know, I can encourage them to raise their bar and fix that weakness. But the rest of the Internet has no reason to listen to me, and my people still need to email their people. :-(

The only "fix" (if it can be called that) I know to provide is to lower the default security level in openssl on my system to enable it to communicate with theirs by dropping the SECLEVEL in /etc/ssl/openssl.cnf to "1" :

diff /etc/ssl/openssl.cnf /etc/ssl/openssl.cnf.orig
362c362
< CipherString = DEFAULT@SECLEVEL=1
---
> CipherString = DEFAULT@SECLEVEL=2

If you know of a better way to resolve this, please chime in. Otherwise, hope this helps someone else,
--K

[EDIT :%s/courier/sendmail/g ]

kaiyel · Documentation

In another thread (https://dev1galaxy.org/viewtopic.php?id=4850) I had suggested using "sysv-rc-conf" as a means of listing all the service runlevels on a system. It's a great utility and very similar to the "chkconfig" utility I am familiar with (from Redhat) for querying and updating the runlevel information for system services. Give it a spin.

But the one thing about the "sysv-rc-conf" utility I find terribly annoying is that the mouse interface in the Curses widget is not de-activated. With multiple windows open on my desktop, if I happen to click away from a terminal session running "sysv-rc-conf" to check something, and then return to that terminal session with another mouse click, and the mouse pointer happens to be over one of the "[ ]" fields where I clicked, "sysv-rc-conf" will dutifully activate or inactivate the service on that line for that runlevel. If you don't notice the change ... Ugh!

Fortunately it is easy to disable. Simply edit the perl script at /usr/sbin/sysv-rc-conf and change :

my $cui = new Curses::UI( -clear_on_exit    => 0,
                          -color_support    => 1,
                          -default_colors   => 1,
                        ) or die "Can't create base Curses::UI object";

to read :

my $cui = new Curses::UI( -clear_on_exit    => 0,
                          -color_support    => 1,
                          -default_colors   => 1,
                          -mouse_support    => 0,
                        ) or die "Can't create base Curses::UI object";

With mouse support disabled in the Curses widget, the risk of accidentally changing a runlevel while jumping between desktop windows is eliminated. This should be the default, in my opinion, with perhaps a command line argument to enable the mouse interaction if the administrator so chooses.

Hope this helps,
--K

kaiyel · Installation

Btw I really like the way Artix handles this (the other non-systemd and non-Gentoo distro I am using as of recently): There, you have a package without any init scripts, and multiple packages including them, specifically for the init system in use. In case of Radciale, this would be the "radicale" package, and if you want the OpenRC init script, the "radicale-openrc" package.

I had to read that twice to let the elegance of it soak in. *That* is the proper approach to supporting interchangeable init systems. It feels like ... common sense. I'm happy with my Devuan desktop, but may have to give Artix a spin for fun -- sounds like they have a few beautiful minds on the team. Thank you for mentioning this.

The officially official Devuan Forum!

#1 Re: Devuan » Devuan Server compromised » 2026-10-18 01:41:01

#2 Re: Other Issues » 2800 open issues » 2026-10-17 23:21:18

#3 Re: Devuan » Why not use runit? Do you guys use runit? » 2026-10-17 21:41:01

#4 Re: Desktop and Multimedia » What DE do you prefer to use on Devuan? » 2026-10-06 20:17:36

#5 Documentation » HOWTO : Disable mouse cursor movement inside vim document » 2026-10-01 16:08:22

#6 Re: Installation » umask - Problems & Solution » 2026-09-30 20:58:09

#7 Re: Documentation » HOWTO : Disable mouse use in sysv-rc-conf » 2025-12-02 23:00:21

#8 Re: Off-topic » Trying to explain what happened with Cloudflare? » 2025-12-02 17:53:18

#9 Re: News & Announcements » Announcing Devuan 6.0 Excalibur! » 2025-11-03 14:15:16

#10 Re: Off-topic » Getting there, slowly but steadily ... » 2025-01-19 21:07:49

#11 Re: Other Issues » Clearing the DNS cache » 2025-01-12 18:31:11

#12 Re: Installation » [SOLVED] /etc/cron.hourly/somejob starts a bash script as dash » 2025-01-12 18:18:09

#13 Re: Hardware & System Configuration » Daedalus MATE freezes sometime » 2024-10-25 04:33:16

#14 Re: Other Issues » backdoor targeting deb and rpm via systemd? » 2024-04-12 21:09:43

#15 Re: Other Issues » backdoor targeting deb and rpm via systemd? » 2024-04-09 16:26:08

#16 Re: DIY » Announcement of the OpenMATE desktop environment » 2024-02-03 19:31:59

#17 Re: Documentation » HOWTO : Downgrade Thunderbird 115 to 102 » 2024-01-22 02:01:51

#18 Documentation » HOWTO : Downgrade Thunderbird 115 to 102 » 2024-01-20 19:50:39

#19 Re: Documentation » Revert recent changes to file viewing options in FF » 2023-12-11 23:04:02

#20 Re: Documentation » HOWTO : use bash instead of dash as the default shell in daedalus » 2023-06-20 14:40:48

#21 Documentation » HOWTO : use bash instead of dash as the default shell in daedalus » 2023-06-19 16:14:56

#22 Devuan » Bookworm : Happy Full Freeze Day Wednesday 2023-05-24 » 2023-05-24 05:28:17

#23 Documentation » HOWTO : Fix sendmail "stat=Deferred: 403 4.7.0 TLS handshake failed." » 2023-04-01 17:13:14

#24 Documentation » HOWTO : Disable mouse use in sysv-rc-conf » 2022-11-23 21:49:33

#25 Re: Installation » Radicale can't be started using the shipped init script (using OpenRC) » 2022-11-17 12:29:09

Board footer