[opensuse-factory] Tumbleweed update to 20200201 removed /etc/services
HI! Just a word of warning: The last Tumbleweed update to 20200201 removed /etc/services which e.g. lets postfix startup fail. Is there a work-around installing a new package? Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/4/20 4:56 PM, Michael Ströder wrote:
Just a word of warning: The last Tumbleweed update to 20200201 removed /etc/services which e.g. lets postfix startup fail.
Is there a work-around installing a new package?
Aargh! Could someone ring a bell here before pushing out a serious change like this: https://bugzilla.opensuse.org/show_bug.cgi?id=1162666 Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-02-04 at 16:56 +0100, Michael Ströder wrote:
HI!
Just a word of warning: The last Tumbleweed update to 20200201 removed /etc/services which e.g. lets postfix startup fail.
Is there a work-around installing a new package?
See this thread: https://lists.opensuse.org/opensuse-factory/2020-02/msg00023.html in short: check /etc/nsswitch.conf; you very likely have a .rpmnew lying next to it. Merge the changes. Cheers, Dominique
Am Dienstag, 4. Februar 2020, 17:02:50 CET schrieb Dominique Leuenberger / DimStar:
HI!
Just a word of warning: The last Tumbleweed update to 20200201 removed /etc/services which e.g. lets postfix startup fail.
Is there a work-around installing a new package?
See this thread: https://lists.opensuse.org/opensuse-factory/2020-02/msg00023.html
in short: check /etc/nsswitch.conf; you very likely have a .rpmnew lying next to it. Merge the changes.
Anything a package maintainer needs to do? Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-02-04 at 17:21 +0100, Axel Braun wrote:
in short: check /etc/nsswitch.conf; you very likely have a .rpmnew lying next to it. Merge the changes.
Anything a package maintainer needs to do?
No; this is all on users that ignore .rpmsave and .rpmnew files. well, maybe. If there is ANY package out there that accesses these files directly instead of using the glibc resolver: yell at upstream - and then fix it :) - but so far I haven't seen any such program Cheers, Dominique
Am 04.02.20 um 18:45 schrieb Dominique Leuenberger / DimStar:
On Tue, 2020-02-04 at 17:21 +0100, Axel Braun wrote:
in short: check /etc/nsswitch.conf; you very likely have a .rpmnew lying next to it. Merge the changes.
Anything a package maintainer needs to do?
No; this is all on users that ignore .rpmsave and .rpmnew files.
I did not find any rpmsave or rpmnew that seemed to belong to nscd. Still it does not work strolchi:/etc # telnet server ssh telnet: ssh: bad port strolchi:/etc # systemctl stop nscd strolchi:/etc # telnet server ssh Trying 192.168.200.1... Connected to server. Escape character is '^]'. SSH-2.0-OpenSSH_7.9 ^] telnet> close Connection closed. So what do I need to do to make nscd work again? nsswitch.conf is fixed (I am using the rpmnew file now).
well, maybe. If there is ANY package out there that accesses these files directly instead of using the glibc resolver: yell at upstream - and then fix it :) - but so far I haven't seen any such program Maybe nscd is such a program? -- Stefan Seyfried
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 04.02.20 um 19:06 schrieb Stefan Seyfried:
So what do I need to do to make nscd work again?
OK. Apparmor. Something switched it on again for some reason... -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Seyfried wrote:
Am 04.02.20 um 19:06 schrieb Stefan Seyfried:
So what do I need to do to make nscd work again?
OK. Apparmor. Something switched it on again for some reason...
While it's running here, it seems it still wants to monitor /etc/services, and constantly complains that it cannot find it.... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Dienstag, 4. Februar 2020, 19:14:26 CET schrieb Stefan Seyfried:
Am 04.02.20 um 19:06 schrieb Stefan Seyfried:
So what do I need to do to make nscd work again?
OK. Apparmor. Something switched it on again for some reason...
Silly question - why did you switch it off before? ;-) Please check if you have *.rpmnew files in /etc/apparmor.d/ or /etc/apparmor.d/abstractions/ - one of the latest snapshots included updated abstractions for the /usr/etc/ move. If you don't have any *.rpmnew files and still see problems, please open a bugreport with your /var/log/audit/audit.log (you can grep for "apparmor" if you don't want to attach the whole file). Regards, Christian Boltz -- Also, ich hab mit win3.11 (damals war ich 2 jahre alt) angefangen und hab dann alle Win-versionen erlebt, bis xp. Das war entgültig zuviel. Danach war Schluss. Jetzt nur noch SuSE Linux. [Soeren Wengerowsky in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 05.02.20 um 20:29 schrieb Christian Boltz:
Hello,
Am Dienstag, 4. Februar 2020, 19:14:26 CET schrieb Stefan Seyfried:
Am 04.02.20 um 19:06 schrieb Stefan Seyfried:
So what do I need to do to make nscd work again?
OK. Apparmor. Something switched it on again for some reason...
Silly question - why did you switch it off before? ;-)
Because it always™ breaks something ;-) No, apparently I actually did not disable it after the last reinstall on this machine IIRC, I need to improve my documentation for reinstall to not forget this again ;-)
Please check if you have *.rpmnew files in /etc/apparmor.d/ or /etc/apparmor.d/abstractions/ - one of the latest snapshots included updated abstractions for the /usr/etc/ move.
Exactly. I checked the changelog and even rebooted to make sure everything is fine. strolchi:~ # find /etc -name '*.rpm*' /etc/sysconfig/network/scripts/functions.rpm-utils strolchi:~ #
If you don't have any *.rpmnew files and still see problems, please open a bugreport with your /var/log/audit/audit.log (you can grep for "apparmor" if you don't want to attach the whole file).
It boils down to: type=AVC msg=audit(1580924683.326:179): apparmor="DENIED" operation="open" profile="nscd" name="/usr/etc/services" pid=3405 comm="nscd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 And I don't understand why by reading the apparmor config. But "aa-teardown;systemctl disable apparmor" fixed it for me. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 2020-02-06, 09h04 schreibt Stefan Seyfried:
[...]
If you don't have any *.rpmnew files and still see problems, please open a bugreport with your /var/log/audit/audit.log (you can grep for "apparmor" if you don't want to attach the whole file).
It boils down to:
type=AVC msg=audit(1580924683.326:179): apparmor="DENIED" operation="open" profile="nscd" name="/usr/etc/services" pid=3405 comm="nscd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
And I don't understand why by reading the apparmor config. But "aa-teardown;systemctl disable apparmor" fixed it for me.
I cured the problem by adding a line to /etc/apparmor.d/usr.sbin.nscd : ... /etc/netgroup r, /etc/nscd.conf r, /usr/{bin,sbin}/nscd rmix, # following line added, Gerald Hammer, 2020-02-06 /usr/etc/services r, ... an then loading it in the running apparmor by # apparmor_parser -r /etc/apparmor.d/usr.sbin.nscd On startup nscd continues to complain "stat failed for file `/etc/services';" but this is not a problem. The problems with nfs-server, postfix etc. are gone. Beste Grüße -- Gerald Hammer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Gerald, Am 06.02.20 um 10:44 schrieb Gerald Hammer:
I cured the problem by adding a line to /etc/apparmor.d/usr.sbin.nscd :
... /etc/netgroup r, /etc/nscd.conf r, /usr/{bin,sbin}/nscd rmix, # following line added, Gerald Hammer, 2020-02-06 /usr/etc/services r, ...
an then loading it in the running apparmor by
# apparmor_parser -r /etc/apparmor.d/usr.sbin.nscd
But it already contains #include <abstractions/nameservice> and /etc/apparmor.d/abstractions/nameservice contains /{usr/,}etc/services r, So it is unclear why this is necessary. The whole idea of abstractions/nameservice is that you do not need to put this into every service's rule. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Just had a long conversation with a friend using the i586 version of Tumbleweed. He suffered from a system clock, which was not synchronized. After setting the logical link /etc/services to /usr/etc/services, NTP did again its work. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 06.02.20 um 15:30 schrieb Freek de Kruijf:
Just had a long conversation with a friend using the i586 version of Tumbleweed. He suffered from a system clock, which was not synchronized. After setting the logical link /etc/services to /usr/etc/services, NTP did again its work.
While the workaround might be good for this single case, a better fix would be to a) fix nsswitch.conf b) disable nscd until someone figures why apparmor does not work for it. Because it is well possible that you will not only be missing /etc/services, but also other files/databases that are managed by nsswitch and cached by nscd. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 2020-02-06, 15h07 schreibt Stefan Seyfried:
Hi Gerald,
Am 06.02.20 um 10:44 schrieb Gerald Hammer:
I cured the problem by adding a line to /etc/apparmor.d/usr.sbin.nscd :
... /etc/netgroup r, /etc/nscd.conf r, /usr/{bin,sbin}/nscd rmix, # following line added, Gerald Hammer, 2020-02-06 /usr/etc/services r, ...
an then loading it in the running apparmor by
# apparmor_parser -r /etc/apparmor.d/usr.sbin.nscd
But it already contains
#include <abstractions/nameservice>
and /etc/apparmor.d/abstractions/nameservice contains
/{usr/,}etc/services r,
So it is unclear why this is necessary.
Yes, unclear indeed, maybe a mystery. But it works, at least for me. Of course I started with prayers and some voodoo. But then I read the mailing-list and manuals. And tried my modification of /etc/apparmor.d/usr.sbin.nscd. The result: nfs-server and postfix work like before. To be sure I just repeated the operation on a notebook with the Tumbleweed update. Same result.
The whole idea of abstractions/nameservice is that you do not need to put this into every service's rule.
A deep analysis of the apparmor system is far beyond my competence. I hope someone with better insight will find out what has to be done. Best regards -- Gerald Hammer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Donnerstag, 6. Februar 2020, 09:04:27 CET schrieb Stefan Seyfried:
Am 05.02.20 um 20:29 schrieb Christian Boltz:
Silly question - why did you switch it off before? ;-)
Because it always™ breaks something ;-)
No, apparently I actually did not disable it after the last reinstall on this machine IIRC, I need to improve my documentation for reinstall to not forget this again ;-)
Well, actually you just confirmed what I see whenever I give my "AppArmor Crash Course" talk ;-) I always ask the audience to raise hands if they a) use AppArmor and b) use AppArmor "accidently" (because they use (open)SUSE, Ubuntu, Debian Buster etc.) For b) I usually see at least twice the hands as for a) - which means that AppArmor typically just works in the background, doesn't cause trouble, and most people even don't notice that it's active ;-)
Please check if you have *.rpmnew files in /etc/apparmor.d/ or /etc/apparmor.d/abstractions/ - one of the latest snapshots included updated abstractions for the /usr/etc/ move.
Exactly. I checked the changelog and even rebooted to make sure everything is fine.
OK, the reboot includes reloading the profiles - which would have been my first guess.
If you don't have any *.rpmnew files and still see problems, please open a bugreport with your /var/log/audit/audit.log (you can grep for "apparmor" if you don't want to attach the whole file).
It boils down to:
type=AVC msg=audit(1580924683.326:179): apparmor="DENIED" operation="open" profile="nscd" name="/usr/etc/services" pid=3405 comm="nscd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
And I don't understand why by reading the apparmor config. But "aa-teardown;systemctl disable apparmor" fixed it for me.
Hmm, that's really strange, and shouldn't happen - as you already wrote in a later mail, abstractions/nameservice includes /{usr/,}etc/services r, which should cover this. Just to be sure, please check if rpm -V apparmor-profiles apparmor-abstractions lists any modified files. Usually I don't use nscd [1], but I just started it and let it run for two hours - without a denial in audit.log. (Just wondering, even if your denial is completely strange - do you use a non-default nscd config?) Instead of using aa-teardown, can you please re-enable AppArmor and set the nscd profile into complain (learning) mode? aa-complain /etc/apparmor.d/usr.sbin.nscd (I guess you know what complain mode does, but for the wider audience: complain mode means everything is allowed, and things that would be denied get logged. There's also aa-enforce to switch back to enforce mode.) After having nscd run for a while, check if you get ALLOWED log entries for it. If you don't find an obvious reason for the problem, feel free to send me a tarball of your /etc/apparmor.d/ (off-list), and I'll have a look at it. Regards, Christian Boltz [1] it caches "too much" for me, and since I run a local nameserver, nscd isn't too useful ;-) -- <cboltz> oh, "test is green" fails? nice ;-) <tampakrap> hahahaha yes <tampakrap> we never thought of that scenario [from #opensuse-admin] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 07.02.20 um 23:42 schrieb Christian Boltz:
Hello,
Am Donnerstag, 6. Februar 2020, 09:04:27 CET schrieb Stefan Seyfried:
Am 05.02.20 um 20:29 schrieb Christian Boltz:
Silly question - why did you switch it off before? ;-)
Because it always™ breaks something ;-)
No, apparently I actually did not disable it after the last reinstall on this machine IIRC, I need to improve my documentation for reinstall to not forget this again ;-)
Well, actually you just confirmed what I see whenever I give my "AppArmor Crash Course" talk ;-)
I always ask the audience to raise hands if they a) use AppArmor and b) use AppArmor "accidently" (because they use (open)SUSE, Ubuntu, Debian Buster etc.)
For b) I usually see at least twice the hands as for a) - which means that AppArmor typically just works in the background, doesn't cause trouble, and most people even don't notice that it's active ;-)
Please check if you have *.rpmnew files in /etc/apparmor.d/ or /etc/apparmor.d/abstractions/ - one of the latest snapshots included updated abstractions for the /usr/etc/ move.
Exactly. I checked the changelog and even rebooted to make sure everything is fine.
OK, the reboot includes reloading the profiles - which would have been my first guess.
If you don't have any *.rpmnew files and still see problems, please open a bugreport with your /var/log/audit/audit.log (you can grep for "apparmor" if you don't want to attach the whole file).
It boils down to:
type=AVC msg=audit(1580924683.326:179): apparmor="DENIED" operation="open" profile="nscd" name="/usr/etc/services" pid=3405 comm="nscd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
And I don't understand why by reading the apparmor config. But "aa-teardown;systemctl disable apparmor" fixed it for me.
Hmm, that's really strange, and shouldn't happen - as you already wrote in a later mail, abstractions/nameservice includes /{usr/,}etc/services r, which should cover this.
Just to be sure, please check if rpm -V apparmor-profiles apparmor-abstractions lists any modified files.
strolchi:/etc # rpm -V apparmor-profiles apparmor-abstractions S.5....T. c /etc/apparmor.d/tunables/alias strolchi:/etc # grep -v ^# /etc/apparmor.d/tunables/alias alias /var/lib/libvirt/ -> /space/.vmspace/libvirt/, strolchi:/etc #
Usually I don't use nscd [1], but I just started it and let it run for two hours - without a denial in audit.log. (Just wondering, even if your denial is completely strange - do you use a non-default nscd config?)
I don't think so: strolchi:/etc # rpm -qf /etc/nscd.conf nscd-2.30-2.2.x86_64 strolchi:/etc # rpm -V nscd strolchi:/etc #
Instead of using aa-teardown, can you please re-enable AppArmor and set the nscd profile into complain (learning) mode? aa-complain /etc/apparmor.d/usr.sbin.nscd (I guess you know what complain mode does, but for the wider audience: complain mode means everything is allowed, and things that would be denied get logged. There's also aa-enforce to switch back to enforce mode.)> After having nscd run for a while, check if you get ALLOWED log entries for it.
Now it seems to work, even in enforce mode... ...and that's why I keep apparmor disabled usually ;-) I'm now rebooting to check if it still works after reboot.
[1] it caches "too much" for me, and since I run a local nameserver, nscd isn't too useful ;-)
if you use network based authentication, "no nscd" is not an option. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 08.02.20 um 11:02 schrieb Stefan Seyfried:
Now it seems to work, even in enforce mode... ...and it survived a reboot... -- Stefan Seyfried
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020/02/04 10:06, Stefan Seyfried wrote:
Am 04.02.20 um 18:45 schrieb Dominique Leuenberger / DimStar:
On Tue, 2020-02-04 at 17:21 +0100, Axel Braun wrote:
in short: check /etc/nsswitch.conf; you very likely have a .rpmnew lying next to it. Merge the changes.
Anything a package maintainer needs to do?
No; this is all on users that ignore .rpmsave and .rpmnew files.
But if their system doesn't come up, how will they be able to look at them? Moving the location of standard linux config and administration files from /etc/ (only been there for about 50 years), to /usr has to be one of the less well thought out changes -- only if you have a suse-only system that isn't used for any user or customer purpose where they would have to load and/or configure any non-suse software might this possibly work and even then its a very dangerous move. At the most basic, you are moving away from unix and posix compatibility which will disqualify opensuse as a base for a huge number of applications that need such compatibility. If you are talking opensuse out of the linux/unix/posix compatible category, then you might justify it, but too many non-suse applications expect files in well documented, fixed locations. Again, you break the source of things on 'root' and point symlinks off to /usr which may not even be mounted yet. Suse can claim it doesn't support various user preferences and methodologies that have been used for scores of years, but this has a potential of being noticeably worse than the systemd change-over. I admit to my lack of knowledge here, but is this the path Redhat is taking and sorta not giving Suse a choice if Suse remains a Redhat derivative? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Feb 09, L A Walsh wrote:
On 2020/02/04 10:06, Stefan Seyfried wrote:
Am 04.02.20 um 18:45 schrieb Dominique Leuenberger / DimStar:
On Tue, 2020-02-04 at 17:21 +0100, Axel Braun wrote:
in short: check /etc/nsswitch.conf; you very likely have a .rpmnew lying next to it. Merge the changes. Anything a package maintainer needs to do? No; this is all on users that ignore .rpmsave and .rpmnew files.
But if their system doesn't come up, how will they be able to look at them?
By looking at it before you reboot? Else you can still do a rollback.
Moving the location of standard linux config and administration files from /etc/ (only been there for about 50 years), to /usr has to be one of the less well thought out changes -- only if you have a suse-only system that isn't used for any user or customer purpose where they would have to load and/or configure any non-suse software might this possibly work and even then its a very dangerous move.
No idea since how many years you haven't looked at your system, but many, many distribution provided configuration files are today already widely spread below /usr. The most prominent one is systemd ...
Again, you break the source of things on 'root' and point symlinks off to /usr which may not even be mounted yet.
Mounting /usr after initrd is not supported with openSUSE. So yes, it will not work as of today. -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/02/2020 19.08, Thorsten Kukuk wrote: | On Sun, Feb 09, L A Walsh wrote: ... |> Again, you break the source of things on 'root' and point |> symlinks off to /usr which may not even be mounted yet. | | Mounting /usr after initrd is not supported with openSUSE. So yes, | it will not work as of today. What, are you saying that having /usr on a separate partition is not supported from now on? - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXkKSPQAKCRC1MxgcbY1H 1eczAJ9Y+iGY93NhXR0e3VwMxgyK9f+OowCfa69lu+gaNQ58X7bfK8pne4SQimQ= =6Kjy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 11, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/02/2020 19.08, Thorsten Kukuk wrote: | On Sun, Feb 09, L A Walsh wrote:
...
|> Again, you break the source of things on 'root' and point |> symlinks off to /usr which may not even be mounted yet. | | Mounting /usr after initrd is not supported with openSUSE. So yes, | it will not work as of today.
What, are you saying that having /usr on a separate partition is not supported from now on?
Please read again ... I wrote that mounting /usr after leaving the initrd isn't supported on openSUSE since ages. /usr has to be mounted if you leave the initrd. There is no change with the services file move. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/11/20 12:38 PM, Carlos E. R. wrote:
On 09/02/2020 19.08, Thorsten Kukuk wrote: | On Sun, Feb 09, L A Walsh wrote:
...
|> Again, you break the source of things on 'root' and point |> symlinks off to /usr which may not even be mounted yet. | | Mounting /usr after initrd is not supported with openSUSE. So yes, | it will not work as of today.
What, are you saying that having /usr on a separate partition is not supported from now on?
Nothing changed - /usr needs to be mounted by the initial ramdisk for quite a while already. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/02/2020 13.10, Stephan Kulow wrote:
On 2/11/20 12:38 PM, Carlos E. R. wrote:
On 09/02/2020 19.08, Thorsten Kukuk wrote: | On Sun, Feb 09, L A Walsh wrote:
...
|> Again, you break the source of things on 'root' and point |> symlinks off to /usr which may not even be mounted yet. | | Mounting /usr after initrd is not supported with openSUSE. So yes, | it will not work as of today.
What, are you saying that having /usr on a separate partition is not supported from now on?
Nothing changed - /usr needs to be mounted by the initial ramdisk for quite a while already.
Ah, ok, I understand. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2/10/20 1:09 AM, L A Walsh wrote:
On 2020/02/04 10:06, Stefan Seyfried wrote:
Am 04.02.20 um 18:45 schrieb Dominique Leuenberger / DimStar:
On Tue, 2020-02-04 at 17:21 +0100, Axel Braun wrote:
in short: check /etc/nsswitch.conf; you very likely have a .rpmnew lying next to it. Merge the changes. Anything a package maintainer needs to do? No; this is all on users that ignore .rpmsave and .rpmnew files.
But if their system doesn't come up, how will they be able to look at them?
Moving the location of standard linux config and administration files from /etc/ (only been there for about 50 years), to /usr has to be one of the less well thought out changes -- only if you have a suse-only system that isn't used for any user or customer purpose where they would have to load and/or configure any non-suse software might this possibly work and even then its a very dangerous move. At the most basic, you are moving away from unix and posix compatibility which will disqualify opensuse as a base for a huge number of applications that need such compatibility. If you are talking opensuse out of the linux/unix/posix compatible category, then you might justify it, but too many non-suse applications expect files in well documented, fixed locations.
Again, you break the source of things on 'root' and point symlinks off to /usr which may not even be mounted yet. Suse can claim it doesn't support various user preferences and methodologies that have been used for scores of years, but this has a potential of being noticeably worse than the systemd change-over.
I admit to my lack of knowledge here, but is this the path Redhat is taking and sorta not giving Suse a choice if Suse remains a Redhat derivative?
Well SUSE has never been a Redhat derivative, Redhat is solving the same problem in a different way by moving the files somewhere else, I don't remember where but all the info is in the thread from June titled "RFC: configuration files in /etc" so that is the best place to read if you want to understand why this change exists. -- 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
Hi, I am a new Tumbleweed user, and this update 20200201 removing /etc/services was a charming welcome, as I could not get my mail to work for several days. I actually had to create the /etc/services file from web info ... wondering what else was wrong (I still seem to have bugs), and spent significant time on this. Regarding your explanation as to what should be done : I have 3 nsswitch.conf: -rw-r--r-- 1 root root 1175 Aug 3 2019 nsswitch.conf -rw-r--r-- 1 root root 1144 Jul 16 2019 nsswitch.confbak -rw-r--r-- 1 root root 1189 Jan 24 14:14 nsswitch.conf.rpmnew # diff nsswitch.conf nsswitch.conf.rpmnew 29c29 < hosts: files mdns_minimal [NOTFOUND=return] dns ---
hosts: files dns 32,35c32,35 < services: files < protocols: files < rpc: files < ethers: files
services: files usrfiles protocols: files usrfiles rpc: files usrfiles ethers: files usrfiles 42c42 < aliases: files
aliases: files usrfiles
I do not understand what you mean by "Merge the changes": changes with respect to what ? Does one just replace nsswitch.conf by nsswitch.conf.rpmnew when nsswitch.conf was never modified by the user? Or is nsswitch.confbak the reference, and I should modify nsswitch.conf.rpmnew in the same way nsswitch.conf is derived from nsswitch.confbak, which is the oldest version I have ... though I have no idea regarding the origin of the modification. # diff nsswitch.conf nsswitch.confbak 29c29 < hosts: files mdns_minimal [NOTFOUND=return] dns ---
hosts: files dns
So I have to keep the line hosts: files mdns_minimal [NOTFOUND=return] dns I tried to find more details in the archive, but without success ... it is hard to read all of it in one reading. And I suppose I have to keep a new reference file if more changes occur ... though I am not sure how that works. I know there is significant technical literature on merging code variants (the only name I still have in mind is Tom Reps), and sophisticated techniques ... but I am a bit worried by this solution. Unless I missed the point completely. Cheers Bernard * Dominique Leuenberger / DimStar <dimstar@opensuse.org>, le 04-02-20, a écrit:
See this thread: https://lists.opensuse.org/opensuse-factory/2020-02/msg00023.html
in short: check /etc/nsswitch.conf; you very likely have a .rpmnew lying next to it. Merge the changes.
Cheers, Dominique
-- Bernard.Lang@datcha.net ,_ /\o \o/ mobile +33 6 6206 1693 http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ fixe +33 1 3056 1693 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Bernard Lang <Bernard.Lang@datcha.net> [02-21-20 18:30]:
Hi,
I am a new Tumbleweed user, and this update 20200201 removing /etc/services was a charming welcome, as I could not get my mail to work for several days. I actually had to create the /etc/services file from web info ... wondering what else was wrong (I still seem to have bugs), and spent significant time on this.
Regarding your explanation as to what should be done :
I have 3 nsswitch.conf: -rw-r--r-- 1 root root 1175 Aug 3 2019 nsswitch.conf -rw-r--r-- 1 root root 1144 Jul 16 2019 nsswitch.confbak -rw-r--r-- 1 root root 1189 Jan 24 14:14 nsswitch.conf.rpmnew
# diff nsswitch.conf nsswitch.conf.rpmnew
[...] I am definitely not an expert, but aiui when parameters are changed and the current file (conf) has been altered by ... , an rpmnew file is generated rather than altering the present admin's wishes (the changed conf{ig} file. Then after updating one should check for rpm{new,save} files and update as they wish. I utilize a diff checker, meld, and alter the current conf file to my wishes and rem the rpm{new,save} file. My nsswitch.conf file had never been changed and an rpmnew file *was* generated but was an exact match. I believe a restart should have been indicated and the parameters automagically updated. From the traffic this has generated, seems there are few who completely understood the situation. I had several services which stopped working, dict and nfs and ... I lost nfs between five local boxes and nothing I did would restore it. I finally changed all to sshfs. Today I cheched and found nfs working again. Have not decided whether to revert. good luck. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [02-21-20 18:53]:
* Bernard Lang <Bernard.Lang@datcha.net> [02-21-20 18:30]:
Hi,
I am a new Tumbleweed user, and this update 20200201 removing /etc/services was a charming welcome, as I could not get my mail to work for several days. I actually had to create the /etc/services file from web info ... wondering what else was wrong (I still seem to have bugs), and spent significant time on this.
Regarding your explanation as to what should be done :
I have 3 nsswitch.conf: -rw-r--r-- 1 root root 1175 Aug 3 2019 nsswitch.conf -rw-r--r-- 1 root root 1144 Jul 16 2019 nsswitch.confbak -rw-r--r-- 1 root root 1189 Jan 24 14:14 nsswitch.conf.rpmnew
# diff nsswitch.conf nsswitch.conf.rpmnew
[...]
I am definitely not an expert, but aiui when parameters are changed and the current file (conf) has been altered by ... , an rpmnew file is generated rather than altering the present admin's wishes (the changed conf{ig} file. Then after updating one should check for rpm{new,save} files and update as they wish. I utilize a diff checker, meld, and alter the current conf file to my wishes and rem the rpm{new,save} file.
My nsswitch.conf file had never been changed and an rpmnew file *was* generated but was an exact match. I believe a restart should have been indicated and the parameters automagically updated. From the traffic this has generated, seems there are few who completely understood the situation.
I had several services which stopped working, dict and nfs and ...
I lost nfs between five local boxes and nothing I did would restore it. I finally changed all to sshfs. Today I cheched and found nfs working again. Have not decided whether to revert.
good luck.
ps: rpmconfigcheck will reveal the rpm{new,save} -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zaterdag 22 februari 2020 00:25:44 CET schreef Bernard Lang:
Hi,
I am a new Tumbleweed user, and this update 20200201 removing /etc/services was a charming welcome, as I could not get my mail to work for several days. I actually had to create the /etc/services file from web info ... wondering what else was wrong (I still seem to have bugs), and spent significant time on this.
Regarding your explanation as to what should be done :
I have 3 nsswitch.conf: -rw-r--r-- 1 root root 1175 Aug 3 2019 nsswitch.conf -rw-r--r-- 1 root root 1144 Jul 16 2019 nsswitch.confbak -rw-r--r-- 1 root root 1189 Jan 24 14:14 nsswitch.conf.rpmnew
# diff nsswitch.conf nsswitch.conf.rpmnew 29c29 < hosts: files mdns_minimal [NOTFOUND=return] dns ---
hosts: files dns
32,35c32,35 < services: files < protocols: files < rpc: files < ethers: files ---
services: files usrfiles protocols: files usrfiles rpc: files usrfiles ethers: files usrfiles
42c42 < aliases: files ---
aliases: files usrfiles
I do not understand what you mean by "Merge the changes": changes with respect to what ? Does one just replace nsswitch.conf by nsswitch.conf.rpmnew when nsswitch.conf was never modified by the user?
Or is nsswitch.confbak the reference, and I should modify nsswitch.conf.rpmnew in the same way nsswitch.conf is derived from nsswitch.confbak, which is the oldest version I have ... though I have no idea regarding the origin of the modification.
# diff nsswitch.conf nsswitch.confbak 29c29 < hosts: files mdns_minimal [NOTFOUND=return] dns ---
hosts: files dns
So I have to keep the line hosts: files mdns_minimal [NOTFOUND=return] dns
I tried to find more details in the archive, but without success ... it is hard to read all of it in one reading.
And I suppose I have to keep a new reference file if more changes occur ... though I am not sure how that works. I know there is significant technical literature on merging code variants (the only name I still have in mind is Tom Reps), and sophisticated techniques ... but I am a bit worried by this solution. Unless I missed the point completely.
Cheers
Bernard
* Dominique Leuenberger / DimStar <dimstar@opensuse.org>, le 04-02-20, a écrit:
See this thread: https://lists.opensuse.org/opensuse-factory/2020-02/msg00023.html
in short: check /etc/nsswitch.conf; you very likely have a .rpmnew lying next to it. Merge the changes.
Cheers,
Dominique Looks like, like me, you never changed the packaged default file, in which case it's safe to go: cp /etc/nsswitch.conf /etc/nsswitch,.conf.`date +%F` cp /etc/nsswitch.conf.rpmnew /etc/nsswitch.conf
-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il giorno Sat, 22 Feb 2020 00:54:01 +0100 Knurpht-openSUSE <knurpht@opensuse.org> ha scritto:
cp /etc/nsswitch.conf /etc/nsswitch,.conf.`date +%F`
Or just "old /etc/nsswitch.conf" ("old" is part of aaa_base, which means installed in almost all configurations). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/02/2020 15.13, Luca Beltrame wrote:
Il giorno Sat, 22 Feb 2020 00:54:01 +0100 Knurpht-openSUSE <> ha scritto:
cp /etc/nsswitch.conf /etc/nsswitch,.conf.`date +%F`
Or just "old /etc/nsswitch.conf" ("old" is part of aaa_base, which means installed in almost all configurations).
cer@Telcontar:~> man old No manual entry for old cer@Telcontar:~> cer@Telcontar:~> old usage: /usr/bin/old file|dir [file|dir ...] cer@Telcontar:~> cer@Telcontar:~> old --help --help does not exist. cer@Telcontar:~> No idea what it does... -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Am Sonntag, 23. Februar 2020, 12:49:52 CET schrieb Carlos E. R.:
On 22/02/2020 15.13, Luca Beltrame wrote:
Il giorno Sat, 22 Feb 2020 00:54:01 +0100 Knurpht-openSUSE <> ha scritto:
cp /etc/nsswitch.conf /etc/nsswitch,.conf.`date +%F`
Or just "old /etc/nsswitch.conf" ("old" is part of aaa_base, which means installed in almost all configurations).
cer@Telcontar:~> man old No manual entry for old cer@Telcontar:~> cer@Telcontar:~> old usage: /usr/bin/old file|dir [file|dir ...] cer@Telcontar:~> cer@Telcontar:~> old --help --help does not exist. cer@Telcontar:~>
No idea what it does...
$ whereis old old: /usr/bin/old $ file /usr/bin/old /usr/bin/old: Bourne-Again shell script, ASCII text executable $ vi /usr/bin/old Ahh.. $ old usage: /usr/bin/old file|dir [file|dir ...] Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23/02/2020 13.19, Hans-Peter Jansen wrote:
Am Sonntag, 23. Februar 2020, 12:49:52 CET schrieb Carlos E. R.:
On 22/02/2020 15.13, Luca Beltrame wrote:
Il giorno Sat, 22 Feb 2020 00:54:01 +0100 Knurpht-openSUSE <> ha scritto:
cp /etc/nsswitch.conf /etc/nsswitch,.conf.`date +%F`
Or just "old /etc/nsswitch.conf" ("old" is part of aaa_base, which means installed in almost all configurations).
cer@Telcontar:~> man old No manual entry for old cer@Telcontar:~> cer@Telcontar:~> old usage: /usr/bin/old file|dir [file|dir ...] cer@Telcontar:~> cer@Telcontar:~> old --help --help does not exist. cer@Telcontar:~>
No idea what it does...
$ whereis old old: /usr/bin/old $ file /usr/bin/old /usr/bin/old: Bourne-Again shell script, ASCII text executable $ vi /usr/bin/old Ahh.. $ old usage: /usr/bin/old file|dir [file|dir ...]
I don't see help or explanations... Like $ old This program does .... whatever usage: /usr/bin/old file|dir [file|dir ...] Of course, I can read the code and figure it out. Or try it: cer@Telcontar:~> l p -rw-r--r-- 1 cer users 842 Jan 30 13:31 p cer@Telcontar:~> old p moving p to p-20200223 cer@Telcontar:~> l p-* -rw-r--r-- 1 cer users 842 Jan 30 13:31 p-20200223 -rw-r--r-- 1 cer users 2747 Oct 8 15:37 p-ui cer@Telcontar:~> cer@Telcontar:~> old p.log moving p.log to p.log-20200223 cer@Telcontar:~> I prefer to timestamp with the actual date of the file. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
I agree I had never heard of it ... But it does exist on my computer. I guessed what it should do and tested in a directory created for the purpose. A waste of time ... because the job was just half done by the author. Just having a decent --help is not hard. This command should be improved or junked. Bernard * Carlos E. R. <robin.listas@telefonica.net>, le 23-02-20, a écrit:
On 22/02/2020 15.13, Luca Beltrame wrote:
Il giorno Sat, 22 Feb 2020 00:54:01 +0100 Knurpht-openSUSE <> ha scritto:
cp /etc/nsswitch.conf /etc/nsswitch,.conf.`date +%F`
Or just "old /etc/nsswitch.conf" ("old" is part of aaa_base, which means installed in almost all configurations).
cer@Telcontar:~> man old No manual entry for old cer@Telcontar:~> cer@Telcontar:~> old usage: /usr/bin/old file|dir [file|dir ...] cer@Telcontar:~> cer@Telcontar:~> old --help --help does not exist. cer@Telcontar:~>
No idea what it does...
-- Cheers / Saludos,
Carlos E. R. (from 15.1 x86_64 at Telcontar)
-- Bernard.Lang@datcha.net ,_ /\o \o/ mobile +33 6 6206 1693 http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ fixe +33 1 3056 1693 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
This command should be improved or junked.
I decided to do the work, and got to correct a bug while doing it. But where do I send that. Code checkers are welcome. Bernard ========================================================== #!/bin/bash # # This script simply renames files or directories to <name>-<date>[<num>] # # Copyright (c) 1996-2002 SuSE Linux AG, Nuernberg, Germany. # # Contributor Bernard Lang # # please send bugfixes or comments to http://www.suse.de/feedback. # ^^^ the above line seems obsolete # # # usage - tell user to use program # # Trick : put a nonexistant file name as first argument if you are worried # about the possibility of files called -h or --help # usage() { echo usage: "$0" file\|dir [file\|dir ...] } if [ $# -eq 0 ] ; then usage exit fi if [ $1 = -h -o $1 = --help ] ; then echo 'Renames file or directory <name> given in argument list to <name>-<date>[<num>]' echo 'adding when necessary a suffix number <num> to avoid already used names.' exit fi DATESTRING=`date +"%Y%m%d"` for i in "$@" ; do i=${i%%/} if [ -e "$i" ] ; then NEWNAME=$i-$DATESTRING NUMBER=0 while [ -e "$NEWNAME" ] ; do NEWNAME=$i-$DATESTRING-$NUMBER let NUMBER=$NUMBER+1 done echo moving "$i" to "$NEWNAME" if [ `expr substr "$i" 1 1` = - ] ; then i="./$i" NEWNAME="./NEWNAME" fi mv "$i" "$NEWNAME" else echo "$i" does not exist. fi done ========================================================== * Bernard Lang <Bernard.Lang@datcha.net>, le 23-02-20, a écrit:
I agree
I had never heard of it ... But it does exist on my computer.
I guessed what it should do and tested in a directory created for the purpose.
A waste of time ... because the job was just half done by the author. Just having a decent --help is not hard.
This command should be improved or junked.
Bernard
* Carlos E. R. <robin.listas@telefonica.net>, le 23-02-20, a écrit:
On 22/02/2020 15.13, Luca Beltrame wrote:
Il giorno Sat, 22 Feb 2020 00:54:01 +0100 Knurpht-openSUSE <> ha scritto:
cp /etc/nsswitch.conf /etc/nsswitch,.conf.`date +%F`
Or just "old /etc/nsswitch.conf" ("old" is part of aaa_base, which means installed in almost all configurations).
cer@Telcontar:~> man old No manual entry for old cer@Telcontar:~> cer@Telcontar:~> old usage: /usr/bin/old file|dir [file|dir ...] cer@Telcontar:~> cer@Telcontar:~> old --help --help does not exist. cer@Telcontar:~>
No idea what it does...
-- Cheers / Saludos,
Carlos E. R. (from 15.1 x86_64 at Telcontar)
--
Bernard.Lang@datcha.net ,_ /\o \o/ mobile +33 6 6206 1693 http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ fixe +33 1 3056 1693
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Bernard.Lang@datcha.net ,_ /\o \o/ mobile +33 6 6206 1693 http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ fixe +33 1 3056 1693 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Typo got in the code after I tested. NEWNAME="./NEWNAME" should be NEWNAME="./$NEWNAME" ======================================================================= #!/bin/bash # # This script simply renames files or directories to <name>-<date>[<num>] # # Copyright (c) 1996-2002 SuSE Linux AG, Nuernberg, Germany. # # Contributor Bernard Lang # # please send bugfixes or comments to http://www.suse.de/feedback. # # # usage - tell user to use program # # Trick : put an inexistant file name as first argument if you are worried # about the possibility of files called -h or --help # usage() { echo usage: "$0" file\|dir [file\|dir ...] } if [ $# -eq 0 ] ; then usage exit fi if [ $1 = -h -o $1 = --help ] ; then echo 'Renames file or directory <name> given in argument list to <name>-<date>[<num>]' echo 'adding when necessary a suffix number <num> to avoid already used names.' exit fi DATESTRING=`date +"%Y%m%d"` for i in "$@" ; do i=${i%%/} if [ -e "$i" ] ; then NEWNAME=$i-$DATESTRING NUMBER=0 while [ -e "$NEWNAME" ] ; do NEWNAME=$i-$DATESTRING-$NUMBER let NUMBER=$NUMBER+1 done echo moving "$i" to "$NEWNAME" if [ `expr substr "$i" 1 1` = - ] ; then i="./$i" NEWNAME="./NEWNAME" fi mv "$i" "$NEWNAME" else echo "$i" does not exist. fi done ======================================================================= * Bernard Lang <Bernard.Lang@datcha.net>, le 23-02-20, a écrit:
This command should be improved or junked.
I decided to do the work, and got to correct a bug while doing it.
But where do I send that.
Code checkers are welcome.
Bernard
========================================================== #!/bin/bash
# # This script simply renames files or directories to <name>-<date>[<num>] # # Copyright (c) 1996-2002 SuSE Linux AG, Nuernberg, Germany. # # Contributor Bernard Lang # # please send bugfixes or comments to http://www.suse.de/feedback. # ^^^ the above line seems obsolete # # # usage - tell user to use program # # Trick : put a nonexistant file name as first argument if you are worried # about the possibility of files called -h or --help #
usage() { echo usage: "$0" file\|dir [file\|dir ...] }
if [ $# -eq 0 ] ; then usage exit fi
if [ $1 = -h -o $1 = --help ] ; then echo 'Renames file or directory <name> given in argument list to <name>-<date>[<num>]' echo 'adding when necessary a suffix number <num> to avoid already used names.' exit fi
DATESTRING=`date +"%Y%m%d"`
for i in "$@" ; do i=${i%%/} if [ -e "$i" ] ; then NEWNAME=$i-$DATESTRING NUMBER=0 while [ -e "$NEWNAME" ] ; do NEWNAME=$i-$DATESTRING-$NUMBER let NUMBER=$NUMBER+1 done echo moving "$i" to "$NEWNAME" if [ `expr substr "$i" 1 1` = - ] ; then i="./$i" NEWNAME="./$NEWNAME" fi mv "$i" "$NEWNAME" else echo "$i" does not exist. fi done
==========================================================
* Bernard Lang <Bernard.Lang@datcha.net>, le 23-02-20, a écrit:
I agree
I had never heard of it ... But it does exist on my computer.
I guessed what it should do and tested in a directory created for the purpose.
A waste of time ... because the job was just half done by the author. Just having a decent --help is not hard.
This command should be improved or junked.
Bernard
* Carlos E. R. <robin.listas@telefonica.net>, le 23-02-20, a écrit:
On 22/02/2020 15.13, Luca Beltrame wrote:
Il giorno Sat, 22 Feb 2020 00:54:01 +0100 Knurpht-openSUSE <> ha scritto:
cp /etc/nsswitch.conf /etc/nsswitch,.conf.`date +%F`
Or just "old /etc/nsswitch.conf" ("old" is part of aaa_base, which means installed in almost all configurations).
cer@Telcontar:~> man old No manual entry for old cer@Telcontar:~> cer@Telcontar:~> old usage: /usr/bin/old file|dir [file|dir ...] cer@Telcontar:~> cer@Telcontar:~> old --help --help does not exist. cer@Telcontar:~>
No idea what it does...
-- Cheers / Saludos,
Carlos E. R. (from 15.1 x86_64 at Telcontar)
--
Bernard.Lang@datcha.net ,_ /\o \o/ mobile +33 6 6206 1693 http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ fixe +33 1 3056 1693
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
--
Bernard.Lang@datcha.net ,_ /\o \o/ mobile +33 6 6206 1693 http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ fixe +33 1 3056 1693
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Bernard.Lang@datcha.net ,_ /\o \o/ mobile +33 6 6206 1693 http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ fixe +33 1 3056 1693 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Knurpht-openSUSE <knurpht@opensuse.org>, le 22-02-20, a écrit:
Looks like, like me, you never changed the packaged default file, in which case it's safe to go: cp /etc/nsswitch.conf /etc/nsswitch,.conf.`date +%F` cp /etc/nsswitch.conf.rpmnew /etc/nsswitch.conf
Thanks for all answers. They seem to suggest that I should consider that my /etc/nsswitch.conf was never edited, and that I should therefore simply replace it by the file nsswitch.conf.rpmnew, as explained, e.g., in "Dealing with .rpmnew and .rpmsave files" located at https://www.linux.com/news/dealing-rpmnew-and-rpmsave-files/ However the info in my post shows a third file, nsswitch.confbak with a date older than nsswitch.conf and nsswitch.conf.rpmnew Though I did not do any editing myself, I have to assume that some modification must have been done by/for some piece of software ... hopefully for a good reason, renaming the original file nsswitch.confbak, and keeping the modified file as nsswitch.conf. This modification concerns the file /etc/hosts which was changed from hosts: files dns in line 29 of nsswitch.confbak to hosts: files mdns_minimal [NOTFOUND=return] dns in line 29 of nsswitch.conf (see # diff nsswitch.conf nsswitch.confbak) It is also clear that this change was not applied to the new file nsswitch.conf.rpmnew. So my guess is that I should indeed make a merge by changing accordingly nsswitch.conf.rpmnew, replacing its line 29 with that of file nsswitch.conf to preserve the change made for /etc/hosts But I would feel more comfortable if I really understood what the change does. As I understand it from reading comments in /etc/nsswitch.conf it restricts hosts to local information given by /etc/hosts and mdns_minimal (/usr/lib64/libnss_mdns_minimal.so.2), unless mdns_minimal is missing (to keep it simple), thus ignoring dns. But why do this? And why not document/comment the change? It actually bothers me that there is not more formalized support for keeping older versions of the files, with comments justifying the changes, so that merging versions could be made safely enough. What should I do if I did not have the old file nsswitch.confbak. ... Though I am not sure I like what I am doing. It is not unfrequent that a configuration created by une user has to be later maintained by another one, who does not know everything about it. This should be supported (not a criticism of SUSE). Bernard -- Bernard.Lang@datcha.net ,_ /\o \o/ mobile +33 6 6206 1693 http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ fixe +33 1 3056 1693 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/02/2020 23.45, Bernard Lang wrote:
* Knurpht-openSUSE <>, le 22-02-20, a écrit:
Looks like, like me, you never changed the packaged default file, in which case it's safe to go: cp /etc/nsswitch.conf /etc/nsswitch,.conf.`date +%F` cp /etc/nsswitch.conf.rpmnew /etc/nsswitch.conf
Thanks for all answers. They seem to suggest that I should consider that my /etc/nsswitch.conf was never edited, and that I should therefore simply replace it by the file nsswitch.conf.rpmnew, as explained, e.g., in "Dealing with .rpmnew and .rpmsave files" located at https://www.linux.com/news/dealing-rpmnew-and-rpmsave-files/
However the info in my post shows a third file, nsswitch.confbak with a date older than nsswitch.conf and nsswitch.conf.rpmnew
Though I did not do any editing myself, I have to assume that some modification must have been done by/for some piece of software ... hopefully for a good reason, renaming the original file nsswitch.confbak, and keeping the modified file as nsswitch.conf.
Maybe YaST :-? ...
It is not unfrequent that a configuration created by une user has to be later maintained by another one, who does not know everything about it. This should be supported (not a criticism of SUSE).
So you write comments explaining each change you do. You can not force others to do the same... unfortunately >:-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sat, Feb 22, Bernard Lang wrote:
# diff nsswitch.conf nsswitch.conf.rpmnew 29c29 < hosts: files mdns_minimal [NOTFOUND=return] dns ---
hosts: files dns 32,35c32,35 < services: files
The question is: why is here only "files" and not "files usrfiles"? Didn't you apply all updates? There should be "files usrfiles" independent of your *.rpmnew file. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Thorsten,
The question is: why is here only "files" and not "files usrfiles"? Didn't you apply all updates? There should be "files usrfiles" independent of your *.rpmnew file.
As far as I know, I apply all updates, though not always with small time intervals. I am not sophisticated enough as a user to be fussy about it. But I did not know I should look for rpm{new, save} every time (why not include it in the update procedure, or give a warning message when it has to be done). Also, I do not understand why I should have "files usrfiles" without having had to play the rpm{new, save} game sometimes earlier. And since I am not the only one who had problems, my guess is that many other people are in the same situation. Unless I misunderstand your question. Bernard * Thorsten Kukuk <kukuk@suse.de>, le 22-02-20, a écrit:
On Sat, Feb 22, Bernard Lang wrote:
# diff nsswitch.conf nsswitch.conf.rpmnew 29c29 < hosts: files mdns_minimal [NOTFOUND=return] dns ---
hosts: files dns 32,35c32,35 < services: files
The question is: why is here only "files" and not "files usrfiles"? Didn't you apply all updates? There should be "files usrfiles" independent of your *.rpmnew file.
Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Bernard.Lang@datcha.net ,_ /\o \o/ mobile +33 6 6206 1693 http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ fixe +33 1 3056 1693 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Feb 22, Bernard Lang wrote:
Also, I do not understand why I should have "files usrfiles" without having had to play the rpm{new, save} game sometimes earlier.
Because we modify /etc/nsswitch.conf during update to add this parameter if necessary, and this didn't seem to work for you.
And since I am not the only one who had problems, my guess is that many other people are in the same situation.
People tend to simply and claim this is the reason for their problem while it is not. If you read carefully, there are quite some people, who did revert the change and it still did not work for them. So "usrfiles" has nothing to do with their problem even if they claim so. E.g. the NFS problems are more likely related to the nfs update at the same time, /etc/nfs.conf gives for me syntax errors since them. That's why it is important to find to root cause for every problem and not assume it's all the same. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Thorsten Kukuk <kukuk@suse.de>, on 23-02-20, wrote:
On Sat, Feb 22, Bernard Lang wrote:
Also, I do not understand why I should have "files usrfiles" without having had to play the rpm{new, save} game sometimes earlier.
Because we modify /etc/nsswitch.conf during update to add this parameter if necessary, and this didn't seem to work for you.
I am not sure I understand ... you modify it during update, and then unmodify it when the update is finished? Because the whole purpose of nsswitch.conf.rpmnew is to avoid modifying without precautions nsswitch.conf ... if I understand correstly.
And since I am not the only one who had problems, my guess is that many other people are in the same situation.
People tend to simply and claim this is the reason for their problem while it is not.
yes, but some seemed to have exactly the same symptoms.
That's why it is important to find to root cause for every problem and not assume it's all the same.
That is why I spend so much time describing what happened to me, with my suggestions ... for my benefit and for the benefit of the community (it is the same in my mind). Bernard
Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Bernard.Lang@datcha.net ,_ /\o \o/ mobile +33 6 6206 1693 http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ fixe +33 1 3056 1693 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (18)
-
Axel Braun -
Bernard Lang -
Carlos E. R. -
Christian Boltz -
Dominique Leuenberger / DimStar -
Freek de Kruijf -
Gerald Hammer -
Hans-Peter Jansen -
Knurpht-openSUSE -
L A Walsh -
Luca Beltrame -
Michael Ströder -
Patrick Shanahan -
Peter Suetterlin -
Simon Lees -
Stefan Seyfried -
Stephan Kulow -
Thorsten Kukuk