Re: [CentOS] Accidentally nuked my system - any suggestions ?

[Phil Perry]

On 05/12/2018 05:37, Nicolas Kovacs wrote:

Le 04/12/2018 à 23:50, Stephen John Smoogen a écrit :

In the rescue mode, recreate the partition table which was on the sdb
by copying over what is on sda


sfdisk –d /dev/sda | sfdisk /dev/sdb

This will give the kernel enough to know it has things to do on
rebuilding parts.


Once I made sure I retrieved all my data, I followed your suggestion,
and it looks like I'm making big progress. The system booted again,
though it feels a bit sluggish. Here's the current state of things.

[root@alphamule:~] # cat /proc/mdstat
Personalities : [raid1]
md125 : active raid1 sdb2[1] sda2[0]
   512960 blocks super 1.0 [2/2] [UU]
   bitmap: 0/1 pages [0KB], 65536KB chunk

md126 : inactive sda1[0](S)
   16777216 blocks super 1.2

md127 : active raid1 sda3[0]
   959323136 blocks super 1.2 [2/1] [U_]
   bitmap: 8/8 pages [32KB], 65536KB chunk

unused devices: 

Now how can I make my RAID array whole again? For the record, /dev/sda
is intact, and /dev/sdb is the faulty disk. How can I force
synchronization with /dev/sda?

Cheers,

Niki



If you are confident in the state of sda, I would remove sdb from the 
array, copy the partition table from sda to sdb as Stephen suggested 
earlier, then add sdb back to the array and allow the data to be synced:


For example:

mdadm --fail /dev/md125 /dev/sdb2
mdadm --remove /dev/md125 /dev/sdb2

mdadm --fail /dev/md126 /dev/sdb1
mdadm --remove /dev/md126 /dev/sdb1

mdadm --fail /dev/md127 /dev/sdb3
mdadm --remove /dev/md127 /dev/sdb3

sfdisk –d /dev/sda | sfdisk /dev/sdb

then add them back and watch then rebuild:

mdadm --add /dev/md125 /dev/sdb2
mdadm --add /dev/md126 /dev/sdb1
mdadm --add /dev/md127 /dev/sdb3

After they have all resynced, I would flush the device buffers for good 
measure. For example:


blockdev --flushbufs /dev/sdb1
...

Lastly, don't forget to reinstall grub to sdb:

grub2-install --recheck /dev/sdb

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

[CentOS] Weird problems with CentOS 7.6 1810 installer

[Nicolas Kovacs]

Hi,

I just updated my installation media for CentOS. I have a few sandbox
PCs in my office, and I'm testing CentOS 7.6 1810 on them. There seem to
be a few issues with the CentOS 7.6 1810 DVD.

Checked DVD integrity on startup : OK.

First attempt : installer froze on root password dialog.

Second attempt : installer froze on dependency calculation.

Third attempt : installer froze on network interface definition.

Similar behavior on two different machines.

On the same machine, the minimal DVD seems to work OK.

I could manage to switch to another virtual console, and I have the
following kernel log messages:

WARNING: kernel:perf: interrupt took too long

Any idea what's going on here?

I should add that all the previous CentOS 7 installation DVDs worked
perfectly on these PCs (Dell Optiplex 330).

Cheers,

Niki
-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Accidentally nuked my system - any suggestions ?

[Nicolas Kovacs]

Le 04/12/2018 à 23:50, Stephen John Smoogen a écrit :
> In the rescue mode, recreate the partition table which was on the sdb
> by copying over what is on sda
> 
> 
> sfdisk –d /dev/sda | sfdisk /dev/sdb
> 
> This will give the kernel enough to know it has things to do on
> rebuilding parts.

Once I made sure I retrieved all my data, I followed your suggestion,
and it looks like I'm making big progress. The system booted again,
though it feels a bit sluggish. Here's the current state of things.

[root@alphamule:~] # cat /proc/mdstat
Personalities : [raid1]
md125 : active raid1 sdb2[1] sda2[0]
  512960 blocks super 1.0 [2/2] [UU]
  bitmap: 0/1 pages [0KB], 65536KB chunk

md126 : inactive sda1[0](S)
  16777216 blocks super 1.2

md127 : active raid1 sda3[0]
  959323136 blocks super 1.2 [2/1] [U_]
  bitmap: 8/8 pages [32KB], 65536KB chunk

unused devices: 

Now how can I make my RAID array whole again? For the record, /dev/sda
is intact, and /dev/sdb is the faulty disk. How can I force
synchronization with /dev/sda?

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] KVM Bridge Problem

[Steven Tardy]

> Am 04.12.2018 um 21:30 schrieb Günther J. Niederwimmer:
> > Hello,
> > is this only my mistake,or can help any from the list?
> >
> > I have 3 host computer on different places, but all have the Problem when
> > starting a client "KVM" to connect to the bridge from the host.
> >
> > It is near not possible to start a client, only after 10-20
> reboot/restart
> > from the client's the network is starting correct?


KVM/Linux bridging often defaults to have spanning tree enabled which many
switches do not like.
Try creating the bridge and disable spanning tree?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Accidentally nuked my system - any suggestions ?

[Gordon Messmer]

On 12/4/18 2:31 PM, Nicolas Kovacs wrote:

Unfortunately that didn't work. The boot process stops here:
[OK] Reached target Basic System.
Now what ?



Remove "rhgb quiet" from the kernel boot args and see if you get any 
more information about what's happening.  "Reached target Basic System." 
is recorded twice in the boot logs on a system I checked a moment ago, 
so I'm not really sure where yours is stalling.



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

Re: [CentOS] Accidentally nuked my system - any suggestions ?

[Stephen John Smoogen]

On Tue, 4 Dec 2018 at 17:30, Nicolas Kovacs  wrote:
>
> Le 04/12/2018 à 23:10, Gordon Messmer a écrit :
> > The system should boot normally if you disconnect sdb.  Have you
> > tried that?
>
> Unfortunately that didn't work. The boot process stops here:
>
> [OK] Reached target Basic System.
>
> Now what ?
>
>

In the rescue mode, recreate the partition table which was on the sdb
by copying over what is on sda


sfdisk –d /dev/sda | sfdisk /dev/sdb

This will give the kernel enough to know it has things to do on
rebuilding parts.


-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Accidentally nuked my system - any suggestions ?

[Nicolas Kovacs]

Le 04/12/2018 à 23:12, mark a écrit :
> I think how I'd go about it would be to boot off a rescue disk, then 
> either try to mount the raid, or just edit the /etc/mdadm.conf, and
> tell it only sda, and maybe sdb marked as failed. Then see if you can
> mount the raid.

OK, I got a partial success that's not so bad. The bad news is that the
system won't boot even if I unplug sdb. The good news is I'm currently
retrieving my data.

Once I booted a Slax Live CD with only sda connected, I couldn't mount
it since it's a RAID member. So here's what I did.

# mdadm -Ss
# mdadm -A -R /dev/md9 /dev/sda3
# mount /dev/md9 /mnt

A peek in /mnt, seems like everything's still there. So I'm currently
transferring 300 GB of data to my server.

A word on backups. I have all the vital stuff on my server, with daily
snapshots using Rsnapshot. But all the audio and video stuff is
excluded, not to mention all my settings in Firefox, Thunderbird, etc.

Anyway: thanks very much for your help, guys.

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Accidentally nuked my system - any suggestions ?

[mark]

Nicolas Kovacs wrote:
>
> My workstation is running CentOS 7 on two disks (sda and sdb) in a
> software RAID 1 setup.
>
> It looks like I accidentally nuked it. I wanted to write an installation
> ISO file to a USB disk, and instead of typing dd if=install.iso
> of=/dev/sdc I typed /dev/sdb. As soon as I hit , the screen froze.
>
> I tried a hard reset, but of course, the boot process would stop short
> very early in the process.
>
> Now, I have backups of the important stuff of course, so no real
> catastrophe. But it would be nice if I could get back the data from my disk
> directly.
>
> I booted a rescue disk (Slax 9.6.4) and I can see my disks as well as
> raid arrays /dev/md125, /dev/md126 and /dev/md127. Oh, my partitioning
> scheme is manual and quite simple. Everything is RAID 1, I have a /boot
> array on /dev/sda1 + /dev/sdb1, swap on /dev/sda2 + /dev/sdb2 and / on
> /dev/sda3 + /dev/sdb3.
>
>
> I tried to mount /dev/sda3 directly from the rescue disk:
>
>
> # mount /dev/sda3 /mnt
>
>
> But I only get this:
>
>
> mount: unknown filesystem type 'linux_raid_member'
>
>
> I'd be very grateful for suggestions.
>
Condolences.

I think how I'd go about it would be to boot off a rescue disk, then
either try to mount the raid, or just edit the /etc/mdadm.conf, and tell
it only sda, and maybe sdb marked as failed. Then see if you can mount the
raid.

 mark



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

Re: [CentOS] Accidentally nuked my system - any suggestions ?

[Nicolas Kovacs]

Le 04/12/2018 à 23:10, Gordon Messmer a écrit :
> The system should boot normally if you disconnect sdb.  Have you
> tried that?

Unfortunately that didn't work. The boot process stops here:

[OK] Reached target Basic System.

Now what ?



-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Accidentally nuked my system - any suggestions ?

[mark]

Gordon Messmer wrote:
> On 12/4/18 2:01 PM, Nicolas Kovacs wrote:
>
>> I tried a hard reset, but of course, the boot process would stop short
>> very early in the process.
>
> The system should boot normally if you disconnect sdb.  Have you tried
> that?

Duh! thanks, Gordon, a simpler answer than mine, with the same effect,
that /dev/sdb failed as far as mdadm was concerned.

 mark

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

Re: [CentOS] Accidentally nuked my system - any suggestions ?

[Gordon Messmer]

On 12/4/18 2:01 PM, Nicolas Kovacs wrote:

I tried a hard reset, but of course, the boot process would stop short
very early in the process.



The system should boot normally if you disconnect sdb.  Have you tried that?

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

[CentOS] Accidentally nuked my system - any suggestions ?

[Nicolas Kovacs]

Hi,

My workstation is running CentOS 7 on two disks (sda and sdb) in a
software RAID 1 setup.

It looks like I accidentally nuked it. I wanted to write an installation
ISO file to a USB disk, and instead of typing dd if=install.iso
of=/dev/sdc I typed /dev/sdb. As soon as I hit , the screen froze.

I tried a hard reset, but of course, the boot process would stop short
very early in the process.

Now, I have backups of the important stuff of course, so no real
catastrophe. But it would be nice if I could get back the data from my
disk directly.

I booted a rescue disk (Slax 9.6.4) and I can see my disks as well as
raid arrays /dev/md125, /dev/md126 and /dev/md127. Oh, my partitioning
scheme is manual and quite simple. Everything is RAID 1, I have a /boot
array on /dev/sda1 + /dev/sdb1, swap on /dev/sda2 + /dev/sdb2 and / on
/dev/sda3 + /dev/sdb3.

I tried to mount /dev/sda3 directly from the rescue disk:

  # mount /dev/sda3 /mnt

But I only get this:

  mount: unknown filesystem type 'linux_raid_member'

I'd be very grateful for suggestions.

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] KVM Bridge Problem

[Alexander Dalloz]

Am 04.12.2018 um 21:30 schrieb Günther J. Niederwimmer:

Hello,
is this only my mistake,or can help any from the list?

I have 3 host computer on different places, but all have the Problem when
starting a client "KVM" to connect to the bridge from the host.

It is near not possible to start a client, only after 10-20 reboot/restart
from the client's the network is starting correct?


Logs are the only source of truth. Without them everything is pure 
speculation.



Is this  only on my computers or have other also this Problem?

Is the bridge software is broken ?


What does your system report in the relevant log files?


Can I use openvswitch to replace bridge Software?


Sure you can. It takes a bit more effort to setup openvswitch. It can be 
worth it depending on your network design.



Any help are welcome ;-)


First of all it would be necessary from your side to provide details 
about your setup. Running KVM with a bridge setup is not enough info.


Get your config sorted and the logs.

Alexander


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

[CentOS] KVM Bridge Problem

[Günther J . Niederwimmer]

Hello,
is this only my mistake,or can help any from the list?

I have 3 host computer on different places, but all have the Problem when 
starting a client "KVM" to connect to the bridge from the host.

It is near not possible to start a client, only after 10-20 reboot/restart 
from the client's the network is starting correct?

Is this  only on my computers or have other also this Problem?

Is the bridge software is broken ?

Can I use openvswitch to replace bridge Software?

Any help are welcome ;-)
 
-- 
mit freundliche Grüßen / best regards,

  Günther J. Niederwimmer


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

Re: [CentOS] [OT] EPEL update?

[Tony Molloy]

On Tue, 2018-12-04 at 12:56 -0500, Stephen John Smoogen wrote:
> On Tue, 4 Dec 2018 at 12:18, Richard  net> wrote:
> > 
> > 
> > 
> > > Date: Tuesday, December 04, 2018 17:08:52 +
> > > From: Tony Molloy 
> > > 
> > > On Mon, 2018-12-03 at 07:44 -0500, Stephen John Smoogen wrote:
> > > > On Mon, 3 Dec 2018 at 06:00, isdtor  wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > OT for this list, but maybe I can get some pointers - how
> > > > > hard is
> > > > > it to get some packages updated in EPEL? The project web site
> > > > > sends you from link to link, and the ML web interface is
> > > > > horrible. No interest here to become a package maintainer or
> > > > > regular contributor.
> > > > > 
> > > > 
> > > > If you have interest in being a package maintainer or regular
> > > > contributor it can be very hard to get packages updated. EPEL
> > > > is
> > > > trying to mainly deal with people who want long term supported
> > > > package
> > > > sets with limited manpower to do so.
> > > > 
> > > > > I have taken it upon myself to rebuild MATE from Fedora 29,
> > > > > seeing that the current EPEL-7 packages are four revisions
> > > > > behind. Also updated a few packages to their latest upstream
> > > > > version.
> > > > 
> > > > If you are needing the latest upstream versions... I would say
> > > > you
> > > > are
> > > > probably going to need to maintain these things yourself. As
> > > > much
> > > > as you want/need the latest MATE or some other item there are
> > > > other
> > > > people who don't and EPEL package maintainers can't satisfy
> > > > both
> > > > demands.
> > > > 
> > > > > 
> > > > > ___
> > > > > CentOS mailing list
> > > > > CentOS@centos.org
> > > > > https://lists.centos.org/mailman/listinfo/centos
> > > > 
> > > > 
> > > 
> > > The problem is that the current version of Mate in the EPEL repos
> > > prevents updating from 7.5 to 7.6. There is a dependency problem
> > > with libgtop.
> > > 
> > > For example trying to update marco gives you.
> > > 
> > > Resolving Dependencies
> > > --> Running transaction check
> > > ---> Package marco.x86_64 0:1.16.1-3.el7 will be installed
> > > --> Processing Dependency: libgtop-2.0.so.10()(64bit) for
> > > package:
> > > marco-1.16.1-3.el7.x86_64
> > > --> Finished Dependency Resolution
> > > Error: Package: marco-1.16.1-3.el7.x86_64 (epel)
> > >    Requires: libgtop-2.0.so.10()(64bit)
> > >  You could try using --skip-broken to work around the problem
> > > 
> > > The same dependency holds for several mate packages.
> > > 
> > > So either hold back on the update until mate is updated or build
> > > it
> > > yourself are the choices..
> > > 
> > > Regards,
> > > 
> > > Tony.
> > 
> > The epel-testing repo resolves these dependencies, so include it
> > when
> > updating and things should be ok -- I just updated a mate desktop
> > system with no issues (it pulled about half a dozen items from
> > -testing).
> 
> 
> The maintainer of the Mate packages did not push the updated packages
> to EPEL until after CentOS-7.6 was out because he did not want to
> break 7.5 users. Now that 7.6.1810 is released, it should get
> promoted
> to epel in the next couple of days.
> 
> 

Great, thanks.

Tony
> 
-- 
Tony Molloy 
Home
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [OT] EPEL update?

[Tony Molloy]

On Tue, 2018-12-04 at 09:16 -0800, Alice Wonder wrote:
> On 12/04/2018 09:08 AM, Tony Molloy wrote:
> 
> > 
> > The same dependency holds for several mate packages.
> > 
> > So either hold back on the update until mate is updated or build it
> > yourself are the choices..
> > 
> 
> Using EPEL-testing also solves the problem in many cases, might also
> be 
> able to build a temporary compat library package for old version of 
> libgtop until MATE packages are updated.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos

Yep I'm just running up a VM to test the epel-testing solution.

Regards,

Tony
-- 
Tony Molloy 
Home
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Dell server dropping packets

[Gordon Messmer]

On 12/4/18 9:12 AM, Jerry Geis wrote:

Hi All - I have a Dell R430 server running CentOS 7.5 that is dropping
packets on the network.   Its connected to Cisco switch at AUTO for the
port.



Does the switch have any logs for the port that the server is connected to?

Have you use "arping" to look for an IP address conflict on the network? 
(To test for a conflict for address 1.2.3.4 on the network attached to 
eth0, use: arping -c 2 -D -I eth0 1.2.3.4)


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

Re: [CentOS] Dell server dropping packets

[Jonathan Billings]

On Tue, Dec 04, 2018 at 12:12:25PM -0500, Jerry Geis wrote:
> Thoughts? Ideas?
> Thanks!

Did you try replacing the cable?

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

Re: [CentOS] Bastion server

[Alexander Dalloz]

Am 04.12.2018 um 09:21 schrieb Ilyass Kaouam:

. And of corse log activity users

For me,  In resume I want :
1. One acces point to all my servers
2. log activity user (login with active directory)

Regard's


Look at FreeIPA and KeyCloak. Maybe those tools do most of what you like 
to get. In addition configure the auditd service which comes by default 
with CentOS.


Alexander

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

Re: [CentOS] CR repo update disaster for my desktop.

[Phil Perry]

On 04/12/2018 09:54, Rob Kampen wrote:


So in an effort to narrow down the problem I also have an old Samsung 
laptop - i5 with an nvidia card - all up-to-date 7.5 - I thought I would 
try a more conservative upgrade approach.


first updated to the CR kernel with yum upgrade kernel*

then after successful reboot did an update to gdm* and gnome*

another reboot and all is well

then update of xorg* (only 20 files)

Now it will not boot - keyboard is non responsive so cannot even do a 
Ctrl Alt F2 to access a shell. Old kernel is also non boot. Left this 
machine for now and back to my main desktop workstation.




The only issue I've seen reported that sounds similar or possibly 
related is:


https://bugzilla.redhat.com/show_bug.cgi?id=1650634

There is a patch in that bug you might like to try.

No idea if this xorg problem relates to my original workstation - so on 
that machine I did a downgrade of xorg* - seemed to complete ok, but on 
reboot and login - still the same problem.


As the only clue in the logs is the libc segfault I did a downgrade of 
glibc - this too seemed to work but no change to the system - gnome 
crashes after 5 - 10 seconds.




I'm guessing that probably hasn't helped matters

Wasted far too much time on this, no idea what to do now so I have done 
a fresh 7.5 install and all works again - just need to install all the 
additional stuff I use each day, but at least I have a desktop that 
functions.



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

Re: [CentOS] [OT] EPEL update?

[Stephen John Smoogen]

On Tue, 4 Dec 2018 at 12:18, Richard  wrote:
>
>
>
> > Date: Tuesday, December 04, 2018 17:08:52 +
> > From: Tony Molloy 
> >
> > On Mon, 2018-12-03 at 07:44 -0500, Stephen John Smoogen wrote:
> >> On Mon, 3 Dec 2018 at 06:00, isdtor  wrote:
> >> >
> >> > Hi,
> >> >
> >> > OT for this list, but maybe I can get some pointers - how hard is
> >> > it to get some packages updated in EPEL? The project web site
> >> > sends you from link to link, and the ML web interface is
> >> > horrible. No interest here to become a package maintainer or
> >> > regular contributor.
> >> >
> >>
> >> If you have interest in being a package maintainer or regular
> >> contributor it can be very hard to get packages updated. EPEL is
> >> trying to mainly deal with people who want long term supported
> >> package
> >> sets with limited manpower to do so.
> >>
> >> > I have taken it upon myself to rebuild MATE from Fedora 29,
> >> > seeing that the current EPEL-7 packages are four revisions
> >> > behind. Also updated a few packages to their latest upstream
> >> > version.
> >>
> >> If you are needing the latest upstream versions... I would say you
> >> are
> >> probably going to need to maintain these things yourself. As much
> >> as you want/need the latest MATE or some other item there are other
> >> people who don't and EPEL package maintainers can't satisfy both
> >> demands.
> >>
> >> >
> >> > ___
> >> > CentOS mailing list
> >> > CentOS@centos.org
> >> > https://lists.centos.org/mailman/listinfo/centos
> >>
> >>
> >
> > The problem is that the current version of Mate in the EPEL repos
> > prevents updating from 7.5 to 7.6. There is a dependency problem
> > with libgtop.
> >
> > For example trying to update marco gives you.
> >
> > Resolving Dependencies
> > --> Running transaction check
> > ---> Package marco.x86_64 0:1.16.1-3.el7 will be installed
> > --> Processing Dependency: libgtop-2.0.so.10()(64bit) for package:
> > marco-1.16.1-3.el7.x86_64
> > --> Finished Dependency Resolution
> > Error: Package: marco-1.16.1-3.el7.x86_64 (epel)
> >Requires: libgtop-2.0.so.10()(64bit)
> >  You could try using --skip-broken to work around the problem
> >
> > The same dependency holds for several mate packages.
> >
> > So either hold back on the update until mate is updated or build it
> > yourself are the choices..
> >
> > Regards,
> >
> > Tony.
>
> The epel-testing repo resolves these dependencies, so include it when
> updating and things should be ok -- I just updated a mate desktop
> system with no issues (it pulled about half a dozen items from
> -testing).


The maintainer of the Mate packages did not push the updated packages
to EPEL until after CentOS-7.6 was out because he did not want to
break 7.5 users. Now that 7.6.1810 is released, it should get promoted
to epel in the next couple of days.



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Dell server dropping packets

[Stephen John Smoogen]

On Tue, 4 Dec 2018 at 12:13, Jerry Geis  wrote:
>
> Hi All - I have a Dell R430 server running CentOS 7.5 that is dropping
> packets on the network.   Its connected to Cisco switch at AUTO for the
> port.  The server reports 1000M on the network. I even changed the setting
> for the switch to 1000M full, that did not seem to make a difference either.
>

I don't think that FULL/AUTO would have a difference on gigabit
networks that it did with 10/100MBit. When I have seen packet losses
on gigabit it has been STP related where the system  and the switch
keep negotiating spanning tree and stuff just goes poof. The other one
is where a second system says it has the same ip address because some
service is being 'helpful' in failover mode.. but that is less likely
here.


> What else might I look at as to why its dropping packets? Its mainly 90'ish
> percent idle. so not doing much at this time. I have no idea what else is
> happening on the network.
>
> I set a windows box on the same network and just did a "ping" to the server
> and once in a while it lost the packets or my putty connection dropped
> etc...
>
> Thoughts? Ideas?
> Thanks!
>
> Jerry
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [OT] EPEL update?

[Richard]

> Date: Tuesday, December 04, 2018 17:08:52 +
> From: Tony Molloy 
>
> On Mon, 2018-12-03 at 07:44 -0500, Stephen John Smoogen wrote:
>> On Mon, 3 Dec 2018 at 06:00, isdtor  wrote:
>> > 
>> > Hi,
>> > 
>> > OT for this list, but maybe I can get some pointers - how hard is
>> > it to get some packages updated in EPEL? The project web site
>> > sends you from link to link, and the ML web interface is
>> > horrible. No interest here to become a package maintainer or
>> > regular contributor.
>> > 
>> 
>> If you have interest in being a package maintainer or regular
>> contributor it can be very hard to get packages updated. EPEL is
>> trying to mainly deal with people who want long term supported
>> package
>> sets with limited manpower to do so.
>> 
>> > I have taken it upon myself to rebuild MATE from Fedora 29,
>> > seeing that the current EPEL-7 packages are four revisions
>> > behind. Also updated a few packages to their latest upstream
>> > version.
>> 
>> If you are needing the latest upstream versions... I would say you
>> are
>> probably going to need to maintain these things yourself. As much
>> as you want/need the latest MATE or some other item there are other
>> people who don't and EPEL package maintainers can't satisfy both
>> demands.
>> 
>> > 
>> > ___
>> > CentOS mailing list
>> > CentOS@centos.org
>> > https://lists.centos.org/mailman/listinfo/centos
>> 
>> 
> 
> The problem is that the current version of Mate in the EPEL repos
> prevents updating from 7.5 to 7.6. There is a dependency problem
> with libgtop.
> 
> For example trying to update marco gives you.
> 
> Resolving Dependencies
> --> Running transaction check
> ---> Package marco.x86_64 0:1.16.1-3.el7 will be installed
> --> Processing Dependency: libgtop-2.0.so.10()(64bit) for package:
> marco-1.16.1-3.el7.x86_64
> --> Finished Dependency Resolution
> Error: Package: marco-1.16.1-3.el7.x86_64 (epel)
>    Requires: libgtop-2.0.so.10()(64bit)
>  You could try using --skip-broken to work around the problem
> 
> The same dependency holds for several mate packages.
> 
> So either hold back on the update until mate is updated or build it
> yourself are the choices..
> 
> Regards,
> 
> Tony.

The epel-testing repo resolves these dependencies, so include it when
updating and things should be ok -- I just updated a mate desktop
system with no issues (it pulled about half a dozen items from
-testing).





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

Re: [CentOS] [OT] EPEL update?

[Alice Wonder]

On 12/04/2018 09:08 AM, Tony Molloy wrote:



The same dependency holds for several mate packages.

So either hold back on the update until mate is updated or build it
yourself are the choices..



Using EPEL-testing also solves the problem in many cases, might also be 
able to build a temporary compat library package for old version of 
libgtop until MATE packages are updated.

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

[CentOS] Dell server dropping packets

[Jerry Geis]

Hi All - I have a Dell R430 server running CentOS 7.5 that is dropping
packets on the network.   Its connected to Cisco switch at AUTO for the
port.  The server reports 1000M on the network. I even changed the setting
for the switch to 1000M full, that did not seem to make a difference either.

What else might I look at as to why its dropping packets? Its mainly 90'ish
percent idle. so not doing much at this time. I have no idea what else is
happening on the network.

I set a windows box on the same network and just did a "ping" to the server
and once in a while it lost the packets or my putty connection dropped
etc...

Thoughts? Ideas?
Thanks!

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

Re: [CentOS] [OT] EPEL update?

[Tony Molloy]

On Mon, 2018-12-03 at 07:44 -0500, Stephen John Smoogen wrote:
> On Mon, 3 Dec 2018 at 06:00, isdtor  wrote:
> > 
> > Hi,
> > 
> > OT for this list, but maybe I can get some pointers - how hard is
> > it to get some packages updated in EPEL? The project web site sends
> > you from link to link, and the ML web interface is horrible. No
> > interest here to become a package maintainer or regular
> > contributor.
> > 
> 
> If you have interest in being a package maintainer or regular
> contributor it can be very hard to get packages updated. EPEL is
> trying to mainly deal with people who want long term supported
> package
> sets with limited manpower to do so.
> 
> > I have taken it upon myself to rebuild MATE from Fedora 29, seeing
> > that the current EPEL-7 packages are four revisions behind. Also
> > updated a few packages to their latest upstream version.
> 
> If you are needing the latest upstream versions... I would say you
> are
> probably going to need to maintain these things yourself. As much as
> you want/need the latest MATE or some other item there are other
> people who don't and EPEL package maintainers can't satisfy both
> demands.
> 
> > 
> > ___
> > CentOS mailing list
> > CentOS@centos.org
> > https://lists.centos.org/mailman/listinfo/centos
> 
> 

The problem is that the current version of Mate in the EPEL repos
prevents updating from 7.5 to 7.6. There is a dependency problem with
libgtop.

For example trying to update marco gives you.

Resolving Dependencies
--> Running transaction check
---> Package marco.x86_64 0:1.16.1-3.el7 will be installed
--> Processing Dependency: libgtop-2.0.so.10()(64bit) for package:
marco-1.16.1-3.el7.x86_64
--> Finished Dependency Resolution
Error: Package: marco-1.16.1-3.el7.x86_64 (epel)
   Requires: libgtop-2.0.so.10()(64bit)
 You could try using --skip-broken to work around the problem

The same dependency holds for several mate packages.

So either hold back on the update until mate is updated or build it
yourself are the choices..

Regards,

Tony.

> 
-- 
Tony Molloy 
Home
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CR repo update disaster for my desktop.

[Jonathan Billings]

On Tue, Dec 04, 2018 at 10:54:58PM +1300, Rob Kampen wrote:
> So in an effort to narrow down the problem I also have an old Samsung laptop
> - i5 with an nvidia card - all up-to-date 7.5 - I thought I would try a more
> conservative upgrade approach.
> 
> first updated to the CR kernel with yum upgrade kernel*
> 
> then after successful reboot did an update to gdm* and gnome*
> 
> another reboot and all is well
> 
> then update of xorg* (only 20 files)
> 
> Now it will not boot - keyboard is non responsive so cannot even do a Ctrl
> Alt F2 to access a shell. Old kernel is also non boot. Left this machine for
> now and back to my main desktop workstation.

Where does it stop booting?  Can you remove 'rhgb quiet' from the
kernel command line and see how it is booting?  Also, are you using
UEFI boot or the old BIOS boot?

> I will wait until 7.6 is officially released, watch the list for a week or
> two and then with much fear and trepidation give it a go. 

7.6 has been released, so you should expect these packages to start
arriving on all your CentOS 7 systems.


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

Re: [CentOS] Centos-release src rpm.

[Johnny Hughes]

On 12/4/18 8:25 AM, m...@tdiehl.org wrote:
> Hi,
> 
> Any chance someone (Johnny?) could point me towards the latest
> centos-release
> src rpm?
> 
> Regards,
> 

https://buildlogs.centos.org/c7.1810.00.x86_64/centos-release/20181123131556/7-6.1810.2.el7.centos.x86_64/





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

[CentOS-docs] [Gitblit] rbowen pushed 1 commits => websites/centos.org.git

[Gitblit]

https://git.centos.org/summary/websites!centos.org.git

>---
 master branch updated (1 commits)
>---

 rbowen 
 Tuesday, December 4, 2018 15:34 +

 ornl dojo

 
https://git.centos.org/commit/websites!centos.org.git/f449f771f271c09b1fab2708bbe75e52b460c3e4
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs

Re: [CentOS] CR repo update disaster for my desktop.

[Simon Matter]

> On 4/12/18 9:06 AM, Rob Kampen wrote:
>> Sorry for top post, my android BlueMail will not let me insert at the
>> bottom.
>>
>> I have found that tracker-extract seems to trigger a segfault. I note
>> this is not updated in CR, but comes from base. Removal of tracker seems
>> too harsh as it has dependant modules like brasero, evince, grilo,
>> nautilus and totem.
>> Maybe there is an obscure relationship in tracker that need attention.
>> Stumpped.
>>
>> ⁣Sent from BlueMail ​
>>
>> On 03 Dec 2018, 11:28 PM, at 11:28 PM, Fabian Arrotin
>>  wrote:
>>> On 03/12/2018 11:14, John Hodrien wrote:
 On Mon, 3 Dec 2018, Simon Matter wrote:

>> Le 03/12/2018 à 06:25, Rob Kampen a écrit :
>>> I enabled the CR repo and did the yum update. Some 800+ rpms were
>>> offered and all seemed to resolve depenancies OK, so yes it was
>>> started. The updates completed and all looked good, until the
>>> reboot.
>> I got a similar disaster here. I guess the lesson to be learned is
>>> that
>> CR is nice to have on servers, but don't use it on desktops.
> My question is what will change with the final release of 7.6? I
>>> thought
> the CR repo usually holds all updates with the exception of
> centos-release, or are there more updates to come? I had the
>>> impression
> that in the past, the final release brought only cosmetic changes
>>> with
> the
> centos-release being updated.
 I've seen zero problems on Desktops I've installed CR on.

 If CR has issues, as you say you'd expect 7.6 to have problems.  If
 things are
 failing with CR updates, you really want to investigate what's going
>>> on.
 jh
>>> +1 as 7.6.1810 is exactly 7.5.1804+updates+CR so only missing packages
>>> are centos-release/anaconda and install tree/media ..
>>>
>>> So if there are issues with CR, using the list and bugs.centos.org
>>> would
>>> be good.
>>> BTW : the goal of CR is exactly to find those issues earlier and then
>>> write Release Notes with workarounds/warnings
>
> So in an effort to narrow down the problem I also have an old Samsung
> laptop - i5 with an nvidia card - all up-to-date 7.5 - I thought I would
> try a more conservative upgrade approach.
>
> first updated to the CR kernel with yum upgrade kernel*
>
> then after successful reboot did an update to gdm* and gnome*
>
> another reboot and all is well
>
> then update of xorg* (only 20 files)
>
> Now it will not boot - keyboard is non responsive so cannot even do a
> Ctrl Alt F2 to access a shell. Old kernel is also non boot. Left this
> machine for now and back to my main desktop workstation.
>
> No idea if this xorg problem relates to my original workstation - so on
> that machine I did a downgrade of xorg* - seemed to complete ok, but on
> reboot and login - still the same problem.
>
> As the only clue in the logs is the libc segfault I did a downgrade of
> glibc - this too seemed to work but no change to the system - gnome
> crashes after 5 - 10 seconds.
>
> Wasted far too much time on this, no idea what to do now so I have done
> a fresh 7.5 install and all works again - just need to install all the
> additional stuff I use each day, but at least I have a desktop that
> functions.
>
> I will wait until 7.6 is officially released, watch the list for a week
> or two and then with much fear and trepidation give it a go. 
>
> As a long time user of CentOS (well over a decade - I started with 5.x
> workstations, then had a couple of 6.x, and used two 7.x machines, not
> counting my servers), I must observe that the core server stuff "just
> works" e.g. mail, mysql / mariadb, postfix, dovecot, apache, php. Even
> the migration to libreoffice was okay.
>
> The major version upgrades each gave an all over better desktop
> experience. What has also happened however is that some of the 7.x
> upgrades have been difficult to deal with - one of the recent firefox
> updates lost all my local password databases which I do not back up to
> the cloud for obvious reasons. Unable to resolve the instability after
> many hours of testing and trialing combinations, I have left firefox and
> moved to vivaldi - we'll see how that works. As upstream seems to
> include more bleeding edge versions of major desktop utilities such as
> firefox, stability has been compromised.
>
> Now with this latest CR update, I have no idea if it is gnome, gdm, xorg
> or some other component, but to have two quite differently configured
> machines both loose their desktops, I am unhappy. The use of roll back
> of over 800 files just didn't pass the transaction test thus that too
> was futile.
>
> I thought the approach I used with my laptop today was sufficiently
> cautious, yet it caught me and I am still trying to work out what to do
> next.
>
> As always, happy to entertain ideas and suggestions. My main workstation
> however is now safely working at a clean install of 7.5, thus cannot do
> further tests there, life must go on, four days of 

Re: [CentOS] Centos-release src rpm.

[John R. Dennison]

On Tue, Dec 04, 2018 at 09:25:31AM -0500, m...@tdiehl.org wrote:
> Hi,
> 
> Any chance someone (Johnny?) could point me towards the latest centos-release
> src rpm?

Until the SRPMs are pushed to vault.centos.org you can get the same
packages that are on the ISOs / mirrors from buildlogs.centos.org.  Do
note, however, that these packages are not signed.






John
-- 
I begin by taking.  I shall find scholars later to demonstrate my perfect right.

-- Euripides (c 480 BC - 406 BC), Greek playwright, Suppliants


pgpLB0pnKCDod.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos-release src rpm.

[Phil Wyett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 2018-12-04 at 09:25 -0500, m...@tdiehl.org wrote:
> Hi,
> 
> Any chance someone (Johnny?) could point me towards the latest centos-release
> src rpm?
> 
> Regards,
> 

Hi,

The source rpm files will appear on: vault.centos.org in due course.
Alternatively you can book out code and build the source rpm files yourself
from: git.centos.org.

Regards

Phil

- -- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

IRC: kathenas

Web: https://kathenas.org

Github: https://github.com/kathenas

GitLab: https://gitlab.com/kathenas

Twitter: kathenasorg

GPG: A0C3 4C6A AC2B B8F4 F1E5 EDF4 333F 60DC B0B9 BB77
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJcBpXlAAoJEDM/YNywubt3f6QP/3b6iPFYQAHufp0kE+oWBDe4
OeEi0Cl4Ll7ts9+6459rP6PwdwPsqN8YglaCS3z977zGF1kcEovhasQK6ANnk2eh
Arv2TAVOaU8l1mesoigDPDSys9o2nL/XobYbTKMbL3jsymc5LkFZ+eEfow4pdKBA
EsmUVnQgZOxWJcCLe5t/XL5Ne33NR41oPYPgqNH2prs4WCbzU2xzn89sHLk1pwf0
NhpVrMH8E5J8VtyAK20o/971JJvlgD/4P3Yz10fNzi5RLMMtcxWM0uI5lFk5VVa6
cUaH+Hz1NS7rfrNGpknvJybwYk+zt8f4iv1Fw5h4wpHlX3izonmrxRQvDjs0f9zC
bQZhtv+sHk6MYmmYbX1JphuZSOTJhqJyZIkTEn/wSttVAuSTX7p1W9UQH+P7AMvt
lr2mfbYSTcSDGD9bTeBsXgimJoC7bbMcYyN1iKgyb6fhn4lrTd1O2F1VNSwrlho3
Ocq+/5jJM0snOpX+7TngA8PWrCCOSuhvWHGS0MYluSauaANN241NRmxbmiqeB3bs
Sell/RIr7PGF9s+qlYaun+yEvTdV1ktvNYEhovN5N4BKQXmZpa1l0KNK7k6ZVU/C
BD/acia/dW8Kx1egKzjhG8lmhEqcL5UndgFD/tg/1m1W04bzMDAT6Vd/o4DiHm7x
dtybD2WozX08GAy5/FcG
=uBkz
-END PGP SIGNATURE-

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

[CentOS] Centos-release src rpm.

[me]

Hi,

Any chance someone (Johnny?) could point me towards the latest centos-release
src rpm?

Regards,

--
Tom m...@tdiehl.org
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Update failure: Mate requires libgtop-2.0.so.10

[Jason Edgecombe]

In addition, there is a bugzilla report for this:
https://bugzilla.redhat.com/show_bug.cgi?id=1644519
---
Jason Edgecombe | Linux Administrator
UNC Charlotte | The William States Lee College of Engineering
9201 University City Blvd. | Charlotte, NC 28223-0001
Phone: 704-687-1943
jwedg...@uncc.edu | http://engr.uncc.edu |  Facebook
---
If you are not the intended recipient of this transmission or a person
responsible for delivering it to the intended recipient, any disclosure,
copying, distribution, or other use of any of the information in this
transmission is strictly prohibited. If you have received this transmission
in error, please notify me immediately by reply e-mail or by telephone at
704-687-1943.  Thank you.


On Mon, Dec 3, 2018 at 9:53 PM Richard 
wrote:

>
>
> > Date: Monday, December 03, 2018 20:41:20 -0600
> > From: Frank Cox 
> >
> > I just tried updating this laptop to the shiny new Centos version
> > and it appears that Mate doesn't like the new version of libgtop,
> > as you can see here:
> >
> > Error: Package: marco-1.16.1-3.el7.x86_64 (@epel)
> >Requires: libgtop-2.0.so.10()(64bit)
> >Removing: libgtop2-2.34.2-2.el7.x86_64 (@base)
> >libgtop-2.0.so.10()(64bit)
> >Updated By: libgtop2-2.38.0-3.el7.x86_64 (base)
> >   ~libgtop-2.0.so.11()(64bit)
> > Error: Package: mate-applets-1.16.0-1.el7.x86_64 (@epel)
> >Requires: libgtop-2.0.so.10()(64bit)
> >Removing: libgtop2-2.34.2-2.el7.x86_64 (@base)
> >libgtop-2.0.so.10()(64bit)
> >Updated By: libgtop2-2.38.0-3.el7.x86_64 (base)
> >   ~libgtop-2.0.so.11()(64bit)
> > Error: Package: mate-disk-usage-analyzer-1.16.1-1.el7.x86_64 (@epel)
> >Requires: libgtop-2.0.so.10()(64bit)
> >Removing: libgtop2-2.34.2-2.el7.x86_64 (@base)
> >libgtop-2.0.so.10()(64bit)
> >Updated By: libgtop2-2.38.0-3.el7.x86_64 (base)
> >   ~libgtop-2.0.so.11()(64bit)
> > Error: Package: mate-system-monitor-1.16.0-1.el7.x86_64 (@epel)
> >Requires: libgtop-2.0.so.10()(64bit)
> >Removing: libgtop2-2.34.2-2.el7.x86_64 (@base)
> >libgtop-2.0.so.10()(64bit)
> >Updated By: libgtop2-2.38.0-3.el7.x86_64 (base)
> >   ~libgtop-2.0.so.11()(64bit)
>
>
> Updated versions of those @epel packages are in the epel-testing
> repo, which resolved this issue for me when I updated using the CR
> repo a couple of weeks ago.
>
>
> ___
> 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] Unable to load dynamic library 'twig.so'

[Richard]

> Date: Tuesday, December 04, 2018 14:12:11 +0100
> From: Ilyass Kaouam 
>
> I have this problem.
> 
> Ca you please help me :
> 
>  php -v
> PHP Warning:  PHP Startup: Unable to load dynamic library 'twig.so'
> (tried: /usr/lib64/php/modules/twig.so
> (/usr/lib64/php/modules/twig.so: undefined symbol:
> zval_used_for_init), /usr/lib64/php/modules/twig.so.so
> (/usr/lib64/php/modules/twig.so.so: cannot open shared object file:
> No such file or directory))

You'll find twig.so in the epel repository (for both centos 6 and 7).




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

[CentOS-docs] [Gitblit] arrfab pushed 1 commits => websites/centos.org.git

[Gitblit]

https://git.centos.org/summary/websites!centos.org.git

>---
 master branch updated (1 commits)
>---

 Fabian Arrotin 
 Tuesday, December 4, 2018 13:19 +

 Redirecting docs to new website. Fixed some links to https

 
https://git.centos.org/commit/websites!centos.org.git/76672dc69a7c91b282d945d28fadf610954e4339
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs

[CentOS] Unable to load dynamic library 'twig.so'

[Ilyass Kaouam]

I have this problem.

Ca you please help me :

 php -v
PHP Warning:  PHP Startup: Unable to load dynamic library 'twig.so' (tried:
/usr/lib64/php/modules/twig.so (/usr/lib64/php/modules/twig.so: undefined
symbol: zval_used_for_init), /usr/lib64/php/modules/twig.so.so
(/usr/lib64/php/modules/twig.so.so: cannot open shared object file: No such
file or directory)) in Unknown on line 0
PHP 7.2.11 (cli) (built: Oct 11 2018 19:14:35) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.2.11, Copyright (c) 1999-2018, by Zend Technologies


-- 
*Ilyass kaouam*
*Ingénieur System OpenSource*
*Mastère européen Manager de Projets Informatiques*
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS-announce Digest, Vol 166, Issue 1

[centos-announce-request]

Send CentOS-announce mailing list submissions to
centos-annou...@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."


Today's Topics:

   1. Release for CentOS Linux 7 (1810) on the x86_64   Architecture
  (Johnny Hughes)
   2. Release for CentOS Linux 7 (1810) on aarch64 i386 ppc64le and
  power9 (Pablo Sebasti?n Greco)
   3. Release for CentOS Linux 7 (1810) on armhfp
  (Pablo Sebasti?n Greco)


--

Message: 1
Date: Mon, 3 Dec 2018 09:18:22 -0600
From: Johnny Hughes 
To: CentOS-Announce 
Subject: [CentOS-announce] Release for CentOS Linux 7 (1810) on the
x86_64  Architecture
Message-ID: <1cf9af45-fd45-b32e-0aea-eae0ff996...@centos.org>
Content-Type: text/plain; charset="utf-8"

We are pleased to announce the general availability of CentOS Linux 7
(1810) for the x86_64 architecture. Effectively immediately, this
is the current release for CentOS Linux 7 and is tagged as 1810, derived
from Red Hat Enterprise Linux 7.6 Source Code.

As always, read through the Release Notes at :
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7 - these notes
contain important information about the release and details about some
of the content inside the release from the CentOS QA team. These notes
are updated constantly to include issues and incorporate feedback from
the users.

--
Updates, Sources, and DebugInfos

Updates released since the upstream release are all posted, across all
architectures. We strongly recommend every user apply all updates,
including the content released today, on your existing CentOS Linux 7
machine by just running 'yum update'.

As with all CentOS Linux 7 components, this release was built from
sources hosted at git.centos.org. In addition, SRPMs that are a
byproduct of the build (and also considered critical in the code and
buildsys process) are being published to match every binary RPM we
release. Sources will be available from vault.centos.org in their own
dedicated directories to match the corresponding binary RPMs. Since
there is far less traffic to the CentOS source RPMs compared with the
binary RPMs, we are not putting this content on the main mirror
network. If users wish to mirror this content they can do so using the
reposync command available in the yum-utils package. All CentOS source
RPMs are signed with the same key used to sign their binary
counterparts. Developers and end users looking at inspecting and
contributing patches to the CentOS Linux distro will find the code
hosted at git.centos.org far simpler to work against. Details on how
to best consume those are documented along with a quick start at :
http://wiki.centos.org/Sources

Debuginfo packages are also being signed and pushed. Yum configs
shipped in the new release file will have all the context required for
debuginfo to be available on every CentOS Linux install.

This release supersedes all previously released content for CentOS
Linux 7, and therefore we highly encourage all users to upgrade their
machines. Information on different upgrade strategies and how to
handle stale content is included in the Release Notes.

Note that older content, obsoleted by newer versions of the same
applications are trim'd off from repos like Extras/ and Plus/ However
this time we have also extended this to the SIG content hosted at
mirror.centos.org, and some older End of Life content has been dropped.
Everything we ever release, is always available on the vault service for
people still looking for and have a real need for it.

--
Download

In order to conserve donor bandwidth, and to make it possible to get
the mirror content sync'd out as soon as possible, we recommend using
torrents to get your initial installer images:

Details on the images are available on the mirrors at
http://mirror.centos.org/centos/7/isos/x86_64/0_README.txt - that file
clearly highlights the difference in the images, and when one might be
more suitable than the others.

sha256sum x86_64:
3213b2c34cecbb3bb817030c7f025396b658634c0cf9c4435fc0b52ec9644667?
CentOS-7-x86_64-LiveGNOME-1810.iso

38d5d51d9d100fd73df031ffd6bd8b1297ce24660dc8c13a3b8b4534a4bd291c?
CentOS-7-x86_64-Minimal-1810.iso

6d44331cc4f6c506c7bbe9feb8468fad6c51a88ca1393ca6b8b486ea04bec3c1?
CentOS-7-x86_64-DVD-1810.iso

87623c8ab590ad0866c5f5d86a2d7ed631c61d69f38acc42ce2c8ddec65ecea2?
CentOS-7-x86_64-LiveKDE-1810.iso

918975cdf947e858c9a0c77d6b90a9a56d9977f3a4496a56437f46f46200cf71?
CentOS-7-x86_64-Everything-1810.iso

19d94274ef856c4dfcacb2e7cfe4be73e442a71dd65cc3fb6e46db826040b56e?

Re: [CentOS] DNS bind - use of /etc/named directory

[J Martin Rushton via CentOS]

On 04/12/18 09:41, John Horne wrote:
> On Tue, 2018-12-04 at 08:19 +, J Martin Rushton via CentOS wrote:
>> The '/etc/named.conf.rpmnew' file supplied is a bare minimum to
>> "configure the ... server as a caching only nameserver (as a localhost
>> DNS resolver only)".  As soon as you start adding any structure to it
>> things change, not just are added to.  See
>> '/usr/share/doc/bind-*/sample/etc/named.conf' for example.  Probably the
>> biggest "gotcha" is that as soon as you use _any_ views you MUST use
>> views for _all_ zones.
>>
>> If you were to move the default '/etc/named.conf.rpmnew' to
>> '/etc/named.conf' and add an 'include "/etc/named/*";', line as you
>> suggest, you would be building problems for the future.  Let's say you
>> dropped in 'internal.conf' which had a simple 'view "internal" stanza -
>> then your root hints, localhost, localhost IPV6 and reverse localhosts
>> would disappear.  Just what you wouldn't want at 00:51 !
>>
>> What you can do safely is to include the zone definitions in a separate
>> file (see '/etc/named.rfc1912.zones' for example) and include that file.
>>  Doing things this way means that your main configuration file can be
>> written to either use views or not, and to just include your zone
>> definitions in the appropriate place.  See the sample file for an example.
>>
> Thanks for the reply.
> 
> However, we don't use views and the local settings are not for zones. We do
> currently have a separate zone file, but again that requires an 'include' in
> the main '/etc/named.conf'. If a local settings file (in '/etc/named') could 
> be
> used, then we would simply 'include' the zone file in that. Ultimately, the
> main named.conf file would remain untouched.
> 
> John.
> 
Since I don't know your particular configuration, the above was of
necessity rather general.  That though is the point, the default named
installation has to be generic and cover everything from a basic
installation up to a major cluster with multiple networks.  I suspect
that in your case there will be no advance on diff(1) and vi(1)!

Regards,
Martin


>>
>> On 04/12/18 00:51, John Horne wrote:
>>> Hello,
>>>
>>> For many years we have modified the '/etc/named.conf' file to include local
>>> settings. The disadvantage with this is of course that when bind is
>>> updated, it
>>> creates an '/etc/named.conf.rpmnew' file. We then have to determine what is
>>> new, and apply the relevant changes to our modified named.conf file.
>>>
>>> There is, however, an '/etc/named' directory which I assumed was for local
>>> configuration settings. The main '/etc/named.conf' file makes no mention of
>>> this directory, so (I suspect) any config files in '/etc/named' would, by
>>> default, just be ignored.
>>>
>>> As far as I can tell we could put our local configuration settings into a
>>> file
>>> in '/etc/named', but we would then, once again, have to modify
>>> '/etc/named.conf' to tell it to include config files in '/etc/named'. We
>>> would
>>> then be back at square one in that any bind update would create an 'rpmnew'
>>> file.
>>>
>>> I admit I haven't actually tested this, but has anyone used the
>>> '/etc/named'
>>> directory and not had to modify the main '/etc/named.conf' file?
>>>
>>> I suspect, if not, then this should be raised as a possible bug since it
>>> would
>>> make sense not to have to modify the main configuration file at all.
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> John.
>>>
>>> --
>>> John Horne | Senior Operations Analyst | Technology and Information
>>> Services
>>> University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
>>> 
>>> [
>>> http://www.plymouth.ac.uk/images/email_footer.gif]>>
>>> This email and any files with it are confidential and intended solely for
>>> the use of the recipient to whom it is addressed. If you are not the
>>> intended recipient then copying, distribution or other use of the
>>> information contained is strictly prohibited and you should not rely on it.
>>> If you have received this email in error please let the sender know
>>> immediately and delete it from your system(s). Internet emails are not
>>> necessarily secure. While we take every care, University of Plymouth
>>> accepts no responsibility for viruses and it is your responsibility to scan
>>> emails and their attachments. University of Plymouth does not accept
>>> responsibility for any changes made after it was sent. Nothing in this
>>> email or its attachments constitutes an order for goods or services unless
>>> accompanied by an official order form.
>>> ___
>>> 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
> --
> John Horne | Senior Operations Analyst | 

Re: [CentOS] CR repo update disaster for my desktop.

[Rob Kampen]

On 4/12/18 9:06 AM, Rob Kampen wrote:

Sorry for top post, my android BlueMail will not let me insert at the bottom.

I have found that tracker-extract seems to trigger a segfault. I note this is 
not updated in CR, but comes from base. Removal of tracker seems too harsh as 
it has dependant modules like brasero, evince, grilo, nautilus and totem.
Maybe there is an obscure relationship in tracker that need attention.
Stumpped.

⁣Sent from BlueMail ​

On 03 Dec 2018, 11:28 PM, at 11:28 PM, Fabian Arrotin  wrote:

On 03/12/2018 11:14, John Hodrien wrote:

On Mon, 3 Dec 2018, Simon Matter wrote:


Le 03/12/2018 à 06:25, Rob Kampen a écrit :

I enabled the CR repo and did the yum update. Some 800+ rpms were
offered and all seemed to resolve depenancies OK, so yes it was
started. The updates completed and all looked good, until the

reboot.

I got a similar disaster here. I guess the lesson to be learned is

that

CR is nice to have on servers, but don't use it on desktops.

My question is what will change with the final release of 7.6? I

thought

the CR repo usually holds all updates with the exception of
centos-release, or are there more updates to come? I had the

impression

that in the past, the final release brought only cosmetic changes

with

the
centos-release being updated.

I've seen zero problems on Desktops I've installed CR on.

If CR has issues, as you say you'd expect 7.6 to have problems.  If
things are
failing with CR updates, you really want to investigate what's going

on.

jh

+1 as 7.6.1810 is exactly 7.5.1804+updates+CR so only missing packages
are centos-release/anaconda and install tree/media ..

So if there are issues with CR, using the list and bugs.centos.org
would
be good.
BTW : the goal of CR is exactly to find those issues earlier and then
write Release Notes with workarounds/warnings


So in an effort to narrow down the problem I also have an old Samsung 
laptop - i5 with an nvidia card - all up-to-date 7.5 - I thought I would 
try a more conservative upgrade approach.


first updated to the CR kernel with yum upgrade kernel*

then after successful reboot did an update to gdm* and gnome*

another reboot and all is well

then update of xorg* (only 20 files)

Now it will not boot - keyboard is non responsive so cannot even do a 
Ctrl Alt F2 to access a shell. Old kernel is also non boot. Left this 
machine for now and back to my main desktop workstation.


No idea if this xorg problem relates to my original workstation - so on 
that machine I did a downgrade of xorg* - seemed to complete ok, but on 
reboot and login - still the same problem.


As the only clue in the logs is the libc segfault I did a downgrade of 
glibc - this too seemed to work but no change to the system - gnome 
crashes after 5 - 10 seconds.


Wasted far too much time on this, no idea what to do now so I have done 
a fresh 7.5 install and all works again - just need to install all the 
additional stuff I use each day, but at least I have a desktop that 
functions.


I will wait until 7.6 is officially released, watch the list for a week 
or two and then with much fear and trepidation give it a go. 


As a long time user of CentOS (well over a decade - I started with 5.x 
workstations, then had a couple of 6.x, and used two 7.x machines, not 
counting my servers), I must observe that the core server stuff "just 
works" e.g. mail, mysql / mariadb, postfix, dovecot, apache, php. Even 
the migration to libreoffice was okay.


The major version upgrades each gave an all over better desktop 
experience. What has also happened however is that some of the 7.x 
upgrades have been difficult to deal with - one of the recent firefox 
updates lost all my local password databases which I do not back up to 
the cloud for obvious reasons. Unable to resolve the instability after 
many hours of testing and trialing combinations, I have left firefox and 
moved to vivaldi - we'll see how that works. As upstream seems to 
include more bleeding edge versions of major desktop utilities such as 
firefox, stability has been compromised.


Now with this latest CR update, I have no idea if it is gnome, gdm, xorg 
or some other component, but to have two quite differently configured 
machines both loose their desktops, I am unhappy. The use of roll back 
of over 800 files just didn't pass the transaction test thus that too 
was futile.


I thought the approach I used with my laptop today was sufficiently 
cautious, yet it caught me and I am still trying to work out what to do 
next.


As always, happy to entertain ideas and suggestions. My main workstation 
however is now safely working at a clean install of 7.5, thus cannot do 
further tests there, life must go on, four days of down time is far too 
much.


Also let me give a heartfelt thanks to the hard working CentOS team, I 
see the more and more difficult task you need to navigate with each 
major update, you do an outstanding task, and I am most grateful!




--
Fabian Arrotin
The 

Re: [CentOS] DNS bind - use of /etc/named directory

[John Horne]

On Tue, 2018-12-04 at 08:19 +, J Martin Rushton via CentOS wrote:
> The '/etc/named.conf.rpmnew' file supplied is a bare minimum to
> "configure the ... server as a caching only nameserver (as a localhost
> DNS resolver only)".  As soon as you start adding any structure to it
> things change, not just are added to.  See
> '/usr/share/doc/bind-*/sample/etc/named.conf' for example.  Probably the
> biggest "gotcha" is that as soon as you use _any_ views you MUST use
> views for _all_ zones.
>
> If you were to move the default '/etc/named.conf.rpmnew' to
> '/etc/named.conf' and add an 'include "/etc/named/*";', line as you
> suggest, you would be building problems for the future.  Let's say you
> dropped in 'internal.conf' which had a simple 'view "internal" stanza -
> then your root hints, localhost, localhost IPV6 and reverse localhosts
> would disappear.  Just what you wouldn't want at 00:51 !
>
> What you can do safely is to include the zone definitions in a separate
> file (see '/etc/named.rfc1912.zones' for example) and include that file.
>  Doing things this way means that your main configuration file can be
> written to either use views or not, and to just include your zone
> definitions in the appropriate place.  See the sample file for an example.
>
Thanks for the reply.

However, we don't use views and the local settings are not for zones. We do
currently have a separate zone file, but again that requires an 'include' in
the main '/etc/named.conf'. If a local settings file (in '/etc/named') could be
used, then we would simply 'include' the zone file in that. Ultimately, the
main named.conf file would remain untouched.



John.

>
> On 04/12/18 00:51, John Horne wrote:
> > Hello,
> >
> > For many years we have modified the '/etc/named.conf' file to include local
> > settings. The disadvantage with this is of course that when bind is
> > updated, it
> > creates an '/etc/named.conf.rpmnew' file. We then have to determine what is
> > new, and apply the relevant changes to our modified named.conf file.
> >
> > There is, however, an '/etc/named' directory which I assumed was for local
> > configuration settings. The main '/etc/named.conf' file makes no mention of
> > this directory, so (I suspect) any config files in '/etc/named' would, by
> > default, just be ignored.
> >
> > As far as I can tell we could put our local configuration settings into a
> > file
> > in '/etc/named', but we would then, once again, have to modify
> > '/etc/named.conf' to tell it to include config files in '/etc/named'. We
> > would
> > then be back at square one in that any bind update would create an 'rpmnew'
> > file.
> >
> > I admit I haven't actually tested this, but has anyone used the
> > '/etc/named'
> > directory and not had to modify the main '/etc/named.conf' file?
> >
> > I suspect, if not, then this should be raised as a possible bug since it
> > would
> > make sense not to have to modify the main configuration file at all.
> >
> >
> >
> >
> > Thanks,
> >
> > John.
> >
> > --
> > John Horne | Senior Operations Analyst | Technology and Information
> > Services
> > University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
> > 
> > [
> > http://www.plymouth.ac.uk/images/email_footer.gif] > >
> >
> > This email and any files with it are confidential and intended solely for
> > the use of the recipient to whom it is addressed. If you are not the
> > intended recipient then copying, distribution or other use of the
> > information contained is strictly prohibited and you should not rely on it.
> > If you have received this email in error please let the sender know
> > immediately and delete it from your system(s). Internet emails are not
> > necessarily secure. While we take every care, University of Plymouth
> > accepts no responsibility for viruses and it is your responsibility to scan
> > emails and their attachments. University of Plymouth does not accept
> > responsibility for any changes made after it was sent. Nothing in this
> > email or its attachments constitutes an order for goods or services unless
> > accompanied by an official order form.
> > ___
> > 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
--
John Horne | Senior Operations Analyst | Technology and Information Services
University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK

[http://www.plymouth.ac.uk/images/email_footer.gif]

This email and any files with it are confidential and intended solely for the 
use of the recipient to whom it is addressed. If you are not the intended 
recipient then copying, distribution or other use of the 

Re: [CentOS] Bastion server

[Ilyass Kaouam]

Hi,

Thank for all your reply,

here the details of the product :

https://www.wallix.com/en/access-manager/

• Customizable admin portal: Fully customize the design of your
administrative portal. Determine how it classifies files, and how files are
transferred between workstations and targeted Windows sources. Plus,
quickly communicate with different target Bastions via the encrypted https
channel.

• Authentication: In addition to traditional “directory” authentications,
ACCESS MANAGER supports SAML 2.0 and integrates with all infrastructures
that utilize identity federation mechanisms.

• Multi-tenant architecture & scalability: Ensure that your organization is
secure even when using multi-tenant architecture. If a resource can be
accessed through several Bastions, you can define and create active Bastion
clusters for a clear visualization of exactly what resources are accessible
by multiple Bastions.

• Audit and compliance: In addition to the standard Bastion functionality,
the ACCESS MANAGER has its own audit functions, providing an unalterable
audit trail of all the sessions it has authorized. The audit log includes a
multi-criteria search engine which facilitates searches within script and
session metadata and has the capability to fully replay sessions for
further review.

. And of corse log activity users

For me,  In resume I want :
1. One acces point to all my servers
2. log activity user (login with active directory)

Regard's

Le lun. 3 déc. 2018 à 18:24, Gordon Messmer  a
écrit :

> On 12/2/18 11:34 AM, Ilyass Kaouam wrote:
> > Thank you for your reply
> > Chère mort détails About wallix
> > https://www.wallix.com/en/
>
>
> The problem here is that all of the details of what the product *does*
> seems to require requesting a demo or watching videos, and at that point
> I think you're asking too much of the community.  If you describe what
> you are trying to do, we can try to help.  But, please be mindful of how
> much time you're asking people to voluntarily spend on your request.
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
*Ilyass kaouam*
*Ingénieur System OpenSource*
*Mastère européen Manager de Projets Informatiques*
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] DNS bind - use of /etc/named directory

[J Martin Rushton via CentOS]

The '/etc/named.conf.rpmnew' file supplied is a bare minimum to
"configure the ... server as a caching only nameserver (as a localhost
DNS resolver only)".  As soon as you start adding any structure to it
things change, not just are added to.  See
'/usr/share/doc/bind-*/sample/etc/named.conf' for example.  Probably the
biggest "gotcha" is that as soon as you use _any_ views you MUST use
views for _all_ zones.

If you were to move the default '/etc/named.conf.rpmnew' to
'/etc/named.conf' and add an 'include "/etc/named/*";', line as you
suggest, you would be building problems for the future.  Let's say you
dropped in 'internal.conf' which had a simple 'view "internal" stanza -
then your root hints, localhost, localhost IPV6 and reverse localhosts
would disappear.  Just what you wouldn't want at 00:51 !

What you can do safely is to include the zone definitions in a separate
file (see '/etc/named.rfc1912.zones' for example) and include that file.
 Doing things this way means that your main configuration file can be
written to either use views or not, and to just include your zone
definitions in the appropriate place.  See the sample file for an example.

HTH,

Martin

On 04/12/18 00:51, John Horne wrote:
> Hello,
> 
> For many years we have modified the '/etc/named.conf' file to include local
> settings. The disadvantage with this is of course that when bind is updated, 
> it
> creates an '/etc/named.conf.rpmnew' file. We then have to determine what is
> new, and apply the relevant changes to our modified named.conf file.
> 
> There is, however, an '/etc/named' directory which I assumed was for local
> configuration settings. The main '/etc/named.conf' file makes no mention of
> this directory, so (I suspect) any config files in '/etc/named' would, by
> default, just be ignored.
> 
> As far as I can tell we could put our local configuration settings into a file
> in '/etc/named', but we would then, once again, have to modify
> '/etc/named.conf' to tell it to include config files in '/etc/named'. We would
> then be back at square one in that any bind update would create an 'rpmnew'
> file.
> 
> I admit I haven't actually tested this, but has anyone used the '/etc/named'
> directory and not had to modify the main '/etc/named.conf' file?
> 
> I suspect, if not, then this should be raised as a possible bug since it would
> make sense not to have to modify the main configuration file at all.
> 
> 
> 
> 
> Thanks,
> 
> John.
> 
> --
> John Horne | Senior Operations Analyst | Technology and Information Services
> University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
> 
> [http://www.plymouth.ac.uk/images/email_footer.gif]
> 
> This email and any files with it are confidential and intended solely for the 
> use of the recipient to whom it is addressed. If you are not the intended 
> recipient then copying, distribution or other use of the information 
> contained is strictly prohibited and you should not rely on it. If you have 
> received this email in error please let the sender know immediately and 
> delete it from your system(s). Internet emails are not necessarily secure. 
> While we take every care, University of Plymouth accepts no responsibility 
> for viruses and it is your responsibility to scan emails and their 
> attachments. University of Plymouth does not accept responsibility for any 
> changes made after it was sent. Nothing in this email or its attachments 
> constitutes an order for goods or services unless accompanied by an official 
> order form.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
> 

-- 
J Martin Rushton MBCS



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