Re: [CentOS] Missing python-reportlab-2.5-11.el7_9 RHSA-2023:5616

2024-02-13 Thread Chris Schanzle via CentOS

On 1/18/24 11:11, Chris Schanzle via CentOS wrote:

I am having troubles finding the -11 update to python-reportlab.  I just got 
dinged for:

Remote package installed : python-reportlab-2.5-10.el7
Should be    : python-reportlab-2.5-11.el7_9

I don't see it in the list of updates, my local mirror, or at:

http://mirror.centos.org/centos/7/updates/x86_64/Packages/

Thanks,

Chris


[Adding centos-devel]

Still getting dinged for this issue from errata issued by RHSA-2023:5616 
<https://access.redhat.com/errata/RHSA-2023:5616> but no package is available 
for CentOS.

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


[CentOS] Missing python-reportlab-2.5-11.el7_9

2024-01-18 Thread Chris Schanzle via CentOS

I am having troubles finding the -11 update to python-reportlab.  I just got 
dinged for:

Remote package installed : python-reportlab-2.5-10.el7
Should be    : python-reportlab-2.5-11.el7_9

I don't see it in the list of updates, my local mirror, or at:

http://mirror.centos.org/centos/7/updates/x86_64/Packages/

Thanks,

Chris

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


Re: [CentOS] C7, removing zoom problem

2023-02-05 Thread Chris Schanzle via CentOS

On 2/5/23 5:19 PM, Simon Matter wrote:

Hi


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

This should tell you the real name of the package

rpm -qa zoom\*

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

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

Regards,
Simon



Looking at 
https://support.zoom.us/hc/en-us/articles/204206269-Installing-or-updating-Zoom-on-Linux#h_c3eadf5f-1311-4d38-972e-dd8868353ccb

You should use:   sudo yum remove zoom

Commercial companies are notorious for renaming their RPM's to different filenames than 
what the package variables set.  The filename has no bearing on the package name when 
installed.  In this case, the download is called "zoom_x86_64.rpm" but it's 
real rpm filename with the typical name-version-release.arch may be queried from the 
download file itself:

rpm -q --qf='%{name}-%{version}-%{release}.%{arch}\n' -p ./zoom_x86_64.rpm
zoom-5.13.5.431-1.x86_64

As you can see, the real package name is "zoom".

"sudo rpm -ev zoom" would also be a fine option.


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


[CentOS] CentOS 7: Missing Thunderbird Updates

2022-11-21 Thread Chris Schanzle via CentOS

Hi,

Looks like CentOS 7 hasn't shipped Thunderbird updates for a while.  The latest 
I see in repos is:

Sep  1 15:22 thunderbird-91.13.0-1.el7.centos.x86_64.rpm

Perusing through the RHEL announcements, that was from the RHSA-2022:6169-01 on 
2022-08-24.  Seems none of the 102.x versions have shipped:

2022-09-26 RHSA-2022:6710-01 thunderbird-102.3.0-3.el7_9.x86_64.rpm

2022-10-18 RHSA-2022:6998-01 thunderbird-102.3.0-4.el7_9.x86_64.rpm

2022-10-25 RHSA-2022:7184-01 thunderbird-102.4.0-1.el7_9.x86_64.rpm


And for completeness, just announced today:

2022-11-21 RHSA-2022:8555-01 thunderbird-102.5.0-2.el7_9.x86_64.rpm


Thanks in advance for efforts to find and clear the blockage!

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


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

2022-11-16 Thread Chris Schanzle via CentOS

On 11/15/22 7:50 PM, Petko Alov wrote:


On 2022-11-08 15:49, Orion Poplawski wrote:

    On 11/8/22 13:12, Simon Matter wrote:

    Is anyone else experiencing trouble with
    kernel-3.10.0-1160.80.1.el7.x86_64?

    I'm seeing a kernel panics in the kvm module on one of our VM hosts 
with

    it.

    I did notice a new libvirt update as well, but it seems to work 
fine with

    the
    older kernel (.76.1).

    Where did you get the .80.1 kernel from? I'm a bit confused because I 
can

    only see .76.1 on my systems.

    Simon

    I'm actually running Scientific Linux, which seems to be a little ahead 
here.
Probably not related, but vmlinuz-4.18.0-372.32.1.el8_6.x86_64 (AlmaLinux 8.6) had a kernel panic on a Intel Xeon E5504 processor, but works fine on Xeon E56XX processors (5620 specifically in our tests). * Believe from kernel version, the original email is for Centos 7, possible the same change that went into the EL8 kernel went also to EL7 Triggered right after I used virsh start to start the vm. (Caused Black Screen, and reboot. Found this in the crashed kernel logs on /var/crash) Works fine on vmlinuz-4.18.0-372.26.1.el8_6.x86_64 and vmlinuz-4.18.0-372.16.1.el8_6.x86_64 


In fact, related - on our systems attempt to start qemu-kvm VM under 
kernel-3.10.0-1160.80.1.el7.x86_64 freezes any of 5 workstations with  dual 
E5507 (all worked OK under kernel-3.10.0-1160.76.1.el7.x86_64 and any previous 
version). The workstations with E5-2609, E5-2650 or E5-2630 are not affected - 
all of them run qemu-kvm VM under kernel-3.10.0-1160.80.1.el7.x86_64 without 
problems.



Thankfully, no problems with 2x Xeon E5-2667 v2 and CentOS 7.9 kernel 
3.10.0-1160.80.1.el7.x86_64.

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


Re: [CentOS] Microsoft deprecation of basic authentication centos 7

2022-10-14 Thread Chris Schanzle via CentOS

On 10/14/22 12:31 PM, Jerry Geis wrote:

Hi All

I have a server out there running centos 7.
I installed fetchmail to monitor an email inbox - has worked for years.
Microsoft deprecated basic authentication so fetchmail is not working any
more.

Anyone else run into this ?
fetchmail 6 does not support oauth.

Any thoughts on how to update - get this working again ?
its nearly impossible  to change the OS - as the box is not local to me.



Microsoft is accepting short-term enforcement delays (until Dec 31 if I recall) 
if your company will submit the request.

Consider looking at a generic proxy like 
https://github.com/simonrob/email-oauth2-proxy

I tried it on EL8, but had troubles getting the GUI to appear in the systray 
unless until in my python virtenv I added:

  pip install PyGObject # also installs pycairo

Worked for me with Thunderbird -- we can't use built-in OAUTH2 due to 
https://bugzilla.mozilla.org/show_bug.cgi?id=1685414

Good luck!

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


[CentOS] OT: DMARC for centos.org

2022-02-01 Thread Chris Schanzle via CentOS

We use Office365 for hosting mail.  You may stop reading now, no offense taken. 
 :-)

Recently and intermittently, emails from the centos and centos-devel mailing lists are being put in 
my "Junk E-Mail" folder by Microsoft (not by any client filtering).  My insightful email 
admin has been working with Microsoft to nail down the cause and it is (partly?) due to centos.org 
not having a DMARC DNS record.  I verified this is true with a missing "ANSWER SECTION" 
if DNS is queried:  dig _dmarc.centos.org txt

When I pressed for more details about the intermittent filtering, he replied:  
"Maybe passing SPF or DKIM for some sending domains helps get some of them through? 
I can’t be totally sure in this evolving Microsoft dynamic situation. But I’m still not 
through with them. Still asking questions trying to draw out answers..."

Microsoft suggested:

    You can ask an admin in the sending domain to configure their email 
authentication records: 
https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/email-validation-and-authentication?view=o365-worldwide#ask-the-sender-to-configure-email-authentication-for-domains-you-dont-own

My apologies if this is bringing up issues already beaten to death.  But if it 
could be addressed without too much hassle...it might help others as well.  
Thanks!

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


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

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

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

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

> As an aside, why can't we we have nice things in life like 'dnf downgrade 
> systemd\*' actually work?  I did the below - might be dumb, but it 
worked -- alternate suggestions to downgrade are appreciated - searching the 
list and my google-fu was off the mark today.
>
>   cd [path-to-repo]/centos/8/BaseOS/x86_64/os/Packages
>   dnf downgrade $(rpm -qa systemd\* | grep 239-41.el8_3.2 | sed -e 
's/3\.2/3.1/' -e 's/^/.\//' -e 's/$/.rpm/')
>
> Chris


[adjusted the subject, hope that is OK.]

Found it!  It's the dbus update to 1.12.8-12.  Downgrade to -11 
and ssh connections close normally.

To clarify the problem, with the new dbus, simple ssh's like:

ssh somehost uptime

will print the uptime, but do not return to the local shell prompt until you 
hit ctrl-c.  It works normally if you downgrade dbus or

ssh -o forwardx11=no somehost uptime

I'm sure a bug report exists somewhere, but that's something to dig for or 
create tomorrow.

To downgrade, packages were scattered in different locations, so I copied 
them to one directory and did

dnf downgrade ./*

The packages I needed to downgrade on a  x86_64 system were:

dbus-1.12.8-11.el8.x86_64.rpm
dbus-common-1.12.8-11.el8.noarch.rpm
dbus-daemon-1.12.8-11.el8.x86_64.rpm
dbus-devel-1.12.8-11.el8.x86_64.rpm
dbus-libs-1.12.8-11.el8.x86_64.rpm
dbus-tools-1.12.8-11.el8.x86_64.rpm
dbus-x11-1.12.8-11.el8.x86_64.rpm



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


Re: [CentOS] rsync over ssh stalls after completing the job

2021-04-13 Thread Chris Schanzle via CentOS
On 4/13/21 5:00 PM, Frank Cox wrote:
> On Tue, 13 Apr 2021 22:29:26 +0200
> Simon Matter wrote:
>
>> You could try running strace on the hanging process so see what it's doing.
> [frankcox@mutt temp]$ rsync -avv ../temp/ jeff:temp
> opening connection using: ssh jeff rsync --server -vvlogDtpre.iLsfxC . temp  
> (7 args)
> sending incremental file list
> delta-transmission enabled
> abc is uptodate
> total: matches=0  hash_hits=0  false_alarms=0 data=0
>
> Leaving that sit there apparently doing nothing (but still not giving me my 
> cursor back) I switched to another terminal window and did the following:
>
> [frankcox@mutt ~]$ ps -FA | grep rsync
> frankcox54002435  0 60586  3160   5 14:52 pts/000:00:00 rsync 
> -avv ../temp/ jeff:temp
> frankcox54015400  0 67980  7440   1 14:52 pts/000:00:00 ssh 
jeff rsync --server -vvlogDtpre.iLsfxC . temp
> frankcox55265416  0 55476  1076   3 14:53 pts/100:00:00 grep 
> --color=auto rsync
>
> [frankcox@mutt ~]$ strace -p 5401
> strace: Process 5401 attached
> select(11, [5 9 10], [], NULL, NULL
>
> Then it just sits there with no further action.  I get my cursor back when I 
> hit ctrl-c.
>
> [frankcox@mutt ~]$ strace -p 5400
> strace: Process 5400 attached
> restart_syscall(<... resuming interrupted nanosleep ...>) = 0
> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
> nanosleep({tv_sec=0, tv_nsec=2000}, NULL) = 0
> wait4(5401, 0x7ffd45105564, WNOHANG, NULL) = 0
>
> The wait4-etc line just keeps repeating endlessly until I hit ctrl-c.
>
> Unfortunately, I have no idea what any of the above actually means.  Does it 
> tell us anything interesting?


Yay!  I am glad someone else on the planet is experiencing this.  
I noticed this started happening to me after updating some CentOS Linux 8 
systems today.

I discovered if I set ForwardX11=no (either on ssh command line or in 
~/.ssh/config) the hang does not happen.  But why does that matter?  No updates 
to openssh.

It is not the systemd update doing something silly with session management.  I 
painfully downgraded manually and rebooted to no effect.  
As an aside, why can't we we have nice things in life like 'dnf downgrade 
systemd\*' actually work?  I did the below - might be dumb, but it worked -- 
alternate suggestions to downgrade are appreciated - searching the list and my 
google-fu was off the mark today.

  cd [path-to-repo]/centos/8/BaseOS/x86_64/os/Packages
  dnf downgrade $(rpm -qa systemd\* | grep 239-41.el8_3.2 | sed -e 
's/3\.2/3.1/' -e 's/^/.\//' -e 's/$/.rpm/')

Chris


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


Re: [CentOS] Date question

2021-02-17 Thread Chris Schanzle via CentOS
On 2/17/21 1:57 PM, Jerry Geis wrote:
> SO from the man page on date I can do
>
> current=`TZ=":America/Indianapolis" date`
> echo $current
> current=`TZ=":America/Los_Angeles" date `
> echo $current
>
> And I get correct data. LA is 3 hours earlier.  But doing this:
>
> current=`TZ=":America/Indianapolis" date +%s`
> echo $current
> current=`TZ=":America/Los_Angeles" date +%s`
> echo $current
>
> I get the same data - its not 3 hours different.
>
> What am I not doing correct ?
>
> Thanks,
>
> Jerry

Per the date(1) man page,

   %s seconds since 1970-01-01 00:00:00 UTC

Thus,%s is independent of the timezonerelative to UTC.

And you don't need any of those double-quotes.

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


Re: [CentOS] luks encrypted - tell at boot to skip/ignore it - how?

2021-02-01 Thread Chris Schanzle via CentOS
On 1/30/21 9:48 AM, lejeczek via CentOS wrote:
> How to tell grub/kernel to ignore, skip either all or a specific block device 
> which is luks-ecrypted - would anybody know?
> I have a box (kvm) which had a "secondary" luks-encrypted disk which now is 
> detached and Centos just hangs @boot waiting for that disk.
> many thanks, L.


Try adding to /etc/crypttab an entry for it including the options:  
nofail,noauto

You might also need an /etc/fstab entry for it (recommend LABEL= or UUID= as 
the source) and use the mount option of "nofail".  Might also need "noauto" 
depending on your situation.

crypttab(5) and mount(8) are your friends here.  Hope that helps!



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


Re: [CentOS] CentOS 8 future

2020-12-14 Thread Chris Schanzle via CentOS

On 12/14/20 3:47 PM, Leroy Tennison wrote:
> The whole issue of "support longevity" raises an issue I've been pondering, 
> is 10-year support a good thing from a security perspective?  At work we use 
> Ubuntu LTS which has only a five year support cycle (you can pay for an extra 
> five years) but, even with that, issues have arisen.  Although they do 
> security and bug fix updates, the package versions remain basically the same. 
>  So, if a package is on version 1.2.3, it remains 1.2.3 with bug fixes and 
> security patches for the life of the distribution. Does Red Hat/CentOS do the 
> same thing?

Yes.  Nearly always.  Exceptions are in release notes as "rebasing".


> The reason I ask is I ran into an issue where OpenVPN was updated in a later 
> release to support a more robust security architecture which wasn't available 
> until I upgraded.  A configuration change could have addressed a security 
> weakness in the older version so that the issue wasn't one of a security 
> patch.

This, in a nutshell, is why it is better for stability within a release, to 
back-port fixes.  Yes, it takes a lot more effort by Red Hat to maintain 
software this way.

When you decide a package needs a significantly newer version, that's when you 
start looking at new releases of the OS.





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


[CentOS] CentOS Stream & Release Notes / Documentation

2020-12-09 Thread Chris Schanzle via CentOS
One thing I have not seen discussed is how users will be notified of changes to 
functionality and new features in CentOS Stream.

With Stream being on the leading edge of a release as opposed to following, 
will there be some mechanism where changes are blogged about, Beta release 
notes, or something similar?

Thanks again to JohnnyH and the rest of the team for a great ride.

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


Re: [CentOS] Desktop Over NFS Home Blocked By Firewalld

2020-11-20 Thread Chris Schanzle via CentOS
On 11/20/20 2:31 PM, Michael B Allen wrote:
> On Fri, Nov 20, 2020 at 2:06 PM Michael B Allen  wrote:
>> Apparently I don't know how to do "that" because this:
>>
>>   # iptables -A INPUT -p tcp --sport 760 -m conntrack --ctstate
>> NEW,ESTABLISHED -j ACCEPT
>>
>> still doesn't allow the traffic through (not that I would want to
>> allow an --sport rule anyway but I'd just like to confirm that this
>> traffic is indeed responsible). What am I doing wrong here? I've also
>> tried simpler rules without conntrack or cstate but it's still not
>> getting through.
>>
>> Incidentally I added kerberos and kadmin firewalld services without
>> effect either.
> Well I've managed to resolve the issue but I'm not entirely satisfied
> with the solution. Apparently firewalld and iptables are at least
> partially mutually exclusive such that changes to iptable have no
> effect. If I add a Source Port rule using the Firewalld GUI to allow
> source port 760, it resolves the issue. But it seems pretty dubious to
> allow traffic from any particular source port. The service using port
> 760 is krbupdate but there isn't a lot of information about it on the
> net. It doesn't look like destination ports are a range because they
> have changed from 41285 and 46167. There must be something on the
> CentOS 7 side broadcasting info about what ports to use. What a PITA.
> I can't log into a desktop with an nfs home dir without punching a
> reverse hole in my firewall? That shouldn't be. 99% of people will
> just drop the pants on their machine.
>
> Mike

You didn't state what version of NFS you're using.  We're still on nfsv3.  What 
you're describing looks like an issue with locked.

Curious:  Try giving the login ~10 minutes to see if something 'gives up.'

On the nfs server:  rpcinfo -p

Look at nlockmgr ports & protocols.  My hunch is your dst ports reported are 
listed.

On CentOS 7 & 8, I lock down ports on my clients and server using /etc/nfs.conf 
(c8) or /etc/sysconfig/nfs (c7).  I used random high numbers, pick your own to 
taste:

$ egrep -v '^($|#)' /etc/nfs.conf
[general]
[exportfs]
[gssd]
use-gss-proxy=1
[lockd]
port = 43090
udp-port = 43090
[mountd]
port = 43091
[nfsdcltrack]
[nfsd]
[statd]
port = 43092
[sm-notify]

On the server and clients, I allow those corresponding ports.

I believe on centos 7 I used /etc/modprobe.d/lockd.conf to use something like:

options lockd nlm_udpport=43094 nlm_tcpport=43094

and

# cat /etc/sysconfig/nfs
LOCKD_TCPPORT=43090
LOCKD_UDPPORT=43090
MOUNTD_PORT=43091
STATD_PORT=43092
RQUOTAD_PORT=43093

Hope that helps!


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


Re: [CentOS] Best practice preparing for disk restoring system

2020-11-17 Thread Chris Schanzle via CentOS
I would include LVM and mdadm info as well, since I use those features.  I 
encourage you to look at what long-lived tools, such as clonezilla, write into 
their archive directories.  It's impressive.

If you zero out all free space on all of your HDD partitions (dd bs=1M 
if=/dev/zero of=/path/deleteme; rm /path/deleteme) or use 'fstrim' for SSD's, 
you could use dd to image with fast & light compression (lzop or my current 
favorite, pzstd) and get maximum benefit of a bit-by-bit archival copy.


On 11/16/20 11:02 PM, H wrote:
> Short of backing up entire disks using dd, I'd like to collect all required 
> information to make sure I can restore partitions, disk information, UUIDs 
> and anything else required in the event of losing a disk.
>
> So far I am collecting information from:
> - fdisk -l
> - blkid
> - lsblk
> - grub2-efi.cfg
> - grub
> - fstab
>
> Hoping that this would supply me with /all/ information to restore a system - 
> with the exception of installed operating system, apps and data.
>
> I would appreciate any and all thoughts on the above!
> ___
> 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] storage for mailserver

2020-09-19 Thread Chris Schanzle via CentOS

On 9/17/20 4:25 PM, Phil Perry wrote:
> On 17/09/2020 13:35, Michael Schumacher wrote:
>> Hello Phil,
>>
>> Wednesday, September 16, 2020, 7:40:24 PM, you wrote:
>>
>> PP> You can achieve this with a hybrid RAID1 by mixing SSDs and HDDs, and
>> PP> marking the HDD members as --write-mostly, meaning most of the reads
>> PP> will come from the faster SSDs retaining much of the speed advantage,
>> PP> but you have the redundancy of both SSDs and HDDs in the array.
>>
>> PP> Read performance is not far off native write performance of the SSD, and
>> PP> writes mostly cached / happen in the background so are not so noticeable
>> PP> on a mail server anyway.
>>
>> very interesting. Do you or anybody else have experience with this
>> setup? Any test results to compare? I will do some testing if nobody
>> can come up with comparisons.
>>
>>
>> best regards
>> ---
>> Michael Schumacher
>
> Here's a few performance stats from my setup, made with fio.
>
> Firstly a RAID1 array from 2 x WD Black 1TB drives. Second set of figures are 
> the same are for a RAID1 array with the same 2 WD Black 1TB drives and a WD 
> Blue NVMe (PCIe X2) added into the array, with the 2 X HDDs set to 
> --write-mostly.
>
> Sequential write QD32
> 147MB/s (2 x HDD RAID1)
> 156MB/s (1 x NVMe, 2 x HDD RAID1)
>
> The write tests give near identical performance with and without the SSD in 
> the array as once any cache has been saturated, write speeds are presumably 
> limited by the slowest device in the array.
>
> Sequential read QD32
> 187MB/s (2 x HDD RAID1)
> 1725MB/s (1 x NVMe, 2 x HDD RAID1)
>
> Sequential read QD1
> 162MB/s (2 x HDD RAID1)
> 1296MB/s (1 x NVMe, 2 x HDD RAID1)
>
> 4K random read
> 712kB/s (2 x HDD RAID1)
> 55.0MB/s (1 x NVMe, 2 x HDD RAID1)
>
> The read speeds are a completely different story, and the array essentially 
> performs identically to the native speed of the SSD device once the slower 
> HDDs are set to --write-mostly, meaning the reads are prioritized to the SSD 
> device. The SSD NVMe device is limited to PCIe X2 hence why sequential read 
> speeds top out at 1725MB/s. Current PCIe X4 devices should be able to double 
> that.
>
> To summarize, a hybrid RAID1 mixing HDDs and SSDs will have write performance 
> similar to the HDD (slowest device) and read performance similar to the SSD 
> (fastest device) as long as the slower HDDs are added to the array with the 
> --write-mostly flag set. Obviously these are synthetic I/O tests and may not 
> reflect real world application performance but at least give you a good idea 
> where the underlying bottlenecks may be.


Too bad the 4k random write tests are missing above.

I have used SSD + HDD RAID1 configurations in dozens of CentOS desktops and 
servers for years and it works very well with the --write-mostly flag being set 
on the HDD.  With most reads coming from the SSD, starting programs are much 
quicker.

However, I find the write queue to be very, very small, so the system "feels" 
like a slow HDD system during writing.  But it is possible to configure an 
extended write-behind buffer/queue which will greatly improve 'bursty' write 
performance (e.g., Yum/DNF updates or unpacking a tarball with many small 
files).

Do test, lest some kernel bugs over the years, such as [1], rear their ugly 
head (you will get a panic quickly).  The bug returned at some point and I gave 
up hope upstream would not break it again.  For desktops, it left me unable to 
boot and required console access to fix.

In short, use 'mdadm --examine-bitmap' on a component (not the md device 
itself) and look at "Write Mode."  I set it to the maximum of 16383 which must 
be done when the bitmap is created, so remove the bitmap and create a new one 
with the options you prefer:

mdadm /dev/mdX --grow --bitmap=none
mdadm /dev/mdX --grow --bitmap=internal --bitmap-chunk=512M --write-behind=16383

Note sync_action must be idle if you decide to script this.  Bigger 
bitmap-chunks are my preference, but might not be yours.  Your mileage and 
performance may differ.  :-)

I've been meaning to test big write-behind's on my CentOS 8 systems...

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1582673  (login required to 
view)



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


Re: [CentOS] Thunderbird 68.10.0

2020-08-06 Thread Chris Schanzle via CentOS
On 7/29/20 6:28 PM, Johnny Hughes wrote:
> On 7/27/20 1:43 PM, Leon Fauster via CentOS wrote:
>> Am 27.07.20 um 19:50 schrieb Chris Schanzle via CentOS:
>>> Sorry if I'm being overly impatient, but is there some snag with
>>> releasing Thunderbird 68.10.0 for EL8?
>>>
>>> [RHSA-2020:3038-01] Important: thunderbird security update
>>>
>>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHSA-2020%3A3038data=02%7C01%7Cchristopher.schanzle%40nist.gov%7C638e7edab7454c80ef2408d8340eb9d7%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637316585150559834sdata=HkuReVjbdCYxkaehqjeC6oNlRBxKcZXIEbUDoKvJuJo%3Dreserved=0
>>>
>>> Thanks!
>>>
>> at the door:
>>
>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.centos.org%2Frpms%2Fthunderbird%2Freleasesdata=02%7C01%7Cchristopher.schanzle%40nist.gov%7C638e7edab7454c80ef2408d8340eb9d7%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637316585150569829sdata=cywUwwoVucVxW6o9EQNDimm280PVFkRx%2BgF4SEGYkDA%3Dreserved=0
> We have been working non-stop for the last several days on the embargoed
> kernel, grub2, and other secure boot items (that is .. the 'Boot Hole'
> issue) for el7 and el8 for the .. therefore some other updates were
> pushed back.
>
> I am trying to finish up the 'Boot Hole' el7 updates right now .. 2
> other people are currently working on the el8 items.
>
> Once these get pushed .. hopefully tonight .. we will be working on the
> other updates starting tomorrow.
>
> Thanks,
> Johnny Hughes


First, thank you for all the efforts that went into the Boot Hole / shim issue. 
 I'm sorry for the bad PR CentOS got for it.  I do hope upstream will not have 
more occurrences of the like...historically, they've been very reliable, which 
is why it is my choice of OS.

Just a friendly reminder Thunderbird 68.10 hasn't been released for CentOS 8.

And I see RHEL has announced Thunderbird 68.11.0:   
https://access.redhat.com/errata/RHSA-2020:3341

I do hope the day will come where we can meet so I can thank you in person.  It 
would be a great pleasure buy you a beer / meal / t-shirt.

Best regards,
Chris


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


Re: [CentOS] rsync upgrade

2020-08-06 Thread Chris Schanzle 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!



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


[CentOS] Thunderbird 68.10.0

2020-07-27 Thread Chris Schanzle via CentOS
Sorry if I'm being overly impatient, but is there some snag with releasing 
Thunderbird 68.10.0 for EL8?

[RHSA-2020:3038-01] Important: thunderbird security update

https://access.redhat.com/errata/RHSA-2020:3038

Thanks!

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


Re: [CentOS] Apache umask

2020-07-19 Thread Chris Schanzle 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 similarly checked CentOS 7.8 httpd-2.4.6-93.el7.centos.src.rpm with the same 
result.

Just thought I'd share my dead-end attempt to help since suexec hasn't been 
mentioned.  :-)

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


Re: [CentOS] CentOS 8 & HandBrakeCLI

2020-07-13 Thread Chris Schanzle via CentOS
On 7/12/20 10:04 PM, Frank M. Ramaekers Jr. wrote:
> Since I upgraded to CentOS8, I cannot get HandBrakeCLI to work:
>
> # HandBrakeCLI
> HandBrakeCLI: error while loading shared libraries: libass.so.5: cannot open 
> shared object file: No such file or directory


HandBrakeCLI (and ghb - the GUI) at least starts without error on CentOS 8 as 
installed from rpmfusion.  I haven't actually used it.

I suggest you look at 'rpm -qi $(which HandBrakeCLI)' to show you where you got 
your handbrake from and possibly update it from there.  Perhaps you disabled 
some repos?


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


Re: [CentOS] Looking for C8 AMD help

2020-04-23 Thread Chris Schanzle via CentOS

On 4/23/20 4:23 PM, Pete Geenhuizen wrote:

I'm migrating from C7 to C8.  I'm currently using autofs, but alas autofs has 
been dropped in C8 for the AMD automounter.


Nope, it's in there! 8/BaseOS/x86_64/os/Packages/autofs-5.1.4-35.el8.x86_64.rpm



I have some very ancient knowledge of AMD, I used it when it was first 
introduced many years ago on Solaris and moved to Sun's automounter when it was 
introduced.
So now it's back to square one.
I used automount2amd to convert one of my existing maps, included it in the 
amd.conf file and tried it out.  I don't get any syntax errors so I guess that 
the map syntax is correct, but amd fails to mount the remote filesystem and 
generates these errors  in messages.


Apr 23 16:04:29 localhost.my.domain amd[19389]: matched default selectors 
"type:=nfs;opts:=rw,grpid,nosuid,utimeout=600"
Apr 23 16:04:29 localhost.my.domain amd[19389]: key new: map selector host 
(=localhost) did not match remotehost
Apr 23 16:04:29 localhost.my.domain amd[19389]: merge rem/opts "rw,grpid,nosuid,utimeout=600" add 
"fstype=nfs,vers=4,soft,intr" => 
"rw,grpid,nosuid,utimeout=600,fstype=nfs,vers=4,soft,intr"
Apr 23 16:04:29 localhost.my.domain amd[19389]: Map entry 
host==remotehost;type:=link;fs:=/export/data/& for /repo/new did not match
Apr 23 16:04:29 localhost.my.domain amd[19389]: merge rem/opts "rw,grpid,nosuid,utimeout=600" add 
"fstype=nfs,vers=4,soft,intr" => 
"rw,grpid,nosuid,utimeout=600,fstype=nfs,vers=4,soft,intr"
Apr 23 16:04:29 localhost.my.domain amd[19389]: get_nfs_version: returning 
NFS(4,tcp) on host remotehost.my.domain
Apr 23 16:04:29 localhost.my.domain amd[19389]: get_nfs_version: NFS(4,udp) 
failed for remotehost.my.domain: RPC: Unable to receive
Apr 23 16:04:29 localhost.my.domain amd[19389]: get_nfs_version: NFS(3,udp) 
failed for remotehost.my.domain: RPC: Unable to receive
Apr 23 16:04:29 localhost.my.domain amd[19389]: get_nfs_version: NFS(2,udp) 
failed for remotehost.my.domain: RPC: Unable to receive
Apr 23 16:04:29 localhost.my.domain amd[19389]: get_nfs_version: returning 
NFS(0,udp) on host remotehost.my.domain
Apr 23 16:04:29 localhost.my.domain amd[19389]: Using NFS version 4, protocol 
tcp on host remotehost.my.domain
Apr 23 16:04:29 localhost.my.domain amd[19389]: changing remotehost.my.domain's 
ping value from 30 to 30
Apr 23 16:04:29 localhost.my.domain amd[19389]: Trying mount of 
remotehost:/export/data/& on /.automount/remotehost/export/data/& fstype nfs 
mount_type non-autofs
Apr 23 16:04:31 localhost.my.domain amd[19389]: Trying mount of 
remotehost:/export/data/& on /.automount/remotehost/export/data/& fstype nfs 
mount_type non-autofs
Apr 23 16:04:32 localhost.my.domain amd[19389]: file server 
remotehost.my.domain, type nfs, state starts down
Apr 23 16:04:49 localhost.my.domain amd[19389]: "/repo/new" on //nil// timed 
out (flags 0x20)

I'm using firewalld  on both hosts and allow these services mountd nfs rpc-bind 
and protocols 111/tcp and 111/udp  all of which allow autofs to work 
flawlessly, I've tried turning firewalld off which made no difference.

Here's my /etc/amd.remote file looks like
new \
  -addopts:=fstype=nfs,vers=4,soft,intr \
  host==remotehost;type:=link;fs:=/export/data/& \
  rhost:=remotehost;rfs:=/export/data/&

Any assistance in pointing me in the right direction would be greatly 
appreciated.
Pete


sudo dnf -y install autofs # for the win!

consider removing what I think you have is am-utils.


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


Re: [CentOS] Mounting CIFS shares on C8

2020-04-03 Thread Chris Schanzle via CentOS

On 4/3/20 12:48 PM, Patrick DERWAEL wrote:

User & pass are present
According to the man pages, workgroup is supported
I have changed it to domain, but that didn't change a thing

[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
  user=plex,pass=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 ~]#

Le ven. 3 avr. 2020 à 18:23, Leon Fauster via CentOS  a
écrit :


Am 03.04.20 um 18:01 schrieb Patrick DERWAEL:

Le ven. 3 avr. 2020 à 17:54, Jonathan Billings  a
écrit :


On Fri, Apr 03, 2020 at 04:00:42PM +0200, Patrick DERWAEL wrote:

//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

Try removing non-ascii characters from your mountpoints and try again.

--
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentosdata=02%7C01%7Cchristopher.schanzle%40nist.gov%7C50e5520598c94cdebfc708d7d7eefb64%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637215293735011190sdata=jVoqTxBRGNNfP7%2BWZCRP%2Fbb5vQ9RdErHznttq5wkWH8%3Dreserved=0


I have commented out the 2 mounts with non-ascii... that didn't help...


[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
   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 ~]# 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 ~]#



   username=value
   password=value
   domain=value

?

--



Instead of user=, try username=.  mount.cifs(8) states:

   While some versions of the cifs kernel module accept user= as an 
abbreviation for this option, its use can confuse the standard mount program 
into thinking that this is a non-superuser mount. It is therefore recommended 
to use the full username= option name.


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


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

2020-02-27 Thread Chris Schanzle via CentOS

On 2/27/20 8:01 AM, Tobias Kirchhofer wrote:

Hi,

we experience difficulties with crond behaviour sending mail since CentOS 8.1. 
The cron job is the same like we used in CentOS 7.

crontab -l
/usr/bin/python3 -c 'import random; import time; time.sleep(random.random() * 3600)' 
&& /usr/local/bin/backup.sh


Agreed on the missing timespec (invalid cron line), but why the mile-long 
python rather than the simpler:

sleep $((RANDOM \% 3600))

Recall percent signs (%) in crontabs means put a newline here, so it needs to 
be quoted to disable.

Regardless, you say it's not sending mail...that could be silence or say if 
/usr/bin/python3 didn't exist, should output an error. did you check your mail 
logs?

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


Re: [CentOS] CentOS 8 on USB disk

2020-01-31 Thread Chris Schanzle via CentOS

On 1/29/20 12:34 PM, Jerry Geis wrote:


Sorry for the noise... My machine must not be working. I copied the iso to

another machine, did the same command as always and worked just fine. not

sure what is up with my normal box. Has always worked before.


[problem with my subscription, sorry if this is a duplicate.]

Just a suggestion - look for "large" files in /dev/ on your old machine.  An 
incorrect output file name will leave a big file there, rather than write to the device 
you intended. Something like:

find /dev -size +1G -ls


I use the dd option 'oflag=direct' to do direct I/O on the output.  Eliminates 
the need for sync.  Coupled with 'status=progress' you can get a real 
indication of how fast your storage device is.

dd bs=4M oflag=direct status=progress if=some.iso of=/dev/sdX


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


Re: [CentOS] http error when updating 7.5 ==> 7.6

2019-03-26 Thread Chris Schanzle via CentOS

On 3/25/19 8:32 AM, Johnny Hughes wrote:

This is not the first time we have had issues with drpms in the update tree.
Would anyone be opposed to taking away deltarpms from the repositories?

They take up lots of space and they have cause multiple issues in the past.

Thoughts?



Due to the disk churn deltarpms need and our own internal mirroring of centos 
packages, one of the first things I do post-install is disable deltarpms.

However, I'm sure there are users on limited connections (either monthly cap or 
slow) who appreciate the deltarpms who are not on this list to cast their vote.

I suppose the only way to find out is to take them away and if there is outcry, 
put them back.


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


Re: [CentOS] Changing UID numbers

2019-02-20 Thread Chris Schanzle via CentOS

On 2/16/19 12:14 PM, Bill Gee wrote:

...After the usermod programs ran, I then did a "find -uid=500" with an exec 
option to change ownership.  Repeat for changing GID.  It found a few dozen files that 
were not in my home directory.

On the server I ran the two "find" commands against the entire file system.  It 
took about half an hour to run.  No surprise there as it was finding and changing several 
hundred thousand files.  I ran the uid change in one terminal and the gid change in 
another.  Between the two of them they consumed about 90% on both processor cores.


Hi Bill,

Just sharing some wisdom/experience.  Too bad it's after the bulk of your work. 
 :-)

It should not have been consuming much cpu.  This is an I/O-based activity.

My guess is you used something like

  find -uid=500 -exec chown 1000 {} \;

This will start a chown process for each file, changing only one file at a 
time.  That's a lot of work the system has to do for each file!  But you 
probably know chown (and similar utilities) can take multiple file arguments, 
and 'find' can help you take advantage grouping many arguments with the '+' 
operator to -exec:

  find -uid=500 -exec chown 1000 {} +

And you could combine the bulk of your I/O work of chgrp-ing for all of your 
files at the same time by using 'chown 1000:1000'.

You might want to check your symlinks ('find -type l -ls'). You may have 
changed the ownership of what they point to rather than the link itself, 
precisely what the chown -h (--no-dereference) option is good for.  Don't 
forget to revisit what the permissions should be on the link targets.  Bad 
things would happen if the user had a symlink to /etc/passwd and/or /etc/shadow 
in their home directory!

I also like to use -xdev to avoid traversing into any unexpected filesystems.  
So I end up with:

  find /somedir -xdev -uid=500 -exec chown -h newID:newGroup {} +

Hope that helps for the next time or someone else!

[This is off the top of my head, so beware of any mistakes...these commands 
have significant consequences.]

Best regards,

Chris Schanzle

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


Re: [CentOS] Fedora Server - as an alternative ?

2018-12-20 Thread Chris Schanzle via CentOS

On 12/20/18 10:07 AM, Patrick Bégou wrote:

Le 20/12/2018 à 14:11, lejeczek via CentOS a écrit :

hi guys

I wonder if any Centosian here have done something different than only
contemplated using Fedora Server, actually worked on it in
test/production envs.

If here are some folks who have done it I want to ask if you deem it
to be a viable option to put it on at least portion of servers stack.

Anybody?

Many thanks, L.

___
CentOS mailing list
CentOS@centos.org


Using fedora will lead you to reinstall servers frequently, for almost
each new versions I think.

Many years ago I was using opensuse as some of my servers were running
SLES and migration between versions was  realy difficult without full
reinstall every 1,5 to 2 years...


Patrick



That's just...err, misinformation.  The Fedora team works very hard to enable 
upgrading (without a clean install) from one release to the next...often 
skipping releases is fine (e.g., 27 to 29).

That said, I only have a few Fedora boxes (used like servers -- that is, not on 
people's desks) for my users that need more bleeding edge software stacks and 
additional packages than CentOS + EPEL can provide.  Due to the heavy flow of 
packages updates and kernel updates, it takes a special kind of user to cope 
with updates, reboots, and occasional breakage.

Chris

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