how to prevent /etc/profile.d/ files from returning
Hi, all -- I'm running Leap 15.2 (and this has been happening for a while), and after a round of updates I have to go back to /etc/profile.d and wipe out files that I don't want (alias.bash + ls.bash in particular). Different from adding my own run commands to profile.local.sh thereunder, I want to NOT get the stock stuff. Is there any way to keep them from being dropped again so that I don't have to deal with this over and over? *sigh* TIA & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
On 3/15/21 12:04 PM, David T-G wrote:
Hi, all --
I'm running Leap 15.2 (and this has been happening for a while), and after a round of updates I have to go back to /etc/profile.d and wipe out files that I don't want (alias.bash + ls.bash in particular). Different from adding my own run commands to profile.local.sh thereunder, I want to NOT get the stock stuff.
Is there any way to keep them from being dropped again so that I don't have to deal with this over and over? *sigh*
Not easily I don't think, those files come from aaa_base which is pretty much impossible to remove. I guess the correct approach if someone cared enough to change it is to keep the bits we really need in that package and move the other parts to some form of branding package. But that would take someone who cares enough to do it. I guess eventually it will probably move to /usr/etc/ maybe before Leap 16. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 15.03.2021 07:58, Olaf Hering wrote:
Am Mon, 15 Mar 2021 15:15:48 +1030 schrieb Simon Lees <sflees@suse.de>:
move to /usr/etc/
How would that change anything for the OP?
The whole idea is that files in /etc will then override files in /usr/etc so OP could simply eliminate unwanted scripts by creating empty files in /etc.
The OP should use 'unalias' and 'unset' in his private .profile, .bashrc, .whatever to declare the desired environment.
Olaf
On 3/15/21 3:30 PM, Andrei Borzenkov wrote:
On 15.03.2021 07:58, Olaf Hering wrote:
Am Mon, 15 Mar 2021 15:15:48 +1030 schrieb Simon Lees <sflees@suse.de>:
move to /usr/etc/
How would that change anything for the OP?
The whole idea is that files in /etc will then override files in /usr/etc so OP could simply eliminate unwanted scripts by creating empty files in /etc.
No they will probably supplement them, so his files will need to overwrite the distro ones, but atleast it would have guaranteed execution order which i'm not sure /etc/profile.d does. It would also make it easier to patch out loading them. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Olaf & Simon, et al -- ...and then Olaf Hering said... % % Am Mon, 15 Mar 2021 15:15:48 +1030 % schrieb Simon Lees <sflees@suse.de>: % % > move to /usr/etc/ % % How would that change anything for the OP? That part is true. % % The OP should use 'unalias' and 'unset' in his private .profile, % .bashrc, .whatever to declare the desired environment. Alas, that won't work, because the aliases have already been defined; we're long past the mess by the time personal files have been read. The profile.d/* files are read in shell glob order, so the closest I ever came was thinking about a clever /etc/profile.d/original-script-name-here.off script that grepped the `basename $0 .off` file for definitions and undid each one. That's a pain, though, and by no means guaranteed. Since files I add to /etc/profile.d remain, curiously enough, I can simply wait until I create a shell and see the unwanted behavior, swear once or twice at such stupidity, and manually remove all of the .off basename files. That's also a pain, though :-) Thanks anyway ... and I'm still hoping for a long-term proper fix somehow! :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
On 15/03/2021 11.04, David T-G wrote: ...
script that grepped the `basename $0 .off` file for definitions and undid each one. That's a pain, though, and by no means guaranteed.
Since files I add to /etc/profile.d remain, curiously enough, I can simply wait until I create a shell and see the unwanted behavior, swear once or twice at such stupidity, and manually remove all of the .off basename files. That's also a pain, though :-)
Cronjob. Or add entries to /etc/permissions.local to deny read permission to each file. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Carlos, et al -- ...and then Carlos E. R. said... % % On 15/03/2021 11.04, David T-G wrote: % ... % >once or twice at such stupidity, and manually remove all of the .off % >basename files. That's also a pain, though :-) % % Cronjob. Heh. Also a kludge :-/ % % Or add entries to /etc/permissions.local to deny read permission to % each file. Hmmmmm ... That's very interesting. New to me! I'm gonna have to dig more into that. Thanks! HANN :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
Am Sun, 14 Mar 2021 21:34:15 -0400 schrieb David T-G <davidtg-robot@justpickone.org>:
Is there any way to keep them from being dropped again so that I don't have to deal with this over and over?
They will be hidden, and disappear during boot, with an entry like this in /etc/fstab: profiled /etc/profile.d tmpfs defaults 0 0 Olaf
On 3/14/21 8:34 PM, David T-G wrote:
Is there any way to keep them from being dropped again so that I don't have to deal with this over and over? *sigh*
You probably cannot prevent it -- or not easily. You can create ".bash.expert" to prevent or undo some of what you don't want. I am currently using: ---- .bash.expert ---- unalias -a unset HISTFILE PS1='\u@\h \$ ' ---- end of .bash.expert ----
On 16.03.2021 05:29, Neil Rickert wrote:
On 3/14/21 8:34 PM, David T-G wrote:
Is there any way to keep them from being dropped again so that I don't have to deal with this over and over? *sigh*
You probably cannot prevent it -- or not easily.
You can create ".bash.expert" to prevent or undo some of what you don't want.
It only skips completion settings.
I am currently using:
---- .bash.expert ---- unalias -a unset HISTFILE PS1='\u@\h \$ ' ---- end of .bash.expert ----
Any reason to put it in .bash.expert instead of (at least, documented) .bashrc?
Neil, et al -- ...and then Neil Rickert said... % % On 3/14/21 8:34 PM, David T-G wrote: % > % > Is there any way to keep them from being dropped again so that I don't % > have to deal with this over and over? *sigh* % % You probably cannot prevent it -- or not easily. Yeah *sigh* % % You can create ".bash.expert" to prevent or undo some of what you don't % want. [snip] Yeah, since my alias.bash.off ls.bash.off file never go away, apparently nothing is removed, so if I wrote my little magic parser to unset anything that the `basename $0 .off` files do then I'd be fine ... until I wasn't :-) This just seems like such a flimsy construct overall. It's lovely in many ways, but it isn't flexible enough to do what it's really trying to do. Thanks & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
On 2021/03/14 18:34, David T-G wrote:
Is there any way to keep them from being dropped again so that I don't have to deal with this over and over? *sigh*
I've occasionally had some files that kept being mung'd or replaced. Depending on what you want to do, you could create a directory where the file would go, but many install progs will deleted that. One persistent option I've used. I had some config I wanted to keep in my network area and it kept trying to overwrite it and/or change the name of the device. While I'd solved the prob in earlier releases, it became a case of new features forcing an overwrite. So...I set the immutable bit on the problematic files. So far, that's kept them intact. Another option replace the dir with an empty dir or one that only has the files/changes you want. Then add that to a a disk image that gets mounted read-only. Those are semi-rogue options to protect files. Some might say there should be an OS way to protect them -- and there usually is -- problem is that such a way often changes between releases, so moving your enforcement mechanism out of the way of an update helps.
Linda, et al -- ...and then L A Walsh said... % % On 2021/03/14 18:34, David T-G wrote: % >Is there any way to keep them from being dropped again so that I don't % >have to deal with this over and over? *sigh* ... % % So...I set the immutable bit on the problematic files. % So far, that's kept them intact. [snip] Oooooh! I like that :-) I could zero out the file and then immutable-ify it so that it never comes back. That's even better than setting permissions to 0000, since root can read right through that and the test doesn't look for executability. Time to go learn something :-) Thanks! :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
Hi, all! My, how time flies ... It's been a year since I last wrestled with this! ...and then davidtg-robot@justpickone.org said... % % ...and then L A Walsh said... % % % % On 2021/03/14 18:34, David T-G wrote: % % >Is there any way to keep them from being dropped again so that I don't % % >have to deal with this over and over? *sigh* % ... % % % % So...I set the immutable bit on the problematic files. % % So far, that's kept them intact. % [snip] % ... % % Time to go learn something :-) So I went and learned and played and eventually played davidtg@jpo:~> lsattr /etc/profile.d/ls.bash ----i-------------- /etc/profile.d/ls.bash with some of these keep-coming-back files. They were empty and stayed that way; yay. Except that I actually stood at the keyboard in the closet and paid attention to updates one day and found that various ones threw failures because they couldn't tweak these files. Dang it! No, I don't want failing updates; it's hard enough to make sure things stay current. I guess we're back to adding ls.bash.off that figures out what's in the original file and undoes it as part of the login process *sigh* There really oughta be a better way. Maybe in Leap 16, I heard in the old thread ... Have a great day! :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
participants (7)
-
Andrei Borzenkov -
Carlos E. R. -
David T-G -
L A Walsh -
Neil Rickert -
Olaf Hering -
Simon Lees