Re: Feature request: Make deb822 default and deprecate old-style sources.list

On Sun, May 11, 2025 at 09:34:44PM +0100, Darac Marjal wrote: I read some advice recently that suggested taking the time some thing has existed to be a "half-life" for deprecation. So, if the pre-deb822 format has existed for 27 years and we deprecated it now, we can expect 50% of users will ha

Re: Feature request: Make deb822 default and deprecate old-style sources.list

for making deb822 the default format and deprecating the previous .list method with a noisy warning. You ask in the wrong place: try debian-devel, or file a request against the relevant packages (apt?) However, can I point out that the pre-822 format has been around for *27 years*: it's goi

Re: Feature request: Make deb822 default and deprecate old-style sources.list

On Thu May 1, 2025 at 9:17 PM BST, Jonathan Dowland wrote: However, can I point out that the pre-822 format has been around for *27 years*: it's going to take a long time for people who are familiar with it to internalise the new format. Introducing nagging warnings too soon will frustrate peop

Re: Feature request: Make deb822 default and deprecate old-style sources.list

On 2025-05-02, Siddh Raman Pant wrote: > Now that we have deb822 format for specifying APT repo which includes > everything within one file, the user should be discouraged from using > old styles where the GPG key is stored in a "keyring" (whether it be a > trusted keyring or just a folder in anot

Re: Feature request: Make deb822 default and deprecate old-style sources.list

On Thu May 1, 2025 at 7:30 PM BST, Siddh Raman Pant wrote: A big red warning (and not error / failure) will bring a much needed kinetic force for the change IMO, on the same lines as the warning when using the old apt-keys stuff. Hence, I request for making deb822 the default format and

Re: Feature request: Make deb822 default and deprecate old-style sources.list

he software or doc-cycle are open in the first place. > > A big red warning (and not error / failure) will bring a much needed > kinetic force for the change IMO, on the same lines as the warning > when using the old apt-keys stuff. > > Hence, I request for making deb822 the default

Feature request: Make deb822 default and deprecate old-style sources.list

ed kinetic force for the change IMO, on the same lines as the warning when using the old apt-keys stuff. Hence, I request for making deb822 the default format and deprecating the previous .list method with a noisy warning. Thanks, Siddh

cups-browsed installed and open by default (was: Limiting attack surface for Debian sshd)

ail/cve-2024-47176 On this machine, the package cups-browsed is installed, but it is disabled and thus not started by systemd. Don't know if this is a default setting? cups-browsed is only required if you want to see the Bonjour available printers on your network, or if you want to make yo

Re: Admin Root user [not set to default]

uld be grateful if someone could explain why admin root user is > not set to default. I have always had user login and password and then > root for for other tasks like Aptitude updates. [I am a fan of > Aptitude although most folk seem to prefer Apt]. > > Also not sure where to set root

Re: Admin Root user [not set to default]

On Wed, Apr 09, 2025 at 13:44:14 +0100, James Freer wrote: > b] 'Sudo' - i thought came in with ubuntu (and some other > derivatives). Many distros use 'su -' for admin rights and i thought > Debian was one of those. Sudo i thought was introduced as a level of > safety for newbie users so they coul

Re: Admin Root user [not set to default]

On Wed, Apr 09, 2025 at 09:34:08AM -0400, Jeffrey Walton wrote: [...] > Disabling root logins by default is especially important when a > network attacker can use the login, like via SSH. To achieve this... > The network attacker >

Re: Admin Root user [not set to default]

On Wed, Apr 09, 2025 at 09:34:08 -0400, Jeffrey Walton wrote: > Disabling root logins by default is especially important when a > network attacker can use the login, like via SSH. The network attacker > is usually your #1 threat, There may be systems where this is true; for example, a p

Re: Admin Root user [not set to default]

has now included sudo. It > >may > be that the Calamares installer has decided this setup and it is > better to use the netinst iso. > Sudo goes back a long way, and was only included in a default Debian installation in the last few versions, but it was always available. Sever

Re: Admin Root user [not set to default]

Greg Wooledge (HE12025-04-09): > I really don't understand why so many people do this. Why would you > install using a "Live" medium instead of the real installer? Because the real installer does not give the fine control I want and has a crappy user interface. I always install my Debians with G

Re: Admin Root user [not set to default]

go with. I would be grateful if someone could explain why admin root user is not set to default. I have always had user login and password and then root for for other tasks like Aptitude updates. [I am a fan of Aptitude although most folk seem to prefer Apt]. Also not sure where to set root admi

Re: Admin Root user [not set to default]

could explain why admin root user is > not set to default. I have always had user login and password and then > root for for other tasks like Aptitude updates. [I am a fan of > Aptitude although most folk seem to prefer Apt]. To answer this question, root login is generally discouraged i

Re: Admin Root user [not set to default]

On Wed, 9 Apr 2025 at 12:05, Greg Wooledge wrote: > > On Wed, Apr 09, 2025 at 10:50:54 +0100, James Freer wrote: > > I've just done my install of Debian 12 Live XFCE version. > > I really don't understand why so many people do this. Why would you > install using a "Live" medium instead of the rea

Re: Admin Root user [not set to default]

On Wed, Apr 09, 2025 at 10:50:54 +0100, James Freer wrote: > I've just done my install of Debian 12 Live XFCE version. I really don't understand why so many people do this. Why would you install using a "Live" medium instead of the real installer? Anyway, the Live version doesn't set a root pass

Re: Admin Root user [not set to default]

James Freer writes: > I would be grateful if someone could explain why admin root user is > not set to default. I have always had user login and password and then > root for for other tasks like Aptitude updates. [I am a fan of > Aptitude although most folk seem to prefer Apt]. >

Re: Admin Root user [not set to default]

ain why admin root user is > not set to default. I have always had user login and password and then > root for for other tasks like Aptitude updates. [I am a fan of > Aptitude although most folk seem to prefer Apt]. > > Also not sure where to set root admin user. I suppose it doesn&#x

Admin Root user [not set to default]

Hi members I've just done my install of Debian 12 Live XFCE version. Been a user of Xubuntu for 15 years and thought i would change. Tried some of the derivatives and chose Debian to go with. I would be grateful if someone could explain why admin root user is not set to default. I have a

nut on Debian bullseye: issues with UID and default config

c I also noticed that without the sudo it does not work either. However, there is more: if I do not change, in upssched.conf two definitions to: PIPEFN /run/nut/upssched.pipe LOCKFN /run/nut/upssched.lock it fails because it looks the startup scripts do not create the /run/nut/upssched/ dire

Re: eject: using default device `/dev/sr0'

Hi, Dan Purgert wrote: > You "may" need to wait for the drive to finish reading the disc metadata > (i.e. drive light stops flashing) before mount(1) will not complain > about the lack of media. Not 100% sure if it's a generic problem, or > just my crappy USB CD drive :) It's a Linux kernel prob

Re: eject: using default device `/dev/sr0'

On Feb 17, 2025, Thomas Schmitt wrote: > Hi, > > Dan Purgert wrote: > > You "may" need to wait for the drive to finish reading the disc metadata > > (i.e. drive light stops flashing) before mount(1) will not complain > > about the lack of media. Not 100% sure if it's a generic problem, or > > jus

Re: eject: using default device `/dev/sr0'

In my experience, `cdrskin -eject` works more reliable than `eject`. Regards, Jörg.

Re: eject: using default device `/dev/sr0'

t; But i get the following error message: > > > > > > > > > *mount: /mnt/cdrom: no medium found on /dev/sr0. dmesg(1) may > > > have > > > more information after failed mount system call.* > > > > Is there a CD/DVD inserted in the drive?

Re: eject: using default device `/dev/sr0'

Hi, William Torrez Corea wrote: > eject: device name is `/dev/sr0' > ... > eject: CD-ROM eject command succeeded > > I can't eject the optical drive That was with: eject -v /dev/sr0 ? What do you get from this program run xorriso -outdev /dev/sr0 -eject all > i try mount the device: > sudo

Re: eject: using default device `/dev/sr0'

the drive? on bookworm without a cd in the tray. mick@courgette:~$ eject -v eject: using default device `/dev/sr0' eject: device name is `/dev/sr0' eject: /dev/sr0: not mounted eject: /dev/sr0: is whole-disk device eject: /dev/sr0: trying to eject using CD-ROM eject command eject:

Re: eject: using default device `/dev/sr0'

On Feb 16, 2025, William Torrez Corea wrote: > *eject: device name is `/dev/sr0'eject: /dev/sr0: not mountedeject: > /dev/sr0: is whole-disk deviceeject: /dev/sr0: trying to eject using CD-ROM > eject commandeject: CD-ROM eject command succeeded* > > I can't eject the optical drive, i try mount th

eject: using default device `/dev/sr0'

*eject: device name is `/dev/sr0'eject: /dev/sr0: not mountedeject: /dev/sr0: is whole-disk deviceeject: /dev/sr0: trying to eject using CD-ROM eject commandeject: CD-ROM eject command succeeded* I can't eject the optical drive, i try mount the device: *sudo mount -t iso9660 /dev/sr0 /mnt/cdrom*

Re: Don't set APT::Default-Release to backports

ped through /etc/apt/apt.conf and /etc/apt/apt.conf.d/ and found no cases of APT::Default-Release. It is rather strange. Fri, 31 Jan 2025 22:52:18 +0100 (CET) <https://lists.debian.org/msgid-search/2ef170ef-3144-c48d-2a47-245e961bf...@rogerprice.org>: apt -t bookworm-backports install yt-dlp

Re: Don't set APT::Default-Release to backports (was: Re: Firefox and Video DRM)

misleading. It seems to me now that synaptic is not the correct tool for managing backported packages, apt on the command line is much preferable. > I do not use Synaptic, but from another message in this thread I suspect that > it sets APT::Default-Release somewhere in /etc/apt/apt.conf

Re: Don't set APT::Default-Release to backports (was: Re: Firefox and Video DRM)

o not do it. It is not a supposed way to use backports. > <https://backports.debian.org/> > > It is therefore recommended to only select single backported packages > > that fit your needs, and not use all available backports. > > I do not use Synaptic, but from another message in this thread

Don't set APT::Default-Release to backports (was: Re: Firefox and Video DRM)

e recommended to only select single backported packages that fit your needs, and not use all available backports. I do not use Synaptic, but from another message in this thread I suspect that it sets APT::Default-Release somewhere in /etc/apt/apt.conf or /etc/apt/apt.conf.d/. This is a depr

Re: XOFF (C-s) on ptys works by default

ply closed the xterm or mate-terminal window without thinking, and they told me something like "oh, that unreliable Linux terminal is stuck again". However, as you explainted it to me in your previous message, I understand now that changing a global default might not be the road

Re: XOFF (C-s) on ptys works by default

Marc SCHAEFER (12024-11-05): > > It is very handy on emulated ttys too. You never had the output of > > tcpdump / tail -f /var/log/ / make you wanted to pause to inspect > > something? > On slow, physical VT100 terminals, indeed, I used that over 20 years > ago. On virtual ones they are usually to

Re: XOFF (C-s) on ptys works by default

On Tue, Nov 05, 2024 at 09:15:56AM -0500, Stefan Monnier wrote: > Nicolas George [2024-11-05 12:11:39] wrote: > > Marc SCHAEFER (12024-11-05): > >> It could have been handy on a real tty > > It is very handy on emulated ttys too. You never had the output of > > tcpdump / tail -f /var/log/… / make y

Re: XOFF (C-s) on ptys works by default

Nicolas George [2024-11-05 12:11:39] wrote: > Marc SCHAEFER (12024-11-05): >> It could have been handy on a real tty > It is very handy on emulated ttys too. You never had the output of > tcpdump / tail -f /var/log/… / make you wanted to pause to inspect > something? I always use `C-z` for that.

Re: XOFF (C-s) on ptys works by default

On Tue, Nov 05, 2024 at 12:11:39PM +0100, Nicolas George wrote: > Marc SCHAEFER (12024-11-05): > > It could have been handy on a real tty > > It is very handy on emulated ttys too. You never had the output of > tcpdump / tail -f /var/log/… / make you wanted to pause to inspect > something? > It's

Re: XOFF (C-s) on ptys works by default

On Tue, Nov 05, 2024 at 12:49:46PM +0100, Marc SCHAEFER wrote: > Hello, > > On Tue, Nov 05, 2024 at 12:11:39PM +0100, Nicolas George wrote: > > > It could have been handy on a real tty > > > > It is very handy on emulated ttys too. You never had the output of > > tcpdump / tail -f /var/log/ / mak

Re: XOFF (C-s) on ptys works by default

Hello, On Tue, Nov 05, 2024 at 12:11:39PM +0100, Nicolas George wrote: > > It could have been handy on a real tty > > It is very handy on emulated ttys too. You never had the output of > tcpdump / tail -f /var/log/ / make you wanted to pause to inspect > something? On slow, physical VT100 termin

Re: XOFF (C-s) on ptys works by default

Marc SCHAEFER (12024-11-05): > It could have been handy on a real tty It is very handy on emulated ttys too. You never had the output of tcpdump / tail -f /var/log/… / make you wanted to pause to inspect something? > It can be annoying because some users will not know that they can > get out of t

XOFF (C-s) on ptys works by default

Hello, Something funny is that on a pty you have XON/XOFF software flow control enabled by default: - if you type C-s (XOFF), output will be paused - if you type C-q (XON), output will be resumed It could have been handy on a real tty -- serial line/port -- although when I was using

Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])

On Tue, Aug 20, 2024 at 11:51 AM Nicolas George wrote: > > [...] > > EFI files are signed > > for Secure Boot, so vendor paths can not be easily adjusted. > > Secure boot is a joke when it comes to security, its only “merit” is to > prevent l

Re: The lack of a future for 32-bit x86 installs (Was Re: Default partition mounts [ "Installation Guide" lacks index ])

On Tue, Aug 20, 2024 at 03:17:02PM +, Andy Smith wrote: > > Then there is the fact that the LTS team can and does mark packages > as unsupportable for the lifetime of LTS when they need to, so just > because LTS team exists doesn't mean they can get around to > supporting 32-bit x86 installer/

Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])

Max Nikulin (12024-08-20): > Single EFI System Partition may contain loaders from different vendors, but > not 2 Debian systems installed on different partitions. This is not true. The only problem you will have with this setup is that you will need to install and/or configure the bootloader manua

Re: UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])

On Tue, Aug 20, 2024 at 05:17:43PM CEST, Max Nikulin said: > On 20/08/2024 11:27, David Christensen wrote: > > AIUI UEFI/GPT were designed to support multi-boot > > Single EFI System Partition may contain loaders from different vendors, but > not 2 Debian systems installed on different partitions

UEFI multiboot (was: Re: Default partition mounts [ "Installation Guide" lacks index ])

On 20/08/2024 11:27, David Christensen wrote: AIUI UEFI/GPT were designed to support multi-boot Single EFI System Partition may contain loaders from different vendors, but not 2 Debian systems installed on different partitions. EFI files are signed for Secure Boot, so vendor paths can not be

The lack of a future for 32-bit x86 installs (Was Re: Default partition mounts [ "Installation Guide" lacks index ])

Hello, On Tue, Aug 20, 2024 at 03:44:03AM -0500, Richard Owlett wrote: > On 08/19/2024 02:51 PM, Andy Smith wrote: > > [32-bit x86] as previously mentioned has a single digit of years > > of remaining lifetime in Debian. > > I don't see anything on https://wiki.debian.org/LTS that implies shorter

Re: Trixie and i386 - was [Re: Default partition mounts [ "Installation Guide" lacks index ]]

On Tue, 20 Aug 2024 07:34:33 -0500 Richard Owlett wrote: > > 5.1.13. Baseline for 32-bit PC is now i686¶ > > > > Debian's support for 32-bit PC (known as the Debian architecture > > i386) now no longer covers any i586 processor. The new minimum > > requirement is i686. This means that the i386 a

Trixie and i386 - was [Re: Default partition mounts [ "Installation Guide" lacks index ]]

On 08/20/2024 05:45 AM, Richard Owlett wrote: On 08/20/2024 04:30 AM, Andrew M.A. Cater wrote: [snip] There will be non i386 installer medium for Trixie when released though i386 will be retained as a release architecture. Can you point me to the details. I have two i386 I wish to use as long

Re: Default partition mounts [ "Installation Guide" lacks index ]

On 08/20/2024 04:30 AM, Andrew M.A. Cater wrote: On Tue, Aug 20, 2024 at 03:44:03AM -0500, Richard Owlett wrote: On 08/19/2024 02:51 PM, Andy Smith wrote: Hi, I'm afraid I have not got the kind of answer you request for your actual question but… Hi Richard, A first question: is this your m

Re: Default partition mounts [ "Installation Guide" lacks index ]

On Tue, Aug 20, 2024 at 03:44:03AM -0500, Richard Owlett wrote: > On 08/19/2024 02:51 PM, Andy Smith wrote: > > Hi, > > > > I'm afraid I have not got the kind of answer you request for your > > actual question but… > > Hi Richard, A first question: is this your main computer? The R61 is from 2

Re: Default partition mounts [ "Installation Guide" lacks index ]

On 08/19/2024 02:51 PM, Andy Smith wrote: Hi, I'm afraid I have not got the kind of answer you request for your actual question but… On Mon, Aug 19, 2024 at 06:19:26AM -0500, Richard Owlett wrote: I'm over 80 and doing first "from scratch" install since Squeeze ;} Hardware is Lenovo R61 ThinkP

Re: Default partition mounts [ "Installation Guide" lacks index ]

On 08/19/2024 11:27 PM, David Christensen wrote: On 8/19/24 04:19, Richard Owlett wrote: I'm over 80 and doing first "from scratch" install since Squeeze ;} Hardware is Lenovo R61 ThinkPad (64 bit). I multi boot [Grub will have at least three options]:    1. minimalist installation - primarily c

Re: Default partition mounts [ "Installation Guide" lacks index ]

On 08/19/2024 10:17 PM, David Wright wrote: On Mon 19 Aug 2024 at 16:23:31 (-0600), Tom Dial wrote: On 8/19/24 05:19, Richard Owlett wrote: I'm over 80 and doing first "from scratch" install since Squeeze ;} Hardware is Lenovo R61 ThinkPad (64 bit). I multi boot [Grub will have at least three o

Re: Default partition mounts [ "Installation Guide" lacks index ]

On 8/19/24 04:19, Richard Owlett wrote: I'm over 80 and doing first "from scratch" install since Squeeze ;} Hardware is Lenovo R61 ThinkPad (64 bit). I multi boot [Grub will have at least three options]:   1. minimalist installation - primarily command line usage   2. 64 bit Debian with maximum

Re: Default partition mounts [ "Installation Guide" lacks index ]

On Mon 19 Aug 2024 at 16:23:31 (-0600), Tom Dial wrote: > On 8/19/24 05:19, Richard Owlett wrote: > > I'm over 80 and doing first "from scratch" install since Squeeze ;} > > Hardware is Lenovo R61 ThinkPad (64 bit). > > I multi boot [Grub will have at least three options]: > >   1. minimalist inst

Re: Default partition mounts [ "Installation Guide" lacks index ]

On 8/19/24 05:19, Richard Owlett wrote: I'm over 80 and doing first "from scratch" install since Squeeze ;} Hardware is Lenovo R61 ThinkPad (64 bit). I multi boot [Grub will have at least three options]:   1. minimalist installation - primarily command line usage   2. 64 bit Debian with maxi

Re: Default partition mounts [ "Installation Guide" lacks index ]

Hi, I'm afraid I have not got the kind of answer you request for your actual question but… On Mon, Aug 19, 2024 at 06:19:26AM -0500, Richard Owlett wrote: > I'm over 80 and doing first "from scratch" install since Squeeze ;} > Hardware is Lenovo R61 ThinkPad (64 bit). > I multi boot [Grub will ha

Re: Default partition mounts [ "Installation Guide" lacks index ]

arameters are specific to the filesystem type. IMHO "tutorial" is a sub-set of "documentation". And the "magic string" is "/etc/fstab" ;} [I had modified the one on this machine. Whenever I modify a default file, I *include comments* about *why*.]

Re: Default partition mounts [ "Installation Guide" lacks index ]

On Mon, 19 Aug 2024 08:44:39 -0500 Richard Owlett wrote: > THANK YOU > > On 08/19/2024 07:02 AM, David wrote: > > On Mon, 19 Aug 2024 at 11:19, Richard Owlett > > wrote: > >> At boot time, what determines which physical partition gets > >> mounted as a specific directory ( /, /home, swap, and

Re: Default partition mounts [ "Installation Guide" lacks index ]

THANK YOU On 08/19/2024 07:02 AM, David wrote: On Mon, 19 Aug 2024 at 11:19, Richard Owlett wrote: At boot time, what determines which physical partition gets mounted as a specific directory ( /, /home, swap, and so forth )? Please reference documentation as reading it will remind me of how

Re: Default partition mounts [ "Installation Guide" lacks index ]

On Mon, 19 Aug 2024 at 11:19, Richard Owlett wrote: > At boot time, what determines which physical partition gets mounted as a > specific directory ( /, /home, swap, and so forth )? > > Please reference documentation as reading it will remind me of how and > why I chose specific options. man 5 f

Default partition mounts [ "Installation Guide" lacks index ]

I'm over 80 and doing first "from scratch" install since Squeeze ;} Hardware is Lenovo R61 ThinkPad (64 bit). I multi boot [Grub will have at least three options]: 1. minimalist installation - primarily command line usage 2. 64 bit Debian with maximum features 3. 32 bit Debian - couple of ap

Avoid APT::Default-Release (was: Re: nvidia vs nouveau driver and initrd.* size)

On 04/08/2024 06:24, Van Snyder wrote: Then, to avoid sucking anything more from unstable, I added /etc/apt/apt.conf.d/my-default containing APT::Default-Release "stable"; <https://wiki.debian.org/AptConfiguration#Be_careful_with_APT::Default-Release> It prevents installing

Re: umask - default user settings?

avior. For administrative tasks 022 is more reasonable default even if something else is configured for regular users. sudoers(5) describes "umask_override" and "umask" settings. It seems changing default umask requires modification of these preferences.

Re: umask - default user settings?

On 19/07/2024 10:45, songbird wrote: - Does MATE use scopes and services to run applications an components? "ps xwf" and "systemd-cgls" trees may clarify where started applications appear. neither of those show all the programs that i have included on the panels, but there are cgroups and so

Re: umask - default user settings?

On Fri, Jul 19, 2024 at 23:04:25 +0700, Max Nikulin wrote: > On 16/07/2024 20:46, Greg Wooledge wrote: > > On Mon, Jul 15, 2024 at 23:39:54 -0400, Greg Wooledge wrote: > > > Now we just need for GNOME users to discover a way to configure the > > > programs that are started as children of dbus, and

Re: umask - default user settings?

On 16/07/2024 20:46, Greg Wooledge wrote: On Mon, Jul 15, 2024 at 23:39:54 -0400, Greg Wooledge wrote: Now we just need for GNOME users to discover a way to configure the programs that are started as children of dbus, and then we can move forward. Documentation would be my top priority. If oth

Re: umask - default user settings?

Max Nikulin wrote: > On 19/07/2024 04:11, songbird wrote: >>so far, agreed, i poked at it a bit the other day to see >> if MATE would work with the roughly (user-@1000,etc) systemd >> unit approach but that didn't accomplish anything i could tell. > > It would be great if those, who tried it, r

Re: umask - default user settings?

On 19/07/2024 04:11, songbird wrote: so far, agreed, i poked at it a bit the other day to see if MATE would work with the roughly (user-@1000,etc) systemd unit approach but that didn't accomplish anything i could tell. It would be great if those, who tried it, reported more precise what the

Re: umask - default user settings?

Greg Wooledge wrote: ... > It only becomes *hard* when Desktop Environments are introduced into the > picture. so far, agreed, i poked at it a bit the other day to see if MATE would work with the roughly (user-@1000,etc) systemd unit approach but that didn't accomplish anything i could tell.

Re: umask - default user settings?

On Thu, Jul 18, 2024 at 09:07:48 +0700, Max Nikulin wrote: > Taking into account a number of bugs, perhaps it is not really bad that > recipes how to change umask are not easily available. Documentation should > be extensive enough to describe possible pitfalls. That's an odd stance, especially if

Re: umask - default user settings?

-update by default. The tool has a brief man page. Files in pam.d need update when packages with pam modules are installed or removed. It seems similar to some other config file only a part of it is managed by a tool. Taking into account a number of bugs, perhaps it is not really bad that

Re: umask - default user settings?

On Wed, Jul 17, 2024 at 20:51:40 +0200, Franco Martelli wrote: > If you plan to add your contribute to the wiki page (see above) in the > section: "Desktop Environments and systemd user services" e.g.: > > - ... > - systemctl --user daemon-reload > - /Restart your Desktop session/ > > Please cons

Re: umask - default user settings?

On 16/07/24 at 15:46, Greg Wooledge wrote: I've added a bit of content to . On 17/07/24 at 04:37, Max Nikulin wrote: daemon-reload is not enough in KDE. krunner and plasmashell services have been started already, so changes would not apply despite

Re: umask - default user settings?

On Wed, Jul 17, 2024 at 17:58:57 +0100, Tim Woodall wrote: > No, I'm talking about sudo, not su. I'm not a sudo user so I can't test > but my understanding is that root inherits the umask of the invoking > user (or it used to) Looks like this is still true. hobbit:~$ bash hobbit:~$ umask 077 hobb

Re: umask - default user settings?

On Wed, 17 Jul 2024, Max Nikulin wrote: On 17/07/2024 15:37, Tim Woodall wrote: umask 077 can come with its own problems when using shared directories. Taking into account old 022 vs. 002 discussions it might be 007. I'm not a sudo user but IIUC,

Re: umask - default user settings?

On 15/07/2024 09:15, Alan D. Salewski wrote: I suspect that most people /do/ change it, once they become aware of it, for the very reason stated in the comment above 'UMASK' in the /etc/login.defs file:     # UMASK is the default umask value for pam_umask and is used by     # u

Re: umask - default user settings?

#x27;t appear until Debian 13. This makes me wonder what's setting umask *now*. Is it still PAM, just using a compile-time default instead of a value that's discoverable in a conffile? Also, this confused me: hobbit:/etc/pam.d$ dpkg -S /etc/pam.d/common-session dpkg-query: no path fo

Re: umask - default user settings?

n change umask, I'd suggest that the better change is to make home directories 0700 by default. The topic starter believes it is not enough <https://lists.debian.org/msgid-search/860527137.0ifERbkFSE@protheus2> Mon, 15 Jul 2024 09:04:54 +0200 However I would not mind to read more details what use cases are not covered. /tmp?

Re: umask - default user settings?

should be world readable. Rather than change umask, I'd suggest that the better change is to make home directories 0700 by default. If that is the wrong choice then it only has to be fixed once per user. Creating 'world/group' readable files with too restrictive permissions never goes away.

Re: umask - default user settings?

On 16/07/2024 10:39, Greg Wooledge wrote: hobbit:~$ cat .config/systemd/user/service.d/env.conf [Service] Environment="FOO=%h/test123" "BAR=b a r" hobbit:~$ systemctl --user daemon-reload hobbit:~$ systemctl --user start xterm.service daemon-reload is not enough in KDE. krunner and plasmashell

Re: umask - default user settings?

On Jul 16, 2024, Thomas Schmitt wrote: > Hi, > > to...@tuxteam.de wrote: > > Somehow I'm glad I stayed away from DEs and systemd up to now. Perhaps I > > just retire before the alternatives aren't viable anymore. Or perhaps, as > > with PulseAudio, I can leapfrog that "tech". > > Retirement is no

Re: umask - default user settings?

Darac Marjal wrote: > I'm not saying that what you did was wrong, but systemd provides a > few shortcuts which can make things a bit more user-friendly. > > On 16/07/2024 04:39, Greg Wooledge wrote: > > OK. Let's follow this path a bit. > > I googled "how to create a systemd user service" and got

Re: umask - default user settings?

Debian is a multi-user operating system. Decisions should be made accordingly. I suppose umask is a moot point on phones and tablets, where single-user is often the use case. On the contrary, modern Android is strongly multi-user. Each "app" tends to be allocated its own user ID. The logic is

Re: umask - default user settings?

I'm not saying that what you did was wrong, but systemd provides a few shortcuts which can make things a bit more user-friendly. On 16/07/2024 04:39, Greg Wooledge wrote: OK. Let's follow this path a bit. I googled "how to create a systemd user service" and got

Re: umask - default user settings?

On Tue, Jul 16, 2024 at 1:45 PM wrote: >[...] > > (The most probable outcome though is even less rosy: everything'll run in > the browser, and Secure Boot will make sure that your hardware refuses to > run anything else, because the chips are sponsored by the Ad Industry. Lol...

Re: umask - default user settings?

Hi, to...@tuxteam.de wrote: > Somehow I'm glad I stayed away from DEs and systemd up to now. Perhaps I > just retire before the alternatives aren't viable anymore. Or perhaps, as > with PulseAudio, I can leapfrog that "tech". Retirement is no solution. What shall we retirees do when X11 is laid t

Re: umask - default user settings?

On Tue, Jul 16, 2024 at 11:52:29AM -0400, Greg Wooledge wrote: > On Tue, Jul 16, 2024 at 22:21:23 +0700, Max Nikulin wrote: > > Greg, do you have an example when Environment= in service.d works, but an > > environment.d file does not? > > Oh gods, there's MORE shit to worry about?? Of course ther

Re: umask - default user settings?

On Tue, Jul 16, 2024 at 22:21:23 +0700, Max Nikulin wrote: > Greg, do you have an example when Environment= in service.d works, but an > environment.d file does not? Oh gods, there's MORE shit to worry about?? Of course there is. Bloody hell. In previous years, I remember exploring environment.d

Re: umask - default user settings?

On 16/07/2024 19:03, Greg Wooledge wrote: On Tue, Jul 16, 2024 at 18:42:40 +0700, Max Nikulin wrote: On 16/07/2024 10:39, Greg Wooledge wrote: hobbit:~/.config$ cat systemd/user/xterm.service I am a bit afraid that corner cases might exist because there are no .service files for applications

Re: umask - default user settings?

On Mon, Jul 15, 2024 at 23:39:54 -0400, Greg Wooledge wrote: > Now we just need for GNOME users to discover a way to configure the > programs that are started as children of dbus, and then we can move > forward. Documentation would be my top priority. If other people want > to try to drum up inte

Re: umask - default user settings?

On Tue, Jul 16, 2024 at 18:42:40 +0700, Max Nikulin wrote: > On 16/07/2024 10:39, Greg Wooledge wrote: > > hobbit:~/.config$ cat systemd/user/xterm.service > > I am a bit afraid that corner cases might exist because there are no > .service files for applications started from menus and runners Wel

Re: umask - default user settings?

On 16/07/2024 10:39, Greg Wooledge wrote: On Tue, Jul 16, 2024 at 09:58:20 +0700, Max Nikulin wrote: cat ~/.config/systemd/user/service.d/umask.conf [Service] UMask=0007 I googled "how to create a systemd user service" and got The following blog posts (0pointer.de) may be a bit outdated, but

Re: umask - default user settings?

Greg Wooledge (12024-07-15): > Neither am I. But more to the point, it appears that the default umask > literally *cannot* be changed in any kind of universal way. There are, > like, half a dozen different places you'd have to apply a change in > order to cover just the *most

Re: umask - default user settings?

On Tue, Jul 16, 2024 at 09:58:20 +0700, Max Nikulin wrote: > I have naively tried > > cat ~/.config/systemd/user/service.d/umask.conf > [Service] > UMask=0007 > > From xterm and konsole: > > umask > 0007 OK. Let's follow this path a bit. I googled "how to create a systemd user service" and go

Re: umask - default user settings?

On 16/07/2024 08:34, Greg Wooledge wrote: On Tue, Jul 16, 2024 at 08:02:45 +0700, Max Nikulin wrote: systemd.exec(5) UMask= [...] [5] refers to <https://systemd.io/USER_RECORD>. I do not have systemd-homed running (minimal KDE). I have no idea concerning default Gnome installati

Re: umask - default user settings?

. See umask(2) for details. Defaults to 0022 for system units. > > > For user units the default value is inherited from the per-user service > > > manager (whose default is in turn inherited from the system service > > > manager, and thus typically also is 0022 — unless

  1   2   3   4   5   6   7   8   9   10   >