Re: [CentOS-virt] Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

[Kevin Stange]

On 08/30/2017 03:10 PM, Pasi Kärkkäinen wrote:
> Hello everyone,
> 
> Recently Nathan March reported on centos-virt list he's getting frequent 
> Linux kernel crashes with Linux 4.9 LTS kernel because of the missing patch 
> "tty: Fix ldisc crash on reopened tty".
> 
> The patch was already merged upstream here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71472fa9c52b1da27663c275d416d8654b905f05
> 
> but then reverted here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=896d81fefe5d1919537db2c2150ab6384e4a6610
> 
> Nathan confirmed if he applies the patch from 
> 71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the 
> bug/problem goes away, so the patch (or similar fix) is still needed, at 
> least for 4.9 LTS kernel.
> 
> 
> Mikulas reported he's able to trigger the same crash on Linux 4.10:
> https://www.spinics.net/lists/kernel/msg2440637.html
> https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#2664604
> 
> Michael Neuling reported he's able to trigger the bug on PowerPC:
> https://lkml.org/lkml/2017/3/10/1582
> 
> 
> So now the question is.. is anyone currently working on getting this patch 
> fixed and applied upstream? I think one of the problems earlier was being 
> able to reliable reproduce the crash.. Nathan says he's able to reproduce it 
> many times per week on his environment on x86_64.

I looked briefly at the patch and related discussion on the kernel
mailing lists and it seemed to be reverted not due to any problems it
caused with kernel behavior but rather due to concerns about
insufficient review before it was committed and possible merge conflicts.

The issue is the problem doesn't appear to have been discussed any
further on the kernel mailing lists since April, and I'm not sure why.
My inclination would be to start back up discussion upstream and try to
get clarification as to why the patch has remained reverted and there's
been no effort to bring it back into the kernel, rather than assume the
patch is safe to use.  I doubt anyone else but people experiencing the
issue have it up on their radar.

The 4.9 virt kernel does have some patches currently that haven't (yet)
been accepted upstream, so it's definitely an option to do that here.
As far as I know, nothing really gets pushed back upstream.  Most often
the patches are just plucked from upstream mailing lists before they get
merged into an official upstream release.

-- 
Kevin Stange
Chief Technology Officer
Steadfast | Managed Infrastructure, Datacenter and Cloud Services
800 S Wells, Suite 190 | Chicago, IL 60607
312.602.2689 X203 | Fax: 312.602.2688
ke...@steadfast.net | www.steadfast.net
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

[Pasi Kärkkäinen]

Hello everyone,

Recently Nathan March reported on centos-virt list he's getting frequent Linux 
kernel crashes with Linux 4.9 LTS kernel because of the missing patch "tty: Fix 
ldisc crash on reopened tty".

The patch was already merged upstream here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71472fa9c52b1da27663c275d416d8654b905f05

but then reverted here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=896d81fefe5d1919537db2c2150ab6384e4a6610

Nathan confirmed if he applies the patch from 
71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the 
bug/problem goes away, so the patch (or similar fix) is still needed, at least 
for 4.9 LTS kernel.


Mikulas reported he's able to trigger the same crash on Linux 4.10:
https://www.spinics.net/lists/kernel/msg2440637.html
https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#2664604

Michael Neuling reported he's able to trigger the bug on PowerPC:
https://lkml.org/lkml/2017/3/10/1582


So now the question is.. is anyone currently working on getting this patch 
fixed and applied upstream? I think one of the problems earlier was being able 
to reliable reproduce the crash.. Nathan says he's able to reproduce it many 
times per week on his environment on x86_64.


Thanks a lot,

-- Pasi

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

Re: [CentOS] spice client?

[Felipe Salvador]

On Wed, Aug 30, 2017 at 08:05:18PM +0200, hw wrote:
> In this case, no encryption is needed.  That is my decision, and if spice 
> thinks
> it could make that decision for me, it needs to be fixed.

So I think you can replace 

> > virt-viewer --connect qemu+ssh:///system 

with[1]

virt-viewer --connect qemu+tcp://example.com/system 


[1] http://libvirt.org/drvqemu.html#uris

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

Re: [CentOS] Syncronize systemctl status with reality?

[James Hogarth]

On 29 August 2017 at 21:52, Leroy Tennison  wrote:

> - Original Message -
> From: "James Hogarth" 
> To: "centos" 
> Sent: Tuesday, August 29, 2017 2:03:44 PM
> Subject: Re: [CentOS] Syncronize systemctl status with reality?
>
> On 29 Aug 2017 17:58, "Leroy Tennison"  wrote:
>
> The particular issue is with puppetmaster (which admittedly takes 4 minutes
> to actually start, setting TimeoutStartSec=300 in it's unit file stopped
> the false timeout report) but I have seen it one other time (don't remember
> the details).
>
> systemctl status puppetmaster
> ● puppetmaster.service - Puppet master
> Loaded: loaded (/lib/systemd/system/puppetmaster.service; enabled; vendor
> preset: enabled)
> Active: failed (Result: resources) since Tue 2017-08-29 11:24:36 CDT; 22min
> ago
> Process: 897 ExecStart=/usr/bin/puppet master (code=exited,
> status=0/SUCCESS)
>
> Aug 29 11:22:39 puppetmaster02 systemd[1]: Starting Puppet master...
> Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Reopening log files
> Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Starting Puppet master
> version 3.8.5
> Aug 29 11:24:36 puppetmaster02 puppet-master[1233]: Could not run: Address
> already in use - listen(2)
> Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: PID 1233
> read from file /run/puppet/master.pid does not exist or is a zombie.
> Aug 29 11:24:36 puppetmaster02 systemd[1]: Failed to start Puppet master.
> Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Unit
> entered failed state.
> Aug 29 11:24:36 puppetmaster02 systemd[1]: puppetmaster.service: Failed
> with result 'resources'.
>
> However, ps -ef | grep puppet (run just after the above) returns
> puppet 1380 1 0 11:26 ? 00:00:08 Passenger RubyApp: /usr/share/puppet/rack/
> puppetmasterd
> root 2015 1341 0 11:48 pts/0 00:00:00 grep --color=auto puppet
>
> Earlier ps .. also reported
> puppet 1355 1166 3 11:26 ? 00:00:01 Passenger AppPreloader:
> /usr/share/puppet/rack/puppetmasterd
>
> And, the "bottom line", puppet agent -t on a client works. It reports
> finishing the catalog run and the client's yaml files on puppetmaster are
> up to date.
>
> Is there a command to tell systemd to re-scan running state and update its
> understanding on what it finds? I tried systemctl daemon-reload just to be
> sure that didn't solve the problem before posting this.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
>
> First glance ity looks like someone has started that puppetmaster manually
> at some point. As such it's not in a cgroup systemd is tracking so it isn't
> aware of it.
>
> Your attempts to start the service are failing because that manually
> started instance already has the port open.
>
> Kill it with pkill -f puppet and then use ss -tnp to check for the port
> being freed (wait for any time_wait states to go... which is why I'm not
> filtering by listen).
>
> Once it's clear then try starting with systemctl
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
> OK, something weird is definitely going on here, I have the luxury of
> rebooting this system so it did.  Here's what I got, note the time stamps.
>
> ps -ef | grep puppet
> root   932 1  0 15:23 ?00:00:00 /usr/bin/ruby
> /usr/bin/puppet master
> root  1343  1327  0 15:24 pts/000:00:00 grep --color=auto puppet
> (immediately afterward as fast as I could type:) uptime
>  15:24:56 up 1 min,  1 user,  load average: 0.16, 0.07, 0.02
> systemctl status puppetmaster
> ● puppetmaster.service - Puppet master
>Loaded: loaded (/lib/systemd/system/puppetmaster.service; enabled;
> vendor preset: enabled)
>Active: activating (start) since Tue 2017-08-29 15:23:44 CDT; 1min 24s
> ago
>   Control: 932 (puppet)
> Tasks: 1
>Memory: 2.4M
>   CPU: 4ms
>CGroup: /system.slice/puppetmaster.service
>└─932 /usr/bin/ruby /usr/bin/puppet master
>
> Aug 29 15:23:44 puppetmaster02 systemd[1]: Starting Puppet master...
>
>
>
> After a short delay:
> systemctl status puppetmaster
> ● puppetmaster.service - Puppet master
>Loaded: loaded (/lib/systemd/system/puppetmaster.service; enabled;
> vendor preset: enabled)
>Active: failed (Result: resources) since Tue 2017-08-29 15:25:11 CDT;
> 11s ago
>   Process: 932 ExecStart=/usr/bin/puppet master (code=exited,
> status=0/SUCCESS)
>
> Aug 29 15:23:44 puppetmaster02 systemd[1]: Starting Puppet master...
> Aug 29 15:25:11 puppetmaster02 puppet-master[1360]: Reopening log files
> Aug 29 15:25:11 puppetmaster02 puppet-master[1360]: Starting Puppet master
> version 3.8.5
> Aug 29 15:25:11 puppetmaster02 puppet-master[1360]: Could not run: Address
> already in use - listen(2)
> Aug 29 15:25:11 puppetmaster02 

Re: [CentOS] spice client?

[hw]

milos.blazevic wrote:

A VM can have spice console listen only on the loopback interface, so the only 
way to connect would be to tunnel the spice connection via SSH. This is so 'by 
design'.


I specified to listen on all addresses --- in my understanding, that
are the addresses of the host rather than those of any particular VM.


You'll certainly need an SSH keypair for authentication along with the 
ssh-agent (if your private key is password protected). I'm using something like:


That´s way too complicated and awkward.

Why would I use ssh-agent?  Specifying a passphrase to use a key means that
I do *not* want everything/everyone to be able to use it.  Not specifying a
passphrase shouldn´t require an ssh-agent.

And how would I set this up, i. e. how would I tell the spice-client which
keys to use, and how the host which keys to use?  It´s not like I´m providing
a user name to the host I´m connecting to which would allow it to pick a key.

Then there are five bazillion different versions of encryption methods and the
overall extreme difficulty to deal with it.

In this case, no encryption is needed.  That is my decision, and if spice thinks
it could make that decision for me, it needs to be fixed.



virt-viewer --connect qemu+ssh:///system 


Regards,
Milos.

Quoting hw :


Felipe Salvador wrote:

On Wed, Aug 30, 2017 at 04:55:45PM +0200, hw wrote:


Hi,

how do I connect to a VM running on a removte machine with some
sort of spice client?  There doesn´t seem to be any spice client
available in Centos 7 that works.


virt-viewer?



That only says it´s unable to connect.

The XML-dump says:




  



I remember it was working somehow, now it doesn´t.  And I don´t remember
what client I used.
___
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] rkhunter and prelink [SOLVED]

[m . roth]

Tony, please don't top post. This isn't Outlook.

Tony Schreiner wrote:
>>
>> On Wed, Aug 30, 2017 at 11:15 AM,  wrote:
>>
>>> Can't remember if I posted this before... We're getting warnings from
>>> rkhunterWarning: Checking for prerequisites   [ Warning ]
>>>All file hash checks will be skipped because:
>>>This system uses prelinking, but the hash function command does not
>>> look like SHA1 or MD5.
>>>
>>> Now, googling, I find people saying to rm /etc/prelink.cache, then run
>>> rkhunter --propupd.
>>>
>>> Works. And then, prelink runs in the middle of the night, via
>>> /etc/cron.daily, and when the cron job of rkhunter runs, it's back to
>>> complaining.
>>>
>>> Anyone have any ideas what's going on here? I don't see anything in the
>>> prelink.conf, or any options in the prelink manpage to tell is what
>>> hash to use.
>>>
> in my prior message, that should be in rkhunter.conf
>
> On Wed, Aug 30, 2017 at 11:43 AM, Tony Schreiner
> 
> wrote:
>
>> This has come up for me on the most recent upgrade, add the line
>>
>> HASH_CMD=sha1sum

Got the answer: I had HASH=sha256sum. That didn't work. sha1sum works.

Oh, that, and uncommenting the line in /etc/rkhunter.conf:
USER_FILEPROP_FILES_DIRS=/etc/rkhunter.conf.local

Works better, don't'cha know.

Thanks for the help and pushes in the right direction, folks.

  mark

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

Re: [CentOS] spice client?

[milos.blazevic]

A VM can have spice console listen only on the loopback interface, so  
the only way to connect would be to tunnel the spice connection via  
SSH. This is so 'by design'.


You'll certainly need an SSH keypair for authentication along with the  
ssh-agent (if your private key is password protected). I'm using  
something like:


virt-viewer --connect qemu+ssh:///system 


Regards,
Milos.

Quoting hw :


Felipe Salvador wrote:

On Wed, Aug 30, 2017 at 04:55:45PM +0200, hw wrote:


Hi,

how do I connect to a VM running on a removte machine with some
sort of spice client?  There doesn´t seem to be any spice client
available in Centos 7 that works.


virt-viewer?



That only says it´s unable to connect.

The XML-dump says:




  



I remember it was working somehow, now it doesn´t.  And I don´t remember
what client I used.
___
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] rkhunter and prelink

[Valeri Galtsev]

On Wed, August 30, 2017 11:27 am, Christian, Mark wrote:
> On Wed, 2017-08-30 at 11:03 -0500, Valeri Galtsev wrote:
>> On Wed, August 30, 2017 10:43 am, Tony Schreiner wrote:
>> > This has come up for me on the most recent upgrade, add the line
>> >
>> > HASH_CMD=sha1sum
>> >
>> > On Wed, Aug 30, 2017 at 11:15 AM,  wrote:
>> >
>> > > Can't remember if I posted this before... We're getting warnings
>> from
>> > > rkhunterWarning: Checking for prerequisites   [ Warning
>> ]
>> > >All file hash checks will be skipped because:
>> > >This system uses prelinking, but the hash function command does
>> not
>> > > look like SHA1 or MD5.
>> > >
>> > > Now, googling, I find people saying to rm /etc/prelink.cache, then
>> run
>> > > rkhunter --propupd.
>> > >
>> > > Works. And then, prelink runs in the middle of the night, via
>> > > /etc/cron.daily, and when the cron job of rkhunter runs, it's back
>> to
>> > > complaining.
>>
>> Prelink is evil, in a sense of what it does. Allegedly it helps to load
>> into memory binaries and libraries faster, for that it TOUCHES every one
>> of them regularly. This effectively defeats the way we watch for system
>> integrity by tracking all system files and libraries information, such
>> as:
>> file sizes, time stamps, inode numbers, checksums. The very moment
>> RedHat
>> made prelink installed by default, I was so upset that you can feel
>> these
>> my feelings in my writing now are still present. I got rid of prelink,
>> and
>> I rid of it specifically on my kickstart files. Two or three years down
>> the road RedHat came to its senses and removed prelink from what is
>> installed by default. I'm surprised, Mark, that you still have it some
>> place. Any specific reason? If not, get rid of prelink which does waaay
>> more harm than it does good IMHO.
> Or keep prelink and modify your HASH_CMD to "prelink -y
> /path/to/binary|sha1sum"

IMHO that means keeping the evil in the loop, the loop that should be
tightest, slimmest and awfully trusted. Which partly much defeats the
reasons why we watch the files. And it doesn't help with ever changing
file inode numbers, timestamps, only checksums (I use different from OP's
system integrity tools, so I'm not certain if the last matters for OP).
Anyway, my decision was to get rid of evil. But that is me who puts system
integrity three levels above how fast the system feels (and feeling is
only about how fast the application starts, not how fast it runs). Sorry,
my attitude to prelink will keep showing always ;-)

Valeri

>
> Mark
>
>
>>
>> Valeri
>>
>> > >
>> > > Anyone have any ideas what's going on here? I don't see anything in
>> the
>> > > prelink.conf, or any options in the prelink manpage to tell is what
>> hash
>> > > to use.
>> > >
>> > >  mark
>> > >
>> > > ___
>> > > 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
>> >
>>
>>
>> 
>> Valeri Galtsev
>> Sr System Administrator
>> Department of Astronomy and Astrophysics
>> Kavli Institute for Cosmological Physics
>> University of Chicago
>> Phone: 773-702-4247
>> 
>> ___
>> 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
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

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

Re: [CentOS] rkhunter and prelink

[Christian, Mark]

On Wed, 2017-08-30 at 11:03 -0500, Valeri Galtsev wrote:
> On Wed, August 30, 2017 10:43 am, Tony Schreiner wrote:
> > This has come up for me on the most recent upgrade, add the line
> > 
> > HASH_CMD=sha1sum
> > 
> > On Wed, Aug 30, 2017 at 11:15 AM,  wrote:
> > 
> > > Can't remember if I posted this before... We're getting warnings from
> > > rkhunterWarning: Checking for prerequisites   [ Warning ]
> > >All file hash checks will be skipped because:
> > >This system uses prelinking, but the hash function command does not
> > > look like SHA1 or MD5.
> > > 
> > > Now, googling, I find people saying to rm /etc/prelink.cache, then run
> > > rkhunter --propupd.
> > > 
> > > Works. And then, prelink runs in the middle of the night, via
> > > /etc/cron.daily, and when the cron job of rkhunter runs, it's back to
> > > complaining.
> 
> Prelink is evil, in a sense of what it does. Allegedly it helps to load
> into memory binaries and libraries faster, for that it TOUCHES every one
> of them regularly. This effectively defeats the way we watch for system
> integrity by tracking all system files and libraries information, such as:
> file sizes, time stamps, inode numbers, checksums. The very moment RedHat
> made prelink installed by default, I was so upset that you can feel these
> my feelings in my writing now are still present. I got rid of prelink, and
> I rid of it specifically on my kickstart files. Two or three years down
> the road RedHat came to its senses and removed prelink from what is
> installed by default. I'm surprised, Mark, that you still have it some
> place. Any specific reason? If not, get rid of prelink which does waaay
> more harm than it does good IMHO.
Or keep prelink and modify your HASH_CMD to "prelink -y /path/to/binary|sha1sum"

Mark


> 
> Valeri
> 
> > > 
> > > Anyone have any ideas what's going on here? I don't see anything in the
> > > prelink.conf, or any options in the prelink manpage to tell is what hash
> > > to use.
> > > 
> > >  mark
> > > 
> > > ___
> > > 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
> > 
> 
> 
> 
> Valeri Galtsev
> Sr System Administrator
> Department of Astronomy and Astrophysics
> Kavli Institute for Cosmological Physics
> University of Chicago
> Phone: 773-702-4247
> 
> ___
> 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] rkhunter and prelink

[Valeri Galtsev]

On Wed, August 30, 2017 10:43 am, Tony Schreiner wrote:
> This has come up for me on the most recent upgrade, add the line
>
> HASH_CMD=sha1sum
>
> On Wed, Aug 30, 2017 at 11:15 AM,  wrote:
>
>> Can't remember if I posted this before... We're getting warnings from
>> rkhunterWarning: Checking for prerequisites   [ Warning ]
>>All file hash checks will be skipped because:
>>This system uses prelinking, but the hash function command does not
>> look like SHA1 or MD5.
>>
>> Now, googling, I find people saying to rm /etc/prelink.cache, then run
>> rkhunter --propupd.
>>
>> Works. And then, prelink runs in the middle of the night, via
>> /etc/cron.daily, and when the cron job of rkhunter runs, it's back to
>> complaining.

Prelink is evil, in a sense of what it does. Allegedly it helps to load
into memory binaries and libraries faster, for that it TOUCHES every one
of them regularly. This effectively defeats the way we watch for system
integrity by tracking all system files and libraries information, such as:
file sizes, time stamps, inode numbers, checksums. The very moment RedHat
made prelink installed by default, I was so upset that you can feel these
my feelings in my writing now are still present. I got rid of prelink, and
I rid of it specifically on my kickstart files. Two or three years down
the road RedHat came to its senses and removed prelink from what is
installed by default. I'm surprised, Mark, that you still have it some
place. Any specific reason? If not, get rid of prelink which does waaay
more harm than it does good IMHO.

Valeri

>>
>> Anyone have any ideas what's going on here? I don't see anything in the
>> prelink.conf, or any options in the prelink manpage to tell is what hash
>> to use.
>>
>>  mark
>>
>> ___
>> 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
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

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

Re: [CentOS] rkhunter and prelink

[Tony Schreiner]

in my prior message, that should be in rkhunter.conf

On Wed, Aug 30, 2017 at 11:43 AM, Tony Schreiner 
wrote:

> This has come up for me on the most recent upgrade, add the line
>
> HASH_CMD=sha1sum
>
> On Wed, Aug 30, 2017 at 11:15 AM,  wrote:
>
>> Can't remember if I posted this before... We're getting warnings from
>> rkhunterWarning: Checking for prerequisites   [ Warning ]
>>All file hash checks will be skipped because:
>>This system uses prelinking, but the hash function command does not
>> look like SHA1 or MD5.
>>
>> Now, googling, I find people saying to rm /etc/prelink.cache, then run
>> rkhunter --propupd.
>>
>> Works. And then, prelink runs in the middle of the night, via
>> /etc/cron.daily, and when the cron job of rkhunter runs, it's back to
>> complaining.
>>
>> Anyone have any ideas what's going on here? I don't see anything in the
>> prelink.conf, or any options in the prelink manpage to tell is what hash
>> to use.
>>
>>  mark
>>
>> ___
>> 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] rkhunter and prelink

[Tony Schreiner]

This has come up for me on the most recent upgrade, add the line

HASH_CMD=sha1sum

On Wed, Aug 30, 2017 at 11:15 AM,  wrote:

> Can't remember if I posted this before... We're getting warnings from
> rkhunterWarning: Checking for prerequisites   [ Warning ]
>All file hash checks will be skipped because:
>This system uses prelinking, but the hash function command does not
> look like SHA1 or MD5.
>
> Now, googling, I find people saying to rm /etc/prelink.cache, then run
> rkhunter --propupd.
>
> Works. And then, prelink runs in the middle of the night, via
> /etc/cron.daily, and when the cron job of rkhunter runs, it's back to
> complaining.
>
> Anyone have any ideas what's going on here? I don't see anything in the
> prelink.conf, or any options in the prelink manpage to tell is what hash
> to use.
>
>  mark
>
> ___
> 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] spice client?

[hw]

Felipe Salvador wrote:

On Wed, Aug 30, 2017 at 04:55:45PM +0200, hw wrote:


Hi,

how do I connect to a VM running on a removte machine with some
sort of spice client?  There doesn´t seem to be any spice client
available in Centos 7 that works.


virt-viewer?



That only says it´s unable to connect.

The XML-dump says:




  



I remember it was working somehow, now it doesn´t.  And I don´t remember
what client I used.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] rkhunter and prelink

[m . roth]

Can't remember if I posted this before... We're getting warnings from
rkhunterWarning: Checking for prerequisites   [ Warning ]
   All file hash checks will be skipped because:
   This system uses prelinking, but the hash function command does not
look like SHA1 or MD5.

Now, googling, I find people saying to rm /etc/prelink.cache, then run
rkhunter --propupd.

Works. And then, prelink runs in the middle of the night, via
/etc/cron.daily, and when the cron job of rkhunter runs, it's back to
complaining.

Anyone have any ideas what's going on here? I don't see anything in the
prelink.conf, or any options in the prelink manpage to tell is what hash
to use.

 mark

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

Re: [CentOS] spice client?

[milos.blazevic]

If memory serves me, spice client (i.e. spicec) is obsoleted.  
virt-viewer is now the remote viewer of choice on EL7. I'm using it  
for 8+ months now

and it's working like a charm.


Quoting hw :


Hi,

how do I connect to a VM running on a removte machine with some
sort of spice client?  There doesn´t seem to be any spice client
available in Centos 7 that works.
___
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] spice client?

[Felipe Salvador]

On Wed, Aug 30, 2017 at 04:55:45PM +0200, hw wrote:
> 
> Hi,
> 
> how do I connect to a VM running on a removte machine with some
> sort of spice client?  There doesn´t seem to be any spice client
> available in Centos 7 that works.

virt-viewer?

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

[CentOS] spice client?

[hw]

Hi,

how do I connect to a VM running on a removte machine with some
sort of spice client?  There doesn´t seem to be any spice client
available in Centos 7 that works.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] A potentially newbie question about vulnerability patching speed in CentOS 7.x's yum repository

[Pete Biggs]

> 
> 
> Same problem happens to other software packages such as:
> glibc
> tcpdump
> libnl
> mariadb
> ...
> (and many others)
> 
> 
> Why is that? and are those software packages not going to get fixed?
> 
There have been various threads concerning this in the past month. You
can find them in the archives - a couple I found by a quick scan:

 https://lists.centos.org/pipermail/centos/2017-August/165910.html

 https://lists.centos.org/pipermail/centos/2017-August/165867.html

Basically the updates build against 7.4 and that was only released to
the CR repository a week ago. See

 https://lists.centos.org/pipermail/centos/2017-August/165930.html

and

 
https://seven.centos.org/2017/08/cr-repository-for-centos-linux-7-1708-released/

It will all make it into the main repositories in due course.

Remember that CentOS is a community distro and as such resources are
limited so things don't happen immediately.  If the timing of the
release of updates is critical to you, then your best bet is to pay for
a RHEL subscription.

P.

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

Re: [CentOS] A potentially newbie question about vulnerability patching speed in CentOS 7.x's yum repository

[Fabian Arrotin]

On 30/08/17 11:09, 知乎申诉处理 wrote:
> I've been dubbing with management of security vulnerabilities and their fixes 
> for a while, recently I discovered there may be a delay in the process of 
> software updates made available on CentOS yum repository. 
> 
> 
> take CVE-2017-5335 for example:
> In redhat official notice board 
> :https://access.redhat.com/security/cve/cve-2017-5335  we can see there is a 
> link point to advisory for RHEL 7: 
> https://access.redhat.com/errata/RHSA-2017:2292 . from there we can see that 
> the fix happens at gnutls 3.3.26. 
> But when trying to update with yum update from a CentOS 7.3 x64 machine. 
> there is no 3.3.26 available. Only available rpm for CentOS 7.3.1611 for 
> x86_64 is gnutls-3.3.24.
> This result can be verified using rpm finder: 
> https://www.rpmfind.net/linux/rpm2html/search.php?query=gnutls
> 
> 
> 
> 
> Same problem happens to other software packages such as:
> glibc
> tcpdump
> libnl
> mariadb
> ...
> (and many others)
> 
> 
> Why is that? and are those software packages not going to get fixed?
> 
> 
> - p.s. please excuse me for any formating issues.  :) 
> 
> 
> Jeff

You're searching for packages that are already built but in an "interim"
repository : RHEL 7.4 was released but CentOS 7.4.1708 isn't yet
available, while packages are built (almost all of them)

See
https://seven.centos.org/2017/08/cr-repository-for-centos-linux-7-1708-released/
and you'll have all the packages you're looking for


-- 
Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] A potentially newbie question about vulnerability patching speed in CentOS 7.x's yum repository

[知乎申诉处理]

I've been dubbing with management of security vulnerabilities and their fixes 
for a while, recently I discovered there may be a delay in the process of 
software updates made available on CentOS yum repository. 


take CVE-2017-5335 for example:
In redhat official notice board 
:https://access.redhat.com/security/cve/cve-2017-5335  we can see there is a 
link point to advisory for RHEL 7: 
https://access.redhat.com/errata/RHSA-2017:2292 . from there we can see that 
the fix happens at gnutls 3.3.26. 
But when trying to update with yum update from a CentOS 7.3 x64 machine. there 
is no 3.3.26 available. Only available rpm for CentOS 7.3.1611 for x86_64 is 
gnutls-3.3.24.
This result can be verified using rpm finder: 
https://www.rpmfind.net/linux/rpm2html/search.php?query=gnutls




Same problem happens to other software packages such as:
glibc
tcpdump
libnl
mariadb
...
(and many others)


Why is that? and are those software packages not going to get fixed?


- p.s. please excuse me for any formating issues.  :) 


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