Posts by kaiyel

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.

kaiyel · Other Issues

Sorry, Golinux, I overlooked your post above HoaS's. I appreciate the warning <thumbs-up>

--K

kaiyel · Other Issues

Thanks again, HoaS

I'll tag this thread solved and continue with the homework due-diligence.

Your time is much appreciated

--K

kaiyel · Other Issues

Thank you, HoaS

I started looking into backports following RR's suggestion, which lead me to :

https://backports.debian.org/Instructions/

As a matter of Backports policy, packages in the stable-backports suite are taken from Debian testing ...

And following the tracker link RR provided, no releases in the vendor 4.x.x branch following 4.0.7 have been added to testing :
https://tracker.debian.org/pkg/lxcfs

It looks like immediately following the 4.0.7 release, the target was moved to 5.0.0 and then to 5.0.2.

If I understand policy correctly, I would be asking for a backport of 5.0.2 from testing to be made available for Bullseye in Backports. If I were the package maintainer receiving that request, my response would likely be something along the lines of "Why are you making more work for me? Eyes on Bookworm.", because experience suggests backporting a major 5.x.x version to a system built at the time 4.x.x was stable frequently gets hairy. If that kind of work were the norm, I would expect Backports to be a bit of an unstable mess.

My perception was that Debian Updates followed software vendor stable releases :
https://linuxcontainers.org/lxcfs/downloads/

lxcfs-4.0.7 => lxcfs-4.0.8 => lxcfs-4.0.9 => lxcfs-4.0.10 => lxcfs-4.0.11 => lxcfs-4.0.12

But, that seems not to be the case.

When you say "The stable release is so named because the version numbers do not change.", does that mean Updates are more like :

lxcfs-4.0.7-1 + patches => lxcfs-4.0.7-2 + patches => lxcfs-4.0.7-3 +patches => lxcfs-4.0.7-4

In which case patches are generally limited to bug squashing and mitigating security concerns?

If I were to produce a patch against lxcfs-4.0.7-1 that exclusively corrected the lxcfs presentation of /proc/meminfo ... would that be welcomed within the Debian ecosystem and worthy of an lxcfs-4.0.7-2 package being released?

Perhaps what I am looking for is a grey area between Backports and Updates where the software vendor has addressed minor issues within a major release and deemed a minor release is warranted. Do these minor releases get picked up in the Debian update cycle? Or do folks just wait for the next Debian stable release?

Thank you for your time as I build an understanding of the way things work,
--K

kaiyel · Other Issues

Thanks, RR

For my immediate needs I did this :

apt-get install devscripts
apt-get install quilt
mkdir /tmp/lxcfs
chown _apt:root /tmp/lxcfs
cd /tmp/lxcfs/
apt-get source lxcfs
apt-get build-dep lxcfs
wget https://linuxcontainers.org/downloads/lxcfs/lxcfs-4.0.12.tar.gz
cd lxcfs-4.0.7
uupdate -v 4.0.12-1 ../lxcfs-4.0.12.tar.gz 
cd ../lxcfs-4.0.12-1
vi debian/rules

override_dh_installinit:
# mv debian/lxcfs/etc/rc.d/init.d/lxcfs debian/lxcfs.init
# rm -rf debian/lxcfs/etc/rc.d
dh_installinit -p lxcfs --no-stop-on-upgrade
override_dh_installsystemd:
# dh_installsystemd -p lxcfs --no-stop-on-upgrade lxcfs.service

dpkg-buildpackage -us -uc -b

And this produced an "lxcfs_4.0.12-1-0devuan1_amd64.deb" package that I installed and confirmed the /proc/meminfo fix works. Nice.

So that is great ... for me. But I'm still at a loss, regarding Debian/Devuan culture (I earned my grey beard in the RPM world), as to how one effectively approaches/advocates/assists toward greater symmetry between stable vendor releases and distribution updates without stepping on toes within the Debian ecosystem.

Is there a Welcome-to-Debian blog somewhere tailored for old transplants?
--K

kaiyel · Other Issues

Version 4.0.12 of LXCFS has been out since 2022-Feb, but no update past the 4.0.7-1 release is available in Debian :

https://packages.debian.org/bullseye/allpackages
https://packages.debian.org/bullseye-up … llpackages

The latest stable release of LXCFS, from the detailed changelog, indicates meminfo and swaps are now cgroupv2 aware. That has value to me as some software I use relies on meminfo to tune itself to available memory :

https://discuss.linuxcontainers.org/t/l … ased/13287

I found the Debian work-needing and prospective packages page, but no mention of updates for LXCFS appear forthcoming :

https://www.debian.org/devel/wnpp/

Is it accurate to say my options are "doing without" or "building my own"?

As a transplant from the RPM-world my question is a bit of an ecosystem/protocol question in the DEB-world. Can someone educate me as to a proper series of events that should take place to advance a Debian package update? I'm confident I can roll my own package (having done so in the RPM-world as needed), but that only helps me.

Thanks,
--K

kaiyel · Documentation

I had a need for a local caching-only name server and installed my goto resolver
bind9 on a fresh Chimaera instance.

apt-get install -y bind9 bind9-utils

Out of the box I discovered an error logged to syslog and all lookups failed :

managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

The default location for the "bind.keys" file is "/etc/bind.keys", but the package
locates that file as "/etc/bind/bind.keys". As such it was necessary to specify the
current file location by editing the "/etc/bind/named.conf.options" config :

vi /etc/bind/named.conf.options

such that :

dnssec-validation auto;
bindkeys-file "/etc/bind/bind.keys";

And, after saving, remove the (likely junked) cache file and journal :

rm /var/cache/bind/managed-keys.bind*

Restart bind and my caching server is now usable.

--K

kaiyel · Installation

For those who are interested in the greybeard history of why "bin" was split between "/bin" and "/usr/bin" :

http://lists.busybox.net/pipermail/busy … 74114.html

--K

kaiyel · Documentation

Fair

As mentioned in the detailed Bash list of changes, bracketed paste mode was enabled by default starting in bash-5.1-alpha.

For folk like me, bash 5.x is a shiny new thing and losing the default ability to immediately execute pasted commands is a change to decades old behavior. I doubt Devuan (or Debian) devs will stray from the new defaults established by bash devs -- so I think you are in good shape. And to their monumental credit, the bash devs gave us an easy way to restore old behavior. In the future, should the bash devs determine the old way was the more common usage and change the default back, this same bashrc tweak can be reversed to turn the new behavior back "on" for you as well.

kaiyel · Documentation

If you've migrated from the Redhat world where you were comfortable with "chkconfig --list",

apt-get install -y sysv-rc-conf

and see if you like "sysv-rc-conf --list".

--K

kaiyel · Documentation

Hat tip to Chris Siebenmann :

https://utcc.utoronto.ca/~cks/space/blo … asteChange

I regularly paste short lists of linefeed separated commands from a library of various instructions into bash terminal windows to accomplish small tasks.

The bash shell on my devuan system accepts the pasted content, but waits for a final interactive <enter> keypress before proceeding with command execution. I've not experienced that interactive <enter> confirmation requirement before. I understand it allows folks one last read of the commands before execution, so it's not necessarily a bad default. But after giving myself some time to try and get used to it, I've decided it's just not for me. If I copied the linefeed and pasted it, it is because I wanted the command executed ... every single time.

Thanks to Chris Siebenmann's blog I learned this interactive confirmation is a new feature of bash that can be turned off by appending this change to the "/etc/bash.bashrc" configuration :

bind 'set enable-bracketed-paste off'

Start a new shell and I'm back to middle-mouse clicking my pasted commands without having to touch the keyboard. A "win" for me; maybe for you too.

--K

kaiyel · Other Issues

Thank you, xinomilo!

--K

kaiyel · Other Issues

Since upgrading to chimaera, RapidSVN is no longer available :

$ apt-get download rapidsvn
E: Can't find a source to download version '0.12.1dfsg-3.1+b1' of 'rapidsvn:amd64'

$ apt-get source rapidsvn
Reading package lists... Done
E: Can not find version '0.12.1dfsg-3.1' of package 'rapidsvn'
E: Unable to find a source package for rapidsvn

Did it not make the cut / does a better (one that does not involve Java or KDE libs) alternative exist?

Thanks,

--K

The officially official Devuan Forum!

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

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

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

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

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

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

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

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

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

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

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

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

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

#14 Re: Other Issues » [SOLVED] LXCFS 4.0.12 build ? » 2022-11-14 21:37:04

#15 Re: Other Issues » [SOLVED] LXCFS 4.0.12 build ? » 2022-11-14 18:26:08

#16 Re: Other Issues » [SOLVED] LXCFS 4.0.12 build ? » 2022-11-14 17:58:26

#17 Re: Other Issues » [SOLVED] LXCFS 4.0.12 build ? » 2022-11-13 23:00:22

#18 Other Issues » [SOLVED] LXCFS 4.0.12 build ? » 2022-11-12 21:13:31

#19 Documentation » HOWTO : Fix bind9 managed-keys-zone: Unable to fetch DNSKEY set '.' » 2022-11-10 17:45:18

#20 Re: Installation » From Debian (testing) to Devuan » 2022-09-29 17:21:49

#21 Re: Documentation » HOWTO : enable pasting linefeed-separated commands into bash terminal » 2022-09-20 15:51:02

#22 Re: Documentation » Help - list all services » 2022-09-19 22:37:19

#23 Documentation » HOWTO : enable pasting linefeed-separated commands into bash terminal » 2022-09-19 19:12:40

#24 Re: Other Issues » [SOLVED] Missing RapidSVN » 2022-01-04 22:20:43

#25 Other Issues » [SOLVED] Missing RapidSVN » 2022-01-04 16:37:17

Board footer