Re: [DNG] merged /usr breakage
On Thu, Jan 06, 2022 at 02:00:57PM -0700, Bob Proulx via Dng wrote: > > > > > 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 Or even chown -R someresponsibleuser /usr/local ? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xdg-desktop-portal
On 1/6/22 4:48 PM, Antony Stone wrote: On Thursday 06 January 2022 at 22:30:58, Ken Dibble wrote: Why is xdg-desktop-portal in a fresh install of Chimaera? I have a Chimaera machine here, freshly installed, without any graphical desktop environment - just a command-line network server - and xdg-desktop- portal is not installed. It can be safely uninstalled, as it no devuan packages in the base install require it, They may not REQUIRE it, but I wonder whether you are allowing packages to install RECOMMENDS as well? Try "aptitude why xdg-desktop-portal" and see whether something you do want to have on your machine has simply Recommended xdg-desktop-portal, and you ended up with it because you haven't told apt or aptitude not to do that sort of thing without your permission. I always put two files into /etc/apt/apt.conf.d before allowing much software to be installed: /etc/apt/apt.conf.d/norecommendationsplease APT::Install-Recommends "false"; APT::Get::Install-Recommends "false"; /etc/apt/apt.conf.d/nosuggestionsplease APT::Install-Suggests "false"; APT::Get::Install-Suggests "false"; That way nothing gets installed unless I explicitly ask for it, or it's essential for something I asked for. Antony. Thank you. The machine in question had a gui and it probably got pulled in with a suggestion. I was not aware of the apt configurability, so I got to learn something for free (except for your time). Thanks again. Ken ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xdg-desktop-portal
On Thursday 06 January 2022 at 22:30:58, Ken Dibble wrote: > Why is xdg-desktop-portal in a fresh install of Chimaera? I have a Chimaera machine here, freshly installed, without any graphical desktop environment - just a command-line network server - and xdg-desktop- portal is not installed. > It can be safely uninstalled, as it no devuan packages in the base > install require it, They may not REQUIRE it, but I wonder whether you are allowing packages to install RECOMMENDS as well? Try "aptitude why xdg-desktop-portal" and see whether something you do want to have on your machine has simply Recommended xdg-desktop-portal, and you ended up with it because you haven't told apt or aptitude not to do that sort of thing without your permission. I always put two files into /etc/apt/apt.conf.d before allowing much software to be installed: /etc/apt/apt.conf.d/norecommendationsplease APT::Install-Recommends "false"; APT::Get::Install-Recommends "false"; /etc/apt/apt.conf.d/nosuggestionsplease APT::Install-Suggests "false"; APT::Get::Install-Suggests "false"; That way nothing gets installed unless I explicitly ask for it, or it's essential for something I asked for. Antony. -- Tinned food was developed for the British Navy in 1813. The tin opener was not invented until 1858. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] xdg-desktop-portal
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? Thanks. Ken ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] merged /usr breakage
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 example if it needs to run as a root
Re: [DNG] Conversion from BullsEye to Devuan Fails
tito via Dng wrote: > Hi, > would you like to the test this conversion script at: > > https://git.devuan.org/farmatito/migration > > Hi, you posted this in response to someone else's migration. I read all the warnings about running this remotely, and then tested it on a new server with minimal install of debian bullseye (no gui); it went smoothly. Thanks for the script. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] merged /usr breakage
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] make-rc: A parallel (as in make(1)) alternative to sysv-rc
A long time ago, in a galaxy far far away, or something... I wrote an implementation of sysv-init based on the LSB spec. This was back when the LSB spec was a thing. Not even looked at it since, but let's see if I can correctly recall some of the features. Written in C. Fully implemented the LSB spec. Included those helper programs that LSB also specced. Figured out dependencies from those LSB comments. Could figure those dependencies from init "scripts" written in other languages, by looking for similar bits of text in their executables. Included a few of the basic common sysv-init scripts, also written in C. It may have ran things in parallel, but obviously dependencies where run one after the other. Was as fast as you could imagine it being. May have been written as a BusyBox module. I should find out where I left it (might have been Source Forge), move it to my own git server, and make it a ToyBox module. In my copious spare time. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Problems with SPF of dyne.org for this mailing list
Hi, This report/notice is generated from the mail server which handles incoming and outgoing emails for: the mailing list NB: Incoming email has been flagged with a permanent error due to the currently defined SPF ruleset as setup by those responsible for the SENDING domain name. Sending IP Address: 141.95.47.84 Sender Email Address: dng-boun...@lists.dyne.org Sender Email Domain: lists.dyne.org Thu 6 Jan 23:11:35 AEDT 2022 spfquery.mail-spf-perl --mfrom dng-boun...@lists.dyne.org --ip 141.95.47.84 fail . lists.dyne.org: Sender is not authorized by default to use 'dng-boun...@lists.dyne.org' in 'mfrom' identity (mechanism '-all' matched) Received-SPF: fail (lists.dyne.org: Sender is not authorized by default to use 'dng-boun...@lists.dyne.org' in 'mfrom' identity (mechanism '-all' matched)) receiver=mail.affinityvision.com.au; identity=mailfrom; envelope-from="dng-boun...@lists.dyne.org"; client-ip=141.95.47.84 -- status: 1 Thu 6 Jan 23:11:38 AEDT 2022 dig -t txt lists.dyne.org +short|grep spf "v=spf1 mx include:dyne.org -all" -- status: 0 Thu 6 Jan 23:11:38 AEDT 2022 dig -x 141.95.47.84 +short harlock.dyne.org. -- status: 0 Kind Regards AndrewM ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Track process start / stop?
On Thursday 06 January 2022 at 12:04:48, Tomasz Torcz wrote: > On Thu, Jan 06, 2022 at 11:51:09AM +0100, Antony Stone wrote: > > Hi. > > > > I'm wondering whether there is any way of getting a list or log file of > > processes which get started and terminated, independently of whether > > those processes themselves actually do any logging. > There is audit exactly for that purpose. Aha - thanks - I'll install the auditd package and see how I get on :) Antony. -- "Have you been drinking brake fluid again? I think you're addicted to the stuff." "No, no, it's alright - I can stop any time I want to." Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Track process start / stop?
On Thu, Jan 06, 2022 at 11:51:09AM +0100, Antony Stone wrote: > Hi. > > I'm wondering whether there is any way of getting a list or log file of > processes which get started and terminated, independently of whether those > processes themselves actually do any logging. > > > I'm wondering whether there's a logging option buried in whichever part of > the > system assigns and recovers process IDs as things get started and stopped, > perhaps? There is audit exactly for that purpose. Something like auditctl -a task,always ausearch -i -sc execve should get you started. Another option could be execsnoop (https://github.com/iovisor/bcc/blob/master/tools/execsnoop.py) -- Tomasz Torcz 72->| 80->| to...@pipebreaker.pl 72->| 80->| ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Track process start / stop?
Hi. I'm wondering whether there is any way of getting a list or log file of processes which get started and terminated, independently of whether those processes themselves actually do any logging. Suppose you're running "top". You see processes appear and disappear from the list as they start and end. Is there anything I can do to get a list of these processes logged somewhere (some of them are extremely transient, so you can be lucky to spot them in a "top" list at all)? Maybe it already exists somewhere, and I just need to either look in the rightplace under /var/log, or adjust the logging level of something? My initial interest in having this is to see that "well, this thing ran at that time, so it could be the cause of that thing which went wrong", or "no, I can't see this thing having run any time between then and now, so it's not surprising we don't see the results we expected". I'm wondering whether there's a logging option buried in whichever part of the system assigns and recovers process IDs as things get started and stopped, perhaps? Antony. -- This space intentionally has nothing but text explaining why this space has nothing but text explaining that this space would otherwise have been left blank, and would otherwise have been left blank. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] make-rc: A parallel (as in make(1)) alternative to sysv-rc
Back in 2014 I suggested a solution using make, in order to address dependencies. I didn't closely read your scripts or the make file, but the only way I can imagine this new system would speed boot is if it ran things in the background and found ways to see when dependencies finished. Otherwise, a make-based solution would be no slower or faster than a parallel-start process manager. What I like about this system is that it makes a complete mockery of the original purpose of systemd. You did that with a couple shellscripts and a makefile, to compete with Redhat and their megadollar per year programmers' salary. Be aware, however, that Redhat's original poetterclaim was that the only choices were systemd, sysvinit and upstart. False then, false now. There are several other great init systems. Your system appears to keep the 50 to 300 line sysvinit init scripts, which to me are the real problem with sysvinit. And I think it was those monster scripts that the "debian devs" and the "upstreams" hated so much. Right now, both s6 and runit execute in parallel, with dependencies, using run scripts (equivalent of an init script) that are between 2 and 15 lines. One other thing: Parallel instantiation is significantly faster only if one of the daemons takes a long time to return. In my experience, this is usually caused by a misconfiguration of the slow daemon, often a malfunctioning reverse DNS. If sysvinit had had a decent reporting system on time taken per daemon, and the daemon's return code, the admin would have fixed the daemon and sped up boot. Parallel instantiation just sweeps the misconfiguration problem under the rug. Back during the init wars, a guy brought out a very nice init system called Epoch, which was serial instantiation but in fact came up faster than runit. Systemd came up faster than Epoch, but in the wild, without special tweaks, I've heard systemd comes up slowly. I like the fact that you've made software that makes systemd look silly, but please keep in mind that there are other init alternatives, or sysvinit + process supervisor configurations, that solve all the objections to sysvinit: The supposedly slow bootup, the hundred line init scripts backed by hundreds of lines of shellscript helper files, the absolute requirement that a daemon background itself, the commented out numbers that actually are read and mean something (e, meaningful comments), and all the rest. Here's how I rate init systems, based on a 0 to 10 rating, where 10 is perfect and 0 is useless: s6: 10 runit: 10 sysvinit plus s6, runit or daemontools-encore process supervisor: 10 OpenRC: 6 Epoch: 5 Sysvinit both PID1 and process manager: 2 Systemd: -15 NOTE: A negative number denotes "worse than useless". SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques Alejandro Colomar \(man-pages\) via Dng said on Wed, 5 Jan 2022 03:03:53 +0100 >Hi all, > >Most of you I added you to this email because I found you on the >maintainers list for the Debian sysv-rc package (now dead for a long >time). I also CCd Devuan, since I hope you'll be interested in this >little project of mine. >I also CCd linux-man@, since there's not many people listening there, >and not much traffic these days so I hope you won't be angry for this >little bit of spam; and I hope some good guys reading that list may >have some comments on this. Sorry again for the bit of spam. >I also CCd help-make@. I (ab)used your software in a way that it was >never designed to; not sorry for that; I'll say it was the original >Unix authors' fault for designing such (ab)usable tools :). Maybe >you're interested in this thread, maybe you don't care, but I'll CC >you in case some of you may be interested in this. >And finally, Randy, as you asked, I'll CC you for news on this. >Anyone not interested in follow-ups, please email me, and I'll try to >remove from CC. > >So, last friday (yes, that's New Year's Eve), I was reading something, >and got this idea... the main valid claim for systemd is that it blows >away competition in terms of performance? Full parallelization? >Knows about dependencies? I don't know too much of systems; I know >some basic stuff, but I'm mostly a C programmer, so I don't know >init(1)... okay. But since I program, I sure know the good ol' >make(1). It's old, and it's good at fully parallelizing _everything_. > Dependencies? sure; fast? sure; parallel? sure; simple? sure; a bit > bloated? GNU make maybe, >especially for init(1), but far from systemd(1): > >$ ls -lh $(realpath $(which systemd make bash sh 2>/dev/null)) >-rwxr-xr-x 1 root root 1.2M Dec 15 00:43 /usr/bin/bash >-rwxr-xr-x 1 root root 123K Nov 3 11:51 /usr/bin/dash >-rwxr-xr-x 1 root root 235K Apr 10 2021 /usr/bin/make >-rwxr-xr-x 1 root root 1.8M Nov 19 21:11 /usr/lib/systemd/systemd > >So, if the problem is that the rc scripts don't run parallel and don't
