Re: [DNG] Another problem you won't have without Systemd (or separate oomd)

[Didier Kryn]

Le 20/08/2022 à 10:20, Martin Steigerwald a écrit :

oomd may make sense in certain cloud based workloads, maybe, just maybe.
However… on a desktop? You are frigging kidding me, aren't you?


    Well, it can happen to anybody to write an application which leaks 
memory. The oom killer is automatically launched by the kernel when 
memory pressure is too high, and it is a necessity. The problem here is 
with systemd's oom killer, and/or with Gnome.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init respawns - was: Be prepared for the fall of systemd

[Didier Kryn]

Le 05/08/2022 à 07:36, Steve Litt a écrit :

Perfectionists never finish, and the perfect is the enemy of the good.


    This is absolutely true. But ...

    perfection can be approached when we keep things "simple stupid". 
For example the init script suggested by Karl:


> for i in /etc/rcS.d/S* /etc/rc2.d/S*
> do
>   $i start
> done

    doesn't need a maintaining community, and you also consider runit 
is simple enough to fall in the same category.


    Often, simplifying a problem till the solution is clear and 
obvious, can take a lot of time, but it deserves the effort. It is 
sometimes possible.


    High level languages, due to their high expressivity, help reach 
such simplicity. For example, the above script, translated in C (why not 
in assembler?) would need a carefull review by a community.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Be prepared for the fall of systemd

[Didier Kryn]

Le 04/08/2022 à 00:36, Bruce Perens via Dng a écrit :
The fundamental OS concept is "Everything's an API" rather than 
everything's a file.

APIs rather than libraries and linking.


 etc...

    It seems to me that "everything is a file" could do it yet: the 
kernel implements such an API though /proc, with netlink for 
asynchronous signalling. A filesystem equivalent to /proc for user 
space, plus inotify capability would just do it. And keep it simple 
stupid. I may be missing something but I like to stick to simple concepts.


-- Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init respawns - was: Be prepared for the fall of systemd

[Didier Kryn]

Le 03/08/2022 à 09:36, marc a écrit :

Thanks Karl,

Some questions:

Hello


1) Does Busybox init require the daemon to background itself?

So I seem no reason why "nohup daemon > /var/log/logfile &" isn't sufficient
for this, or is there something I am not aware of ?


2) Does Busybox init give you a reasonable way to automatically restart the 
process
after the process terminates?

3) Does Busybox init give you the choice of auto-restart or not for each 
different
process? If it does, that's something specifically missing in Runit.

At the risk of pinning my own interpretation on this:

I suppose for quick, dirty and crashy hacks maybe automated restarts
are useful to paper over some problems. But if the daemon you are running
is likely to crash, it might also just hang in an infinite loop or
leak file descriptors, or fill up a partition or grind through swap, things
that a respawn doesn't really solve ...

We are often told that "thesedays computers are cheap and programmers are
expensive" as an excuse for writing flaky software, and from the perspective
of the greedy and immortal AI that is a corporation, this makes sense - a
bit of bespoke software, even if flaky, might do the work of a human more
quickly and cheaper while the costs are externalised.

But the free software universe things are different - unreliable or
bloated software wastes the time and hardware resources of thousands, perhaps
millions of people. And even if you are happy to ignore the environmental
costs (electricity, more hardware bought more often), then maybe some
other reasoning might be persuasive: I certainly often marvel at the
craftsmanship of people from previous ages - from as small as an excellent
hand tool to as expansive as a church, mosque or similar - those things were 
made
not "meh, good enough", but as good as humanly possible, and I would
think that the free software world has some similarities there - while
software might be written to scratch an itch, the solution is often
created for the joy of it, for the satisfaction of building something
really good - be it just for fun, the desire to leave a legacy or
building a contemplative mandala.

TL;DR: just install better daemons ;)


    +1

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] article about devuan

[Didier Kryn]

Le 30/07/2022 à 12:07, Steve Litt a écrit :

I thought most of the Devuan review was accurate and complimentary. However, 
I've
never thought of Devuan as "retro" or particularly inconvenient for newbies.


    It's Debian itself which is known as inconvenient to newbies, hence 
Devuan, of course (~:


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Didier Kryn]

Le 24/07/2022 à 05:18, Olaf Meeuwissen via Dng a écrit :

Hi list,

I lost the single SSD on my mini PC and am in the process of rethinking
its storage.  So far, I've got myself two brand new and identical PCIe
NVMe SSDs (256GB) for use in a software RAID1 setup.  I think I need to
enable UEFI to get access to the BIOS from the GRUB menu.

I want my /home directory on a partition of its own, at a minimum, and
encrypt it.  I don't see a need to encrypt much else as I am not after
plausible deniability.  It's mostly to be able to return a broken disk
for a replacement and still sleep in relative peace of mind;-)

I haven't quite made up my mind as to a need for other partitions.  I
use containers and VMs quite a bit.  Perhaps these are better stored
some place other than the partitions for / or (an encrypted) /home.

With 64GB of RAM, I don't see much need for swap.  If needed, I could
always add a swapfile instead of a partition.


    Apart from the containers, which I haven't any experience of, and 
given your pretty reasonable description of your needs, my take would be 
to reserve the whole of your RAID1 for /home and add a small ssd for all 
the OS, in one single partition. Of course, no swap.


    If you happen to loose the OS disk, which is very unlikely: not a 
big harm, install Devuan on a fresh one. Your home is safe, although the 
only protection against your own mistakes is, of course, backup. KISS!


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] The word is irony

[Didier Kryn]

Le 08/07/2022 à 12:57, al3xu5 via Dng a écrit :

The word is irony

Disgust also.



    Expected.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 27/05/2022 à 15:40, Dr. Nikolaus Klepp via Dng a écrit :

Anno domini 2022 Fri, 27 May 15:11:24 +0200
  Didier Kryn scripsit:

Le 26/05/2022 à 13:26, k...@aspodata.se a écrit :

The kernel devtmpfs makes dev files come and go, yes, but they
will have some default user, group and permission setting, so
*dev daemons handle that part.

      Yes, I forgot this point.

      However handling permission and ownership is a simple task.
Couldn't it be done by a script fed by inotifywait ?

      'inotifywait -mqe create --format %f /dev | PermissionManager.sh'

      An oversimple hotplugger (~:

Once upon a time there was /proc/sys/kernel/hotplug which did this.

Nik


    Yes. The legacy Busybox's mdev is working like this: 
/proc/sys/kernel/hotplug points to it.


    I think you can invoke your script like this. The script just needs 
to read some global variables to know if the uevent causes the creation 
of a device file and make sure the kernel has created this file before 
changing permissions.


    There was a disussion years ago in Busybox, about the respective 
merits of /proc/sys/kernel/hotplug versus netlink. In the first case, 
you have a "fork bomb" at boot time (launching the hotplugger at each 
device creation) and possibly unordered activity, and in the second 
case, you have the hotplugger always resident in RAM even when it's not 
needed, but sequential activity.


    DEVTMPFS was invented later, AFAIK because kernel people were 
unhappy with what udev was doing. It happens to offer a third triggering 
method to manage devices which have a device file: inotify.


    Using inotify is simple and sequential, but the process is 
permanently in RAM (like all hotpluggers but mdev). I think it is the 
simplest method if you deal only with character and block devices. Of 
course, the program isn't necessarily a script. I gave the example to 
show how easy it is.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 26/05/2022 à 13:26, k...@aspodata.se a écrit :

The kernel devtmpfs makes dev files come and go, yes, but they
will have some default user, group and permission setting, so
*dev daemons handle that part.


    Yes, I forgot this point.

    However handling permission and ownership is a simple task. 
Couldn't it be done by a script fed by inotifywait ?


    'inotifywait -mqe create --format %f /dev | PermissionManager.sh'

    An oversimple hotplugger (~:

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 25/05/2022 à 23:04, k...@aspodata.se a écrit :

Aitor:

On 20/1/22 0:23, aitor wrote:

...

I uploaded some images of gnuinos chimaera including vdev as default
device manager.

...

It's possible to choose between sysvinit, openrc or runit at the end of the
installation, but unlike devuan, the later is set as default.

Bear in mind that you can always toggle device managers via apt, whether:

# apt-get install libeudev1 eudev

or

# apt-get install libudev1-compat vdev

It would be nice if one could choose static /dev (as it was before udev).
It is no problem running with a static /dev if you compile your own
kernel.

    Seems there is a myth about user-space hotplugger 
(udev/eudev/vdev/mdev) being necessary to have a dynamic /dev. Dynamic 
/dev has been managed by the kernel from many years. The hotpluggers do 
other things, like managing the symlinks in /dev/disk/by-* and they are 
usefull for that. But, even if you remove the hotplugger, if the kernel 
has the DEVTMPFS feature enabled (which is likely), it will create and 
delete the device files.


--     Didier

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Web md RAID monitoring [was: Re: Fake RAID]

[Didier Kryn]

Le 12/03/2022 à 11:03, tito via Dng a écrit :

On Sat, 12 Mar 2022 10:32:53 +0100
Didier Kryn  wrote:


Le 12/03/2022 à 02:05, Ralph Ronnquist via Dng a écrit :

On Sat, 12 Mar 2022 09:33:01 +1100
Ralph Ronnquist  wrote:


On Fri, 11 Mar 2022 16:04:45 +0100
Didier Kryn  wrote:

       Its almost done. I have added a few features devised from
Tito's suggestions, and added git version control, but I can't
remember how to create the initial version in Devuan's git store.

You need an acount set up first; let's say it's "kryn" and for the
sake of example I use the name "webraid" for this project.

Then, at home, you use the 2 commands:

$ git remote add origin g...@git.devuan.org:kryn/webraid.git

$ git push --set-upstream origin master

Thereafter you need to jump onto the store's web interface and change
the project settings into not being a private project.

Actually, the above would be only if you have your ssh key registered
at the git store. If not you would rather use the following first
command:

$ git remote add origin https://git.devuan.org/kryn/webraid.git

and then follow on with the login credentials it asks for.


      Thanks for the explanations. I will keep your mails for the next
time. Following Aitor's instructions, I created a minimal repository
from the web, then cloned it locally, copied all the stuff in locally,
committed it and pushed the result back.

      It's called Diskweb. Thanks all for your help.

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Hi,
some minor typos in Readme.md file:

This is a small http server, originally inspired by micro-httpd, for its small 
size, but with the intention to serve dynamic content instead of static files.

The primary reason to use an http server is that it is a simpler method to 
display graphics than interfacing with a graphics library like Gtk or Qt.

The second reason is that it is still usable on systems without graphics 
capability, since it is enough to have a network connection and view the 
graphics from a remote full-fledged computer.

This server provides monitoring of filesystem status and md RAID status. 
Monitoring of other system-critical components could be added.

file system

This server follows http 1.0 protocol, which means that the connexion is closed 
immediately after the content have been transferred. This makes it usable to 
serve one request after the other and have only one session at a time.


   connection

Data transferred reflects the status of the filesytems and of the RAID(s) at the moment 
of the request. There is no automatic update. To obtain updates, the user must repeat the 
request (by using the "refresh" button of the web blowser).

 file systems   



  browser
  
PORT NUMBER


This server expects connexions on port 8085 by default. If another port number 
is desired, it can be changed by one of 4 means:

   connections

 on the command line, invoque 'httpd port-number'

   invoke  (call?)

 in src/httpd.c: change the line #define LISTEN

 add the line above in /src/diskweb.h

 in the makefile, add a -D option to the gcc command to do the same

diskweb's httpd can also be invoqued through inetd, in which case it does not 
listen to any port and the listening port is part of inetd's configuration.

   invoked (called?)

BUILDING and INSTALLING

To just compile the executable file httpd, run 'make' To delete it, run 'make 
clean' To install /usr/local/diskweb/httpd, run 'make install' . (A dot is 
missing)

  To uninstall it, run 'make uninstall'   . (A dot is missing)

No sysv-rc, runit, s6, or other init scipt is provided. The easy way to start 
diskweb on Devuan is to copy the file diskweb.sh in /etc/boot.d ; commands in 
this directory

   script

  are executed by /etc/rc.local as the last step of system startup. This script 
is not installed by 'make install' because it would require root priviledge.



privileges
Note that root priviledge is needed to listen on a port number lower that 1024.

   privileges are


 

Re: [DNG] Web md RAID monitoring [was: Re: Fake RAID]

[Didier Kryn]

Le 12/03/2022 à 02:05, Ralph Ronnquist via Dng a écrit :

On Sat, 12 Mar 2022 09:33:01 +1100
Ralph Ronnquist  wrote:


On Fri, 11 Mar 2022 16:04:45 +0100
Didier Kryn  wrote:

      Its almost done. I have added a few features devised from
Tito's suggestions, and added git version control, but I can't
remember how to create the initial version in Devuan's git store.

You need an acount set up first; let's say it's "kryn" and for the
sake of example I use the name "webraid" for this project.

Then, at home, you use the 2 commands:

$ git remote add origin g...@git.devuan.org:kryn/webraid.git

$ git push --set-upstream origin master

Thereafter you need to jump onto the store's web interface and change
the project settings into not being a private project.

Actually, the above would be only if you have your ssh key registered
at the git store. If not you would rather use the following first
command:

$ git remote add origin https://git.devuan.org/kryn/webraid.git

and then follow on with the login credentials it asks for.

    Thanks for the explanations. I will keep your mails for the next 
time. Following Aitor's instructions, I created a minimal repository 
from the web, then cloned it locally, copied all the stuff in locally, 
committed it and pushed the result back.


    It's called Diskweb. Thanks all for your help.

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Fake RAID

[Didier Kryn]

Le 10/03/2022 à 18:52, Hendrik Boom a écrit :

On the other hand, mdadm also is not a
piece of cake but I can find my way with it and I have developped a 
graphics
monitoring tool for it, actually a little web server displaying the 
status

of all the host's md RAIDs.

That looks useful.
I already have a web server.
Is it possible to easily configure this thing so it provides content 
to an existing web server?


    Diskweb is a minimal web server providing two tables:

    - the status of md RAID devices

    - the occupancy of mounted filesystems

    - an index file containing links to the 2 above.

If you want to aglomerate contents from various web services, I 
recommend installing Nginx. Nginx is a very nice web server and 
reverse-proxy. It is relatively easy to configure and is designed to be 
the front-end to other servers, wether http, https, cgi-bin and 
fcgi-bin. One possible role is as an https front-end merging data from 
http or fcgi-bin servers either local or in LAN.


A few years ago I set up such a service in which one of the pages was 
merging RAID status tables from 5 diskweb servers in the LAN.


I think it makes sense to separate raw content production (like diskweb 
does) and polished presentation.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Web md RAID monitoring [was: Re: Fake RAID]

[Didier Kryn]

Le 10/03/2022 à 18:52, Michael Neuffer via Dng a écrit :




On 3/10/22 08:41, Didier Kryn wrote:
 Not packaged. Debian packaging is something I was never able to 
achieve and I prefer devoting my time to more fruitfull trasks, given 
my skills. I can send you diskweb.tgz, the size of which is 16K. It 
is trivial to build. It monitors both md RAIDs and the level of 
occupation of the filesystems. RAID data is read from devices' 
representation in /sys/devices/virtual/block, and the display is made 
attractive by the use of colors and svg graphics. I wrote this more 
than a dozen years ago and never touched it since that time. It's 
running on our home Desktop.


 Note that the location /sys/devices/virtual/block is not granted 
to stay the same place in the future, but this location is easy to 
change in the source in case kernel people change their mind.


 If more people are interested I might put it on Devuan git.



Please do so.



    Its almost done. I have added a few features devised from Tito's 
suggestions, and added git version control, but I can't remember how to 
create the initial version in Devuan's git store.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Web md RAID monitoring [was: Re: Fake RAID]

[Didier Kryn]

Le 09/03/2022 à 20:58, tito via Dng a écrit :

On Wed, 9 Mar 2022 19:18:13 +0100
Didier Kryn  wrote:


Le 09/03/2022 à 17:12, d...@d404.nl a écrit :

On 09-03-2022 16:55, Hendrik Boom wrote:

On Wed, Mar 09, 2022 at 02:42:07PM +0100, aitor wrote:


Did you read the following guide?

https://wiki.debian.org/DebianInstaller/SataRaid

Interesting note.

What is a "fake RAID"?  Is it a RAID or not?

-- hendrik


A real RAID controller has hardware and software on board and often a
battery backup. A "fake" RAID does have some hardware but no software
or better some software but depends on a Windows driver for the RAID
functions. Same trick as with Win modems and printers.


      I have worked with Dell Poweredge servers around 15 y ago. These
had PERC hardware RAIDs able to completely do the whole job without any
help from the OS. The configured RAID devices were seen by the kernel as
individual disks. After a few years working like this I configured the
PERC so as to show every disk individually (therefore no RAID), and
managed software RAIDs using mdadm. md RAIDS, not dm RAIDS. dm stands
for device-mapper, which also means Logical Volume Manager. On the
contrary of what is said in the Debian document, I found LVM (dm RAIDs)
not much more usefull than md and overly complex. On the other hand,
mdadm also is not a piece of cake but I can find my way with it and I
have developped a graphics monitoring tool for it, actually a little web
server displaying the status of all the host's md RAIDs.

Hi,
I'm interested about this web server thing is it packaged?


    Not packaged. Debian packaging is something I was never able to 
achieve and I prefer devoting my time to more fruitfull trasks, given my 
skills. I can send you diskweb.tgz, the size of which is 16K. It is 
trivial to build. It monitors both md RAIDs and the level of occupation 
of the filesystems. RAID data is read from devices' representation in 
/sys/devices/virtual/block, and the display is made attractive by the 
use of colors and svg graphics. I wrote this more than a dozen years ago 
and never touched it since that time. It's running on our home Desktop.


    Note that the location /sys/devices/virtual/block is not granted to 
stay the same place in the future, but this location is easy to change 
in the source in case kernel people change their mind.


    If more people are interested I might put it on Devuan git.

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Fake RAID

[Didier Kryn]

Le 09/03/2022 à 17:12, d...@d404.nl a écrit :

On 09-03-2022 16:55, Hendrik Boom wrote:

On Wed, Mar 09, 2022 at 02:42:07PM +0100, aitor wrote:


Did you read the following guide?

https://wiki.debian.org/DebianInstaller/SataRaid

Interesting note.

What is a "fake RAID"?  Is it a RAID or not?

-- hendrik

A real RAID controller has hardware and software on board and often a 
battery backup. A "fake" RAID does have some hardware but no software 
or better some software but depends on a Windows driver for the RAID 
functions. Same trick as with Win modems and printers. 



    I have worked with Dell Poweredge servers around 15 y ago. These 
had PERC hardware RAIDs able to completely do the whole job without any 
help from the OS. The configured RAID devices were seen by the kernel as 
individual disks. After a few years working like this I configured the 
PERC so as to show every disk individually (therefore no RAID), and 
managed software RAIDs using mdadm. md RAIDS, not dm RAIDS. dm stands 
for device-mapper, which also means Logical Volume Manager. On the 
contrary of what is said in the Debian document, I found LVM (dm RAIDs) 
not much more usefull than md and overly complex. On the other hand, 
mdadm also is not a piece of cake but I can find my way with it and I 
have developped a graphics monitoring tool for it, actually a little web 
server displaying the status of all the host's md RAIDs.


    What I mean is that there is probably the possibility to configure 
the PERC as no-RAID and build a software RAID on Linux, if this is 
manageable for your Win10.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [OT] files disappearing reproducibly

[Didier Kryn]

Le 21/02/2022 à 01:36, Steve Litt a écrit :

Florian Zieboll via Dng said on Sat, 19 Feb 2022 18:51:54 +0100



Back to the keyboard, I just discovered, that every (GUI) program I
run, is spawned from PID 1.

This is not precisely true. Even though ps ax lists the PPID of the
programs you run is 1, PID1 didn't spawn them. Here's the explanation...

When there's a desire to background a program in such a way that you
can close the parent program without closing the "spawned" program,
without using the problematic nohup, the iconic way to do it is called
"doublefork", which *assigns* the PPID to PID1.

As a doublefork example, the following is the C code my qownbackup
system uses to background the `qownbackup backup` command:

==
#include
#include

int main(int argc, char *argv[]){
 pid_t pid = fork();
 if(pid < 0){
 printf("First fork failed.\n");
 perror("First fork failed!");
 } else if(pid == 0){
 pid = fork();
 if(pid < 0){
 printf("Second fork failed.\n");
perror("Second fork failed!");
 } else if(pid == 0){
 execl("./qownbackup.sh", "./qownbackup.sh", "backup", NULL);
 }
 }
}
==

Aitor can correct any misunderstandings I have, but here goes my
explanation...

First, understand that the fork() function produces a second process,
called "the child", almost completely identical to the first. The
child's program counter is the same as the parent's, so both process
proceed from the point immediately after the fork() function.

The fork() function returns one of three ranges of integers:

* Less than 1 on error.
* Zero if the current process is the child.
* Greater than zero, and in fact the child's PID, if the process is
   the parent.

The child of a child is assigned a PPID of 1.

So the first thing is to do one fork, test the return code for error,
and abort if so. If the return code is positive, indicating that this
is the parent, do nothing, so that the parent finishes normally.

But if the return code is zero, this is the first child, so do another
fork. Once again, run the fork() function, and if the return indicate's
that you're a child (of the child the child the original created), do
an exec function to replace yourself with the command you want to
background, in this case "qownbackup backup".

Because it's the child of a child, its PPID is 1. Aitor, I don't think
I've given the complete story, I think there's a dependency on which
process finishes first, and as such I might have a race condition in my
code.

Also, I think I should have done a setsid() after the second fork, and
I should have done something to close stdin, and redirect stdout and
stderr, to a log file or to /dev/null.

The following is the (Python3) doublefork used in my UMENU2 software:

==
#!/usr/bin/python

import sys
import os

if os.fork():
 sys.exit(0)
if os.fork():
 sys.exit(0)
os.setsid()  ### New to 1.9.3, guarantees complete fork
sys.argv.pop(0)
executable = sys.argv[0]
os.execvp(executable, sys.argv)
==

In the preceding, errors aren't handled, so it just does two straight
forks and proceeds only if both return zero. Then it does a setsid(),
which I think my C implementation should have done too, and then exec's
the desired command, just like my C implementation does.

Doubleforking works in pretty much any computer language with the
fork(). You can even do it in bash or dash, but it's not so
straightforward.

SteveT


    Note that this double-fork has not to be implemented in processes 
launched from sysv-rc scripts, since the launching script already 
performs one of the forks and then dies. In a daemon you launch by hand, 
the critical thing is to detach from the controlling terminal (closing 
stdin is not enough), and start a new session (setsid). Then you don't 
care who is the parent of the daemon; when the parent dies, the daemon 
becomes a child of init, but who cares?


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 10/02/2022 à 02:34, aitor a écrit :


Hi Didier,

On 9/2/22 16:36, Didier Kryn wrote:
And, if you haven't a server like ifupdown or netplug, you're going 
to need to restart networking everytime you plug/unplug your Ethernet 
cable.


Well, you mean *ifplugd* or netplug..., I understand.


    Yep (~:


Try with "auto" and "allow-hotplug" together, both at once. That is:

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

With this configuration, plug/unplug events will be automatically 
detected.


    Maybe plug/unplug of devices are detected, but I doubt plug/unplug 
of Ethernet cable are, though I didn't try because I should have 
uninstalled ifplugd for the test to be conclusive.


    But I made a minimum testing: I just inserted the doube stanza you 
suggest, for the eth0 interface of my laptop, and the net effect on 
reboot is a long delay with the message that ifup is waiting for a lock 
file the name of which contains "eth0". I would have bet some bucks on 
this result (~:


    My normal interfaces file contains an "auto" stanza for wlan0, 
which is superfluous, according to messages from ifplugd, and *only* 
"iface eth0 inet dhcp" for eth0 because it comes first in the file and 
"auto" and/or "allow-hotplug" can just cause the abovementionned delay 
when no Ethernet cable is connected. Again, "auto" and/or 
"allow-hotplug" are useless when you have ifplugd managing eth0 and 
wlan0; they can only cause a startup delay. Even on my desktop, which 
only has an Ethernet connection, eth0 is managed by ifplugd and there is 
no "auto" or "allow-hotplug" stanza. This allows smooth functionning 
when the machine is moved around and the Ethernet cable 
plugged/unplugged and/or the DSL modem/router is restarted.



I'll answerin detail to the rest of your post shortly, when I have time.

    I'd like a lot to learn more on this. I reached a consistent 
understanding based on experiments, but it's certainly not definitive 
and I know you're looking at things more in depth.


    Cheers.

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 08/02/2022 à 01:45, aitor a écrit :

Hi Didier,
On 7/2/22 19:21, Didier Kryn wrote:

If you
remove the "allow-hotplug" and "auto" stanzas, ifup -a will just do
nothing, hence no wait. Therefore the solution is to install ifplugd or
netplug, configure it, and eliminate the "allow-hotplug" stanzas from
/etc/network/interfaces.

I've found a workaround replacing in the init script:
if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
then
  log_action_end_msg $?
else
  log_action_end_msg $?
fi
with this:
if [ $(runlevel) != "unknown" ] || ! [ -z $(grep '^id:1:initdefault:$' 
/etc/inittab) ]; then
   if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
   then
     log_action_end_msg $?
   else
     log_action_end_msg $?
   fi
fi
which means: "skip these lines if the boot process still has not switched to 
the default runlevel,
unless it is single user". The following script located in /etc/boot.d:
#!/bin/sh -e
#
# networking-restart
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.

if test -x /etc/init.d/networking ; then
     service networking restart
fi
will restart the service and from this moment, both "auto " and "allow-hotplug 
" will take effect.
This way, the delay will occur only in the case of a single user default 
runlevel, which is often not the case.

     IIUC this means that network startup is deferred. Does it mean 
starting ntp, ssh and/or web services before the network is available? 
Doesn't this method defeat the whole purpose of the dependencies 
inserted as comments in the headers of the RC scripts? I ask this 
because I'm not sure of my understanding of the whole mechanism. 
Wouldn't it be cleaner to change the priorities?


     Clearly there is a wrong assignment of priorities in the startup: 
there is no reason that the login prompt and all the applications which 
do not depend on the network have to wait until the network startup 
times out. AFAIU your method is a workaround for this misconfiguration. 
But the timeout is still there before you can use the network, while in 
most cases, it should not. And, if you haven't a server like ifupdown or 
netplug, you're going to need to restart networking everytime you 
plug/unplug your Ethernet cable.


 The ifupdown API, driven by the configuration of 
/etc/network/interfaces is well suited for static network configuration; 
it offers a lot of possibilities to the admin, eg bonding. The addition 
of the stanza "inet dhcp" has made it usable with dynamic network 
configuration, and the addition of the stanza "allow-hotplug" in 
replacement of "auto" has made it usable with hotplug network interfaces 
such as USB-Ethernet or USB-WIFI adapters.


 But this does not respond to the cases where one or more 
interfaces are not *always* connected, in particular the case of laptops 
which have one single connection to the network, *alternatively* through 
Wifi and through Ethernet. In this case, the connection is done through 
Ethernet when the Ethernet cable is connected and through Wifi otherwise 
and it is a nonsense to try to bring eth0 up when the Ethernet cable is 
not plugged in. Instead, eth0 must be brought respectively up and down 
when the cable is connected and disconnected, and, simultaneously wlan0 
must be brought down and up.


 I don't know any stanza of the interfaces file which might achieve 
that because there is no feature such as the detection of the Ethernet 
carrier in ifupdown - ifupdown is not a server. This functionality can 
be provided by ifplugd, and AFAIK by netplug. These two servers detect 
changes in the presence of the Ethernet carrier and make use of the 
ifupdown API to bring the interfaces up and down. In this situation, 
stanzas like "auto" and "allow-hotplug" are nothing but nuisances.


 It would be very nice if the installer could provide a dialog to 
configure this, but it does not look like an easy job. Maybe the user 
could be directed to some documentation.



--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 07/02/2022 à 16:22, fsmithred via Dng a écrit :

On 2/7/22 06:35, Didier Kryn wrote:

Le 07/02/2022 à 08:29, aitor a écrit :

I've uploaded new iso images fixing a bug related to the last change in
simple-netaid for
compatibility with static ip addresses, that involved the response to
routing table netlink
events triggered by other processes. The images come with vdev by
default. Next step will be
to write a runit script for ifupdown that intend to solve the problem of
the still remaining
(at least booting with vdev) long delayed boot time when using
"allow-hotplug "
stanzas in /etc/network/interfaces.

     The long delay is also present with sysvrc. It can be supressed by
just removing the "allow-hotplug" line, without replacing it by an "auto"
line, and relying on ifplugd or netplug to detect the presence of the
carrier and trigger the configuration of the interface. The delay is
suppressed because 'ifup -a' does not find any interface to bring up and
carrier to wait for; and then ifplugd/netplug brings them up only when the
carrier is detected. Dunno if simple-netaid can play the role of ifplugd
or netplug.

--     Didier


I keep updating your check-link-state.patch on /etc/network/interfaces. It
seems to still be working with allow-hotplug.

The original discussion on DNG is gone, but I saved part of it here:
https://dev1galaxy.org/viewtopic.php?pid=15493#p15493

I think the line numbers are right for chimaera, but I always edit this
manually.

--- networking.orig 2021-11-08 08:47:47.520020285 -0500
+++ patches/networking.patched  2019-12-14 11:13:07.842536000 -0500
@@ -112,7 +112,13 @@
done)
if [ -n "$ifaces" ]
then
-   ifup $ifaces "$@" || true
+   # link detection does not work unless we up the link
+   ip link set "$iface" up || true
+   if [ "$(cat /sys/class/net/$link/operstate)" = up ]
+   then
+   echo "$iface"
+   fi
+
fi
  fi
  }

    Sorry but I doubt that the patch is from me, specially because I'm 
not familiar (yet) with the ip command, which replaced ifconfig.


    The problem I met, like most people with a laptop is that I have 
both eth0 and wlan0. Invoquing ifup -a at boot causes a delay when no 
Ethernet cable is plugged in, which is the usual situation. This is 
because ifupdown then waits for the carrier and only gives up after a 
delay, and only then, brings up wlan0 (given eth0 is listed first in the 
interfaces file).


    "allow-hotplug" is meant for network *devices* (not cables) you 
plug in on the fly, like USB-Ethernet adapters. The word hotplug does 
not mean that the cable is plugged in/out on the fly. In most cases, 
"allow-hotplug" is equivalent to "auto". But, when bringing up an 
interface, ifupdown waits until the carrier is detected or the timeout 
is expired. When there is no cable, there is no carrier, and the timeout 
is pretty long.


    On the other hand, ifplugd or netplug are awakened when the carrier 
is detected on one of the interfaces they control, and then, they invoke 
ifup for the interface in question, just when it makes sense. If you 
remove the "allow-hotplug" and "auto" stanzas, ifup -a will just do 
nothing, hence no wait. Therefore the solution is to install ifplugd or 
netplug, configure it, and eliminate the "allow-hotplug" stanzas from 
/etc/network/interfaces.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev in chimaera

[Didier Kryn]

Le 07/02/2022 à 08:29, aitor a écrit :

I've uploaded new iso images fixing a bug related to the last change in 
simple-netaid for
compatibility with static ip addresses, that involved the response to routing 
table netlink
events triggered by other processes. The images come with vdev by default. Next 
step will be
to write a runit script for ifupdown that intend to solve the problem of the 
still remaining
(at least booting with vdev) long delayed boot time when using "allow-hotplug 
"
stanzas in /etc/network/interfaces.


    The long delay is also present with sysvrc. It can be supressed by 
just removing the "allow-hotplug" line, without replacing it by an 
"auto" line, and relying on ifplugd or netplug to detect the presence of 
the carrier and trigger the configuration of the interface. The delay is 
suppressed because 'ifup -a' does not find any interface to bring up and 
carrier to wait for; and then ifplugd/netplug brings them up only when 
the carrier is detected. Dunno if simple-netaid can play the role of 
ifplugd or netplug.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What is your take on finit?

[Didier Kryn]

Le 31/01/2022 à 19:16, Steve Litt a écrit :

     Writing a self-daemonizing daemon in C was a routine when I was
still active, though I understand it could be more difficult in shell.

But more difficult in Python. I try to stay away from C if Python does
the job. I think Python3 plus its standard libraries are more secure
than C code written by the error prone Steve Litt.


    Let me generalize: "I think Python3 plus its standard libraries are 
more secure than C code written by an error prone human being." (~:


    Actually I don't know Python, but I think I can trust you because I 
consider C/C++ amongst the most insecure languages. But this is one of 
my favourite themes...


--     Didier



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What is your take on finit?

[Didier Kryn]

Le 29/01/2022 à 21:00, k...@aspodata.se a écrit :

I don't see the point in letting init do serious process monitoring.
Just use a minimal init and startup a separate process monitoring
daemon (or what theese things are called).

...
I don't see the point, learn to write good deamons. It seems the need
to use theese process monitors has sprung up from the availability
of shitty deamons.
  In my view, when a deamon dies by any other cause than from your will
then it shall die so hard that it causes a major headacke and the shitty
programmer should be publicly flogged as a reminder and example to other
programmers -- well not really, but you get my point.

Most deamons I have run, they just run, they don't need a process monitor
except me.

    I fully share this pov. I'm happy with sysvinit or Busybox init.  
If I was still active, and needing to write daemons, I would certainly 
welcome improvements on the following points:


    - simplify start/stop scripts and find a better way to express 
their dependencies

    - help daemons ack when they're actually ready

    Writing a self-daemonizing daemon in C was a routine when I was 
still active, though I understand it could be more difficult in shell. 
Also I like that the logs are sent to syslog.


    But, as a user, I'm satisfied with sysvinit. Boot is so fast that 
I've abandonned the use of suspend/resume.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] PHP 8.1 depends on systemd?

[Didier Kryn]

Le 29/01/2022 à 18:46, goli...@devuan.org a écrit :




PHP is not relevant to my world but perhaps related to this thread?

https://dev1galaxy.org/viewtopic.php?id=3331


    AFAIU the name of the dependency, PHP isn't able to create a 
temporary file without the help or permission of Systemd.


    How scary!

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What is your take on finit?

[Didier Kryn]

Le 26/01/2022 à 08:59, Martin Steigerwald a écrit :

Hi!

I saw this coming into Debian Sid, so should be available in Devuan
Ceres as well:

https://troglobit.com/projects/finit/

Sounds interesting, I'd say.

Best,


    There are few very interesting point in this announcement.

    1) It comes in Debian like an *alternative to systemd*, which I 
find amazing. Which suggest the question why this alternative and not 
others?


    2) It comes from the embedded world, which supposes it is 
lightweight. The fact that it supports both udev and mdev (and also 
static /dev). Lightweight and support of mdev are very good points for me.


    3) The fact that it integrates in one application init + all modes 
of process launching and supervision, + watchdog + getty is against the 
principle of Do One Thing and Do It Well, and the only weakpoint IMHO.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Bug in synaptic package manager?

[Didier Kryn]

Le 25/01/2022 à 09:49, Olaf Meeuwissen via Dng a écrit :

Hi Tito,

tito via Dng  writes:


Hi,
while trying to open the Settings>Repositories menu in Synaptic package manager 
i get:

  synaptic-pkexec
ERROR:root:Cannot import UbuntuDrivers: No module named 'UbuntuDrivers'
Traceback (most recent call last):
   File "/usr/bin/software-properties-gtk", line 101, in 
 app = SoftwarePropertiesGtk(datadir=options.data_dir, options=options, 
file=file)
   File 
"/usr/lib/python3/dist-packages/softwareproperties/gtk/SoftwarePropertiesGtk.py",
 line 109, in __init__
 SoftwareProperties.__init__(self, options=options, datadir=datadir)
   File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
109, in __init__
 self.reload_sourceslist()
   File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
599, in reload_sourceslist
 self.distro.get_sources(self.sourceslist)
   File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in 
get_sources
 raise NoDistroTemplateException(
aptsources.distro.NoDistroTemplateException: Error: could not find a 
distribution template for Devuan/chimaera


Could this be a bug ot did I just manage to break my setup once again?

Here's wondering why youu'd need UbuntuDrivers on a Devuan system but
...  I'd try an `apt update` with root privileges on the command line
to check that your APT sources are okay.  Probably

   sudo apt update

will do that trick.  If that goes alright (ignoring network issues), you
didn't obviously break your APT setup.

You might also want to post the output of

   sed 's/#.*//; /^[ \t]*$/d' /etc/apt/sources.list{,.d/*}

so we can see what sources you're using.

BTW, I don't use synaptic myself.  Too much bloat.  The command-line
suits my needs just fine.


    I'd have loved using aptitude but could never understand how to do 
the simplest thing with it, although I watched several experts using it 
and was impressed. As a menu-driven package manager, I very often use 
Synaptic, leaving apt-get for quick simple things or when dist-upgrading.


    I don't use synaptic with pkexec to get the permission. I think I 
haven't pkexec installed. I have a button on my pannel programmed with 
sh -c "SUDO_ASKPASS=/usr/bin/ssh-askpass sudo -A synaptic".


    For this to work, I must have ssh-askpass installed, /etc/sudoers 
configured to allow me to invoque synaptic, plus the following line in 
/etc/sudoers:


Defaults env_keep = "EDITOR LOGNAME XAUTHORITY DISPLAY"

    Only XAUTHORITY and DISPLAY  are needed in this case, the other 
variables serve other purposes.


    Hth.

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] kernel-update: initramfs fails to find swap

[Didier Kryn]

Le 21/01/2022 à 15:45, Florian Zieboll via Dng a écrit :

after the latest kernel-update (chimaera, from 5.10.0-10-amd64 to
5.10.0-11-amd64), my desktop's initramfs no longer finds the swap
(suspend/resume) partition.

Running 'update-initramfs -u' returns the correct UUID "to resume
from", and also adding the line

resume=UUID=

to '/etc/initramfs-tools/conf.d/resume' does not solve the issue:
Booting stalls for half a minute and then continues with the
information that it "gave up waiting for suspend/resume device".


    I must have missed something in the evolution of Linux because I'm 
extremely surprised initramfs has anything to do with suspend/resume. 
For me it was purely a kernel buizness, a mechanism in which all of the 
memory and registers is dumped to the swap partition. At the time when 
suspend occurs, the initramfs is already gone forever and, when resuming 
the kernel restarts the system where it was suspended.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Question re: security/info sent with emails and more

[Didier Kryn]

Le 20/01/2022 à 13:32, o1bigtenor via Dng a écrit :

Greetings

When I look at the headers from my emails and sometimes available
in websites all this information about my system is included.

Is there a way to block the sending of this particular information?


    First thing: don't use gmail. gmail == google = aspiration of all 
data about you. Google knows everything about you even better than your 
mother. Plus all the network of your relations. Not only Google, also 
the 3-letter agencies.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] nftables firewall and fail2ban replacement.

[Didier Kryn]

Le 12/01/2022 à 14:49, onefang a écrit :

I've been using shorewall and fail2ban for a while now, but nftables is
soon replacing iptables, so it's time to consider some options.

Apparently fail2ban already supports nftables, but shorewall doesn't and
wont -

https://shorewall-users.narkive.com/aujuSpJ1/nftables-on-the-roadmap

My main problem with fail2ban is that it fails to ban.  Or rather it does
ban, for that one rule I wrote myself, but not for any of the built in
rules, but then it releases the ban, even though I have told shorewall to
ban that particular IP.  So the IP ends up being unbanned, coz fail2ban
says so.

Yes, I'm aware you can configure fail2ban to shift from temporary to
permanent bans for persistent rule breakers.  Would be good if the built
in rules actually worked.

Right now there's a particular IP hitting that one rule, and no matter
what I do, even completely zapping fail2ban's database and leaving it
turned off, that IP keeps bypassing my firewall somehow.

So I'll eventually need a replacement for shorewall anyway, and I'd like
something similar to fail2ban that doesn't fail to ban.  So the two
replacements have to get along with each other.  None of this "bad IP can
get through coz the two fight over it" bullshit.

This has to run on my servers and desktop, so no GUI.  I'm an experienced
sysadmin, text config is good.

Any suggestions?

    My experience/understanding of fail2ban is that it's intended 
against attackers "smart" enough to periodically change their address. 
For fix addresses, custom iptables rules was the "simple" way to go. Now 
I guess it's custom nftables rules.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 09/01/2022 à 13:23, Benjamin Riefenstahl a écrit :

Hi Didier,


Didier Kryn writes:

But the launchers are to be installed/uninstalled by every user in
their own ~/.local

benny wrote:

What happens, if you add another user after installation?  AFAIU default
launchers should be in a global place.

Didier Kryn writes:

     We want to install files only under /usr/local, and, for
Freedesktop.org, there's no other global place than
/usr/share/applications. Full point (AFAIK). I agree with you it's not
very clever.

Oh, you mean, the installer would tell the users to install the desktop
files themself, via xdg-install-icon?  I don't think that works very
well.
    Just cp '/usr/local/share/applications/foobar.desktop 
~/.local/applications/'
    The installer script certainly would not. But the admin might 
suggest them to.


Anyway,
<https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html>
says that /usr/local/share/applications should work fine, so there
should be no problem.


   Good finding. Actually in my session XDG_DATA_DIRS is set as you 
write. It seems it is set in /etc/alternatives/x-session-manager.


    Still one point has not been discussed yet: the config file is 
currently in /etc .


    The Linux Foundation suggests it should be put in /usr/local/etc 
(https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html


    So it seems everything is clear now. Thanks to all. I will make the 
software install in /usr/local. DO you fiond this satisfactory Hendrik?


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 08/01/2022 à 20:40, Benjamin Riefenstahl a écrit :

Hi Didier,

Didier Kryn writes:

But the launchers are to be installed/uninstalled by every user in
their own ~/.local

What happens, if you add another user after installation?  AFAIU default
launchers should be in a global place.

    We want to install files only under /usr/local, and, for 
Freedesktop.org, there's no other global place than 
/usr/share/applications. Full point (AFAIK). I agree with you it's not 
very clever.


    Users could make their .local/applications be a symlink to 
/usr/local/share/applications. This is not a standard and they would 
loose the ability to have their own private entries in their 
applications menu. I think very few users actually have private entries 
in their applications menu - this is not the same as launchers on the 
desktop. Therefore this symlink could be considered as a workaround: the 
applications menu would only expose globally installed applications, 
either provided by the distro or in /usr/local. It still has to be 
tested; Freedesktop might forbid it as well...


--  Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 08/01/2022 à 17:18, tito via Dng a écrit :

On Sat, 8 Jan 2022 15:56:19 +0100
Didier Kryn  wrote:


Le 07/01/2022 à 23:27, Hendrik Boom a écrit :
    Install can be user-configurable, this is easy, but the package 
provides
the way to uninstall and, for the uninstall to work, the install 
must be
hardcoded because the source of the package cannot remember what 
the user

has done at install time.

So the installer can create the appropriate uninstall script, based on
the parameters the user has provided.

Then the uninstall script will have the user's own locations hardcoded
into it.

    And what do you do with the uninstall script ? Is there any
standard place to store it, under what name?

    Currently, if you install hopman, you can get rid of the source.
Then, if you need to remove it, just download the source again, unpack
it and run 'make uninstall'. Having an uninstall script (actually a
makefile) is not a bad idea. We just need a standard place to put it. 
Ideas?


--     Didier


Hi,

Option A:

put it inside hopman itself.
It will get the cwd of the hopman binary,
assume that the prefix to uninstall
the other files is one level up,
create the paths and uninstall.
For example, installed in /usr/local/bin/hopman:
hopman --uninstall
are you sure? yes
getcwd returns /usr/local/bin
prefix is strrchr("/usr/local/bin", '/') => /usr/local
paths are:
prefix/etc/hopman.conf
prefix/bin/hopman/helperbin
prefix/bin/hopman
for list of paths
if paths exists rm paths

Should work with all prefixes /, ~/bin, /usr/local, /opt.

Option B:
assume that path prefix is known at compile time
hardcode the paths in the binary
remove the hardcoded paths at uninstall time

Option B1:
it would be nice if sha sums of the files to be removed
could be stored into the binary to be sure to remove the right
ones (doesn't apply to conf files if there are some).


    If you install in /usr/local, everything is standard and can be 
hardcoded and install/uninstall is done by the owner of /usr/local. But 
the launchers are to be installed/uninstalled by every user in their own 
~/.local


    When installing on /opt your method seems best. At the end the 
uninstall script must delete itself, but there is certainly a trick to 
do that. Note however that it adds quite a lot of complexity to the 
application, plus one file to install: the uninstall script. In this 
case, every user must install the launchers, but also update his PATH 
and MANPATH.


    When installing in the user's home, your method can 
install/uninstall everything and is also responsible of his PATH and 
MANPATH.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 07/01/2022 à 23:27, Hendrik Boom a écrit :

     Install can be user-configurable, this is easy, but the package provides
the way to uninstall and, for the uninstall to work, the install must be
hardcoded because the source of the package cannot remember what the user
has done at install time.

So the installer can create the appropriate uninstall script, based on
the parameters the user has provided.

Then the uninstall script will have the user's own locations hardcoded
into it.


    And what do you do with the uninstall script ? Is there any 
standard place to store it, under what name?


    Currently, if you install hopman, you can get rid of the source. 
Then, if you need to remove it, just download the source again, unpack 
it and run 'make uninstall'. Having an uninstall script (actually a 
makefile) is not a bad idea. We just need a standard place to put it. Ideas?


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 07/01/2022 à 12:13, Olaf Meeuwissen a écrit :

Concerning installation in /usr/local:
--

    My first investigations indicate that there is provision in
Freedesktop.org to put icons and launchers under $HOME/.local, but
nothing for /usr/local. Therefore the installation of an application
in /usr/local could include executable, config files and manpages, but
the icon and the launcher would be per user.
    Seems /usr/local is honoured by the base system (default PATH and
default man search path) but is "deprecated" by Freedesktop.


Concerning installation in user's space:


    As written above, Freedesktop enables icons, launchers and
applications menu in ~/.local . Man will look also by default search
~/man if it exists, but, to my knowledge, there is no default user
directory for executables; it is therefore up to the user to create
this directory and specify it when installing, which makes
uninstallation problematic.

    In this case, the installer might force the use of ~/bin and ~/man
and create them if they don't exist.

If I were you I would make the installation locations configurable, at
least at build time with an option to override at install time.

Don't know if you have any experience with building GNU software from
source but the ./configure command has options to set a whole pile of
locations:

- bindir
- libdir
- mandir
- ...

by default these locations are below a configurable prefixdir that
defaults to /usr/local so you get to install below

- /usr/local/bin
- /usr/local/lib
- /usr/local/man
-/usr/local/...

If the user runs ./configure --prefix=$HOME then everything will end up
below $HOME. If that user also added --mandir=/usr/local/man then only
the manual pages would end up there, everything else still goes below
$HOME.

Often the resulting Makefile allows specifying a staging location, a
destdir, so you can easily bundle the installed result, in a Debian
package for example;-). Setting destdir to /tmp/test, would install
that $HOME configured build in

-/tmp/test/$HOME/bin
-/tmp/test/$HOME/lib
- /tmp/test/usr/local/man
-/tmp/test/$HOME/...

but at run-time still use the location without the /tmp/test prefix.

Long story short, don't try to decide the final locations but make them
configurable and let the builder decide. Just organize the locations
using things like bindir, libdir, etc and make your code use whatever
was configured at build time.

I realize that autoconf may be less popular than it once was (cmake is
gaining popularity, it seems) but its documentation has a section on the
various installation locations it supports. Perhaps that can serve as a
guide for picking the places you need.

https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#Installation-Directory-Variables


    First I won't use GNU autotools they're very complicated and they 
make Makefiles unreadable and, in this case, it's a hammer to kill a fly.


    Install can be user-configurable, this is easy, but the package 
provides the way to uninstall and, for the uninstall to work, the 
install must be hardcoded because the source of the package cannot 
remember what the user has done at install time.


    Therefore there must be some standard locations where to put files. 
I could provide three options: /usr, /usr/local and $HOME. Then, the 
uninstall could find its way automatically, but, in the case /usr/local, 
it would be up to every user to create symlinks to icon and launcher, 
and in the case of $HOME, the directories bin and man would be created 
automatically.


--     Didier




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 07/01/2022 à 13:06, Benjamin Riefenstahl a écrit :

Hi Didier,

Didier Kryn writes:

    My first investigations indicate that there is provision in
Freedesktop.org to put icons and launchers under $HOME/.local, but
nothing for /usr/local.

I do not think that ~/.local is related to /usr/local in any meaningfull
way. /usr/local is for the administrator to put self-compiled stuff
there, stuff that should be avaiable for all accounts on the machine.
Used to be, that in some environments that directory was on a network
share, so these packages were immediatly available on all machines in
the local network.


    This is exactly what I wrote (or meant). Freedesktop provides for 
private declarations but not for anything in /usr/local, while the Linux 
command-line-ecosystem considers /usr/local as a legitimate place to put 
applications and their manpages.






    Seems /usr/local is honoured by the base system (default PATH and
default man search path) but is "deprecated" by Freedesktop.

The distribution package manager and its packages have no business
installing anything there, so there is nothing to deprecate. That the
default install add /usr/local/bin to PATH and similarly for other
directories is just a convenience. Some of the BSDs do not do that
IIRC.

    We are talking of packages which do not belong to the distro.

    The default PATH is a convenience but something very standard I 
don't thing users remove from their profiles.



Therefore the installation of an application in /usr/local could
include executable, config files and manpages, but the icon and the
launcher would be per user.

Icon pictures can be in /usr/local. XDG desktop files (which make the
applications show up in the Gnome shell and other DEs) can be installed
in /etc/xdg, like the packages from the package manager do. It is
possible that Gnome/XDG also looks into /usr/local/etc/xdg or some
similar place in addition to /etc/xdg, I haven't checked.


    I don't exacly know what /etc/xdg is. I think it contains some kind 
of template or default files as most files in /etc are. It is probably 
used when creating new users.


    The fact is that to make an application appear in the applications 
menu, there are two possible places to put the launcher: 
/usr/share/applications or ~/.local/applications .


    /etc belongs to root and has to. We are speaking of installing 
software without root permission.




/etc is used both by distribution packages and by packages in
/usr/local. Only distribution packages should install default
configurations there, and only if those files did not exist before or,
during an update, if they where not modified since installation or last
update.
    As written above, we don't want to give root permission to the 
installer.






to my knowledge, there is no default user directory for executables;

In some distibutions /etc/profile adds ~/bin to PATH, if it exists.
Again this is just a convenience. In the end /etc is for the
administrator to set her/his own policy.


    Yes, at least in Debian. But the .profile, .bash_profile and 
.bashrc are very personnal things and the ~/bin directory has to be 
created explicitely by the user and some won't, some will prefer other 
names etc...


    What the user does with his subdirs is essentially personnal up to 
the advent of Freedesktop. Freedesktop forces some directories and 
files. This policy has two faces: on one face it is an abuse, on the 
other it facilitates standardization. What Freedesktop misses/disregards 
is /usr/local.


--     Didier



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 07/01/2022 à 10:18, Didier Kryn a écrit :

Le 06/01/2022 à 22:00, Bob Proulx via Dng a écrit :

Didier Kryn wrote:

Hendrik Boom a ecrit :

software that isn't properly packaged as a .deb, but instead has an
"installer" that needs to be run as root.

Immediately I think of all of those script "installers" that request
the user do this and similar to install their software as root this way.

 wget -O- http:/example.com/foo.sh | bash

How many projects do this?  Hundreds?  Thousands?

In real life I have encountered many CAD/EDA tool vendors with
installation scripts that casually make system modifications not
knowing what they do.  I try to keep those contained.

In real life I have encountered sysadmins who have casually modified
modules, python in this case but it could have been other, in /usr/lib
outside of the package manager or any tracking.  Then later normal
machine upgrades were broken because newer modules were broken by
upgrading older ones.  If those had been made into /usr/local instead
it would have been both visible and would not have been broken by
normal system upgrades.

Being more than twice burned I am extremely shy now...

 If the installer must be run as root, it is precisely because 
it needs

to install software in /usr.

Or into /usr/local which now requires root.  Back in the better days
of Debian it used to be possible for a user of group staff to install
into /usr/local without full superuser access.  But that's gone from
the installation now.

 https://bugs.debian.org/484841#62

Since that has been removed in favor of using full root for everything
it removes a useful safety net layer.  For example this statement.

 Russ Allbery writes in comment #77 in favor of using full root
 instead of a more limited group staff.

 I would prefer to drop the writeability of /usr/local by staff
 personally.  I don't think it serves much useful purpose these days
 given the existence of tools like sudo, and where it does, I 
think we
 can work out a transition plan that will make it relatively easy 
for

 sites to recreate the concept.

And the vote went against it.  So it's gone now.  It's root only.
Sigh.  On my systems I recreate the group staff concept and
implementation.  Because I do find it useful.


Such software should be installing to /opt, but might not.
 Installing application and configuration files in /opt is a 
possibility,
but what to do with man page, application launcher, entry in the 
application

menu? Installing in /opt does not require to mount /usr readonly. Just
create a particular user account for /opt and use it to install. 
Even one

user and one subdir per application.

Although I am not fully warmed up to /opt even after all of these
years for each of these questions there is a strategy to handle it.
PATH, MANPATH, desktop launcher files, and so forth.  But those are
all already set up for /usr/local by default.  /opt by the nature of
it being outside of the normal system then requires everything to be
set up for it.  Which is possible and easily done.  But then also must
be done if used.

 I have written such a software, called hopman. This 
discussion suggests
me that I should provide the option to install it in a user's 
directory,

without the need to be root, rather than install it system-wide.

I would say yes.  If it is intended to be installed outside of being
packaged for the system then it should be easily installed both by
root (or the classic group staff) in /usr/local or by the user as
non-root installed into the user's $HOME.

Back in 2019 Didier Kryn wrote:
 > cd hopman/hopman-1.0
 > make && make install # You must be root to install
 > Installed files: /usr/bin/hopman, ...

I didn't follow things beyond this so do not know how things evolved,
and it isn't fair of me to reach back into the original if it has
improved and evolved since then.  Sorry.  My bad.  But in the above it
really should install that into /usr/local/bin (or sbin) by default
instead of /usr/bin.

For my own environment I would run that as myself in group staff which
can write to /usr/local/bin without root.  I would run it.  It would
fail.  I would notice that it was trying to install into /usr/bin.  I
would review and inspect.  I would then make adjustments so that on my
system it installed into /usr/local.  Having a read-only /usr in order
to detect these issues by preventing them is useful.  In my case
readonly is achieved by not being root.  But since we are training a
new generation that one must be root for everything then mounting
/usr read-only kicks the can down the road and pushes the problem
around to a different place.  But root can always remount it
read-write.  And the arms conflict continues.  Is Qubes the logical
conclusion?

 https://www.qubes-os.org/

I also do not know the design of this particular tool hopman. It may
require by the nature of it an i

Re: [DNG] xdg-desktop-portal

[Didier Kryn]

Le 06/01/2022 à 22:30, Ken Dibble a écrit :
At the risk of confirming that I am none too smart, I have the 
following question.\


Why is xdg-desktop-portal in a fresh install of Chimaera?\

It can be safely uninstalled, as it no devuan packages in the base 
install require it,


and as far as I can tell it is only needed for snap and systemd type 
stuff.


I only noticed it because it screws with df.

Can someone enlighten me? 



    Everything xdg* is Freedesktop. I don't kow about this new package 
proper.


    I draw your attention to $HOME/.config/user-dirs.dirs, which 
governs the default directories used by some applications and which, 
therefore, are created by your desktop env if they don't exist.


    If you want to get rid of some of them, it is not enough to remove 
them, you should also redefine them in this file.


Hth.

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 06/01/2022 à 22:00, Bob Proulx via Dng a écrit :

Didier Kryn wrote:

Hendrik Boom a ecrit :

software that isn't properly packaged as a .deb, but instead has an
"installer" that needs to be run as root.

Immediately I think of all of those script "installers" that request
the user do this and similar to install their software as root this way.

 wget -O- http:/example.com/foo.sh | bash

How many projects do this?  Hundreds?  Thousands?

In real life I have encountered many CAD/EDA tool vendors with
installation scripts that casually make system modifications not
knowing what they do.  I try to keep those contained.

In real life I have encountered sysadmins who have casually modified
modules, python in this case but it could have been other, in /usr/lib
outside of the package manager or any tracking.  Then later normal
machine upgrades were broken because newer modules were broken by
upgrading older ones.  If those had been made into /usr/local instead
it would have been both visible and would not have been broken by
normal system upgrades.

Being more than twice burned I am extremely shy now...


 If the installer must be run as root, it is precisely because it needs
to install software in /usr.

Or into /usr/local which now requires root.  Back in the better days
of Debian it used to be possible for a user of group staff to install
into /usr/local without full superuser access.  But that's gone from
the installation now.

 https://bugs.debian.org/484841#62

Since that has been removed in favor of using full root for everything
it removes a useful safety net layer.  For example this statement.

 Russ Allbery writes in comment #77 in favor of using full root
 instead of a more limited group staff.

 I would prefer to drop the writeability of /usr/local by staff
 personally.  I don't think it serves much useful purpose these days
 given the existence of tools like sudo, and where it does, I think we
 can work out a transition plan that will make it relatively easy for
 sites to recreate the concept.

And the vote went against it.  So it's gone now.  It's root only.
Sigh.  On my systems I recreate the group staff concept and
implementation.  Because I do find it useful.


Such software should be installing to /opt, but might not.

 Installing application and configuration files in /opt is a possibility,
but what to do with man page, application launcher, entry in the application
menu? Installing in /opt does not require to mount /usr readonly. Just
create a particular user account for /opt and use it to install. Even one
user and one subdir per application.

Although I am not fully warmed up to /opt even after all of these
years for each of these questions there is a strategy to handle it.
PATH, MANPATH, desktop launcher files, and so forth.  But those are
all already set up for /usr/local by default.  /opt by the nature of
it being outside of the normal system then requires everything to be
set up for it.  Which is possible and easily done.  But then also must
be done if used.


 I have written such a software, called hopman. This discussion suggests
me that I should provide the option to install it in a user's directory,
without the need to be root, rather than install it system-wide.

I would say yes.  If it is intended to be installed outside of being
packaged for the system then it should be easily installed both by
root (or the classic group staff) in /usr/local or by the user as
non-root installed into the user's $HOME.

Back in 2019 Didier Kryn wrote:
 > cd hopman/hopman-1.0
 > make && make install # You must be root to install
 > Installed files: /usr/bin/hopman, ...

I didn't follow things beyond this so do not know how things evolved,
and it isn't fair of me to reach back into the original if it has
improved and evolved since then.  Sorry.  My bad.  But in the above it
really should install that into /usr/local/bin (or sbin) by default
instead of /usr/bin.

For my own environment I would run that as myself in group staff which
can write to /usr/local/bin without root.  I would run it.  It would
fail.  I would notice that it was trying to install into /usr/bin.  I
would review and inspect.  I would then make adjustments so that on my
system it installed into /usr/local.  Having a read-only /usr in order
to detect these issues by preventing them is useful.  In my case
readonly is achieved by not being root.  But since we are training a
new generation that one must be root for everything then mounting
/usr read-only kicks the can down the road and pushes the problem
around to a different place.  But root can always remount it
read-write.  And the arms conflict continues.  Is Qubes the logical
conclusion?

 https://www.qubes-os.org/

I also do not know the design of this particular tool hopman.  It may
require by the nature of it an installation into the root file system
at the system level.  For

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 05/01/2022 à 23:12, Hendrik Boom a écrit :

On Wed, Jan 05, 2022 at 09:54:20PM +0100, Didier Kryn wrote:

Le 05/01/2022 à 16:11, Hendrik Boom a écrit :

On Wed, Jan 05, 2022 at 12:08:18AM +0100, Didier Kryn wrote:

Le 04/01/2022 à 23:38, Hendrik Boom a écrit :

On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:

There is no utility in splitting the OS in several partitions.

Might it make sense to have /usr mounted readonly except when upgradng
or installing paackages?


    What could you fear which makes you want to keep /usr readonly.

software that isn't properly packaged as a .deb, but instead has an
"installer" that needs to be run as root.
    If the installer must be run as root, it is precisely because it 
needs

to install software in /usr. You have an alternative: either mount /usr
readwrite and install it, or keep /usr readonly and not install it. 
Keeping

/usr readonly and trying to install the software has no chance to work.


Such software should be installing to /opt, but might not.
    Installing application and configuration files in /opt is a 
possibility, but what to do with man page, application launcher, entry 
in the application menu? Installing in /opt does not require to mount 
/usr readonly. Just create a particular user account for /opt and use it 
to install. Even one user and one subdir per application.


    I have written such a software, called hopman. This discussion 
suggests

me that I should provide the option to install it in a user's directory,
without the need to be root, rather than install it system-wide.


software that is properly packaged, but has components that run as root
but do stuff with /usr outside my expectations.

    Do you mean a package from a Debian repository which would install a
trojan horse in /usr?
Packages from other sources that are built for Debian but aren't part 
of Debian.


    For these ones my personal attitude is binary: either I trust them 
or I don't, not half. Anyway, is there a difference wether the Trojan 
horse is in /usr or /opt ? Which matters is rather the permissions it 
has, then at first glance, creating an account per application seems a 
good practice.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 05/01/2022 à 16:11, Hendrik Boom a écrit :

On Wed, Jan 05, 2022 at 12:08:18AM +0100, Didier Kryn wrote:

Le 04/01/2022 à 23:38, Hendrik Boom a écrit :

On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:

There is no utility in splitting the OS in several partitions.

Might it make sense to have /usr mounted readonly except when upgradng
or installing paackages?


     What could you fear which makes you want to keep /usr readonly.

software that isn't properly packaged as a .deb, but instead has an
"installer" that needs to be run as root.


    If the installer must be run as root, it is precisely because it 
needs to install software in /usr. You have an alternative: either mount 
/usr readwrite and install it, or keep /usr readonly and not install it. 
Keeping /usr readonly and trying to install the software has no chance 
to work.


    I have written such a software, called hopman. This discussion 
suggests me that I should provide the option to install it in a user's 
directory, without the need to be root, rather than install it system-wide.



software that is properly packaged, but has components that run as root
but do stuff with /usr outside my expectations.


    Do you mean a package from a Debian repository which would install 
a trojan horse in /usr?


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] busybox init

[Didier Kryn]

Le 04/01/2022 à 03:08, Steve Litt a écrit :

k...@aspodata.se  said on Mon,  3 Jan 2022 18:45:28 +0100 (CET)



Would there be any interests having a busybox_init package which
I could possible maintain (with a little help) ?

My opinion is that the more init systems the merrier, except for
systemd.

If busybox init does not require daemons to self-background, I'd be
even more enthusiastic.

SteveT


    Busybox init is merely a simplified replacement for sysvinit. As 
sysvinit, it can be used to invoke either the famous scripts invoquing 
servers which background themselves or any supervisor or launcher of 
your choice.


    The striking feature of Busybox, in the context of a /usr merge, is 
that it has no runtime dependency if you build it as a statically linked 
executable, which is probably the most popular way to build it. I.e. it 
does not need a shared library to run, therefore does not depend on 
anything in /usr. And it provides anything you would find in /bin and 
/sbin and all the base system utilities you can find in /usr/bin and 
/usr/sbin. When you configure it, you just specify the applictions you want.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 04/01/2022 à 23:38, Hendrik Boom a écrit :

On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:

There is no utility in splitting the OS in several partitions.

Might it make sense to have /usr mounted readonly except when upgradng
or installing paackages?

    What could you fear which makes you want to keep /usr readonly. If 
your OS is broken, you can reinstall it in a few hours. And the most 
likely thing which can break it is the package manager itself.


    Recently it happenned to me on Chimaera that some packages were 
broken, because of incompatible versions between backports and stable. I 
eventually solved the problem with the only help of Synaptic, and 
finally eliminated backports from sources.list. If necessary, I would 
just have re-installed Devuan without backports from the beginning.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 04/01/2022 à 18:48, k...@aspodata.se a écrit :

Didier:

The simplest way to kick off problms with /usr merge is to *not*
make /usr a mountpoint.

Perhaps, but why break working systems, especially when they are
3h car ride from home and all in differnt locations.
That is just rude.


There is no utility in splitting the OS in several partitions.

...

My systems, my rules.

    I totally agree, "your system, your rules" (~: . And I fully agree 
that forcing the merge is at least impolite. I was just trying to 
de-dramatize the question. When some change prevents you to follow "your 
rules", the practical response is not to rant after the change (the 
merge) but first question the said rules.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

    The simplest way to kick off problms with /usr merge is to *not* 
make /usr a mountpoint. There is no utility in splitting the OS in 
several partitions. This wouldn't help you recover the OS if one 
partition is broken since the package manager installs/deinstalls files 
not only on /usr, but also /, /etc, /boot, /var. Splitting is even 
discouraged if you use a filesystem with snapshots like btrfs (whih 
isn't my case). The only thing which may (and should) be on a different 
disk (not partition) is the precious user data, ie /home.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] busybox init

[Didier Kryn]

Le 03/01/2022 à 21:27, tito via Dng a écrit :

On Mon,  3 Jan 2022 18:45:28 +0100 (CET)
k...@aspodata.se wrote:


  I have used busybox init for a while. It differs from sysvinit
by not having runlevels, except perhaps on and off.

Busybox repo is at: git://busybox.net/busybox.git
Website at: https://busybox.net/
Comment re. systemd: https://busybox.net/kill_it_with_fire.txt

Example inittab at:
  https://git.busybox.net/busybox/tree/examples/inittab
excerpt:

# Note: BusyBox init works just fine without an inittab. If no inittab is
# found, it has the following default behavior:
#   ::sysinit:/etc/init.d/rcS
#   ::askfirst:/bin/sh
#   ::ctrlaltdel:/sbin/reboot
#   ::shutdown:/sbin/swapoff -a
#   ::shutdown:/bin/umount -a -r
#   ::restart:/sbin/init
#   tty2::askfirst:/bin/sh
#   tty3::askfirst:/bin/sh
#   tty4::askfirst:/bin/sh

The sysinit thing is a how you start the system, it's just
one script /etc/init.d/rcS (or where you prefer to place it).

One could possible (not tested) mimic sysvinit bootup by having
  for i in /etc/rc2.d/S*; do $i start; done
in the rcS file or if you prefer you can have your own handwritten
and tuned script there.

Would there be any interests having a busybox_init package which
I could possible maintain (with a little help) ?

Regards,
/Karl Hammar


Hi,
just to add my 2 cents.

I would build a static compiled busybox binary with:

init
a shell
reboot, shutdown
swapon/swapoff
mount, umount
(start-stop-daemon)
(getty, login)
    AFAIR you would also need cttyhack, setsid and a few others I've 
forgotten if you want to be able to debug it.


able to fully bring up a system.
We could call it systemB like the other one but _B_etter.
Then we implant it as blob into the kernel image
so that we get rid also of initrds creating a
PAC man like  GNU/Linux/systemB/Frankenstein monster
that eats all little sysDs.

    This wasn't the proposal of Karl. He just suggested a KISS 
replacement for sysvinit. But it does not solve the issue of the 
complexity of the RC scripts: they remain exactly the same and this is 
the main (only ?) issue with them.


    The boot time is no longer an issue with faster cpus and disks. My 
laptop takes 20s to boot Chimaera and the longest is the kernel, not the 
RC scripts. I've stopped several years ago to use any mode of suspend. 
On Dell servers, the BIOS startup takes at least 10 times as long as 
Linux boot.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Lead or follow? this decade’s dilemma for GNU/Linux based ICT industry

[Didier Kryn]

Le 30/12/2021 à 07:53, Steve Litt a écrit :
> The one improvement I can suggest with the article is to define all
> acronyms once within the text. Because I'm from North America, I call
> it "IT", and it took 10 minutes of looking up to find out that "ICT" is
> a European acronym for basically the same thing. It took about 25
> minutes to find out what an "SME" is.

    Thanks Steve. I'm an european and still can't remember the meaning
of both acronyms, although I understand from the context that they name
in some way the computer technology (~:

    For the article, English not being my mother tongue, I feel rather
confused (the html version doesn't help) although I understand that
Jaromil shares the same concerns as many of us about who manages the
future of Linux and in what direction. It is clear that Linus Torvalds
doesn't deal only with benevolent contributors. For userland I feel more
comfortable that there will long be a possibility to keep the freedom,
given we still get the kernel.

--    Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Pipewire and PulseAudio: apulse & firefox

[Didier Kryn]

Le 18/12/2021 à 15:22, Florian Zieboll via Dng a écrit :
> On December 18, 2021 2:43:30 PM GMT+01:00, Didier Kryn  wrote:
>
>> apt-get remove --purge libpulse0 wants to remove the following (which
>> includes gimp):
>>
>> The following packages will be REMOVED:
>>   atril* audacious* audacious-plugins* blueman* ffmpeg* font-manager*
>> geeqie*
>>   gimp* gstreamer1.0-libav* gstreamer1.0-plugins-good* libasound2-plugins*
>>   libatrilview3* libavdevice58* libavfilter7* libffmpegthumbnailer4v5*
>>   libfluidsynth2* libgegl-0.4-0* libgimp2.0* libopenscenegraph161*
>>   libpocketsphinx3* libpulse-mainloop-glib0* libpulse0* libqt5multimedia5*
>>   libsdl-image1.2* libsdl1.2debian* libsdl2-2.0-0* libsphinxbase3*
>>   libwebkit2gtk-4.0-37* libyelp0* metacity* metacity-themes* pavucontrol*
>>   qemu-system-gui* scribus* surf* vlc* vlc-plugin-base* xfce4*
>>   xfce4-pulseaudio-plugin* yelp* zenity*
>> 0 upgraded, 0 newly installed, 41 to remove and 0 not upgraded.
>
> Hallo Didier,
>
> do you perhaps have something like an auto-'autoclean' policy defined in your 
> apt configuration?
>
> Libre Grüsse,
> Florian
>
(sda5)root@apcnb98:/etc/apt/apt.conf.d# grep auto- *
01autoremove-kernels:// DO NOT EDIT! File autogenerated by
/etc/kernel/postinst.d/apt-auto-removal




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Pipewire and PulseAudio: apulse & firefox

[Didier Kryn]

Le 18/12/2021 à 14:55, Antony Stone a écrit :
> On Saturday 18 December 2021 at 14:43:30, Didier Kryn wrote:
>
>> Aptitude why libpulse0 only lists xfce4-pulseaudio-plugin, but it
>> misses a lot, including indirectly xfce4.
> Yes, this is in my opinion one of the shortcomings of "aptitude why" - it 
> only 
> goes "one level up", whereas I would like it to follow each dependency until 
> it finds something that was installed manually, or is a system-essential 
> component.
>
> So, you did "aptitude why libpulse0" and it said "xfce4-pulseaudio-plugin".
>
> However, was that:
>   "xfce4-pulseaudio-plugin Depends libpulse0" or
>   "xfce4-pulseaudio-plugin Recommends libpulse0" or
>   "xfce4-pulseaudio-plugin Suggests libpulse0" ?
    depends. This is obvious. the plugin needs at least to determine if
PA is installed. libpulse0 plays the same role as libsystemd0. And
package xfce4 is probably a virtual package which has no content but
only dependencies, one of them being xfce4-pulseaudio-plugin. The
problem is when you remove xfce4, all the useful stuff of xfce4 which
were installed automatically become "removable" and you need to turn
them one by one to "manually installed" to secure them.
>
> The next step is to do "aptitude why xfce4-pulseaudio-plugin" and keep 
> following things until you discover which package that you installed 
> manually, 
> or which essential system component, ultimately means you ended up with 
> libpulse0.
>
>> apt-get remove --purge libpulse0 wants to remove the following (which
>> includes gimp):
>>
>> The following packages will be REMOVED:
>>   atril* audacious* audacious-plugins* blueman* ffmpeg* font-manager*
>> geeqie*
>>   gimp* gstreamer1.0-libav* gstreamer1.0-plugins-good* libasound2-plugins*
>>   libatrilview3* libavdevice58* libavfilter7* libffmpegthumbnailer4v5*
>>   libfluidsynth2* libgegl-0.4-0* libgimp2.0* libopenscenegraph161*
>>   libpocketsphinx3* libpulse-mainloop-glib0* libpulse0* libqt5multimedia5*
>>   libsdl-image1.2* libsdl1.2debian* libsdl2-2.0-0* libsphinxbase3*
>>   libwebkit2gtk-4.0-37* libyelp0* metacity* metacity-themes* pavucontrol*
>>   qemu-system-gui* scribus* surf* vlc* vlc-plugin-base* xfce4*
>>   xfce4-pulseaudio-plugin* yelp* zenity*
>> 0 upgraded, 0 newly installed, 41 to remove and 0 not upgraded.
> Do you get the same list of packages from "aptitude purge libpulse0"?
    Here it is: to preserve the dependent packages, aptitude recommends
to not do the requested action! It seems to stay in the middle of the
dependency tree because it misses some ultimately dependant packages.

(sda5)root@apcnb98:~# aptitude purge libpulse0
The following packages will be REMOVED: 
  libasyncns0{u} libpulse0{p}
0 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 1,039 kB will be freed.
The following packages have unmet dependencies:
 libsphinxbase3 : Depends: libpulse0 (>= 0.99.1) but it is not going to
be installed
 libfluidsynth2 : Depends: libpulse0 (>= 0.99.1) but it is not going to
be installed
 audacious-plugins : Depends: libpulse0 (>= 0.99.1) but it is not going
to be installed
 libavdevice58 : Depends: libpulse0 (>= 0.99.1) but it is not going to
be installed
 libasound2-plugins : Depends: libpulse0 (>= 0.99.1-1~) but it is not
going to be installed
 pavucontrol : Depends: libpulse0 (>= 4.0) but it is not going to be
installed
 libpulse-mainloop-glib0 : Depends: libpulse0 (= 14.2-2) but it is not
going to be installed
 libqt5multimedia5 : Depends: libpulse0 (>= 0.99.1) but it is not going
to be installed
 gstreamer1.0-plugins-good : Depends: libpulse0 (>= 2.0) but it is not
going to be installed
 libsdl2-2.0-0 : Depends: libpulse0 (>= 0.99.1) but it is not going to
be installed
 libsdl1.2debian : Depends: libpulse0 (>= 0.99.1) but it is not going to
be installed
 xfce4-pulseaudio-plugin : Depends: libpulse0 (>= 0.99.1) but it is not
going to be installed
 qemu-system-gui : Depends: libpulse0 (>= 0.99.1) but it is not going to
be installed
 vlc-plugin-base : Depends: libpulse0 (>= 1.0) but it is not going to be
installed
The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) libasyncns0 [0.8-6+b2 (now, stable)]  
2) libpulse0 [14.2-2 (now, stable)]




Accept this solution? [Y/n/q/?]


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Pipewire and PulseAudio: apulse & firefox

[Didier Kryn]

Le 18/12/2021 à 12:25, Antony Stone a écrit :
>> Please can you post the output of "aptitude show gimp" from the machine
>> where you have seen this?
> Another useful output to see would be "aptitude why XXX" where XXX is any of 
> the PA libraries you say you have found which gimp etc. depends on.
>
> "why" will tell you which other packages either depend on, or recommend, the 
> one you've asked about, and is a useful way to find out how (or indeed why) 
> something got installed on your machine.
>
    Aptitude why libpulse0 only lists xfce4-pulseaudio-plugin, but it
misses a lot, including indirectly xfce4.

apt-get remove --purge libpulse0 wants to remove the following (which
includes gimp):

The following packages will be REMOVED:
  atril* audacious* audacious-plugins* blueman* ffmpeg* font-manager*
geeqie*
  gimp* gstreamer1.0-libav* gstreamer1.0-plugins-good* libasound2-plugins*
  libatrilview3* libavdevice58* libavfilter7* libffmpegthumbnailer4v5*
  libfluidsynth2* libgegl-0.4-0* libgimp2.0* libopenscenegraph161*
  libpocketsphinx3* libpulse-mainloop-glib0* libpulse0* libqt5multimedia5*
  libsdl-image1.2* libsdl1.2debian* libsdl2-2.0-0* libsphinxbase3*
  libwebkit2gtk-4.0-37* libyelp0* metacity* metacity-themes* pavucontrol*
  qemu-system-gui* scribus* surf* vlc* vlc-plugin-base* xfce4*
  xfce4-pulseaudio-plugin* yelp* zenity*
0 upgraded, 0 newly installed, 41 to remove and 0 not upgraded.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Pipewire and PulseAudio: apulse & firefox

[Didier Kryn]

Le 17/12/2021 à 23:29, Didier Kryn a écrit :
> Le 17/12/2021 à 20:32, Marc Shapiro via Dng a écrit :
>> On 12/16/21 04:44, Didier Kryn wrote:
>>> Le 16/12/2021 à 07:08, Marc Shapiro via Dng a écrit :
>>>> I don't think I'm up for compiling firefox from source.  And it would
>>>> have to be recompiled every time mozilla releases a new version.
>>>>
>>>  Why do you need to track the very last version from Mozilla? The
>>> package provided in Devuan Chimaera just works with Alsa out of the box.
>> Not here.  I just uninstalled pulseaudio, again, and ran Firefox ESR
>> (78.15.0esr 64-bit) and got complete silence.  Xine, however, was
>> working this time.
>     Firefox isn't my daily browser but I have it installed. I'm running
> the same version of Firefox as you, on the same arch and the same distro
> and it plays sound without pulseaudio. There must be something wrong in
> your config. Have you Alsa installed? And QuasMixer? Is it the version
> of Firefox provided by the Devuan package or did you compile it yourself?

    I noticed, looking for packages the name of which include just the
string "pulse", that a few PA libraries are still installed and cannot
be removed because a lot of packages have a dependency on them, such as
xfce4, atril and even gimp! This is the same kind of cancer as Systemd
in what we can easily recognize the touch of the author.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Pipewire and PulseAudio: apulse & firefox

[Didier Kryn]

Le 17/12/2021 à 20:32, Marc Shapiro via Dng a écrit :
>
> On 12/16/21 04:44, Didier Kryn wrote:
>> Le 16/12/2021 à 07:08, Marc Shapiro via Dng a écrit :
>>> I don't think I'm up for compiling firefox from source.  And it would
>>> have to be recompiled every time mozilla releases a new version.
>>>
>>  Why do you need to track the very last version from Mozilla? The
>> package provided in Devuan Chimaera just works with Alsa out of the box.
>
> Not here.  I just uninstalled pulseaudio, again, and ran Firefox ESR
> (78.15.0esr 64-bit) and got complete silence.  Xine, however, was
> working this time.

    Firefox isn't my daily browser but I have it installed. I'm running
the same version of Firefox as you, on the same arch and the same distro
and it plays sound without pulseaudio. There must be something wrong in
your config. Have you Alsa installed? And QuasMixer? Is it the version
of Firefox provided by the Devuan package or did you compile it yourself?

    -- Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Pipewire and PulseAudio: apulse & firefox

[Didier Kryn]

Le 17/12/2021 à 20:37, Marc Shapiro via Dng a écrit :
> On 12/16/21 09:59, Steve Litt wrote:
>> Gregory Nowak via Dng said on Wed, 15 Dec 2021 19:32:11 -0700
>>
>>> On Wed, Dec 15, 2021 at 03:34:09PM -0800, Marc Shapiro via Dng wrote:
>>> You need to use /usr/bin/apulse as a wrapper around every
>>> application you want to use it.
>
> Something got clipped wrong.  It was Gregory who said that, not me.
>
> Marc 

    Nevertheless it's true. It's the way apulse is supposed to work.

    -- Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Pipewire and PulseAudio: apulse & firefox

[Didier Kryn]

Le 16/12/2021 à 07:08, Marc Shapiro via Dng a écrit :
>
> I don't think I'm up for compiling firefox from source.  And it would
> have to be recompiled every time mozilla releases a new version.
>
    Why do you need to track the very last version from Mozilla? The
package provided in Devuan Chimaera just works with Alsa out of the box.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Pipewire and PulseAudio: apulse & firefox

[Didier Kryn]

Le 14/12/2021 à 13:37, ael via Dng a écrit :

Firefox works fine on my systems for playing audio without pulseaudio
or apulse. So, I suggest verifying firefox works for you without
apulse first.

Interesting. I only use firefox occasionally, but some versions at least
need apulse.


    On Chimaera: Mozilla Firefox 78.15.0esr - sound workswith Alsa only.

--     Didier





___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Pipewire and PulseAudio

[Didier Kryn]

Le 13/12/2021 à 06:40, Marc Shapiro via Dng a écrit :
I was scrolling though my e-mail from the debian user group and I saw 
mention of pipewire, as a replacement for pulseaudio.  It seemed to 
suggest that it was in Testing, so would not be available on my Devuan 
Stable (chimaera) system, but I took a look, anyway.  It seems to be 
available, and, in fact, installed on my system.  It seems to have 
been brought in by zoom.


So my question are:

I have pipewire installed AND pulseaudio is still installed, as well.  
Don't they do the same thing?  Shouldn't they be conflicting with each 
other?  My sound seems to be working fine. Is is using pulseaudio?  Or 
is it using pipewire?


Is zoom using pipewire and everything else is using pulseaudio?

If pipewire is meant as a replacement for pulseaudio, can I delete 
pulseaudio.  Will my sound, including upstream firefox, continue to work?



    On Chimaera, I have neither pipewire nor pulseaudio (nor zoom) and 
sound is working fine. If zoom requires the pulseaudio API, you might 
well use apulse instead.


 -- Didier




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Avoid "unlock your keyring" prompt without desktop environment

[Didier Kryn]

Le 10/12/2021 à 16:20, Haines Brown a écrit :
> I do not run any DE. On a new installation of skypeforlinux it priodically 
> asks me to unlock my keyring. I do not use a keyring. 

    For me it id it already for some years already. I think it just
wants to force the key wallet. I just refuse.

    On the last release I even experienced crashes. Poor quality.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] system administration of non-systemd distros and releases

[Didier Kryn]

Le 26/11/2021 à 12:05, Peter Duffy a écrit :
> The trouble is that it's not just an OS for geeks - it's the OS on which
> the vast majority of the internet runs. 
>
> If the sysadmins who maintain the servers which form the infrastructure
> and backbone of the internet were to get de-skilled, that would be a
> very big problem. (Although, I should say that I personally can't for a
> moment imagine that that would happen.)
>
> On Thu, 2021-11-25 at 19:50 +0100, Didier Kryn wrote:
>
>> For myself, I prefer Linux to remain an OS for geeks rather than try
>> to catch the market of clueless users, but the last has been, for
>> decades, the quest of Gnome, and now of Freedesktop. Systemd fits well
>> in the plot.

    Sorry, it wasn't clear but I include professionals amongst geeks. I
think systemd is meant for the clueless user who is the admin of his own
computer. Or maybe there will advent a new class of clueless sysadmins...

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] system administration of non-systemd distros and releases

[Didier Kryn]

Le 25/11/2021 à 19:11, Simon a écrit :
> So in some ways it’s a step along the road of making things easier for the 
> general user, or in this case, the power user or novice admin. So yes, the 
> user does get what they are asking for - but the downside is that when it 
> breaks, it’s harder to fix.

    Independently of the commercial motivations of RH, it seems to me
(from reading about it) that Systemd is rather meant to protect the
security of the system against the admin, who is supposed an idiot, as
clueless as the mean M$ or McOs "owner". This might be understood as a
building block to make systemd-linux-gnu able to catch a share of the
market of the two above.

    Similarly, automatic flight control prevents the planes to obey the
pilots and causes crashes because they're buggy. But crashes could also
be caused by the errors of the pilots. At the end, with time, automation
will prove safer than humans. I'm sorry of this because I was a private
pilot.

    For myself, I prefer Linux to remain an OS for geeks rather than try
to catch the market of clueless users, but the last has been, for
decades, the quest of Gnome, and now of Freedesktop. Systemd fits well
in the plot.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] system administration of non-systemd distros and releases

[Didier Kryn]

Le 19/11/2021 à 12:29, Peter Duffy a écrit :
> I've recently been asked to recommend an upgrade route for a number of
> linux servers, and I proposed going to devuan. In response, I've had a
> concern raised which took me by surprise. It was suggested that in the
> future, it may not be possible to find staff who have the skills to
> administer and manage servers running non-systemd or pre-systemd
> distros/releases.
>
> I've tried to give reassurance - but I'm still wondering if this could
> be a valid concern. I'd always taken the view that it's primarily the
> linux sysadmin community which is trying to stop the onslaught of the
> systemd juggernaut - but obviously, the greater the proportion of
> servers running systemd-based distros/releases, the less staff get
> exposed to non-systemd management techniques and tools.
>
> I'd be grateful for thoughts and comments.
>
    I suggest that professional admins haven't blinkers like horses and
are supposed to be educated enough to be able to learn even a completely
new OS.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [OT] Re: Embedded devuan (was Re: Devuan with usr merge?)

[Didier Kryn]

Le 18/11/2021 à 03:07, onefang a écrit :
> Um, initramfs already uses busybox.  Or it can, it's an option in
> initramfs-tools.

    Initramfs can use what you want to provide what is bundled by Debian
in binutils and util-linux, + a shell. Busybox provides you with all
that, and much more, ready-made. Aboriginal was a distro in which all of
these applications was actually provided by busybox - I didn't look
recently.

    The initramfs typically contains a script named /sbin/init, which is
the default application launched by the kernel when it has finished
booting. If the initramfs is based on busybox, then this script is
interpreted by one of the shells provided by busybox (or it could be
busybox's init), and all the userspace applications are also provided by
busybox.

    YOU DON'T NEED AN INITRAMFS TO DO THAT. THIS INIT SEQUENCE CAN BE
DONE OUT OF A DISK PARTITION IF THE KERNEL IS ABLE TO MOUNT IT. The
advantage of such a set up is that you can modify your script from
another OS mounting this partition.

    The application to launch by the kernel is given as an argument to
the kernel when invoked by the bootloader (grub, uboot). In case of a
bootloader firmware which lacks the possibility to provide arguments to
the kernel, it is possible to define the default init when configuring
the kernel. Just to experiment with busybox, give to the kernel the
argument init="/bin/busybox ash" . After boot, you get the prompt; 
first invoke 'busybox install'; export
PATH='/bin:/sbin:/usr/bin:/usr/sbin' (depending how you have prepared
your boot partition and configured your busybox) and then 'mount -t proc
proc /proc', and experiment... By default, the kernel will invoke
/sbin/init. If you are running out of a partition and not initramfs, you
need to invoke 'busybox install' only once and this can be done in
advance by chrooting into the partition. There are many possibities ...
up to your imagination.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Embedded devuan (was Re: Devuan with usr merge?)

[Didier Kryn]

Le 17/11/2021 à 22:31, Steve Litt a écrit :
> musl is a C library revealing various OS functionalities and various
> standard ways of doing things. It and libc are replacements for each
> other. musl makes smaller and more efficient programs, from what I
> understand.

    What is called libc in general is the C runtime library, which
provides various ordinary functions and a wrapper between C applications
and the OS. Years ago, Linux kernel people developped their own libc
because unsatisfied from glibc (the Gnu version of libc) and they called
it "libc" which was confusing but this was not for use by the kernel.
This library is now abandonned.

    The kernel itself does not make use of any library at all. The libc
is meant for userspace applications written in C. It is easier to
interface C runtime to the kernel because the kernel is also written in
C. Other languages come with their own runtime library. Ada runtime
library interfaces with the libc rather than directly with the kernel,
because the most dificult is already done.

    The most popular versions of libc are glibc, musl, uClibc, dietlibc.

--     Didier

   


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Embedded devuan (was Re: Devuan with usr merge?)

[Didier Kryn]

Le 17/11/2021 à 13:03, o1bigtenor via Dng a écrit :
>
>
> On Tue, Nov 16, 2021 at 6:39 PM Steve Litt  <mailto:sl...@troubleshooters.com>> wrote:
>
> Didier Kryn said on Tue, 16 Nov 2021 14:36:23 +0100
>
>
> >    Yes, very active and with pretty constructive exchanges and
> >collaboration with Glibc. I'm on the mailing list. See
> >http://musl.libc.org <http://musl.libc.org> <http://musl.libc.org
> <http://musl.libc.org>>
>
> LOL, from what I hear, a musl compiled Linux will not work with
> systemd. 
>
>
>
> Apologies - - - - - but 'what' is "a musl compiled Linux"?
>
    The libc is an essential part of a distribution. It is not only a
pure library of facilities like string manipulation or mathematics but a
friendly interface to the OS. It provides an interface to all system
calls, plus the C standard IO, memory allocation, and other facilities.

The name Debian Gnu Linux tells that not only a big part of the
applications come from Gnu, but also the libc. All applications are
dynamically linked against glibc. A musl-compiled distro might be
called, say, Alpine Musl Linux, even if binutils and many other
applications (eg Emacs) are compiled from Gnu sources, but all are
linked against musl.

    This difference is systematic in the name of the compiler, eg
x86_64-musl-linux vs x86_64-gnu-linux.

    The incompatibility of musl and systemd is not due to an hostility
from musl author, but to a persistent attitude of systemd developpers of
bad programming. Musl is, by intention, hostile to bad programming:
everything specified as unknown behaviour (UB) by POSIX will end up
sooner or later by a crash. AFAIU systemd relies in some non-conformant
pecularities of glibc. The authors might easily correct that be won't,
which is their consistent attitude towards the rest of the world.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Embedded devuan (was Re: Devuan with usr merge?)

[Didier Kryn]

Le 16/11/2021 à 14:31, Dr. Nikolaus Klepp via Dng a écrit :
> Anno domini 2021 Tue, 16 Nov 14:19:59 +0100
>  Didier Kryn scripsit:
>> Le 16/11/2021 à 12:15, onefang a écrit :
>>> http://landley.net/aboriginal/about.html is what I used for my last
>>> embedded Linux project.
>>>
>>> "Aboriginal Linux is a shell script that builds the smallest/simplest
>>> linux system capable of rebuilding itself from source code. This
>>> currently requires seven packages: linux, busybox, uClibc, binutils, gcc,
>>> make, and bash."
>>     Aboriginal is nice and Rob Landley is doing a great job. But are you
>> sure about uClibc. I thought Aboriginal had switched to Musl years ago.
>> uClibc is pretty far from POSIX compliance, and also from Glibc, which
>> would make the system difficult to use as a build platform, although
>> otherwise functional, of course. AFAIR, Rob Landley is developping his
>> binutils mostly because of a disagreement with Busybox license.
> Is it still under devlopment? The archives end 2016.
>
    Yes, very active and with pretty constructive exchanges and
collaboration with Glibc. I'm on the mailing list. See
http://musl.libc.org <http://musl.libc.org>



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Embedded devuan (was Re: Devuan with usr merge?)

[Didier Kryn]

Le 16/11/2021 à 12:15, onefang a écrit :
> http://landley.net/aboriginal/about.html is what I used for my last
> embedded Linux project.
>
> "Aboriginal Linux is a shell script that builds the smallest/simplest
> linux system capable of rebuilding itself from source code. This
> currently requires seven packages: linux, busybox, uClibc, binutils, gcc,
> make, and bash."

    Aboriginal is nice and Rob Landley is doing a great job. But are you
sure about uClibc. I thought Aboriginal had switched to Musl years ago.
uClibc is pretty far from POSIX compliance, and also from Glibc, which
would make the system difficult to use as a build platform, although
otherwise functional, of course. AFAIR, Rob Landley is developping his
binutils mostly because of a disagreement with Busybox license.

    Here's a comparison of C libraries (by Rich felker, the author of
musl). Unfortunately it is dated from 2014. Since that time, all
librares should have made progress.
http://www.etalabs.net/compare_libcs.html


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan with usr merge?

[Didier Kryn]

Le 16/11/2021 à 01:44, Florian Zieboll via Dng a écrit :
> On Mon, 15 Nov 2021 21:19:08 +0100
> Antoine via Dng  wrote:
>> For what it's worth, I can confirm this : I ran a BeagleBoneBlack
>> build of Devuan for a while and was rather surprised one day to
>> discover that it had no kernel package installed at all. The kernel
>> and initramfs where packed into a u-boot file and once loaded, the OS
>> didn't care.
> As I use to do a minimal *.bian install on my SoC hardware, which I 
> afterwards move to the Devuan repositories, while keeping the related 
> original "firmware" repository, I must confess that the whole 
> "embedded"-thing is still somewhat unclear to me, at least regarding kernel 
> and firmware updates. I'd be more than happy to get a hint towards an honest 
> introduction to this topic.
>
    This takes some learning by experimentation. The first lesson is to
install a Devuan distro in an empty directory which will become the root
directory of the new system. Then you can use it by the mean of chroot.
The way to install the distro in this directory is debootstrap.
Debootstrap, as its name tells, is the bootstrap of the installation of
a Debian distro. When you execute chroot, you change the whole
userspace, but you still run the same kernel. From your chroot you can
continue the install wih apt-get. There are other ways to install a
distro than debootstrap, but debootstrap is usefull to learn.

    Of course, if you want to install the distro for another
architecture, you must use debootstrap --foreign and, then you cannot
switch to it with chroot. It's a little more work and you need a kernel
and understanding how the kernel passes control to userspace.

    To compile the kernel, download a source from kernel.org, look at
howtos and readme files, prepare for a build "out of tree", start from
the config of a known kernel, like the one you are currently running,
run menuconfig (eg) and compile.

    There are a lot of tricks to learn but you can only learn them by
experimentation I cannot list all of them because I used to do that many
years ago. It's time-consuming but, after that you fill more comfortable.

    Another experiment with great fun is to just install busybox in a
chroot. Build a monolithic version of Busybox statically linked against
musl libc and "install" it with symbolic links. You get a fully
functional non-GUI Linux OS; it's simply amazing. Just Busybox + kernel
can also be the starting point of an install.

    To summarize, a linux OS needs kernel + some userspace application.
To go further, the first thing the application must do is to mount /proc
and /sys. If you have a hotplugger (eudev for Debian, mdev for Busybox),
then you should also mount /dev and /dev/pts and launch the hotplugger.
This applies if the OS is standalone; in a chroot, just mount these
/proc, /sys, /dev, /dev/pts as copies of the ones of the main OS, using
mount --bind.

    I wish to every Linux fan to live this adventure.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan with usr merge?

[Didier Kryn]

Le 13/11/2021 à 20:46, Steve Litt a écrit :
> k...@aspodata.se said on Sat, 13 Nov 2021 12:42:51 +0100 (CET)
>
>> Steve Litt:
>>> John Morris via Dng said on Fri, 12 Nov 2021 17:26:52 -0600  
 On Tue, 2021-11-09 at 01:56 -0500, Steve Litt wrote:  
>> ...
 The size of the OS is just so small now, compared to storage media
 and data files.  Even a small SSD will easily hold all of /usr for
 all but the most bloated installs on old obsolete storage media.
 So simply including /usr in the root filesystem makes sense for
 almost all use cases.  
>> Size is not the only reason.
>> You might want to have a separation for other reason.
>>
>> ...
>>> Which brings up another beef I have: Why don't they build Ext4 and
>>> maybe a couple other mainstream filesystems into the kernel, so if I
>>> want, I can boot without initramfs? What would it cost?  
>> ...
>>
>> I use it all the time.
>>
>> Just do it yourself, it just cost you a little time, or do you
>> volunteer to maintain a such kernel for devuan ?
> Hi Karl,
>
> I think it's more than just a little time. Every time the kernel
> updates, you need to get the new kernel's source, recompile, and
> replace the new kernel.
>
> It *is* an interesting idea though.
>
    AFAIR you can install a Debian/Devuan system without installing a
kernel package. I did it still a decade ago on Powerpc-based SBCs: I
compiled my own kernel and built my own initramfs and it prepared the
system in a way that mimicked what Debian was expecting to find after
the pivot-root. I did it with a custom initramfs because the boards were
diskless but you can always do all this initial preparation from a
dedicated partition if you prefer. The thing is after that you must
switch to Debian proper by a pivot-root or switch-root.

    AFAIR, what the Debian init sequence (starting after pivot-root)
expects is to find /, /proc /sys, /run and /dev already mounted.

    And for what regards the kernel, you upgrade it at your own pace,
following your own needs. It is essentially decoupled from the rest of
the distro.

--     Didier

--     Didier

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan with usr merge?

[Didier Kryn]

Le 13/11/2021 à 08:48, Didier Kryn a écrit :
> Le 13/11/2021 à 00:26, John Morris via Dng a écrit :
>> So yes, it is time to eliminate /bin, /sbin and /lib.
>     Seems I've got it wrong. My understanding was that /usr/bin and
> /usr/sbin were merged into /bin and /sbin. You assume the opposite and
> probably so does Steve.
>
>     Needs clarifications.
>
> --     Didier


    I checked and I was wrong, based on the option offered years ago in
Busybox and Buildroot (/usr/bin was a symlink to /bin and /usr/sbin was
an symlink to /sbin). I'm amazed; I find this amazingly stupid. It just
makes no sense because /usr is a nonsense - /usr means "users'
directory", which is now /home) - and I was hopping to see it disapear.
On the opposite, it becomes the actual root of the OS.

    I now understand the concern of Steve: it looks like the beginning
of an attempt to force initramfs on people, even if it is not effective yet.

    There remains the option to make /usr a symlink to /, let dpkg use
it blindly and ignore it in real life.

--     Didier

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan with usr merge?

[Didier Kryn]

Le 13/11/2021 à 00:26, John Morris via Dng a écrit :
> So yes, it is time to eliminate /bin, /sbin and /lib.

    Seems I've got it wrong. My understanding was that /usr/bin and
/usr/sbin were merged into /bin and /sbin. You assume the opposite and
probably so does Steve.

    Needs clarifications.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan with usr merge?

[Didier Kryn]

Le 09/11/2021 à 07:56, Steve Litt a écrit :
> The logic is still the same. I need a guaranteed place on the root
> partition to find the programs necessary to mount all the other
> partitions, or else I'll need to run an initramfs.

    You just need that the root partition be large enough to contain all
of /bin, /sbin, /lib, with includes all applications which were in
/usr/bin and /usr/sbin before the merge. This is below 400MB in a basic
Devuan desktop.

    However many of the applications moved from /usr/bin to /bin are
dynamically linked with shared libraries in /usr/lib. Is that part of
the merge? That would be the biggest part. 2.8G on by Chimaera laptop.

    That said, I agree that there is some confusion in mixing all
applications in the same directory, but, in my mind, it is mostly the
question of a sensible organization.

--    Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] pkexec in Chimaera

[Didier Kryn]

Le 08/11/2021 à 14:16, Didier Kryn a écrit :
>     There is a hand-made replacement for pkexec and the good old gksu
> and gksudo:
>
> In your sudoers file (edited with visudo), put the following line
>
> Defaults env_keep = "XAUTHORITY DISPLAY"
>
> Note there can be other variables in the list, like EDITOR, but the
> above are the ones which will allow you to run GUIs under root priviledge.
>
> Then allow yourself to run foo with sudo (also by editing your sudoers
> file vith visudo) and then
>
> sudo foo
>
> hth
>
> --     Didier
>

    Alternative:

su -w DISPLAY,XAUTHORITY -c /usr/sbin/foo

Doesn't work with option -l of su; therefore the PATH is yours.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] pkexec in Chimaera

[Didier Kryn]

    There is a hand-made replacement for pkexec and the good old gksu
and gksudo:

In your sudoers file (edited with visudo), put the following line

Defaults env_keep = "XAUTHORITY DISPLAY"

Note there can be other variables in the list, like EDITOR, but the
above are the ones which will allow you to run GUIs under root priviledge.

Then allow yourself to run foo with sudo (also by editing your sudoers
file vith visudo) and then

sudo foo

hth

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan with usr merge?

[Didier Kryn]

Le 08/11/2021 à 13:50, Didier Kryn a écrit :
> Le 06/11/2021 à 03:03, Steve Litt a écrit :
>> Personally, I want a directory, guaranteed not to be a mount point,
>> where the statically compiled binaries necessary to bring up the
>> system, things like mount and ln and vi and fsck, etc, so if I don't
>> want to, I don't have to run an initramfs.
>     Hi Steve. It seems you always understand the s of sbin as meaning
> "static". it isn't. Look at Devuan binaries in /sbin and /usr/sbin; they
> are dynamically linked. s stands for "system".
>
>  # file /bin/mount
> /bin/mount: setuid ELF 64-bit LSB pie executable, x86-64, version 1
> (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
> BuildID[sha1]=82eb1fdddc0083f599c4072f4e1a39e28de6c759, for GNU/Linux
> 3.2.0, stripped
>
> What is called "interpreter" here is the dynamic linker associated to
> the shared version of gcc, the Gnu C library. There is practically no
> statically linked application in a Debian distribution, except some part
> of debootstrap.
>
> --     Didier
>
>
    Sorry, not gcc, glibc.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan with usr merge?

[Didier Kryn]

Le 06/11/2021 à 03:03, Steve Litt a écrit :
> Personally, I want a directory, guaranteed not to be a mount point,
> where the statically compiled binaries necessary to bring up the
> system, things like mount and ln and vi and fsck, etc, so if I don't
> want to, I don't have to run an initramfs.

    Hi Steve. It seems you always understand the s of sbin as meaning
"static". it isn't. Look at Devuan binaries in /sbin and /usr/sbin; they
are dynamically linked. s stands for "system".

 # file /bin/mount
/bin/mount: setuid ELF 64-bit LSB pie executable, x86-64, version 1
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=82eb1fdddc0083f599c4072f4e1a39e28de6c759, for GNU/Linux
3.2.0, stripped

What is called "interpreter" here is the dynamic linker associated to
the shared version of gcc, the Gnu C library. There is practically no
statically linked application in a Debian distribution, except some part
of debootstrap.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!

[Didier Kryn]

Le 24/10/2021 à 01:22, Steve Litt a écrit :
> At this point I can't be sure because I run a rolling release, but I
> think ~/Music, Documents and ~/Videos were put there by the distro ---

These are freedesktop crap. You can remove them by editing
$HOME/.config/user-dirs.dirs .

Some applications refer to these definitions as a default place to store
files.

Just define those you don't want as the same as an already existing one,
such as $HOME.

I don't know what the purpose of user-dirs.locale is.

It's unfortunate one needs to surf the web to discover this and there is
no tool in the application menu to configure it.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!

[Didier Kryn]

Le 17/10/2021 à 20:44, Steve Litt a écrit :
> Hendrik Boom said on Sun, 17 Oct 2021 11:55:56 -0400
>
>> On Sun, Oct 17, 2021 at 07:56:47AM -0400, . via Dng wrote:
>>> On 10/17/21 07:48, terryc wrote:
> [snip]
>
>>> Well, it can't hurt to try another update/upgrade cycle; I had a
>>> konsole open during the last reboot and it was restored, so I can do
>>> command-line things (and what else could I possibly need:-) If that
>>> doesn't fix things up then it's nuke-and-repave time.
>> I've learned it's useful to repeat upgrades and dist-upgrandes and an
>> occasinoal aptitude until nothing happens AND there are no errors
>> reported.

    Thanks. I discovered there remains a lot to upgrade/install after
the reboot!

    I use to also insert 'apt-get autoremove --purge' in between.

> When dealing with non-rolling releases, and maybe even rolling releases
> in certain circumstances, I'm a fan of nuke-and-repave for major
> versions. This is because I'm an elder in the Church of the Known State,
> and a brand new install is an opportunity to achieve a known state. This
> tends to limit the ghosts of versions past.

    I agree with you. Sometimes it's good to restart fromscratch. It's
also an opportunity to make hardware changes.

    Two systems upgraded to Chimaera these days. All looks fine. Thanks
to the great team.

--     Didier





___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Gnome and KDE: Was: a how to question (project(s) related)

[Didier Kryn]

Le 18/08/2021 à 12:22, al3xu5 a écrit :
> Tue, 17 Aug 2021 17:46:01 -0400 - Steve Litt :
>
>> Antony Stone said on Tue, 17 Aug 2021 21:38:05 +0200
>>
>>  
>>> "I think both KDE and Gnome suck - I'm quite unbiased in that, because
>>> I use a Mac."
>>> - Jason Isitt  
>> I think both KDE and Gnome suck - I'm quite unbiased in that, because I
>> use OpenBox on Linux.
>
> I think both KDE and Gnome, and also all the Mac stuff, suck -- I'm
> quite unbiased in that, because I use OpenBox (+LXDE) on Linux.
>
    I've used Gnome and KDE many years ago, before they started to suck.
I had recently the opportunity to use Mac and Windows and they both
suck. Here is an example:

    I have a USB memory key on which are several directories with
photos, personal videos (from my Gopro Hero-2) plus some movies. Amongst
the directories, there is one named DCIM because I have used it in the
camera. Fatal error!

    When I plug the USB key on my laptop, I can open it with hopman and
look at any of the contents with thunar or xfce4-ternimal.

    When I plug it on a TV receiver, I can navigate the directory
structure, by first choosing if I want to see photos or videos.

    When I plug it on a Mac, it looks for a (photo or video) application
to open it, doesn't find one and never tries to just show it in a file
manager.

    When I plugged it into the Windows machine of a friend 1 month ago,
we tried half an hour to open it in the file manager (or however they
call that on Windows), without success. We gave up. After that I
discovered that Windows had created a lot of junk files on the USB key.

    I consider Mac sucks as much as Windows; I dislike Mac's desktop,
maybe by lack of habit, and I hate the way they prevent the user to make
simple things. For example it is impossible to open an SVG file by
clicking on it. You must first launch the web browser! Mac was once (in
1981) the inventor of the idea of associating a file type to an
application. Very well, but with any Linux file manager you can open a
file not only with a default application but with any one of your
choice. And there is a default application out of the box for SVG files.

    When I see the life of a friend of me with her Macs, I just see her
as a prisonner. She keeps an old desktop Mac, because she has on it an
old version of Photoshop which is enough for her. She does nothing else
with this machine. She has a newer one with which she does other things.
She never uses them to browse the web or send mails but relies for that
on her Android smartphone which continuously harasses her with
commercial "allerts". I do all that (except the "allerts") with my
single laptop running Devuan and Xfce4.

    I dunno when a Mac becomes old (meaning not maintained by Apple). 3,
4 years? After that any hardware or software becomes incompatible. It
may be fine to have a Mac when it is renewed by your employer every 3
years. Nice because it is beautiful and shining, and, most of all,
expensive. But, even when it is new, it *sucks*.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 30/07/2021 à 15:24, Enrico Weigelt, metux IT consult a écrit :
> On 21.07.21 14:36, Didier Kryn wrote:
>
>>  I want to add to the comments that this alloca() function has been
>> added (by gcc ?) to work around a missing feature of the C language:
>> dynamic allocation on the stack. 
>
> What you *actually* want is not "on stack" (directly), but automatically
> freed when leaving the function scope - doing it by moving SP is just an
> specific implementation. But actually a problematic one that needs great
> caution: you usually don't know how much free stack you actually have.


    The principle of stack allocation, when possible is a very efficient
use of the memory and cpu: it is fast and requires no calculation. This
stack is not necessarily "the stack of automatic variables"; any array
can be managed as a stack by a custom allocator. This one, as you say is
convenient because automatically reclaimed on return.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [OT] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 29/07/2021 à 20:10, Andreas Messer a écrit :
> On Wed, Jul 28, 2021 at 03:58:02PM +0200, Didier Kryn wrote:
>>     With all respect due to your work, I tend to think that with such
>> expensive and dangerous machines, more investment should be put into
>> hardware so as to get controllers with a decent ram. And maybe the
>> firmware could take safety action when software crashes.
> Sure, but I'm not the boss :-)
    Your boss is the ultimate responsible person in case of human
hazard, at the condition s?he is properly educated, and it might be your
responsibility to educate her/him.
>
>>     Similarly, more investment should be put in software so as to make a
>> review of available languages suited for mssion-critical applications
>> and invest in learning the chosen language. C and C++ are so error-prone
>> that they are really not suited.
> Well, you can implement bugs in any kind of language. To be honest,
> crashes are the most easy ones to find. I know there are other languages
> outside but here applies the same as above: I'm not the one to decide.
    Not all language are equal. Some really discourage bad programming,
meaning it takes a big effort to actually program badly/unsafely, while
it is still possible. Others open traps under your feet everywhere.
>
> I can just give hints and try to push in some direction. But embedded
> software development is still driven by myths like "C is faster than C++"
> and its hard overcome these. Maybe a generation thing.
    Myths actually. The advantage of C and C++ is to be easily portable
to every paltform since the compiler and runtime are always available by
default. But, when you develop a private application, you can invest in
building the necessary environment.
>
> My personal way to push through this is to run as much (automated)
> firmware tests in our hardware-in-the-loop test system as possible. And to
> have a testcase for every single requirement, situation, sequence or ever
> seen bug in the software. We end up to have 20-30 testruns a day
> distributed among different test setups, SoC cpu generations, operating
> systems. The only missing thing is kind of developer slap robot to punish
> the developer who made the bad commit automatically :-)
>
    Not sure that works (~:  Would make the programmers nervous.
Stress-based human management causes bad surprises.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [OT] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 25/07/2021 à 11:45, Andreas Messer a écrit :
> Why I'm so critical about letting it crash: I typically deal with stack
> sizes of no more around 2-8kB in automation devices and have to be careful
> with that. You can't simply let a newspaper printing machine's motor control
> crash, 1000's of newspaper pages would be trashed. Once we had a crash in
> simple limit switch device. As a result the high-rack robot pushed a
> pallet in 15m height out of the rack. Fortunately, it was just another
> robot which was destroyed (stood just below) - not a human being. Still 
> a very expensive case for the company. So I'm used implement a lot of 
> checks :-). (Actually we even don't use heap allocation after booting 
> the firmware)

    Note that not only a crash might cause this effect. C (and libc) is
a language where "undefined behaviour" may happen at the corner of every
streets, as mentionned everywhere in the mans.

    With all respect due to your work, I tend to think that with such
expensive and dangerous machines, more investment should be put into
hardware so as to get controllers with a decent ram. And maybe the
firmware could take safety action when software crashes.

    Similarly, more investment should be put in software so as to make a
review of available languages suited for mssion-critical applications
and invest in learning the chosen language. C and C++ are so error-prone
that they are really not suited.

    This went far off topic. I have more on the initial topic but am
getting tired (~:

    -- Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 22/07/2021 à 20:53, Andreas Messer a écrit :
> Hi,
>
> On Thu, Jul 22, 2021 at 07:53:58AM +0200, Didier Kryn wrote:
>>     There's a choice of options in GCC to deal with stack protection.
>> Eg:  -fstack-check
>>
>>     Plus a bunch of macros.
>>
>>     They all deal with allocation of automatic variables. For alloca(),
>> instead, there's explicitely no check.
> I don't find any reference about automatic variables in the docs regarding
> this topic.
    AFAIK, in the C language, stack == automatic variables.
>  Actually, the description of gcc's alloca() builtin states that 
> it behaves similar to automatic variables.

    This only means that it takes space from the stack. I've read also
that using it together with automatic variables of dynamic size, or,
even, embedded control blocks, is UB. Which means the compiler and
runtime are not properly informed. That said, it is possible that
compiler authors have made progress on this matter without updating the
documentation.

>  However, all these macros will 
> not prevent you from stack overflow but only help you to detect one when it 
> already happened. Also, the way gcc implements the check (probing SP) works 
> for alloca and for automatic variables in the same way. 
>
> However, once you have detected a stack overflow, your application is 
> in an inconsistent state. Of course you can implement some kind of rescue.
> (e.g using libsigsev) But you have to do a clean rewind of your app
> state back to state before the overflow occurred. This can become quite
> complex and hard to maintain. And then your're back to state before stack
> overflow, but what is the application supposed to do then? Log and ignore
> the request? Terminate? Ask the User? 
>
> The point is, an application should be designed such that a stack overflow
> just can not occur. And this implies length checking, regardless if using
> automatic vars or alloca.
    There is always something safer than UB: crash.
>
>>     In addition, the compiler is not informed of the invocation of
>> alloca(); therefore the space allocated to non-static automatic
>> variables may overlap with the space "allocated" by alloca().
> No. This is wrong alloca() is implemented as compiler builtin and
> does exactly the same as GCC does when allocating automatic vars on the
> stack.
>
> Prove: https://godbolt.org/z/abqK4T43c

> The generated machine code is identical including the stack overflow
> checking code.

    Generated code is normally not a proof. In the job of a compiler,
generating code is not necessarily the biggest part. Compile-time
controls and the generation of runtime checking code, when necessary,
are also essential. Here you tell the runtime verifications are the same
and I believe you - I don't know arm assembler; I used to read/write
assembler for PDP15 and IBM370 but it was  30-40 years ago (~:

    However the manual of alloca() states that "There is no error
indication if the stack  frame  cannot  be  extended." If the same would
happen with automatic variables, I would expect a crash; otherwise it
would be a serious flaw in the compiler. According to you there is such
a flaw?

    Cheers.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 21/07/2021 à 21:08, Andreas Messer a écrit :
> On Wed, Jul 21, 2021 at 02:36:16PM +0200, Didier Kryn wrote:
>> added (by gcc ?) to work around a missing feature of the C language:
>> dynamic allocation on the stack. This lack has disapeared many years ago
>> ( don't know with which version of the C standard) , with the following
>> form of allocation:
>>
>> ...
>>
>> n = 2x+1;
>>
>> {
>>
>>     int array[n];
>>
>>     ...
>>
>> }
>>
>>     And, therefore, alloca() should be removed.
> Well, alloca(n*sizeof(int)) and your suggestion both do the same in that 
> they allocate memory from stack without any checking. Thus both will 
> show the same failure mode of possible stack overflow.

    There's a choice of options in GCC to deal with stack protection.
Eg:  -fstack-check

    Plus a bunch of macros.

    They all deal with allocation of automatic variables. For alloca(),
instead, there's explicitely no check.

    In addition, the compiler is not informed of the invocation of
alloca(); therefore the space allocated to non-static automatic
variables may overlap with the space "allocated" by alloca().

>
> In any case, the implementation should put some limit on n before
> executing alloca() or int array[n].
>
> To be honest, I really don't seesomething against using alloca() despite
> its not Posix. Especially, there is no advantage of array[n] 
> regarding the stack overflow issue.
    See above.
>
> Of course, critical software should not rely on dynamic stack allocation
> since its unpredictable. (but also not on runtime heap allocation too)
    malloc() returns NULL il case of error. Errors should always be checked.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 21/07/2021 à 18:19, Tomasz Torcz a écrit :
> On Wed, Jul 21, 2021 at 06:00:15PM +0200, Didier Kryn wrote:
>> Le 21/07/2021 à 16:51, Bernard Rosset via Dng a écrit :
>>>> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
>>> I'll be projecting myself here, but I reckon sharing the original
>>> source rather than journalistic articles whenever possible is best
>>> towards a tech-savvy audience.
>>>
>>> The source (included in above article) is here:
>>> https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/cve-2021-33910-denial-of-service-stack-exhaustion-in-systemd-pid-1
>>     The code shows the use of strdupa(). There is a family of functions
>> which are extensions of POSIX functions, with the suffix 'a' which
>> allocate space for the returned string from the stack. They are very
>> convenient for lazy programmer, but (slightly ?) dangerous and do not
>> belong to POSIX.
>>
>>     I've found a discussion between a developper and Lennart Poeterring
>> in which LP recommends the addition of this kind of functions in Musl
>> libc (which will certainly never happen). 
> That's amusing thought. strdupa() is in Musl:
> http://git.musl-libc.org/cgit/musl/tree/include/string.h#n89
> alloca() is there, too:
> http://git.musl-libc.org/cgit/musl/tree/include/alloca.h
>
    At least strdupa() is just a macro conditionned by #ifedf _GNU_SOURCE.

    Similarly alloca() is #defined as the compiler's built in alloca().

    This is a way to provide the minimal service to people wanting to
link with Musl programs developped for Glibc. I guess the pressure was
too high.

--     Didier





___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 21/07/2021 à 16:51, Bernard Rosset via Dng a écrit :
>> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
>
> I'll be projecting myself here, but I reckon sharing the original
> source rather than journalistic articles whenever possible is best
> towards a tech-savvy audience.
>
> The source (included in above article) is here:
> https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/cve-2021-33910-denial-of-service-stack-exhaustion-in-systemd-pid-1

    The code shows the use of strdupa(). There is a family of functions
which are extensions of POSIX functions, with the suffix 'a' which
allocate space for the returned string from the stack. They are very
convenient for lazy programmer, but (slightly ?) dangerous and do not
belong to POSIX.

    I've found a discussion between a developper and Lennart Poeterring
in which LP recommends the addition of this kind of functions in Musl
libc (which will certainly never happen). It's slightly amusing how the
author of such a critical software as systemd lacks a culture of security.

https://github.com/systemd/casync/issues/129


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 21/07/2021 à 15:47, William Gallafent via Dng a écrit :
> According to a man page I happen to have in front of me, “alloca()
> appeared in Version 32V AT UNIX.”
>
> I've certainly seen it in use on code originally written during the
> last millennium for SGI IRIX, and then ported to several other
> systems, many years ago.
>
> It was C99 that introduced variable-length arrays, which is, as you
> say, also many years ago :)
>
> According to the same man page:
>
> ==B<==
> BUGS
>  alloca() is machine and compiler dependent; its use is discouraged.
>
>  alloca() is slightly unsafe because it cannot ensure that the
> pointer returned points to a valid and usable block of memory.  The
>  allocation made may exceed the bounds of the stack, or even go
> further into other objects in memory, and alloca() cannot determine
>  such an error.  Avoid alloca() with large unbounded allocations.
>
>  The use of C99 variable-length arrays and alloca() in the same
> function will cause the lifetime of alloca's storage to be limited
>  to the block containing the alloca()
> ==B<==
>
> Here endeth the lesson, certainly. I like the use of “slightly” in
> front of the word “unsafe”. Humorous.

    Slightly humorous (~:

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Nasty Linux systemd security bug revealed

[Didier Kryn]

Le 20/07/2021 à 22:08, Dr. Nikolaus Klepp a écrit :
> Just in case sombody missed it:
>
> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
>
>
> "Systemd, the Linux system and service manager that has largely
> replaced init as the master Linux startup and control program, has
> always had its critics. Now, with Qualys's discovery of a new systemd
> security bug, systemd will have fewer friends. Successful exploitation
> of this newest vulnerability enables any unprivileged user to cause a
> denial of service via a kernel panic.
> In a phrase, "that's bad, that's really bad." [...]
> "
>
> Nik
>
    I want to add to the comments that this alloca() function has been
added (by gcc ?) to work around a missing feature of the C language:
dynamic allocation on the stack. This lack has disapeared many years ago
( don't know with which version of the C standard) , with the following
form of allocation:

...

n = 2x+1;

{

    int array[n];

    ...

}

    And, therefore, alloca() should be removed.

    delenda est alloca !

--     Didier




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..how to installing it from a git repository "the good old Debian way", was: Hopman and inotify

[Didier Kryn]

Le 30/06/2021 à 12:15, Arnt Karlsen a écrit :
> On Tue, 29 Jun 2021 16:42:47 +0200, Didier wrote in message 
> :
>
>> Le 13/06/2021 à 23:29, Haines Brown a écrit :
>>> I tried hopman some years ago and loved it, But when installed on a 
>>> new machine failed copy the code. Would anyone indulge me by
>>> pointing to a link to the current stete of the application?
>>>  
>>     "Legacy" hopman is back on gitlab, at
>> https://git.devuan.org/kryn/hopman
>> . The executable is now
>> named /usr/bin/hopman-GTK2, and a symbolic link to it is created in
>> the same directory with the name hopman.
>>
>>     To build and install it, first retrieve it from
>> https://git.devuan.org/kryn/hopman
>>  ; Make sure you have the GTK+-2
>> library installed, eg libgtk-2.0 and libgtk-2.0-dev;
>>     then go to the subdirectory hopman-1.1;
> ..to do it "the good old Debian way", what are the missing stages 
> that would prevent a "make deb && dpkg -i hopman" from working?
>
    I tried a few times, years ago, to folow this and others ready-made
recipes to "debianize" a package. It never worked and I never understood
why. Debian-know-it-all experts are welcome.

    --     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Hopman and inotify

[Didier Kryn]

Le 13/06/2021 à 23:29, Haines Brown a écrit :
> I tried hopman some years ago and loved it, But when installed on a 
> new machine failed copy the code. Would anyone indulge me by pointing 
> to a link to the current stete of the application?
>
    "Legacy" hopman is back on gitlab, at
https://git.devuan.org/kryn/hopman .
The executable is now named /usr/bin/hopman-GTK2, and a symbolic link to
it is created in the same directory with the name hopman.

    To build and install it, first retrieve it from
https://git.devuan.org/kryn/hopman  ;
    Make sure you have the GTK+-2 library installed, eg libgtk-2.0 and
libgtk-2.0-dev;
    then go to the subdirectory hopman-1.1;
    make && sudo make install && make cleanall

    Declare hopman as autostarted application of your desktop session.
Alternatively run it from the application menu (submenu: system).

    In the default configuration, hopman uses the following applications
to perform the requested actions: pmount, pumount, thunar,
xfce4-terminal. This is all customizable: read man hopmanrc.

    To uninstall, 'sudo make uninstall'

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[Didier Kryn]

Le 23/06/2021 à 14:38, Dr. Nikolaus Klepp a écrit :
> Anno domini 2021 Wed, 23 Jun 13:34:39 +0200
>  Didier Kryn scripsit:
>> Le 23/06/2021 à 12:49, Dr. Nikolaus Klepp a écrit :
>>> Anno domini 2021 Wed, 23 Jun 12:16:50 +0200
>>>  Didier Kryn scripsit:
>>>> [...]
>>>>     There is no other way to know which partitions are mounted or not
>>>> than read /proc/self/mounts. inotify does not work on pseudo-filesystems
>>>> like /sys or /proc. Therefore, either this is done by the front-end or
>>>> by the back-end.
>>> Oh, inotifywatch perfectly works on /sys and /dev when you are root, in 
>>> fact that's what I use as part of my automounter when I run fvwm:
>>     Of course it works on /dev; tmpfs and devtmpfs behave like real
>> filesystems. This is what Hopman is based on (~:
>>
>>     Hopman isn't root, doesn't need to be, and shouldn't be. And inotify
>> doesn't work on /proc (at least for non-root).
> Well, inotifywait does work  on /dev /sys and /proc for non-root, too. At 
> least it does here on chimaera. Just try these:
>
> $ inotifywait -rm /proc/
> $ inotifywait -rm /sys/devices/pci*
>
> What does not work is /sys/block, but that's a cosmetic problem, as you alway 
> can watch for /sys and fiilter the output.
    I don't need to poll or watch /sys. I browse it when inotify tells
me something about /dev, to see if it is a partition and if it is removable.
>
> How does hopman differ from e.g. "inotifywait -rm /dev/disk" or "inotifywait 
> -rm /dev/block" + some lines of shell magic to get a nice output? 
    Because It does it all in just one single process and also browses
/sys to filter events as explained above and all the rest of the work:
display the status, collect mouse-clicks, launch helpers, wait() them,
display their error messages, all asynchrohously. It is easy to make a
toy script to play with it but really unpractical to do a complete job.
> If polling /proc/self/mounts is required, where is the point in not polling 
> /sys/block/sd*/removable, too?

    1st because polling one file only is less load for the system; 2nd
because when there are no removable device in the system, then there is
no need to poll it, and this is most of the time. As long as there is no
removable device, Hopman is sleeping 100% the time, except briefly when
a file is created/deleted in /dev.

    Reading /proc/self/mounts is triggered by an alarm which is enabled
only when there is a removable device in the system.

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[Didier Kryn]

Le 23/06/2021 à 12:49, Dr. Nikolaus Klepp a écrit :
> Anno domini 2021 Wed, 23 Jun 12:16:50 +0200
>  Didier Kryn scripsit:
>> [...]
>>     There is no other way to know which partitions are mounted or not
>> than read /proc/self/mounts. inotify does not work on pseudo-filesystems
>> like /sys or /proc. Therefore, either this is done by the front-end or
>> by the back-end.
> Oh, inotifywatch perfectly works on /sys and /dev when you are root, in fact 
> that's what I use as part of my automounter when I run fvwm:

    Of course it works on /dev; tmpfs and devtmpfs behave like real
filesystems. This is what Hopman is based on (~:

    Hopman isn't root, doesn't need to be, and shouldn't be. And inotify
doesn't work on /proc (at least for non-root).

--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[Didier Kryn]

Le 23/06/2021 à 11:50, Dr. Nikolaus Klepp a écrit :
> Hi!
>
> Anno domini 2021 Wed, 23 Jun 00:00:11 +0200
>  Didier Kryn scripsit:
>> Le 22/06/2021 à 19:10, Steve Litt a écrit :
>> [...]
>>     Hopman-cli would write to the pipe 3 sorts of messages, with all the
>> necessary details:
>>
>> - a device special file associated to a removable partition has been
>> detected in /dev
>> - a symlink has been detected in /dev/disk/by-label, pointing to a
>> removable partition
>> - a device special file associated to a removable partition has been
>> removed
> IMO this sounds good. I would just make it react on all partitions, not only 
> the removable: there are broken devices out in the wild that lie about their 
> removability. And there are devices that have wrong entries in the hw 
> database (e.g. old Casio cameras).

    No, Hopman should not show /home, /var, etc... Currently it relies
on /sys to tell which device is removable. Removable partitions might
also be declared in the config file as regular expressions.

>
> Oh, hopman would only send data, not receive from the client side, would it?
>
>> [...]
>>     Then it's up to the GUI application to
>>
>> - parse these messages, maintain and display a list of removable
>> partitions and their labels,
>> - on click, spawn helpers to mount/umount/open partitions and
>> potentially eject disks, check completion and report errors,
>> - periodically read /proc/self/mounts and report mountpoints of
>> removable partitions on the display.
> Why parse /proc/self/mounts? IMO it would make more sense if hopman-cli sends 
> " mounted on yyy" or "xxx unlounted" over the pipe, as it is already 
> monitoring stuff.

    There is no other way to know which partitions are mounted or not
than read /proc/self/mounts. inotify does not work on pseudo-filesystems
like /sys or /proc. Therefore, either this is done by the front-end or
by the back-end.


>
>>     Both Hopman-cli and the GUI must read hopmanrc at startup (it seems
>> simpler to have a single file to configure both). Possibly the name of
>> the GUI application might be specified in hopmanrc and Hopman-cli would
>> launch it.
> What's configurable in hopmanrc? Shouldn't it "just work" for all 
> partitions/devices? The GUI part most likely will need some config, e.g 
> automounting certain devices/partitions etc.

    hopmanrc provides a lot of possiblities to parameterise the
application, such as window appearance, behaviour and position, location
of pid-file and helper applications to mount/umount/open/eject
partitions/devices.

--     Didier




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[Didier Kryn]

Le 22/06/2021 à 19:10, Steve Litt a écrit :
> Didier Kryn said on Tue, 22 Jun 2021 18:00:17 +0200
>
>> Le 22/06/2021 à 14:20, Steve Litt a écrit :
>>> How bout making a CLI Hopman with an API somebody can interact with
>>> in gtk, or CLI, or PHP, or Tcl/Tk, or Python/Tk, or pretty much
>>> anything else?  
>>     I have thought of this initially before doing it with Gtk2. But it
>> means a dual-process application (Hopman + a GUI written in Tk, PHP
>> ...). In a mode of operation like inotifywait, a formatted message
>> would be emitted by Hopman to standard outputeverytime the status
>> changes. I probably rejected this solution because it implied to
>> develop the two programs, which at least is twice more work.
>>
>>     If there are volonteers to develop the GUIs, I can think of this
>> CLI version.
> I'll volunteer to make a Python3/Tk version. I'll need specifications
> from you, either written or formulated via a set of emails between us,
> offlist.

    Let's continue on list for generalities since it might trigger
reactions. This is my suggestion:

    Hopman-cli would write to the pipe 3 sorts of messages, with all the
necessary details:

- a device special file associated to a removable partition has been
detected in /dev
- a symlink has been detected in /dev/disk/by-label, pointing to a
removable partition
- a device special file associated to a removable partition has been
removed

    At startup Hopman-cli looks for removable partitions already
present; then it relies on inotify; but the messages would be the same
for initial discovery and for online creation.

    Then it's up to the GUI application to

- parse these messages, maintain and display a list of removable
partitions and their labels,
- on click, spawn helpers to mount/umount/open partitions and
potentially eject disks, check completion and report errors,
- periodically read /proc/self/mounts and report mountpoints of
removable partitions on the display.

    Both Hopman-cli and the GUI must read hopmanrc at startup (it seems
simpler to have a single file to configure both). Possibly the name of
the GUI application might be specified in hopmanrc and Hopman-cli would
launch it.

    Both applications must die immediately when the pipe is broken.

    I don't think the GUI is a piece of cake, but you seem to have some
experience (~: Note that this a reactive program: it must react on input
data available, mouse-click, and child-termination, while periodically
reading /proc/self/mounts. I think the most difficult is to check the
result of helpers and forward their messages to the user.

    If this seems too difficult, Hopman-cli could take care of mount
helpers, but this would require a bidirectional communication, making it
impossible to launch both applications from the command-line (Hopman-cli
should be in charge of launching the GUI).

    Maybe this is similar to what Aitor does with his dual-threaded version.

    Cheers.

--     Didier




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[Didier Kryn]

Le 22/06/2021 à 14:20, Steve Litt a écrit :
> aitor said on Tue, 22 Jun 2021 08:24:04 +0200
>
>> Hi Steve,
>>
>> On 20/6/21 23:09, Steve Litt wrote:
>>> Huh? The preceding link appears to be a whole distro. How can I
>>> download, compile and install*hopman*  on my existing Void Linux
>>> computer?  
>> The unique existent development files of gtk in Void Linux seem to be 
>> 3.24 or higher:
>>
>> http://54.37.137.89/pkgs.void/package/gtkmm 
>> 
> I should have made this suggestion a year ago, and it might be too late
> now, but I'll make it just in case...
>
> How bout making a CLI Hopman with an API somebody can interact with in
> gtk, or CLI, or PHP, or Tcl/Tk, or Python/Tk, or pretty much anything
> else?

    I have thought of this initially before doing it with Gtk2. But it
means a dual-process application (Hopman + a GUI written in Tk, PHP
...). In a mode of operation like inotifywait, a formatted message would
be emitted by Hopman to standard outputeverytime the status changes. I
probably rejected this solution because it implied to develop the two
programs, which at least is twice more work.

    If there are volonteers to develop the GUIs, I can think of this CLI
version.

>
> The API could include the list of all access points, sortable by alpha
> or by strength. There could be a function that takes access point,
> encryption type, passphrase or long pass string,
    What? Hopman only watches device special files associated to
partitions, full stop.
>  this function being
> fed by whatever GUI input screen wanted. Most of all, you could include
> a document of the definition of what a GUI Hopman looks like and what
> it doesn't, so all the implementations are roughly the same except for
> appearance. I could write that document for you.
>
> My local LUG, GoLUG, once featured a genius named Gary Miller, who is
> now programming for the angels. He taught me the concept of the Gary
> Miller program architecture. What Gary did is write a program with a
> text interface: Perhaps not even a very understandable text interface.
> He put this interface at a given port number. He then published how
> you'd need to interact with that port in order to properly manipulate
> his program to produce the intended results.

    No need for a port, a simple anonymous pipe is fine.

    Cheers.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Hopman and inotify

[Didier Kryn]

Le 13/06/2021 à 23:29, Haines Brown a écrit :
> I tried hopman some years ago and loved it, But when installed on a 
> new machine failed copy the code. Would anyone indulge me by pointing 
> to a link to the current stete of the application?
>
    I've not followed the change in git repository of Devuan. In the
mean time i tried to put into the same source tree all the files
necessary for internationalization and didn't find a satisfactory way to
do it.

    I have some work to do to clean up the tree from
internationalization files and correct a little bug. Then I should push
the tree to the new git repository. Then I will let you know. I have
been lazy during the two last years. Motivation is back but I'm
currently travelling.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Hopman and inotify

[Didier Kryn]

Le 13/06/2021 à 09:16, tito via Dng a écrit :
> On Sat, 12 Jun 2021 15:35:56 -0400
> Steve Litt  wrote:
>
>> Hi all,
>>
>> I think inotify is the best foundation for a usb plugin/plugout
>> detector. I used it in my early 2015 proof of concept proving that
>> Poettering's socket activation was overkill and could be accomplished
>> much less intrusively with inotify.
>>
>> As far as I know, Hopman's only usage is to mount thumb drives and USB
>> connected SATA drives. 
> Hi,
> don't forget smartphones there are billions far more than thumb drives
> and  USB SATA drives.

    Yep, hopman's gui provides buttons to mount/umount/open everything
which can be handled through the disk paradigm. But what to do with
things which cannot? What are the tools (helpers in hopman's parlance)
to handle those?

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] USB mount problem

[Didier Kryn]

Le 12/06/2021 à 20:59, aitor a écrit :
>
> Hi Didier,
>
> On 12/6/21 19:42, Didier Kryn wrote:
>>     Hello.
>>
>>     My aproach with Hopman was to be totally independant of the
>> hotplugger (udev/eudev/vdev/mdev, even systemd) provided it does the
>> job, which is to create the device special file in /dev (which the
>> kernel can do on its own). Then, if the hotplugger is capable to create
>> a symlink in /dev/disk/by-label, then Hopman uses it to display the disk
>> label and eventually passes it to the mount helper. 
> And this is the problem i was having with vdev. The capability to
> create symlinks in /dev/disk in the right way (maybe my fault),
> and this is the reason whyi was using blkid to get the disk label.
>> Hopman is a single-threaded program;
> I'm used to using a worker thread to make it update the gui without
> crashing. Although, I've been using your single-threaded version
> for a long time and it works fine, doing the job.
>>  its only dependencies are the presence of a
>> kernel with the inotify and signalfd APIs, which is the case since more
>> than a decade, unless disabled during kernel build, which would be evil.
>
> "Moreover, the approach of libudev-compat is generic enough to not
> specific to a particular kernel or device manager" -Jude Nelson.
>
> Btw, i'm splitting the content of the vdev project in vdevd and the
> helpers on the one hand, and libudev-compat on the other,increasing
> the version of libudev-compat in the same rate as libeudev for the
> sake of a less painful packaging maintainence:
>
> https://gitea.devuan.dev/aitor_czr/libudev-compat
> <https://gitea.devuan.dev/aitor_czr/libudev-compat>
>
> What do you think about this?
>
> @Didier: if you are interested in how libudev-compat works, give
> special attention to libudev-monitor.c and libudev-fs.c
>
    Hi AItor.

    I was never able to understand the ABI of libudev, due to the
absence of a manual. I have a great admiration for Jude and you to have
understood it. I will have a look at libudev-monitor.c . Nevertheless,
and whatever the method used (netlink for libudev or files for
libudev-compat), it relies on the hotplugger to populate its database. I
don't think this makes a big difference, except that udev make things
more confuse by using the same netlink as the kernel to talk to libudev.

    It seems to me that, with libudev-compat you could have Vdevd create
the symlinks, so that your problem would be solved. Do I understand
well? This seems to me completely independant of Hopman which is desirable.

    Cheers.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ifupdown laptop wired/wifi trick

[Didier Kryn]

Le 26/05/2021 à 12:22, o1bigtenor a écrit :
> On Wed, May 26, 2021 at 1:26 AM Didier Kryn  wrote:
>> Le 25/05/2021 à 21:43, Mason Loring Bliss a écrit :
>>> I've been managing network connections on my laptop by hand, and I was just
>>> thinking that I'd like it to bring up its NICs automatically if it's
>>> plugged in, but I didn't want to use ifplugd for various reasons, and
>>> anyway, I like ifupdown and I want to stick with it.
>> There's no contradiction between ifupdown and ifplugd; they work
>> well together. I have been using both for decades. What I exclude is
>> network-manager.
>>
> Hmm - - - - - why exclude network-manager?
>
> (just wanting to understand.)
>
> TIA

    Well it goes in the way: it undoes what ifupdown does and vice
versa, creating a total mess (~:

--     Didier




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ifupdown laptop wired/wifi trick

[Didier Kryn]

Le 26/05/2021 à 13:54, Olaf Meeuwissen a écrit :
> I have found that the combination of ifupdown, netplug and wpasupplicant
> and a bit of tinkering with /etc/network/interfaces and a configuration
> file for wpa_supplicant satisfies my needs.

    Same for me, replacing netplug with ifplugd. I have nothing against
netplug, just too lazzy to change a working configuration.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ifupdown laptop wired/wifi trick

[Didier Kryn]

Le 25/05/2021 à 21:43, Mason Loring Bliss a écrit :
> I've been managing network connections on my laptop by hand, and I was just
> thinking that I'd like it to bring up its NICs automatically if it's
> plugged in, but I didn't want to use ifplugd for various reasons, and
> anyway, I like ifupdown and I want to stick with it.

    There's no contradiction between ifupdown and ifplugd; they work
well together. I have been using both for decades. What I exclude is
network-manager.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Ascii to Beowulf upgrade borked with eudev

[Didier Kryn]

Le 11/05/2021 à 06:57, Brad Campbell via Dng a écrit :
> G'day all,
>
> I use a self-compiled kernel (v5.10) at the moment.
> An Ascii to Beowulf upgrade died early on because the eudev preinst
> script isn't correctly parsing /proc/kallsyms.
>
> Preparing to unpack .../25-eudev_3.2.9-8~beowulf1_amd64.deb ...
> Since release 198, udev requires support for the following features in
> the running kernel:
>
> - inotify(2)    (CONFIG_INOTIFY_USER)
> - signalfd(2)   (CONFIG_SIGNALFD)
> - accept4(2)
> - open_by_handle_at(2)  (CONFIG_FHANDLE)
> - timerfd_create(2) (CONFIG_TIMERFD)
> - epoll_create(2)   (CONFIG_EPOLL)
> dpkg: error processing archive
> /tmp/apt-dpkg-install-PJCPSM/25-eudev_3.2.9-8~beowulf1_amd64.deb
> (--unpack):
>  new eudev package pre-installation script subprocess returned error
> exit status 1
>
> root@bkmac:/tmp/temp# needed_symbols='inotify_init signalfd accept4
> open_by_handle_at timerfd_create epoll_create'
>
> root@bkmac:/tmp/temp# for symbol in $needed_symbols; do echo $symbol ;
> egrep "^[a-fA-F0-9]+ T \.?sys_${symbol}$" /proc/kallsyms ; done
> inotify_init
> signalfd
> accept4
> open_by_handle_at
> timerfd_create
> epoll_create
>
> root@bkmac:/tmp/temp# for symbol in $needed_symbols; do echo $symbol ;
> egrep "^[a-fA-F0-9]+ T __x64.sys_${symbol}$" /proc/kallsyms ; done
> inotify_init
> 811ac000 T __x64_sys_inotify_init
> signalfd
> 811af380 T __x64_sys_signalfd
> accept4
> 813df4a0 T __x64_sys_accept4
> open_by_handle_at
> 811d3410 T __x64_sys_open_by_handle_at
> timerfd_create
> 811b00c0 T __x64_sys_timerfd_create
> epoll_create
> 811ad9b0 T __x64_sys_epoll_create
>
> I unpacked, patched out the check and re-packed the deb, then manually
> installed it.
> Unfortunately for me (yay) the upgrade then proceeded to break
> horribly with an apt-get -f install resulting it in wanting to
> uninstall X and everything associated with it, requiring severe manual
> intervention to get a functioning system again.
>
> root@bkmac:/var/cache/apt/archives# apt-get -u dist-upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> You might want to run 'apt --fix-broken install' to correct these.
> The following packages have unmet dependencies:
>  cups-daemon : Depends: libcups2 (= 2.2.10-6+deb10u4) but
> 2.2.1-8+deb9u6 is installed
>  cups-ipp-utils : Depends: libcups2 (= 2.2.10-6+deb10u4) but
> 2.2.1-8+deb9u6 is installed
>  libcupsimage2 : Depends: libcups2 (= 2.2.10-6+deb10u4) but
> 2.2.1-8+deb9u6 is installed
>  libeudev-dev : Depends: libeudev1 (= 3.2.2-13) but 3.2.9-8~beowulf1
> is installed
>  libreoffice-java-common : Depends: libreoffice-common (=
> 1:6.1.5-3+deb10u7) but 1:5.2.7-1+deb9u11 is installed
>  libreoffice-style-colibre : Depends: libreoffice-common (=
> 1:6.1.5-3+deb10u7) but 1:5.2.7-1+deb9u11 is installed
>  libusb-1.0-0-dev : Depends: libusb-1.0-0 (= 2:1.0.22-2) but
> 2:1.0.21-1 is installed
>  python3-distutils : Depends: python3 (>= 3.7.1-1~) but 3.5.3-1 is
> installed
>  python3-lib2to3 : Depends: python3 (>= 3.7.1-1~) but 3.5.3-1 is
> installed
> E: Unmet dependencies. Try 'apt --fix-broken install' with no packages
> (or specify a solution).
>
> I got there, but there was a lot of manual dpkg -i from the cache
> directory to get things back on track.
>
> Just a headsup.
>
> Brad


    Hello Brad.

    I'd bet you disabled - or failed to enable - one of the mentionned
kernel features during the config phase of your kernel build. So it
would just be a matter of carefully configuring your kernel build, not
reusing an old config file.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Hopman (Was: ..are we|Devuan safe from this systemd backdoor malware (...)?

[Didier Kryn]

Le 02/05/2021 à 21:09, aitor a écrit :
>
> Hi Didier,
>
> On 1/5/21 17:11, Didier Kryn wrote:
>>     Gvfs is not expected to be installed on servers, but is required by
>> some desktop goodies - even in Xfce4, for example if you install the
>> tool to mount/unmount hotplug disks; it is primarily to avoid it that I
>> developped hopman.
> As i announced, i'm continuing your Hopman project and today i pushed
> the code of the new interface in Gtkmm-2.4,
> keeping yours the same original folder GTK2. The code is available at:
>
> https://gitea.devuan.dev/aitor_czr/hopman/src/branch/master/hopman-1.0/gtkmm
> <https://gitea.devuan.dev/aitor_czr/hopman/src/branch/master/hopman-1.0/gtkmm>
>
> There have been some changes in the watch directory too. For example,
> the original C code didn't manage removable
> sata, ssd... hard disks connected via usb, because the integer
> storaged in the corresponding "removable" file [*] was equal to "0"
> in such cases. On the other hand, trying to figure out how to get the
> hotplug partitioning data in the most efficient way,
> i ended up involved in the helpers of vdev (stat_usb.* and common.*
> files in  the watch directory):
>
> https://gitea.devuan.dev/aitor_czr/hopman/src/branch/master/hopman-1.0/watch
> <https://gitea.devuan.dev/aitor_czr/hopman/src/branch/master/hopman-1.0/watch>
>
> I had wanted to upload the packages of hopman throughout the past
> week, but i've had issues related to some, already resolved,
> GdkMouseEvents. Therefore, they'll be available as soon as posible.
>
> Cheers,
>
> Aitor.
>
> [*] Have a look at the lines nº 25-30 of hotplug_partition.c:
>
> https://gitea.devuan.dev/aitor_czr/hopman/src/branch/master/hopman-1.0/watch/hotplug_partition.c
> <https://gitea.devuan.dev/aitor_czr/hopman/src/branch/master/hopman-1.0/watch/hotplug_partition.c>
>

    Hi Aitor.

    I'm very happy that you cath up on Hopman. I initially made it for
my needs and the community and as a proof of concept. Then I became too
ambitious and I didn't succeed to properly organize internationalization
files and I got discouraged. Yet the tool is working and it is my only
installed tool to mount hotplug USB disks.

    The first method I considered to determine which device was
hotpluggable was a config file made of a list of regular expressions to
match the device file names, such as "sd[c-f]*", untill I found that
kernel tag. Then I discovered, like you, that it only tagged USB
devices. But I sticked with the kernel tag by lazzyness and beause I
could live with it (I use an USB-SDcard adapter).

    There is still a bug in a function in subdir watch, which I have
narrowed down to a logic error in the handling of multiple inotify
events in one buffer. This happens typically the first time a loop
device is mounted, because the driver then creates all loop devices at
once and the corresponding inotify events are small enough that more
than one can fit in the buffer; then hopman enters an endless loop.
Maybe I will dedicate time to repair it some day (~:

--     Didier



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng