Re: [CentOS] Latest firefox upgrade crashes

2024-01-25 Thread Simon Matter
Hi,

> I guess you'll find I lot of old-schoolers among those still using CentOS
> 7.
> I've realised I'm one of them, and I'm proud of it :-) Getting to know how
> and
> / or why is how we keep learning instead of just doing. I'm still hoping
> for
> it to become trendy :-D
>
> Have you tried to see if your profiles works with firefox in another
> distribution?

I had to go on with this and found a solution: I had two FF windows open
with ~20 tabs on each of them. I've closed one of them with the less
important tabs. In this configuration I was able to perform the update and
all seems well.

Maybe there was a single tab there which FF did not like. It seems to work
now.

Regards,
Simon

>
> Regards, Christer
>
> On Wednesday 24 January 2024 14:39:05 Simon Matter wrote:
>> > I did a quick search to see if there were any SQlite related changes
>> to
>> > 115.6.0; I could find anything. If I understand you correctly, you
>> > frequently
>> > generate places.sqlite and push it to the users. Could there be any
>> > change in
>> > file format? Some version conflict between the tool you use to
>> generate
>>
>> The places.sqlite is one of a few files which is synced from a template
>> profile nightly.
>>
>> But, to start with I tested the update with my own private profile which
>> is not synced in any way. Just a standard profile with my settings, two
>> windows with a number of tabs and 3 extensions (ublock, google analytics
>> opt-out and I still don't want cookies). This profile has been in use
>> for
>> over a decade and this is the first time it fails on a new Firefox
>> version.
>>
>> I'll report if I find out more. I know I'm a bit old-school because I
>> would like to know why things break instead of just creating a new
>> profile
>>
>> :)
>>
>> Simon
>>
>> > the
>> > config file(s) and the current firefox included version? IIRC there
>> was a
>> > SQlite security fix for some read related function in december. Any
>> > relevant
>> > changes there going into firefox? Hope these suggestions can help you
>> > further.
>> > Good luck, and please let us know if you find a solution.
>> >
>> > Regards, Christer
>> >
>> > On Wednesday 24 January 2024 09:01:18 Simon Matter wrote:
>> >> > The message
>> >> > "ATTENTION: default value of option mesa_glthread overridden by
>> >> > environment."
>> >> > is most likely caused by firefox overriding the env var to _avoid_
>> a
>> >> > crash:
>> >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1744389
>> >> > It's an old but unclosed bug, focusing on getting rid of the
>> warning,
>> >>
>> >> so
>> >>
>> >> > unsure whether this is in any way relevant to your problem.
>> >>
>> >> Thanks, I think it has nothing to do with the crashes I see.
>> >>
>> >> I found out that Firefox doesn't like the current state of open
>> >> windows/tabs. Even running with a new empty profile where I first
>> copied
>> >> places.sqlite from the existing session does result in the crashes.
>> I'm
>> >> still trying to find out if starting with a new empty profile makes
>> >> everything work again or not. I mean, if I open all the windows/tabs
>> >> again
>> >> by hand, will it then work or also start crashing again? Since this
>> is a
>> >> controlled environment where we push several configs files to the
>> >> profiles
>> >> nightly, it's a bit more complicated than to just "start with a fresh
>> >> profile".
>> >>
>> >> Simon
>> >>
>> >> > Regards, Christer
>> >> >
>> >> > On Friday 19 January 2024 19:07:51 Simon Matter wrote:
>> >> >> > The first lines ("... No marshaller ...") I see on my terminal
>> too,
>> >> >>
>> >> >> with
>> >> >>
>> >> >> > a working firefox. I has been that way for I don't know how long
>> >> >>
>> >> >> (_many_
>> >> >>
>> >> >> > releases).
>> >> >> > In addition I get repeated output of this line:
>> >> >> > "firefox:): GLib-GObject-CRITICAL **: HH:MM:SS.NNN:
>> >>
>> >> g_object_ref:
>> >> >> > a

Re: [CentOS] Latest firefox upgrade crashes

2024-01-24 Thread Simon Matter
> I did a quick search to see if there were any SQlite related changes to
> 115.6.0; I could find anything. If I understand you correctly, you
> frequently
> generate places.sqlite and push it to the users. Could there be any change
> in
> file format? Some version conflict between the tool you use to generate

The places.sqlite is one of a few files which is synced from a template
profile nightly.

But, to start with I tested the update with my own private profile which
is not synced in any way. Just a standard profile with my settings, two
windows with a number of tabs and 3 extensions (ublock, google analytics
opt-out and I still don't want cookies). This profile has been in use for
over a decade and this is the first time it fails on a new Firefox
version.

I'll report if I find out more. I know I'm a bit old-school because I
would like to know why things break instead of just creating a new profile
:)

Simon

> the
> config file(s) and the current firefox included version? IIRC there was a
> SQlite security fix for some read related function in december. Any
> relevant
> changes there going into firefox? Hope these suggestions can help you
> further.
> Good luck, and please let us know if you find a solution.
>
> Regards, Christer
>
> On Wednesday 24 January 2024 09:01:18 Simon Matter wrote:
>> > The message
>> > "ATTENTION: default value of option mesa_glthread overridden by
>> > environment."
>> > is most likely caused by firefox overriding the env var to _avoid_ a
>> > crash:
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1744389
>> > It's an old but unclosed bug, focusing on getting rid of the warning,
>> so
>> > unsure whether this is in any way relevant to your problem.
>>
>> Thanks, I think it has nothing to do with the crashes I see.
>>
>> I found out that Firefox doesn't like the current state of open
>> windows/tabs. Even running with a new empty profile where I first copied
>> places.sqlite from the existing session does result in the crashes. I'm
>> still trying to find out if starting with a new empty profile makes
>> everything work again or not. I mean, if I open all the windows/tabs
>> again
>> by hand, will it then work or also start crashing again? Since this is a
>> controlled environment where we push several configs files to the
>> profiles
>> nightly, it's a bit more complicated than to just "start with a fresh
>> profile".
>>
>> Simon
>>
>> > Regards, Christer
>> >
>> > On Friday 19 January 2024 19:07:51 Simon Matter wrote:
>> >> > The first lines ("... No marshaller ...") I see on my terminal too,
>> >>
>> >> with
>> >>
>> >> > a working firefox. I has been that way for I don't know how long
>> >>
>> >> (_many_
>> >>
>> >> > releases).
>> >> > In addition I get repeated output of this line:
>> >> > "firefox:): GLib-GObject-CRITICAL **: HH:MM:SS.NNN:
>> g_object_ref:
>> >> > assertion 'G_IS_OBJECT (object)' failed
>> >> > [Parent , Main Thread] WARNING: g_object_ref: assertion
>> >>
>> >> 'G_IS_OBJECT
>> >>
>> >> > (object)' failed: 'glib warning', file
>> >> > /builddir/build/BUILD/firefox-115.6.0/toolkit/xre/nsSigHandlers.cpp:16
>> >> >7"
>> >> >
>> >> > Do you know why the default value of mesa_glthread is overridden?
>> >>
>> >> Might
>> >>
>> >> > be worth looking at, as /usr/lib64/dri/swrast_dri.so involved in
>> the
>> >> > crash belongs to package mesa-dri-drivers-18.3.4-12.el7_9.x86_64.
>> >>
>> >> Might
>> >>
>> >> > be a relation, but I'm not very knowledgeable about these
>> >>
>> >> configurations.
>> >>
>> >> > Maybe try
>> >> > "yum reinstall mesa-dri-drivers", I guess it will warn about not
>> >> > replacing the
>> >> > config file, but instead create a config file whose name ends with
>> >> > ".rpmnew".
>> >> > Then you can compare and maybe see if it works with the default
>> >>
>> >> config.
>> >>
>> >> Running "rpm -V mesa-dri-drivers" shows no output which means nothing
>> >> has
>> >> fiddled with its config file.
>> >>
>> >> Of course I'm still wondering why this message is shown.
>

Re: [CentOS] Latest firefox upgrade crashes

2024-01-24 Thread Simon Matter
> The message
> "ATTENTION: default value of option mesa_glthread overridden by
> environment."
> is most likely caused by firefox overriding the env var to _avoid_ a
> crash:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1744389
> It's an old but unclosed bug, focusing on getting rid of the warning, so
> unsure whether this is in any way relevant to your problem.

Thanks, I think it has nothing to do with the crashes I see.

I found out that Firefox doesn't like the current state of open
windows/tabs. Even running with a new empty profile where I first copied
places.sqlite from the existing session does result in the crashes. I'm
still trying to find out if starting with a new empty profile makes
everything work again or not. I mean, if I open all the windows/tabs again
by hand, will it then work or also start crashing again? Since this is a
controlled environment where we push several configs files to the profiles
nightly, it's a bit more complicated than to just "start with a fresh
profile".

Simon

>
> Regards, Christer
>
> On Friday 19 January 2024 19:07:51 Simon Matter wrote:
>> > The first lines ("... No marshaller ...") I see on my terminal too,
>> with
>> > a working firefox. I has been that way for I don't know how long
>> (_many_
>> > releases).
>> > In addition I get repeated output of this line:
>> > "firefox:): GLib-GObject-CRITICAL **: HH:MM:SS.NNN: g_object_ref:
>> > assertion 'G_IS_OBJECT (object)' failed
>> > [Parent , Main Thread] WARNING: g_object_ref: assertion
>> 'G_IS_OBJECT
>> > (object)' failed: 'glib warning', file
>> > /builddir/build/BUILD/firefox-115.6.0/toolkit/xre/nsSigHandlers.cpp:167"
>> >
>> > Do you know why the default value of mesa_glthread is overridden?
>> Might
>> > be worth looking at, as /usr/lib64/dri/swrast_dri.so involved in the
>> > crash belongs to package mesa-dri-drivers-18.3.4-12.el7_9.x86_64.
>> Might
>> > be a relation, but I'm not very knowledgeable about these
>> configurations.
>> > Maybe try
>> > "yum reinstall mesa-dri-drivers", I guess it will warn about not
>> > replacing the
>> > config file, but instead create a config file whose name ends with
>> > ".rpmnew".
>> > Then you can compare and maybe see if it works with the default
>> config.
>>
>> Running "rpm -V mesa-dri-drivers" shows no output which means nothing
>> has
>> fiddled with its config file.
>>
>> Of course I'm still wondering why this message is shown.
>>
>> Regards,
>> Simon
>>
>> > Regards, Christer
>> >
>> > On Thursday 18 January 2024 21:07:00 Simon Matter wrote:
>> >> The list seems to strip even text files. Here it is:
>> >>
>> >> $ firefox
>> >> [Parent 3932877, Main Thread] WARNING: No marshaller for signature of
>> >>  signal 'PropertiesChanged': 'glib warning', file
>> >> /builddir/build/BUILD/firefox-115.6.0/toolkit/xre/nsSigHandlers.cpp:167
>> >>
>> >> ** (firefox:3932877): WARNING **: 18:38:25.125: No marshaller for
>> >> signature of
>> >> signal 'PropertiesChanged'
>> >> ATTENTION: default value of option mesa_glthread overridden by
>> >> environment.
>> >> ATTENTION: default value of option mesa_glthread overridden by
>> >> environment.
>> >> *** stack smashing detected ***: /usr/lib64/firefox/firefox
>> terminated
>> >> === Backtrace: =
>> >> /lib64/libc.so.6(__fortify_fail+0x37)[0x7f499197c7a7]
>> >> /lib64/libc.so.6(+0x118762)[0x7f499197c762]
>> >> /usr/lib64/dri/swrast_dri.so(+0x152b65)[0x7f493965cb65]
>> >> /usr/lib64/dri/swrast_dri.so(+0x20f5e0)[0x7f49397195e0]
>> >> /usr/lib64/dri/swrast_dri.so(+0x21021b)[0x7f493971a21b]
>> >> /usr/lib64/dri/swrast_dri.so(+0x27ba74)[0x7f4939785a74]
>> >> /usr/lib64/dri/swrast_dri.so(+0x27d6c3)[0x7f49397876c3]
>> >> /usr/lib64/dri/swrast_dri.so(+0x1fe2c5)[0x7f49397082c5]
>> >> /usr/lib64/dri/swrast_dri.so(+0x1ff890)[0x7f4939709890]
>> >> /usr/lib64/firefox/libxul.so(+0x16d113b)[0x7f497eb4b13b]
>> >> /usr/lib64/firefox/libxul.so(+0x2851927)[0x7f497fccb927]
>> >> /usr/lib64/firefox/libxul.so(+0x2777d9d)[0x7f497fbf1d9d]
>> >> /usr/lib64/firefox/libxul.so(+0x2855bb8)[0x7f497fccfbb8]
>> >> /usr/lib64/firefox/libxul.so(+0x27f8630)[0x7f497fc72630]
>> >> /usr/lib64/firefox/libxul.so(+0x2827fe9)[0x7f497fca1fe9]
>> >> /usr/

Re: [CentOS] Latest firefox upgrade crashes

2024-01-19 Thread Simon Matter
> The first lines ("... No marshaller ...") I see on my terminal too, with a
> working firefox. I has been that way for I don't know how long (_many_
> releases).
> In addition I get repeated output of this line:
> "firefox:): GLib-GObject-CRITICAL **: HH:MM:SS.NNN: g_object_ref:
> assertion 'G_IS_OBJECT (object)' failed
> [Parent , Main Thread] WARNING: g_object_ref: assertion 'G_IS_OBJECT
> (object)' failed: 'glib warning', file
> /builddir/build/BUILD/firefox-115.6.0/toolkit/xre/nsSigHandlers.cpp:167"
>
> Do you know why the default value of mesa_glthread is overridden? Might be
> worth looking at, as /usr/lib64/dri/swrast_dri.so involved in the crash
> belongs to package mesa-dri-drivers-18.3.4-12.el7_9.x86_64. Might be a
> relation, but I'm not very knowledgeable about these configurations. Maybe
> try
> "yum reinstall mesa-dri-drivers", I guess it will warn about not replacing
> the
> config file, but instead create a config file whose name ends with
> ".rpmnew".
> Then you can compare and maybe see if it works with the default config.

Running "rpm -V mesa-dri-drivers" shows no output which means nothing has
fiddled with its config file.

Of course I'm still wondering why this message is shown.

Regards,
Simon

>
> Regards, Christer
>
> On Thursday 18 January 2024 21:07:00 Simon Matter wrote:
>> The list seems to strip even text files. Here it is:
>>
>> $ firefox
>> [Parent 3932877, Main Thread] WARNING: No marshaller for signature of
>>  signal 'PropertiesChanged': 'glib warning', file
>> /builddir/build/BUILD/firefox-115.6.0/toolkit/xre/nsSigHandlers.cpp:167
>>
>> ** (firefox:3932877): WARNING **: 18:38:25.125: No marshaller for
>> signature of
>> signal 'PropertiesChanged'
>> ATTENTION: default value of option mesa_glthread overridden by
>> environment.
>> ATTENTION: default value of option mesa_glthread overridden by
>> environment.
>> *** stack smashing detected ***: /usr/lib64/firefox/firefox terminated
>> === Backtrace: =
>> /lib64/libc.so.6(__fortify_fail+0x37)[0x7f499197c7a7]
>> /lib64/libc.so.6(+0x118762)[0x7f499197c762]
>> /usr/lib64/dri/swrast_dri.so(+0x152b65)[0x7f493965cb65]
>> /usr/lib64/dri/swrast_dri.so(+0x20f5e0)[0x7f49397195e0]
>> /usr/lib64/dri/swrast_dri.so(+0x21021b)[0x7f493971a21b]
>> /usr/lib64/dri/swrast_dri.so(+0x27ba74)[0x7f4939785a74]
>> /usr/lib64/dri/swrast_dri.so(+0x27d6c3)[0x7f49397876c3]
>> /usr/lib64/dri/swrast_dri.so(+0x1fe2c5)[0x7f49397082c5]
>> /usr/lib64/dri/swrast_dri.so(+0x1ff890)[0x7f4939709890]
>> /usr/lib64/firefox/libxul.so(+0x16d113b)[0x7f497eb4b13b]
>> /usr/lib64/firefox/libxul.so(+0x2851927)[0x7f497fccb927]
>> /usr/lib64/firefox/libxul.so(+0x2777d9d)[0x7f497fbf1d9d]
>> /usr/lib64/firefox/libxul.so(+0x2855bb8)[0x7f497fccfbb8]
>> /usr/lib64/firefox/libxul.so(+0x27f8630)[0x7f497fc72630]
>> /usr/lib64/firefox/libxul.so(+0x2827fe9)[0x7f497fca1fe9]
>> /usr/lib64/firefox/libxul.so(+0x282f97a)[0x7f497fca997a]
>> /usr/lib64/firefox/libxul.so(+0x2862576)[0x7f497fcdc576]
>> /usr/lib64/firefox/libxul.so(+0x1958366)[0x7f497edd2366]
>> /usr/lib64/firefox/libxul.so(+0x138f230)[0x7f497e809230]
>> /usr/lib64/firefox/libxul.so(+0x139832d)[0x7f497e81232d]
>> /usr/lib64/firefox/libxul.so(+0x1398c43)[0x7f497e812c43]
>> /usr/lib64/firefox/libxul.so(+0x1398db7)[0x7f497e812db7]
>> /usr/lib64/firefox/libxul.so(+0xc8cfe2)[0x7f497e106fe2]
>> /usr/lib64/firefox/libxul.so(+0xc7866b)[0x7f497e0f266b]
>> /usr/lib64/firefox/libxul.so(+0x138540a)[0x7f497e7ff40a]
>> /usr/lib64/firefox/libxul.so(+0x1333fc5)[0x7f497e7adfc5]
>> /usr/lib64/firefox/libxul.so(+0xc8c699)[0x7f497e106699]
>> /lib64/libnspr4.so(+0x28f7b)[0x7f49907dff7b]
>> /lib64/libpthread.so.0(+0x7ea5)[0x7f499265dea5]
>> /lib64/libc.so.6(clone+0x6d)[0x7f4991962b0d]
>> === Memory map: 
>> 126e30-126e40 rw-p  00:00 0
>> 56dfc0-56dfd0 rw-p  00:00 0
>> 1715220-1715230 rw-p  00:00 0
>> 2c62f60-2c62f70 rw-p  00:00 0
>> 2cf7cb0-2cf7cc0 rw-p  00:00 0
>> 3eb4b40-3eb4b50 rw-p  00:00 0
>> 4b75c30-4b75c40 rw-p  00:00 0
>> 543f090-543f0a0 rw-p  00:00 0
>> 5d99720-5d99730 rw-p  00:00 0
>> 6755310-6755320 rw-p  00:00 0
>> 67dbaf0-67dbb00 rw-p  00:00 0
>> a1368e0-a1368f0 rw-p  00:00 0
>> e866ef18000-e866ef26000 r-xp  00:00 0
>> e866ef26000-e866ef28000 r-xp  00:00 0
>> e866ef28000-e866ef38000 ---p  00:00 0
>> e

Re: [CentOS] Latest firefox upgrade crashes

2024-01-18 Thread Simon Matter
> Hi,
>
> On Thu, Jan 18, 2024 at 06:47:54PM +0100, Simon Matter wrote:
> ..
>> Yes I do see the same issue after upgrading to
>> firefox-115.6.0-1.el7.centos.
>>
>> It's just unusable now, don't understand how this got released :(
>
> It is working fine for us (firefox-115.6.0-1.el7.centos.x86_64).
>
> Maybe you can try with a fresh profile?
> $ firefox --ProfileManager

Thanks for confirming that it works for you.
Sure I'll try with a fresh profile and do other tests like manually
disabling hardware acceleration and so.
Problem is, this is on a terminal serving host with tens of connected
desktop users working almost around the clock so I can't just upgrade
again and play with it without disturbing business.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Latest firefox upgrade crashes

2024-01-18 Thread Simon Matter
  00:00 0
7f494400-7f4944002000 rw-p  00:00 0
7f4944002000-7f4944003000 ---p  00:00 0
7f4944003000-7f49440ff000 rw-p  00:00 0
7f49440ff000-7f494410 ---p  00:00 0
7f494410-7f4944102000 rw-p  00:00 0
7f4944102000-7f4944103000 ---p  00:00 0
7f4944103000-7f49441ff000 rw-p  00:00 0
7f49441ff000-7f494420 ---p  00:00 0
7f494420-7f4944202000 rw-p  00:00 0
7f4944202000-7f4944203000 ---p  00:00 0
7f4944203000-7f49442ff000 rw-p  00:00 0
7f49442ff000-7f494430 ---p  00:00 0
7f494430-7f4944302000 rw-p  00:00 0
7f4944302000-7f4944303000 ---p  00:00 0
7f4944303000-7f49443ff000 rw-p  00:00 0
7f49443ff000-7f494440 ---p  00:00 0
7f494440-7f4944402000 rw-p  00:00 0
7f4944402000-7f4944403000 ---p  00:00 0
7f4944403000-7f49444ff000 rw-p  00:00 0
7f49444ff000-7f494450 ---p  00:00 0
7f494450-7f4944502000 rw-p  00:00 0
7f4944502000-7f4944503000 ---p  00:00 0
7f4944503000-7f49445ff000 rw-p  00:00 0
7f49445ff000-7f494460 ---p  00:00 0
7f494460-7f4944602000 rw-p  00:00 0
7f4944602000-7f4944603000 ---p  00:00 0
7f4944603000-7f49446ff000 rw-p  00:00 0
7f49446ff000-7f494470 ---p  00:00 0
7f494470-7f4944702000 rw-p  00:00 0
7f4944702000-7f4944703000 ---p  00:00 0
7f4944703000-7f49447ff000 rw-p  00:00 0
7f49447ff000-7f494480 ---p  00:00 0 Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]:
CompositorBridgeChild receives
IPC close with reason=AbnormalShutdown (t=25.4368) [GFX1-]:
CompositorBridgeChild
receives IPC close with reason=AbnormalShutdown
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]:
CompositorBridgeChild receives
IPC close with reason=AbnormalShutdown (t=24.5542) [GFX1-]:
CompositorBridgeChild
receives IPC close with reason=AbnormalShutdown
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Aborted
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.

>
> Regards, Christer
>
> On Thursday 18 January 2024 19:06:10 Simon Matter wrote:
>> > Hi,
>> >
>> >> I'm still using CentOS 7 (because the stream sucks). Recently there
>> >> was a yum upgrade for firefox. I had to downgrade to the previous
>> >> version because the latest version keeps crashing. Anyone else
>> >> experience this?
>> >
>> > Yes I do see the same issue after upgrading to
>> > firefox-115.6.0-1.el7.centos.
>> >
>> > It's just unusable now, don't understand how this got released :(
>>
>> Attached is the console output of when running Firefox.
>>
>> Does anyone have an idea what's going on?
>>
>> Simon
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Latest firefox upgrade crashes

2024-01-18 Thread Simon Matter
> Hi,
>
>> I'm still using CentOS 7 (because the stream sucks). Recently there
>> was a yum upgrade for firefox. I had to downgrade to the previous
>> version because the latest version keeps crashing. Anyone else
>> experience this?
>>
>
> Yes I do see the same issue after upgrading to
> firefox-115.6.0-1.el7.centos.
>
> It's just unusable now, don't understand how this got released :(

Attached is the console output of when running Firefox.

Does anyone have an idea what's going on?

Simon
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Latest firefox upgrade crashes

2024-01-18 Thread Simon Matter
Hi,

> I'm still using CentOS 7 (because the stream sucks). Recently there
> was a yum upgrade for firefox. I had to downgrade to the previous
> version because the latest version keeps crashing. Anyone else
> experience this?
>

Yes I do see the same issue after upgrading to firefox-115.6.0-1.el7.centos.

It's just unusable now, don't understand how this got released :(

Regards,
Simon


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] resetting a serial port

2023-12-14 Thread Simon Matter
Hi,

> I have Centos 7 arm32 running on a Cubieboard and I am logged in as root
> on its serial uart from another system.
>
> On that system I use
>
> screen /dev/ttyUSB0 115200
>
> Well it was working well for a couple days, but now only garbage comes
> across.  Something messed up the serial link.
>
> pulling the usb cable to the usb/serial adapter does not reset things.
>
> I can ssh into the server and see root logged into ttyS0
>
> How do I reset that serial port so that I can work on the system?

I don't know how you can handle the wedged connection. But, I think you
troubles may come from the settings used. 115200 baud can be too fast to
run for a long time without errors. Also, I don't know how the default
handshaking is configured but maybe you have to add such settings as well.
Maybe something like "screen /dev/ttyUSB0 19200,ixoff,ixon" would work?

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Current RHEL fragmentation landscape

2023-07-25 Thread Simon Matter
>
>> 5. Red Hat's policy change contradicts the GPL's spirit.
>
>
> As you acknowledge, that's a subjective question.  I would say "no."
>
> I think the entire history of the free-as-in-speech vs free-as-in-beer
> clarification is proof that we wanted to ensure the right to improve
> software if you didn't like its limitations, not the right to give away
> software if you didn't like its price.
>
> But I also think it's important to acknowledge that the thing that
> rebuilders are asking for (the RPM source repositories) aren't GPL
> licensed, they're MIT licensed, which makes the question something of a
> non-sequitur.

I think you're simplifying too much here and I'm quite sure it's not true
that "RPM source repositories aren't GPL licensed, they're MIT licensed".

RPM source repositories consist of SPEC files, patches, documentation,
helper scripts and more and for sure not all of them are MIT licensed.
Many of those files are actually GPL licensed and as such enjoy the
freedom that the GPL asks for.

We don't have to study every letter of the FLOSS licenses to understand
what Red Hat is doing. Things are much simpler:

Let's assume Red Hat has written 15% of the sources of RHEL themself. That
would mean they've got 85% of the rest of the source code for free from
the worldwide community. Now, large parts of this community expect to also
get access to Red Hats 15% of source code without any restrictions, the
same way Red Hat got access to the 85% of source code from the community.

Everything else is considered unfriendly, shameless and evil, by a large
part of the worldwide open source community.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Current RHEL fragmentation landscape

2023-07-20 Thread Simon Matter
>> I can't predict the future but my feeling is that AlmaLinux has a good
>> chance to become the second Gold standard.
>
> I disagree with you. Both Rocky Linux and AlmaLinux are in a very
> comfortable position, and they will likely stay that way.

We'll see, Rocky Linux wants to stay a 100% rebuid of RHEL. Red Hat could
be tempted to hide more of the sources of RHEL, the parts not under GPL.

This won't hurt AlmaLinux as much because there is no real need to be 100%
RHEL compatible. It must be 100% compatible with itself, sure.

>
> my predict is that they will continue as a #rebuilder / #freeloader,
> writing software is a hard work.

We shouldn't forget that Red Hat didn't write all the software for RHEL.
They wrote some parts of it but "freeloaded" 90% from the community. I'm
also part of this community and never asked for a cent from Red Hat. The
deal is quite clear, isn't it?

>
> SuSe hardfork will probably be only an stable version of CentOS Stream.
>
> #offensive terms to the community :-), hide hat wrote it.
>

These terms are a shame for those who speak them out.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] Current RHEL fragmentation landscape

2023-07-20 Thread Simon Matter
Hi,

I've quickly made an incomplete list of the RHEL and clones/forks
landscape to see what the current situation is. The interesting question
will be how this will change in the coming years and how it affects Red
Hat/IBM and the Linux users in general.

RHEL ("The Original", quasi Gold standard until June 2023)
CentOS Stream (rolling RHEL next)
Oracle Linux (almost 1:1 rebuild with own patches, adds own packages)
Rocky Linux (tries to be 1:1 rebuild)
AlmaLinux (ABI compatible rebuild)
EuroLinux (status unknown)
Springdale Linux (status unknown)
Navy Linux (status unknown)
SUSE RHEL fork (status unknown)

For me it's clear that RHEL and certain clones/forks are here to stay.
Large enterprises or institutions like CERN and Fermilab will continue to
use RHEL and their favorite rebuild. Whoever likes it or not. The same
goes for a lot of SMEs and private users.

It will be interesting to see what turns out to be the new Gold standard.
"
Personally I expect we may see not one, but two Gold standards in the
future.  To run commercial applications, RHEL will stay the Gold standard.
To run all kind open source software, one of the clones/forks may be the
winner. Red Hat may also be attacked in the commercial space by Oracle and
other commercial players.

I can't predict the future but my feeling is that AlmaLinux has a good
chance to become the second Gold standard.

To those who call my discussion OT, let me say this: CentOS has brought us
into the current situation. Bear with us as we find our way out of this
trap.

I'm interested to hear some other ideas before I leave.

Thanks,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] How will fragmentation help Red Hat

2023-07-13 Thread Simon Matter
>
> Well, as RH's announcement is quite some day ago, I had time to reflect
> this jumble. The whole thing is much more complex than people want to
> admit and I will not decompose this all here now. Honestly I see
> the open source ecosystem like a hardware store. You have everything
> that you need to build your own home, thats all. So, some entity is
> needed to build it - a worker, consultant, hobby crafts(wo)man, agency,
> midsize firm, corporation et cetera, and that is the truth the we all
> should face it. To make it clear, what product do you get when a loosy
> community build a distribution, with components of projects that are

You'll get distributions like Debian, Arch or also FreeBSD and other BSDs.
One thing they had in common with Red Hat distributions is that they are
of high quality and one could fully trust them.

Unfortunately I fail to still trust Red Hat as I did in the past.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] How will fragmentation help Red Hat

2023-07-13 Thread Simon Matter
> On 2023-07-13 05:11, mario juliano grande-balletta wrote:
>> IBM wants to make money, PERIOD.  They paid billions for RedHat and
>> investors, executives, want ROI and profit, period.  No excuses.
>>
>> So, they are locking down RedHat and closing channels to important
>> software/materials.  It is what companies do all the time.
>
>
> I see this hypothesis relatively often, but there's no evidence to
> support it, and it doesn't make much logical sense.
>
> If Red Hat (or IBM) wanted to "lock down" RHEL, they wouldn't be
> focusing on Stream, which opens it up (and makes it easier to fork.)

IMHO Red Hat is focusing on Stream, because the community helps them to
build RHEL, without losing their own benefit of the long term support in
the final product, RHEL.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] How will fragmentation help Red Hat

2023-07-13 Thread Simon Matter
Hi,

As I found out yesterday, the fragmentation of the "Enterprise Linux"
ecosystem just started to come true. I expect this is only the beginning
and Red Hat may also start to completely hold back sources of non GPL
software which is part of the "Enterprise Linux" ecosystem.

I'm really wondering, how will this help anybody and how will this help
Red Hat in the long run?

I've been using and promoting the Red Hat "(Enterprise) Linux" ecosystem
for more than two decades. But, who will I promote in the future if this
ecosystem becomes fragmented?

I'm still trying to find answers but it's quite difficult.

How do others, who were using and promoting the Red Hat "Enterprise Linux"
ecosystem, handle this new situation?

Kind regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] bash test ?

2023-04-20 Thread Simon Matter
> On Wed, Apr 19, 2023 at 09:16:26PM +0200, lejeczek via CentOS wrote:
>>On 19/04/2023 08:46, wwp wrote:
>>> Hello lejeczek,
> ...
> Surround ${_Val} with double quotes (as you should) and things will
> be different:
>
> $ unset _Val; test -n "${_Val}"; echo $?
> 1
>
> Now you get it? :-)
>
 I don't know, am not sure, I remembered it differently, did not think
 enclosing quotes were necessary(always?) for that were {}
>>> {} does not prevent this (at least not in bash):
>>>
>>> $ FOO="a b"
>>>
>>> $ test -z $FOO
>>> bash: test: a: binary operator expected
>>>
>>> $ test -z ${FOO}
>>> bash: test: a: binary operator expected
>>>
>>> Because after $FOO or ${FOO} variable expansion, bash parsed:
>>> test -z a b
>>> 'b' is unexpected, from a grammar point of view.
>>>
>>> Quoting is expected, here:
>>> $ test -z "$FOO"
>>> 
>>>
>>> When FOO is unset, apparently it's a different matter, where you end up
>>> with $?=0 in all unquoted -n/-z cases, interestingly. I could not find
>>> this specific case in the bash documentation. That may not be portable
>>> to other shells, BTW. I only use {} when necessary (because of what
>>> bash allows to do between {}, plenty!, or when inserting $FOO into a
>>> literal string that may lead the parser to take the whole string for a
>>> variable name: echo $FOObar != echo ${FOO}bar).
>>>
>>>
>>> Regards,
>>There is a several ways to run tests in shell, but 'test'
>>which is own binary as I understand, defeats me..
>
> Yes, there is a binary for test (and its alternate '[').
>
> But most shells, including bash have incorporated code for test
> (and other commands) into the shell code itself for efficiency.
>
> $ type test
> test is a shell builtin
>
>>
>>I'd expect a consistency, like with what I usually do to
>>test for empty var:
>>-> $ export _Val=some; [[ -v _Val ]]; echo $?
>>0
>>-> $ unset _Val; [[ -v _Val ]]; echo $?
>>1
>>
>
> I do hope you don't use -v to test for empty variables as
> it tests for "set" variables and valid name syntax.
>
> Set variables can be "empty"  ( name= ).
>
> But in your last example _Val is "un"set, it does not
> exist.  Thus it can neither be empty nor occupied.

And to know if a variable is declared or not, this can be used:

if (( ${VAR+1} )); then
  echo "variable \$VAR is set"
else
  echo "variable \$VAR is NOT set"
fi

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] where is glib-devl x86-64?

2023-03-21 Thread Simon Matter
Hi,

> I have a brand new installation of Rocky Linux 9.1 (I know, this isn't a
> Rocky mailing list, but I can't find anything on this on Rocky forums,
> etc.
> so I figured I would ask here),
> and I installed Gimp, and would like to install the Resynthesizer plugin
> package.
>
> Trying to compile it from source, autogen.sh complains that I don't have
> the gimp development libraries installed. In fact, I can't find glib-devel
> anywhere in any of the configured repos (all the default Rocky repos,
> epel,
> rpmfusion).
>

Can it be that what you're looking for is glib2-devel?

Regards,
Simon


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Kernel updates do not boot - always boots oldest kernel

2023-03-15 Thread Simon Matter
> Here is the contents of the entire
>
> cat /etc/default.grub
>
> GRUB_TIMEOUT=5
> GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
> GRUB_DEFAULT=0
> GRUB_DISABLE_SUBMENU=true
> GRUB_TERMINAL_OUTPUT="console"
> GRUB_CMDLINE_LINUX="crashkernel=auto
> rd.md.uuid=066ffecb:69137a0b:4e579b4f:dfbf1696
> rd.md.uuid=bd87f682:e6df10e2:d2a6e247:834133f7 rhgb quiet"
> GRUB_DISABLE_RECOVERY="true"
>
> I have only changed GRUB_DEFAULT from "saved" to "0"
>
> I have also run
>
> /usr/sbin/grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

I may be wrong here but IIRC, using grub2-mkconfig as described in the
Grub docs didn't work for me when I tried to use it years ago.

I think you have to find out what is done when installing kernels and try
to find out where it goes wrong in your case. When you look at 'rpm -q
--scripts kernel' you can see that new kernels are registered with the
script '/usr/sbin/new-kernel-pkg'. I suggest to analyze what it does
exactly. I think it calls 'grubby' to do further work...

Regards,
Simon

>
> and seen the grub.cfg and grubenv updated in /boot/efi/EFI/centos
>
> At this point I think I have grub doing its stuff in the correct folder
> / destination used by UEFI for booting.
>
> When I look at grub.cfg there is some stuff I cannot understand
>
> there are five menuentry in this file, like:
>
> menuentry 'CentOS Linux (3.10.0-1160.88.1.el7.x86_64) 7 (Core)' --class
> centos --class gnu-linux --class gnu --class os --unrestricted
> $menuentry_id_option
> 'gnulinux-3.10.0-1160.81.1.el7.x86_64-advanced-7276336b-d2f2-4b94-b491-ad8c5662acb3'
> {
>      load_video
>      set gfxpayload=keep
>      insmod gzio
>      insmod part_gpt
>      insmod part_gpt
>      insmod diskfilter
>      insmod mdraid1x
>      insmod xfs
>      set root='mduuid/bd87f682e6df10e2d2a6e247834133f7'
>      if [ x$feature_platform_search_hint = xy ]; then
>        search --no-floppy --fs-uuid --set=root
> --hint='mduuid/bd87f682e6df10e2d2a6e247834133f7'
> f12be7f3-a6c6-4b90-8c51-286c32d11d12
>      else
>        search --no-floppy --fs-uuid --set=root
> f12be7f3-a6c6-4b90-8c51-286c32d11d12
>      fi
>      linuxefi /vmlinuz-3.10.0-1160.88.1.el7.x86_64
> root=UUID=7276336b-d2f2-4b94-b491-ad8c5662acb3 ro crashkernel=auto
> rd.md.uuid=066ffecb:69137a0b:4e579b4f:dfbf1696
> rd.md.uuid=bd87f682:e6df10e2:d2a6e247:834133f7 rhgb quiet LANG=en_US.UTF-8
>      initrdefi /initramfs-3.10.0-1160.88.1.el7.x86_64.img
> }
>
> the above is the latest kernel - doesn't boot as the console tells me it
> cannot load the vmlinuz file
>
> the kernel that boots looks like:
>
> menuentry 'CentOS Linux (3.10.0-1160.36.2.el7.x86_64) 7 (Core)' --class
> centos --class gnu-linux --class gnu --class os --unrestricted
> $menuentry_id_option
> 'gnulinux-3.10.0-1160.36.2.el7.x86_64-advanced-7276336b-d2f2-4b94-b491-ad8c5662acb3'
> {
>      load_video
>      set gfxpayload=keep
>      insmod gzio
>      insmod part_gpt
>      insmod part_gpt
>      insmod diskfilter
>      insmod mdraid1x
>      insmod xfs
>      set root='mduuid/bd87f682e6df10e2d2a6e247834133f7'
>      if [ x$feature_platform_search_hint = xy ]; then
>        search --no-floppy --fs-uuid --set=root
> --hint='mduuid/bd87f682e6df10e2d2a6e247834133f7'
> f12be7f3-a6c6-4b90-8c51-286c32d11d12
>      else
>        search --no-floppy --fs-uuid --set=root
> f12be7f3-a6c6-4b90-8c51-286c32d11d12
>      fi
>      linuxefi /vmlinuz-3.10.0-1160.36.2.el7.x86_64
> root=UUID=7276336b-d2f2-4b94-b491-ad8c5662acb3 ro crashkernel=auto
> rd.md.uuid=066ffecb:69137a0b:4e579b4f:dfbf1696
> rd.md.uuid=bd87f682:e6df10e2:d2a6e247:834133f7 rhgb quiet
>      initrdefi /initramfs-3.10.0-1160.36.2.el7.x86_64.img
> }
>
> I see that the first line names the kernel in brackets (correctly) but
> the $menuentry_id_option '.' doesn't make sense to me.
>
> For the kernel that boots (3.10.0-1160.36.2) the entry is
> 'gnulinux-3.10.0-1160.36.2.el7.x86_64-advanced-7276336b-d2f2-4b94-b491-ad8c5662acb3'
>
> For kernels that don't boot, e.g (3.10.0-1160.88.1) we see
>
> 'gnulinux-3.10.0-1160.81.1.el7.x86_64-advanced-7276336b-d2f2-4b94-b491-ad8c5662acb3'
>
> and this entry just seems wrong
>
> firstly the kernel version doesn't match - it has been set to ... 81.1
> ... rather than 88.1
>
> secondly the last part of the line is the same for every menuentry, namely
>
> -advanced-7276336b-d2f2-4b94-b491-ad8c5662acb3
>
> where does this come from? what is this part for? doing?
>
> Thanks
> Rob
>
>
> On 15/03/23 05:05, Leon Fauster via CentOS wrote:
>> Am 14.03.23 um 12:30 schrieb Rob Kampen:
>>> OK,
>>>
>>> found out the problem as to why it doesn't boot any kernel except 36.2
>>>
>>> the system reports that it cannot find
>>>
>>> vmlinuz-3.10.0-1160.88.1.el7.x86_64
>>>
>>> or any one of the others, except for
>>> vmlinuz-3.10.0-1160.36.2.el7.x86_64
>>>
>>> hence a manual selection from the grub menu when in front of the
>>> machine will only load the 36.2 kernel
>>>
>>> I found that under /boot/grub2 there were 

Re: [CentOS] EL9 says: pcp-pmie[2870]: Low random number entropy available 15.6%

2023-03-04 Thread Simon Matter
> Hi,
>
> I've discovered an issue which I don't understand. On a new test install
> of EL9 I saw this message in the logs:
>
> Mar 01 08:09:18  pcp-pmie[2870]: Low random number entropy
> available 15.6%avail@
>
> This is on a 64 core "AMD Opteron(tm) Processor 6282 SE" server but I also
> got the same low entropy on an EL9 KVM guest running on a "AMD EPYC 7601"
> server.

The simple fix here is to install rng-tools and start rngd. Starting from
when rngd was started, the available entropy still doesn't go higher than
256 but also didn't get lower.

So, why is rng-tools not installed by default, at least on a server
install? I've asked you.com about this and the answer is interesting

Q: why does rhel9 not install rng-tools by default
A: RHEL 9 does not install the rng-tools package by default because it is
not necessary for most users. The Linux kernel now uses hardware random
number generators (RNGs) to generate random numbers, which provides enough
entropy for most applications. For applications that require more entropy,
users can choose to install the rng-tools package if necessary.

Indeed, this was discussed here
https://bugzilla.redhat.com/show_bug.cgi?id=1888695 but why do I see
available entropy being low on my freshly installed systems?

I start to believe that at least AMD EPYC based servers without TPM module
(yes, we order our server without TPM) will not work well without rngd
running. If that's the case, then it wasn't a good idea to remove
rng-tools from server installs IMHO.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] EL9 says: pcp-pmie[2870]: Low random number entropy available 15.6%

2023-03-03 Thread Simon Matter
Hi,

I've discovered an issue which I don't understand. On a new test install
of EL9 I saw this message in the logs:

Mar 01 08:09:18  pcp-pmie[2870]: Low random number entropy
available 15.6%av...@beta.corp.invoca.ch

This is on a 64 core "AMD Opteron(tm) Processor 6282 SE" server but I also
got the same low entropy on an EL9 KVM guest running on a "AMD EPYC 7601"
server.

After a lot of searching the net I understand that rng has been reworked
in 5.x kernels and /proc/sys/kernel/random/entropy_avail reaches only 256
in default configurations. But why does it go too low on a test system
with almost not load?

Is this an issue with AMD CPUs or does it also happen on other systems?

Thanks for any insights,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] EL9/udev generates wrong device nodes/symlinks with HPE Smart Array controller

2023-03-01 Thread Simon Matter
Hi,

> Simon Matter 
>> 2) some symlinks created by udev are just wrong and therefore very
>> dangerous to use:
>> scsi-SHP_LOGICAL_VOLUME_500143801722C0B0 -> ../../sda
>> scsi-SHP_LOGICAL_VOLUME_500143801722C0B0-part1 -> ../../sdb1
>> scsi-SHP_LOGICAL_VOLUME_500143801722C0B0-part2 -> ../../sdb2
>
>I think it maybe caused by sd driver asynchronous scanning.
>I am lucky that I didn't see this before. nvme may have similar
> issues, but nvme has boot parameter to avoid it.
>Suse has boot parameter to avoid it.
>with EL9 we will wait until EL 9.3 if we are lucky.
>I had report issue: https://bugzilla.redhat.com/show_bug.cgi?id=2140017

Thanks for confirming that I'm not alone with this "feature"

In the above example, it's much fun if you want to wipe the two partitions on
/dev/disk/by-id/scsi-SHP_LOGICAL_VOLUME_500143801722C0B0 and therefore
wipe this device. You end up wiping the wrong disk!

When I see such things my blood start boiling :(

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] EL9/udev generates wrong device nodes/symlinks with HPE Smart Array controller

2023-03-01 Thread Simon Matter
Hi,

I see some strange and dangerous things happening on a HPE server with HPE
Smart Array controller where EL9 ends up with wrong device nodes/symlinks
to the attached disks/raid volumes:

(I didn't touch anything here but at 08:09 some symlinks were changed)
/dev/disk/by-id/:
lrwxrwxrwx 1 root root  9 Mar  1 07:57 scsi-0HP_LOGICAL_VOLUME_ ->
../../sdc
lrwxrwxrwx 1 root root 10 Mar  1 07:57
scsi-0HP_LOGICAL_VOLUME_-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Mar  1 07:57
scsi-0HP_LOGICAL_VOLUME_-part2 -> ../../sdc2
lrwxrwxrwx 1 root root  9 Mar  1 07:57 scsi-0HP_LOGICAL_VOLUME_0100 ->
../../sdb
lrwxrwxrwx 1 root root  9 Mar  1 08:09 scsi-0HP_LOGICAL_VOLUME_0200 ->
../../sda
lrwxrwxrwx 1 root root  9 Mar  1 07:57 scsi-0HP_LOGICAL_VOLUME_0300 ->
../../sdd
lrwxrwxrwx 1 root root  9 Mar  1 08:09
scsi-SHP_LOGICAL_VOLUME_500143801722C0B0 -> ../../sda
lrwxrwxrwx 1 root root 10 Mar  1 07:57
scsi-SHP_LOGICAL_VOLUME_500143801722C0B0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Mar  1 07:57
scsi-SHP_LOGICAL_VOLUME_500143801722C0B0-part2 -> ../../sdc2

/dev/disk/by-path/:
lrwxrwxrwx 1 root root  9 Mar  1 07:57 pci-:03:00.0-scsi-0:1:0:0 ->
../../sdc
lrwxrwxrwx 1 root root 10 Mar  1 07:57 pci-:03:00.0-scsi-0:1:0:0-part1
-> ../../sdc1
lrwxrwxrwx 1 root root 10 Mar  1 07:57 pci-:03:00.0-scsi-0:1:0:0-part2
-> ../../sdc2
lrwxrwxrwx 1 root root  9 Mar  1 07:57 pci-:03:00.0-scsi-0:1:0:1 ->
../../sdb
lrwxrwxrwx 1 root root  9 Mar  1 08:09 pci-:03:00.0-scsi-0:1:0:2 ->
../../sda
lrwxrwxrwx 1 root root  9 Mar  1 07:57 pci-:03:00.0-scsi-0:1:0:3 ->
../../sdd

After rebooting, the things are different but also wrong:

(here nothing has changed after boot but symlinks are already wrong)
/dev/disk/by-id/:
lrwxrwxrwx 1 root root   9 Mar  1 10:56 scsi-0HP_LOGICAL_VOLUME_
-> ../../sdb
lrwxrwxrwx 1 root root  10 Mar  1 10:56
scsi-0HP_LOGICAL_VOLUME_-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  10 Mar  1 10:56
scsi-0HP_LOGICAL_VOLUME_-part2 -> ../../sdb2
lrwxrwxrwx 1 root root   9 Mar  1 10:56 scsi-0HP_LOGICAL_VOLUME_0100
-> ../../sda
lrwxrwxrwx 1 root root   9 Mar  1 10:56 scsi-0HP_LOGICAL_VOLUME_0200
-> ../../sdd
lrwxrwxrwx 1 root root   9 Mar  1 10:56 scsi-0HP_LOGICAL_VOLUME_0300
-> ../../sdc
lrwxrwxrwx 1 root root   9 Mar  1 10:56
scsi-SHP_LOGICAL_VOLUME_500143801722C0B0 -> ../../sda
lrwxrwxrwx 1 root root  10 Mar  1 10:56
scsi-SHP_LOGICAL_VOLUME_500143801722C0B0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  10 Mar  1 10:56
scsi-SHP_LOGICAL_VOLUME_500143801722C0B0-part2 -> ../../sdb2

/dev/disk/by-path/:
lrwxrwxrwx 1 root root   9 Mar  1 10:56 pci-:03:00.0-scsi-0:1:0:0 ->
../../sdb
lrwxrwxrwx 1 root root  10 Mar  1 10:56
pci-:03:00.0-scsi-0:1:0:0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  10 Mar  1 10:56
pci-:03:00.0-scsi-0:1:0:0-part2 -> ../../sdb2
lrwxrwxrwx 1 root root   9 Mar  1 10:56 pci-:03:00.0-scsi-0:1:0:1 ->
../../sda
lrwxrwxrwx 1 root root   9 Mar  1 10:56 pci-:03:00.0-scsi-0:1:0:2 ->
../../sdd
lrwxrwxrwx 1 root root   9 Mar  1 10:56 pci-:03:00.0-scsi-0:1:0:3 ->
../../sdc

Note that two things are strange:

1) the /dev/sd* nodes are in a random order after every restart.
# lsscsi
[1:0:0:0]storage HP   P410i6.64  -
[1:1:0:0]diskHP   LOGICAL VOLUME   6.64  /dev/sdb
[1:1:0:1]diskHP   LOGICAL VOLUME   6.64  /dev/sda
[1:1:0:2]diskHP   LOGICAL VOLUME   6.64  /dev/sdd
[1:1:0:3]diskHP   LOGICAL VOLUME   6.64  /dev/sdc

2) some symlinks created by udev are just wrong and therefore very
dangerous to use:
scsi-SHP_LOGICAL_VOLUME_500143801722C0B0 -> ../../sda
scsi-SHP_LOGICAL_VOLUME_500143801722C0B0-part1 -> ../../sdb1
scsi-SHP_LOGICAL_VOLUME_500143801722C0B0-part2 -> ../../sdb2

While 1 may be expected(???) I think 2 should really not happen.

I've tried to find out where things go wrong but the whole udev stuff
started to hurt my brain :)

I'm quite sure HPE Smart Array based servers are quite common so my big
question is: do others see that same?

While it's possible to live with this mess I'd really like to fix it somehow.

Thanks,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] C7, removing zoom problem

2023-02-05 Thread Simon Matter
Hi

> Guys, I'm trying to update my zoom client and yum (or yumex) won't let me
> do an update, so I try to remove the installed one, on the theory that if
> it isn't there I should be able to install a newer one, by doing "sudo yum
> remove zoom_x86_64" (where my PWD is the directory where the zoom RPM
> files
> live) and it tells me "no packages marked for removal.

This should tell you the real name of the package

rpm -qa zoom\*

Then rpm -e zoom... should remove it.

That said, I've never used zoom so I don't really know if they do
something special.

Regards,
Simon

>
> Reading thru the man page for rpm I can't figure out any other way to do
> it. Suggestions, any one?
>
> Thanks in advance!
>
> Fred
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] failed: Could not start storage pool: cannot open directory: ... No such file or directory

2023-01-14 Thread Simon Matter
Hi,

> Hi,
>
> virt-install --help
> Use '--option=?' or '--option help' to see available suboptions
> See man page for examples and full option syntax.
   ^^
As it says, see the man page with 'man virt-install'.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Upgrading system from non-RAID to RAID1

2023-01-12 Thread Simon Matter
> Hallo Simon,
>
>> Anyway, the splitting of large disks has additional advantages. Think of
>> what happens in case of a failure (power loss, kernel crash...). With
>> the
>> disk as one large chunk, the whole disk has to be resynced on restart
>> while with smaller segments only those which are marked as dirty have to
>> be resynced. This can make a bit difference.
>
> I am not sure if this is true. If a underlying disk fails, it will mark
> all partitions on that disk as dirty, so you will have to resync them all
> after replacing or readding the disk into the array.

No, I'm not talking about a complete disk failure, my example wasn't a
failure at all but a server problem like power loss, kernel crash and such
things. In this case only the segments which were not in sync at the time
of the crash will be resynced on restart, not the whole disk.

The same is, if a read error happens on one disk, only the partial segment
will lose redundancy and not the whole contents of the disk.

That's a huge improvement especially on very large disks.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Upgrading system from non-RAID to RAID1

2023-01-11 Thread Simon Matter
> On 01/11/2023 01:33 PM, H wrote:
>> On 01/11/2023 02:09 AM, Simon Matter wrote:
>>> What I usually do is this: "cut" the large disk into several pieces of
>>> equal size and create individual RAID1 arrays. Then add them as LVM PVs
>>> to
>>> one large VG. The advantage is that with one error on one disk, you
>>> wont
>>> lose redundancy on the whole RAID mirror but only on a partial segment.
>>> You can even lose another segment with an error on the other disk and
>>> still have redundancy if the error is in another part.
>>>
>>> That said, it's a bit more work to setup but has helped me several
>>> times
>>> in the decades ago.
>>>
>>>
>> But is your strategy of dividing the large disk into individual RAID1
>> arrays also applicable to SSDs? I have heard, perhaps incorrectly, that
>> once a SSD fails, the entire SSD becomes unusable which would suggest
>> that dividing it into multiple RAID1 arrays would not be useful?
>>
> Follow-up question: Is my proposed strategy below correct:
>
> - Make a copy of all existing directories and files on the current disk
> using clonezilla.
>
> - Install the new M.2 SSDs.
>
> - Partitioning the new SSDs for RAID1 using an external tool.
>
> - Doing a minimal installation of C7 and mdraid.
>
> - If choosing three RAID partitions, one for /boot, one for /boot/efi and
> the third one for the rest, do I go with the default mdraid version, ie
> 1.2 I believe?

I think at least /boot/efi must be on an mdraid version which has its
metadata at the end of the partition, I'm not sure about /boot.
That said, I think the installer should take care here but I'm not sure it
already does on C7.

>
> - Copying the backup above with contents of the the existing disks, ie not
> just /root and /home but all other directories and files to the new disks
> from the clonezilla backup. Note that the new disks will be larger.

I can't comment on clonezilla as I've never used it. Tar and rsync are my
friends when doing such things.
I think you may have to take special care for boot related stuff like
things in /boot and boot/efi. The other thing to care is for hardware
related stuff like UUIDs generated in /etc/udev. The whole undertaking is
not trivial.

>
> - Change the boot sequence in the BIOS and reboot.

That's EFI, yes? I still fell like a greenhorn with EFI :)

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Upgrading system from non-RAID to RAID1

2023-01-11 Thread Simon Matter
> On 01/11/2023 02:09 AM, Simon Matter wrote:
>> What I usually do is this: "cut" the large disk into several pieces of
>> equal size and create individual RAID1 arrays. Then add them as LVM PVs
>> to
>> one large VG. The advantage is that with one error on one disk, you wont
>> lose redundancy on the whole RAID mirror but only on a partial segment.
>> You can even lose another segment with an error on the other disk and
>> still have redundancy if the error is in another part.
>>
>> That said, it's a bit more work to setup but has helped me several times
>> in the decades ago.
>>
>>
> But is your strategy of dividing the large disk into individual RAID1
> arrays also applicable to SSDs? I have heard, perhaps incorrectly, that
> once a SSD fails, the entire SSD becomes unusable which would suggest that
> dividing it into multiple RAID1 arrays would not be useful?

What you heard seems extremely oversimplified to me. A HD can fail in
different manners and so can SSDs.
Anyway, the splitting of large disks has additional advantages. Think of
what happens in case of a failure (power loss, kernel crash...). With the
disk as one large chunk, the whole disk has to be resynced on restart
while with smaller segments only those which are marked as dirty have to
be resynced. This can make a bit difference.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Upgrading system from non-RAID to RAID1

2023-01-11 Thread Simon Matter
>
>
> On 1/11/23 02:09, Simon Matter wrote:
>>> I plan to upgrade an existing C7 computer which currently has one 256
>>> GB
>>> SSD to use mdadmin software RAID1 after adding two 4 TB M2. SSDs, the
>>> rest
>>> of the system remaining the same. The system also has one additional
>>> internal and one external harddisk but these should not be touched. The
>>> system will continue to run C7.
>  trimming
>>>
>>> - I do not see any benefit to breaking up the LVM2/LUKS partition
>>> containing /root, /swap and /home into more than one RAID1 partition or
>>> am
>>> I wrong? If the SSD fails, the entire SSD would fail and break the
>>> system,
>>> hence I might as well keep it as one single RAID1 partition, or?
>> What I usually do is this: "cut" the large disk into several pieces of
>> equal size and create individual RAID1 arrays. Then add them as LVM PVs
>> to
>> one large VG. The advantage is that with one error on one disk, you wont
>> lose redundancy on the whole RAID mirror but only on a partial segment.
>> You can even lose another segment with an error on the other disk and
>> still have redundancy if the error is in another part.
>>
>> That said, it's a bit more work to setup but has helped me several times
>> in the decades ago.
>
> Ah, now I begin to get it.  Separate partitions RAIDed.

Yes, exactly, sorry for not being clear enough. The structure of disk 0
looks like this:


$ lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT /dev/nvme0n1
NAMEFSTYPE  SIZE MOUNTPOINT
nvme0n1   745.2G
├─nvme0n1p1 vfat200M /boot/efi
├─nvme0n1p2 linux_raid_member 1G
│ └─md0 xfs1023M /boot
├─nvme0n1p3 linux_raid_member   186G
│ └─md1 LVM2_member   185.9G
│   ├─main-root xfs  30G /
│   ├─main-swap swap 16G [SWAP]
│   ├─main-tmp  xfs  10G /tmp
│   ├─main-var  xfs 200G /var
│   └─main-imap xfs 1.2T /var/spool/imap
├─nvme0n1p4 linux_raid_member   186G
│ └─md2 LVM2_member   185.9G
│   └─main-imap xfs 1.2T /var/spool/imap
├─nvme0n1p5 linux_raid_member   186G
│ └─md3 LVM2_member   185.9G
│   └─main-imap xfs 1.2T /var/spool/imap
├─nvme0n1p6 linux_raid_member   186G
│ └─md4 LVM2_member   185.9G
│   ├─main-var  xfs 200G /var
│   └─main-imap xfs 1.2T /var/spool/imap
└─nvme0n1p715.8M


Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] RAID1 setup

2023-01-11 Thread Simon Matter
>
>
> On 1/10/23 20:20, Robert Moskowitz wrote:
>> Official drives should be here Friday, so trying to get reading.
>>
>>
>>
>> On 1/9/23 01:32, Simon Matter wrote:
>>> Hi
>>>
>>>> Continuing this thread, and focusing on RAID1.
>>>>
>>>> I got an HPE Proliant gen10+ that has hardware RAID support. (can turn
>>>> it off if I want).
>>> What exact model of RAID controller is this? If it's a S100i SR Gen10
>>> then
>>> it's not hardware RAID at all.
>>
>> Yes, I found the information:
>> 
>> HPE Smart Array Gen10 Controllers Data Sheet.
>>
>> Software RAID
>>
>> · HPE Smart Array S100i SR Gen10 Software RAID
>>
>> Notes:
>>
>> - HPE Smart Array S100i SR Gen10 SW RAID will operate in UEFI mode
>> only. For legacy support an additional controller will be needed
>>
>> - The S100i only supports Windows. For Linux users, HPE offers a
>> solution that uses in-distro open-source software to create a two-disk
>> RAID 1 boot volume. For more information visit:
>> https://downloads.linux.hpe.com/SDR/project/lsrrb/
>> 
>> I have yet to look at this url.
>
> This guide seems to answer MOST of my questions.

I didn't know this guide from HPE. What I'm not sure is how well it is
supported now for newer distributions like EL9. I could be wrong but I
think EL9 already supports setting this up out of the box without any
additional fiddling.

In my case years ago with EL7 I simply put /boot/efi on a partition on
disk 0 and another one on disk 1, like so:

/dev/nvme0n1p1 200M   12M  189M   6% /boot/efi
/dev/nvme1n1p1 200M   12M  189M   6% /boot/efi.backup

To keep the filesystems in sync I've added a hook to our package update
mechanism which simply calls this bash function:

EFISRC="/boot/efi"
EFIDEST="${EFISRC}.backup"

efisync() {
  if [ -d "${EFISRC}/EFI" -a -d "${EFIDEST}/EFI" ]; then
rsync --archive --delete --verbose "${EFISRC}/EFI" "${EFIDEST}/"
  fi
}

If I had to install this today I'd like to put it on RAID as discussed.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Upgrading system from non-RAID to RAID1

2023-01-10 Thread Simon Matter
> I plan to upgrade an existing C7 computer which currently has one 256 GB
> SSD to use mdadmin software RAID1 after adding two 4 TB M2. SSDs, the rest
> of the system remaining the same. The system also has one additional
> internal and one external harddisk but these should not be touched. The
> system will continue to run C7.
>
> If I remember correctly, the existing SSD does not use a M2. slot so they
> should be available for the new 4GB SSDs while the old SSD remains in
> place. If I read the output from gparted correctly, this existing SSD is
> partitioned as follows:
>
> - EFI system partition 260 MB and mounted as /boot/efi (formatted as
> FAT32).
>
> - boot partition 1 GB and mounted as /boot (formatted as xfs).
>
> - /root, swap and /home seem to coexist on a LUKS encrypted partitition
> using LVM2 PV.
>
> My current plan is to:
>
> - Use clonezilla to make individual backups of all partitions above.
>
> - Install the two M2. SSDs.
>
> - Use an external disk tool to partition the two new M2. SSDs as follows:
>
> -- Create a RAID1 partition for /boot - same size as current, ie 260 MB
>
> -- Create a RAID1 partition for /boot/efi - same size as current, ie 1 GB
>
> -- Create a RAID1 partition for LVM2 and LUKS - the rest of the 4 TB SSD
>
> Questions:
>
> - I do not see any benefit to breaking up the LVM2/LUKS partition
> containing /root, /swap and /home into more than one RAID1 partition or am
> I wrong? If the SSD fails, the entire SSD would fail and break the system,
> hence I might as well keep it as one single RAID1 partition, or?

What I usually do is this: "cut" the large disk into several pieces of
equal size and create individual RAID1 arrays. Then add them as LVM PVs to
one large VG. The advantage is that with one error on one disk, you wont
lose redundancy on the whole RAID mirror but only on a partial segment.
You can even lose another segment with an error on the other disk and
still have redundancy if the error is in another part.

That said, it's a bit more work to setup but has helped me several times
in the decades ago.

>
> - Is the next step after the RAID1 partitioning above then to do a minimal
> install of C7 followed by using clonezilla to restoring the LVM2/LUKS
> partition??
>
> - Any advice on using clonezilla? Or the external partitioning tool?
>
>  - Finally, since these new SSDs are huge, perhaps I should take the
> opportunity to increase the space for both /root and /swap?
>
> - /root is 50 GB - should I increase it to eg 100 GB?
>
> - The system currently has 32 GB of memory but I will likely upgrade it to
> 64 GB (or even 128 GB), perhaps I should at this time already increase the
> /swap space to 64 GB/128 GB?

I'm also interested here to learn what others are doing in higher memory
situations. I have some systems with half a TB memory and never configured
more than 16GB of swap. I has usually worked well and when a system
started to use swap heavily, there was something really wrong in an
application and had to be fixed there. Additionally we've tuned the kernel
VM settings so that it didn't want to swap too much. Because swapping was
always slow anyway even on fast U.2 NVME SSD storage.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] CentOS Stream 8 sssd.service failing part of sssd-common-2.8.1-1.el8.x86_64 baseos package

2023-01-09 Thread Simon Matter
>
>
> On 1/9/23 17:45, Simon Matter wrote:
>>> On 1/3/23 13:41, Simon Matter wrote:
>>>>> On 1/3/23 05:17, Orion Poplawski wrote:
>>>>>> On 12/30/22 04:06, Jelle de Jong wrote:
>>>>>>> On 12/27/22 22:55, Gordon Messmer wrote:
>>>>>>>> On 2022-12-25 07:44, Jelle de Jong wrote:
>>>>>>>>> A recent update of the sssd-common-2.8.1-1.el8.x86_64 package is
>>>>>>>>> causing sssd.service systemctl failures all over my CentosOS
>>>>>>>>> machines.
>>>>>>>> ...
>>>>>>>>> [sssd] [confdb_expand_app_domains] (0x0010): No domains
>>>>>>>>> configured,
>>>>>>>>> fatal error!
>>>>>>>>
>>>>>>>>
>>>>>>>> Were you previously using sssd?  Or is the problem merely that it
>>>>>>>> is
>>>>>>>> now reporting an error starting a service that you don't use?
>>>>>>>>
>>>>>>>> Are there any files in /etc/sssd/conf.d, or does
>>>>>>>> /etc/sssd/sssd.conf
>>>>>>>> exist?  If so, what are the contents of those files?
>>>>>>>>
>>>>>>>> What are the contents of /usr/lib/systemd/system/sssd.service?
>>>>>>>>
>>>>>>>> If you run "journalctl -u sssd.service", are there any log entries
>>>>>>>> older than the package update?
>>>>>>>
>>>>>>> I got a monitoring system for failing services and I sudenly
>>>>>>> started
>>>>>>> getting dozens of notifications for all my CentOS systems that sssd
>>>>>>> was failing. This is after the sssd package updates, causing this
>>>>>>> regression. SSSD services where not really in use but some of the
>>>>>>> common libraries are used.
>>>>>>>
>>>>>>> # systemctl status sssd
>>>>>>> ● sssd.service - System Security Services Daemon
>>>>>>>       Loaded: loaded (/usr/lib/systemd/system/sssd.service;
>>>>>>> enabled;
>>>>>>> vendor preset: enabled)
>>>>>>>       Active: failed (Result: exit-code) since Sat 2022-12-24
>>>>>>> 06:14:10
>>>>>>> UTC; 6 days ago
>>>>>>> Condition: start condition failed at Fri 2022-12-30 11:02:01 UTC;
>>>>>>> 4s
>>>>>>> ago
>>>>>>>       ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not
>>>>>>> met
>>>>>>>       └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was
>>>>>>> not
>>>>>>> met
>>>>>>>     Main PID: 3953157 (code=exited, status=4)
>>>>>>>
>>>>>>> Warning: Journal has been rotated since unit was started. Log
>>>>>>> output
>>>>>>> is incomplete or unavailable.
>>>>>>
>>>>>>
>>>>>>> # ls -halZ /etc/sssd/sssd.conf
>>>>>>> ls: cannot access '/etc/sssd/sssd.conf': No such file or directory
>>>>>>
>>>>>> Looks like you need to figure out what happened to your
>>>>>> /etc/sssd/sssd.conf file.  FWIW - I've updated my one CS8 machine to
>>>>>> 2.8.1-1 and it seems to be fine.
>>>>>
>>>>> I did not do anything specific to the configuration file. I tried to
>>>>> reinstall the new sssd-common pacakge, but it will not install the
>>>>> /etc/sssd/sssd.conf file. I can not remove the package because it
>>>>> will
>>>>> remove a lot of packages that I do need. I still think something is
>>>>> wrong with the new sssd packages..
>>>>>
>>>>> [root@nginx01 ~]# rpm -qplc sssd-common-2.8.1-1.el8.x86_64.rpm
>>>>> /etc/logrotate.d/sssd
>>>>> /etc/pam.d/sssd-shadowutils
>>>>> /etc/rwtab.d/sssd
>>>>> /etc/sssd/sssd.conf
>>>>
>>>> Most likely the file /etc/sssd/sssd.conf is a ghost file and therefore
>>>> it's not installed but only recognized as being part of the package.
>>>>
>>>> Simon
>>>
>>> I do not get this. There has nog been an /etc/sssd/sssd.conf on my
>>> system before as it only installed sssd-common due to dependencies for
>>> other libaries. I do not use the sssd service. The package gets an
>>> update and now my systemd status is failing on a lot of systems and I
>>> am
>>> being tolled I should get /etc/sssd/sssd.conf sorted?
>>>
>>> Can you fix the sssd package by either not enabling the sssd systemd
>>> service or some other solution that does not make systemd status fail?
>>>
>>> This is a regression and it is going to cause me a lot of time now to
>>> write ansible code for the disabling of the sssd service on all systems
>>> that have it installed due to dependencies but do not use it.
>>>
>>> sssd.services failing regressions and dfn-automatic.serivces failing
>>> regressions due to freeipa/sssd/samba conflicts for months now.
>>
>> Do you have a file /etc/sssd/sssd.conf? IIRC you said you don't have
>> such
>> a file, which is fine.
>
> no file is there.
>
>> Do you have any file in /etc/sssd/conf.d/? This directory should be
>> empty
>> but it's possible that another package puts something there.
>
> no files are there.

Maybe you can check for a difference in sssd.service from the older
package and the current one. It seems that there was a change which
results in the behavior you see.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] CentOS Stream 8 sssd.service failing part of sssd-common-2.8.1-1.el8.x86_64 baseos package

2023-01-09 Thread Simon Matter
> On 1/3/23 13:41, Simon Matter wrote:
>>> On 1/3/23 05:17, Orion Poplawski wrote:
>>>> On 12/30/22 04:06, Jelle de Jong wrote:
>>>>> On 12/27/22 22:55, Gordon Messmer wrote:
>>>>>> On 2022-12-25 07:44, Jelle de Jong wrote:
>>>>>>> A recent update of the sssd-common-2.8.1-1.el8.x86_64 package is
>>>>>>> causing sssd.service systemctl failures all over my CentosOS
>>>>>>> machines.
>>>>>> ...
>>>>>>> [sssd] [confdb_expand_app_domains] (0x0010): No domains configured,
>>>>>>> fatal error!
>>>>>>
>>>>>>
>>>>>> Were you previously using sssd?  Or is the problem merely that it is
>>>>>> now reporting an error starting a service that you don't use?
>>>>>>
>>>>>> Are there any files in /etc/sssd/conf.d, or does /etc/sssd/sssd.conf
>>>>>> exist?  If so, what are the contents of those files?
>>>>>>
>>>>>> What are the contents of /usr/lib/systemd/system/sssd.service?
>>>>>>
>>>>>> If you run "journalctl -u sssd.service", are there any log entries
>>>>>> older than the package update?
>>>>>
>>>>> I got a monitoring system for failing services and I sudenly started
>>>>> getting dozens of notifications for all my CentOS systems that sssd
>>>>> was failing. This is after the sssd package updates, causing this
>>>>> regression. SSSD services where not really in use but some of the
>>>>> common libraries are used.
>>>>>
>>>>> # systemctl status sssd
>>>>> ● sssd.service - System Security Services Daemon
>>>>>      Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled;
>>>>> vendor preset: enabled)
>>>>>      Active: failed (Result: exit-code) since Sat 2022-12-24 06:14:10
>>>>> UTC; 6 days ago
>>>>> Condition: start condition failed at Fri 2022-12-30 11:02:01 UTC; 4s
>>>>> ago
>>>>>      ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met
>>>>>      └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not
>>>>> met
>>>>>    Main PID: 3953157 (code=exited, status=4)
>>>>>
>>>>> Warning: Journal has been rotated since unit was started. Log output
>>>>> is incomplete or unavailable.
>>>>
>>>>
>>>>> # ls -halZ /etc/sssd/sssd.conf
>>>>> ls: cannot access '/etc/sssd/sssd.conf': No such file or directory
>>>>
>>>> Looks like you need to figure out what happened to your
>>>> /etc/sssd/sssd.conf file.  FWIW - I've updated my one CS8 machine to
>>>> 2.8.1-1 and it seems to be fine.
>>>
>>> I did not do anything specific to the configuration file. I tried to
>>> reinstall the new sssd-common pacakge, but it will not install the
>>> /etc/sssd/sssd.conf file. I can not remove the package because it will
>>> remove a lot of packages that I do need. I still think something is
>>> wrong with the new sssd packages..
>>>
>>> [root@nginx01 ~]# rpm -qplc sssd-common-2.8.1-1.el8.x86_64.rpm
>>> /etc/logrotate.d/sssd
>>> /etc/pam.d/sssd-shadowutils
>>> /etc/rwtab.d/sssd
>>> /etc/sssd/sssd.conf
>>
>> Most likely the file /etc/sssd/sssd.conf is a ghost file and therefore
>> it's not installed but only recognized as being part of the package.
>>
>> Simon
>
> I do not get this. There has nog been an /etc/sssd/sssd.conf on my
> system before as it only installed sssd-common due to dependencies for
> other libaries. I do not use the sssd service. The package gets an
> update and now my systemd status is failing on a lot of systems and I am
> being tolled I should get /etc/sssd/sssd.conf sorted?
>
> Can you fix the sssd package by either not enabling the sssd systemd
> service or some other solution that does not make systemd status fail?
>
> This is a regression and it is going to cause me a lot of time now to
> write ansible code for the disabling of the sssd service on all systems
> that have it installed due to dependencies but do not use it.
>
> sssd.services failing regressions and dfn-automatic.serivces failing
> regressions due to freeipa/sssd/samba conflicts for months now.

Do you have a file /etc/sssd/sssd.conf? IIRC you said you don't have such
a file, which is fine.

Do you have any file in /etc/sssd/conf.d/? This directory should be empty
but it's possible that another package puts something there.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Help with an HP Proliant gen10 plus?

2023-01-09 Thread Simon Matter
>
>
> On 1/9/23 01:37, Simon Matter wrote:
>>> Just starting and trying to boot off the SPP firmware update ISO image
>>> on a USB stick.
>>>
>>> I made the stick with:
>>>
>>> # mkfs.vfat /dev/sdb
>> 
>> Why create an MS-DOS filesystem on the stick which gets immediately
>> overwritten in the next step?
>
> I think the idea is to get that first 4MB set up for booting, as the dd
> skips that space.

No, what you've set is a dd block size of 4MB.

>
>>
>>
>>> # dd bs=4M
>>> if=P52581_001_gen10spp-2022.09.01.00-SPP2022090100.2022_0930.1.iso
>>> of=/dev/sdb status=progress
>> Is this what HPE says how to create the stick? If yes then you may ask
>> HPE
>> how to get it to work.
>
> HP gives no instructions.  At least I can't find it on the support
> pages.  I do have a support account.

You should be able to simply do

dd if=P52581_001_gen10spp-2022.09.01.00-SPP2022090100.2022_0930.1.iso
of=/dev/sdb

of even simpler

cat P52581_001_gen10spp-2022.09.01.00-SPP2022090100.2022_0930.1.iso >
/dev/sdb

If that's not working I don't know what to do else.

Otherwise you could search for an USB disk image instead of an ISO image,
I don't know if HPE provides such a thing.

BTW, if this server has an HPE ILO, you can upgrade firmware directly from
there.

Regards,
Simon

>
> You should just 'know' how to build a bootable device from a 9GB iso
> image.
>
>
>>
>>> The usb drive is 16GB and the iso is 9GB.
>>>
>>> seem to boot from it and go into auto install of firmware then died
>>> with
>>>
>>> starting initrd...
>>>
>>> warning!!! Unable to mount the file system [cdrom]
>>> warning!!! Unable to mount the file system
>>>
>>> Preboot maintence mode
>>>
>>> /bin/ash: can't access tty: job control turned off
>>>
>>> and at # prompt.
>>>
>>> There is no cdrom on the gen10 plus.  Only in internal bootable usb
>>> port.
>> That's usually fine because the cdrom can be mounted as loop device. No
>> need for a real cdrom.
>
> Yeah.  Going to work on it some more today.  Plus got a finish a paper
> for a symposium.  I give up on learning tex; I found a word template
> that can create the right pdf, so pull out all my writing in tex and
> start over.  And I DO use the IETF's xml format for creating Internet
> Drafts, so I am teachable on this stuff despite my age...
>
> I do vaguely recall working with tex for writing back around '78, but
> that was it.
>
>>
>> Regards,
>> Simon
>>
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Help with an HP Proliant gen10 plus?

2023-01-08 Thread Simon Matter
> Just starting and trying to boot off the SPP firmware update ISO image
> on a USB stick.
>
> I made the stick with:
>
> # mkfs.vfat /dev/sdb
   
Why create an MS-DOS filesystem on the stick which gets immediately
overwritten in the next step?


> # dd bs=4M
> if=P52581_001_gen10spp-2022.09.01.00-SPP2022090100.2022_0930.1.iso
> of=/dev/sdb status=progress

Is this what HPE says how to create the stick? If yes then you may ask HPE
how to get it to work.

>
> The usb drive is 16GB and the iso is 9GB.
>
> seem to boot from it and go into auto install of firmware then died with
>
> starting initrd...
>
> warning!!! Unable to mount the file system [cdrom]
> warning!!! Unable to mount the file system
>
> Preboot maintence mode
>
> /bin/ash: can't access tty: job control turned off
>
> and at # prompt.
>
> There is no cdrom on the gen10 plus.  Only in internal bootable usb port.

That's usually fine because the cdrom can be mounted as loop device. No
need for a real cdrom.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] RAID1 setup

2023-01-08 Thread Simon Matter
Hi

> Continuing this thread, and focusing on RAID1.
>
> I got an HPE Proliant gen10+ that has hardware RAID support.  (can turn
> it off if I want).

What exact model of RAID controller is this? If it's a S100i SR Gen10 then
it's not hardware RAID at all.

>
> I am planning two groupings of RAID1 (it has 4 bays).
>
> There is also an internal USB boot port.
>
> So I am really a newbie in working with RAID.  From this thread it
> sounds like I want /boot and /boot/efi on that USBVV boot device.

I suggest to use the USB device only to bot the installation medium, not
use it for anything used by the OS.

>
> Will it work to put / on the first RAID group?  What happens if the 1st
> drive fails and it is replaced with a new blank drive.  Will the config
> in /boot figure this out or does the RAID hardware completely mask the 2
> drives and the system runs on the good one while the new one is being
> replicated?

I guess the best thing would be to use Linux Software RAID and create a
small RAID1 (MD0) device for /boot and another one for /boot/efi (MD1),
both in the beginning of disk 0 and 1 (MD2). The remaining space on disk 0
and 1 are created as another MD device. Disk 2 and 3 are also created as
one RAID1 (MD3) device. Formatting can be done like this

MD0 has filesystem for /boot
MD1 has filesystem for /boot/efi
MD2 is used as LVM PV
MD3 is used as LVM PV

All other filesystems like / or /var or /home... will be created on LVM
Logical Volumes to give you full flexibility to manage storage.

Regards,
Simon

>
> I also don't see how to build that boot USB stick.  I will have the
> install ISO in the boot USB port and the 4 drives set up with hardware
> RAID.  How are things figure out?  I am missing some important piece here.
>
> Oh, HP does list Redhat support for this unit.
>
> thanks for all help.
>
> Bob
>
> On 1/6/23 11:45, Chris Adams wrote:
>> Once upon a time, Simon Matter  said:
>>> Are you sure that's still true? I've done it that way in the past but
>>> it
>>> seems at least with EL8 you can put /boot/efi on md raid1 with metadata
>>> format 1.0. That way the EFI firmware will see it as two independent
>>> FAT
>>> filesystems. Only thing you have to be sure is that nothing ever writes
>>> to
>>> these filesystems when Linux is not running, otherwise your /boot/efi
>>> md
>>> raid will become corrupt.
>>>
>>> Can someone who has this running confirm that it works?
>> Yes, that's even how RHEL/Fedora set it up currently I believe.  But
>> like you say, it only works as long as there's no other OS on the system
>> and the UEFI firmware itself is never used to change anything on the FS.
>> It's not entirely clear that most UEFI firmwares would handle a drive
>> failure correctly either (since it's outside the scope of UEFI), so IIRC
>> there's been some consideration in Fedora of dropping this support.
>>
>> And... I'm not sure if GRUB2 handles RAID 1 /boot fully correctly, for
>> things where it writes to the FS (grubenv updates for "savedefault" for
>> example).  But, there's other issues with GRUB2's FS handling anyway, so
>> this case is probably far down the list.
>>
>> I think that having RAID 1 for /boot and/or /boot/efi can be helpful
>> (and I've set it up, definitely not saying "don't do that"), but has to
>> be handled with care and possibly (probably?) would need manual
>> intervention to get booting again after a drive failure or replacement.
>>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Looking for a RAID1 box

2023-01-06 Thread Simon Matter
> At Fri, 6 Jan 2023 08:39:22 +0100 CentOS mailing list 
> wrote:
>
>>
>> Hi
>>
>> > I have found a:
>> >
>> > HPE 873830-S01 ProLiant MicroServer Gen10
>> >
>> > for <$300 without drives.'?''?''?'? If I can believe the seller, it
>> has a AMD
>> > Opteron X3216 Dual-core (2 Core) 1.6GHz and 8GB Installed.
>> >
>> > It has 4 3.5" bays. and 1? "Media" bay?
>> >
>> > https://www.servertechsupply.com/873830-s01/
>> >
>> > this could well be acceptable.'?''?''?'? Got to find out power
>> draw.'?''?''?'? Looks like
>> > ~40W.
>> >
>> > Any input on issues of OS install?'?''?''?'? Do I go with separate OS
>> and data
>> > RAID1 sets?
>>
>> I usually do
>>
>> [ 1(+n) RAID1 ]->[ LVM ]->[ XFS ]
>>
>> then you can use LVM to manage different filesystems as required.
>>
>> /boot and/or /boot/efi should be on its own RAID1 with old metadata
>> version but I'm not up to date about how the situation is exactly with
>> EL9.
>
> It depends on the version of Grub.  Grub V1 needs /boot to be RAID1 with
> old
> metadata (metadata at the *end* of the partition, so Grub just sees a
> plain
> ext2/3/4 file system to find vmlinuz and initrd).  Note: /boot/efi or the
> grub
> fs that Grub2 seems to want cannot be RAID, but you should duplicate the
> partitions across all of the physical disks in the raid set and arange
> some
> other way of "mirroring" them (eg rsync or some such -- does not need to
> be
> continious, since these file systems don't change continuiously).  I
> believe
> Grub V2 understands raid and LVM, so having a separate /boot raid set
> might
> not be needed.  Things like /boot/efi and grub's on fs still need to exist
> outside of the raid set and will need "manual" mirroring.

Are you sure that's still true? I've done it that way in the past but it
seems at least with EL8 you can put /boot/efi on md raid1 with metadata
format 1.0. That way the EFI firmware will see it as two independent FAT
filesystems. Only thing you have to be sure is that nothing ever writes to
these filesystems when Linux is not running, otherwise your /boot/efi md
raid will become corrupt.

Can someone who has this running confirm that it works?

Thanks,
Simon

>
>>
>> Simon
>>
>> >
>> > Also HPE is ClearOS.'?''?''?'? I ran ClearOS6 for years before going
>> with QNAP
>> > turnkey.'?''?''?'? Perhaps current ClearOS is better, but it does not
>> handle
>> > multi-domain email as I need.'?''?''?'? Or it did not.'?''?''?'? So I
>> am going to install
>> > my own CentOS variant and iRedMail...
>> >
>> > thanks
>> >
>> >
>> > On 1/5/23 13:08, Jon LaBadie wrote:
>> >> On Thu, Jan 05, 2023 at 08:18:08AM -0500, Robert Moskowitz wrote:
>> >>> Proliant gen8 does NOT have UEFI.
>> >>>
>> >>> So I think this means I better move up to the gen10...
>> >>>
>> >>
>> >> I'm pleased with my Gen 10+ (Plus).'?''?''?'? Pricer than I thought
>> >> you want.
>> >>
>> >> I like the "no power supply", just an external brick.
>> >> Quiet.'?''?''?'? I put in a PCI card to use 2 NVMe sticks, one for
>> >> system and one for /home.'?''?''?'? You can also boot from an
>> internal
>> >> usb port like a thumb drive permanently installed.
>> >>
>> >> Carriers for 2.5inch SSD drives work fine so with few fans,
>> >> no drive motors, could be quite low power.
>> >>
>> >> Mine acts as email server, local caching DNS server (dnsmasq)
>> >> and Amanda backup server.
>> >>
>> >> Jon
>> >>
>> >
>> >
>> > ___
>> > CentOS mailing list
>> > CentOS@centos.org
>> > https://lists.centos.org/mailman/listinfo/centos
>> >
>>
>>
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
>>
>
> --
> Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
> Deepwoods Software-- Custom Software Services
> http://www.deepsoft.com/  -- Linux Administration Services
> hel...@deepsoft.com   -- Webhosting Services
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Looking for a RAID1 box

2023-01-05 Thread Simon Matter
Hi

> I have found a:
>
> HPE 873830-S01 ProLiant MicroServer Gen10
>
> for <$300 without drives.  If I can believe the seller, it has a AMD
> Opteron X3216 Dual-core (2 Core) 1.6GHz and 8GB Installed.
>
> It has 4 3.5" bays. and 1? "Media" bay?
>
> https://www.servertechsupply.com/873830-s01/
>
> this could well be acceptable.  Got to find out power draw.  Looks like
> ~40W.
>
> Any input on issues of OS install?  Do I go with separate OS and data
> RAID1 sets?

I usually do

[ 1(+n) RAID1 ]->[ LVM ]->[ XFS ]

then you can use LVM to manage different filesystems as required.

/boot and/or /boot/efi should be on its own RAID1 with old metadata
version but I'm not up to date about how the situation is exactly with
EL9.

Simon

>
> Also HPE is ClearOS.  I ran ClearOS6 for years before going with QNAP
> turnkey.  Perhaps current ClearOS is better, but it does not handle
> multi-domain email as I need.  Or it did not.  So I am going to install
> my own CentOS variant and iRedMail...
>
> thanks
>
>
> On 1/5/23 13:08, Jon LaBadie wrote:
>> On Thu, Jan 05, 2023 at 08:18:08AM -0500, Robert Moskowitz wrote:
>>> Proliant gen8 does NOT have UEFI.
>>>
>>> So I think this means I better move up to the gen10...
>>>
>>
>> I'm pleased with my Gen 10+ (Plus).  Pricer than I thought
>> you want.
>>
>> I like the "no power supply", just an external brick.
>> Quiet.  I put in a PCI card to use 2 NVMe sticks, one for
>> system and one for /home.  You can also boot from an internal
>> usb port like a thumb drive permanently installed.
>>
>> Carriers for 2.5inch SSD drives work fine so with few fans,
>> no drive motors, could be quite low power.
>>
>> Mine acts as email server, local caching DNS server (dnsmasq)
>> and Amanda backup server.
>>
>> Jon
>>
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] CentOS Stream 8 sssd.service failing part of sssd-common-2.8.1-1.el8.x86_64 baseos package

2023-01-03 Thread Simon Matter
> On 1/3/23 05:17, Orion Poplawski wrote:
>> On 12/30/22 04:06, Jelle de Jong wrote:
>>> On 12/27/22 22:55, Gordon Messmer wrote:
 On 2022-12-25 07:44, Jelle de Jong wrote:
> A recent update of the sssd-common-2.8.1-1.el8.x86_64 package is
> causing sssd.service systemctl failures all over my CentosOS
> machines.
 ...
> [sssd] [confdb_expand_app_domains] (0x0010): No domains configured,
> fatal error!


 Were you previously using sssd?  Or is the problem merely that it is
 now reporting an error starting a service that you don't use?

 Are there any files in /etc/sssd/conf.d, or does /etc/sssd/sssd.conf
 exist?  If so, what are the contents of those files?

 What are the contents of /usr/lib/systemd/system/sssd.service?

 If you run "journalctl -u sssd.service", are there any log entries
 older than the package update?
>>>
>>> I got a monitoring system for failing services and I sudenly started
>>> getting dozens of notifications for all my CentOS systems that sssd
>>> was failing. This is after the sssd package updates, causing this
>>> regression. SSSD services where not really in use but some of the
>>> common libraries are used.
>>>
>>> # systemctl status sssd
>>> ● sssd.service - System Security Services Daemon
>>>     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled;
>>> vendor preset: enabled)
>>>     Active: failed (Result: exit-code) since Sat 2022-12-24 06:14:10
>>> UTC; 6 days ago
>>> Condition: start condition failed at Fri 2022-12-30 11:02:01 UTC; 4s
>>> ago
>>>     ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met
>>>     └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met
>>>   Main PID: 3953157 (code=exited, status=4)
>>>
>>> Warning: Journal has been rotated since unit was started. Log output
>>> is incomplete or unavailable.
>>
>>
>>> # ls -halZ /etc/sssd/sssd.conf
>>> ls: cannot access '/etc/sssd/sssd.conf': No such file or directory
>>
>> Looks like you need to figure out what happened to your
>> /etc/sssd/sssd.conf file.  FWIW - I've updated my one CS8 machine to
>> 2.8.1-1 and it seems to be fine.
>
> I did not do anything specific to the configuration file. I tried to
> reinstall the new sssd-common pacakge, but it will not install the
> /etc/sssd/sssd.conf file. I can not remove the package because it will
> remove a lot of packages that I do need. I still think something is
> wrong with the new sssd packages..
>
> [root@nginx01 ~]# rpm -qplc sssd-common-2.8.1-1.el8.x86_64.rpm
> /etc/logrotate.d/sssd
> /etc/pam.d/sssd-shadowutils
> /etc/rwtab.d/sssd
> /etc/sssd/sssd.conf

Most likely the file /etc/sssd/sssd.conf is a ghost file and therefore
it's not installed but only recognized as being part of the package.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] set default permission to deployuser:deployuser for nfs common mount point /mnt/test

2022-11-09 Thread Simon Matter
> On Wed, Nov 9, 2022 at 3:26 PM Simon Matter 
> wrote:
>
>> > On Mon, Nov 7, 2022 at 8:50 AM Kaushal Shriyan
>> > >
>> > wrote:
>> >
>> >> Thanks Emmett for the suggestion. I will keep you posted once it is
>> >> done.
>> >> Thanks in advance.
>> >>
>> >>
>> > Hi Emmett,
>> >
>> > I have a follow up question regarding permissions. I am running a php
>> > application hosted on the nginx version: nginx/1.22.0
>> > using php74-fpm-7.4.32-1.el7.ius.x86_64  running on CentOS Linux
>> release
>> > 7.9.2009 (Core)I have this folder
>> > /var/www/html/gsmaidp/web/sites/default/files folder which is owned by
>> > deployuser.
>> >
>> > *drwrwsrwx 25 deployuser deployuser  4096 Nov  9 08:23 files*
>> >
>> > #id deployuser
>> > uid=1001(deployuser) gid=1002(deployuser)
>> > groups=1002(deployuser),995(nginx),994(php-fpm)
>> >
>> > ps aux | grep php
>> > root 27692  0.0  0.0 473296 14648 ?Ss   09:23   0:00
>> php-fpm:
>> > master process (/etc/php-fpm.conf)
>> > nginx27693  0.0  0.1 475476 17980 ?S09:23   0:00
>> php-fpm:
>> > pool www
>> > nginx27694  0.0  0.1 475476 16440 ?S09:23   0:00
>> php-fpm:
>> > pool www
>> > nginx27695  0.0  0.1 475476 16412 ?S09:23   0:00
>> php-fpm:
>> > pool www
>> > nginx27696  0.0  0.1 475476 16420 ?S09:23   0:00
>> php-fpm:
>> > pool www
>> > nginx27697  0.0  0.1 475492 16428 ?S09:23   0:00
>> php-fpm:
>> > pool www
>> >
>> > ps aux | grep nginx
>> > root  3392  0.0  0.0  51264  1368 ?Ss   Oct21   0:00
>> nginx:
>> > master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
>> > nginx 3393  0.0  0.0  52356  4380 ?SOct21   0:51
>> nginx:
>> > worker process
>> > nginx 3394  0.0  0.0  52396  4648 ?SOct21   1:45
>> nginx:
>> > worker process
>> > nginx 3395  0.0  0.0  52488  4648 ?SOct21   5:38
>> nginx:
>> > worker process
>> > nginx 3396  0.0  0.0  52500  4652 ?SOct21   8:32
>> nginx:
>> > worker process
>> > nginx27693  0.0  0.1 475476 17980 ?S09:23   0:00
>> php-fpm:
>> > pool www
>> > nginx27694  0.0  0.1 475476 16440 ?S09:23   0:00
>> php-fpm:
>> > pool www
>> > nginx27695  0.0  0.1 475476 16412 ?S09:23   0:00
>> php-fpm:
>> > pool www
>> > nginx27696  0.0  0.1 475476 16420 ?S09:23   0:00
>> php-fpm:
>> > pool www
>> > nginx27697  0.0  0.1 475492 16428 ?S09:23   0:00
>> php-fpm:
>> > pool www
>> >
>> > Whenever any new files like images or pdf files or new subfolders
>> created
>> > inside /var/www/html/gsmaidp/web/sites/default/files folder by the php
>> > application the files or subfolders have user and group ownership of
>> nginx
>> > user.
>> >
>> > Is there a way to have ownership of all new files and subfolders to
>> > deployuser created under
>> /var/www/html/gsmaidp/web/sites/default/files. I
>> > set SETGID (SET Group ID) flag of chmod as per below but the file is
>> still
>> > owned by nginx user.
>> >
>> > #cd  /var/www/html/gsmaidp/web/sites/default/
>> > #chmod g+s files
>>
>> also do chmod 2775 files
>> then, create a file in files/ as user nginx, it should then be owned by
>> nginx:deployuser
>>
>> I think you can not set owner this way, only the group.
>>
>> >
>> > I also tried the ACL method but the new files and  subfolders are
>> still
>> > owned by nginx user.
>> >
>> > #setfacl -Rdm u:deployuser:rwx,g:deployuser:rwx,o::rwx files
>> > #setfacl -Rm u:deployuser:rwx,g:deployuser:rwx,o::rwx files
>>
>> I guess fiddling with ACLs just makes it more complicated :)
>>
>> Regards,
>> Simon
>>
>>
> Thanks Simon for the email response. Is there a way to have consistent
> deployuser (user and group ownership) on new files and subfolders created
> inside files directory?
>
> cd /var/www/html/gsmaidp/web/sites/default/files/
>
> #ls -l  image15.png
> -rw-rw-r--+ 1 nginx deployuser  387071 Nov  9 08:27 image15.png

That's the expected behaviour.

>
> to
>
> #ls -l  image15.png
> -rw-rw-r--+ 1 deployuser deployuser  387071 Nov  9 08:27 image15.png

I'm not aware of any way to do that. I thought a newly created file always
has the ownership of the creating user. Maybe it's possible somehow but I
don't know it.

>
> Apologies for bugging. Please suggest further. Thanks in advance
>
> Best Regards,
>
> Kaushal
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] set default permission to deployuser:deployuser for nfs common mount point /mnt/test

2022-11-09 Thread Simon Matter
> On Mon, Nov 7, 2022 at 8:50 AM Kaushal Shriyan 
> wrote:
>
>> Thanks Emmett for the suggestion. I will keep you posted once it is
>> done.
>> Thanks in advance.
>>
>>
> Hi Emmett,
>
> I have a follow up question regarding permissions. I am running a php
> application hosted on the nginx version: nginx/1.22.0
> using php74-fpm-7.4.32-1.el7.ius.x86_64  running on CentOS Linux release
> 7.9.2009 (Core)I have this folder
> /var/www/html/gsmaidp/web/sites/default/files folder which is owned by
> deployuser.
>
> *drwrwsrwx 25 deployuser deployuser  4096 Nov  9 08:23 files*
>
> #id deployuser
> uid=1001(deployuser) gid=1002(deployuser)
> groups=1002(deployuser),995(nginx),994(php-fpm)
>
> ps aux | grep php
> root 27692  0.0  0.0 473296 14648 ?Ss   09:23   0:00 php-fpm:
> master process (/etc/php-fpm.conf)
> nginx27693  0.0  0.1 475476 17980 ?S09:23   0:00 php-fpm:
> pool www
> nginx27694  0.0  0.1 475476 16440 ?S09:23   0:00 php-fpm:
> pool www
> nginx27695  0.0  0.1 475476 16412 ?S09:23   0:00 php-fpm:
> pool www
> nginx27696  0.0  0.1 475476 16420 ?S09:23   0:00 php-fpm:
> pool www
> nginx27697  0.0  0.1 475492 16428 ?S09:23   0:00 php-fpm:
> pool www
>
> ps aux | grep nginx
> root  3392  0.0  0.0  51264  1368 ?Ss   Oct21   0:00 nginx:
> master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
> nginx 3393  0.0  0.0  52356  4380 ?SOct21   0:51 nginx:
> worker process
> nginx 3394  0.0  0.0  52396  4648 ?SOct21   1:45 nginx:
> worker process
> nginx 3395  0.0  0.0  52488  4648 ?SOct21   5:38 nginx:
> worker process
> nginx 3396  0.0  0.0  52500  4652 ?SOct21   8:32 nginx:
> worker process
> nginx27693  0.0  0.1 475476 17980 ?S09:23   0:00 php-fpm:
> pool www
> nginx27694  0.0  0.1 475476 16440 ?S09:23   0:00 php-fpm:
> pool www
> nginx27695  0.0  0.1 475476 16412 ?S09:23   0:00 php-fpm:
> pool www
> nginx27696  0.0  0.1 475476 16420 ?S09:23   0:00 php-fpm:
> pool www
> nginx27697  0.0  0.1 475492 16428 ?S09:23   0:00 php-fpm:
> pool www
>
> Whenever any new files like images or pdf files or new subfolders created
> inside /var/www/html/gsmaidp/web/sites/default/files folder by the php
> application the files or subfolders have user and group ownership of nginx
> user.
>
> Is there a way to have ownership of all new files and subfolders to
> deployuser created under /var/www/html/gsmaidp/web/sites/default/files. I
> set SETGID (SET Group ID) flag of chmod as per below but the file is still
> owned by nginx user.
>
> #cd  /var/www/html/gsmaidp/web/sites/default/
> #chmod g+s files

also do chmod 2775 files
then, create a file in files/ as user nginx, it should then be owned by
nginx:deployuser

I think you can not set owner this way, only the group.

>
> I also tried the ACL method but the new files and  subfolders are still
> owned by nginx user.
>
> #setfacl -Rdm u:deployuser:rwx,g:deployuser:rwx,o::rwx files
> #setfacl -Rm u:deployuser:rwx,g:deployuser:rwx,o::rwx files

I guess fiddling with ACLs just makes it more complicated :)

Regards,
Simon

>
> #ls -l  image15.png
> -rw-rw-r--+ 1 nginx nginx  387071 Nov  9 08:27 image15.png
>
> Do i need to run any add cron entry to have consistent ownership of
> deployuser for all files and subfolders created under
> /var/www/html/gsmaidp/web/sites/default/files
> * * * * * root chown -R  deployuser.deployuser
> /var/www/html/gsmaidp/web/sites/default/files
>
> Am I missing anything above? Please guide me. Thanks in advance.
>
> Best Regards,
>
> Kaushal
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Trouble with kernel-3.10.0-1160.80.1.el7.x86_64

2022-11-08 Thread Simon Matter
> Is anyone else experiencing trouble with
> kernel-3.10.0-1160.80.1.el7.x86_64?
> I'm seeing a kernel panics in the kvm module on one of our VM hosts with
> it.
>
> I did notice a new libvirt update as well, but it seems to work fine with
> the
> older kernel (.76.1).

Where did you get the .80.1 kernel from? I'm a bit confused because I can
only see .76.1 on my systems.

Simon

>
> --
> Orion Poplawski
> IT Systems Manager 720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] set default permission to deployuser:deployuser for nfs common mount point /mnt/test

2022-11-05 Thread Simon Matter
> Hi,
>
> I am running two GCP GCE VM instances running CentOS Linux release
> 7.9.2009
> (Core) behind https load balancer. I am using
> https://cloud.google.com/filestore#documentation to mount the nfs server
> common mount point to both client servers.
>
> #mount 10.0.0.2:/vol1 /mnt/test
>
> I did chown -Rc deployuser:deployuser (user:group) /mnt/test. When the php
> code uploads any file to the /mnt/test folder, the file permission is
> owned
> by php-fpm:php-fpm (user:group)

Wouldn't it be easiest to run the PHP code as user deployuser?

Otherwise you may have to fiddle with setuid/setgid flags on the
directories in /mnt/test.

Regards,
Simon

>
> Please guide and let me know how to set it to the default permissions
> of deployuser:deployuser (user:group) for all files and folders created in
> nfs server common point /mnt/test.
>
> Thanks in advance.
>
> Best Regards,
>
> Kaushal
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Fedora EPEL vs Oracle EPEL

2022-09-08 Thread Simon Matter
> Hi folks,
>
> Are there any Oracle Linux users here? What are you doing with EPEL? Do
> you use Fedora EPEL, or Oracle EPEL? What are your reasons for using one
> or the other?
>
> I am aware that these two repos are quite similar, but not identical.

I _was_ using some Oracle Linux 8 in the past and decided to use it with
Fedora EPEL. Back then Oracle EPEL was was lacking some latest packages
found in Fedora EPEL and therefore Fedora seemed the better choice.

I don't know how the situation is today because I moved to AlmaLinux with
Fedora EPEL.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] building ngx_cache_purge module on CentOS Linux release 7.9.2009 (Core).

2022-05-07 Thread Simon Matter
Hi,

> Hi,
>
> I am referring to https://github.com/FRiCKLE/ngx_cache_purge/ and running
> the open source nginx version: nginx/1.20.2 on CentOS Linux release
> 7.9.2009 (Core). When i trying to compile the ngx_cache_purge_module.c I
> am
> encountering fatal error: nginx.h: No such file or directory
>
> # ls -l
> total 76
> -rw-r--r-- 1 501 wheel  1980 Dec 23  2014 CHANGES
> -rw-r--r-- 1 501 wheel   516 Dec 23  2014 config
> -rw-r--r-- 1 501 wheel  1424 Dec 23  2014 LICENSE
> -rw-r--r-- 1 501 wheel 51501 Dec 23  2014 ngx_cache_purge_module.c
> -rw-r--r-- 1 501 wheel  5090 Dec 23  2014 README.md
> drwxr-xr-x 2 501 wheel80 May  7 02:22 t
> -rw-r--r-- 1 501 wheel   281 Dec 23  2014 TODO.md
> #
>
> #gcc -o ngx_cache_purge_module ngx_cache_purge_module.c
> ngx_cache_purge_module.c:30:19: fatal error: nginx.h: No such file or
> directory
>  #include 
>^
> compilation terminated.
>
> # yum search nginx-devel
> Loaded plugins: fastestmirror
> Loading mirror speeds from cached hostfile
>  * base: uk.mirrors.clouvider.net
>  * centos-sclo-rh: uk.mirrors.clouvider.net
>  * epel: d2lzkl7pfhq30w.cloudfront.net
>  * extras: mirrors.vinters.com
>  * updates: mirrors.vinters.com
> Warning: No matches found for: nginx-devel
> No matches found
> # rpm -qa | grep epel
> epel-release-7-14.noarch
> # cat /etc/redhat-release
> CentOS Linux release 7.9.2009 (Core)
> #
>
> Please correct me if I am missing something. Thanks in advance.

I can only guess but I think there is no -devel package available. What I
found is nginx-mod-devel and it includes the nginx.h file. Maybe you need
this to compile.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Process owned by a user running after logout

2022-03-10 Thread Simon Matter
Hi,

> Update:
> If I change the user's default shell from csh to bash the problem is
> fixed.
> However, we have most of our scripts for EDA tools written in csh

Apart from that, which version of dbus is installed on your system?

There was a bug in dbus-1.12.8-11 and later which could be the root of
your issue. I'm not sure this is already fixed in C8s.

Simon

>
>
> -Original Message-
> From: "Hooton, Gerard"
> mailto:%22Hooton,%20gerard%22%20%3cg.hoo...@ucc.ie%3e>>
> Reply-To: CentOS mailing list
> mailto:centos%20mailing%20list%20%3ccen...@centos.org%3e>>
> To: centos@centos.org
> mailto:%22cen...@centos.org%22%20%3ccen...@centos.org%3e>>
> Subject: [CentOS] Process owned by a user running after logout
> Date: Thu, 10 Mar 2022 11:41:22 +
> Mailer: Evolution 3.36.5-0ubuntu1
>
>
> [EXTERNAL] This email was sent from outside of UCC.
>
>
> After logout, process owned by the logged out user keep running.
>
> If a user connects using ssh and then, without starting any programs,
> signs out the following processes remain running
>
>
> 4 S Tom  1808940   1  0  80   0 - 22440 do_epo 11:08 ?00:00:00
> /usr/lib/systemd/systemd --user
>
> 5 S Tom  1808943 1808940  0  80   0 - 75441 -  11:08 ?00:00:00
> (sd-pam)
>
> 0 S Tom  1809033   1  0  80   0 - 108596 x64_sy 11:08 ?   00:00:00
> gio monitor -f /run/systemd/sessions/13496
>
> 0 S Tom  1809062 1808940  0  80   0 - 16095 do_epo 11:08 ?00:00:00
> /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile
> --systemd-activation --syslog-only
>
>
> This only applies to users who use ssh, when using the system console
> [Gnome 3 desktop] all processes own by a user stop when that user  signs
> out.
>
> I have a number of users who use the computer for remote access and the
> number of these running process grows over a few weeks.
>
>
> I am using CentOS Stream 8.
>
> Kernel :  4.18.0-365.el8.x86_64 #1 SMP Thu Feb 10 16:11:23 UTC 2022 x86_64
> x86_64 x86_64 GNU/Linux
>
>
>
>
> ___
>
> CentOS mailing list
>
> 
>
> CentOS@centos.org
>
>
> 
>
> https://lists.centos.org/mailman/listinfo/centos
>
>
> --
>
> Gerard Hooton.
> Senior Technical Officer
> School of Engineering.
> University College Cork.
> College Road.
> Cork.
> Ireland.
> Loc8: WDR-04-60G
> Tel: +353 21 4902296
> Mobile: +353 852813491
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] vault.centos.org down

2022-03-01 Thread Simon Matter
> On Tue, 1 Mar 2022 16:36:55 -0700
> Nels Lindquist wrote:
>
>> I've been unable to access it at all for the past couple of days, either
>> through a browser or yum.
>
> https://downforeveryoneorjustme.com/vault.centos.org

Doesn't help here because downforeveryoneorjustme.com is not working
currently:

 Error 520 Ray ID: 6ae04324820783 • 2022-03-02 07:23:20 UTC
Web server is returning an unknown error
You
Browser
Working

Frankfurt
Cloudflare
Working

downforeveryoneorjustme.com
Host
Error

Nice new world, clouds everywhere, how can they fail :)

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] vault.centos.org down

2022-03-01 Thread Simon Matter
> On 2/28/22 23:46, Simon Matter wrote:
>> Yes, also mostly down for me. Some requests were answered but unable to
>> really use the site.
>
>
> Is it just overloaded?  I've seen a few examples recently of people
> building CentOS 8 containers by building repo definitions that reference
> vault.  Naturally, I asked them to stop doing that...
>
> If overload is the problem, I'd suggest that making the site *less*
> reliable might eventually fix the problem.  In particular, dropping
> requests for repomd.xml would probably shed a lot of load while still
> giving human users access to package files.

In my case I was just trying with firefox to get some files and browsing
wasn't possible at all. Suddenly some pages were shown and then connection
was stuck again. However, currently it works fine for me.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] vault.centos.org down

2022-02-28 Thread Simon Matter
> Is anyone else having issues getting to vault.centos.org right now? I'm
> getting connection timed out on the web page, but I can ping the server:
> $ ping vault.centos.org
> PING vault.centos.org (54.186.51.210) 56(84) bytes of data.
> 64 bytes from ec2-54-186-51-210.us-west-2.compute.amazonaws.com
> (54.186.51.210): icmp_seq=1 ttl=25 time=67.1 ms
> 64 bytes from ec2-54-186-51-210.us-west-2.compute.amazonaws.com
> (54.186.51.210): icmp_seq=2 ttl=25 time=66.6 ms
> 64 bytes from ec2-54-186-51-210.us-west-2.compute.amazonaws.com
> (54.186.51.210): icmp_seq=3 ttl=25 time=67.6 ms

Yes, also mostly down for me. Some requests were answered but unable to
really use the site.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [EXT] c9s: CPU ISA level lower than required

2022-02-07 Thread Simon Matter
> On 07/02/2022 16.01, Alessio wrote:
>> Hello.
>> I had a CentOS Stream 9 installation in a KVM VM.
>> Today a "dnf upgrade" lead to an unusable system: dnf, rpm commands
>> complain that "glibc cpu does not support x86-64-v2" or "CPU ISA level
>> is lower than required".
>> The updates leading to this state seem to be: python3 3.9.10-1, glibc
>> 2.34-21, rpm 4.16.1.3-10
>>
>> What happened?
>
> glibc-2.34-20 includes a fix to more reliable detect CPU compatibility.
> See Bug https://bugzilla.redhat.com/show_bug.cgi?id=2040657
>
> Does your CPU support x86-64-v2?
>
> CentOS Stream for AMD and Intel 64-bit architectures requires at least
> x86-64-v2. See [1] for some background.
>
> [1]:
> https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level#architectural_considerations_for_rhel_9

Is there an easy way to figure out if a CPU does support x86-64-v2?
Something like a list of CPU families or a list of flags to check?

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] Polkit patch for CVE-2021-4034 for CentOS 6

2022-01-26 Thread Simon Matter
Hi,

For those still running CentOS 6 somewhere, the patch below can be added
to the source RPM.

Verified to fix the issue on CentOS 6.10 x86_64 with this exploit:

https://packetstormsecurity.com/files/165728/Polkit-pkexec-CVE-2021-4034-Proof-Of-Concept.html

Regards,
Simon

PS: Sure, I know nobody is really running old EL6 anymore :-)

diff -Naupr polkit-0.96.patched/src/programs/pkcheck.c
polkit-0.96/src/programs/pkcheck.c
--- polkit-0.96.patched/src/programs/pkcheck.c  2022-01-26
17:03:29.059789167 +0100
+++ polkit-0.96/src/programs/pkcheck.c  2022-01-26 17:04:34.051159050 +0100
@@ -96,6 +96,11 @@ main (int argc, char *argv[])
   allow_user_interaction = FALSE;
   ret = 126;

+  if (argc < 1)
+{
+  exit(126);
+}
+
   g_type_init ();

   details = polkit_details_new ();
diff -Naupr polkit-0.96.patched/src/programs/pkexec.c
polkit-0.96/src/programs/pkexec.c
--- polkit-0.96.patched/src/programs/pkexec.c   2022-01-26
17:03:29.046789093 +0100
+++ polkit-0.96/src/programs/pkexec.c   2022-01-26 17:04:34.056159079 +0100
@@ -415,6 +415,14 @@ main (int argc, char *argv[])
   gchar *opt_user;
   pid_t pid_of_caller;

+  /*
+   * If 'pkexec' is called THIS wrong, someone's probably evil-doing.
Don't be nice, just bail out.
+   */
+  if (argc < 1)
+{
+  exit(127);
+}
+
   ret = 127;
   authority = NULL;
   subject = NULL;
@@ -520,7 +528,15 @@ main (int argc, char *argv[])
   goto out;
 }
   g_free (path);
-  argv[n] = path = s;
+  path = s;
+
+  /* argc<2 and pkexec runs just shell, argv is guaranteed to be
null-terminated.
+   * /-less shell shouldn't happen, but let's be defensive and don't
write to null-termination
+   */
+  if (argv[n] != NULL)
+  {
+argv[n] = path;
+  }
 }
   if (access (path, F_OK) != 0)
 {


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ping as regular user not allowed (CentOS Stream 8)

2022-01-20 Thread Simon Matter
> Am 19.01.22 um 15:44 schrieb Brian Stinson:
>> On Wed, Jan 19, 2022 at 8:33 AM Toralf Lund  wrote:
>>>
>>> Following some update or the other (I think) on my CentOS Stream 8
>>> system, I'm no longer able to use ping as a regular user; I get
>>>
>>> $ ping www.centos.org
>>> ping: socket: Operation not permitted
>>>
>>> Does anyone else see this? It it a bug, or were the system/default
>>> permissions deliberately changed? Can anyone suggest a fix/workaround?
>>> Actually, I can find several different ones via a simple web search,
>>> but
>>> they are generally related to other distributions, I'm not quite sure
>>> which would be the most appropriate for CentOS...
>>>
>
>
> I also noticed this "change".
>
>
>>
>> Folks interested in this issue can watch this bugzilla:
>> https://bugzilla.redhat.com/show_bug.cgi?id=2037807
>>
>> We're waiting for systemd-239-55.el8 sources to show up after which we
>> will build this and publish to CentOS Stream. Right now this appears
>> to be an infrastructure issue and the appropriate folks are working on
>> that, but we also want this package to pass the proper checks before
>> we build.
>>
>
>
> Is this a regression of the last systemd update?

Yes, systemd, this new operating system which still lacks a kernel ;-)

But seriously, this should be a warning how dangerous even the smallest
bug in systemd can be. In this case it's absolutely harmless but it shows
once more how domineering systemd became to be in the Linux ecosystem.

A bit frightening for me.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Is CentOS-Stream-9-20211222.0 suitable for building for RHEL9

2022-01-06 Thread Simon Matter
> On Thu, Jan 6, 2022 at 4:15 AM Simon Matter 
> wrote:
>>
>> > On 1/5/22 05:06, Leon Fauster via CentOS wrote:
>> >> Am 05.01.22 um 11:02 schrieb Simon Matter:
>> >>> Hi,
>> >>> I have to port/build quite a number of packages for upcoming RHEL9.
>> I
>> thought about starting to do so now on CentOS-Stream-9-20211222.0 in
>> the
>> >>> hope that I don't have to redo a lot of the work again later for the
>> released RHEL9.
>> >>> Does it sound like a good idea to start now or should I better wait
>> a
>> bit?
>> >> I'm already doing that. Do just expect everything that also happened
>> in
>> EL8. Missing devel or sub packages. Striped down s/rpm macros that
>> blocks building fedora packages directly. So, business as usual. BTW,
>> some packages are not in streams anymore. This makes custom
>> overlay
>> >> repos a bit easier ...
>> > I think you can build directly against the repos in the centos stream
>> koji.
>> > https://kojihub.stream.centos.org/kojifiles/
>>
>> We're not using koji so I don't know how I could make use of these
>> repos.
>>
>> I've done a number of the easier builds now and they went well. Now I'm
>> trying to build a package which requires imake but I can't find it
>> anywhere.
>>
>> I guess imake could be missing because the Xorg stuff is being built
>> without it today?
>>
>> Does anybody know if imake is still used but not shipped or is it not
>> used
>> and built for EL9 anymore?
>
> imake is not included in EL9 at all.  It could be packaged and added
> to EPEL9 for those interested in doing so.

So, can we expect that what is included in baseos+appstream+crb is what
will be available in RHEL9?

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Is CentOS-Stream-9-20211222.0 suitable for building for RHEL9

2022-01-06 Thread Simon Matter
> On 1/5/22 05:06, Leon Fauster via CentOS wrote:
>> Am 05.01.22 um 11:02 schrieb Simon Matter:
>>> Hi,
>>> I have to port/build quite a number of packages for upcoming RHEL9. I
thought about starting to do so now on CentOS-Stream-9-20211222.0 in
the
>>> hope that I don't have to redo a lot of the work again later for the
released RHEL9.
>>> Does it sound like a good idea to start now or should I better wait a
bit?
>> I'm already doing that. Do just expect everything that also happened in
EL8. Missing devel or sub packages. Striped down s/rpm macros that
blocks building fedora packages directly. So, business as usual. BTW,
some packages are not in streams anymore. This makes custom
overlay
>> repos a bit easier ...
> I think you can build directly against the repos in the centos stream koji.
> https://kojihub.stream.centos.org/kojifiles/

We're not using koji so I don't know how I could make use of these repos.

I've done a number of the easier builds now and they went well. Now I'm
trying to build a package which requires imake but I can't find it
anywhere.

I guess imake could be missing because the Xorg stuff is being built
without it today?

Does anybody know if imake is still used but not shipped or is it not used
and built for EL9 anymore?

Thanks,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


[CentOS] Is CentOS-Stream-9-20211222.0 suitable for building for RHEL9

2022-01-05 Thread Simon Matter
Hi,

I have to port/build quite a number of packages for upcoming RHEL9.

I thought about starting to do so now on CentOS-Stream-9-20211222.0 in the
hope that I don't have to redo a lot of the work again later for the
released RHEL9.

Does it sound like a good idea to start now or should I better wait a bit?

Thanks,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] log4j cve

2021-12-14 Thread Simon Matter
> Hello Steve,
>
> Am 2021-12-14 14:14, schrieb Steve Clark:
>>  This is the standard version that comes with CentOS 7 and is the
>> latest available as of a yum update just now.
>> log4j-1.2.17-16.el7_4.noarch
>
> yes, that's correct, but it is abandoned nonetheless.
>
> According to the RPM's change log, Red Hat backported a fix for
> CVE-2017-5645.
> They have not done this for CVE-2019-17571 it seems.
> I would be very surprised if they'd do so now.

It seems CVE-2019-17571 is also covered by the fix for CVE-2017-5645:

https://access.redhat.com/node/4677071

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] mounting XFS RAID-1 disk partition that needs repair.

2021-11-24 Thread Simon Matter
> haven't tried the suggestions yet, but here is some diagnostics on what
> happens when I attempt to mount it:
> upon running *mdadm --assemble /dev/md40 /mnt/dvd --run*, info from
> /var/log/messages):
> (note that /mnt/dvd is just an empty mount point that exists, used here
> for
> convenience).
>
> Nov 24 12:21:42 fcshome kernel: md: md40 stopped.
> Nov 24 12:21:42 fcshome kernel: md/raid1:md40: active with 1 out of 2
> mirrors
> Nov 24 12:21:42 fcshome kernel: md40: detected capacity change from 0 to
> 996887429120
>
> output from doing:
> sudo mount /dev/md40 /mnt/dvd
> mount: mount /dev/md40 on /mnt/dvd failed: Structure needs cleaning
>
> corresponding items from /var/log/messages:
> Nov 24 12:22:55 fcshome kernel: XFS (md40): Superblock earlier than
> Version
> 5 has XFS_[PQ]UOTA_{ENFD|CHKD} bits.
> Nov 24 12:22:55 fcshome kernel: XFS (md40): Metadata corruption detected
> at
> xfs_sb_read_verify+0x122/0x160 [xfs], xfs_sb block 0xff
> ff
> Nov 24 12:22:55 fcshome kernel: XFS (md40): Unmount and run xfs_repair
> Nov 24 12:22:55 fcshome kernel: XFS (md40): First 128 bytes of corrupted
> metadata buffer:
> Nov 24 12:22:55 fcshome kernel: 8e0c8f4e: 58 46 53 42 00 00 10 00
> 00 00 00 00 0e 81 b1 e0  XFSB
> Nov 24 12:22:55 fcshome kernel: 8e0c8f4e0010: 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00  
> Nov 24 12:22:55 fcshome kernel: 8e0c8f4e0020: d2 22 a7 30 dd 88 48 8b
> bd bb 9c 8b 2a 22 72 cc  .".0..H.*"r.
> Nov 24 12:22:55 fcshome kernel: 8e0c8f4e0030: 00 00 00 00 08 00 00 04
> 00 00 00 00 00 00 00 80  
> Nov 24 12:22:55 fcshome kernel: 8e0c8f4e0040: 00 00 00 00 00 00 00 81
> 00 00 00 00 00 00 00 82  
> Nov 24 12:22:55 fcshome kernel: 8e0c8f4e0050: 00 00 00 01 00 74 0d 8f
> 00 00 00 20 00 00 00 00  .t. 
> Nov 24 12:22:55 fcshome kernel: 8e0c8f4e0060: 00 00 80 00 30 c4 02 00
> 01 00 00 10 00 00 00 00  0...
> Nov 24 12:22:55 fcshome kernel: 8e0c8f4e0070: 00 00 00 00 00 00 00 00
> 0c 09 08 04 17 00 00 19  
> Nov 24 12:22:55 fcshome kernel: XFS (md40): SB validate failed with error
> -117.
>
> running xfs_repair give:
> sudo xfs_repair /dev/md40
> Phase 1 - find and verify superblock...
> xfs_repair: V1 inodes unsupported. Please try an older xfsprogs.
>
> before proceeding with other experiments, I decided to use dd to create an
> image file on my local disk of that partition so I could mess with it with
> less chance of trashing the on-disk partition. when attempting to use it,
> I
> get:
>
> sudo mdadm --assemble /dev/md41 ./part4.img --run
> mdadm: ./part4.img is not a block device.
> mdadm: ./part4.img has no superblock - assembly aborted
>
> So, I thought maybe the image had somehow become corrupted, so I did:
>
> sudo md5sum /dev/sdd4
> bd7cac3c886e7b3110e28100e119bb82  /dev/sdd4
>
> and
>
> md5sum part4.img
> bd7cac3c886e7b3110e28100e119bb82  part4.img
>
> which shows the partition and its disk image to be identical.
>
> Why shouldn't a dd image of a partition work just as well (for my
> purposes)
> as the actual disk partition? I've certainly done this before with EXTn
> and
> NTFS filesystems, is XFS somehow different in this regard?
>
> Do any of you know what I'm doing wrong here?

I'm not sure but I think you are making it too complicated.

If the partition is from a software RAID 1, then you should be able to use
it directly without building an mdadm array.

That said, it depends on the metadata type IIRC. If metadata is in the
beginning of the partition, then you have to remove it by doing a dd to a
file and skipping the metadata in the beginning of the partition.

md raid metadata locations:
0.9 At the end of the device
1.0 At the end of the device
1.1 At the beginning of the device
1.2 4K from the beginning of the device

So with metadata versions 0.9 0r 1.0, you could directly use the md
partition like a normal partition, only some bytes in the end are not used
by the filesystem.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] mounting XFS RAID-1 disk partition that needs repair.

2021-11-23 Thread Simon Matter
Hi,

> I'm attempting to extract data from a HD that has a bunch of linux-raid
> partitions, including one large one with data I need to save off the disk.
>
> I actually have two drives like that (both not from the same RAID pair),
> and one of them I was successful in creating a MD device so I could mount
> it RO and copy off a ton of data.
>
> the second one fails to mount, saying the XFS filesystem is corrupted.
> Attempting to run XFS_repair I get a message that the filesystem is XFS-1
> and I need an older version of XFS tools to do it.

Are you sure the filesystem is really corrupt? Maybe it's only your kernel
which doesn't understand the old XFS version?

To use older xfs_repair, you can just download an older version like
xfsprogs-2.9.4-1.el4.centos.x86_64.rpm, extract it to a directory and call
the xfs_repair binary from the package.

I'm not sure whether you need a matching xfs kernel module to run
xfs_repair successfully.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Ruby on Cent OS 8

2021-11-15 Thread Simon Matter
> On Mon, 15 Nov 2021 at 09:18, Nikolaos Milas  wrote:
>>
>> Another option is to migrate to an RHEL 8 -compatible OS, like Rocky
>> Linux, AlmaLinux, Oracle Linux, Springdale Linux.
>>
>> (I remind that CentOS Stream is no more a RHEL 8 twin.)
>>
>> I have already migrated successfully all my CentOS 8 boxes to Rocky. (I
>> am informed that in Academic Institutions in Greece -at least-, SysAdmin
>> teams have also selected Rocky to migrate from CentOS 8.)
>>
>> Rocky seems to be gaining momentum as the main CentOS 8 successor.
>>
>
> Going off of EPEL8 client use meters, it is still a fair tie between
> Rocky usage and Alma usage.
>
> Date | OS Name | Number of systems longer than 2 weeks old (so
> probably not CI/Containers)
> 2021-11-01 | Red Hat Enterprise Linux | 119625
> 2021-11-01 | CentOS Linux | 461424
> 2021-11-01 | CentOS Stream | 56902
> 2021-11-01 | Oracle Linux | 20683
> 2021-11-01 | AlmaLinux | 25880
> 2021-11-01 | Rocky | 28167

These figures are interesting but they can not be compared directly.
Oracle has its own EPEL repo and therefore I guess that the number here
shows only those who are using the official EPEL instead of the one
provided by Oracle. That said, I expect that the true number of Oracle
Linux installations is quite a bit higher than what we see here.

Even more interesting and worrying is the still growing number of CentOS
Linux 8 installations ;)

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] UID/GID migration vom C6 to C8

2021-11-15 Thread Simon Matter
> Hello.
>
> We have to migrate an old Centos 6 to Centos 8. C6 has UID/GID starting
> at number 500.
> I the Users should possibily keep the existing UID/GID as on the old
> system.
>
> I changed on the Centos 8 system, in /etc/login.defs, the lines
> UID_MIN/SYS_UID_MAX and GID_MIN/SYS_GID_MAX:
>
> #
> # Min/max values for automatic uid selection in useradd
> #
> UID_MIN   500
> UID_MAX 6
> # System accounts
> SYS_UID_MIN   201
> SYS_UID_MAX   499
>
> #
> # Min/max values for automatic gid selection in groupadd
> #
> GID_MIN   500
> GID_MAX 6
> # System accounts
> SYS_GID_MIN   201
> SYS_GID_MAX   499
>
> and extracted all users and groups with UID/GID greater than 499 from
> the old system and inserted in the corresponding files
> (passwd/groups/shadows) on the new system.
>
> So wanted to ask if this is a valid thing to do? Especially regarding
> security of the new system. Can it create problems in the future
> (updates etc.)?
> It is a simple LAMP server.

I was in a similar situation but on a quite large application server with
hundreds of users.
I quickly found that I don't want to fiddle with UID/GID settings so I
decided to change all users on the CentOS 6 host before migrating any
data.
I've created a script which uses `chown' to recursively change UIDs and
GIDs. I don't remember exactly but I think I made it run for every user in
parallel and it finished quite fast considering the fact that it had to
traverse the whole storage consisting of millions of files.
I could then later just rsync everything to the new box without ant
UID/GID conversion.
See below for the script `chuidgid'.

Regards,
Simon

%<-
#!/bin/bash

if (( $# < 4 )); then
  echo "Usage: $0
[...]"
  echo "Example: $0 user1 1000 \"\" /tmp /etc /usr /opt /var /home"
  echo
  echo "Important: this needs to run before changing any uid/gid!"
  exit 1
fi

USR="$1"
NEW_UID="$2"
NEW_GID="$3"

shift 3
DIRS=$@

OLD_UID=$(id -u "$USR")
OLD_GID=$(id -g "$USR")

if [[ -z "$NEW_GID" ]]; then
  NEW_GID="$NEW_UID"
fi

echo "modifying user $USR ids ${OLD_UID}:${OLD_GID} ->
${NEW_UID}:${NEW_GID} on $DIRS"

# Note: usermod changes ownership of at least $HOME and
/var/spool/mail/${USR}
groupmod -g "$NEW_GID" "$USR"
usermod -u "$NEW_UID" -g "$USR" "$USR"

chown --changes --silent --no-dereference --preserve-root --recursive
--from=":${OLD_GID}" ":${NEW_GID}" $DIRS
chown --changes --silent --no-dereference --preserve-root --recursive
--from="${OLD_UID}"   "${NEW_UID}" $DIRS
%<-

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Install OpenSSL 1.1.1 on CentOS Linux release 7.9.2009 (Core).

2021-11-09 Thread Simon Matter
> Hello Kaushal,
>
> the EPEL repository has OpenSSL 1.1 packages available:
>
> # yum install epel-release
> # yum install openssl11 openssl11-libs openssl11-devel
>
> If you want to compile software with OpenSSL 1.1 instead of 1.0
> you may have to set the proper path or environment variables
> such as LDFLAGS.
>
> Hope this helps.
>

OTOH, my first question would be why he wants to install Python 3.10? If
another Python 3.x version would work, it should be possible to install it
from EPEL, no?

That way the whole mess of building and installing Python from source
would be avoided.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] systemd does not generate both StandardOutput and StandardError files in /var/log/ directory

2021-11-05 Thread Simon Matter
Hi,

> Hi,
>
> I am running CentOS Linux release 7.9.2009 (Core). I have created a
> systemd
> service for a java service. I want to capture both stdout and stderr to
> files under /var/log directory.
> # cat /etc/redhat-release
> CentOS Linux release 7.9.2009 (Core)
> #
> # rpm -qa | grep systemd
> systemd-sysv-219-78.el7_9.3.x86_64
> systemd-libs-219-78.el7_9.3.x86_64
> systemd-219-78.el7_9.3.x86_64
>
> # cat /etc/systemd/system/smartresponse.service
> [Unit]
> Description=Smart Response Service
>
> [Service]
> WorkingDirectory=/opt/demo
> ExecStart=/bin/java -jar old2-wsb-smart-response-0.0.2-SNAPSHOT.jar
> Type=simple
> Restart=on-failure
> RestartSec=10
> StandardOutput=file:/var/log/smartresponseserviceoutput.log
> StandardError=file:/var/log/smartresponseserviceerror.log
>
> [Install]
> WantedBy=multi-user.target
> #
>
> The files /var/log/smartresponseserviceoutput.log and
> /var/log/smartresponseserviceoutput.log are not created. Please guide.

I think the "file:" method is not supported with your version of systemd. See
`man systemd.exec' for more info.

You could use a shell script to work around this limitation, something like

--%<---
#!/bin/bash

exec java -jar old2-wsb-smart-response-0.0.2-SNAPSHOT.jar >>
/var/log/smartresponseserviceoutput.log 2>>
/var/log/smartresponseserviceerror.log
--%<---

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [External] Re: Unexpected /etc/resolv.conf updates on CentOS 7

2021-10-22 Thread Simon Matter
> On 14/10/2021 08:44, Simon Matter wrote:
>>> On 13/10/2021 20:06, J Martin Rushton via CentOS wrote:
>>>> If you just want to tell NM to clear off and leave your resolv.conf
>>>> alone do the following:
>>> I might possibly be able to set up a workaround based on that, but it's
>>> not what I really want. Ideally I want NetworkManager to update
>>> resolv.conf, but only if it actually set up a new connection and/or got
>>> new information. Which is what it seemed to do in the past, but then
>>> something changed...
>> I'm not running CentOS 7 with NetworkManager so I could be wrong but,
>> isn't it possible to run DHCP internally in NM or use dhclient? If so,
>> did
>> you really check that nothing has happened there like renewing of the
>> lease?
>
> I'm not exactly sure what you mean by running DHCP internally in NM, but
> dhclient is being used. It's started automatically with a config
> generated by NetworManager, and also a NM/connection specific lease file.

I meant by default NM uses its own built in DHCP client. See here

https://wiki.archlinux.org/title/NetworkManager#DHCP_client

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] libxml2 update/packaging issues?

2021-10-20 Thread Simon Matter
Hi,

> Hello all,
>
> last Friday (Oct 15) I encountered a weird issue relating to the
> libxml2* packages.
>
> I have a script which monitors the CentOS mirrors to find new packages.
> On Friday, these showed up:
>
> libxml2-2.9.1-6.el7.5.i686.rpm
> libxml2-2.9.1-6.el7.5.x86_64.rpm
> libxml2-devel-2.9.1-6.el7.5.i686.rpm
> libxml2-devel-2.9.1-6.el7.5.x86_64.rpm
> libxml2-python-2.9.1-6.el7.5.x86_64.rpm
> libxml2-static-2.9.1-6.el7.5.i686.rpm
> libxml2-static-2.9.1-6.el7.5.x86_64.rpm
>
> However, looking at Scientific Linux
> (https://scientificlinux.org/category/sl-errata/slsa-20213810-1/)
> and Red Hat Errata (https://access.redhat.com/errata/RHSA-2021:3810) it
> seems that CentOS is one release
> behind (el7.5 from CentOS vs. el7.6 for SL and RHEL).
>

Yes, it seems the newest package has not been built from current GIT.

What's also strange is that I see libxml2 two times, in
centos/7.9.2009/updates/x86_64/Packages/ and in
centos/7.9.2009/os/x86_64/Packages/. Both with identical version but
_different_ builds.

Maybe some automated thing which went wrong?

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [External] Re: Unexpected /etc/resolv.conf updates on CentOS 7

2021-10-14 Thread Simon Matter
> On 13/10/2021 20:06, J Martin Rushton via CentOS wrote:
>> If you just want to tell NM to clear off and leave your resolv.conf
>> alone do the following:
>
> I might possibly be able to set up a workaround based on that, but it's
> not what I really want. Ideally I want NetworkManager to update
> resolv.conf, but only if it actually set up a new connection and/or got
> new information. Which is what it seemed to do in the past, but then
> something changed...

I'm not running CentOS 7 with NetworkManager so I could be wrong but,
isn't it possible to run DHCP internally in NM or use dhclient? If so, did
you really check that nothing has happened there like renewing of the
lease? And did you also check on the ethernet link level that it never
went down for a short period of time? Such things can happen in certain
configurations.

Or, could it be that you have some software which interacts with
NetworkManager via dbus and therefore the problem happens?

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Boot time in wtmp is not correct

2021-10-12 Thread Simon Matter
Hi,

> When I do who -b; uptime I get
>
> system boot  2021-10-12 17:05
>  16:36:09 up 30 min,  1 user,  load average: 0.00, 0.00, 0.00
>
> As you can see the boot time reported by the last command is ahead.
> I have noted it is  one hour ahead after a reboot.
>
> I have checked the system time in the BIOS  before booting Linux and it is
> correct.

I don't know how exactly it comes but I guess it has something to do with
local vs. system time. You have UTC as timezone but because of DST it's
one hour apart.

What does last report?

On my test system I find the reboot which is shown in the who -b output in
the last output, and the uptime reported by last again matches with the
uptime output.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] C7: NM and changing MAC addresses

2021-10-11 Thread Simon Matter
Hi,

> On Mon, 11 Oct 2021, José María Terry Jiménez wrote:
>
>> El 11/10/21 a las 13:00, Tom Yates escribió:
>>>  On Mon, 11 Oct 2021, José María Terry Jiménez wrote:
>>>
  Hello

  Perhaps the solution is this:

  https://access.redhat.com/solutions/70215HWADDR=
>>>
>>>  thanks, but either that link is broken, or the site requires a login,
>>> as i
>>>  can't see anything and get redirected to a general search page.  could
>>> i
>>>  trouble you to check the link?
>>>
>>>
>> Uh oh! Some copypaste at the end
>>
>> Is this one
>>
>> https://access.redhat.com/solutions/70215
>
> thank you very much for the suggestion!  sadly, this has not worked.
>

Are you even sure it's NetworkManager messing with your MAC addresses? I
have no idea why NM should ever mess with MAC addresses on a server and I
don't expect NM is doing so.

I have another idea: Seems this is on a SuperMicro server, can it be that
the box in question has a shared lights out management, sharing the
management ethernet port with the first LAN port? If so, can it be that
the management port is not configured properly and does try to DHCP an
IPv4 address? If you don't need the management stuff then you may try to
simply disable it to get rid of the mess.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Upgrading CentOS from 7 to 8

2021-09-30 Thread Simon Matter
> On 9/29/21 3:24 PM, Gestió Servidors wrote:
>> Hi,
>>
>> I'm doing some tests of upgrading CentOS from 7 to 8 reading this
>> step-by-step guide:
>> https://netshopisp.medium.com/how-to-upgrade-linux-servecentos-7-to-centos-8-ec2db96a189b
>>
>> I'm trying this upgrade in a VM, so I can save "snapshots" and restart
>> in a past saved point. However, all my test ends wrong, exacly in Step 4
>> when I run "rpm -e `rpm -q kernel`". Then, systems says that some
>> packages are kernel dependencies. After I remove that dependencies, I
>> can't remove kernel...

One problem which could show up here is that kernel packages have
changed/splitted and therefore things are more complicated. At least
that's what has happened in the past, don't know about 7->8.

>
> That specific step is probably useless.
> Installing new kernels for Centos8 will sooner or later remove older
> kernels coming form C7.
> If you really want to do this manually you could specify the version on
> your "rpm -e" command.
>
> If you are not ready to tweak the process a bit while upgrading and just
> expect
> a straightforward list of commands, well, as others have explained, there
> is no guaranteed
> script or method.
> If instead you have enough familiarity with the system to work around the
> obstacles,
> "impossible" things can often be done: for example, years ago I've managed
> to upgrade
> a Fedora 16 from i386 to x86_64, and everybody was swearing it was
> impossible to do.

I can confirm that because I also migrated a server from i386 to x86_64 in
place. That was with an old RHEL release.

I don't remember exactly how I did it but I think I only used rpm for it,
no yum.

Unfortunately upgrading complex systems is still a lot of work these days,
no matter what all the cloud experts try to tell you :-)

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] lvm2 2.03.12-6 CentOS Stream broke

2021-09-05 Thread Simon Matter
> Simon Matter said...
>
> "And when you downgrade lvm2, does it work again?"
>
> Thanks for the reply Simon. Found this great doc here :
> https://access.redhat.com/solutions/57300

I can't read the above because it's for `insiders' only.

>
> So I added the following filter to /etc/lvm/lvm.conf to exclude
> non-block-devices from the scan...
>
> # grep ^filter /etc/lvm/lvm.conf
> filter = [ "a|/dev/sda.*|", "a|/dev/sdb.*|", "r|/dev/sdc.*|",
> "r|/dev/sdd.*|", "r|/dev/sde.*|" ]
>
> ( essentially sda / sdb are the two SSD in my system under LVM
> control...the rest are USB devices )
>
> And now the LV commands complete...so dracut completes...and I can
> boot into the new kernel !!

Glad you got it to work, however, it looks more like a workaround than a
fix :-)

Maybe you could open a bugzilla issue about it?

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] lvm2 2.03.12-6 CentOS Stream broke

2021-09-05 Thread Simon Matter
> hi there since updating my system to include the following package...
>
> # rpm -qi lvm2
> Name: lvm2
> Epoch   : 8
> Version : 2.03.12
> Release : 6.el8
> Architecture: x86_64
> 
> Build Date  : Thu 12 Aug 2021 06:06:53 BST
> Build Host  : x86-01.mbox.centos.org
>
> ...all LV commands just hang (pvdisplay / vgdisplay / lvdisplay / etc)
> which in turn is stopping dracut from generating the initramfs for the
> new kernel from the same update...
>
> 71464 pts/4S+ 0:00  |   \_ /bin/bash -p
> /bin/dracut -f /boot/initramfs-4.18.0-338.el8.x86_64.img
> 4.18.0-338.el8.x86_64
>   71483 pts/4S+ 0:00  |   \_ /bin/cat
>   71601 pts/4S+ 0:00  |   \_ /bin/bash -p
> /bin/dracut -f /boot/initramfs-4.18.0-338.el8.x86_64.img
> 4.18.0-338.el8.x86_64
>   71602 pts/4D+ 0:00  |   \_ lvm vgs
> --noheadings -o pv_name cs_ctream
>
> ( see dracut running the lvm vgs command...which never returns...so
> dracut nevern completes...so I can't boot into the new kernel )
>
> any ideas on this one ? is it a known issue ? or is there anything
> else I can do to troubleshoot further ?

And when you downgrade lvm2, does it work again?

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Troubles expanding file system.

2021-09-03 Thread Simon Matter
> On 9/2/2021 10:28 PM, Simon Matter wrote:
>> There is one thing that I couldn't find a solution for no matter what I
>> tried: When the root/boot disk of the guest is being resized, it's not
>> possible to modify and reread the new partition table without reboot.
>
> I'm curious to know if this works for you.  Suppose /dev/sda is the boot
> disk.  Determine the highest number primary partition in use on the
> drive.  Let's say it's 3.
>
> # growpart /dev/sda 3
>
> In addition, you might try
>
> # printf "F\n" | parted ---pretend-input-tty -l
>
> I have these in an Ansible playbook for creating CentOS 7 and Ubuntu
> Focal VMs.  They require cloud-int (for growpart) and gdisk.  Note:
> growpart doesn't work if the highest partition is not a primary
> partition, i.e., greater than 4.

I think the problem in my case was that EL6 didn't support this. From
growpart man page:

  "this requires kernel support and 'partx --update'"

Maybe it works for newer systems but didn't work when I last had to do it
on EL6.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Troubles expanding file system.

2021-09-02 Thread Simon Matter
Hi Jeff,

> I realized I was still on receiving the daily digest format last night, so
> I have probably screwed up the threading on this now.  If you cc me
> directly maybe I can maintain the future threading.
>
> Ok, looking at Parted it looks like the resize (or resizepart) command
> will be what I will need.  But that doesn't appear to help recognize the
> expanded disk, so I think I need something before that.  That is what I
> thought the echo 1 > rescan would do for me.

I'm not sure what your current state is but I'd like to point out what I
usually do to online resize disks on KVM hosts/guests.

After expanding the disk image/logical volume, let the quest know it has
changed. To do so, run like this on the host:

virsh blockresize db01 /var/lib/libvirt/images/db01.var.img 7516192768B

or

virsh blockresize db01 vdb 7516192768B

Note: I'm using bytes (B) as unit to make very sure it's correct!

After doing so, you should see that disk size has changed on the guest, in
syslog or with dmesg.

Now you can modify partition tables or pvresize. After that, resize the
fillesystems with resize2fs or xfs_growfs.

That's all possible while the guest is online with one exception outlined
below.

There is one thing that I couldn't find a solution for no matter what I
tried: When the root/boot disk of the guest is being resized, it's not
possible to modify and reread the new partition table without reboot.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Troubles expanding file system.

2021-09-01 Thread Simon Matter
> On 9/1/21 9:42 AM, Jeff Boyce wrote:
>> 6. I suspect that I need to rescan the devices on Sequoia so that it
>> recognizes the increased space that has been allocated from the
>> extended the logical volume.  But when I did that (command below) it
>> came back with a no such file or directory.
>>
>> echo 1 > /sys/class/block/vde1/device/rescan
>
>
> If you look at the content of /sys/class/block/vde and vde1, you'll see
> that vde has a device subdir, and vde1 does not.  You can't rescan a
> partition.  Rescan the *drive*
>
> echo 1 > /sys/class/block/vde/device/rescan

And, on additional disks, one can put filesystems directly on the disk and
so not have to care about useless partition tables (that's not on the
root/boot disk). To add more flexibility, one can also use LVM on the
device directly without having to mess with partition tables.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Out of the Office -- Re: Application migration

2021-09-01 Thread Simon Matter
> Yeah, well...  That's what I get for writing a Google Script to try to
> automate these things.
>
> I had "centos@centos.org" in my list of addresses to *not* send these
> auto-responders to, but not "CentOS@centos.org".  *sigh*
>
> I've amended the thing so it shouldn't badger anyone who sends me mail
> with
> "[CentOS]" in the subject line...or who emails "CentOS@centos.org" instead
> of "centos@centos.org".

It's much better to check for certain headers and then never send vacation
replies to them, like:

Precedence: list
List-Id: CentOS mailing list 

Otherwise your rules will fail often.

Regards,
Simon

>
> Happy Wednesday!
>
> *J. Adam Craig*
> Lead Linux Operating Systems Analyst
> VCU Infrastructure Services 
> Technology Services Department
> 804.828.4886
> jacr...@vcu.edu
>
> 
> *Don't be a phishing victim -- VCU and other reputable organisations will
> never use email to request that you reply with your password, social
> security number or confidential personal information.  For more details,
> visit
> **https://ts.vcu.edu/about-us/information-security/common-questions/what-is-phishing
> *
>
>
>
> On Wed, Sep 1, 2021 at 8:55 AM Scott Robbins  wrote:
>
>> On Wed, Sep 01, 2021 at 02:47:50AM -0700, jacr...@vcu.edu wrote:
>> > I am currently out of the office, but plan to return to my desk on
>> > Wednesday at 7am.
>>
>> Well, they're going to be embarrassed when they get back.
>>
>> Ah well, as we said the last time this happened, most of us have done
>> worse.
>>
>>
>> --
>> Scott Robbins
>> PGP keyID EB3467D6
>> ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
>> gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
>>
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Upgrading (?) from legacy boot to UEFI

2021-08-28 Thread Simon Matter
> On 27/08/21 10:51 pm, Rob Kampen wrote:
>> Unfortunately the server is remote and the CentOS7 USB device I left
>> plugged into the machine refuses to boot from UEFI mode. Thus a rescue
>> mode boot has not been possible.
>>
> So i made a trip and replaced the USB stick with another one - CentOS7
>>
>> I am unsure what file I need to point the UEFI bios disk manager setup
>> at, I have tried shim.efi and shimx84-centos.efi
>>
>> The message I get is that linux16 and initrd16 cannot find their
>> files. The change to linuxefi and initrdefi also fail but the system
>> reboot happens before I can see what flashes on screen.
>>
>> Is a USB based UEFI booted rescue mode the only way I can fix this?
>
> So I then rebooted - selected UEFI native boot and got into rescue mode
> - only problem is that the rescue system did not find a Linux system.
> Really weird as each of the four drives effectively have a complete
> centos7 system. No idea why it didn't start md raid and find the 6 raid1
> volumes.
>
> About to give this a miss and just live with legacy boot - this UEFI
> thing is just far too complicated. Looking on line at all the various
> blogs and questions it seems I am not alone in finding it far too
> complicated.

Don't worry, you're not alone. IMHO UEFI and GRUB2 and the whole Linux
startup procedure can be a real problem to handle and I guess most people
just give up earlier or later and simply use the installer to do the job.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] A Blast from the past

2021-08-17 Thread Simon Matter
> Thank you for your feedback.
>
> Unfortunately the manufacturer of our application software will only
> support
> it on RHEL/CentOS 7.0. I have asked and that is all they say.
> When the CentOS 7.0 boots it does not recognise the CPU ID, flags it as a
> soft error then continues.
> The Haswell and the Ice Lake both have 28 cores but different frequencies.
> A couple of clues. At the boot prompt the server cooling fans are running
> slowly. When it hangs, after a short delay, the fans run faster and this
> is
> repeated.
> Also, when it hangs the keyboard is unresponsive and the server status
> LED's
> state that all is okay.
> If Intel adhere to the x86_64 standard for their processors then surely
> the
> only difference would be the addition functionality.
> I am trying to find a resolution as this particular application is perfect
> for our requirements.
> Mark

But, if you only install the newer kernel, does your application work on
it? If so, why not just run it that way?

Apart from that, you could install a current distribution on the host and
then let the application server run in a KVM instance. That way you can
fine tune what kind of CPU/features are provided to the VM.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] A Blast from the past

2021-08-17 Thread Simon Matter
> Hello,
> Can you please help with an interesting problem.
> I have an Intel Haswell based processor with CentOS 7.0 with an early
> kernel
> booting and running perfectly.
> I changed the processor to an Ice Lake and I get the problem below when I
> boot the working Haswell disk.
> The boot process hangs almost immediately and when I remove the 'quiet'
> boot
> parameter I see that it hangs randomly, usually with a high CPU number,
> when
> SMPBOOT is starting up the cores.
> The only solution I have found is to boot with the 'nr_cpus=8 (could be
> any
> low number), update to the latest kernel then reboot with the 'nr_cpus=8'
> parameter removed.
> On examination there are no problems with CentOS 7.4 and above but there
> are
> with CentOS 7.3 and below.

I think the issue is quite clear here: the newer CPU is not handled
correctly by the old kernel - maybe it even doesn't know this CPU type and
doesn't know how to detect the number of cores it has.

I don't think there is a better solution than what you already did.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] NFS Share fails to mount at boot time

2021-08-17 Thread Simon Matter
> My suggestion - Add "_netdev" to the parameters list:
>
>   NAS2HOST:/volume1/export/  /mnt/NAS2 nfs
> _netdev,rw,vers=3,soft,bg,intr0 0

And, if it doesn't work, try this instead and please let us know which one
worked best:

NAS2HOST:/volume1/export/  /mnt/NAS2 nfs
rw,vers=3,soft,bg,intr,x-systemd.requires=network-online.target 0 0

The 'x-systemd.requires=network-online.target' makes sure that this NFS
mount is _only_ mounted fter a network interface is really online.

And I'm wondering why systemd doesn't do this by default because NFS
mounts are always _only_ possible with an online network.

Can someone explain to me the logic of what systemd does here?

Regards,
Simon

>
> 
> Bill Gee
>
>
> On Tuesday, August 17, 2021 9:18:53 AM CDT Felix Natter wrote:
>> hello fellow CentOS Users,
>>
>> on Scientific Linux 7 (_very_ similar to CentOS7), I get this when
>> trying to mount NFS Shares (exported from Synology NAS) automatically at
>> boot time:
>>
>> [root@HOST ~]# journalctl -b 0 | grep NAS[20]
>> Jul 01 13:32:09 HOST systemd[1]: Mounting /mnt/NAS0...
>> Jul 01 13:32:09 HOST systemd[1]: Mounting /mnt/NAS2...
>> Jul 01 13:32:09 HOST systemd[1]: mnt-NAS0.mount mount process exited,
>> code=exited status=32
>> Jul 01 13:32:09 HOST systemd[1]: Failed to mount /mnt/NAS0.
>> Jul 01 13:32:09 HOST systemd[1]: Unit mnt-NAS0.mount entered failed
>> state.
>> Jul 01 13:32:09 HOST systemd[1]: mnt-NAS2.mount mount process exited,
>> code=exited status=32
>> Jul 01 13:32:09 HOST systemd[1]: Failed to mount /mnt/NAS2.
>> Jul 01 13:32:09 HOST systemd[1]: Unit mnt-NAS2.mount entered failed
>> state.
>>
>> I read that enabling NetworkManager-wait-online.service can mitigate
>> that, but it's already enabled:
>>
>> [root@HOST ~]# systemctl list-unit-files|grep wait
>> chrony-wait.service   disabled
>> NetworkManager-wait-online.serviceenabled
>> plymouth-quit-wait.servicedisabled
>>
>> /mnt/NAS2 is defined in /etc/fstab (/mnt/NAS0 is mounted analogously):
>>
>> NAS2HOST:/volume1/export/  /mnt/NAS2 nfs rw,vers=3,soft,bg,intr
>>   0 0
>>
>> This does not always occur, and it seems to be a race condition, because
>> it did not occur a few months ago, before we moved offices (when only
>> the networking changed slightly).
>>
>> Of course, once the computer is booted, I can always mount the shares
>> without problems.
>>
>> Does someone have an idea?
>>
>> Many Thanks and Best Regards,
>>
>
>
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] yum quiet not really quiet anymore?

2021-07-24 Thread Simon Matter
> Hi all,
> I noticed that "yum -q" (or "dnf" -q) on CentOS 8 is not really quiet
> anymore. For example (notiche the "upgraded" line):
>
> [root@localhost cron.d]# yum upgrade -y -q
>
> Upgraded:
>python3-perf-4.18.0-305.10.2.el8_4.x86_64
>
> While yum historically had issue with the quiet option [1], this
> specific issue seems new to me. Do you have any suggestion (short of
> redirecting stdout to /dev/null)?
>

Maybe redirecting only stderr to /dev/null is enough?

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Warning: No matches found for: clamav on CentOS Linux release 7.9.2009 (Core)

2021-07-19 Thread Simon Matter
> The latest version in in epel-testing, yum  --enablerepo=epel-testing
> update clam* will do the trick

I don't see any clamav package in testing on my local mirror, only in the
main tree.

Can it be that there are outdated/broken epel mirrors out there?

Simon

>
> On 7/19/21 5:04 AM, Kaushal Shriyan wrote:
>> Hi,
>>
>> I am running CentOS Linux release 7.9.2009 (Core) and installed epel
>> repository.
>>
>> # rpm -qa | grep epel
>> epel-release-7-13.noarch
>> # cat /etc/redhat-release
>> CentOS Linux release 7.9.2009 (Core)
>> #yum search clamav
>> Loaded plugins: fastestmirror
>> Determining fastest mirrors
>>   * base: mirrors.piconets.webwerks.in
>>   * extras: mirrors.piconets.webwerks.in
>>   * updates: mirrors.piconets.webwerks.in
>> base
>>
>>  | 3.6 kB  00:00:00
>> docker-ce-stable
>>
>>  | 3.5 kB  00:00:00
>> elastic-7.x
>>
>> | 1.3 kB  00:00:00
>> extras
>>
>>  | 2.9 kB  00:00:00
>> ius
>>
>> | 1.3 kB  00:00:00
>> mariadb
>>
>> | 2.9 kB  00:00:00
>> nginx
>>
>> | 2.9 kB  00:00:00
>> updates
>>
>> | 2.9 kB  00:00:00
>> (1/10): base/7/x86_64/group_gz
>>
>>  | 153 kB  00:00:00
>> (2/10): extras/7/x86_64/primary_db
>>
>>  | 242 kB  00:00:00
>> (3/10): elastic-7.x/primary
>>
>> | 288 kB  00:00:00
>> (4/10): docker-ce-stable/7/x86_64/primary_db
>>
>>  |  62 kB  00:00:00
>> (5/10): docker-ce-stable/7/x86_64/updateinfo
>>
>>  |   55 B  00:00:00
>> (6/10): ius/x86_64/primary
>>
>>  | 100 kB  00:00:01
>> (7/10): updates/7/x86_64/primary_db
>>
>> | 8.8 MB  00:00:04
>> (8/10): base/7/x86_64/primary_db
>>
>>  | 6.1 MB  00:00:05
>> (9/10): nginx/7/x86_64/primary_db
>>
>> |  67 kB  00:00:04
>> (10/10): mariadb/primary_db
>>
>> |  36 kB  00:00:05
>> elastic-7.x
>>
>>880/880
>> ius
>>
>>467/467
>> Warning: No matches found for: clamav
>> No matches found
>>
>> Am I missing anything? Please suggest further. Thanks in Advance.
>>
>> Best Regards,
>>
>> Kaushal
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
>
> --
> Unencumbered by the thought process.
>   -- Click and Clack the Tappet brothers
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Warning: No matches found for: clamav on CentOS Linux release 7.9.2009 (Core)

2021-07-19 Thread Simon Matter
> Hi,
>
> I am running CentOS Linux release 7.9.2009 (Core) and installed epel
> repository.
>
> # rpm -qa | grep epel
> epel-release-7-13.noarch

Hi Kaushal,

I think after installing epel-release, you have to enable the repositories
you want in the /etc/yum.repos.d/epel.repo file.

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Microsoft Teams on CentOS 7. Does the latest version work?

2021-07-16 Thread Simon Matter
> On 16/07/21 10:39 pm, Simon Matter wrote:
>>> And I ask again, how else would you expect the package to satisfy the
>>> dependency in chrome for the newer libstdc++?
>
> And yet you still have not answered this question.

Simple answer: you can NOT without breaking RPMs dependency system.

>
>> And that's where it breaks the rules! It "provides" something that it
>> doesn't really provide. That's NOT allowed with RPM because it breaks
>> other applications. It breaks the whole meaning of dependency tracking
>> of
>> the RPM system. That's why the mentioned chrome package has to be
>> considered broken.
>
> It is not broken, it does exactly what it intends to do.  It needs to
> provide the dependency in order to allow chrome to be installed, and
> with the usage of the correct LD_LIBRARY_PATH it allows chrome to run on
> the system where otherwise it would not.
>
> Yes, it violates the Fedora packaging guidelines, it's a good thing it's
> not a Fedora package, then.  Also please note the very first sentence on
> the main page of the guidelines:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/
>
> "The Packaging Guidelines are a collection of common issues and the
> severity that should be placed on them. While these guidelines should
> not be ignored, they should also not be blindly followed."

It has nothing directly to do with Fedora but with RPM - and the Fedora
folks have rules not to break RPM. For more info see

https://rpm.org/user_doc/dependency_generators.html

>
> Sometimes you have to break some rules to get things to work.  In this
> particular case the results are worth it for a great many people.
>
>

If you break it, then don't wonder why your system doesn't work as
expected. If you break RPMs dependency system by installing broken
packages, you get a broken system.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Microsoft Teams on CentOS 7. Does the latest version work?

2021-07-16 Thread Simon Matter
> On 16.07.21 12:39, Simon Matter wrote:
>>> On 16/07/21 10:19 pm, Simon Matter wrote:
>>>>> I think you missed from a different post where the package was
>>>>> created
>>>>> by a different 3rd-party, not google.  So how else would you expect
>>>>> the
>>>>> 3rd-party package to satisfy the dependency?
>>>>
>>>> I didn't say the chrome packages came from google. But, the TO has
>>>> some
>>>> chrome RPM installed which "provides" the libstdc++ version required
>>>> by
>>>> teams, but doesn't really provide this libstdc++ version to the whole
>>>> system. That's why the RPM is broken, it claims to provide a libstdc++
>>>> version which it doesn't really provide.
>>>
>>> And I ask again, how else would you expect the package to satisfy the
>>> dependency in chrome for the newer libstdc++?  The package was
>>> explicitly created to allow chrome to run on an older system that
>>> doesn't have the newer libstdc++, by rights it should work with other
>>> programs that need a newer libstdc++ as well provided that they set
>>> LD_LIBRARY_PATH appropriately.  So it does, in fact, provide the stated
>>> dependency for the entire system, you just have to tell programs that
>>> need it where to find it.
>>
>> And that's where it breaks the rules! It "provides" something that it
>> doesn't really provide. That's NOT allowed with RPM because it breaks
>> other applications. It breaks the whole meaning of dependency tracking
>> of
>> the RPM system. That's why the mentioned chrome package has to be
>> considered broken.
>>
>
> $ LANG=C rpm -qp --provides
> https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
> warning:
> https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm:
> Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOKEY
> google-chrome = 91.0.4472.164
> google-chrome-stable = 91.0.4472.164-1
> google-chrome-stable(x86-64) = 91.0.4472.164-1
> $
>

Hi Leon,

The problem package is not from google but seems to be
'chrome-deps-stable' from wherever it comes.

It provides 'libstdc++.so.6(GLIBCXX_3.4.22)(64bit)' which it can NOT
because it installs its libs in /opt/google/chrome/lib.

This is all explained in
https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/
and this is why the package 'chrome-deps-stable' has to be considered
broken and actually breaks teams.

From the above text:
--%<--

Examples
Pidgin plugin package

On a x86_64 machine, the pidgin-libnotify provides
pidgin-libnotify.so()(64bit) which it shouldn’t as this library is not
inside the paths searched by the system for libraries. It’s a private, not
global, "provides" and as such must not be exposed globally by RPM.

To filter this out, we could use:

%global __provides_exclude_from ^%{_libdir}/purple-2/.*\\.so$

--%<--

The 'chrome-deps-stable' RPM should have used '%global
__provides_exclude_from ...' to exclude /opt as those libraries are
"private, not global, "provides" and as such must not be exposed globally
by RPM".

That's why teams fails here, Microsoft is NOT the culprit in this case :-)

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Microsoft Teams on CentOS 7. Does the latest version work?

2021-07-16 Thread Simon Matter
> On 16/07/21 10:19 pm, Simon Matter wrote:
>>> I think you missed from a different post where the package was created
>>> by a different 3rd-party, not google.  So how else would you expect the
>>> 3rd-party package to satisfy the dependency?
>>
>> I didn't say the chrome packages came from google. But, the TO has some
>> chrome RPM installed which "provides" the libstdc++ version required by
>> teams, but doesn't really provide this libstdc++ version to the whole
>> system. That's why the RPM is broken, it claims to provide a libstdc++
>> version which it doesn't really provide.
>
> And I ask again, how else would you expect the package to satisfy the
> dependency in chrome for the newer libstdc++?  The package was
> explicitly created to allow chrome to run on an older system that
> doesn't have the newer libstdc++, by rights it should work with other
> programs that need a newer libstdc++ as well provided that they set
> LD_LIBRARY_PATH appropriately.  So it does, in fact, provide the stated
> dependency for the entire system, you just have to tell programs that
> need it where to find it.

And that's where it breaks the rules! It "provides" something that it
doesn't really provide. That's NOT allowed with RPM because it breaks
other applications. It breaks the whole meaning of dependency tracking of
the RPM system. That's why the mentioned chrome package has to be
considered broken.

>
>> It may have worked before because older teams required a libstdc++
>> version
>> which is available on CentOS 7.
>
> Correct.
>
>> The broken chrome packages are the reason why RPM allowed the new teams
>> version being installed.
>
> Again, they are not broken, they are suitable for the systems they were
> built for, which would be current Fedora systems (which happen to have a
> newer libstdc++).
>
>> But because the chrome package doesn't really
>> provide to the systems what it claims,
>
> You're confusing here.  I assume you mean the package that provides the
> libstdc++ dependency which happens to have chrome in it's name but is
> not actually chrome and does not come from google or chrome.

I don't know where the package comes from but it's a broken package and
has something with chrome in the name. This package is the reason why the
teams RPM can be installed and doesn't work. Without this broken package
the new teams package could NOT have been installed and break.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Microsoft Teams on CentOS 7. Does the latest version work?

2021-07-16 Thread Simon Matter
> On 16/07/21 8:41 pm, Simon Matter wrote:
>>> No, it looks for several different "libstdc++.so.6" versions, and the
>>> "chrome" package provides them all. I just listed one of them to
>>> illustrate the point.
>>
>> I'm not sure that's true. You said your chrome package provides it all
>> but
>> from what I see, it installs its libs into /opt/google/chrome/lib. But,
>> your system doesn't know about private libs installed in /opt and I
>> think
>> the chrome package should NOT "provide" its private libs in its RPM
>> packages.
>
> I think you missed from a different post where the package was created
> by a different 3rd-party, not google.  So how else would you expect the
> 3rd-party package to satisfy the dependency?

I didn't say the chrome packages came from google. But, the TO has some
chrome RPM installed which "provides" the libstdc++ version required by
teams, but doesn't really provide this libstdc++ version to the whole
system. That's why the RPM is broken, it claims to provide a libstdc++
version which it doesn't really provide.

It may have worked before because older teams required a libstdc++ version
which is available on CentOS 7.

>
>> IMHO, if it's like that, then the chrome packages are crap :-)
>

The broken chrome packages are the reason why RPM allowed the new teams
version being installed. But because the chrome package doesn't really
provide to the systems what it claims, teams won't work an is in a broken
state.

Did I miss something?

Simon

> The chrome packages are not built for CentOS or supported on such, it is
> coincidence that they happened to have worked in the past.  They will
> continue to work if the libstdc++ dependency is satisfied.
>
>> What happens if you try this:
>>
>> $ export LD_LIBRARY_PATH=/opt/google/chrome/lib
>> $ teams
>
> Better to just do:
> LD_LIBRARY_PATH=/opt/google/chrome/lib teams
>
> ...or if you have a desktop launcher that you use, edit the command and
> add this to the beginning:
>
> env LD_LIBRARY_PATH=/opt/google/chrome/lib
>
>
> Peter
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Microsoft Teams on CentOS 7. Does the latest version work?

2021-07-16 Thread Simon Matter
> On 15/07/2021 12:57, Stephen John Smoogen wrote:
>> On Thu, 15 Jul 2021 at 05:30, Toralf Lund  wrote:
>>> On 15/07/2021 09:37, Gianluca Cecchi wrote:
 On Tue, Jul 13, 2021 at 2:03 PM Toralf Lund 
 wrote:

> Does anyone else run Microsoft Teams on CentOS 7?
>
> I've used it for a while now, and it's generally worked reasonably
> well.
> However, after upgrading to the latest version from the Microsoft
> repos,
> it doesn't start up properly. Processes start and remain active until
> I
> give up and kill them, but I can't see a window or a tray icon or
> anything.
>
> Has anyone else seen this? Is there anything I can do to make the GUI
> appear?
>
> This is not a big deal as everything just works fine if I revert to
> the
> previous release, but it would be interesting to know if this is a
> general problem with the software, or I have some weird issue with my
> system.
>
> The release that doesn't work is 1.4.00.13653. The one that does is
> 1.4.00.7556.
>
> - Toralf
>
>
>
 At the end I think you have something broken with your repo config or
 you
 installed forcing something.
>>> Like I said elsewhere, it turns out that it's a little more complicated
>>> than that. The libraries are actually "provided", but they're not on
>>> the
>>> library path.
>>>
>> That isn't provided..
>
> It's quite definitely provided. I'm mean in the rpm/package install
> context, of course, which is what we were discussing.
>
> The libraries/abi versions are also provided in the sense that the
> actually exist on my system, event though teams can't find them right now.
>
>>   that is a private copy that chrome bundles
>> itself to use. It may or may not have all of the library calls in it
>> (the chrome upstream may only turn on things it knows it wants), and
>> it may have changes which the team doesn't expect.
>
> I think you're missing my point. The teams install works because the
> package *claims* that it provides everything teams wants (besides what's
> in the "normal" system libs.) Whether it works or not is a different
> question.
>
> It most likely will, though, if I set up the necessary LD_PRELOAD etc.
> (haven't been able to try because I needed to have a Teams version i
> *knew* worked.)  It's unlikely that there are "changes which the team
> doesn't expect"; I'm reasonably sure this is a straight
> rebuild/repackaging of newer upstream "libstdc++". It's also not an
> integral part of Chrome, but rather a package someone related to the
> Fedora team made to allow a certain "upstream" versions of chrome to
> work on a certain "downstream" OS release.
>
>>
>> Also teams is looking for `rpm -q --whatprovides
>> 'libstdc++.so.6(GLIBCXX_3.4.20)(64bit)'` and you typed
>> `rpm -q --whatprovides 'libstdc++.so.6(GLIBCXX_3.4.22)(64bit)'`
>
> No, it looks for several different "libstdc++.so.6" versions, and the
> "chrome" package provides them all. I just listed one of them to
> illustrate the point.

I'm not sure that's true. You said your chrome package provides it all but
from what I see, it installs its libs into /opt/google/chrome/lib. But,
your system doesn't know about private libs installed in /opt and I think
the chrome package should NOT "provide" its private libs in its RPM
packages.

IMHO, if it's like that, then the chrome packages are crap :-)

What happens if you try this:

$ export LD_LIBRARY_PATH=/opt/google/chrome/lib
$ teams

Or maybe even add

$ export LD_PRELOAD=/opt/google/chrome/lib/libstdc++.so.6

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [External] Re: Microsoft Teams on CentOS 7. Does the latest version work?

2021-07-14 Thread Simon Matter
> On 14/07/2021 09:04, Simon Matter wrote:
>>> On 13/07/2021 15:07, Tru Huynh wrote:
>>>> hi
>>>>
>>>> On Tue, Jul 13, 2021 at 01:23:58PM +0100, Phil Perry wrote:
>>>>> On 13/07/2021 13:02, Toralf Lund wrote:
>>>>>> Does anyone else run Microsoft Teams on CentOS 7?
>>>>>>
>>>> <...>
>>>>>> The release that doesn't work is 1.4.00.13653. The one that does
>>>>>> is 1.4.00.7556.
>>>>>>
>>>>>> - Toralf
>>>>>>
>>>>> My wife has been using it on el7, but for the last month or two yum
>>>>> has been complaining about broken dependencies when trying to update
>>>>> it, so I'd disabled the Teams repo from yum updating.
>>>>>
>>>>> I can check what version I'm running later for you, if that would be
>>>>> helpful.
>>>> AFAIK, the latest rpm version for c7 is teams-1.4.00.7556-1.x86_64
>>>> after that they only support CentOS-8 for rpm or snap based for c7
>>>> (but one needs to have $HOME under /home).
>>> OK.
>>>
>>> The weird thing here is that the newer version actually installs. If
>>> it's built on/for a later release, I'd normally expect complaints about
>>> the libc or libstdc++ version or something along those lines...
>>>
>>> - Toralf
>> Hi,
>>
>> I've seen a lot of commercial software to completely disable the
>> dependency thing in their RPM packages. So you can always install it, it
>> just doesn't work :)
>
> I guess that's true.
>
> But in that situation, you expect runtime errors. In this case, the
> application doesn't just install, it also starts and stays running for
> as long as I care to let it. It just doesn't do anything useful. Not as

Maybe the same folks who disabled dependency tracking also disabled
logging... Or the software tries to call bluescreen() which obviously
doesn't exist on CentOS :)

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] [External] Re: Microsoft Teams on CentOS 7. Does the latest version work?

2021-07-14 Thread Simon Matter
> On 13/07/2021 15:07, Tru Huynh wrote:
>> hi
>>
>> On Tue, Jul 13, 2021 at 01:23:58PM +0100, Phil Perry wrote:
>>> On 13/07/2021 13:02, Toralf Lund wrote:
 Does anyone else run Microsoft Teams on CentOS 7?

>> <...>
 The release that doesn't work is 1.4.00.13653. The one that does
 is 1.4.00.7556.

 - Toralf

>>> My wife has been using it on el7, but for the last month or two yum
>>> has been complaining about broken dependencies when trying to update
>>> it, so I'd disabled the Teams repo from yum updating.
>>>
>>> I can check what version I'm running later for you, if that would be
>>> helpful.
>> AFAIK, the latest rpm version for c7 is teams-1.4.00.7556-1.x86_64
>> after that they only support CentOS-8 for rpm or snap based for c7
>> (but one needs to have $HOME under /home).
>
> OK.
>
> The weird thing here is that the newer version actually installs. If
> it's built on/for a later release, I'd normally expect complaints about
> the libc or libstdc++ version or something along those lines...
>
> - Toralf

Hi,

I've seen a lot of commercial software to completely disable the
dependency thing in their RPM packages. So you can always install it, it
just doesn't work :)

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Centos versions in the future?

2021-07-07 Thread Simon Matter
> On 07/07/2021 13:41, Leon Fauster via CentOS wrote:
>> On 07.07.21 14:31, J Martin Rushton via CentOS wrote:
>>> Fashion, and Oracle's past practices.  I evaluated
>>>  Alma Linux
>>>  Fedora
>>>  Mint
>>>  Open SuSE
>>>  Oracle Linux
>>>  Springdale Linux
>>> and settled on Alma.  Rocky was still vapourware when Alma was stable.
>>> I've seen how Oracle promise no change in the long term, then change
>>> their charging model in the past.  We got badly burned at work when
>>> they took over DEC RDB.
>>>
>>> I like Alma's independence built on Cloud's experience over many years
>>> building RHEL clones.
>>>
>>
>> Here is another one:
>>
>> https://navylinux.org/
>>
>> --
>> Leon
>>
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>
> I hadn't seen that one, but I do notice that it aims to be "minimalist"
> whereas my main machine is the network server (DNS, DHCP etc), a server
> (Wiki, Cloud, storage) and my workstation.
>
> BTW, anyone know who the "Navy Foundation" are?  Is this an arm of the
> US government?
>
> Martin

See https://navylinux.org/news/legal/

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Tracking down application sending mail in CentOS 7

2021-06-25 Thread Simon Matter
> On 06/23/2021 09:59 PM, Frank Cox wrote:
>> On Wed, 23 Jun 2021 21:54:02 -0400
>> H wrote:
>>
>>> Can anyone suggest how to track down the app so I can reconfigure the
>>> mail
>>> address?
>> And the relevant line(s) in /var/log/maillog are
>>
> Here is an example line:
>
> Jun 25 03:25:40 centos7 postfix/smtp[59252]: 6AB952C03793A:
> to=, relay=smtp.1and1.com[74.208.5.2]:587, delay=1.4,
> delays=0/0.02/1.2/0.23, dsn=5.0.0, status=bounced (host
> smtp.1and1.com[74.208.5.2] said: 550-Requested action not taken: mailbox
> unavailable 550 invalid DNS MX or A/ resource record (in reply to RCPT
> TO command))
>
> aaa.bbb.ccc above is a filler for the incorrect address, in fact a
> malformed address on the server itself that I need to track down, and, as
> I understand it, the reason smtp.1and1.com kicks it away.

You can check the pickup log line to see which user sends the mail. There
are multiple programs sending mail so you may have to look into the mails
content to learn where the mail comes from.

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Security Updates not properly flagged

2021-06-21 Thread Simon Matter
> Sorry, I forgot to mention that I am using CENTOS 7.
> This should receive the Red Hat Update cycle releases until 2024, right?

Yes, but if you only want to install security related updates, you have to
select the packages on your own because CentOS doesn't provide such
metadata.

Regards,
Simon

>
> Regards,
> Thomas
>
> --
>
> Thomas Doczkal
> Snr System Engineer
>
>
> Socionext Europe GmbH
> pittlerstrasse 47
> 63225 langen, germany
> tel +49-6103-3745-386
> mobile +49-174-9226082
> fax +49-6103-3745-122
> thomas.docz...@socionext.com
> www.eu.socionext.com
> www.socionext.com
>
> Geschaeftsfuehrer/Managing Director: Toshihiko Tanaka, Dirk Weinsziehr,
> Koichi Otsuki, Yutaka Yoneyama
>
> Sitz/Seat: Langen, Hessen; Registergericht/Commercial Register:
> Offenbach/Main HRB 48005
>
>
> This e-mail and any attachment contains information
> which is private and confidential and is intended for
> the addressee only. If you are not an addressee, you
> are not authorized to read, copy or use the e-mail or
> any attachment. If you have received this e-mail in
> error, please notify the sender by return e-mail and
> then delete it.
>
>
> 
> From: CentOS  on behalf of Gionatan Danti
> 
> Sent: Monday, June 21, 2021 01:53 PM
> To: CentOS mailing list
> Subject: Re: [CentOS] Security Updates not properly flagged
>
> Il 2021-06-21 13:34 Pete Biggs ha scritto:
>> CentOS does not provide the metadata to allow the --security flag to
>> work.
>
> Right.
>
>> It doesn't provide it because that information from Redhat is
>> proprietary and not open source.
>
> This is not my understanding. From what I can see, updates which patches
> CVEs are freely readable on Red Has site. For example:
> CVE: https://access.redhat.com/security/cve/cve-2021-3156
> UPDATE: https://access.redhat.com/errata/RHSA-2021:0221
>
> Historically the CentOS team refused to provide such metadata due to the
> added work required. Now with Stream, and the demise of classic CentOS,
> security updates are even less probable (ie: a rolling release is often
> wholly updated).
>
> Regards.
>
> --
> Danti Gionatan
> Supporto Tecnico
> Assyoma S.r.l. - www.assyoma.it
> email: g.da...@assyoma.it - i...@assyoma.it
> GPG public key ID: FF5F32A8
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Fwd: Pre-announcement of an ISC DHCP security issue scheduled for disclosure 26 May 2021

2021-06-07 Thread Simon Matter
> On 07.06.21 12:02, Simon Matter wrote:
>>> On 31.05.21 12:57, cen...@niob.at wrote:
>>>> Am 22/05/2021 um 06:15 schrieb Kenneth Porter:
>>>>>
>>>>>  Forwarded Message 
>>>>> Subject: Pre-announcement of an ISC DHCP security issue scheduled
>>>>> for disclosure 26 May 2021
>>>>> Date: Fri, 21 May 2021 11:44:19 -0800
>>>>> From: Michael McNally 
>>>>> To: dhcp-annou...@lists.isc.org
>>>>>
>>>>>
>>>>>
>>>>> Hello, dhcp-announce list subscribers,
>>>>>
>>>>> It has been a while since our last post to this list.
>>>>>
>>>>> Since the last time we posted news of a new release of ISC DHCP,
>>>>> Internet Systems Consortium has adopted a practice of pre-announcing
>>>>> expected security disclosures in order to give operators who use our
>>>>> products a little advance warning and planning time.
>>>>>
>>>>> For that reason, I am writing you today to let you know that a
>>>>> vulnerability
>>>>> in ISC DHCP will be publicly announced next week on Wednesday, 26 May
>>>>> 2021.
>>>>>
>>>>> Further details about that vulnerability will be publicly disclosed
>>>>> next
>>>>> week, and new releases of ISC DHCP that correct the vulnerability
>>>>> will
>>>>> be
>>>>> made available at that time. It is our hope that this
>>>>> pre-announcement
>>>>> will
>>>>> aid DHCP operators in preparing for that disclosure when it occurs.
>>>>>
>>>> The released announcement: https://kb.isc.org/docs/cve-2021-25217
>>>>
>>>> Any updates on this? From the announcement I take it that the version
>>>> used in C7 (4.2.5) is likely affected - yet there was no update.
>>>>
>>>> Disclaimer: I did not check if upstream has released anything and I
>>>> did
>>>> not check if the preconditions for the crash case are met by the
>>>> current
>>>> package. Nevertheless, the "loosing a lease" case is bad enough...
>>>>
>>>
>>>
>>> https://access.redhat.com/security/cve/cve-2021-25217
>>
>> I'm wondering why this bug is still unfixed in EL[6-8] for more than a
>> week now while it is mentioned as being a security issue? Since the
>> fixing
>> patch is just a view lines I'm surprised why it's delayed?
>>
>
>
> Maybe because it depends on more the one other ticket ...
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1963258

Not really, I think. They usually create BZs for every distribution
affected to track them separately, but it seems to be always the same
trivial fix:

https://bugzilla.redhat.com/attachment.cgi?id=1786774=diff
or
https://bugzilla.redhat.com/attachment.cgi?id=1786775=diff

That's why my question, what do we NOT know?

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Fwd: Pre-announcement of an ISC DHCP security issue scheduled for disclosure 26 May 2021

2021-06-07 Thread Simon Matter
> On 31.05.21 12:57, cen...@niob.at wrote:
>> Am 22/05/2021 um 06:15 schrieb Kenneth Porter:
>>>
>>>  Forwarded Message 
>>> Subject: Pre-announcement of an ISC DHCP security issue scheduled
>>> for disclosure 26 May 2021
>>> Date: Fri, 21 May 2021 11:44:19 -0800
>>> From: Michael McNally 
>>> To: dhcp-annou...@lists.isc.org
>>>
>>>
>>>
>>> Hello, dhcp-announce list subscribers,
>>>
>>> It has been a while since our last post to this list.
>>>
>>> Since the last time we posted news of a new release of ISC DHCP,
>>> Internet Systems Consortium has adopted a practice of pre-announcing
>>> expected security disclosures in order to give operators who use our
>>> products a little advance warning and planning time.
>>>
>>> For that reason, I am writing you today to let you know that a
>>> vulnerability
>>> in ISC DHCP will be publicly announced next week on Wednesday, 26 May
>>> 2021.
>>>
>>> Further details about that vulnerability will be publicly disclosed
>>> next
>>> week, and new releases of ISC DHCP that correct the vulnerability will
>>> be
>>> made available at that time. It is our hope that this pre-announcement
>>> will
>>> aid DHCP operators in preparing for that disclosure when it occurs.
>>>
>> The released announcement: https://kb.isc.org/docs/cve-2021-25217
>>
>> Any updates on this? From the announcement I take it that the version
>> used in C7 (4.2.5) is likely affected - yet there was no update.
>>
>> Disclaimer: I did not check if upstream has released anything and I did
>> not check if the preconditions for the crash case are met by the current
>> package. Nevertheless, the "loosing a lease" case is bad enough...
>>
>
>
> https://access.redhat.com/security/cve/cve-2021-25217

I'm wondering why this bug is still unfixed in EL[6-8] for more than a
week now while it is mentioned as being a security issue? Since the fixing
patch is just a view lines I'm surprised why it's delayed?

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Upgrade to 8.4 .2105 Problems

2021-06-05 Thread Simon Matter
> On Sat, Jun 05, 2021 at 04:32:30PM +1200, Alan McRae via CentOS wrote:
>>I noticed in journalctl that gnome-shell was core dumping.
>>
>>yum reinstall gnome-shell fixed my displays problem.
>>
>>So I am back to my first premise that the 'yum update' did not
>>complete properly for some reason.
>>
>>Is there any way I can check the integrity of the packages installed?
>
> rpm, but not to my knowledge, has a "verify" command.

rpm -Va

>
> It checks all files from the specified package are present
> and compares 9 properties with the original specs.
>
>
> --
> Jon H. LaBadie  j...@labadie.us
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] where to get reliable/open source license manager

2021-05-29 Thread Simon Matter
>>> I have developped one python application. I need open source license
>>> server to manage the app via local network. Where can I get this kind
>>> of open source project?
>>
>>
>>It's not really clear (to me, anyway) what you're asking for. What would
>>the application you're looking for *do*?
>>
>>Are you looking for something like flexlm?  Are you licensing your
>>python application on a per-seat basis?
> I'm looking for some software like flexlm, which has the function like
> floating license. My python app will be installed in several PCs in local
> network, and I want to manage which python app can be used. So I need one
> license manager to control the usage of python app. One python app will be
> installed in one PC.

I know flexlm but I never heard of an open source project with the same
functionality. Open source is usually free to use so there is no need to
control the number of licenses used :-)

Regards,
Simon

>
>
>
>
> Thanks!
>
>
> Regards
>
>
> Andrew
>
>
>
>
>
> At 2021-05-29 04:54:34, "Gordon Messmer"  wrote:
>>On 5/28/21 5:49 AM, qw wrote:
>>> I have developped one python application. I need open source license
>>> server to manage the app via local network. Where can I get this kind
>>> of open source project?
>>
>>
>>It's not really clear (to me, anyway) what you're asking for. What would
>>the application you're looking for *do*?
>>
>>Are you looking for something like flexlm?  Are you licensing your
>>python application on a per-seat basis?
>>
>>___
>>CentOS mailing list
>>CentOS@centos.org
>>https://lists.centos.org/mailman/listinfo/centos
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Weird localectl behavior under CentOS 7

2021-05-15 Thread Simon Matter
> Le 15/05/2021 à 12:48, Nicolas Kovacs a écrit :
>> Except when I display my LANG variable, it's still fr_FR.UTF-8 for
>> normal
>> users... but en_US.utf8 for root.
>>
>> This looks like inconsistent or buggy behavior to me.
>
> OK, I experimented some more, and now I'm puzzled.
>
> 1. When I'm connected directly (physically) to the server, LANG is set
> correctly: en_US.utf8 for both root and non-root users.
>
> 2. When I'm opening a remote SSH session, LANG is set to fr_FR.UTF_8 for
> both
> root and non-root users.
>
> What's going on here ?

Hi Nicolas,

it works as expected because SSH sends these vars:

/etc/ssh/ssh_config: SendEnv LANG LC_CTYPE LC_NUMERIC ...

/etc/ssh/sshd_config: AcceptEnv LANG LC_CTYPE LC_NUMERIC ...

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] systemd and 'Stale file handle' errors?

2021-05-14 Thread Simon Matter
> I have a CentOS 7 system where I needed to restart chronyd - but the
> systemctl restart failed with the error:
>
>  systemd[1]: Starting NTP client/server...
>  systemd[43578]: Failed at step NAMESPACE spawning /usr/sbin/chronyd:
> Stale file handle
>  systemd[1]: chronyd.service: control process exited, code=exited
> status=226
>
> Turns out there are a couple of Stale NFS file handles from fuse mounts
> (related to gvfsd) of sub directories under an NFS mounted home directory
> server - but the home directory for the user in this case, no longer exist
> (user has left)
>
> However, I have no idea why these 'Stale file handles' prevent a service
> being started by systemd ?
>
> In this case, chronyd has nothing to do with NFS mounted user home
> directories - so shouldn't really care ?
>
> I have tried everything I can think of to clear these stale mounts, but
> with no luck
>
> Does anyone know why systemd complains about unconnected 'Stale file
> handles' - and is there any way I can tell systemctl to start a service
> regardless of these 'errors' ?
>
> Rebooting the host will be a last resort (the system is used by many
> users) - but in the meantime, I've manually started the /usr/sbin/chronyd
> binary directly, which runs fine

We're running large multi user systems with desktop sessions on Red Hat
based systems for decades but it became increasingly painful after EL6
with the introduction of systemd in EL7. It may have improved the user
experience on developers laptops but for our use case things are worse
today...

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] ssh stalls/hangs instead of exiting

2021-04-15 Thread Simon Matter
> On 4/14/21 2:22 AM, Simon Matter wrote:
>>>>> On 4/13/21 11:36 PM, Chris Schanzle via CentOS wrote:
>>>>>> On 4/13/21 5:00 PM, Frank Cox wrote:
>>>>>>> On Tue, 13 Apr 2021 22:29:26 +0200
>>>>>>> Simon Matter wrote:
>>>>>>>
>>>>>>>> You could try running strace on the hanging process so see what
>>>>>>>> it's
>>>>>>>> doing.
>>>>>>> [frankcox@mutt temp]$ rsync -avv ../temp/ jeff:temp
>>>>>>> opening connection using: ssh jeff rsync --server
>>>>>>> -vvlogDtpre.iLsfxC
>>>>>>> .
>>>>> temp  (7 args)
>>>>>>> sending incremental file list
>>>>>>> delta-transmission enabled
>>>>>>> abc is uptodate
>>>>>>> total: matches=0  hash_hits=0  false_alarms=0 data=0
>>>>>>>
>>>>>>> Leaving that sit there apparently doing nothing (but still not
>>>>>>> giving
>>>>>>> me my cursor back) I switched to another terminal window and did
>>>>>>> the
>>>>>>> following:
>>>>>>>
>>>>>>> [frankcox@mutt ~]$ ps -FA | grep rsync
>>>>>>> frankcox54002435  0 60586  3160   5 14:52 pts/000:00:00
>>>>>>> rsync -avv ../temp/ jeff:temp
>>>>>>> frankcox54015400  0 67980  7440   1 14:52 pts/000:00:00
>>>>>>> ssh
>>>>>> jeff rsync --server -vvlogDtpre.iLsfxC . temp
>>>>>>> frankcox55265416  0 55476  1076   3 14:53 pts/100:00:00
>>>>>>> grep --color=auto rsync
>>>>>>>
>>>>>>> [frankcox@mutt ~]$ strace -p 5401
>>>>>>> strace: Process 5401 attached
>>>>>>> select(11, [5 9 10], [], NULL, NULL
>>>>>>>
>>>>>>> Then it just sits there with no further action.  I get my cursor
>>>>>>> back
>>>>>>> when I hit ctrl-c.
>>>>>>>
>>>>>>> [frankcox@mutt ~]$ strace -p 5400
>>>>>>> strace: Process 5400 attached
>>>>>>> restart_syscall(<... resuming interrupted nanosleep ...>) = 0
>>>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>>>>
>>>>>>> The wait4-etc line just keeps repeating endlessly until I hit
>>>>>>> ctrl-c.
>>>>>>>
>>>>>>> Unfortunately, I have no idea what any of the above actually means.
>>>>>>> Does it tell us anything interesting?
>>>>>> Yay!  I am glad someone else on the planet is experiencing this. 
>>>>>> I noticed this started happening to me after updating some CentOS
>>>>>> Linux
>>>>> 8
>>>>>> systems today.
>>>>>>
>>>>>> I discovered if I set ForwardX11=no (either on ssh command line or
>>>>>> in
>>>>> ~/.ssh/config) the hang does not happen.  But why does that matter? 
>>>>> No
>>>>> updates to openssh.
>>>>>> It is not the systemd update doing something silly with session
>>>>>> management.  I painfully downgraded manually and rebooted to no
>>>>>> effect. 
>>>>>> As an aside, why can't we we have nice things in life like 'dnf
>>>>>> downgrade
>>>>>> systemd\*' actually work?  I did the below - might be dumb, but it
>>>>> wor

Re: [CentOS] ssh stalls/hangs instead of exiting

2021-04-14 Thread Simon Matter
>>> On 4/13/21 11:36 PM, Chris Schanzle via CentOS wrote:
>>>> On 4/13/21 5:00 PM, Frank Cox wrote:
>>>>> On Tue, 13 Apr 2021 22:29:26 +0200
>>>>> Simon Matter wrote:
>>>>>
>>>>>> You could try running strace on the hanging process so see what it's
>>>>>> doing.
>>>>> [frankcox@mutt temp]$ rsync -avv ../temp/ jeff:temp
>>>>> opening connection using: ssh jeff rsync --server -vvlogDtpre.iLsfxC
>>>>> .
>>> temp  (7 args)
>>>>> sending incremental file list
>>>>> delta-transmission enabled
>>>>> abc is uptodate
>>>>> total: matches=0  hash_hits=0  false_alarms=0 data=0
>>>>>
>>>>> Leaving that sit there apparently doing nothing (but still not giving
>>>>> me my cursor back) I switched to another terminal window and did the
>>>>> following:
>>>>>
>>>>> [frankcox@mutt ~]$ ps -FA | grep rsync
>>>>> frankcox54002435  0 60586  3160   5 14:52 pts/000:00:00
>>>>> rsync -avv ../temp/ jeff:temp
>>>>> frankcox54015400  0 67980  7440   1 14:52 pts/000:00:00
>>>>> ssh
>>>> jeff rsync --server -vvlogDtpre.iLsfxC . temp
>>>>> frankcox55265416  0 55476  1076   3 14:53 pts/100:00:00
>>>>> grep --color=auto rsync
>>>>>
>>>>> [frankcox@mutt ~]$ strace -p 5401
>>>>> strace: Process 5401 attached
>>>>> select(11, [5 9 10], [], NULL, NULL
>>>>>
>>>>> Then it just sits there with no further action.  I get my cursor back
>>>>> when I hit ctrl-c.
>>>>>
>>>>> [frankcox@mutt ~]$ strace -p 5400
>>>>> strace: Process 5400 attached
>>>>> restart_syscall(<... resuming interrupted nanosleep ...>) = 0
>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>>
>>>>> The wait4-etc line just keeps repeating endlessly until I hit ctrl-c.
>>>>>
>>>>> Unfortunately, I have no idea what any of the above actually means.
>>>>> Does it tell us anything interesting?
>>>>
>>>> Yay!  I am glad someone else on the planet is experiencing this. 
>>>> I noticed this started happening to me after updating some CentOS
>>>> Linux
>>> 8
>>>> systems today.
>>>>
>>>> I discovered if I set ForwardX11=no (either on ssh command line or in
>>> ~/.ssh/config) the hang does not happen.  But why does that matter?  No
>>> updates to openssh.
>>>>
>>>> It is not the systemd update doing something silly with session
>>>> management.  I painfully downgraded manually and rebooted to no
>>>> effect. 
>>>
>>>> As an aside, why can't we we have nice things in life like 'dnf
>>>> downgrade
>>>> systemd\*' actually work?  I did the below - might be dumb, but it
>>> worked -- alternate suggestions to downgrade are appreciated -
>>> searching
>>> the list and my google-fu was off the mark today.
>>>>
>>>>   cd [path-to-repo]/centos/8/BaseOS/x86_64/os/Packages
>>>>   dnf downgrade $(rpm -qa systemd\* | grep 239-41.el8_3.2 | sed -e
>>> 's/3\.2/3.1/' -e 's/^/.\//' -e 's/$/.rpm/')
>>>>
>>>> Chris
>>>
>>>
>>> [adjusted the subject, hope that is OK.]
>>>
>>> Found it!  It's the dbus update to 1.12.8-12.  Downgrade to -11
>>> and ssh connections close normally.
>>>
>>> To clarify the problem, with the new dbus, simple ssh's like:
>>>
>>> ssh somehost uptime
>>>
>

Re: [CentOS] ssh stalls/hangs instead of exiting

2021-04-14 Thread Simon Matter
>> On 4/13/21 11:36 PM, Chris Schanzle via CentOS wrote:
>>> On 4/13/21 5:00 PM, Frank Cox wrote:
>>>> On Tue, 13 Apr 2021 22:29:26 +0200
>>>> Simon Matter wrote:
>>>>
>>>>> You could try running strace on the hanging process so see what it's
>>>>> doing.
>>>> [frankcox@mutt temp]$ rsync -avv ../temp/ jeff:temp
>>>> opening connection using: ssh jeff rsync --server -vvlogDtpre.iLsfxC .
>> temp  (7 args)
>>>> sending incremental file list
>>>> delta-transmission enabled
>>>> abc is uptodate
>>>> total: matches=0  hash_hits=0  false_alarms=0 data=0
>>>>
>>>> Leaving that sit there apparently doing nothing (but still not giving
>>>> me my cursor back) I switched to another terminal window and did the
>>>> following:
>>>>
>>>> [frankcox@mutt ~]$ ps -FA | grep rsync
>>>> frankcox54002435  0 60586  3160   5 14:52 pts/000:00:00
>>>> rsync -avv ../temp/ jeff:temp
>>>> frankcox54015400  0 67980  7440   1 14:52 pts/000:00:00
>>>> ssh
>>> jeff rsync --server -vvlogDtpre.iLsfxC . temp
>>>> frankcox55265416  0 55476  1076   3 14:53 pts/100:00:00
>>>> grep --color=auto rsync
>>>>
>>>> [frankcox@mutt ~]$ strace -p 5401
>>>> strace: Process 5401 attached
>>>> select(11, [5 9 10], [], NULL, NULL
>>>>
>>>> Then it just sits there with no further action.  I get my cursor back
>>>> when I hit ctrl-c.
>>>>
>>>> [frankcox@mutt ~]$ strace -p 5400
>>>> strace: Process 5400 attached
>>>> restart_syscall(<... resuming interrupted nanosleep ...>) = 0
>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>>
>>>> The wait4-etc line just keeps repeating endlessly until I hit ctrl-c.
>>>>
>>>> Unfortunately, I have no idea what any of the above actually means.
>>>> Does it tell us anything interesting?
>>>
>>> Yay!  I am glad someone else on the planet is experiencing this. 
>>> I noticed this started happening to me after updating some CentOS Linux
>> 8
>>> systems today.
>>>
>>> I discovered if I set ForwardX11=no (either on ssh command line or in
>> ~/.ssh/config) the hang does not happen.  But why does that matter?  No
>> updates to openssh.
>>>
>>> It is not the systemd update doing something silly with session
>>> management.  I painfully downgraded manually and rebooted to no
>>> effect. 
>>
>>> As an aside, why can't we we have nice things in life like 'dnf
>>> downgrade
>>> systemd\*' actually work?  I did the below - might be dumb, but it
>> worked -- alternate suggestions to downgrade are appreciated - searching
>> the list and my google-fu was off the mark today.
>>>
>>>   cd [path-to-repo]/centos/8/BaseOS/x86_64/os/Packages
>>>   dnf downgrade $(rpm -qa systemd\* | grep 239-41.el8_3.2 | sed -e
>> 's/3\.2/3.1/' -e 's/^/.\//' -e 's/$/.rpm/')
>>>
>>> Chris
>>
>>
>> [adjusted the subject, hope that is OK.]
>>
>> Found it!  It's the dbus update to 1.12.8-12.  Downgrade to -11
>> and ssh connections close normally.
>>
>> To clarify the problem, with the new dbus, simple ssh's like:
>>
>> ssh somehost uptime
>>
>> will print the uptime, but do not return to the local shell prompt until
>> you hit ctrl-c.  It works normally if you downgrade dbus or
>>
>> ssh -o forwardx11=no somehost uptime
>>
>> I'm sure a bug report exists somewhere, but that's something to dig for
>> or
>> create tomorrow.
>>
>> To downgrade, packages were scattered in different locations, so I
>> copied
>&g

Re: [CentOS] ssh stalls/hangs instead of exiting

2021-04-14 Thread Simon Matter
> On 4/13/21 11:36 PM, Chris Schanzle via CentOS wrote:
>> On 4/13/21 5:00 PM, Frank Cox wrote:
>>> On Tue, 13 Apr 2021 22:29:26 +0200
>>> Simon Matter wrote:
>>>
>>>> You could try running strace on the hanging process so see what it's
>>>> doing.
>>> [frankcox@mutt temp]$ rsync -avv ../temp/ jeff:temp
>>> opening connection using: ssh jeff rsync --server -vvlogDtpre.iLsfxC .
> temp  (7 args)
>>> sending incremental file list
>>> delta-transmission enabled
>>> abc is uptodate
>>> total: matches=0  hash_hits=0  false_alarms=0 data=0
>>>
>>> Leaving that sit there apparently doing nothing (but still not giving
>>> me my cursor back) I switched to another terminal window and did the
>>> following:
>>>
>>> [frankcox@mutt ~]$ ps -FA | grep rsync
>>> frankcox54002435  0 60586  3160   5 14:52 pts/000:00:00
>>> rsync -avv ../temp/ jeff:temp
>>> frankcox54015400  0 67980  7440   1 14:52 pts/000:00:00 ssh
>> jeff rsync --server -vvlogDtpre.iLsfxC . temp
>>> frankcox55265416  0 55476  1076   3 14:53 pts/100:00:00
>>> grep --color=auto rsync
>>>
>>> [frankcox@mutt ~]$ strace -p 5401
>>> strace: Process 5401 attached
>>> select(11, [5 9 10], [], NULL, NULL
>>>
>>> Then it just sits there with no further action.  I get my cursor back
>>> when I hit ctrl-c.
>>>
>>> [frankcox@mutt ~]$ strace -p 5400
>>> strace: Process 5400 attached
>>> restart_syscall(<... resuming interrupted nanosleep ...>) = 0
>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
>>> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>>>
>>> The wait4-etc line just keeps repeating endlessly until I hit ctrl-c.
>>>
>>> Unfortunately, I have no idea what any of the above actually means.
>>> Does it tell us anything interesting?
>>
>> Yay!  I am glad someone else on the planet is experiencing this. 
>> I noticed this started happening to me after updating some CentOS Linux
> 8
>> systems today.
>>
>> I discovered if I set ForwardX11=no (either on ssh command line or in
> ~/.ssh/config) the hang does not happen.  But why does that matter?  No
> updates to openssh.
>>
>> It is not the systemd update doing something silly with session
>> management.  I painfully downgraded manually and rebooted to no effect. 
>
>> As an aside, why can't we we have nice things in life like 'dnf
>> downgrade
>> systemd\*' actually work?  I did the below - might be dumb, but it
> worked -- alternate suggestions to downgrade are appreciated - searching
> the list and my google-fu was off the mark today.
>>
>>   cd [path-to-repo]/centos/8/BaseOS/x86_64/os/Packages
>>   dnf downgrade $(rpm -qa systemd\* | grep 239-41.el8_3.2 | sed -e
> 's/3\.2/3.1/' -e 's/^/.\//' -e 's/$/.rpm/')
>>
>> Chris
>
>
> [adjusted the subject, hope that is OK.]
>
> Found it!  It's the dbus update to 1.12.8-12.  Downgrade to -11
> and ssh connections close normally.
>
> To clarify the problem, with the new dbus, simple ssh's like:
>
> ssh somehost uptime
>
> will print the uptime, but do not return to the local shell prompt until
> you hit ctrl-c.  It works normally if you downgrade dbus or
>
> ssh -o forwardx11=no somehost uptime
>
> I'm sure a bug report exists somewhere, but that's something to dig for or
> create tomorrow.
>
> To downgrade, packages were scattered in different locations, so I copied
> them to one directory and did
>
> dnf downgrade ./*
>
> The packages I needed to downgrade on a  x86_64 system were:
>
> dbus-1.12.8-11.el8.x86_64.rpm
> dbus-common-1.12.8-11.el8.noarch.rpm
> dbus-daemon-1.12.8-11.el8.x86_64.rpm
> dbus-devel-1.12.8-11.el8.x86_64.rpm
> dbus-libs-1.12.8-11.el8.x86_64.rpm
> dbus-tools-1.12.8-11.el8.x86_64.rpm
> dbus-x11-1.12.8-11.el8.x86_64.rpm

Now that's really interesting, I was wondering why I don't see this on
OL8. The thing is that certain OL8 packages have an additional RPM
revision added like .0.1. Just checked dbus and its changelog shows:

* Tue Feb 16 2021 Kevin Lyons  -1.12.8-12.0.1
- bus: raise fd limits before dropping privs [Orabug: 31175643]
- fix netlink poll: error 4 (Zhenzhong Duan)

So OL is defnitly not 100% bug to bug compatible like the other clones :-)

And it makes me a bit worried why O* fixed this on Feb 16 and the broken
dbus packages are now (in April) installed on CentOS servers?

Regards,
Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


  1   2   3   4   5   >