Re: [CentOS] Viewing changelog for packages to be updated

[Simon Matter via CentOS]

> On Wed, Aug 26, 2020 at 2:54 PM Kenneth Porter 
> wrote:
>>
>> Is there some way to see the RPM changelog entries for a prospective yum
>> update? Ideally I'd like to see just the entries that are newer than the
>> version of the package I already have.
>>
>> I saw a new kernel in today's yum-cron email and I'd like to know what
>> it's
>> about and how urgent the issue is for me.
>
> You may want to look into git.centos.org. For example, spec file diff
> for the latest C7 kernel update can be seen here:
>
> https://git.centos.org/rpms/kernel/c/c53828b00fb26a7f96b149eef5e220a5ed4cc4e5?branch=c7#_5

Hi Akemi,

Thanks for the hint about git.centos.org.
But, is there some yum/dnf utility which can show the changelog changes?
If not, then I may expand one of my rpm tools to do it.

Simon

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

Re: [CentOS] Laptop and NFS homedir

[Simon Matter via CentOS]

> On Wed, Aug 26, 2020 at 12:08:56PM +0100, isdtor wrote:
>> Are there any documented best practices for using NFS home
>> directories on laptops? Right now, and this is on CentOS 7, when I
>> disconnect the machine from the network, the desktop freezes, and I
>> can't even tell if the machine switches to the wireless network. If
>> this sort of adapter switching, which is standard in e.g. Windows
>> 10, is even supported.
>
> I'd say: Don't do it.
>
> NFS does not handle disconnected operations well, nor does the client
> handle IP migrations well.  You'd have to restart the client to get it
> to work, most likely, and processes that are living in $HOME would
> need to be killed before you could unmount it.
>
> There is some effort being made in making fscache work with NFS but
> I've not had much luck in CentOS7 or 8.  It still wouldn't help with
> IP roaming.
>
> Best advice I can offer is to make $HOME local but have symlinks into
> NFS for directories that can be safely unmounted and remounted.
>
> Windows doesn't really have network home directories like UNIX does,
> and their SMB client handles IP roaming better.

But, if your configuration makes sure that the IP address stays the same,
shouldn't it work then, at least with UDP?

Simon

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

Re: [CentOS] Fixing grub/shim issue Centos 7

[Simon Matter via CentOS]

> On 8/7/20 5:30 AM, Phil Perry wrote:
>> On 07/08/2020 10:01, Johnny Hughes wrote:
>>> On 8/7/20 3:46 AM, Nicolas Kovacs wrote:
 Le 07/08/2020 à 09:40, Alessandro Baggi a écrit :
> Probably many users have not updated their machines between the bug
> release and
> the resolution (thanks to your fast apply in the weekend, thank you)
> and many
> update their centos machines on a 2 months base (if not worst). I
> think also
> that many users of CentOS user base have not proclamed their
> disappointement/the issue on this list or in other channels. For
> example I
> simply updated in the wrong time.

 I'm using yum-cron to keep all my server updated on a daily basis.

 And my question "How could this have passed Q & A" was obviously
 directed at
 Red Hat... and *not* at Johnny Hughes and the CentOS team who do
 their best to
 deliver the best possible downstream system. I raise my morning
 coffee mug to
 your health, guys.

 Cheers,

 Niki

>>> I can assure you .. a BUNCH of testing was done.  Because of the scope
>>> of this udpate, the CentOS team was looped in during the embargo stage
>>> (we normally are not .. Red Hat Engineering got permission to make this
>>> happen for this issue). Normally we see things that are open source
>>> only
>>> .. not embargoed content.  Once the embargo gets lifted, the items
>>> become open source.  Kudos to the RH team for making this happen.
>>>
>>> The CentOS team worked with the RHEL team on this update for several
>>> days (more than a week, for sure, maybe 2 weeks)
>>>
>>> I gained MUCH respect for all those guys .. especially  Peter Jones. 
>>> He
>>> is Mr.Secure Boot.
>>>
>>> I personally tested both the c8 and c7 solutions on several machines
>>> (All i have access to actually, including several personal machines
>>> that
>>> have secureboot).  I saw some of the testing that happened on the RHEL
>>> side.  It was extensive.
>>>
>>
>> I'll just add to Johnny's already comprehensive reply. As a member of
>> the CentOS QA team, I personally tested the update on 3 physical
>> machines and all worked fine. Moreover, the QA team was not able to
>> replicate the issue on a single physical machine available to them - the
>> first indication of a problem came from public reports. We give up a
>> huge amount of our personal time and resources to ensure CentOS (and
>> RHEL) are the very best products they can be. I'm unsure what more could
>> have been done.
>
> Thanks Phil,
>
> I very much appreciate all you and the rest of the QA team do.
>
> I know it is a knee jerk reaction to say .. how did that not get caught.
>  I actually said it MYSELF for this very issue.  But looking back, I am
> not sure how we could have caught it.
>
> "Stuff Happens"  :)
>

Crowd testing? Feed the green bananas to the crowd and let them ripe. It
works well for some of the biggest software companies :-)

At least it could make sense for directly hardware related stuff like
kernel, boot loader, firmware/microcode and similar.

Regards,
Simon

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

Re: [CentOS] Fixing grub/shim issue Centos 7

[Simon Matter via CentOS]

> Once upon a time, Alessandro Baggi  said:
>> you are right but is not UEFI a standard and it shouldn't work the
>> same on several vendors? I ask this because this patch broken all my
>> uefi workstations.
>
> The great thing about standards is there's so many to choose from!  Also
> relevant: https://xkcd.com/927/
>
> UEFI has gone through a number of revisions over the years, and has
> optional bits like Secure Boot (which itself has gone through
> revisions).  Almost any set of standards has undefined corners where
> vendors interpret things differently.  Vendors also have bugs in weird
> places sometimes.
>
> The firmware and boot loaders arguably are the least "exercised" parts
> of a system - both change rarely and there are few implementations.
> There's not many combinations, and they don't change a lot.
>
> I'm interested to read about the cause of this issue - something like
> this can be a lesson on "hmm, hadn't thought of that before" type things
> to watch for in other areas.

If you ask me I think the real root of the problem is that the UEFI/Secure
Boot developers didn't know KISS - or they forgot about it. Once such a
beast is born you can not handle it correctly no matter how much you try.

Regards,
Simon

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

Re: [CentOS] rsync upgrade

[Simon Matter via CentOS]

> On 8/6/20 12:30 PM, Jack Bailey via CentOS wrote:
>> On 2020-08-06 08:45, J Martin Rushton via CentOS wrote:
>>> You'll need to upgrade to CentOS8.
>>>
>>> C7 is at rsync 3.1.2-10, and will not go above 3.1.2 ever.
>>>
>>> C8.2 is at 3.1.3-7, C8 will always be on 3.1.3
>>>
>>> Martin
>>
>> Another option is to build rsync from source, which is what I did to try
>> out the zstd compression.
>
>
> Just wanted to share Fedora 32's rsync-3.2.2-1.fc32.src.rpm rebuilds
> cleanly without any necessary tweaks on CentOS 7.  I used mock for a clean
> build environment.
>
> It is very empowering to learn how to build your own packages and not very
> hard to get started.  I encourage you to do the same!
>

If you're using 3.2.2, be sure to add this fix to make rsync behave as
expected:

https://github.com/WayneD/rsync/issues/81

Regards,
Simon

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

Re: [CentOS] Fixing grub/shim issue Centos 7

[Simon Matter via CentOS]

> Le 04/08/2020 à 08:31, lpeci a écrit :
>> I had the same problem with my UEFI bios machine and I fixed it so for
>> Centos 7:
>>
>> 1) Boot from an rescue linux usb
>>
>> 2) When the rescue system is running:
>>
>>     2.1) #chroot /mnt/sysimage
>>
>> 3) Config network:
>>
>>     3.1) # ip addr add X.X.X.X/X dev X
>>
>>     3.2) # ip route add default via X.X.X.X    <--- default router
>>
>> 4) And finally:
>>
>>     #yum downgrade shim\* grub2\* mokutil
>>
>>     #exit
>>
>>     #reboot
>>
>> I hope you can fix it with these steps.
>
> Thanks for the detailed suggestion.
>
> Unfortunately I couldn't recover the installation, and I had to redo
> everything
> from scratch, which cost me the first two days of my holidays.

Now you know how the Window$ admins suffered all the years :-)

>
> One thought regularly kept crossing my mind:
>
> "How on earth could this have passed Q & A ?"

Quite simple I guess. It's one of the cases where you can not test so
easily like other updates. Here you have to make tests on real hardware,
different hardware of all kind and can not do it in the Cloud, a VM or
whatever.

The only real solution I can think of to prevent this would be to make
preview versions of updates available to the public so that a lot of
people can test them on their hardware, hopefully spare hardware, and give
feedback.

I think current business models do not support such a way these days.

However one can find strategies to survive. What I do is:

* Never update any system directly from what is provided online. Sync to
local repositories first to control what is fed to your systems.

* Never blindly apply updates. Always do tests on not so important systems
or dedicated test systems first.

* If all goes well, update important systems. If you have multiple
systems, update only one first as another test. Then update others.

I have learned my lessons in the past decades but this was a good wake up
call to follow above rules even more strictly. Better safe than sorry.

Regards,
Simon

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

Re: [CentOS] NFSroot over wifi in CentOS 7 - graceful shutdown problem

[Simon Matter via CentOS]

> Hi,
>
> I've got a task to have a small number of laptops netboot Linux over
> WiFi. The kernel is loaded off the USB stick of cource, it's off topic
> for now.
>
> The WPA-supplicant daemon is started early by dracut off initrd. It
> works. Mostly.
>
> The problem is that upon shutdown systemd terminates all the processes
> FIRST and unmounts filesystems NEXT.
>
> Guess what? Upon termination, wpa-supplicant brings the wireless
> interface down and the system hangs being unable to unmount now-defunct
> NFSroot.
>
> There were some discussions regarding similar matter and there's even
> the RH Errata:
> https://access.redhat.com/errata/RHBA-2018:2447
> But I'm woking on a fully updated CentOS Linux release 7.8.2003 and
> nevertheless I've got the problem.
>
> I don't have rights to see the BZ.
> https://bugzilla.redhat.com/show_bug.cgi?id=1593649
>
> I'm deciding to use a quick and dirty hack to do a totally ungraceful
> shutdown/reboot:
> https://unix.stackexchange.com/questions/533307/systemd-fails-to-umount-manually-mounted-nfs-shares-in-initramfs
>
> Any better ideas?

Short answer:

Looks like this should be fixed in systemd or its configuration.

Long answer is the one I already gave you on centos-devel. I post it here
because someone may have deeper knowledge of what exactly goes on:

What I'm wondering here is, do you see the hangs because of wpa_supplicant
was terminated and therefore also the wireless interface is down, or do
you see the hangs because networking is already completely down.

If it is because wpa_supplicant gets terminated, then maybe it would be
possible to terminate wpa_supplicant in a way that it lets the wireless
interface still up and functional at least for a certain amount of time.

I don't know wpa_supplicant good enough but I think maybe it is not always
needed to be alive for the wireless interface to work.

Otherwise, I guess it's more a question for the systemd developers than
for CentOS or Linux in general.

Regards,
Simon

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

Re: [CentOS] systemd syslog.target

[Simon Matter via CentOS]

Hi,

>
> I've noticed that there are several systemd unit files in CentOS 7 and 8
> with the optionAfter=syslog.targetin the [Unit] section, but since systemd
> version 198 syslog.target has not existed.I deduce from this that
> "After=syslog.target" is ignored by systemd and can therefore be removed.
> Is this correct? I am writing some systemd unit files for our own services
> which previously used init.d scripts, so I want to ensure I'm not causing
> problems by omitting "After=syslog.target"ChrisSent from Samsung Mobile on
> O2

Interesting, there is really no syslog.target on either CentOS 7 or 8. But
if a service needs classic syslog, shouldn't it have another After=
instead?

Simon

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

Re: [CentOS] Apache umask

[Simon Matter via CentOS]

> On 7/19/20 10:41 PM, Simon Matter via CentOS wrote:
>>> On 7/13/20 6:40 PM, Emmett Culley via CentOS wrote:
>>>> I need to set the umask for apache to 002.  I've tried every idea I've
>>>> found on the internet, but nothing make a difference.  Most suggest
>>>> that
>>>> I put "umask 002" in /etc/sysconfig/httpd, but that doesn't seem to
>>>> make
>>>> a difference.  Other's suggest adding something to the httpd.service
>>>> script for systemd.  And that doesn't make any difference.
>>>
>>> I had a couple sideline emails with Emmett about suexec possibly being
>>> the
>>> culprit.  TL;DR: that's not it.
>>>
>>> The apache suexec utility can enforce a umask (typically 022) on CGI
>>> and
>>> SSI (server-side includes).  Taking a look at the source in
>>> support/suexec.c, if compiled with AP_SUEXEC_UMASK set to some value,
>>> it
>>> will set the umask; else there is no umask change.  AP_SUEXEC_UMASK is
>>> set
>>> via ./configure with --with-suexec-umask.
>>>
>>> In CentOS 8 httpd-2.4.37-21.module_el8.2.0+382+15b0afa8.src.rpm the
>>> httpd.spec for ./configure with suexec-related configuration flags are
>>> notably absent of --with-suexec-umask.  I also did a prep of the
>>> sources
>>> and no patches modify the suexec sources in this way.
>>
>> I may have missed something but it seems to work in my test:
>>
>> # grep -i umask /proc//status
>> Umask:   0022
>>
>> # cat /etc/systemd/system/httpd.service.d/override.conf
>> [Service]
>> UMask=0002
>>
>> # systemctl edit httpd.service
>> < enter override config >
>>
>> 
>>
>> # grep -i umask /proc//status
>> Umask:   0002
>>
>> That's what you are looking for, isn't it?
>>
>> I didn't test to write files but at least the umask on the process is
>> set
>> as it seems.
>>
>> Regards,
>> Simon
>>
> How can I find the value for ?
>
> Emmett

W£ith  I meant the processes running httpd. Try this:

ps faxu | grep http[d]

This will give you the list of PIDs and the UID running it. First PID is
usually run by root and the children are run by user apache.

Regards,
Simon

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

Re: [CentOS] Apache umask

[Simon Matter via CentOS]

> On 7/13/20 6:40 PM, Emmett Culley via CentOS wrote:
>> I need to set the umask for apache to 002.  I've tried every idea I've
>> found on the internet, but nothing make a difference.  Most suggest that
>> I put "umask 002" in /etc/sysconfig/httpd, but that doesn't seem to make
>> a difference.  Other's suggest adding something to the httpd.service
>> script for systemd.  And that doesn't make any difference.
>
> I had a couple sideline emails with Emmett about suexec possibly being the
> culprit.  TL;DR: that's not it.
>
> The apache suexec utility can enforce a umask (typically 022) on CGI and
> SSI (server-side includes).  Taking a look at the source in
> support/suexec.c, if compiled with AP_SUEXEC_UMASK set to some value, it
> will set the umask; else there is no umask change.  AP_SUEXEC_UMASK is set
> via ./configure with --with-suexec-umask.
>
> In CentOS 8 httpd-2.4.37-21.module_el8.2.0+382+15b0afa8.src.rpm the
> httpd.spec for ./configure with suexec-related configuration flags are
> notably absent of --with-suexec-umask.  I also did a prep of the sources
> and no patches modify the suexec sources in this way. 

I may have missed something but it seems to work in my test:

# grep -i umask /proc//status
Umask:  0022

# cat /etc/systemd/system/httpd.service.d/override.conf
[Service]
UMask=0002

# systemctl edit httpd.service
< enter override config >



# grep -i umask /proc//status
Umask:  0002

That's what you are looking for, isn't it?

I didn't test to write files but at least the umask on the process is set
as it seems.

Regards,
Simon

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

Re: [CentOS] hex editor for huge files

[Simon Matter via CentOS]

> On 2020-07-13 15:01, hexp...@hexpeek.com wrote:
>> On 2020-07-13 04:04, Simon Matter via CentOS wrote:
>>> BTW: I strongly suggest to change back the assignment of BINDIR in the
>>> Makefiles.
>>> ...
>>>
>>> Regards,
>>> Simon
>>
>> Thank you for bringing this to my attention. I apologize for any
>> inconvenience. I was under the impression make would terminate if a
>> command
>> failed, but it seems that is not true for variables set via a subshell.
>>
>> I will remove the dependency on realpath in the Makefiles and scripts,
>> and
>> implement a more robust cross-platform build solution when I get a
>> chance.
>> Again, thank you for testing this within the RPM framework.
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Simon, I made some adjustments to the Makefiles that should address
> this issue. I tested on a mostly vanilla CentOS 8.1 system. If you
> have any other issues, let me know.

Thanks, it's fine now. The problem was showing up on EL6 which lacks
realpath.

Simon

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

Re: [CentOS] hex editor for huge files

[Simon Matter via CentOS]

> On 2020-07-12 05:57, Mogens Kjaer wrote:
>> On 7/10/20 4:10 PM, Simon Matter via CentOS wrote:
>>> Thanks for the tool, I've created RPMs of it:
>>>
>>> http://www.invoca.ch/pub/packages/hexpeek/
>>
>> The package generates a symlink /usr/bin/hexedit to /usr/bin/hexpeek,
>> but this is in conflict with the package hexedit which is in base of
>> Centos 7.
>>
>> Mogens
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Indeed, this oversight made it into the beta release. It has already
> been
> removed from the current version and will not appear in future versions.

I've upgraded the RPM as well.

BTW: I strongly suggest to change back the assignment of BINDIR in the
Makefiles. If 'realpath' doesn't exist on the build host, this is what
happens when you run make:

make -C src
make[1]: Entering directory
`/home/pkgbuild/rpmbuild/BUILD/hexpeek-v0.0.20200712b/src'
rm -f /*
rm: cannot remove `/bin': Is a directory
rm: cannot remove `/boot': Is a directory
rm: cannot remove `/cgroup': Is a directory
rm: cannot remove `/dev': Is a directory
rm: cannot remove `/etc': Is a directory
rm: cannot remove `/home': Is a directory
rm: cannot remove `/lib': Is a directory
...
...

Regards,
Simon

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

Re: [CentOS] hex editor for huge files

[Simon Matter via CentOS]

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> hexpeek: a hex editor for huge files
>
> Occasionally I need to work with huge binary files. Over the years I've
> tried many different tools and never found one that was exactly what I
> wanted. In my experience most hex editors either (1) do not work well
> with 4GB+ files or (2) require the user to learn a curses interface and
> are not scriptable.

Hi,

Thanks for the tool, I've created RPMs of it:

http://www.invoca.ch/pub/packages/hexpeek/

Regards,
Simon

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

Re: [CentOS] Blog article about the state of CentOS

[Simon Matter via CentOS]

> On 21/06/20 1:23 pm, John Pierce wrote:
>> but the build process should be the same, no?I can't believe RH
>> would
>> use a completely different build process for the release than for the
>> beta/development stuff.
>
> The packages still have to be built as a whole, they need to go through
> QA testing, isos need to be built and tested.  The only thing that I can
> think of that Stream benefits this process is to help Red Hat find the
> odd bug here and there before their final release (after which CentOS
> still has to do everything listed above).

As I understand it the whole full build and QA and whatever may still be
done again. The big difference is that the whole work of how to build and
setting up the build infrastructure has already been done and is known and
tested. So the complete build is going quite fast and the big delays are a
thing of the past.

If it's going to be like that it sounds very good.

Regards,
Simon

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

Re: [CentOS] EL8 / certwatch missing

[Simon Matter via CentOS]

> Am 17.06.20 um 12:28 schrieb John Horne:
>> On Sun, 2020-06-07 at 23:36 +0200, Leon Fauster via CentOS wrote:
>>> I have some scripts using certwatch from the crypto-utils package. This
>>> rpm seems to be unshipped with EL8. Any ideas whats the "new" tool to
>>> check pem cert files?
>>>
>> Hi,
>>
>> I have used the 'x509watch' package for several years now to see when
>> certificates are about to expire.
>
> Everyday learning new stuff. Thanks for the pointer. ;-)
>

Another option would be ssl-cert-check

https://github.com/Matty9191/ssl-cert-check

I'm using it with a patch for Zabbix.

Regards,
Simon

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

Re: [CentOS] Blog article about the state of CentOS

[Simon Matter via CentOS]

> Hi,
>
> I just read this blog article from austrian Linux expert Michael Kofler.
> For
> those among you who don't know the guy, he's my home country's number one
> Linux
> expert (known as "der Kofler") and most notably the author of a series of
> excellent books about Linux over the last 25 years.
>
> https://kofler.info/centos-8-wertlose-langzeitunterstuetzung/
>
> Disclaimer : I've been a CentOS user (and fan) since 4.x, I'm using it on
> all
> my servers, and yes, I know the difference between upstream RHEL and
> CentOS.
>
> The article is in german, but the statistics graph is eloquent enough for
> the
> non-german-speaking users. It focuses on updates for CentOS 8, and more
> exactly
> the extended periods of time where there have been no updates available.
>
> The author's theory ("unspoken truth"): while it's a positive thing that
> Red
> Hat is sponsoring CentOS, the amount of sponsoring is just insufficient
> enough
> so that the product is "starved to death" by Red Hat (e. g. IBM) to
> encourage
> users to move to RHEL.

I think if Red Hat really wanted to improve the situation, they could
integrate the building of CentOS into the EL build system to produce both
versions, RHEL and CentOS, at the same time. In the end 99% of the bits
are the same anyway. If the delay of CentOS builds is really wanted by Red
Hat, it would be nice of them to speak it out - and change the name to
COS, because the ent is not true anymore :-)

Up to now I thought the big delay with 8 is more an accident than wanted.
Would be nice to hear what Red Hat says about it. Maybe the problem is not
known well enough in the Red Hat universe.

Regards,
Simon

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

Re: [CentOS] firewall help request (solved)

[Simon Matter via CentOS]

> At 03:47 PM 6/16/2020, Kenneth Porter wrote:
>>The rule is in the wrong chain. The INPUT chain affects packets that
>>terminate at the same machine. You want to block packets that will
>>be passed on to the Internet, so your rule needs to be in the
>>FORWARD chain. (The OUTPUT chain affects packets that originate at
>>your machine.)
>>
>>Here's a nice collection of diagrams showing how packets flow
>>through the system:
>>
>>
>
>
> Ah ... Caught it.  So here is the IPTABLES method to block output on
> port 22 from internal machines on a gateway:
>
>iptables -I FORWARD -p tcp --dport 22 -i
> {name-of-internal-interface} -j DROP
>
> So, for example, if your internal interface is, for example,
> /dev/enp2s0, you'd write
>
>iptables -I FORWARD -p tcp --dport 22 -i enp2s0 -j DROP
>
> If you want to log such attempts, preceed it with a log
> request.  Since I'm using the -I command (insert at top), it means
> the log request is entered second:
>
>iptables -I FORWARD -p tcp --dport 22 -i
> {name-of-internal-interface} -j LOG --log-prefix "LOOK HERE"
>
>
> If someone can suggest a firewall-cmd equivalent, it would be nice.

For that kind of firewalling, I suggest to use Shorewall instead:

https://shorewall.org/

IMHO it's the better tool for where you need more than a "personal" firewall.

Regards,
Simon

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

Re: [CentOS] Apache (httpd) fails to start at boot - Centos 8.1

[Simon Matter via CentOS]

>
>
> Il 16/06/20 08:11, Alessandro Baggi ha scritto:
>>
>>
>> Il 16/06/20 06:21, Gordon Messmer ha scritto:
>>> On 6/15/20 7:06 PM, Jay Hart wrote:
 If I do 'systemctl start httpd', apache will start right up.  But
 during boot, it doesn't and I
 get the resulting errors below.

 Jun 15 21:17:28 dream httpd[1534]: (99)Cannot assign requested
 address: AH00072: make_sock: could
 not bind to address 10.20.30.11:80
>>>
>>>
>>> httpd is starting before an interface has been configured with
>>> 10.20.30.11.
>>>
>>> The default configuration starts httpd after "network.target" but you
>>> want to start it after "network-online.target".
>>>
>>> IIRC: run "systemctl edit httpd.service" and insert:
>>>
>>> [Unit]
>>> Afteretwork-online.target
>>>
>>> ___
>>> CentOS mailing list
>>> CentOS@centos.org
>>> https://lists.centos.org/mailman/listinfo/centos
>>
>>
>> +1
>>
>> This happened to me with ssh.
>
> Note: when you will get update for httpd package all could be reverted
> to the original status, so to avoid that your modified httpd.service
> will get an overwrite, create an alternative httpd.service in
> /etc/systemd/system (if I'm not wrong).

That's half right now, but still not good enough. If the RPM provided file
changes, your copy won't get those changes. To make this work better,
don't put the full file in /etc/systemd/system but just add an
override.conf there which is like a diff to the original file. That way
updates of the RPM are handled correctly.

Simon


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

Re: [CentOS] yum/dnf diff

[Simon Matter via CentOS]

> --On Friday, June 05, 2020 1:39 PM -0700 John Pierce
> 
> wrote:
>
>> don't most packages create a .rpmnew file if you've modified the
>> previous
>> package file ?
>
> That file is created AFTER you've made edits, and reflects only the state
> of the file in the latest package. So it's not clear what changed from the
> original package that needs to be migrated into one's current settings.
>
> As a rule I try to copy the original files to xxx.original so I can
> compare
> that to both the .rpmnew file and my working file. But I or another admin
> might forget to save the original. So I end up going the cpio route to
> extract the original files to a temp tree to do the 3-way comparison
> between the original, my modifications, and the latest package's
> modifications.

I do something similar. Before editing any config file, I create a copy of
it named xxx.orig. If I once forgot to do it in time, I have a helper
script 'mkorig [file]' which extracts the file from the corresponding RPM.
Now when doing upgrades with our package managing tool, this will upgrade
using YUM/DNF and after this it's merging all config files. This goes well
in ~95% of the cases. For the cases where merging wasn't possible, it
produces the .rej files so one can merge by hand.

Simon

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

Re: [CentOS] Recover from an fsck failure

[Simon Matter via CentOS]

Hi

> On Thu, May 28, 2020 19:38, Robert Nichols wrote:
>
>> What output do you get from:
>>
>>  file -s /dev/mapper/vg_voinet01-lv_log
>>  lsblk -f /dev/mapper/vg_voinet01-lv_log
>>
>
> file -s /dev/mapper/vg_voinet01-lv_log
> /dev/mapper/vg_voinet01-lv_log: symbolic link TO '../DM-5'
> dm-f
>
> lsblk -f /dev/mapper/vg_voinet01-lv_log
> NAME  FSTYPE LABEL UUID MOUNTPOINT
> vg_voinet01-lv_log (dm-5)
>
>
> The cloned source is a CentOS-6.6 based FreePBSX appliance using lvm.  It

How exactly did you create the cloned disk?

If the source disk still works and is in operation without system errors,
the cloned disk with its filesystems should really be without error as
well.

If the filesystems have errors, maybe the cloning didn't go well?

If you cloned the disk while the system was running, it should at least be
done in single user mode to prevent filesystem errors.

Regards,
Simon

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

Re: [CentOS] xinetd custom service - perl - remote address

[Simon Matter via CentOS]

> Hi all,
>
> I can't believe that I can't find the answer to this one.  I have a perl
> script which is called by xinetd.
>
> I want that perl script to be able to detect the remote IP address of the
> caller.
>
> I presumed that it would be an environment variable but I could be wrong.
> I've found reference to the ENV and PASSENV arguments for xinetd.conf but
> no examples, and no indication of what auguments to use.
>
> In my script I have the following code:
>
> foreach (keys %ENV) { print "$_=$ENV{$_}\n";}
>
>
> but the only line I get back is:

The variable you may want is REMOTE_HOST, at least that's what I see on a
host of mine.

Regards,
Simon

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

Re: [CentOS] ether-wake

[Simon Matter via CentOS]

> Actually you are not correct.
>
>
> 1st: I didn't quote the wikipedia article,  someone sent that as an
> answer to my previous post.
>
>     (similar mindset probably, as in your response)
>
> 2: You are wrong,  broadcast packets, like for example DHCP, and also
> WOL (if UDP), can be routed, by
>
> the means of ip helper addresses and directed broadcasts on Cisco
> equipment
>
>
> Also, you like others seem to have a very hard time understanding what
> is wriiten/asked.  I asked "What port number does
>
> ether-wake us",  ether-wake being part of Centos So what I am looking
> for is a number,  like 9, 37 or something in case it is

Part of the problem is that there is no THE WOL package as there are
different forms of WOL and their packages.

One way is using UDP port 9 as you said. I was using the script below to
do so (using socat) but I can tell you that this method doesn't work for
all devices.

#!/bin/bash

HWADDR="$1"
DEST_IP="255.255.255.255"
DEST_PORT="9"

# The magic packet is a broadcast frame containing anywhere within its
payload
# 6 bytes of all ones (FF FF FF FF FF FF in hexadecimal), followed by sixteen
# repetitions of the target computer's 48-bit MAC address.
MAGIC="\xFF\xFF\xFF\xFF\xFF\xFF"
for ((CNT=0; CNT < 16; CNT++)); do
  MAGIC="${MAGIC}\x${HWADDR//:/\x}"
done

echo -en "$MAGIC" | socat -T1 -u STDIO \
  UDP-DATAGRAM:${DEST_IP}:${DEST_PORT},broadcast

Kind regards,
Simon

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

Re: [CentOS] Ailing MATE desktop

[Simon Matter via CentOS]

> On Wed, 2020-05-06 at 10:26 -0500, Robert G (Doc) Savage via CentOS
> wrote:
>> On Tue, 2020-05-05 at 19:25 -0500, Robert G (Doc) Savage via CentOS
>> wrote:
>> > I'm about ready to run "dnf erase *mate*" and try re-installing
>> > MATE
>> > from scratch from the GNOME3 desktop. Is that possible without
>> > ripping
>> > the heart out of C8 by deleting other critical packages?
>>
>> I've attached a capture of "dnf erase *mate*" that shows the 104
>> packages that would be removed. It looks safe enough, but if there's
>> a
>> a better way to fix the problem I'd rather try that.
>
> Having gotten no responses, I'm about ready to plunge ahead and try
> removing MATE v1.22 with dnf, then do a fresh reinstall of all
> packages. However, I'm unsure about the safest way to proceed.
>
> If you look at the listing attached to my last message, you'll see
> three different groups of packages:
>
> Removing:
>   xxx
> Removing dependent packages:
>   xxx
> Removing unused dependencies:
>   xxx
>
> I don't understand the meaning of the last group of "unused
> dependencies".
>
> Is there a manual, more surgical way to remove packages that won't rip
> the overall CentOS 8.1 installation apart? For example, is there a way
> (perhaps a for loop) that deletes only the first two package groups?
> All of those are from the COPR repository. Removing them should cause
> no problems. But the third group (unused) includes several @AppStream,
> @epel, and even one @PowerTools package.
>
> Any dnf gurus please weigh in here.

I'm not sure why dnf is eager to remove more than what you want. I think
it's an option you can use to make it remove only what is required, and
unused packages are not touched.

However, in such cases, what I did is:
- check the yum/dnf log for which packages were installed by the time I
installed something with lot of dependencies. Make a list of all RPMs.
- use plain 'rpm -e --test ' and see what it does.
- if okay remove '--test' and remove the RPMs.

Regards,
Simon

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

Re: [CentOS] CentOS 7 - xfs shrink & expand

[Simon Matter via CentOS]

Hi,

> Yeah, I tried that but ran into a problem.  It came up fine in
> single-user/maintenance mode.   The mount command shows all of the
> mounted file systems, but after I 'chroot /sysroot', the mount failed
> (with some problem with mtab, sorry don't have the exact error
> message).  So I couldn't mount my 32TB RAID (where the xfsdump file was).

I think you misunderstood what I meant. You appear to have booted into
rescue mode, but that's not what I meant. What I meant is good old single
user mode. The state you'll get with "telinit 1" or with "s" or "1" as a
kernel boot option.

For what you want to do not a single reboot is required.

Regards,
Simon

>
> On 5/13/2020 12:48 AM, Simon Matter via CentOS wrote:
>> Hi,
>>
>>> I'm having some difficulty finding a method to shrink my /home to
>>> expand
>>> my /.  They both correspond to LVMs.  It is my understanding that one
>>> cannot shrink a xfs filesystem.  One must back it up (xfsdump), remove
>>> (lvremove) redefine it and then restore it back (xfsrestore).
>>>
>>> Okay, I'm running into a problem where /home  needs to be "unused".  If
>>> tried going in to "maintance mode", but I ran into a problem with the
>>> mount command (after issuing a 'chroot /sysroot').  I then tried using
>>> SystemRescueCD to boot to, but it wouldn't mount my 32TB RAID USB drive
>>> (something about too big).
>>>
>>> Any thoughts or suggestions?
>> What is the problem if you boot directly into maintenance mode? Then it
>> should be possible to backup home to a remote destination, unmount
>> /home,
>> remove the home LV, expand /, recreate home and mount it, restore from
>> backup and you're done. No need to use any SystemRescueCD or other tool.
>>
>> 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
>


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

Re: [CentOS] CentOS 7 - xfs shrink & expand

[Simon Matter via CentOS]

Hi,

> I'm having some difficulty finding a method to shrink my /home to expand
> my /.  They both correspond to LVMs.  It is my understanding that one
> cannot shrink a xfs filesystem.  One must back it up (xfsdump), remove
> (lvremove) redefine it and then restore it back (xfsrestore).
>
> Okay, I'm running into a problem where /home  needs to be "unused".  If
> tried going in to "maintance mode", but I ran into a problem with the
> mount command (after issuing a 'chroot /sysroot').  I then tried using
> SystemRescueCD to boot to, but it wouldn't mount my 32TB RAID USB drive
> (something about too big).
>
> Any thoughts or suggestions?

What is the problem if you boot directly into maintenance mode? Then it
should be possible to backup home to a remote destination, unmount /home,
remove the home LV, expand /, recreate home and mount it, restore from
backup and you're done. No need to use any SystemRescueCD or other tool.

Regards,
Simon

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

Re: [CentOS] Can't move to Centos 8

[Simon Matter via CentOS]

Hi,

> Folks
>
> I've been trying to convert my systems to Centos 8, seeing the EOL on
> the horizon a few years away.  One of my systems is a Mac-Mini, and
> support for that has been discontinued.  I'm wondering what the
> community suggests among these alternatives:
>
> 1)  Stay with Centos 7 even after EOL hoping market pressures will
> add Mac-Mini support
>
> 2)  Spend a few hundred dollars on a small, **quiet** replacement (ugh)
>
> 3) Convert to the Debian/Ubuntu distro.
>
> 4) Hope someone figures out a solution.
>
> By the way, the same issue exists, I believe, also for other Mac
> products, such as the newer laptops and servers.

I can't speak for Macs as I never had or used something from Apple. But,
CentOS 8 also doesn't support a lot of other older hardware and you may
find support for the hardware in the ElRepo repository.

Regards,
Simon

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

Re: [CentOS] CentOS7 and NFS

[Simon Matter via CentOS]

> Le 12/05/2020 à 16:10, James Pearson a écrit :
>> Patrick Bégou wrote:
>>>
>>> Hi,
>>>
>>> I need some help with NFSv4 setup/tuning. I have a dedicated nfs server
>>> (2 x E5-2620  8cores/16 threads each, 64GB RAM, 1x10Gb ethernet and 16x
>>> 8TB HDD) used by two servers and a small cluster (400 cores). All the
>>> servers are running CentOS 7, the cluster is running CentOS6.
>>>
>>> Time to time on the server I get:
>>>
>>>   kernel: NFSD: client xxx.xxx.xxx.xxx testing state ID with
>>>  incorrect client ID
>>>
>>> And the client xxx.xxx.xxx.xxx freeze whith:
>>>
>>>   kernel: nfs: server x.legi.grenoble-inp.fr not responding,
>>>  still trying
>>>   kernel: nfs: server x.legi.grenoble-inp.fr OK
>>>   kernel: nfs: server x.legi.grenoble-inp.fr not responding,
>>>  still trying
>>>   kernel: nfs: server x.legi.grenoble-inp.fr OK
>>>
>>> There is a discussion on RedHat7 support about this but only open to
>>> subscribers. Other searches with google do not provide  useful
>>> information.
>>>
>>> Do you have an idea how to solve these freeze states ?
>>>
>>> More generally I would be really interested with some advice/tutorials
>>> to improve NFS performances in this dedicated context. There are so
>>> many
>>> [different] things about tuning NFS available on the web that I'm a
>>> little bit lost (the opposite of the previous question). So if some one
>>> has "the tutorial"...;-)
>>
>> How many nfsd threads are you running on the server? - current count
>> will be in /proc/fs/nfsd/threads
>>
>> James Pearson
>
> Hi James,
>
> Thanks for your answer. I've configured 24 threads (for 16 hardware
> cores/ 32Threads on the NFS server with this processors)
>
> But it seams that there are buffer setup to modify too when increasing
> the threads number... It is not done.
>
> Load average on the server is below 1

I'd be very careful with higher thread numbers than physical cores. NFS
threads and so called CPU hyper/simultaneous threads are quite different
things and it can hurt performance if not configured correctly.

Regards,
Simon

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

Re: [CentOS] network disconnection after several hours

[Simon Matter via CentOS]

Hi,

> Thanks Simon,
> Of course we are not sure but we have a strong feeling :
> - We tried the restore in loop (14) and all worked fine when firewall is
> disabled.- We tried the restore several times but no more 2  succeed
> restore at a row when firewall is enabled.
> We also tried :
>
>- - iptables avec nftables en backend
>- - firewalld avec nftables en backend
>- - nft avec nftables en backend
>- but no improvment.
>
>
> We would want to try "iptables with netfilter" this but we have not find
> how to switch to.
> Do you think server subpackage of NM is a track to follow?

Hi,

I suggest to try it at least as it's so easy:

yum/dnf install NetworkManager-config-server

Regards,
Simon

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

Re: [CentOS] network disconnection after several hours

[Simon Matter via CentOS]

> Hello,
> Here is the context during the problem occurs :
>
> We have a new machine running on centos 8.From this machine, we restore a
> postgresql dump on an other machine runnning on centos 7.After several
> hoursof running, restore fails due to a disconnection (no route to
> host).But, if we disable the firewall on centos 8, restore succeed.
> Before having this new centos 8 machine, we had a centos 7 machine and all
> worked fine with firewall activated.

Are you really sure it happens because of the firewall? Anything in the
logs indicating it happens because firewalld fiddles with something? I
gues by firewall you mean firewalld.

Usually such situations can come from NetworkManager with its default
configuration. If, for some reason, an ethernet device looses link for a
short time, NetworkManager is eager to bring down the interface and the
result is the nice "no route to host" situation. To prevent NM from
"helping" you in this situation, you have to install the server subpackage
from NM - or get rid of it :-)

Regards,
Simon

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

Re: [CentOS] Tomcat or what on CentOS 8?

[Simon Matter via CentOS]

> --On Tuesday, April 28, 2020 9:35 PM +0200 Simon Matter via CentOS
>  wrote:
>
>> If I don't find usable RPMs for CentOS 8 I'm going to build our own as I
>> do for other things as well. But I just can't believe they don't already
>> exist.
>
> Some upstream providers have taken to providing their own repositories.
> I'm
> now getting Nginx, MariaDB, and PostgreSQL from the source that way.
> Perhaps Tomcat has its own upstream repo.

But then why would you want to use CentOS for it or even pay for RHEL if
you can have all this packaged nicely in FreeBSD? Plus, as a long term
Unix and Linux user I feel much more at home on FreeBSD these days than I
feel on CentOS 7 or 8. Even Fedora provides Tomcat 9 which I'm calling an
enterprise feature. How can an enterprise distribution lack such an
important and widely used feature?

Regards,
Simon

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

Re: [CentOS] Tomcat or what on CentOS 8?

[Simon Matter via CentOS]

> On Tue, Apr 28, 2020 at 7:35 PM Simon Matter via CentOS
>  wrote:
>> If I don't find usable RPMs for CentOS 8 I'm going to build our own as I
>> do for other things as well. But I just can't believe they don't already
>> exist.
>
> I've packaged tomcat8 and tomcat9 in my repo here:
> https://harbottle.gitlab.io/harbottle-main/8/x86_64/

Thanks, that's a good starting point to look at.

Regards,
Simon

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

Re: [CentOS] Tomcat or what on CentOS 8?

[Simon Matter via CentOS]

> Hi,
>
> We're running some web apps on CentOS 6 on Tomcat 6 shipped by the
> distribution.
>
> As time goes by we'd like to move on to CentOS 8 and Tomcat 9 or whatever
> is appropriate.
>
> My question is, what do others use now that Tomcat is not shipped anymore
> with CentOS?
>
> Do you run some JBoss/WildFly instead or still running Tomcat?
>
> And, how do you install/manage those installations. Do you have RPM
> packaged versions or fiddle with tarballs?
>
> Since this is a quite standard setup for web apps I'm really wondering how
> everybody is doing it these days?

Anybody care to comment? I can't believe nobody's running Java servlet
containers on CentOS since it's a very common way to provide webservices.

I've just checked our FreeBSD box and it provides:

root@freebsd:~ # pkg search tomcat
tomcat-native-1.2.23 Tomcat native library
tomcat7-7.0.92   Open-source Java web server by Apache, 7.x branch
tomcat85-8.5.54  Open-source Java web server by Apache, 8.5.x branch
tomcat9-9.0.34   Open-source Java web server by Apache, 9.0.x branch
tomcat-devel-10.0.0.M4   Open-source Java web server by Apache, 10.0.x branch

root@freebsd:~ # pkg search wildfly
wildfly90-9.0.2_2Replacement for JBoss Application Server
wildfly10-10.1.0_2   Replacement for JBoss Application Server
wildfly11-11.0.0_1   Replacement for JBoss Application Server
wildfly12-12.0.0_1   Replacement for JBoss Application Server
wildfly13-13.0.0_1   Replacement for JBoss Application Server
wildfly14-14.0.1 Replacement for JBoss Application Server
wildfly15-15.0.1 Replacement for JBoss Application Server
wildfly16-16.0.0 Replacement for JBoss Application Server
wildfly17-17.0.1 WildFly is a Java Jakarta EE8 application server
developed by Red Hat
wildfly18-18.0.1 WildFly is a Java Jakarta EE8 application server
developed by Red Hat

Additionally there are also packages of Geronimo and Glassfish as
alternatives.

If I don't find usable RPMs for CentOS 8 I'm going to build our own as I
do for other things as well. But I just can't believe they don't already
exist.

Regards,
Simon

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

[CentOS] Tomcat or what on CentOS 8?

[Simon Matter via CentOS]

Hi,

We're running some web apps on CentOS 6 on Tomcat 6 shipped by the
distribution.

As time goes by we'd like to move on to CentOS 8 and Tomcat 9 or whatever
is appropriate.

My question is, what do others use now that Tomcat is not shipped anymore
with CentOS?

Do you run some JBoss/WildFly instead or still running Tomcat?

And, how do you install/manage those installations. Do you have RPM
packaged versions or fiddle with tarballs?

Since this is a quite standard setup for web apps I'm really wondering how
everybody is doing it these days?

Thanks,
Simon

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

Re: [CentOS] Understanding modularity

[Simon Matter via CentOS]

> Am 27.04.20 um 17:31 schrieb Simon Matter via CentOS:
>>> On 4/27/20 8:27 AM, Simon Matter via CentOS wrote:
>>>> Hi,
>>>>
>>>> I've read the Fedora modularity docs but am still missing the big
>>>> picture
>>>> somehow. Hope someone can clarify things for me.
>>>>
>>>> What I'm most wondering: does modularity have any influence on the RPM
>>>> packages at all. I mean, is there anything inside a RPM package which
>>>> says
>>>> it belongs to a module or it has a special function in a module?
>>>>
>>>> >From what I understand the RPMs are just completely normal packages
>>>> and
>>>> only YUM/DNF knows from some metadata that an RPM belongs to a module.
>>>> Is
>>>> that corrent?
>>>>
>>>
>>> Well .. yes and no.
>>>
>>> Individual rpm packages have requirements for install .. so if a
>>> package
>>> is built against python38 , it will require python38 libraries.  The
>>> individual RPMs though do not have knowledge specifically about Modules
>>> though, just the metadata.
>>
>> Okay, so the rpm has it's usual provides and requires, in this case a
>> requirement for python38.
>>
>> Still, I don't really understand how it can work for a simple example I
>> have in mind. Let's say there is this new, shiny Apache httpd version
>> 3.0.0 which requires this new and incompatible zlib version 2.0.0.
>>
>> How can this be built with modules? Dozen of RPMs depend on zlib version
>> 1.x.x, how is this situation handled with modules.
>>
>> Sorry, I just don't really understand.
>
>
> IIRC: A module is just a set of RPM packages that can or must be
> installed together. Modules of the same "applications" can not be
> installed at the same time (postgresql 10 or 12). Normally a core
> library would not be packaged as a module but technically possible.
> So, the new thing about "modules" is, that the package manager (dnf) can
> handle this bundles like it would be a single package (handled with the
> help of metadata).

In other words, it does not have a solution for the problem mentioned above?

Simon

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

Re: [CentOS] Understanding modularity

[Simon Matter via CentOS]

> On 4/27/20 8:27 AM, Simon Matter via CentOS wrote:
>> Hi,
>>
>> I've read the Fedora modularity docs but am still missing the big
>> picture
>> somehow. Hope someone can clarify things for me.
>>
>> What I'm most wondering: does modularity have any influence on the RPM
>> packages at all. I mean, is there anything inside a RPM package which
>> says
>> it belongs to a module or it has a special function in a module?
>>
>>>From what I understand the RPMs are just completely normal packages and
>> only YUM/DNF knows from some metadata that an RPM belongs to a module.
>> Is
>> that corrent?
>>
>
> Well .. yes and no.
>
> Individual rpm packages have requirements for install .. so if a package
> is built against python38 , it will require python38 libraries.  The
> individual RPMs though do not have knowledge specifically about Modules
> though, just the metadata.

Okay, so the rpm has it's usual provides and requires, in this case a
requirement for python38.

Still, I don't really understand how it can work for a simple example I
have in mind. Let's say there is this new, shiny Apache httpd version
3.0.0 which requires this new and incompatible zlib version 2.0.0.

How can this be built with modules? Dozen of RPMs depend on zlib version
1.x.x, how is this situation handled with modules.

Sorry, I just don't really understand.

Thanks,
Simon

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

[CentOS] Understanding modularity

[Simon Matter via CentOS]

Hi,

I've read the Fedora modularity docs but am still missing the big picture
somehow. Hope someone can clarify things for me.

What I'm most wondering: does modularity have any influence on the RPM
packages at all. I mean, is there anything inside a RPM package which says
it belongs to a module or it has a special function in a module?

>From what I understand the RPMs are just completely normal packages and
only YUM/DNF knows from some metadata that an RPM belongs to a module. Is
that corrent?

Thanks for any insights,
Simon

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

Re: [CentOS] slow performance on company production server I need help

[Simon Matter via CentOS]

>> Hello Everyone,
>>
>> Since rebooting my Centos 6.10 Openvz server "daisy" yesterday, I am
>> getting horrible system performance.  /var/log/messages is full of
>> HDIO_GET_IDENTITY failed for /dev/sdb.  The latest entries look like
>> this:
>>
>> Apr 22 08:51:32 daisy kernel: [141224.655699] CT: 1005: stopped
>> Apr 22 08:55:04 daisy ata_id[21513]: HDIO_GET_IDENTITY failed for
>> '/dev/sdb'
>
> Hi,
>
> You didn't tell us much about your hardware. It seems you're running a
> 3ware controller in it.
>
> What exactly is /dev/sdb? I don't know 3ware so I can only guess but it
> looks to me like at least one of your drives is having problems.
>
> Any chance you can check SMART status on the disks or have it do a SMART
> test? I guess your 3ware controller has to initiate this.

And, what is the status of the BBU?

Looks like "tw_cli /cx/bbu show status" should tell.

> Regards,
> Simon
>
>> Apr 22 09:00:05 daisy ata_id[21584]: HDIO_GET_IDENTITY failed for
>> '/dev/sdb'
>> Apr 22 09:05:02 daisy ata_id[21644]: HDIO_GET_IDENTITY failed for
>> '/dev/sdb'
>> Apr 22 09:10:01 daisy ata_id[22282]: HDIO_GET_IDENTITY failed for
>> '/dev/sdb'
>> Apr 22 09:11:49 daisy kernel: [142441.721065] INFO: task hdparm:22246
>> blocked for more than 120 seconds.
>> Apr 22 09:11:49 daisy kernel: [142441.721083]   Not tainted
>> 2.6.32-042stab142.1 #1
>> Apr 22 09:11:49 daisy kernel: [142441.721093] "echo 0 >
>> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> Apr 22 09:11:49 daisy kernel: [142441.721109] hdparm    D
>> 88000c778300 0 22246  20845    0 0x0080
>> Apr 22 09:11:49 daisy kernel: [142441.721115]  88006654bcb8
>> 0086 8114f130 88002821fa40
>> Apr 22 09:11:49 daisy kernel: [142441.721121]  8804d238
>> 88006654bd70 88006654bc88 ea00016ab7c0
>> Apr 22 09:11:49 daisy kernel: [142441.721125]  88011a707000
>> 880028321168 0001b7ea 816be9b3faa2
>> Apr 22 09:11:49 daisy kernel: [142441.721130] Call Trace:
>> Apr 22 09:11:49 daisy kernel: [142441.721139]  [] ?
>> sync_page+0x0/0x50
>> Apr 22 09:11:49 daisy kernel: [142441.721144]  [] ?
>> update_curr+0xe1/0x1f0
>> Apr 22 09:11:49 daisy kernel: [142441.721149]  []
>> schedule_timeout+0x215/0x2f0
>> Apr 22 09:11:49 daisy kernel: [142441.721155]  [] ?
>> check_preempt_curr+0x82/0xa0
>> Apr 22 09:11:49 daisy kernel: [142441.721159]  []
>> wait_for_completion+0xe4/0x120
>> Apr 22 09:11:49 daisy kernel: [142441.721162]  [] ?
>> default_wake_function+0x0/0x20
>> Apr 22 09:11:49 daisy kernel: [142441.721167]  [] ?
>> _spin_unlock_bh+0x1b/0x20
>> Apr 22 09:11:49 daisy kernel: [142441.721172]  []
>> sync_inodes_sb_ub+0xa8/0x1d0
>> Apr 22 09:11:49 daisy kernel: [142441.721176]  [] ?
>> filemap_fdatawait+0x2f/0x40
>> Apr 22 09:11:49 daisy kernel: [142441.721181]  []
>> __sync_filesystem+0x95/0xa0
>> Apr 22 09:11:49 daisy kernel: [142441.721184]  []
>> sync_filesystems+0x30d/0x350
>> Apr 22 09:11:49 daisy kernel: [142441.721188]  []
>> sys_sync+0x155/0x1a0
>> Apr 22 09:11:49 daisy kernel: [142441.721192]  []
>> system_call_fastpath+0x22/0x3a
>> Apr 22 09:13:49 daisy kernel: [142561.721069] INFO: task hdparm:22246
>> blocked for more than 120 seconds.
>> Apr 22 09:13:49 daisy kernel: [142561.721087]   Not tainted
>> 2.6.32-042stab142.1 #1
>> Apr 22 09:13:49 daisy kernel: [142561.721096] "echo 0 >
>> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> Apr 22 09:13:49 daisy kernel: [142561.721112] hdparm    D
>> 88000c778300 0 22246  20845    0 0x0080
>> Apr 22 09:13:49 daisy kernel: [142561.721118]  88006654bcb8
>> 0086 8114f130 88002821fa40
>> Apr 22 09:13:49 daisy kernel: [142561.721123]  8804d238
>> 88006654bd70 88006654bc88 ea00016ab7c0
>> Apr 22 09:13:49 daisy kernel: [142561.721128]  88011a707000
>> 880028321168 0001b7ea 816be9b3faa2
>> Apr 22 09:13:49 daisy kernel: [142561.721133] Call Trace:
>> Apr 22 09:13:49 daisy kernel: [142561.721142]  [] ?
>> sync_page+0x0/0x50
>> Apr 22 09:13:49 daisy kernel: [142561.721148]  [] ?
>> update_curr+0xe1/0x1f0
>> Apr 22 09:13:49 daisy kernel: [142561.721153]  []
>> schedule_timeout+0x215/0x2f0
>> Apr 22 09:13:49 daisy kernel: [142561.721158]  [] ?
>> check_preempt_curr+0x82/0xa0
>> Apr 22 09:13:49 daisy kernel: [142561.721162]  []
>> wait_for_completion+0xe4/0x120
>> Apr 22 09:13:49 daisy kernel: [142561.721166]  [] ?
>> default_wake_function+0x0/0x20
>> Apr 22 09:13:49 daisy kernel: [142561.721170]  [] ?
>> _spin_unlock_bh+0x1b/0x20
>> Apr 22 09:13:49 daisy kernel: [142561.721176]  []
>> sync_inodes_sb_ub+0xa8/0x1d0
>> Apr 22 09:13:49 daisy kernel: [142561.721180]  [] ?
>> filemap_fdatawait+0x2f/0x40
>> Apr 22 09:13:49 daisy kernel: [142561.721184]  []
>> __sync_filesystem+0x95/0xa0
>> Apr 22 09:13:49 daisy kernel: [142561.721188]  []
>> sync_filesystems+0x30d/0x350
>> Apr 22 09:13:49 daisy kernel: [142561.721192]  []
>> sys_sync+0x155/0x1a0

Re: [CentOS] slow performance on company production server I need help

[Simon Matter via CentOS]

> Hello Everyone,
>
> Since rebooting my Centos 6.10 Openvz server "daisy" yesterday, I am
> getting horrible system performance.  /var/log/messages is full of
> HDIO_GET_IDENTITY failed for /dev/sdb.  The latest entries look like this:
>
> Apr 22 08:51:32 daisy kernel: [141224.655699] CT: 1005: stopped
> Apr 22 08:55:04 daisy ata_id[21513]: HDIO_GET_IDENTITY failed for
> '/dev/sdb'

Hi,

You didn't tell us much about your hardware. It seems you're running a
3ware controller in it.

What exactly is /dev/sdb? I don't know 3ware so I can only guess but it
looks to me like at least one of your drives is having problems.

Any chance you can check SMART status on the disks or have it do a SMART
test? I guess your 3ware controller has to initiate this.

Regards,
Simon

> Apr 22 09:00:05 daisy ata_id[21584]: HDIO_GET_IDENTITY failed for
> '/dev/sdb'
> Apr 22 09:05:02 daisy ata_id[21644]: HDIO_GET_IDENTITY failed for
> '/dev/sdb'
> Apr 22 09:10:01 daisy ata_id[22282]: HDIO_GET_IDENTITY failed for
> '/dev/sdb'
> Apr 22 09:11:49 daisy kernel: [142441.721065] INFO: task hdparm:22246
> blocked for more than 120 seconds.
> Apr 22 09:11:49 daisy kernel: [142441.721083]   Not tainted
> 2.6.32-042stab142.1 #1
> Apr 22 09:11:49 daisy kernel: [142441.721093] "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Apr 22 09:11:49 daisy kernel: [142441.721109] hdparm    D
> 88000c778300 0 22246  20845    0 0x0080
> Apr 22 09:11:49 daisy kernel: [142441.721115]  88006654bcb8
> 0086 8114f130 88002821fa40
> Apr 22 09:11:49 daisy kernel: [142441.721121]  8804d238
> 88006654bd70 88006654bc88 ea00016ab7c0
> Apr 22 09:11:49 daisy kernel: [142441.721125]  88011a707000
> 880028321168 0001b7ea 816be9b3faa2
> Apr 22 09:11:49 daisy kernel: [142441.721130] Call Trace:
> Apr 22 09:11:49 daisy kernel: [142441.721139]  [] ?
> sync_page+0x0/0x50
> Apr 22 09:11:49 daisy kernel: [142441.721144]  [] ?
> update_curr+0xe1/0x1f0
> Apr 22 09:11:49 daisy kernel: [142441.721149]  []
> schedule_timeout+0x215/0x2f0
> Apr 22 09:11:49 daisy kernel: [142441.721155]  [] ?
> check_preempt_curr+0x82/0xa0
> Apr 22 09:11:49 daisy kernel: [142441.721159]  []
> wait_for_completion+0xe4/0x120
> Apr 22 09:11:49 daisy kernel: [142441.721162]  [] ?
> default_wake_function+0x0/0x20
> Apr 22 09:11:49 daisy kernel: [142441.721167]  [] ?
> _spin_unlock_bh+0x1b/0x20
> Apr 22 09:11:49 daisy kernel: [142441.721172]  []
> sync_inodes_sb_ub+0xa8/0x1d0
> Apr 22 09:11:49 daisy kernel: [142441.721176]  [] ?
> filemap_fdatawait+0x2f/0x40
> Apr 22 09:11:49 daisy kernel: [142441.721181]  []
> __sync_filesystem+0x95/0xa0
> Apr 22 09:11:49 daisy kernel: [142441.721184]  []
> sync_filesystems+0x30d/0x350
> Apr 22 09:11:49 daisy kernel: [142441.721188]  []
> sys_sync+0x155/0x1a0
> Apr 22 09:11:49 daisy kernel: [142441.721192]  []
> system_call_fastpath+0x22/0x3a
> Apr 22 09:13:49 daisy kernel: [142561.721069] INFO: task hdparm:22246
> blocked for more than 120 seconds.
> Apr 22 09:13:49 daisy kernel: [142561.721087]   Not tainted
> 2.6.32-042stab142.1 #1
> Apr 22 09:13:49 daisy kernel: [142561.721096] "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Apr 22 09:13:49 daisy kernel: [142561.721112] hdparm    D
> 88000c778300 0 22246  20845    0 0x0080
> Apr 22 09:13:49 daisy kernel: [142561.721118]  88006654bcb8
> 0086 8114f130 88002821fa40
> Apr 22 09:13:49 daisy kernel: [142561.721123]  8804d238
> 88006654bd70 88006654bc88 ea00016ab7c0
> Apr 22 09:13:49 daisy kernel: [142561.721128]  88011a707000
> 880028321168 0001b7ea 816be9b3faa2
> Apr 22 09:13:49 daisy kernel: [142561.721133] Call Trace:
> Apr 22 09:13:49 daisy kernel: [142561.721142]  [] ?
> sync_page+0x0/0x50
> Apr 22 09:13:49 daisy kernel: [142561.721148]  [] ?
> update_curr+0xe1/0x1f0
> Apr 22 09:13:49 daisy kernel: [142561.721153]  []
> schedule_timeout+0x215/0x2f0
> Apr 22 09:13:49 daisy kernel: [142561.721158]  [] ?
> check_preempt_curr+0x82/0xa0
> Apr 22 09:13:49 daisy kernel: [142561.721162]  []
> wait_for_completion+0xe4/0x120
> Apr 22 09:13:49 daisy kernel: [142561.721166]  [] ?
> default_wake_function+0x0/0x20
> Apr 22 09:13:49 daisy kernel: [142561.721170]  [] ?
> _spin_unlock_bh+0x1b/0x20
> Apr 22 09:13:49 daisy kernel: [142561.721176]  []
> sync_inodes_sb_ub+0xa8/0x1d0
> Apr 22 09:13:49 daisy kernel: [142561.721180]  [] ?
> filemap_fdatawait+0x2f/0x40
> Apr 22 09:13:49 daisy kernel: [142561.721184]  []
> __sync_filesystem+0x95/0xa0
> Apr 22 09:13:49 daisy kernel: [142561.721188]  []
> sync_filesystems+0x30d/0x350
> Apr 22 09:13:49 daisy kernel: [142561.721192]  []
> sys_sync+0x155/0x1a0
> Apr 22 09:13:49 daisy kernel: [142561.721196]  []
> system_call_fastpath+0x22/0x3a
> Apr 22 09:15:06 daisy ata_id[22299]: HDIO_GET_IDENTITY failed for
> '/dev/sdb'
> Apr 22 09:15:49 daisy kernel: 

Re: [CentOS] CentOS 7 : broken dependencies

[Simon Matter via CentOS]

> On Thu, 9 Apr 2020 at 09:34, Simon Matter  wrote:
>
>> > On Thu, 9 Apr 2020 at 08:40, Simon Matter via CentOS
>> 
>> > wrote:
>> >
>> >> > On Thu, Apr 09, 2020 at 11:06:45AM +0200, Nicolas Kovacs wrote:
>> >> >> Which leads me to the more general question of: enable CR on a
>> >> >> production
>> >> >> server, yes or no?
>> >> >
>> >> > Not on production.  Only for testing.
>> >>
>> >> I'm not sure. Running production environments without CR enabled
>> means
>> >> you're running without current security updates for quite some time.
>> >> Seems
>> >> a bad and risky idea to me.
>> >>
>> >>
>> > Like most things in the world, there is no single answer which will
>> > satisfy
>> > all the different demands that all the environments have. You have to
>> > weigh
>> > what each environment needs in terms of confidentiality, availability,
>> and
>> > integrity (or whatever 3 or 4 letter acronym your site uses) then
>> answer
>> > if
>> > it is a good idea or not. If you need high availability, then you are
>> > going
>> > to set things up where testing is done first then roll out of updates
>> is
>> > done. If you need high confidentiality, you may push out security
>> updates
>> > more and if you need high integrity, well you probably make the
>> waterfall
>> > model look simple in what you have to do to make sure anything changes
>> > anywhere.
>>
>> My reply was to the answer "Not on production.  Only for testing.".
>>
>> I didn't go into detail because I thought it's obvious that it's not so
>> easy. I didn't mean to blindly feed all CR updates to production
>>
>
> One thing I have learned in mailing lists is that it isn't always obvious
> and there is rarely anything which meets common sense. I have dealt with
> too many policies set at some site because the person read a comment on
> email/reddit/stack-overflow and didn't see the obvious nature of
> something.
> Instead they decided that the short nature was the MUST do and end up with
> replicating things which the original poster did not expect.
>
> Or sometimes happens someone does believe that it is as simple as they
> stated and no matter what they turn on CR for every system (or turn off
> all
> updates or whatever simple solution they expound as being the one true
> solution.)
>
> That said, I should have asked what you meant by that versus going for a
> high-horse response on my own. I apologize.

No problem, sorry for not being clear enough in my first answer. Anyway
such a discussion is good as it shows different views and can help us to
make smarter decisions.

In this particular case the question is not so much about CR but about
SCLO being production ready or not.

How about upstream, do they already have updated SCLO packages?

Regards,
Simon

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

Re: [CentOS] CentOS 7 : broken dependencies

[Simon Matter via CentOS]

> Hi,
>
> I got an alert from Yum-Cron this morning:
>
> Failed to check for updates with the following error message:
> Failed to build transaction:
> sclo-php72-php-pecl-imagick-3.4.4-1.el7.x86_64
> requires libMagickCore.so.5()(64bit)
> sclo-php72-php-pecl-imagick-3.4.4-1.el7.x86_64 requires
> libMagickWand.so.5()(64bit)
>
> The CR repository is activated on this server, so I guess that's why.
>
> Which leads me to the more general question of: enable CR on a production
> server, yes or no?
>
> Pros : get security updates sooner
>
> Cons : expect breakage like the one above
>
> Any suggestions?

Hi,

The breakage you see is not directly within CentOS 7 and CR. The problem
is that your SCLO package sclo-php72-php-pecl-imagick-3.4.4-1.el7.x86_64
is for 7.7.1908 and needs to be updated for CentOS 7.8.

All the same you'll not be able to update to CentOS 7.8 until a fixed
sclo-php72-php-pecl-imagick package is available.

Applying CR updates to clean installations of a basic CentOS system
usually works very fine.

Regards,
Simon


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

Re: [CentOS] CentOS 7 : broken dependencies

[Simon Matter via CentOS]

> On Thu, 9 Apr 2020 at 08:40, Simon Matter via CentOS 
> wrote:
>
>> > On Thu, Apr 09, 2020 at 11:06:45AM +0200, Nicolas Kovacs wrote:
>> >> Which leads me to the more general question of: enable CR on a
>> >> production
>> >> server, yes or no?
>> >
>> > Not on production.  Only for testing.
>>
>> I'm not sure. Running production environments without CR enabled means
>> you're running without current security updates for quite some time.
>> Seems
>> a bad and risky idea to me.
>>
>>
> Like most things in the world, there is no single answer which will
> satisfy
> all the different demands that all the environments have. You have to
> weigh
> what each environment needs in terms of confidentiality, availability, and
> integrity (or whatever 3 or 4 letter acronym your site uses) then answer
> if
> it is a good idea or not. If you need high availability, then you are
> going
> to set things up where testing is done first then roll out of updates is
> done. If you need high confidentiality, you may push out security updates
> more and if you need high integrity, well you probably make the waterfall
> model look simple in what you have to do to make sure anything changes
> anywhere.

My reply was to the answer "Not on production.  Only for testing.".

I didn't go into detail because I thought it's obvious that it's not so
easy. I didn't mean to blindly feed all CR updates to production
environments. In fact over here, we never ever feed any update directly
from public servers to any production machine. It all comes from local
repositories where we have control over what goes where and we can make
sure not to blindly make updates.

What I meant is that just staying away from CR for production servers
sounds dangerous. You just can't if security critical updates are only
available in CR.

Regards,
Simon

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

Re: [CentOS] CentOS 7 : broken dependencies

[Simon Matter via CentOS]

> On Thu, Apr 09, 2020 at 11:06:45AM +0200, Nicolas Kovacs wrote:
>> Which leads me to the more general question of: enable CR on a
>> production
>> server, yes or no?
>
> Not on production.  Only for testing.

I'm not sure. Running production environments without CR enabled means
you're running without current security updates for quite some time. Seems
a bad and risky idea to me.

Regards,
Simon

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

Re: [CentOS] CentOS 8.1 cron does not send mail

[Simon Matter via CentOS]

> On Mon, Apr 06, 2020 at 09:26:18AM -0400, Jonathan Billings wrote:
>> If you use /etc/systemd/system/cron.d/service.d/override.conf, the
>
> I meant /etc/systemd/system/crond.service.d/override.conf, sorry.

Thanks, I was just thinking about how the path is constructed here.

Simon

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

Re: [CentOS] C8.1 Grub problem

[Simon Matter via CentOS]

> Il 06/04/20 11:54, Georgios ha scritto:
>> Hi there!
>> I had a similar problem recently with grub. No idea why it doesnt work.
>> Try using grubby instead of grub2-mkconfig if you want the system to
>> keep your kernel parameters between boots.
>>
>> Something like:
>>
>> sudo grubby --args="i915.modeset=0 rd.driver.blacklist=i915" --update-
>> kernel=ALL
>>
>>
>> Hope it helps!
>> Have a nice day!
>>
>>
>> On Mon, 2020-04-06 at 11:42 +0200, Alessandro Baggi wrote:
>>> Hi list,
>>>
>>> I reinstalled on my workstation CentOS 8.1.
>>>
>>> I explain: I'm a KDE user but packages shipped from EPEL currently
>>> are
>>> buggy so I prefer a stable and functioning system to work with. So I
>>> tried to remove KDE workgroup and installed group "Workstation" but
>>> the
>>> system bricked so I reinstalled with GNOME.
>>>
>>> I've an nvidia gtx 1050ti GPU so I installed kmod-driver from
>>> rpmfusion.
>>> After the installation of Nvidia driver, I rebooted, gdm start and
>>> after
>>> I perform the login the system freeze. So this problem happened to
>>> me
>>> with C7.5 and nvidia driver. In my case I need to blacklist i915
>>> module
>>> and system works.
>>>
>>> Also in this case I tried to boot centos changing grub kernel
>>> parameters
>>> pressing 'e' in the grub menu and adding "i915.modeset=0
>>> rd.driver.blacklist=i915", booted and system works.
>>>
>>> So I tried to make this permanent updating grub configuration adding
>>> the
>>> previous directives (and removed rhgb and quiet) to
>>> /etc/default/grub
>>> and run grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg.
>>>
>>> Reboot the system and checked again kernel parameters on grub menu
>>> and
>>> seen that nothing changed. Booted and freezed.
>>>
>>> I checked /boot/efi/EFI/centos/grub.cfg and kernelops has the new
>>> directives.
>>>
>>> Seems that grub configuration does not take effect.
>>>
>>> I made another test inside a VM installed with minimal selection and
>>> remove rhgb and quiet parameters and worked fine. The vm is BIOS and
>>> my
>>> workstation UEFI.
>>>
>>> How I can solve this problem? Currently to boot my system I need
>>> always
>>> to add this params.
>>>
>>> Thank you in advance
>>>
>>> ___
>>> 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
>
> Hi,
>
> I tried as suggested, parameters will be updated but I get already
> crash. So I tried to remove also rhgb and quiet and works well.
>
>   Would be good to know what is wrong with grub2-mkconfig.
>
> Where start to investigate?

Just to be sure, your subject line says this is on CentOS 8.1, right?

Because IIRC grub2-mkconfig was broken in CentOS 7 despite the head of
every grub cfg file telling us "It is automatically generated by
grub2-mkconfig using templates".

Really weird that you see the same with CentOS 8.1.

Regards,
Simon

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

Re: [CentOS] CentOS 8.1 cron does not send mail

[Simon Matter via CentOS]

> On Mon, 6 Apr 2020 at 06:59, Tobias Kirchhofer 
> wrote:
>
>> On 6 Apr 2020, at 12:21, Stephen John Smoogen wrote:
>>
>> > On Mon, 6 Apr 2020 at 04:16, Tobias Kirchhofer 
>> > wrote:
>> >
>> >> On 5 Apr 2020, at 21:20, Tobias Kirchhofer wrote:
>> >>
>> >> we experience difficulties with crond behaviour sending mail
>> >> since
>> >> CentOS 8.1. The cron job is the same like we used in CentOS 7.
>> >>>
>> >>> Meanwhile we found the reason for the bug - actually we do not know
>> >>> if
>> >>> it is related to a specific version of CentOS or a specific kind of
>> >>> command as cron job.
>> >>>
>> >>> Let me explain what we have:
>> >>>
>> >>> - sssd for ssh login of ldap user
>> >>> - crond for cron jobs :)
>> >>>
>> >>> If we stop sssd and restart crond cron starts to send mails again!
>> >>>
>> >>> We started with sssd on newly provisioned machines with CentOS 8. We
>> >>> do not know if this is the same on CentOS 7.
>> >>>
>> >>> We send mails only to root. So no remote user is involved in cron.
>> >>>
>> >>> From our perspective it is a bug. How could we dive deeper to find
>> >>> the
>> >>> specific reason?
>> >>
>> >> To sum it up:
>> >>
>> >> - Install CentOS 8
>> >> - Enabled and started crond
>> >> - crond sends emails properly
>> >> - Enable and start sssd
>> >> - crond stops sending emails and starts journal logging
>> >> - Restart crond (or reboot)
>> >> - crond sends emails and stops journal logging
>> >>
>> >> It is a matter of order. At boot time crond starts after sssd.
>> >>
>> >> This situation is bearable if you know it but has cost us some hours.
>> >>
>> >> Thanks for reading and sorry for this public clarification process ;)
>> >>
>> >> Tobias
>> >>
>> >>
>> > So it sounds like that crond needs to have sssd as a pre-dependency so
>> > it
>> > doesn't start until sssd is running?
>>
>> No - if crond is already running and sssd is initially set and starting
>> (after crond) crond does not send mail. For whatever reason. At boot
>> time things are okay, crond starts after sssd. So if sssd is already
>> there, crond is fine. If sssd starts after crond, crond is not fine.
>>
>>
> I must have miscommunicated. I am saying what you are above and wondering
> if this is a place where putting a custome crond.service in
> /etc/systemd/system with
>
> [Unit]
> Description=Command Scheduler
> After=auditd.service systemd-user-sessions.service time-sync.target
> sssd.service
>
> [Service]
> EnvironmentFile=/etc/sysconfig/crond
> ExecStart=/usr/sbin/crond -n $CRONDARGS
> ExecReload=/bin/kill -HUP $MAINPID
> KillMode=process
> Restart=on-failure
> RestartSec=30s
>
> [Install]
> WantedBy=multi-user.target
>
> # 
>
> would fix the race. My apologies for not being clearer.

Just wondering here, if the system crond.service file is being
modified/fixed with an update by rpm package, will the custom file in
/etc/systemd/system also be fixed then?

Thanks,
Simon

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

Re: [CentOS] Mounting CIFS shares on C8

[Simon Matter via CentOS]

Then, what I'd try is

1) With an other directory like /mnt/xxx just to make sure it's not
something with /home that it doesn't like.

2) See what it's doing by running it with strace -f mount.

Regards,
Simon

> Exactly the same... 
>
>
> [root@plexvm ~]# mount -t cifs //192.168.1.200/mp3 /home/plex/Musique
> --verbose -o username=plex,password=plex,domain=DERWAEL,ro,auto,vers=3.0
> mount.cifs kernel mount options:
> ip=192.168.1.200,unc=\\192.168.1.200\mp3,vers=3.0,user=plex,domain=DERWAEL,pass=
> mount error(2): No such file or directory
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
> [root@plexvm ~]#
>
> Le ven. 3 avr. 2020 à 19:15, Simon Matter via CentOS  a
> écrit :
>
>> > That was my initial setup before trying the abbreviations, but anyway:
>> >
>> > [root@plexvm ~]# nano /etc/fstab
>> > [root@plexvm ~]# cat /etc/fstab
>> >
>> > #
>> > # /etc/fstab
>> > # Created by anaconda on Fri Apr  3 14:02:23 2020
>> > #
>> > # Accessible filesystems, by reference, are maintained under
>> '/dev/disk/'.
>> > # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more
>> > info.
>> > #
>> > # After editing this file, run 'systemctl daemon-reload' to update
>> systemd
>> > # units generated from this file.
>> > #
>> > /dev/mapper/cl_plexvm-root /   xfs defaults
>> >  0 0
>> > UUID=f7c4e0e2-703e-4e61-8d7a-0aa34f836b02 /boot   ext4
>> >  defaults1 2
>> > /dev/mapper/cl_plexvm-swap swapswapdefaults
>> >  0 0
>> > //192.168.1.200/mp3 /home/plex/Musique  cifs
>> >  username=plex,password=plex,domain=DERWAEL,ro,auto,vers=3.0
>> > #//192.168.1.200/videos /home/plex/Vidéos   cifs
>> >  user=plex,pass=plex,workgroup=DERWAEL,ro,auto,vers=3.0
>> > #//192.168.1.200/series /home/plex/Séries   cifs
>> >  user=plex,pass=plex,workgroup=DERWAEL,ro,auto,vers=3.0
>> > [root@plexvm ~]# systemctl daemon-reload
>> > [root@plexvm ~]# mount -a
>> > mount error(2): No such file or directory
>> > Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
>> > [root@plexvm ~]#
>> >
>>
>> What happens when you run
>>
>> mount -t cifs //192.168.1.200/mp3 /home/plex/Musique --verbose \
>>   -o username=plex,password=plex,domain=DERWAEL,ro,auto,vers=3.0
>>
>> Regards,
>> Simon
>>
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
>
>
> --
>
> Patrick Derwael
> Rue de la fontaine, 3
> 4210 Burdinne
> Tél:+32.(0)479.80.50.79
>


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

Re: [CentOS] IOMMU and kernel (solved?)

[Simon Matter via CentOS]

Hi,

> I think i might have solve it.
>
> For some reason grub2-mkconfig doesnt work.  (Have no idea why)

Is this on CentOS 7?

Well, yes, I remember that it didn't work for me when I installed new
servers one or two years ago, that was with CentOS 7 and they were my
first EFI installs.

>
> I manage to solve it with grubby.
>
> sudo grubby --args="intel_iommu=on" --update-kernel=ALL
>
> For some reason it works. I dont know if it works if my kernel gets
> upgraded.

I have restored the original configs after messing with grub2-mkconfig and
only used kernel installs to further modify grub config. That way it has
always worked for me. And I was a bis scared by the whole EFI, grub2 and
everything around it because I felt I don't really understand how it all
interacts in detail.

Regards,
Simon

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

Re: [CentOS] Mounting CIFS shares on C8

[Simon Matter via CentOS]

> That was my initial setup before trying the abbreviations, but anyway:
>
> [root@plexvm ~]# nano /etc/fstab
> [root@plexvm ~]# cat /etc/fstab
>
> #
> # /etc/fstab
> # Created by anaconda on Fri Apr  3 14:02:23 2020
> #
> # Accessible filesystems, by reference, are maintained under '/dev/disk/'.
> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more
> info.
> #
> # After editing this file, run 'systemctl daemon-reload' to update systemd
> # units generated from this file.
> #
> /dev/mapper/cl_plexvm-root /   xfs defaults
>  0 0
> UUID=f7c4e0e2-703e-4e61-8d7a-0aa34f836b02 /boot   ext4
>  defaults1 2
> /dev/mapper/cl_plexvm-swap swapswapdefaults
>  0 0
> //192.168.1.200/mp3 /home/plex/Musique  cifs
>  username=plex,password=plex,domain=DERWAEL,ro,auto,vers=3.0
> #//192.168.1.200/videos /home/plex/Vidéos   cifs
>  user=plex,pass=plex,workgroup=DERWAEL,ro,auto,vers=3.0
> #//192.168.1.200/series /home/plex/Séries   cifs
>  user=plex,pass=plex,workgroup=DERWAEL,ro,auto,vers=3.0
> [root@plexvm ~]# systemctl daemon-reload
> [root@plexvm ~]# mount -a
> mount error(2): No such file or directory
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
> [root@plexvm ~]#
>

What happens when you run

mount -t cifs //192.168.1.200/mp3 /home/plex/Musique --verbose \
  -o username=plex,password=plex,domain=DERWAEL,ro,auto,vers=3.0

Regards,
Simon

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

Re: [CentOS] IOMMU and kernel

[Simon Matter via CentOS]

> Hi.
> Im trying to set intel_iommu=on on kernel parameters at grub but for
> some reason it doesnt work.
>
> I edit /etc/default/grub file and i add the parameter.
>
> then i run grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg and then i
> reboot.

When you look at /boot/efi/EFI/centos/grub.cfg, do you see that the
parameter has been added?

Regards,
Simon

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

Re: [CentOS] Trying again: KDE fails with a gray screen after login, can't reinstall

[Simon Matter via CentOS]

> I set for graphical mode, I get the login screen, I change to KDE, and
> the screen goes black, then after minutes, gray with a cursor, and
> that's it - I left it overnight, no change.
>
> Brand new install (as of yesterday). Missed any "agree to license", and
> missed choosing software. Manually groupinstalled
> Installed Environment Groups:
> KDE Plasma Workspaces
> Development and Creative Workstation
>
> Tried to reinstall:
> No group named KDE Plasma Workspaces exists
>
> I'm assuming I need to install something else, but does anyone have a
> clue? I really do NOT want gnome.

I don't know how the situation is with C8 but I always liked XFCE to get
work done. It has less dependencies and is therefore a bit easier to
install.

Regards,
Simon

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

Re: [CentOS] Mounting CIFS shares on C8

[Simon Matter via CentOS]

> Hi all,
>
> I'm tearing my hair off trying to understand the difference between C7 &
> C8
> for mounting a cifs FS with fstab
>
> I'm building a Plex media server on C8 and duplicated the fstab entries
> over from my current C7 installation
> My data (music & movies) are on CIFS shares on a Synology NAS.
> The packages cifs-utils samba-client samba-common are installed, up to
> date
> etc...
>
> These are my current fstab entries on the C7 box
>
> //192.168.1.200/mp3 /home/plex/Musique cifs
> user=plex,pass=plex,ro,auto,vers=3.0
> //192.168.1.200/videos /home/plex/Vidéos cifs
> user=plex,pass=plex,ro,auto,vers=3.0
>
>
> On my C8:
>
> [root@plexvm etc]# cat fstab
>
> #
> # /etc/fstab
> # Created by anaconda on Fri Apr  3 14:02:23 2020
> #
> # Accessible filesystems, by reference, are maintained under '/dev/disk/'.
> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more
> info.
> #
> # After editing this file, run 'systemctl daemon-reload' to update systemd
> # units generated from this file.
> #
> /dev/mapper/cl_plexvm-root /   xfs defaults
>  0 0
> UUID=f7c4e0e2-703e-4e61-8d7a-0aa34f836b02 /boot   ext4
>  defaults1 2
> /dev/mapper/cl_plexvm-swap swapswapdefaults
>  0 0
> //192.168.1.200/mp3 /home/plex/Musique  cifs
>  user=plex,pass=plex,workgroup=DERWAEL,ro,auto,vers=3.0
> //192.168.1.200/videos  /home/plex/Vidéos   cifs
>  user=plex,pass=plex,workgroup=DERWAEL,ro,auto,vers=3.0
> //192.168.1.200/series  /home/plex/Séries   cifs
>  user=plex,pass=plex,workgroup=DERWAEL,ro,auto,vers=3.0
> [root@plexvm etc]# mount -a
> mount error(2): No such file or directory
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
> mount error(2): No such file or directory
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
> mount error(2): No such file or directory
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
> [root@plexvm etc]#
>
>
>
> Any pointer would be MUCH appreciated!

Do the directories /home/plex/Musique, /home/plex/Vidéos and
/home/plex/Séries really exist on the C8 host?

Regards,
Simon

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

Re: [CentOS] C8 and backup solution

[Simon Matter via CentOS]

> Once upon a time, Valeri Galtsev  said:
>> On 4/3/20 8:34 AM, John Pierce wrote:
>> >Do note, backup systems that use rsync or similar file by file copies
>> of a
>> >running system do not make coherent atomic snapshots, so things like
>> >relational databases should be excluded from those, and backed by
>> database
>> >tools
>>
>> Long ago I learned to back up databases by dumping them (with a flag
>> "lock" or similar to make sure no changed are made during dump), and
>> backing up dump file.
>
> It isn't just databases - there are other things that backing up
> individual files one at a time is not so good.  The best way to handle
> that is to freeze/snapshot the whole filesystem, and then back up the
> snapshot.  This can be scripted pretty easily if the filesystem is on
> LVM.
>
> Even better is to freeze _all_ filesystems simultaneously - this is
> usually easiest if the system is a virtual machine and/or the storage is
> on a SAN with snapshot capabilities.

Then again, to get a _really_ consistent backup, you can only terminate
all applications who read/write files, or instruct the applications to go
into a state which allows consistent file backups. Of course after the
backup you have to instruct the applications to go on with the work. You
can not achieve this consistency even with freezing _all_ filesystems
simultaneously. That's why usually RDBMS's and other more complex
applications provide their own backup mechanism embedded into the
application.

That's why rsnapshot backups are not so much worse than filesystem snapshots.

Regards,
Simon

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

Re: [CentOS] Need help to fix bug in rsync

[Simon Matter via CentOS]

> I appreciate the reply - it keeps me from wondering "is there something I
> should be concerned about?".  We use a co-location facility where we pay
> for bandwidth utilization so it's still an issue.

Hi,

You are right, bandwidth always costs, always.

Who pays for it can differ a lot, but there is always someone who pays.

It can be an individual, a company, the tax payer, whoever, but bandwidth
is never free.

Thanks,
Simon

>
> 
> From: CentOS  on behalf of Pete Biggs
> 
> Sent: Wednesday, March 25, 2020 1:32 PM
> To: centos@centos.org 
> Subject: [EXTERNAL] Re: [CentOS] Need help to fix bug in rsync
>
>
> Harriscomputer
>
> Leroy Tennison
> Network Information/Cyber Security Specialist
> E: le...@datavoiceint.com
>
>
> [cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]
>
>
> 2220 Bush Dr
> McKinney, Texas
> 75070
> www.datavoiceint.com<http://www..com>
>
>
> This message has been sent on behalf of a company that is part of the
> Harris Operating Group of Constellation Software Inc.
>
> If you prefer not to be contacted by Harris Operating Group please notify
> us<http://subscribe.harriscomputer.com/>.
>
>
>
> This message is intended exclusively for the individual or entity to which
> it is addressed. This communication may contain information that is
> proprietary, privileged or confidential or otherwise legally exempt from
> disclosure. If you are not the named addressee, you are not authorized to
> read, print, retain, copy or disseminate this message or any part of it.
> If you have received this message in error, please notify the sender
> immediately by e-mail and delete all copies of the message.
>
>
>
>
>
> On Wed, 2020-03-25 at 19:15 +0100, Simon Matter via CentOS wrote:
>> > On Wed, 2020-03-25 at 14:39 +, Leroy Tennison wrote:
>> > > Since you state that using -z is almost always a bad idea, could you
>> > > provide the rationale for that?  I must be missing something.
>> > >
>> > I think the "rationale" is that at some point the
>> > compression/decompression takes longer than the time reduction from
>> > sending a compressed file.  It depends on the relative speeds of the
>> > machines and the network.
>> >
>> > You have most to gain from compressing large files, but if they are
>> > already compressed, then you have nothing to gain from just doing
>> small
>> > files.
>> >
>> > It obviously depends on your network speed and if you have a metered
>> > connection, but does anyone really have such an ancient network
>> > connection still these days - I mean if you have fast enough machines
>> > at both ends to do rapid compression/decompression, it seems unlikely
>> > that you will have a damp piece of string connecting them.
>>
>> I really don't understand the discussion here. What is wrong with using
>> -z
>> with rsync? We're using rsync with -z for backups and just don't want to
>> waste bandwidth for nothing. We have better use for our bandwidth and it
>> makes quite a difference when backing up terabytes of data.
>
> I don't really care if you use -z, but you asked for the rationale, and
> I gave you it. I'm not telling you what you should do.
>
> I'll try and make it simpler - if rsync takes 1 second to compress the
> file, then 1 second to decompress the file, and the whole transfer of
> the file takes 11 seconds uncompressed vs 10 seconds compressed, then
> dealing with file takes overall 12 seconds compressed, vs 11 seconds
> uncompressed. It's not worth it.
>
> But as I said it depends on your network and your machine speeds.  It's
> up to you to decide what is best in your own situation.
>
> P.
>
>
> ___
> 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] Need help to fix bug in rsync

[Simon Matter via CentOS]

> On Wed, Mar 25, 2020 at 02:49:24PM +0100, Simon Matter via CentOS wrote:
>> Hi,
>>
>> I've discovered a bug in rsync which leads to increased CPU usage and
>> slower transfers in many situations.
>>
>> When syncing with compression (-z), certain file types should not be
>> compressed during the transfer because they are already compressed. The
>> file types which are not to be compressed can be seen in the man page
>> section --skip-compress.
>>
>> Unfortunately skipping the default file types doesn't work and all
>> transferred data is being compressed during the transfer. This is true
>> for
>> all versions since 3.1.0.
>>
>> Steps to Reproduce:
>> 1. run 'rm -f Z ; rsync -azv alpha:z.gz Z'
>>
>> Actual results, transferred data was compressed during the transfer:
>> sent 43 bytes  received 63,873 bytes  25,566.40 bytes/sec
>> total size is 628,952  speedup is 9.84
>>
>> Expected results:
>> No compression should happen for .gz file.
>>
>> Additional info:
>> Note that the source file 'z.gz' was an ascii text file to show clearly
>> that compression took place.
>
> That may invalidate your testing.
>
> rsync may not depend upon the filename extension
> but instead check the magic numbers within the file
> to determine whether to compress or not.

One could think so but it's not the case, rsync just uses the file suffix
to decide which files to compress. It even lower cases them, leaving good
old UNIX .Z file behind... Also a bug IMHO but not so important.

Simon

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

Re: [CentOS] Need help to fix bug in rsync

[Simon Matter via CentOS]

> On Wed, 25 Mar 2020, Leroy Tennison wrote:
>
>> Since you state that using -z is almost always a bad idea, could you
>> provide the rationale for that?  I must be missing something.
>
> I can't speak to that, but the obvious workaround is to use ssh's
> compression instead of rsync's:
>
> rsync -av -e 'ssh -C' remotehost:remote.file local.file

>From what I understand that's not really the same as having compression
inside rsync makes rsync transfers even better than only compressing the
transport.

Thanks,
Simon

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

Re: [CentOS] Need help to fix bug in rsync

[Simon Matter via CentOS]

> On Wed, 2020-03-25 at 14:39 +, Leroy Tennison wrote:
>> Since you state that using -z is almost always a bad idea, could you
>> provide the rationale for that?  I must be missing something.
>>
> I think the "rationale" is that at some point the
> compression/decompression takes longer than the time reduction from
> sending a compressed file.  It depends on the relative speeds of the
> machines and the network.
>
> You have most to gain from compressing large files, but if they are
> already compressed, then you have nothing to gain from just doing small
> files.
>
> It obviously depends on your network speed and if you have a metered
> connection, but does anyone really have such an ancient network
> connection still these days - I mean if you have fast enough machines
> at both ends to do rapid compression/decompression, it seems unlikely
> that you will have a damp piece of string connecting them.

I really don't understand the discussion here. What is wrong with using -z
with rsync? We're using rsync with -z for backups and just don't want to
waste bandwidth for nothing. We have better use for our bandwidth and it
makes quite a difference when backing up terabytes of data.

The only reason why I asked for help is because we don't want to double
compress data which is already compressed. This is what currently is
broken in rsync without manually specifying a skip-compress list. Fixing
it would help all those who don't know it's broken now.

Thanks,
Simon

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

[CentOS] Need help to fix bug in rsync

[Simon Matter via CentOS]

Hi,

I've discovered a bug in rsync which leads to increased CPU usage and
slower transfers in many situations.

When syncing with compression (-z), certain file types should not be
compressed during the transfer because they are already compressed. The
file types which are not to be compressed can be seen in the man page
section --skip-compress.

Unfortunately skipping the default file types doesn't work and all
transferred data is being compressed during the transfer. This is true for
all versions since 3.1.0.

Steps to Reproduce:
1. run 'rm -f Z ; rsync -azv alpha:z.gz Z'

Actual results, transferred data was compressed during the transfer:
sent 43 bytes  received 63,873 bytes  25,566.40 bytes/sec
total size is 628,952  speedup is 9.84

Expected results:
No compression should happen for .gz file.

Additional info:
Note that the source file 'z.gz' was an ascii text file to show clearly
that compression took place.

Please the following BZ for more info:
https://bugzilla.samba.org/show_bug.cgi?id=14323
https://bugzilla.redhat.com/show_bug.cgi?id=1816528

I tried to locate the bug in the code but failed. That said I'm not a C
developer and therefore need some help from someone who understands C
better than me. Any help is much appreciated!

Thanks and kind regards,
Simon

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

Re: [CentOS] Building a NFS server with a mix of HDD and SSD (for caching)

[Simon Matter via CentOS]

Hi,

> Hi list,
>
> I'm building a NFS server on top of CentOS 8.
> It has 8 x 8 TB HDDs and 2 x 500GB SSDs.
> The spinning drives are in a RAID-6 array. They are 4K sector size.
> The SSDs are in RAID-1 array and with a 512bytes sector size.
>
>
> I want to use the SSDs as a cache using dm-cache. So here what I've done
> so far:
> /dev/sdb ==> SSD raid1 array
> /dev/sdd ==> spinning raid6 array

Looks like you're using a hardware raid controller, right?

>
> I've added "allow_mixed_block_sizes = 1" to lvm.conf to be able to add
> sdb and sdd in the same VG (because of the sector size missmatch). But
> as the LVs will only use one and only one PV I guess it's OK.
>
> # lvcreate -L 500M -n lv_cache_meta VGnfs /dev/sdb
> # lvcreate -l +100%FREE -n lv_cache VGnfs /dev/sdb
> # lvconvert --type cache-pool /dev/VGnfs/lv_cache --poolmetadata
> /dev/VGnfs/lv_cache_meta
> # lvcreate -l +100%FREE -n LVnfs VGnfs /dev/sdd
> # lvconvert --type cache /dev/VGnfs/LVnfs --cachepool /dev/VGnfs/lv_cache
> # lvconvert --cachemode writeback --type cache /dev/VGnfs/LVnfs
> --cachepool /dev/VGnfs/lv_cache
> # mkfs.xfs /dev/VGnfs/LVnfs
>
> And now I'm asking myself if I'm not doing something somewhat dangerous
> for a server that will be critical when in production :]

I can't comment here as I've never used SSD as a cache the way you do it.

> The server has 128GB of RAM so maybe the caching in memory will be
> sufficient to achieve good performance ?

The 128GB will of course help as read cache but what about write cache? If
your raid hardware has battery/flash based write cache and is big enough,
then you could set it in write back mode and make use of it. I'm not sure
your proposed configuration is safe enough.

Regards,
Simon

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

Re: [CentOS] Need info on adobe flash player plugin 32 for CentOS7

[Simon Matter via CentOS]

> James Pearson wrote:
>>
>> J Martin Rushton via CentOS wrote:
>>>
>>> On 16/01/2020 20:37, Steve Clark wrote:
 On 01/16/2020 03:30 PM, Chris Adams wrote:
> Once upon a time, Kay Schenk  said:
>> I kept getting messages that my old Flash Player 31 was obsolete so
>> I went in search of an update.
> Adobe stopped releasing Flash for Linux a while back.  IIRC the only
> "supported" Flash on Linux is distributed as a part of Google Chrome
> (and that's going away sometime soon too, Chrome on all platforms
> will
> no longer support Flash).
>
 Don't know about C7 but I just yum updated my C6 system.
 adobe-linux-x86_64 | 2.9 kB 00:00

 Resolving Dependencies
 --> Running transaction check
 ---> Package flash-plugin.x86_64 0:32.0.0.255-release will be updated
 ---> Package flash-plugin.x86_64 0:32.0.0.314-release will be an
 update
 --> Finished Dependency Resolution

>>> It's still supported on C7:
>>>
>>> $ yum list | grep flash
>>> flash-plugin.x86_64    32.0.0.314-release @adobe-linux-x86_64
>>> ...
>>
>> I think you'll find the latest releases won't run on CentOS 7:
>>
>> % ldd libflashplayer.so
>> ./libflashplayer.so: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not
>> found (required by ./libflashplayer.so)
>>
>> and hence Firefox won't load this version ...
>>
>> The last version that runs on CentOS 7 is 32.0.0.270
>>
>> See: https://tracker.adobe.com/#/view/FP-4199058
>
> Adobe have recently released Flash 32.0.0.330 - which works OK on CentOS
> 6/7

Thanks for lettings us know, I already gave up checking as they didn't
manage to fix it for so many weeks.

Seems they finally found out that upgrading their build hosts to the
latest greatest distribution was not the smartest idea :-)

Regards,
Simon

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

Re: [CentOS] NetworkManager on servers

[Simon Matter via CentOS]

> On 09/02/2020 23:55, Nicolas Kovacs wrote:
>
> Hi Nicolas,
>
> [snip]
>
>> Maybe there's a reason to make NetworkManager more or less mandatory
>> from now on, but I don't see it. So I thought I'd rather ask on this
>> list.
>
> Like you, I read about NetworkManager becoming the default tool for
> CentOS 8. So I sat down with a colleague to figure out how we could use
> NetworkManager, and convert our existing network configs (on CentOS 6
> and 7) to work with NetworkManager.
>
> I'm sad to report that we ran into at least 3 issues (listed below). We
> found solutions to the first two, but the last one was a show-stopper,
> and we came to the conclusion that for servers, NetworkManager is still
> overkill, and for us, actually unusable. So even on CentOS 8, we will
> keep using the legacy scripts.
>
> 1. When NetworkManager activates interfaces, it does not wait for IPv6
> DAD to complete. This makes systemd reach the "network-online" target
> before IPv6 is fully initialised, and some daemons fail to start. We
> eventually found a work-around, but not before I'd lost some of my hair.
>
> 2. NetworkManager doesn't know how to activate dummy interfaces from
> ifcfg-dummy* files. You have to create dummy interfaces directly in
> NetworkManager. This is not a problem on CentOS 8, but on CentOS 7,
> there is a subtle issue with loading the dummy module that makes things
> fail at boot. We again found the solution, but it's annoying that none
> of it was documented.
>
> 3. Some of our servers run full routing daemons (BIRD), and have
> multiple route tables. On these, when we start NetworkManager, it
> attempts to read the entire route tables into memory using the netlink
> API. This makes it log lots of errors. Then, NetworkManager's RAM usage
> goes up and up, going to over 3 GB!! Finally, it barfs and dies. And
> then systemd starts it again, and it goes and does the same.
>
> We have NOT been able to find any solution to this stupidity of
> NetworkManager. And so we have made the choice to abandon it, and remain
> with legacy network scripts.

Thanks for confirming that NetworkManager is not the solution for
everyone. To me it seems that NetworkManager was developed by laptop users
for laptop users and that's why it is what it is today. Useful for
laptops/desktops and simple server setups.

Unfortunately, instead of fixing/refactoring the whole bash networking
script mess, another new project was started instead, called
systemd-networkd :-)

Regards,
Simon

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

Re: [CentOS] Relabel /usr directory

[Simon Matter via CentOS]

> Hi,
> I've done the following:
> - Copy usr content with rsync to another partition:
>
> rsync -av --partial --progress /usr/ /mnt

I won't comment on you real question but just want to suggest to really
add -H to the rsync here as there are hardlinks in /usr you really want to
keep.

Simon

>
> Then, unmounted, added to fstab a line for /usr, then deleted /usr/* (not
> the directory itself). But I've found that is bad labeled:
>
> ls -Z /usr
> unconfined_u:object_r:unlabeled_t:s0 bin
>  unconfined_u:object_r:unlabeled_t:s0 local
> unconfined_u:object_r:unlabeled_t:s0 games
>  unconfined_u:object_r:unlabeled_t:s0 sbin
> unconfined_u:object_r:unlabeled_t:s0 include
>  unconfined_u:object_r:unlabeled_t:s0 share
> unconfined_u:object_r:unlabeled_t:s0 lib
>  unconfined_u:object_r:unlabeled_t:s0 src
> unconfined_u:object_r:unlabeled_t:s0 lib64
>  unconfined_u:object_r:unlabeled_t:s0 tmp
>
> How can I restore the default contexts?
>
> I've tried with restorecon and with fixfiles, but no luck, for example:
>
> matchpathcon -V /usr
> /usr error: No data available
>
> How can I fix this?
>
> Thanks in advance.
> --
> --
> Sergio Belkin
> LPIC-2 Certified - http://www.lpi.org
> ___
> 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] (SOLVED) YUM (DNF) Possible Confusion Centos 8

[Simon Matter via CentOS]

> On 1/24/20 8:02 AM, Simon Matter via CentOS wrote:
>>> 
>>>
>>>
>>>> The redhat access page comes up in both google and duckduckgo when I
>>>> put
>>>> in the entire 4 lines of the error message.  You still have to login
>>>> to
>>>> see the solution.
>>>>
>>>> https://www.google.com/search?client=ubuntu=fs=+Problem+1%3A+conflicting+requests+++-+nothing+provides+module%28perl%3A5.26%29+needed+by+module+perl-DBD-SQLite%3A1.58%3A8010020190322125518%3A073fa5fe-0.x86_64++Problem+2%3A+conflicting+requests+++-+nothing+provides+module%28perl%3A5.26%29+needed+by+module+perl-DBI%3A1.641%3A8010020190322130042%3A16b3ab4d-0.x86_64=utf-8=utf-8
>>>>
>>>> Other than that you could create a login on the redhat site and
>>>> register
>>>> as a developer (free of charge) and have access to some of their
>>>> online
>>>> resources including the access knowledgebase.
>>>>
>>>> I am mostly a CentOS user, and installed redhat 8 so I could start
>>>> working on my applications before CentOS 8 was released.
>>>>
>>>>
>>>> Nataraj
>>>
>>> I have a free subscription, but still can't get to the solution page.
>>> Oh
>>> well.
>>
>> I've never really understood how hiding those solutions behind a wall is
>> a
>> good thing in/for the OpenSource world. Looks like I'm not alone :-)
>>
>
> A good thing is the ability for someone to be able to pay people actual
> money so that CentOS can actually exist.  There is no CentOS (or
> Scientfic Linux or Oracle Linux) without RHEL.  There is no RHEL if Red
> Hat can not make money.

And there is no RedHat if thousands of developers would not allow RedHat
to consume their work for free. Creators of free software didn't build
walls around their projects. Do you thinks it's a good thing that RedHat
does exactly this with their tip and tricks (KB)? I believe it can damage
RedHat because a lot of people at the source of RedHats products don't
appreciate it at all.

Regards,
Simon

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

Re: [CentOS] (SOLVED) YUM (DNF) Possible Confusion Centos 8

[Simon Matter via CentOS]

> On 1/24/20 8:02 AM, Simon Matter via CentOS wrote:
>>> 
>>>
>>>
>>>> The redhat access page comes up in both google and duckduckgo when I
>>>> put
>>>> in the entire 4 lines of the error message.  You still have to login
>>>> to
>>>> see the solution.
>>>>
>>>> https://www.google.com/search?client=ubuntu=fs=+Problem+1%3A+conflicting+requests+++-+nothing+provides+module%28perl%3A5.26%29+needed+by+module+perl-DBD-SQLite%3A1.58%3A8010020190322125518%3A073fa5fe-0.x86_64++Problem+2%3A+conflicting+requests+++-+nothing+provides+module%28perl%3A5.26%29+needed+by+module+perl-DBI%3A1.641%3A8010020190322130042%3A16b3ab4d-0.x86_64=utf-8=utf-8
>>>>
>>>> Other than that you could create a login on the redhat site and
>>>> register
>>>> as a developer (free of charge) and have access to some of their
>>>> online
>>>> resources including the access knowledgebase.
>>>>
>>>> I am mostly a CentOS user, and installed redhat 8 so I could start
>>>> working on my applications before CentOS 8 was released.
>>>>
>>>>
>>>> Nataraj
>>>
>>> I have a free subscription, but still can't get to the solution page.
>>> Oh
>>> well.
>>
>> I've never really understood how hiding those solutions behind a wall is
>> a
>> good thing in/for the OpenSource world. Looks like I'm not alone :-)
>>
>
> A good thing is the ability for someone to be able to pay people actual
> money so that CentOS can actually exist.  There is no CentOS (or
> Scientfic Linux or Oracle Linux) without RHEL.  There is no RHEL if Red
> Hat can not make money.

I can not agree here. To make this clear, I'm not from the "everything
must be free to consume" crowd just in case it sounds so. But when we talk
about money and RedHat my POV is this:

1) RedHat has made quite a lot of money through me in the past decades! Of
course not from my personal purchases but from those companies who bought
from RedHat because I was behind the projects.

2) RedHat includes the work of thousands of people around the world
without paying a cent to most of them. One of them is me, work from me can
be found in RedHat products and it's from my personal work as well as work
I did for companies who agreed to keep this work free for everybody as
well.

I never asked a cent from RedHat and don't expect it. I only don't like
how they've built walls to prevent me from having access to some useful
tips and tricks which can make my life easier.

That's why I don't like these walls even if you can climb them for free
somehow if you learn how.

Regards,
Simon

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

Re: [CentOS] Centos 7: UPD packet checksum verification?

[Simon Matter via CentOS]

> On Tuesday, January 28, 2020 1:50:57 PM CET Stephen John Smoogen wrote:
>> On Sun, 26 Jan 2020 at 20:45, hw  wrote:
>> > > I'm not sure I understand what you are asking.
>> >
>> > It is about VOIP calls via SRTP being interrupted at irregular
>> intervals.
>> > The intervals appear to depend on the time of day:  Such phone calls
>> can
>> > last for a duration of about 5--25 minutes during the day to up to 1.5
>> > hours at around 3am before being interrupted.
>>
>> UDP is called Unreliable Datagram Protocol for a reason. It can be
>> dropped at all kinds of places in between the two users depending on
>> how busy the routers/firewalls between 2 users can be.
>
> How would packets being dropped explain the replay errors and
> authentication
> failures?
>
>> Packets can get
>> out of order or a dozen other things which then relies on the
>> application layer to put the things back in 'order'.
>
> libsrtp seems to have provisions to deal with packets arriving out of
> order.
>
>> For voice, that
>> usually means a drop or other ugliness because it is assumed that if
>> the quality is too bad, the people would just call each other again.
>
> That's a funny idea.  Phone calls just worked fine and were good quality
> 25
> years ago, and mostly long before that.  I have never expected to have to
> call
> anyone back because of poor quality in over 40 years, and I'm not going to
> start to expect that now.

Just wait another 10 or 20 years and everybody will tell you it's normal
and nothing to worry. They won't believe you if you tell them there was a
time long ago when telephony just worked.

I remember in around 1999, when a lot of companies started to hear about
VoIP and wanted to implement it to save money and welcome the future, I
had lot's of discussion about it in the company I was working back then.
Those who new a bit more from the technology side said this can be done in
a company but not widely as a replacement for (public) telephony
infrastructure. Now that whole countries went all IP, just listen to
police and emergency services what they think about it: only now they
start to realize that having telephony which just works is a thing of the
past!

But hey, don't worry, they will fix it with "the Cloud" :-)

>
> It's unacceptable, and it's not feasible, either.  For example, try to
> call
> paypal to solve some issue with your account.  It can take an hour before
> they
> call you back because everyone is busy.  Finally you talk to someone and
> just
> after you explained the problem, the call is interrupted.  Good luck
> calling
> the same person back.  You won't get anywhere because your next try will
> only
> result in another interrupted call.
>
>> For the most part this works pretty well but all it takes is a
>> firewall to get busy on something else and you have a bunch of UDP
>> packets out of order and people's calls dropping.
>
> VOIP calls are worlds away from what phone calls used to be.  Dropping
> calls
> has never been an option and is not an option now.

Telephony is like operating systems these days: a lot of things improve
but not everything...

Regards,
Simon

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

Re: [CentOS] Centos 7 32 Bits install. Answer to Johnny Hughes.

[Simon Matter via CentOS]

> On Thu, Jan 23, 2020 at 8:54 AM Ger van Dijck 
> wrote:
>
>> But when trying to do a fresh install or a netinstall (both Centos 7) I
>> get the following message :
>>
>> [ 0.123604] ACPI:SCI(ACPI GSI 9) not registered
>> [28.595238] systemd[1] Caught  , dump core as pid 75
>> [28.595814] systemd[1] : Freezing execution.
>>
>>
>> Question : What now ?
>
>
> Possibly:
> https://access.redhat.com/solutions/58790

And please report back if it's the solution so others may know it too.

Simon

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

Re: [CentOS] C8 Question

[Simon Matter via CentOS]

>
>> I noticed a strange behaviour (don't know if this is the wanted
>> default). If I try ,from normal user shell, to run command like "reboot"
>> or "shutdown -h now" system will reboot/shutdown. This happens on tty
>> console, on xfce terminal and ssh session.
>
> I've just created a normal user on my test system and when I try to
> reboot or halt the system when logged in via ssh I get:
>
>$ reboot
>Failed to set wall message, ignoring: Interactive authentication
> required.
>Failed to reboot system via logind: Interactive authentication
> required.
>Failed to open initctl fifo: Permission denied
>Failed to talk to init daemon.
>
> Which is correct behaviour.
>
> However, a user logged in at the machine as GUI console session has
> always been able to halt or reboot the system.
>
>>
>> Why on CentOS a normal user can shutdown the system without root
>> privileges? I think that on any server normal user should not be able to
>> shutdown the system without privileges.
>>
> If it's a desktop machine, then the console logged in user should be
> able to shutdown the machine - at least then it means they don't resort
> to pulling the plug.  Presumably you don't allow users physically near
> a server?

That's why I asked if the user who was logged in via ssh was also logged
in locally at the same time. That would at lest explain such behavior.

Regards,
Simon

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

Re: [CentOS] C8 Question

[Simon Matter via CentOS]

>
> Il 24/01/20 15:11, Simon Matter via CentOS ha scritto:
>>> Hi list,
>>>
>>> I installed on my workstation C8.1 (1911) and performed a minimal
>>> install and then installed XFCE from EPEL.
>>>
>>> I noticed a strange behaviour (don't know if this is the wanted
>>> default). If I try ,from normal user shell, to run command like
>>> "reboot"
>>> or "shutdown -h now" system will reboot/shutdown. This happens on tty
>>> console, on xfce terminal and ssh session.
>> But can you describe exactly in which situation user x can shutdown? I
>> mean, if you say via ssh connection, is it that user x is at the same
>> time
>> also logged in into XFCE desktop on the same system? Or is it also true
>> if
>> the only login to the system at this time is via the ssh connection and
>> then user x is still able to shutdown?
>>
>> I mean if user x runs the XFCE session remote on the system using ssh
>> X11
>> forwarding, NX or whatever, then user x should really NOT be able to
>> shutdown without providing the root password. That would be a nightmare
>> for multi user systems :-)
>>
>> Regards,
>> Simon
>>
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>
> Hi Simon,
>
> I tried on my system using XFCE, I tried with a fresh installation on vm
> without X (using minimal and server installation), inside ssh
> with/without user logged and from tty console.
>
> Try to reproduce it. Install C8 on a VM using minimal installation,
> login in as normal user an type reboot.

Well, I didn't install C8 yet but do you say that if do a fresh server
type install of C8 on a host, add an unprivileged user, login via ssh to
the user account on the host, you can reboot then?

Regards,
Simon

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

Re: [CentOS] C8 Question

[Simon Matter via CentOS]

> Hi list,
>
> I installed on my workstation C8.1 (1911) and performed a minimal
> install and then installed XFCE from EPEL.
>
> I noticed a strange behaviour (don't know if this is the wanted
> default). If I try ,from normal user shell, to run command like "reboot"
> or "shutdown -h now" system will reboot/shutdown. This happens on tty
> console, on xfce terminal and ssh session.

But can you describe exactly in which situation user x can shutdown? I
mean, if you say via ssh connection, is it that user x is at the same time
also logged in into XFCE desktop on the same system? Or is it also true if
the only login to the system at this time is via the ssh connection and
then user x is still able to shutdown?

I mean if user x runs the XFCE session remote on the system using ssh X11
forwarding, NX or whatever, then user x should really NOT be able to
shutdown without providing the root password. That would be a nightmare
for multi user systems :-)

Regards,
Simon

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

Re: [CentOS] (SOLVED) YUM (DNF) Possible Confusion Centos 8

[Simon Matter via CentOS]

> 
>
>
>>The redhat access page comes up in both google and duckduckgo when I put
>>in the entire 4 lines of the error message.  You still have to login to
>>see the solution.
>>
>>https://www.google.com/search?client=ubuntu=fs=+Problem+1%3A+conflicting+requests+++-+nothing+provides+module%28perl%3A5.26%29+needed+by+module+perl-DBD-SQLite%3A1.58%3A8010020190322125518%3A073fa5fe-0.x86_64++Problem+2%3A+conflicting+requests+++-+nothing+provides+module%28perl%3A5.26%29+needed+by+module+perl-DBI%3A1.641%3A8010020190322130042%3A16b3ab4d-0.x86_64=utf-8=utf-8
>>
>>Other than that you could create a login on the redhat site and register
>>as a developer (free of charge) and have access to some of their online
>>resources including the access knowledgebase.
>>
>>I am mostly a CentOS user, and installed redhat 8 so I could start
>>working on my applications before CentOS 8 was released.
>>
>>
>>Nataraj
>
> I have a free subscription, but still can't get to the solution page.  Oh
> well.

I've never really understood how hiding those solutions behind a wall is a
good thing in/for the OpenSource world. Looks like I'm not alone :-)

Simon

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

Re: [CentOS] yum update / kernal update failed - remove or repair

[Simon Matter via CentOS]

> On 1/22/20 3:57 PM, Gary Stainburn wrote:
>> I have managed to find out what happened in the yum update and it turns
>> out it was a mess.  It looks like the server ran out of memory in the
>> middle and things then started to fail.  Any advice on how to recover
>> from this would be greatly appreciated
>>
>> The log below shows:
>>
>> [root@vps2 ~]# yum history info 22
>> Loaded plugins: fastestmirror, langpacks
>> Repository mariadb is listed more than once in the configuration
>> Transaction ID : 22
>> Begin time : Sun Jan 19 18:15:33 2020
>> Begin rpmdb: 795:6c5cd82e3ada047c7071fea1524f41fd13fab6a1
>> End time   :19:19:32 2020 (63 minutes)
>> End rpmdb  : 801:6d1b278ccbeef6f68ff494cb28eaed5c7be4124b
>> User   : root 
>> Return-Code: Failure: 1
>> Command Line   : update
>> Transaction performed with:
>> Installed rpm-4.11.3-40.el7.x86_64
>> @anaconda
>> Installed yum-3.4.3-163.el7.centos.noarch
>> @anaconda
>> Installed yum-plugin-fastestmirror-1.1.31-52.el7.noarch
>> @anaconda
>> Packages Altered:
>> Updated MariaDB-client-10.4.10-1.el7.centos.x86_64@mariadb
>> Update 10.4.11-1.el7.centos.x86_64@mariadb
>> Updated MariaDB-common-10.4.10-1.el7.centos.x86_64@mariadb
>> Update 10.4.11-1.el7.centos.x86_64@mariadb
>> Updated MariaDB-compat-10.4.10-1.el7.centos.x86_64@mariadb
>> Update 10.4.11-1.el7.centos.x86_64@mariadb
>>  ** Updated MariaDB-server-10.4.10-1.el7.centos.x86_64@mariadb
>> Loading mirror speeds from cached hostfile
>>  * base: mirror.as29550.net
>>  * epel: www.mirrorservice.org
>>  * extras: www.mirrorservice.org
>>  * remi-php73: mirrors.ukfast.co.uk
>>  * remi-safe: mirrors.ukfast.co.uk
>>  * updates: www.mirrorservice.org
>>  ** Update 10.4.11-1.el7.centos.x86_64@?mariadb
>>  ** Updated MariaDB-shared-10.4.10-1.el7.centos.x86_64@mariadb
>> Update 10.4.11-1.el7.centos.x86_64@mariadb
>>  ** Updated ca-certificates-2018.2.22-70.0.el7_5.noarch   @anaconda
>>  ** Update  2019.2.32-76.el7_7.noarch @?updates
>> Updated certbot-0.39.0-1.el7.noarch   @epel
>> Update  1.0.0-1.el7.noarch@epel
>> Updated clamav-0.101.4-1.el7.x86_64   @epel
>> Update 0.101.5-1.el7.x86_64   @epel
>> Updated clamav-data-0.101.4-1.el7.noarch  @epel
>> Update  0.101.5-1.el7.noarch  @epel
>> Updated clamav-devel-0.101.4-1.el7.x86_64 @epel
>> Update   0.101.5-1.el7.x86_64 @epel
>> Updated clamav-filesystem-0.101.4-1.el7.noarch@epel
>> Update0.101.5-1.el7.noarch@epel
>> Updated clamav-lib-0.101.4-1.el7.x86_64   @epel
>> Update 0.101.5-1.el7.x86_64   @epel
>> Updated clamav-update-0.101.4-1.el7.x86_64@epel
>> Update0.101.5-1.el7.x86_64@epel
>> Updated clamd-0.101.4-1.el7.x86_64@epel
>> Update0.101.5-1.el7.x86_64@epel
>> Updated curl-7.29.0-54.el7.x86_64 @anaconda
>> Update   7.29.0-54.el7_7.1.x86_64 @updates
>> Updated fail2ban-0.9.7-1.el7.noarch   @epel
>> Update   0.10.4-1.el7.noarch  @epel
>> Updated fail2ban-firewalld-0.9.7-1.el7.noarch @epel
>> Update 0.10.4-1.el7.noarch@epel
>> Updated fail2ban-sendmail-0.9.7-1.el7.noarch  @epel
>> Update0.10.4-1.el7.noarch @epel
>> Updated fail2ban-server-0.9.7-1.el7.noarch@epel
>> Update  0.10.4-1.el7.noarch   @epel
>> Updated fail2ban-systemd-0.9.7-1.el7.noarch   @epel
>> Update   0.10.4-1.el7.noarch  @epel
>> Updated fribidi-1.0.2-1.el7.x86_64@anaconda
>> Update  1.0.2-1.el7_7.1.x86_64@updates
>> Updated iproute-4.11.0-25.el7.x86_64  @anaconda
>> Update  4.11.0-25.el7_7.2.x86_64  @updates
>> Install kernel-3.10.0-1062.9.1.el7.x86_64 @updates
>> Updated kernel-headers-3.10.0-1062.4.3.el7.x86_64 @updates
>> Update 3.10.0-1062.9.1.el7.x86_64 @updates
>> Updated kernel-tools-3.10.0-1062.4.3.el7.x86_64   @updates
>> Update   3.10.0-1062.9.1.el7.x86_64   @updates
>> Updated kernel-tools-libs-3.10.0-1062.4.3.el7.x86_64  @updates
>> Update 

Re: [CentOS] dbus/systemd failure on startup (CentOS 7.7)

[Simon Matter via CentOS]

> Simon Matter via CentOS wrote:
>>
>>> We are seeing a problem that occurs ~5% of the time when rebooting
>>
>> I see such issues on a quite large multi user system but when this
>> happens, after forced restarts for kernel updates, I usually don't have
>> the time to analyze and play doctor on it. My "solution" now is to
>> simply
>> reboot the server again in such a case, AKA the systemd way :-)
>>
>>> CentOS 7.7 where systemd gets a 'Connection timed out' to D-Bus just
>>> after the D-Bus service starts - from 'journalctl -x' :
>>>
>>> ...
>>> Jan 21 16:09:59 linux7-7.mpc.local systemd[1]: Started D-Bus System
>>> Message Bus.
>>> -- Subject: Unit dbus.service has finished start-up
>>> -- Defined-By: systemd
>>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>> --
>>> -- Unit dbus.service has finished starting up.
>>> --
>>> -- The start-up result is done.
>>> Jan 21 16:10:24 linux7-7.mpc.local systemd[1]: Failed to register match
>>> for Disconnected message: Connection timed out
>>> Jan 21 16:10:24 linux7-7.mpc.local systemd[1]: Failed to initialize
>>> D-Bus connection: Connection timed out
>>> ...
>>>
>>> This then has a knock-on effect that causes other services to fail -
>>> e.g.
>>>
>>> -- Unit gdm.service has begun starting up.
>>> Jan 21 16:10:39 linux7-7.mpc.local dbus[817]: [system] Activating
>>> systemd to hand-off: service name='org.freedesktop.login1'
>>> unit='dbus-org.freedesktop.login1.service'
>>> Jan 21 16:10:50 linux7-7.mpc.local dbus[817]: [system] Failed to
>>> activate service 'org.freedesktop.systemd1': timed out
>>> Jan 21 16:10:50 linux7-7.mpc.local systemd-logind[1221]: Failed to
>>> enable subscription: Failed to activate service
>>> 'org.freedesktop.systemd1': timed out
>>> Jan 21 16:10:50 linux7-7.mpc.local systemd-logind[1221]: Failed to
>>> fully
>>> start up daemon: Connection timed out
>>> Jan 21 16:10:50 linux7-7.mpc.local systemd[1]: systemd-logind.service:
>>> main process exited, code=exited, status=1/FAILURE
>>> Jan 21 16:10:50 linux7-7.mpc.local systemd[1]: Failed to start Login
>>> Service.
>>> -- Subject: Unit systemd-logind.service has failed
>>> -- Defined-By: systemd
>>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>> --
>>> -- Unit systemd-logind.service has failed.
>>> --
>>> -- The result is failed.
>>>
>>> Whatever the issue is, it appears that polkit might be involved - if we
>>> restart the polkit service, things appear to return to normal (e.g. gdm
>>> starts up etc)
>>>
>>> We can't find any similar reports of this happening elsewhere with
>>> CentOS 7.7 - but we were wondering if anyone else had come across a
>>> problem like this?
>>
>> I think the root of the problem is that there are missing definitions in
>> some of the systemd scripts. They allow things to work in 95% or greater
>> of the cases but this happens by chance, not because of perfect process
>> handling and system control. Small delays somewhere or uncommon system
>> environments then lead to intermittent failures which are difficult to
>> diagnose - at least for me.
>>
>> The good news is that you can just fiddle with the systemd scripts the
>> same way we fiddled with init scripts in the past. That way you can try
>> and error until you find a solution. Doesn't sound like being in full
>> control of things but better than not finding a solution at all.
>
> Yeah, we found that by introducing a small delay before the ExecStart in
> the dbus.service unit - even a delay of just 0.01 seconds (via
> 'ExecStartPre=/usr/bin/sleep 0.01') _seems_ to workaround the issue ...

Nice that you found at least a workaround. I think I remember that dbus is
quite special here because systemd starts it but also depends on it. At
least I remember cases where dbus got crazy for whatever reason: the
result was that systemd became completely unresponsive and unmanageable
and the whole system went down the drain, slowly but steady. Ever tried to
shutdown a box if systemd doesn't listen to you anymore? The perfect
Windows experience on Linux ;-)

> However, we would still like to know what the issue is and get a 'real'
> fix - I guess we could try creating a bug report with Redhat ...

By bug report you mean BZ or a support request as paying RHEL customer?

Unfortunately I'm not too happy anymore with how BZs are handled these
days. Am I alone with this feeling?

Regards,
Simon

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

Re: [CentOS] dbus/systemd failure on startup (CentOS 7.7)

[Simon Matter via CentOS]

> We are seeing a problem that occurs ~5% of the time when rebooting

I see such issues on a quite large multi user system but when this
happens, after forced restarts for kernel updates, I usually don't have
the time to analyze and play doctor on it. My "solution" now is to simply
reboot the server again in such a case, AKA the systemd way :-)

> CentOS 7.7 where systemd gets a 'Connection timed out' to D-Bus just
> after the D-Bus service starts - from 'journalctl -x' :
>
> ...
> Jan 21 16:09:59 linux7-7.mpc.local systemd[1]: Started D-Bus System
> Message Bus.
> -- Subject: Unit dbus.service has finished start-up
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit dbus.service has finished starting up.
> --
> -- The start-up result is done.
> Jan 21 16:10:24 linux7-7.mpc.local systemd[1]: Failed to register match
> for Disconnected message: Connection timed out
> Jan 21 16:10:24 linux7-7.mpc.local systemd[1]: Failed to initialize
> D-Bus connection: Connection timed out
> ...
>
> This then has a knock-on effect that causes other services to fail - e.g.
>
> -- Unit gdm.service has begun starting up.
> Jan 21 16:10:39 linux7-7.mpc.local dbus[817]: [system] Activating
> systemd to hand-off: service name='org.freedesktop.login1'
> unit='dbus-org.freedesktop.login1.service'
> Jan 21 16:10:50 linux7-7.mpc.local dbus[817]: [system] Failed to
> activate service 'org.freedesktop.systemd1': timed out
> Jan 21 16:10:50 linux7-7.mpc.local systemd-logind[1221]: Failed to
> enable subscription: Failed to activate service
> 'org.freedesktop.systemd1': timed out
> Jan 21 16:10:50 linux7-7.mpc.local systemd-logind[1221]: Failed to fully
> start up daemon: Connection timed out
> Jan 21 16:10:50 linux7-7.mpc.local systemd[1]: systemd-logind.service:
> main process exited, code=exited, status=1/FAILURE
> Jan 21 16:10:50 linux7-7.mpc.local systemd[1]: Failed to start Login
> Service.
> -- Subject: Unit systemd-logind.service has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit systemd-logind.service has failed.
> --
> -- The result is failed.
>
> Whatever the issue is, it appears that polkit might be involved - if we
> restart the polkit service, things appear to return to normal (e.g. gdm
> starts up etc)
>
> We can't find any similar reports of this happening elsewhere with
> CentOS 7.7 - but we were wondering if anyone else had come across a
> problem like this?

I think the root of the problem is that there are missing definitions in
some of the systemd scripts. They allow things to work in 95% or greater
of the cases but this happens by chance, not because of perfect process
handling and system control. Small delays somewhere or uncommon system
environments then lead to intermittent failures which are difficult to
diagnose - at least for me.

The good news is that you can just fiddle with the systemd scripts the
same way we fiddled with init scripts in the past. That way you can try
and error until you find a solution. Doesn't sound like being in full
control of things but better than not finding a solution at all.

Regards,
Simon

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

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 8 (1911)

[Simon Matter via CentOS]

> On 1/16/20 5:03 PM, Gianluca Cecchi wrote:
>> On Thu, Jan 16, 2020 at 11:08 PM Peter  wrote:
>>
>>> On 17/01/20 8:06 am, Lamar Owen wrote:
 On 1/16/20 6:49 AM, Peter wrote:
> On 16/01/20 4:14 am, Brian Stinson wrote:
>> Release for CentOS Linux 8 (1911)
>>
>> We are pleased to announce the general availability of CentOS Linux
>> 8.
>
> CentOS 8 was released in September 2019.  Don't you mean 8.1?
 No, they mean CentOS 8 (1911).  This was hashed to death back in early
 CentOS 7 days, so shouldn't need rehashing again..
>>>
>>> No, the hashing ove back then had nothing to do with dropping the minor
>>> release number.  Doing that now is just making things way too
>>> confusing.
>>>
>>> Back then the vast majority of the community showed disapproval for
>>> even
>>> that new naming scheme, but the wishes of the community were ignored
>>> and
>>> the new naming scheme went ahead anyways.  I doubt anything different
>>> will happen now.
>>>
 Yeah, I know most people are going to call it 8.1,
>>>
>>> That's because it *is* 8.1 and calling it 8 (1911) is just confusing
>>> and
>>> ridiculous.
>>>
>>>
>>> Peter
>>>
>>
>> I think that the e-mail subject of the announcement could be a bit
>> misleading.
>> Also for 7.x the subject for the latest one, posted by Johnny, was:
>>
>> "Release for CentOS Linux 7 (1908) on the x86_64  Architecture"
>>
>> Actually at CentOS 7 time, after some discussions, developers accepted
>> to
>> have both "numbers" inside release information.
>>
>> For example on running systems you have
>>
>> - for 7.x
>> On 7.6:
>> # cat /etc/centos-release
>> CentOS Linux release 7.6.1810 (Core)
>>
>> # lsb_release -r
>> Release: 7.6.1810
>>
>> On 7.7:
>> # cat /etc/centos-release
>> CentOS Linux release 7.7.1908 (Core)
>>
>> # lsb_release -r
>> Release: 7.7.1908
>>
>> And this has been maintained in 8.x too:
>> On 8.0:
>> # cat /etc/centos-release
>> CentOS Linux release 8.0.1905 (Core)
>>
>> # lsb_release -r
>> Release: 8.0.1905
>>
>> On the just released 8.1
>> # cat /etc/centos-release
>> CentOS Linux release 8.1.1911 (Core)
>>
>> # lsb_release -r
>> Release: 8.1.1911
>>
>> This is acceptable in my opinion from a final user point of view
>>
>> I'm not sure but possibly the origin of the lng discussion thread
>> was
>> this one from Karanbir, if interested:
>> https://lists.centos.org/pipermail/centos-devel/2014-June/010444.html
>
>
> Let's just say this:
>
> We are ALWAYS going to officially call the releases:
>
> 'CentOS 8 (1911)' and 'CentOS 7 (1908)'
>
> We are going to do it regardless of who does like it or who does not
> like it (myself included).
>
> It is just the way it is and how it will be.  It has been this way since
> the original CentOS 7 release and it is not ever changing.

Never, until the next change of course :-)

Wasn't it like that because RHEL maintains multiple .X levels while CentOS
always only represents the current, newest level. So omitting the .X level
was intended to prevent such confusion we actually see.

Simon

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

Re: [CentOS] yum update / kernal update failed - remove or repair

[Simon Matter via CentOS]

> I have managed to find out what happened in the yum update and it turns
> out it was a mess.  It looks like the server ran out of memory in the
> middle and things then started to fail.  Any advice on how to recover from
> this would be greatly appreciated

I may sound old school but my suggestion would be to forget yum aka dnf
for now and just fix the real stuff using rpm.

I always considered yum a wrapper for rpm (I wish it was) and was able to
fix a system with rpm alone and later make yum behave again.

It usually boils down to analyzing what is in the rpm db and what is on
the filesystem actually. You can then remove invalid rpm db content as
well as wrong filesystem content. It's a bit of work and you may create
helper scripts as needed but you can fix almost everything that way.

Regards,
Simon

>
> The log below shows:
>
> [root@vps2 ~]# yum history info 22
> Loaded plugins: fastestmirror, langpacks
> Repository mariadb is listed more than once in the configuration
> Transaction ID : 22
> Begin time : Sun Jan 19 18:15:33 2020
> Begin rpmdb: 795:6c5cd82e3ada047c7071fea1524f41fd13fab6a1
> End time   :19:19:32 2020 (63 minutes)
> End rpmdb  : 801:6d1b278ccbeef6f68ff494cb28eaed5c7be4124b
> User   : root 
> Return-Code: Failure: 1
> Command Line   : update
> Transaction performed with:
> Installed rpm-4.11.3-40.el7.x86_64  @anaconda
> Installed yum-3.4.3-163.el7.centos.noarch   @anaconda
> Installed yum-plugin-fastestmirror-1.1.31-52.el7.noarch @anaconda
> Packages Altered:
> Updated MariaDB-client-10.4.10-1.el7.centos.x86_64@mariadb
> Update 10.4.11-1.el7.centos.x86_64@mariadb
> Updated MariaDB-common-10.4.10-1.el7.centos.x86_64@mariadb
> Update 10.4.11-1.el7.centos.x86_64@mariadb
> Updated MariaDB-compat-10.4.10-1.el7.centos.x86_64@mariadb
> Update 10.4.11-1.el7.centos.x86_64@mariadb
>  ** Updated MariaDB-server-10.4.10-1.el7.centos.x86_64@mariadb
> Loading mirror speeds from cached hostfile
>  * base: mirror.as29550.net
>  * epel: www.mirrorservice.org
>  * extras: www.mirrorservice.org
>  * remi-php73: mirrors.ukfast.co.uk
>  * remi-safe: mirrors.ukfast.co.uk
>  * updates: www.mirrorservice.org
>  ** Update 10.4.11-1.el7.centos.x86_64@?mariadb
>  ** Updated MariaDB-shared-10.4.10-1.el7.centos.x86_64@mariadb
> Update 10.4.11-1.el7.centos.x86_64@mariadb
>  ** Updated ca-certificates-2018.2.22-70.0.el7_5.noarch   @anaconda
>  ** Update  2019.2.32-76.el7_7.noarch @?updates
> Updated certbot-0.39.0-1.el7.noarch   @epel
> Update  1.0.0-1.el7.noarch@epel
> Updated clamav-0.101.4-1.el7.x86_64   @epel
> Update 0.101.5-1.el7.x86_64   @epel
> Updated clamav-data-0.101.4-1.el7.noarch  @epel
> Update  0.101.5-1.el7.noarch  @epel
> Updated clamav-devel-0.101.4-1.el7.x86_64 @epel
> Update   0.101.5-1.el7.x86_64 @epel
> Updated clamav-filesystem-0.101.4-1.el7.noarch@epel
> Update0.101.5-1.el7.noarch@epel
> Updated clamav-lib-0.101.4-1.el7.x86_64   @epel
> Update 0.101.5-1.el7.x86_64   @epel
> Updated clamav-update-0.101.4-1.el7.x86_64@epel
> Update0.101.5-1.el7.x86_64@epel
> Updated clamd-0.101.4-1.el7.x86_64@epel
> Update0.101.5-1.el7.x86_64@epel
> Updated curl-7.29.0-54.el7.x86_64 @anaconda
> Update   7.29.0-54.el7_7.1.x86_64 @updates
> Updated fail2ban-0.9.7-1.el7.noarch   @epel
> Update   0.10.4-1.el7.noarch  @epel
> Updated fail2ban-firewalld-0.9.7-1.el7.noarch @epel
> Update 0.10.4-1.el7.noarch@epel
> Updated fail2ban-sendmail-0.9.7-1.el7.noarch  @epel
> Update0.10.4-1.el7.noarch @epel
> Updated fail2ban-server-0.9.7-1.el7.noarch@epel
> Update  0.10.4-1.el7.noarch   @epel
> Updated fail2ban-systemd-0.9.7-1.el7.noarch   @epel
> Update   0.10.4-1.el7.noarch  @epel
> Updated fribidi-1.0.2-1.el7.x86_64@anaconda
> Update  1.0.2-1.el7_7.1.x86_64@updates
> Updated iproute-4.11.0-25.el7.x86_64  @anaconda
> Update  4.11.0-25.el7_7.2.x86_64  @updates
>   

Re: [CentOS] YUM (DNF) Possible Confusion Centos 8

[Simon Matter via CentOS]

> On 1/21/20 10:10 AM, david wrote:
>> At 08:52 AM 1/21/2020, David G. Miller wrote:
>>
>>
>>> On 1/21/20 9:35 AM, david wrote:
 Folks

 In a test Centos 8 installation as a guest of VirtualBox on Windows
 10, I want to install ffmpeg, and support for exfat. They're not in
 the standard distribution (as far as I know), so I issue as root:

   yum -y --enablerepo rpmfusion-free-updates install ffmpeg
 fuse-exfat exfat-utils

 and that works just fine.  The ffmpeg functionality works; I
 haven't tested exfat yet.  However, later, as part of maintenance,
 I want to get a list of everything that's installed, so I issue

   yum list installed

 and the following diagnostics occur:
 ---
 Modular dependency problems:

 Â Problem 1: conflicting requests
   - nothing provides module(perl:5.26) needed by module
 perl-App-cpanminus:1.7044:8010020191120175858:a9207fc6-0.x86_64
 Â Problem 2: conflicting requests
   - nothing provides module(perl:5.26) needed by module
 perl-DBD-MySQL:4.046:8010020191114030811:073fa5fe-0.x86_64
 Â Problem 3: conflicting requests
   - nothing provides module(perl:5.26) needed by module
 perl-DBD-SQLite:1.58:8010020191114033549:073fa5fe-0.x86_64
 Â Problem 4: conflicting requests
   - nothing provides module(perl:5.26) needed by module
 perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64
 Â Problem 5: conflicting requests
   - nothing provides module(perl:5.26) needed by module
 perl-YAML:1.24:8010020191114031501:a5949e2e-0.x86_64
 Installed Packages
 
 --

 By the way, cpanm works ok too.


 My questions are:
 What do these diagnostics tell me?  What am I supposed to do about
 it?

 Thanks for your help

 David


>>> I think its telling you that perl is NOT installed but the listed
>>> perl modules are installed although it could be looking for
>>> specifically the 5.26 version of perl (since you mentioned the CPAN
>>> works).  What happens if you issue perl -v?  perl gets installed as
>>> a dependency of logwatch as an example so a lot of people don't
>>> realize that they have perl installed whether they want it or not.
>>>
>>> Cheers,
>>> Dave
>>>
>>> --
>>> "They that can give up essential liberty to obtain a little temporary
>>> safety deserve neither safety nor liberty."
>>>
>>> -- Benjamin Franklin
>>
>>
>> Perl is explicitly installed,  "perl -v" identifies v5.26.3, and comes
>> from the standard Centos 8 repositories.  So, I suspect your
>> interpretation doesn't fit the facts.
>> David K
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
> Not seeing that here but it appears you are running newer versions of at
> least perl-DBD-MySQL, perl-DBD-SQLite and perl-DBI (snipped from "yum
> list installed" on my CentOS 8 VM after running "yum update"):
>
> perl-DBD-MySQL.x86_64 4.023-6.el7 @anaconda
> perl-DBD-SQLite.x86_64    1.39-3.el7 @anaconda
> perl-DBI.x86_64   1.627-4.el7 @anaconda
>
> What repo are you pulling the listed packages from?  Is it the same repo
> as for perl?  I'm getting:

Maybe it's worth to have a look a yum.log to see what happened to perl in
the history of the installation?

Simon

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

Re: [CentOS] After upgrade to CentOS 8.1 default gateway missing

[Simon Matter via CentOS]

> On Fri, 17 Jan 2020 14:39:19 +0100, Simon Matter via CentOS
>  wrote:
>
>> Anything in the logs about what was going on? If you reboot this server
>> again and again, does the problem show up again?
>
> This is shared hosting servers that is in production with customers live
> sites. So I don't want to reboot again if not absolutely needed. I guess I
> will find out if the problem continues the next time there is a new
> kernel. I would like to avoid doing reboots before a new kernel is
> released.
>
> I have not had time to go over the logs yet.
>
> I was hoping that somone else experienced the same, but it does not seems
> so. I can't believe I would be the only one in the world this would happen
> to, and also that it happened on both my CentOS 8 servers.

Such things happened to me in the past as well and I couldn't believe I'm
the only one. But, you have to consider certain things:

1) CentOS 8 is very new and I don't think it has already widely reached
the production world. I usually don't do this before .2 comes out and I
feel I'm not alone with this rule. At least it has served me well in the
last decade or two.

2) The number of production servers running two different IPv4 networks on
two adapters, as you do, may be quite small compared to the big number of
simple settings.

3) A lot of serious production servers are still using good old init
scripts to handle network settings and interfaces. Now that we're almost
forced to move to the more modern approach with NetworkManager and
systemd, new issues will slowly appear and get fixed step by step.

Regards,
Simon

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

Re: [CentOS] After upgrade to CentOS 8.1 default gateway missing

[Simon Matter via CentOS]

> On Thu, 16 Jan 2020 15:34:43 +0100, Stephen John Smoogen
>  wrote:
>
>> On Thu, 16 Jan 2020 at 07:58, Asle Ommundsen 
>> wrote:
>>>
>>> Hi,
>>>
>>> Tonight I upgraded two CentOS 8 boxes to CentOS 8.1 (1911). Then after
>>> a
>>> reboot of the first server the network was unavailable. In IPMI console
>>> everything except the network was looking good. Network was
>>> unreachable.
>>> No errors in NetworkManager. I also restarted NetworkManager, but it
>>> did
>>> not help. Then I discovered that the default gateway suddenly was
>>> missing.
>>>
>>> Then I rebooted the server one more time, but network was still down.
>>>
>>> Then both myself and a technician in my datcenter was debugging this (I
>>> had to wake him up in the middle of the night, costing me a lot of
>>> money),
>>> without finding any reason for why the default gateway was missing
>>> after
>>> reboot.
>>>
>>> Then we rebooted the server a third time, and all of a sudden the
>>> problem
>>> was gone and the default gateway was back. [...cut...]
>
>> In order to determine what is going on you need to give a lot more
>> information.
>>
>> 1. How do these boxes get their network information? DHCP or static
>> 2. If they are static, what controls the setting of ips:
>> NetworkManager or network-scripts
>> 3. If they are static, how are they set in
>> /etc/sysconfig/network-scripts/
>> 4. Do the files in /etc/sysconfig/network-scripts list a GATEWAY=
>> 5. If you are using network-manager, what does nmtui or the graphical
>> tool say the gateway or default route is?
>
> Here is answers to your list. I have anonymized the some of the data:
>
> 1) Static ip configuration
>
> 2) This should be NetworkManager.
> nmcli output:
>
> eno1: connected to eno1
>  inet4 1.1.1.234/29
>  route4 1.1.1.232/29
>  route4 0.0.0.0/0
>
> eno2: connected to eno2
>  inet4 192.168.0.5/24
>  route4 192.168.0.0/24
>
> [root@server ~]# nmcli d show | grep IP4.GATEWA
> IP4.GATEWAY: 1.1.1.1.233
>
> 3)
> TYPE=Ethernet
> PROXY_METHOD=none
> BROWSER_ONLY=no
> BOOTPROTO=none
> DEFROUTE=yes
> IPV4_FAILURE_FATAL=yes
> IPV6INIT=yes
> IPV6_AUTOCONF=yes
> IPV6_DEFROUTE=yes
> IPV6_FAILURE_FATAL=no
> IPV6_ADDR_GEN_MODE=stable-privacy
> NAME=eno1
> UUID=1f9ec889-3c64-470a-894b-05543ee44c29
> DEVICE=eno1
> ONBOOT=yes
> IPADDR=1.1.1..234
> PREFIX=29
> GATEWAY=1.1.1.233
> IPV6_PRIVACY=no

Anything in the logs about what was going on? If you reboot this server
again and again, does the problem show up again?

Regards,
Simon

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

Re: [CentOS] can't boot after volume rename

[Simon Matter via CentOS]

> I renamed my volume with vgrename however I didn't complete the other
> steps.
> Mainly update fstab and intiramfs. Once I booted, I was dropped on the
> Dracut shell. From here I can see the newly rename VG and I can lvm lvscan
> as well as activate it, lvm vgchange -ay.

IIRC this could all be done before rebooting. I know I did it in the past
but don't remember exactly and also don't remember the exact CentOS
versions used.

What I'd try is to rename the VG back to its original name and try to get
a bootable system again. Then I think you can make all the changes to
fstab and grub and rename again and reboot.

Regards,
Simon

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

Re: [CentOS] systemd-coredump service

[Simon Matter via CentOS]

> I am unable to locate systemd-coredump service on CentOS 7.5. It is not
> listed under "systemctl -a" and also I'm unable to locate the associated
> unit file (folder /usr/lib/systemd/system/ ). Am I missing any package
> which installs this service?

I don't really understand what you are looking for but don't you have
/usr/lib/systemd/systemd-coredump and /usr/bin/systemd-coredumpctl on your
system?

Regards,
Simon

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

Re: [CentOS] KVM Random Reboots AMD EPYC Server

[Simon Matter via CentOS]

> our new Server with AMD EPYC and super micro board reboots ramdonly.
> There is no error message before the reboot in /var/log/messages.

Anything in the hardware logs of the server like memory error or so? Any
watchdog on the servers acting bad?
We run CentOS 7 and KVM on AMD Opteron and AMD EPYC servers without issues.

Regards,
Simon

>
> we are running 2 Server with VMWare workstation without any problem.
>
> The new server should run KVM.
>
> older servers with AMD (before EPYC) running KVM without any problem.
>
> any idea or recommendation?
>
> --
> Viele Grüße
> Helmut Drodofsky
>
> Internet XS Service GmbH
> Heßbrühlstraße 15
> 70565 Stuttgart
>
> Geschäftsführung
> Helmut Drodofsky
> HRB 21091 Stuttgart
> USt.ID: DE190582774
> Fon: 0711 781941 0 
> Fax: 0711 781941 79
> Mail: i...@internet-xs.de
> www.internet-xs.de
> ___
> 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] centos8 :: firewalld active but tables empty

[Simon Matter via CentOS]

> Hi! I have a minimal installation of centos8 + packages for freeipa as a
> vbox vm. there is something strange with the firewall rules :

I'm not sure but does CentOS 8 still use iptables?

Regards,
Simon

>
> [root@ldap ~]# iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
>
> [root@ldap ~]# firewall-cmd --get-active-zones
> public
> interfaces: enp0s17
>
> [root@ldap ~]# firewall-cmd --state
> running
>
> [root@ldap ~]# firewall-cmd --zone=public --permanent --list-all
> public
> target: default
> icmp-block-inversion: no
> interfaces:
> sources:
> services: cockpit dhcpv6-client dns freeipa-ldap freeipa-ldaps http
> https ssh
> ports: 22/tcp 6/tcp
> protocols:
> masquerade: no
> forward-ports:
> source-ports:
> icmp-blocks:
> rich rules:
>
> Does anyone know what is the problem or how can i fix this?
> Thank you!
> Adrian
>
> ___
> 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] C8 and NetworkManager problem

[Simon Matter via CentOS]

> Hi list,
>
> I've installed C8 on my workstation. I configured my network devices
> (two bridges, two nics) using nmcli. Now that NM is the default I tried
> it. On C7 I always disabled it.
>
> I noticed some problem:
>
> 1) During the boot, also if NetworkManager-wait-online.service status is
> OK, I noticed that opening a terminal and ping some address it needs
> some time to perform ping and any operation on a network connection. So
> seems that in the first 30sec/1min there isn't an available network
> connection. After this time if I run a ping or whatever network is
> available.
>
> 2) Due to the problem 1, It cannot mount samba shares on boot saying
> "Not suitable address found". After the network is available I can mount
> samba shares.
>
> 3) I noticed that with NetworkManager a bridge must have an address. If
> I don't specify an address for the bridge, NM will try to assign some
> address, enable the connection  forever (reporting errors in messages
> and on notification bar).
>
> 4) NetworkManager-wait-online slow down  boot time and network
> availability.
>
> To solve this problem I installed network-scripts and disabled
> NetworkManager but I don't understand why NetworkManager need so much
> time to enable a connection.
>
> Can someone point me in the right direction?

I don't know C8 or smbmount but on C7 with nfs, I had to add this to the
fstab options to make it works as expected:

x-systemd.requires=network-online.target

Maybe something similar is needed in your situation.

Regards,
Simon

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

Re: [CentOS] frr packages for CentOS 8

[Simon Matter via CentOS]

> Hello,
>
> I'm not seeing free range routing (frr) packages for CentOS 8.
>
> The RHEL8 docs say frr is the replacement for quagga.
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/setting-your-routing-protocols_configuring-and-managing-networking
>
> What am i missing?

Wild guess, above description is for RH 8.1 and not for CentOS 8.0.

Simon

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

Re: [CentOS] Centos 8 Mate?

[Simon Matter via CentOS]

>
>
> On 2019-10-18 10:27, Jonathan Billings wrote:
>> On Fri, Oct 18, 2019 at 09:23:38AM -0500, Valeri Galtsev wrote:
>>> And last but not least: I got used to some way of interaction with
>>> computer,
>>> and that way is most productive for me after very long use. I don't
>>> want to
>>> blend in iPad generation, I want to stay productive which I am. So, I
>>> use
>>> Mutt (on FreeBSD, which my workstation runs, it is so easy and
>>> straightforward to install and maintain Mutt).
>
> I corrected myself, I meant above: Mate (desktop). The Desktop
> Environment that is behaving and interacting with me the old fashioned
> way I became productive using since forever.

But hey, why in the world you want it easy when you can have it
complicated, super modern and sucking your work time?

>
>>
>> Nothing stopping you from using mutt on a CentOS system, regardless of
>> what desktop environment you use, just as email clients such as
>> Evolution and kmail can run in other desktop environments.
>>
>> It's too bad that Mutt doesn't support GMail's authentication well
> And no, I don't use gmail anything, I know you are a wast majority who
> don't care, so, I'll not explain, and will stop right here.

As you, I'm trying to keep my life ungoogled as much as I can. Just to
explain it has always been a pain. I'll use your words above in future :-)

Regards,
Simon

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

Re: [CentOS] Odd issue with 7.7.1908 updated with qemu-kvm-ev

[Simon Matter via CentOS]

Hi,

> So, I have a client that has an internal use application that needs an
> ancient version of libc5.  That's not a typo; libc5.  Before the server
> that ran it died about a year and a half ago (said server was an AMD
> K6-2/450 with a 6GB Western Digital Caviar drive that had been spinning
> nearly continuously for almost 20 years!) it was running on Red Hat
> Linux 5.2.  The last version of CentOS that shipped with a libc5 was
> 2.1.  So I set them up a KVM guest running CentOS 2.1, mainly because
> Red Hat 5.2 wouldn't recognize the network at all, using the e1000
> network driver, and it ran well.
>
> Now, yes, there are no updates, but no it doesn't matter; it's an
> internal use application that has a very small footprint and very low
> risk.
>
> After the update on the host to 7.7.1908, the network stopped running. 
> The host also has a CentOS 7 guest that is still working properly.  If I
> change the 2.1 system to not automatically load the e1000 driver and
> console in and 'modprobe e1000' manually, it starts working again, for a
> while.

Just as a workaround, did you try to use another network card than the e1000?

Simon

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

Re: [CentOS] UEFI booting

[Simon Matter via CentOS]

> On Thu, 19 Sep 2019, Jerry Geis wrote:
>
>> I installed my first UEFI disk yesterday. Seemed to go fine. CentOS 7.6
>> x86_64
>> I then took that disk "out" of that machine and put it another machine -
>> it
>> seems to not even boot.
>> I put the original disk back in that machine and it boots fine.
>>
>> I put the UEFI disk back in the machine I built it on and it works fine.
>> They are similar machines either and i3 and i7.
>>
>> Shouldn't that work?  Build a UEFI disk on machine A - move it to
>> machine B?
>
> I think the issue is that the UEFI firmware doesn't know which UEFI boot
> loader to load.  I think this should help:
>
> https://noobient.com/2017/09/27/fixing-the-efi-bootloader-on-centos-7/
>
> Boot into rescue mode, and run:
>
> efibootmgr --create --label CentOS --disk /dev/sda1 --loader
> "\EFI\centos\shim.efi"
>
> I think you then should end up in a happy place.  You can probably add
> that entry by hand within the UEFI config itself.

Just wondering, will it still boot if he then puts the disk back to the
other machine?

Regards,
Simon

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

Re: [CentOS] another bizarre thing...

[Simon Matter via CentOS]

Wow, thanks for the detailed recipe!

How did we deserve this when it was so easy in the past :-)

> On Aug 5, 2019, at 6:57 PM, Fred Smith 
> wrote:
>>
>> no core file (yes, ulimit is configured)
>
> That’s nowhere near sufficient.  To restore classic core file dumps on
> CentOS 7, you must:
>
> 1. Remove Red Hat’s ABRT system, which wants to catch all of this and
> handle it directly.  Say something like “sudo yum remove abrt*”
>
>
> 2. Override the default sysctl telling where core dumps land by writing
> this file, /etc/sysctl.d/10-core.conf:
>
> kernel.core_pattern = /tmp/core-%e-%p
> kernel.core_uses_pid = 1
> fs.suid_dumpable = 2
>
> Then apply those settings with “sudo sysctl —system”.
>
> I don’t remember what the default is, which this overrides, but I
> definitely didn’t want it.
>
> You can choose any pattern you like, just remember what permissions the
> service runs under, because that’s the permission needed by the process
> that actually dumps the core to make the file hit the disk.  That’s why I
> chose /tmp in this example: anyone can write there.
>
>
> 3. Raise the limits by writing the following to
> /etc/security/limits.d/10-core.conf:
>
> * hard core unlimited
> * soft core unlimited
>
> If this is what you meant by “ulimit,” then great, but I suspect you
> actually meant “ulimit -c unlimited”, but I believe until you do the
> above, the ulimit CLI app can have no effect.  You have to log out and
> back in to make this take effect.
>
> Once the above is done, “ulimit -c unlimited” can take effect, but it’s of
> no value at all in conjunction with systemd services, for example, since
> those don’t run under a standard shell, so your .bash_profile and such
> aren’t even exec’d.
>
>
> 4. If your program is launched via systemd, then you must edit
> /etc/systemd/system.conf and set
>
> DefaultLimitCORE=infinity
>
> then say “sudo systemctl daemon-reeexec”
>
> Case matters; “Core” won’t work.  Ask me how I know. :)
>
>
> 5. If you have a systemd unit file for your service, you have to set a
> related value in there as well:
>
> LimitCore=infinity
>
> You need both because #4 sets the system-wide cap, while this sets the
> per-service value, which can go no higher than the system cap.
>
>
> 6. Restart the service to apply the above two changes.
>
>
> Yes, it really is that difficult to enable classic core dumps on CentOS 7.
>  You’re welcome. :)
> ___
> 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] [OT] odd network question

[Simon Matter via CentOS]

> On Fri, Aug 02, 2019 at 02:43:30PM -0400, Fred Smith wrote:
>> On Fri, Aug 02, 2019 at 02:38:05PM -0400, Jon LaBadie wrote:
>> > On Fri, Aug 02, 2019 at 10:19:49AM -0400, mark wrote:
>> > > Fred Smith wrote:
>> > > > On Fri, Aug 02, 2019 at 09:28:23AM -0400, mark wrote:
>> > > 
>> > > > One thing I don't understand is how/why the firewall is DROPping
>> so
>> > > > many attempts on port 25 when it in fact has a port forward rule
>> sending
>> > > > port 25 on to my mailserver. How does it know, or why does it
>> think that
>> > > > some of them can be dropped at the outer barrier?
>> > > >
>> > > >> you, but thank you for taking a hundred thousand or so for all of
>> us.
>> > > >
>> > > > Hey, its the least I can do for all the good guys out there! :)
>> > > > But that doesn't mean the same dratsabs aren't hitting all the
>> rest
>> > > > of you too.
>> > > >
>> > > I'm sure they are. Are you running fail2ban?
>> > >
>> > Several years back I switched from sendmail to postfix.
>> > Not knowing what I was doing, I think I have it set to
>> > say it will forward email following SASL authentication.
>> > But as I had no intention of forwarding anything, I did
>> > not set up any authentication methods.  So anyone who
>> > tries fails to authenticate.
>> >
>> > With fail2ban in place I get 200-500 daily SASL "fail to
>> > authenticate" instances.  In contrast, several months ago
>> > fail2ban either died or did not restart correctly.  This
>> > went unnoticed for about a week.  During that time I got
>> > 1-32000 daily "failed to authenticate".
>>
>> I'm not using fail2ban, and am using sendmail (why? because
>> I've spent years slowly accumulating options in my .mc file that
>> kill off unwanted connections and other hate-the-spammer options.).
>> I'm not getting such emails but most of the entries in /var/log/mail
>> are due to such events. every now and then a legitimate email can
>> be seen passing through.
>>
>> Oh, I also am now using (as of 2-3 years ago) milter-greylist, which
>> made an enormous contribution to preventing spam emails.
>>
>> Fred
>
> I tried greylisting a while back and was surprised how many were
> being rejected.  But they were also getting through despite the
> rejection at my end.
>
> I use a 3rd party as my backup MX email address.  If I'm down,
> they save up the email and forward it to me when I'm back up.
> But the greylist rejected emails just tried the backup MX
> address and got through that way.
>
> Should I ever have a backup MX that I administer, I will
> definitely reinstate greylisting.

If you have a stable environment and connections, you could also get rid
of the backup MX completely. That's what we did and we're not alone. Of
course if you have frequent service interruptions for whatever reason,
that's not an option.

Regards,
Simon

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

Re: [CentOS] Performance issues/difference of two servers running same task (one is quicker)

[Simon Matter via CentOS]

> Hi
>
> I need some advice what to do next, even if someone tells me to
> check out (an)other mailing list(s), tuning site or point me in a better
> direction how to solve my annoying problem: one server is much faster
> for certain tasks although on "shitty" hardware.
>
> I have tried many things to solve my issue
>  - changed buffer/pool/cache/etc mysqld
>  - changed server settings apache/php
>  - changed various OS settings (sysctl) e.g. turned off IPV6
> but havent figured it out.
>
> I have a development server (local) and life servers (data center)
> Used mainly for many different websites and one online training site.
>
> the development and life server in question run the same software setup:
>   - CentOS Linux release 7.6.1810
>   - bind 32:9.9.4-74.el7_6.1
>   - Apache/2.4.6 (CentOS)
>   - PHP 7.1.29
>   - mysqld  Ver 5.7.26
>   - wordpress, woocommerce, wishlistmember, Sensei etc
>   - software are all in the same stages of updates.
>   - even many of the linux conf files are the same (/etc/host, bind, etc)
>   - the databases are copies/identical
>
> Life server is a Poweredge M710,48GB,2xXeon L5630,LSI Raid1 SSD
> Dev  server is a DIY, GIGABYTE MX31-BS0, 32GB, 1xXeon E3-1245,MDADM RAID0
> 1TB Seagate Spinners
>
> Clearly the development server is hardware wise way below the specs of the
> Dell but
> software wise they are identical (they get upgraded at the same time).
>
> During normal operations (i.e. display websites, online training courses
> etc) the DELL
> displays the websites faster although it sits 1000KM up north in a
> datacenter on
> a different network than the local server on the same network as my
> machine.
>
> Yet the DEV server outshines the DELL when creating a few large custom
> tables, ie
> the local server takes 5s while the DELL takes 15s (small tables), more
> for bigger tables.
>
> The task is based on:
>  - level, member, course, group are all ID's
>  - members can belong to a group, a level and can access many courses
>  - the ID restricts what they can access and what they belong to.
>  - a course for each member can have various stages of completion
>  - using an API (wishlist member) that performs LOCAL calls when accessed
> locally
>I can get who belongs to what and make up my info I need, then use PHP
>to make up the table.
>  - DB calls ARE LOCAL!
>
> Now when I try to create a table of members belonging to the same group
> level
> doing the same course with different stages of completion the DELL takes
> on average
> 3 times longer to complete the table (normally about 20 to 30 rows).
>
> I have put microtime() calls before and after certain calls, and it's
> visibly different:
>   DEV
> Jul 04 04:57:26 UTC _members took 0.0005459785461425 ms
> Jul 04 04:57:26 UTC _members took 0.0005321502685546 ms
>   LIFE
> Jul 04 05:00:36 UTC _members took 0.0014369487762451 ms
> Jul 04 05:00:36 UTC _members took 0.0013291835784912 ms
> If I do this 300+ times, the outcome is very different.
>
>
> So my questions:
>
>  - How can it be that the DELL takes so much longer alltough on the far
> better hardware?
>  - How can it be allthough everything (software/os/plugins) is the same?
>  - This even happens if the DELL is on low load (i.e. middle of the night)
> and
>only serves a few requests.
>
> Same software, same config, same database, same amount of data in the
> database
> yet on better hardware it's slower?

Two ideas:

a) the DELL maybe faster over all but if I'm right single core speed is
slower than on DEV machine.

b) how do the LSI/SSD perform compared to the MDADM/RAID0 on the DEV
server? I'm not sure the DELL is a clear winner here.

Regards,
Simon

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

Re: [CentOS] raid 5 install

[Simon Matter via CentOS]

>
>
> On 2019-07-01 10:01, Warren Young wrote:
>> On Jul 1, 2019, at 8:26 AM, Valeri Galtsev 
>> wrote:
>>>
>>> RAID function, which boils down to simple, short, easy to debug well
>>> program.
>
> I didn't intend to start software vs hardware RAID flame war when I
> joined somebody's else opinion.
>
> Now, commenting with all due respect to famous person who Warren Young
> definitely is.
>
>>
>> RAID firmware will be harder to debug than Linux software RAID, if only
>> because of easier-to-use tools.
>
> I myself debug neither firmware (or "microcode", speaking the language
> as it was some 30 years ago), not Linux kernel. In both cases it is
> someone else who does the debugging.
>
> You are speaking as the person who routinely debugs Linux components. I
> still have to stress, that in debugging RAID card firmware one has small
> program which this firmware is.
>
> In the case of debugging EVERYTHING that affects reliability of software
> RAID, on has to debug the following:
>
> 1. Linux kernel itself, which is huge;
>
> 2. _all_ the drivers that are loaded when system runs. Some of the
> drivers on one's system may be binary only, like NVIDIA video card
> drives. So, even for those who like Warren can debug all code, these
> still are not accessible.
>
> All of the above can potentially panic kernel (as they all run in kernel
> context), so they all affect reliability of software RAID, not only the
> chunk of software doing software RAID function.
>
>>
>> Furthermore, MD RAID only had to be debugged once, rather that once per
>> company-and-product line as with hardware RAID.
>
> Alas, MD RAID itself not the only thing that affects reliability of
> software RAID. Panicking kernel has grave effects on software RAID, so
> anything that can panic kernel had also to be debugged same thoroughly.
> And it always have to be redone once changed to kernel or drivers are
> introduced.
>
>>
>> I hope you’re not assuming that hardware RAID has no bugs.  It’s
>> basically a dedicated CPU running dedicated software that’s difficult to
>> upgrade.
>
> That's true, it is dedicated CPU running dedicated program, and it keeps
> doing it even if the operating system crashed. Yes, hardware itself can
> be unreliable. But in case of RAID card it is only the card itself.
> Failure rate of which in my racks is much smaller that overall failure
> rate of everything. In case of kernel panic, any piece of hardware
> inside computer in some mode of failure can cause it.
>
> One more thing: apart from hardware RAID "firmware" program being small
> and logically simple, there is one more factor: it usually runs on RISC
> architecture CPU, and introduce bugs programming for RISC architecture
> IMHO is more difficult that when programming for i386 and amd64
> architectures. Just my humble opinion I carry since the time I was
> programming.
>
>>
>>> if kernel (big and buggy code) is panicked, current RAID operation will
>>> never be finished which leaves the mess.
>>
>> When was the last time you had a kernel panic?  And of those times, when
>> was the last time it happened because of something other than a hardware
>> or driver fault?  If it wasn’t for all this hardware doing strange
>> things, the kernel would be a lot more stable. :)
>
> Yes, I half expected that. When did we last have kernel crash, and who
> of us is unable to choose reliable hardware, and unable to insist that
> our institution pays mere 5-10% higher price for reliable box than they
> would for junk hardware? Indeed, we all run reliable boxes, and I am
> retiring still reliably working machines of age 10-13 years...
>
> However, I would rather suggest to compare not absolute probabilities,
> which, exactly as you said, are infinitesimal. But with relative
> probabilities, I still will go with hardware RAID.
>
>>
>> You seem to be saying that hardware RAID can’t lose data.  You’re
>> ignoring the RAID 5 write hole:
>>
>>  https://en.wikipedia.org/wiki/RAID#WRITE-HOLE
>
> Neither of our RAID cards runs without battery backup.
>
>>
>> If you then bring up battery backups, now you’re adding cost to the
>> system.  And then some ~3-5 years later, downtime to swap the battery,
>> and more downtime.  And all of that just to work around the RAID write
>> hole.
>
> You are absolutely right about system with hardware RAID being more
> expensive than that with software RAID. I would say, for "small scale
> big storage" boxes (i.e. NOT distributed file systems), hardware RAID
> adds about 5-7% of cost in our case. Now, with hardware RAID all
> maintenance (what one needs to do in case of single failed drive
> replacement routine) takes about 1/10 of a time necessary do deal with
> similar failure in case of software RAID. I deal with both, as it
> historically happened, so this is my own observation. Maybe software
> RAID boxes I have to deal with are too messy (imagine almost two dozens
> of software RAIDs 12-16 drives each on one machine; even bios runs out
> of 

Re: [CentOS] raid 5 install

[Simon Matter via CentOS]

>> You seem to be saying that hardware RAID can’t lose data.  You’re
>> ignoring the RAID 5 write hole:
>>
>>  https://en.wikipedia.org/wiki/RAID#WRITE-HOLE
>>
>> If you then bring up battery backups, now you’re adding cost to the
>> system.  And then some ~3-5 years later, downtime to swap the battery,
>> and more downtime.  And all of that just to work around the RAID write
>> hole.
>
> Yes. Furthermore, with the huge capacity disks in use today, rebuilding
> a RAID 5 array after a disk fails, with all the necessary parity
> calculations, can take days.
> RAID 5 is obsolete, and I'm not the only one saying it.

Needless to say hardware and software RAID have the problem above.

Simon

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

Re: [CentOS] raid 5 install

[Simon Matter via CentOS]

> On Mon, 1 Jul 2019, Warren Young wrote:
>
>> If you then bring up battery backups, now you’re adding cost to the
>> system.  And then some ~3-5 years later, downtime to swap the battery,
>> and more downtime.  And all of that just to work around the RAID write
>> hole.
>
> Although batteries have disappeared in favour of NV storage + capacitors,
> meaning you don't have to replace anything on those models.

That's what you think before you have to replace the capacitors module :-)

Simon

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

Re: [CentOS] raid 5 install

[Simon Matter via CentOS]

>>
>>
>>
> IMHO, Hardware raid primarily exists because of Microsoft Windows and
> VMware esxi, neither of which have good native storage management.
>
> Because of this, it's fairly hard to order a major brand (HP, Dell, etc)
> server without raid cards.
>
> Raid cards do have the performance boost of nonvolatile write back cache.
>  Newer/better cards use supercap flash for this, so battery life is no

The supercaps may be more stable than batteries but they can also fail.
Since I had to replace the supercap of a HP server I know they also do
fail. That's why they are also built as a module connected to the
controller :-)

As for the write back cache, good SSDs do the same with integrated cache
and supercaps, so you really don't need the RAID controller to do it
anymore.

> longer an issue
>
> That said, make my Unix boxes zfs or mdraid+xfs on jbod for all the
> reasons
> previously given.

Same here, after long years of all kind of RAID hardware, I'm happy to run
everything on mdraid+xfs. Software RAID on directly attached U.2 NMVe
disks is all we use for new servers. It's fast, stable and also important,
still KISS.

Regards,
Simon

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

Re: [CentOS] mirror.centos.org ships non-updated version of bind ?

[Simon Matter via CentOS]

> Okay, some minutes before I post this question - the update was pushed to
> mirror.centos.org and an announcement was published:
> https://lists.centos.org/pipermail/centos-announce/2019-June/023321.html
>
> But the actually question still remains:
> Which steps are between 'RedHat published an update' and
> 'mirror.centos.org'?
>
> At Fedora there's 'Bodhi' where Users can review/test new updates - and
> give positive karma for working updates. Is there something similar for
> Centos or are updates checked by selected audience?

In contrast to Fedora the updates for CentOS mean mostly rebuild from the
upstream sources. So testing is probably only needed for the correct build
but not for included updates. They were already tested by upstream.

Regards,
Simon

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

Re: [CentOS] system unresponsive

[Simon Matter via CentOS]

> Ok, we used to get this occasionally on cluster nodes, and we just got it
> on a fileserver (very bad). The system is discovered to be unresponsive:
> it doesn't ping, and plugging a console in, you can see that it's not
> dead, but there nothing at all on the screen, nor does it respond to even
> . The only answer is to power cycle it; it comes up fine.
>
> Nothing in /var/log/dmesg or /var/log/messages. No abrts I can find. sar
> tells me it went unredponsive between 18:10 and 10:20 yesterday. Note that
> there are no further entries in sar, either, for yesterday, after the
> event, and nothing till I power cycled it.
>
> Has anyone else seen this - I can't imagine it's only us - or have any
> thoughts?
>
> C 7, 7.6.1810

I saw such an issue recently and never found out what happened and why.

Regards,
Simon



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

Re: [CentOS] Bypassing 'A stop job is running' when rebooting CentOS 7

[Simon Matter via CentOS]

> James Pearson wrote:
>> James Pearson wrote:
>>
>>>
>>> I'm currently trying to reboot a CentOS 7.5 workstation (to complete an
>>>  upgrade to 7.6), but it is 'stuck' while shutting down with 'A stop
>>> job is running for ...' - the counter initially gave a limit of '1min
>>> 30s' -
>>> but each time it reaches that limit, it just adds on ~90 seconds to the
>>> limit ...
>>>
>>> Currently the limit is '25min 33s'
>>>
>>>
>>> I'm in no hurry to have this workstation operational, but I guess at
>>> some point I will have to power cycle it ...
>>>
>>> Does anyone know how to bypass this? - or at least stop it increasing
>>> the limit each time it is reached?
>>>
>>> It does seems rather pointless to keep increasing the limit like this
>>> ...
>>>
>> It _finally_ gave up at 30 mins and rebooted
>
> One question: did it have a mounted nfs filesystem?
>
> The joys of systemd

Yes, NFS integration with systemd is broken by default, at least it was
still the case when I last checked.
If you want it to work correctly, you have to add
'x-systemd.requires=network-online.target' as NFS mount option.

Clearly, how should systemd know that NFS won't work without network? I
knew you agree :-)

Regards,
Simon

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

Re: [CentOS] where to find wifi driver

[Simon Matter via CentOS]

> On Tue, May 14, 2019 at 10:13:35AM +0800, qw wrote:
>> I use the wifi adaptor, Edimax AC1200, and its driver can be
>> downloaded from
>>
>> 'http://www.edimax.com.tw/edimax/download/download/data/edimax/tw/download/for_home/wireless_adapters/wireless_adapters_ac1200_dual-band/ew-7822ulc'.

Looking at the source code, it seems to provide some version of realtek
driver.

Since you run CentOS 7.4 it may be a good time to upgrade to current 7.6
release and see if it already supports your device.

Simon

>>
>>
>> I fail to compile its GPL Source Code on CentOS 7.4.
>>
>>
>> Where to get its rpm drivers, or how to compile its GPL Source Code?
>
> Looks like you've found the only official source code.
>
> It looks like someone else has (unofficial) code here:
>
> https://github.com/abperiasamy/rtl8812AU_8821AU_linux
>
> It isn't a driver supported by the CentOS kernel, nor any 3rd-party
> repositories that I know of.  You'll either have to get it to work
> yourself or use a newer kernel (which isn't something supported on
> CentOS, but provided by 3rd party repos such as elrepo.org.)
>
> --
> Jonathan Billings 
> ___
> 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] Firefox esr repackage

[Simon Matter via CentOS]

> On 11/05/19 2:05 AM, Simon Matter via CentOS wrote:
>>> Am 10.05.2019 um 11:12 schrieb Nux! :
>>>> I maintain a desktop oriented repo for CentOS and last I checked a
>>>> year
>>>> or so ago, I got over 150k+ unique IPs with yum user agent downloading
>>>> stuff from it.
>>>>
>>>> It's a bit anecdotal as perhaps not all are actual desktop users and
>>>> some users were using multiple IPs (dhcp), but it shows there are
>>>> quite
>>>> a few users out there running CentOS for desktop purposes.
>>>>
>>>> There are desktop focused distros out there who do not even reach this
>>>> kind of numbers. How many active users do you think Mageia or Linux
>>>> Mint
>>>> have?
>>>
>>> We are moving our workstations from OSX to EL8 right now. We think its
>>> time to
>>> couple our activities more tight to the new technologies that come with
>>> EL8 ...
>>> otherwise the user keeps brain-splitted :-)
>> Don't get me wrong. At work we are running 99% of all desktop activity
>> on
>> RHEL/CentOS for much more than a decade.
>>
>> That's why I'm wondering why such a Firefox breakage has such a low
>> priority for upstream. Our users are used to Firefox with several
>> add-ons
>> like uBlock and others. Suddenly having to run it without them is quite
>> a
>> mess and asks for an immediate fix.
>
> I have used CentOS 6 and 7 as workstation core along with EPEL, elrepo
> and nux ever since v6 was released. It has just got better and better.
> Then we have the likes of gnome and firefox, seeming to think of others
> rather than the hard core users that have consistently worked to
> streamline work flows in the real paying world. They are making huge
> changes, motivated by  and in the process sacrificing work flow and
> efficiency as they pursue other goals.

That's why we're using XFCE for more than a decade. That may sound a bit
boring but it helps to stay focused on the real work.

Regards,
Simon

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

Re: [CentOS] Firefox esr repackage

[Simon Matter via CentOS]

> Am 10.05.2019 um 11:12 schrieb Nux! :
>>
>> I maintain a desktop oriented repo for CentOS and last I checked a year
>> or so ago, I got over 150k+ unique IPs with yum user agent downloading
>> stuff from it.
>>
>> It's a bit anecdotal as perhaps not all are actual desktop users and
>> some users were using multiple IPs (dhcp), but it shows there are quite
>> a few users out there running CentOS for desktop purposes.
>>
>> There are desktop focused distros out there who do not even reach this
>> kind of numbers. How many active users do you think Mageia or Linux Mint
>> have?
>
>
> We are moving our workstations from OSX to EL8 right now. We think its
> time to
> couple our activities more tight to the new technologies that come with
> EL8 ...
> otherwise the user keeps brain-splitted :-)

Don't get me wrong. At work we are running 99% of all desktop activity on
RHEL/CentOS for much more than a decade.

That's why I'm wondering why such a Firefox breakage has such a low
priority for upstream. Our users are used to Firefox with several add-ons
like uBlock and others. Suddenly having to run it without them is quite a
mess and asks for an immediate fix.

That's what I'm wondering about.

Regards,
Simon

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

Re: [CentOS] Firefox esr repackage

[Simon Matter via CentOS]

> On 09/05/2019 09:09, Simon Matter via CentOS wrote:
>>> The price we pay.. :)
>>
>> Do you say that paying RH customers already received new firefox
>> packages?
>>
>> Regards,
>> Simon
>>
>
> No, Red Hat have not yet released any updates for Firefox. I doubt it's
> a priority for them.

Which makes me believe they don't expect anybody to use RHEL as a desktop
system :-(

Are there any numbers showing how RHEL is used? That would be interesting.

Regards,
Simon

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