Re: [DNG] merged /usr breakage
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 example if it needs to run as a root
Re: [DNG] xdg-desktop-portal
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
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 installation into the root file system at the s
[DNG] request for assistance
Greetings Basic question is: what happened? I wanted to update a beowulf system. So did the apt update, apt upgrade, apt dist-upgrade after changing the references in /etc/apt/sources.list from beowulf to chimaera. After reboot - - - well - - - screen says devuan but uname -r is 4.19.xx and not 5.10.xx Any ideas as to how I update the kernel? TIA ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xdg-desktop-portal
Thu, 6 Jan 2022 22:48:16 +0100 - Antony Stone : > 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. Hi Please can anyone suggest a way to list all the packages installed as recommended but without a real dependency? I would be curious to see how I have my system from this point of view ... Regards al3xu5 -- Say NO to copyright, patents, trademarks and industrial design restrictions! Public GPG/PGP key: 8FC2 3121 2803 86E9 F7D8 B624 DA50 835B 2624 A36B pgpTDRpuEdIoX.pgp Description: Firma digitale OpenPGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] request for assistance
Anno domini 2022 Fri, 7 Jan 05:01:46 -0600 o1bigtenor via Dng scripsit: > Greetings > > Basic question is: what happened? > > I wanted to update a beowulf system. > So did the apt update, apt upgrade, apt dist-upgrade > after changing the references in /etc/apt/sources.list > from beowulf to chimaera. > > After reboot - - - well - - - screen says devuan but > uname -r is 4.19.xx and not 5.10.xx > > Any ideas as to how I update the kernel? Most likely you have 2 kernels installed, but GRUB loads the old one. Check that with $ dpkg -l|grep linux-image If so, then uninstall the old kernel and reboot. If not, install the new kernel with # apt-get install linux-image-5. Nik > > TIA > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] merged /usr breakage
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. > 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. > 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. /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. When the user changes stuff in the desktop files (managing autostarts, hiding applications), those changes go into copies of the files in ~/.local. Gnome sees those files as overrides, as long as they have the same name. When the user installs applications for himself (e.g. using xdg-desktop-icon), those desktop files also go there. > 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. so long, benny ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] request for assistance
> On 7 Jan 2022, at 22:02, o1bigtenor via Dng wrote: > > Greetings > > Basic question is: what happened? > > I wanted to update a beowulf system. > So did the apt update, apt upgrade, apt dist-upgrade > after changing the references in /etc/apt/sources.list > from beowulf to chimaera. > > After reboot - - - well - - - screen says devuan but > uname -r is 4.19.xx and not 5.10.xx > > Any ideas as to how I update the kernel? > > TIA > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Do you have the linux-image-amd64 package installed? This is the meta-package that depends on the latest Linux kernel package for the currently installed release; 4.19 for beowulf and 5.10 for chimaera. Without this package there is nothing to tell APT to install the newer kernel package on dist-upgrade. https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=linux-image-amd64&x=submit___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Fwd: request for assistance
-- Forwarded message - From: o1bigtenor Date: Fri, Jan 7, 2022 at 7:18 AM Subject: Re: [DNG] request for assistance To: Olaf Meeuwissen On Fri, Jan 7, 2022 at 5:12 AM Olaf Meeuwissen wrote: > > Hi, > > o1bigtenor via Dng writes: > > > Greetings > > > > Basic question is: what happened? > > > > I wanted to update a beowulf system. > > So did the apt update, apt upgrade, apt dist-upgrade > > after changing the references in /etc/apt/sources.list > > from beowulf to chimaera. > > > > After reboot - - - well - - - screen says devuan but > > uname -r is 4.19.xx and not 5.10.xx > > > > Any ideas as to how I update the kernel? > > Do you by any chance have only a versioned kernel image package > installed? Something like linux-image-4.19.xx-y-amd64. > > If so, you want to install linux-image-amd64 to keep getting the latest > version. > > Adjust for your architecture if necessary. > > Hope this helps, Dunno how it happened but installed linux-image-amd64 did a reboot and things are different. Thank you! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] request for assistance
On Fri, Jan 7, 2022 at 5:14 AM Dr. Nikolaus Klepp via Dng wrote: > > Anno domini 2022 Fri, 7 Jan 05:01:46 -0600 > o1bigtenor via Dng scripsit: > > Greetings > > > > Basic question is: what happened? > > > > I wanted to update a beowulf system. > > So did the apt update, apt upgrade, apt dist-upgrade > > after changing the references in /etc/apt/sources.list > > from beowulf to chimaera. > > > > After reboot - - - well - - - screen says devuan but > > uname -r is 4.19.xx and not 5.10.xx > > > > Any ideas as to how I update the kernel? > > Most likely you have 2 kernels installed, but GRUB loads the old one. Check > that with > $ dpkg -l|grep linux-image > Checked that - - - thanks - - - - not the case. There was only the 4.19.xxx kernel listed. Thanks ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] request for assistance
On Fri, Jan 7, 2022 at 6:14 AM wirelessduck--- via Dng wrote: > > > > On 7 Jan 2022, at 22:02, o1bigtenor via Dng wrote: > > Greetings > > Basic question is: what happened? > > I wanted to update a beowulf system. > So did the apt update, apt upgrade, apt dist-upgrade > after changing the references in /etc/apt/sources.list > from beowulf to chimaera. > > After reboot - - - well - - - screen says devuan but > uname -r is 4.19.xx and not 5.10.xx > > Any ideas as to how I update the kernel? > > TIA > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > Do you have the linux-image-amd64 package installed? This is the meta-package > that depends on the latest Linux kernel package for the currently installed > release; 4.19 for beowulf and 5.10 for chimaera. Without this package there > is nothing to tell APT to install the newer kernel package on dist-upgrade. > > https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=linux-image-amd64&x=submit No - - - dunno how but all that was installed was a kernel. Thanks for the tip! Regards ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] merged /usr breakage
On Fri, Jan 07, 2022 at 11:44:59AM +0100, Didier Kryn wrote: > 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. If I recall correctly, the manufacturer-supplied printer driver for the Brother HL 3170CDW laser printer does this. > > > > > > 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. My chimaera system says hendrik@midwinter:~$ ls /usr/local -l total 36 drwxrwsr-x 2 rootstaff 4096 Jun 1 2021 bin drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 etc drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 games drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 include drwxrwsr-x 4 rootstaff 4096 Oct 5 08:27 lib lrwxrwxrwx 1 rootstaff9 Jul 9 2018 man -> share/man drwxr-sr-x 10 hendrik staff 4096 Jun 1 2021 racket drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 sbin drwxrwsr-x 9 rootstaff 4096 Oct 5 08:21 share drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 src so it looks as if 'staff' is still alive. I certainly didn't set up a 'staff' account myself. ... ... > > > 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. It is not unusual for a non-distro package, let's call it foo, to install *all* of its files in /usr/local/foo . Sometimes the installer for such a package is so kind as to ask the user where to install, with /usr/local/foo as default location. Then the user is expected or told to put things on her PATHs
Re: [DNG] merged /usr breakage
On 1/7/22 8:59 AM, Hendrik Boom wrote: On Fri, Jan 07, 2022 at 11:44:59AM +0100, Didier Kryn wrote: 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. If I recall correctly, the manufacturer-supplied printer driver for the Brother HL 3170CDW laser printer does this. 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. My chimaera system says hendrik@midwinter:~$ ls /usr/local -l total 36 drwxrwsr-x 2 rootstaff 4096 Jun 1 2021 bin drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 etc drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 games drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 include drwxrwsr-x 4 rootstaff 4096 Oct 5 08:27 lib lrwxrwxrwx 1 rootstaff9 Jul 9 2018 man -> share/man drwxr-sr-x 10 hendrik staff 4096 Jun 1 2021 racket drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 sbin drwxrwsr-x 9 rootstaff 4096 Oct 5 08:21 share drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 src so it looks as if 'staff' is still alive. I certainly didn't set up a 'staff' account myself. ... ... Just another data point. kdibble@thinkstation:~$ ls -l /usr/local total 32 drwxr-xr-x 2 root root 4096 Oct 14 08:23 bin drwxr-xr-x 2 root root 4096 Oct 14 08:23 etc drwxr-xr-x 2 root root 4096 Oct 14 08:23 games drwxr-xr-x 2 root root 4096 Oct 14 08:23 include drwxr-xr-x 3 root root 4096 Dec 4 18:59 lib lrwxrwxrwx 1 root root 9 Oct 14 08:23 man -> share/man drwxr-xr-x 2 root root 4096 Oct 14 08:23 sbin drwxr-xr-x 10 root root 4096 Oct 20 11:37 share drwxr-xr-x 2 root root 4096 Oct 14 08:23 src 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. It is not unusual for a non-distro package, let's call it foo, to install *all* of its files in /usr/local/foo . Sometimes the installer for such a package is so kind as to as
Re: [DNG] merged /usr breakage
Hi Didier, Didier Kryn writes: > 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
Re: [DNG] request for assistance
Hi, o1bigtenor via Dng writes: > Greetings > > Basic question is: what happened? > > I wanted to update a beowulf system. > So did the apt update, apt upgrade, apt dist-upgrade > after changing the references in /etc/apt/sources.list > from beowulf to chimaera. > > After reboot - - - well - - - screen says devuan but > uname -r is 4.19.xx and not 5.10.xx > > Any ideas as to how I update the kernel? Do you by any chance have only a versioned kernel image package installed? Something like linux-image-4.19.xx-y-amd64. If so, you want to install linux-image-amd64 to keep getting the latest version. Adjust for your architecture if necessary. Hope this helps, -- Olaf MeeuwissenFSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] merged /usr breakage
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
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
On Fri, Jan 07, 2022 at 05:48:08PM +0100, Didier Kryn wrote: > 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. 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. -- hendrik. > > 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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: request for assistance
Hi, o1bigtenor via Dng writes: > On Fri, Jan 7, 2022 at 5:12 AM Olaf Meeuwissen wrote: >> >> Hi, >> >> o1bigtenor via Dng writes: >> >> > Greetings >> > >> > Basic question is: what happened? >> > >> > I wanted to update a beowulf system. >> > So did the apt update, apt upgrade, apt dist-upgrade >> > after changing the references in /etc/apt/sources.list >> > from beowulf to chimaera. >> > >> > After reboot - - - well - - - screen says devuan but >> > uname -r is 4.19.xx and not 5.10.xx >> > >> > Any ideas as to how I update the kernel? >> >> Do you by any chance have only a versioned kernel image package >> installed? Something like linux-image-4.19.xx-y-amd64. >> >> If so, you want to install linux-image-amd64 to keep getting the latest >> version. >> >> Adjust for your architecture if necessary. >> >> Hope this helps, > > Dunno how it happened but installed linux-image-amd64 did > a reboot and things are different. It happens as a result of the Depends: for linux-image-amd64. These are updated to point to the latest linux-image-x.y.z-n-amd64 package. Take a look at apt show linux-image-amd64 | grep Depends: and enlighten yourself :-) Hope this helps, -- Olaf MeeuwissenFSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xdg-desktop-portal
Hi, al3xu5 via Dng writes: > [[PGP Signed Part:Undecided]] > Thu, 6 Jan 2022 22:48:16 +0100 - Antony Stone > : > >> 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. > > Hi > > Please can anyone suggest a way to list all the packages installed as > recommended but without a real dependency? > > I would be curious to see how I have my system from this point of view ... While I don't know of any such command, you can make apt-get tell you what it would auto-remove if you treat automatically installed packages as candidates for removal. That goes like this apt-get --assume-no \ auto-remove -o APT::AutoRemove::RecommendsImportant=false The --assume-no is there to make sure you don't shoot yourself in the feet, both of them ;-) A similar options exists for Suggests: APT::AutoRemove::SuggestsImportant=false Feel free to set both by using a second -o option. These options will help getting rid of stuff that's already installed. You make them the default by adding APT::AutoRemove::RecommendsImportant "false"; APT::AutoRemove::SuggestsImportant "false"; to your /etc/apt/apt.conf (or in a snippet below /etc/apt/apt.conf.d/). Please note that changing dependencies (courtesy of you applying some upgrades to your system or just running an apt update for daedalus or ceres) may make previously "required" packages no longer so. The APT::AutoRemove::* options are there to clean up in that case. To prevent such packages from getting installed in the first place you can use the --no-install-recommends and --no-install-suggests options. The latter is the default. To set them in your apt.conf APT::Install-Recommends "false"; APT::Install-Suggests "false"; You may want to tell APT that any and all autoremovable packages should be zapped ASAP with APT::Get::AutomaticRemove "true"; This only triggers on installs and removals, not on upgrades :-/, but at least you no longer need to run apt auto-remove manually yourself. You can find this and other gems in the apt-get and apt.conf manual pages. While the apt.conf settings are honoured by the apt as well as apt-get commands, I am not sure apt will honour the same set of options. Finally, the list of automatically and manually installed packages (as well as those on hold) is maintained via the apt-mark utility. Looking at its manual page just now I see some things I didn't know about. Off checking those out ;-) Hope this helps, -- Olaf MeeuwissenFSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] request for assistance
Hi, o1bigtenor via Dng writes: > On Fri, Jan 7, 2022 at 6:14 AM wirelessduck--- via Dng > wrote: >> >> On 7 Jan 2022, at 22:02, o1bigtenor via Dng wrote: >> >>> Greetings >>> >>> Basic question is: what happened? >>> >>> I wanted to update a beowulf system. >>> So did the apt update, apt upgrade, apt dist-upgrade >>> after changing the references in /etc/apt/sources.list >>> from beowulf to chimaera. >>> >>> After reboot - - - well - - - screen says devuan but >>> uname -r is 4.19.xx and not 5.10.xx >>> >>> Any ideas as to how I update the kernel? >> >> Do you have the linux-image-amd64 package installed? This is the >> meta-package that depends on the latest Linux kernel package for the >> currently installed release; 4.19 for beowulf and 5.10 for >> chimaera. Without this package there is nothing to tell APT to >> install the newer kernel package on dist-upgrade. >> >> https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=linux-image-amd64&x=submit > > No - - - dunno how but all that was installed was a kernel. What probably happened is that you selected the versioned kernel in the devuan-installer when you first installed that beowulf system. The installer gives you a choice between a versioned kernel and one that tracks the latest version. I don't remember if that choice is available in the default install or only in the expert install, though. Hope this helps, -- Olaf MeeuwissenFSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Group for /usr/local (was Re: merged /usr breakage)
Hi Ken, Hendrik,
Ken Dibble writes:
> On 1/7/22 8:59 AM, Hendrik Boom wrote:
>> On Fri, Jan 07, 2022 at 11:44:59AM +0100, Didier Kryn wrote:
>>> Le 07/01/2022 à 10:18, Didier Kryn a écrit :
Le 06/01/2022 à 22:00, Bob Proulx via Dng a écrit :
> 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.
>> If I recall correctly, the manufacturer-supplied printer driver for the
>> Brother HL 3170CDW laser printer does this.
The Docker, Kubernetes, Helm and RKE utilities do this to. It seems to
be fairly common for Go applications as well.
> 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.
>> My chimaera system says
>>
>> hendrik@midwinter:~$ ls /usr/local -l
>> total 36
>> drwxrwsr-x 2 rootstaff 4096 Jun 1 2021 bin
>> drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 etc
>> drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 games
>> drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 include
>> drwxrwsr-x 4 rootstaff 4096 Oct 5 08:27 lib
>> lrwxrwxrwx 1 rootstaff9 Jul 9 2018 man -> share/man
>> drwxr-sr-x 10 hendrik staff 4096 Jun 1 2021 racket
>> drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 sbin
>> drwxrwsr-x 9 rootstaff 4096 Oct 5 08:21 share
>> drwxrwsr-x 2 rootstaff 4096 Jul 9 2018 src
>>
>> so it looks as if 'staff' is still alive.
>> I certainly didn't set up a 'staff' account myself.
Hendrik, did you upgrade this system from beowulf (or earlier)? If so,
that's where the staff group was created.
> Just another data point.
>
> kdibble@thinkstation:~$ ls -l /usr/local
> total 32
> drwxr-xr-x 2 root root 4096 Oct 14 08:23 bin
> drwxr-xr-x 2 root root 4096 Oct 14 08:23 etc
> drwxr-xr-x 2 root root 4096 Oct 14 08:23 games
> drwxr-xr-x 2 root root 4096 Oct 14 08:23 include
> drwxr-xr-x 3 root root 4096 Dec 4 18:59 lib
> lrwxrwxrwx 1 root root9 Oct 14 08:23 man -> share/man
> drwxr-xr-x 2 root root 4096 Oct 14 08:23 sbin
> drwxr-xr-x 10 root root 4096 Oct 20 11:37 share
> drwxr-xr-x 2 root root 4096 Oct 14 08:23 src
Ken, is this on a chimaera install? As opposed to an upgrade.
It's group root on my daedalus install (used the 5.0.preview-20211220
installer) but I really would have liked it to be staff out-of-the-box.
The staff group still exists, by the way.
Guess I'll have some fixing up to do.
adduser olaf staff
chgrp --recursive staff /usr/local
chmod --recursive g+w /usr/local
find /usr/local -type d -exec chmod g+s '{}' \;
together with a little /etc/apt/apt.conf.d/ snippet like
DPkg::Post-Invoke { "chgrp -R staff /usr/local; chmod -R g+w /usr/local; find
/usr/local -type d -exec chmod g+s '{}' \;"; };
ought to keep things the way I prefer them. The snippet uses -R instead
of the more descriptive --recursive for brevity.
Note that the above is simplistic. If you have anything that requires a
specific group and/or permissions, such specifics will be clobbered by
the next apt or dpkg information that modifies your installed packages.
Hmm, on checking before and after states, I noticed that before there
was a /usr/local/share/fonts/ with group staff and the setuid bit for
the group set. There was also a .uuid file in there.
drwxrwsr-x 2 root staff4096 Jan 6 12:27 /usr/local/share/fonts
-rw-r--r-- 1 root staff 36 Jan 6 12:50
/usr/local/share/fonts/.uuid
All of the above has been checked and tested on a clean, minimal install
of daedulus just a few days ago. That fonts directory was added by the
installation of xserver-xorg.
Hmm, hmm, now
