date:20170920

On 09/19/2017 05:18 AM, Sorin Srbu wrote:

-Original Message-
From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of FHDATA
Sent: den 18 september 2017 18:10
To: CentOS mailing list 
Subject: Re: [CentOS] KeePassX replacement

On Mon, 18 Sep 2017, Valeri Galtsev wrote:

You may have reasons to prefer KeePassX over KeePass 2, though.

I for one use keepassx. My password database is synchronized between
variety of systems, and I can view/edit it on: CentOS, FreeBSD, MS
Windows, Android (and should be able on any derivatives of those). I
didn't try iOS as currently I don't have a need in that.

Incidentally, does anybody know if there is any necessity in keepassx to
be patched? Did I read the original post correctly: there is no activity
on the development site for long time? Should there be any? (As, I would
say for comparison: cvs is so established software that there is no
development to expect, only if there are any security holes found those
need to be patched). Any insight on KeePassX anybody?

Valeri

hello

using keepassx probably for 10 years or so across linux,win,mac,ios

in late 2015 there was a security issue found and folks @ keepassx.org
patched it fairly  quickly and patch propagated
up to epel quickly as well ...

passwd manager {non-cloud ones} , in my opinion,
is a "static"  concept ...
unless no issues with the underlying frameworks,
what's there to patch ...

-

OT-sidetrack:

What is/are a good cloud-less password manager if I'd need it in a
cross-platform scenario;  Windows, CentOS, Ubuntu and Android?

A cloud enabled manager would be okay I guess if I could move the password
database to say my own private cloud and be able to access it from there
from all platforms.

KeepassX seemed like a good choice until I found out it didn't do Android.

Suggestions greatly appreciated!

Thanks.

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

I have installed keypass2android on my phones which should be able to use the same 
database but have not tried it to see how to actually use a password manager on a 
touchscreen device... Apparently there are also concerns about apps having 
"unlimited" access to the clipboard so one should use the keepass2android 
keyboard. Sounds like a hassle...

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

Re: [CentOS] KeePassX replacement


On 09/18/2017 11:54 AM, Valeri Galtsev wrote:

On Sat, September 16, 2017 1:45 pm, Yves Bellefeuille wrote:

H  wrote:


I have been using the KeePassX password manager on CentOS 6 and 7 for
some time and it works pretty well. On my Windows machine I use
KeePass which offers a number of features missing from KeePassX, I
also sync the database between several machines, including Android
units where I use keepass2android. Database compatibility is thus
required.

Are you aware that KeePass 2 works under Linux, with mono? There are
also ports for Android, but I've never tried them.

You may have reasons to prefer KeePassX over KeePass 2, though.

I for one use keepassx. My password database is synchronized between
variety of systems, and I can view/edit it on: CentOS, FreeBSD, MS
Windows, Android (and should be able on any derivatives of those). I
didn't try iOS as currently I don't have a need in that.

Incidentally, does anybody know if there is any necessity in keepassx to
be patched? Did I read the original post correctly: there is no activity
on the development site for long time? Should there be any? (As, I would
say for comparison: cvs is so established software that there is no
development to expect, only if there are any security holes found those
need to be patched). Any insight on KeePassX anybody?

Valeri


--
Yves Bellefeuille


___
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


I found KeePassX for Linux lacking compared to KeePass on Windows, specifically:

- It does not support references; and

- When switching keyboards, characters in the password (possibly even userid) 
are switched, almost like it is storing key codes rather than characters. Big 
annoyance for me since I need to make sure to always switch back to the US 
English keyboard when using AutoFill.

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

Re: [CentOS] KeePassX replacement


On 09/16/2017 11:25 AM, Phil Perry wrote:

On 16/09/17 16:05, Phil Perry wrote:

The only other potential issue I see is that the latest KeePassXC requires a 
newer version of libgcrypt, which the repo above packages as libgcrypt16 
(libgcrypt version 1.6.6) on el7. The release of 1.6 broke ABI compatibility 
with version 1.5 in el7. I have not tried building KeePassXC against 
libgcrypt-1.5 in el7 to know if that is viable.




I've just looked at the ABI changes, and can confirm that the latest version of 
KeePassXC uses the GCRY_CIPHER_SALSA20 cipher function added in libgcrypt-1.6, 
so users will also need to install a newer version of libgcrypt alongside 
version 1.5 in el7.

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


OK

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

Re: [CentOS] KeePassX replacement


On 09/16/2017 06:55 AM, Tom Longfield wrote:

I have been using KeePassXC (though mostly on Debian) for quite a while now and 
am happy to report it works well.  Nothing springs to mind that annoys me and 
it's a decent drop in replacement.
My setup sounds pretty similar to your own (also use keepass2android, though 
not KeePass on Windows).

I would be inclined to compile from source yourself rather than use an 
unofficial repo you have no reason to trust for such a sensitive application.

I'm not trying to besmirch the good name of copr.fedorainfracloud.org/bugzy but 
I've never heard of them and if you hadn't either that would give me pause for 
thought before I let their binaries at my passwords.

On Fri 15 Sep 2017 @ 21:43, H wrote:

I have been using the KeePassX password manager on CentOS 6 and 7 for some time 
and it works pretty well. On my Windows machine I use KeePass which offers a 
number of features missing from KeePassX, I also sync the database between 
several machines, including Android units where I use keepass2android. Database 
compatibility is thus required.

KeePassX, however, does not seem to be maintained any more, the last update was 
just a bit less than a year ago. It also has some annoying bugs, including 
where switching keyboards on the computer corrupts the username and the 
password if they include any character outside the ASCII range.

There seems to be a community fork called KeePassXC and I would like to ask if 
anyone is using this password manager? It is not in EPEL, nor in any other 
standard repository, only through an unofficial repository at 
https://copr.fedorainfracloud.org/coprs/bugzy/keepassxc/,

___
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


Ok, thanks. How does it compare feature wise with KeePass on Windows?

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

Re: [CentOS] xfs not getting it right?

2017-09-20 Thread Chris Adams

Once upon a time, hw  said:
> Are you saying there is no difference between a RAID1 and a non-raid
> device as far as xfs is concerned?

Yes.

> What if you use hardware RAID?

No difference - same result.

> When you look at [1], it tells you to specify su and sw with hardware
> RAID and says it detects everything automatically with md-RAID.  It doesn´t
> have an example with RAID1 but one with RAID10 --- however, why would that
> make a difference?

Because RAID level 1 and RAID level 10 are different.  I suggest you
read:

https://en.wikipedia.org/wiki/RAID#Standard_levels

What is called "RAID 10" is really a combination of level 1 and level 0
(which one is higher/lower varies between implementations).

> If you read from both
> disks in a RAID1 simultaneously, you have to wait out the latency of both
> disks before you get the data at full speed, and it might be better to use
> stripes with them as well and read multiple parts of the data at the same
> time.

RAID level 1 has the same data on both drives.  You wouldn't be reading
the same data from both drives at the same time; reads would be spread
between the drives (I know the Linux software RAID tries to keep read
load fairly balanced between drives, I assume most hardware RAID
implementations do the same).

> Oh, ok.  How do you know what stripe size was picked by mdadm?  It seemd a
> good idea to go with defaults as far as possible.

Again, RAID level 1 has no stripes.
-- 
Chris Adams 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Join us at CERN, October 20th, 2017

2017-09-20 Thread Rich Bowen

Please join us, one month from today, in Meyrin, Switzerland, at the
amazing CERN facility, for a day of learning and sharing.

http://cern.ch/centos

Details, schedule, and registration are at the above link.

While the event is free, you *must* register in order to gain access to
the facility, due to security requirements.

See you at CERN!

-- 
Rich Bowen - rbo...@redhat.com
RDO Community Liaison
http://rdoproject.org
@RDOCommunity
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] firefox and D state

2017-09-20 Thread Michael Hennebry


Previously when firefox went catatonic
to the point that I could not even scroll,
its CPU usage had gone to 100%+.
Now top tells me that firefox, Web Content (with a space)
or sometimes kswap... has process state D,
uninterruptable sleep.

Any suggestions on how to deal?

I often have a lot of tabs open,
so discovering the right one was hard enough before.
Usually, it was something relatively new, so that helped.
Not so much anymore.
I think a lot of it is just waiting (D) for ads or running them.

Closing and reopening sometimes works,
but then I have to go find all the video ads and stop
them one at a time.

--
Michael   henne...@web.cs.ndsu.nodak.edu
"Sorry but your password must contain an uppercase letter, a number,
a haiku, a gang sign, a heiroglyph, and the blood of a virgin."
 --  someeecards
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] owncloud on CentOS - I have problems installing/updating recently

2017-09-20 Thread Nicolas Kovacs

Le 20/09/2017 à 18:18, Valeri Galtsev a écrit :
> after quite some time of praising ownclowd, I started having problems with
> installing and updating desktop owncloud-client on CentOS. Namely, yum
> repository owncloud.org points to for rpm/yum based Linux distributions
> lives on suse.com site (well, for all flavors of Linux, actually). I
> remember it smelled fishy for me the first time I installed ownclouud on
> CentOS using that repository living at suse.com. It worked, however, for
> quite some time, but recently it just times out for me, even what
> owncloud.org currently gives as yum.repo information (which has changed
> from what was in the past).
> 
> Does anybody have any suggestion? Am I the only one (thus, making my
> "pilot error"), or others have the same? Did someone find workaround?

Hi Valeri,

I'm using OwnCloud client on my workstation and my server, both running
CentOS 7 with KDE.

I wrote a little blog article (in French) about installing and
configuring OwnCloud.

https://blog.microlinux.fr/owncloud-centos-kde/

The SUSE repository works perfectly. There has been a transition period
with overlapping dependencies in this repository and EPEL. What I did
was simply remove all packages and reinstall the owncloud-client
package. This repository is also always up-to-date, whereas the EPEL
package is regularly lagging behind.

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Web  : http://www.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] upgrade or install to Centos 7.4.1708

2017-09-20 Thread Pete Geenhuizen




On 09/20/17 10:41, Gregory P. Ennis wrote:


I upgraded from 7.3 to 7.4 over the weekend.  Everything went well
except that I can't login because the screen is black with a cursor.

If reboot boot the 7.3 kernel 3.10.0-514.26.2.el7.x86_64 kernel
everything works just fine, so my guess is that there's a kernel issue
with the hardware, specifically the Skylake processor.

Has anyone else run into this problem and if so can how I resolve the
problem other than using the previous kernel?

ASUSTeK COMPUTER INC.  Z170M-PLUS
VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz Skylake

Any help with this would be greatly appreciated.

Pete



Pete,

I have had various assortment of problems with 7.4 to the point that I
quit upgrading the rest of our PC's with 7.4 until the problems are
identified and fixed.  The only work around that I could come up with is
to use the last 7.3 os which at least made each unit usable.

As you know, most of the time these upgrades have been seamless because
the Centos team has done a wonderful job.  However, the upgrade to 7.4
has some problems, and I decided to stop the upgrade of our remaining
units until 7.4 works as well as 7.3.

Greg

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


Greg,
I've done 5 upgrades so far without any issues.  This is the first one 
that has a problem and after some experimenting it looks like the kernel 
is identifying both the analog and digital ports and making the digital 
display the primary.  I use a KVM switch and needless to say it's a 
royal pain to have to switch back and forth to accommodate this one 
host.  Like you I settled on using th3 previous perfectly working 7.3 
kernel, not optimum but it does work.


I've also decided to get a graphics card in lieu of the on-board 
graphics card in the hope that that will solve the issue with the 7.4 
kernel.


Agreed you do get used to these upgrades working seamlessly and it's a 
bummer when occasionally things don't work out exactly as planned.


Pete

--
Unencumbered by the thought process.
 -- Click and Clack the Tappet brothers


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Re: [CentOS] update to 7.4


Thanks all for the thoughts. I have no issues with 7.4 - this was clearly
"freek" accident while updating, either internet connection closed on me or
something. I brought the unit back here, I tried a few of the suggestions -
wasn't really working for me. So I just re-installed 7.4 and all was fine.

Thanks again.

Jerry

---

Jerry,

I thought I had a freek accident too, but the very same thing happened
to one of mine, actually this machine was my desktop.  For now, I am
booting using an older kernel, but will probably do a fresh install of
7.4 at a latter time. 

Greg

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

Re: [CentOS] update to 7.4

-Original Message-From: John Hodrien 
Reply-to: CentOS mailing list 
To: CentOS mailing list 
Subject: Re: [CentOS] update to 7.4
Date: Wed, 20 Sep 2017 15:59:25 +0100 (BST)

On Wed, 20 Sep 2017, Gregory P. Ennis wrote:

> This happened to me on one of the units during a 7.4 upgrade, and the only
> way for the system to work for me was to use the previous os.
>
> I tried to use the yum remove kernal 7.4 , but yum tried to remove all of
> the kernels instead of just that last one installed.  I obviously aborted
> the command.

Uninstall a specific kernel, e.g.:

yum remove kernel-3.10.0-693.2.2.el7.x86_64

> Looks like 7.4 has some major problems.

I've seen no major problems so far, having updated a fair few machines.

jh
___

John,

The machine that had the boot problem related to 7.4 would only boot
with the use of kernel-3.10.0-514.26.2.el7, when I used yum after
booting to the 7.3 kernel and I tried to remove
kernel-3.10.0-693.2.2.el7.x86_64 using the command that you recorded
above, yum presented me with a list of all the kernels instead of the
just the singular kernel-3.10.0-693.2.2.el7.x86_64; I was surprised and
aborted the process. 

Greg

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

Re: [CentOS] xfs not getting it right?

2017-09-20 Thread Fred Smith

On Wed, Sep 20, 2017 at 06:12:39PM +0200, hw wrote:
> Chris Adams wrote:
> >Once upon a time, hw  said:
> >>xfs is supposed to detect the layout of a md-RAID devices when creating the
> >>file system, but it doesn´t seem to do that:
> >>
> >>
> >># cat /proc/mdstat
> >>Personalities : [raid1]
> >>md10 : active raid1 sde[1] sdd[0]
> >>  499976512 blocks super 1.2 [2/2] [UU]
> >>  bitmap: 0/4 pages [0KB], 65536KB chunk
> >
> >RAID 1 has no "layout" (for RAID, that usually refers to striping in
> >RAID levels 0/5/6), so there's nothing for a filesystem to detect or
> >optimize for.
> 
> Are you saying there is no difference between a RAID1 and a non-raid
> device as far as xfs is concerned?

RAID1 is simply two or more drives with the same stuff on each drive.
its a simple form of redundancy. striping would put some of it on one
drive and more on another, and so forth for as many drives as you use
with some kind of redundancy or checksumming. RAID1 is much simpler:
simply make all the drives carry the same data.


> 
> What if you use hardware RAID?
> 
> When you look at [1], it tells you to specify su and sw with hardware
> RAID and says it detects everything automatically with md-RAID.  It doesn´t
> have an example with RAID1 but one with RAID10 --- however, why would that
> make a difference?  Aren´t there stripes in a RAID1?  If you read from both
> disks in a RAID1 simultaneously, you have to wait out the latency of both
> disks before you get the data at full speed, and it might be better to use

RAID1 wouldn't have that problem, necessarily. since all drives carry
the same data, it is necessary to read from only one of them. it is during
a write  operation that all drives are written, and even then they may not
be written at exactly the same time... one can be written and the data for the
other in buffer-cache until the system gets a chance to write it.

I don't know details, per the above, for Linux software raid, but I also
have a USB-attached HW raid box (jmicron chip) and I can watch the lights
on the drives and see it doing exactly that. I would find it hard to believe
that software raid in Linux is significantly different (in fact, i rather
suspect that the external raid box is probably running some older version
of Linux)
> stripes with them as well and read multiple parts of the data at the same
> time.
> 
> [1]: 
> http://xfs.org/index.php/XFS_FAQ#Q:_How_to_calculate_the_correct_sunit.2Cswidth_values_for_optimal_performance
> 
> 
> > The chunk size above is for the md-RAID write-intent bitmap; that's not
> > exposed information (for any RAID system that I'm aware of, software or
> > hardware) or something that filesystems can optimize for.
> 
> Oh, ok.  How do you know what stripe size was picked by mdadm?  It seemd a
> good idea to go with defaults as far as possible.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos

-- 
 Fred Smith -- fre...@fcshome.stoneham.ma.us -
  "For him who is able to keep you from falling and to present you before his 
 glorious presence without fault and with great joy--to the only God our Savior
 be glory, majesty, power and authority, through Jesus Christ our Lord, before
 all ages, now and forevermore! Amen."
- Jude 1:24,25 (niv) -
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] owncloud on CentOS - I have problems installing/updating recently

2017-09-20 Thread Valeri Galtsev

Dear Experts,

after quite some time of praising ownclowd, I started having problems with
installing and updating desktop owncloud-client on CentOS. Namely, yum
repository owncloud.org points to for rpm/yum based Linux distributions
lives on suse.com site (well, for all flavors of Linux, actually). I
remember it smelled fishy for me the first time I installed ownclouud on
CentOS using that repository living at suse.com. It worked, however, for
quite some time, but recently it just times out for me, even what
owncloud.org currently gives as yum.repo information (which has changed
from what was in the past).

Does anybody have any suggestion? Am I the only one (thus, making my
"pilot error"), or others have the same? Did someone find workaround?

Incidentally, another system - FreeBSD - I run on my laptop and
workstation, has no trouble with owncloudclient package. But I have to
give graduate students Linux, and prefer CentOS Linux, so I do need to
make it work even if I end up compiling it all the time myself (sigh, I
hope, not).


Thanks a lot in advance for all your help!

Valeri


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] xfs not getting it right?

2017-09-20 Thread Jon Pruente

On Wed, Sep 20, 2017 at 11:12 AM, hw  wrote:

> Are you saying there is no difference between a RAID1 and a non-raid
> device as far as xfs is concerned?
>
> What if you use hardware RAID?
>

RAID1 is mirroring. There is nothing to stripe because the virtual device
is almost identical to the physical drives, and they both see the same read
and write instructions in parallel.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] xfs not getting it right?

Chris Adams wrote:

Once upon a time, hw said:

xfs is supposed to detect the layout of a md-RAID devices when creating the
file system, but it doesn´t seem to do that:

# cat /proc/mdstat
Personalities : [raid1]
md10 : active raid1 sde[1] sdd[0]
499976512 blocks super 1.2 [2/2] [UU]
bitmap: 0/4 pages [0KB], 65536KB chunk

RAID 1 has no "layout" (for RAID, that usually refers to striping in
RAID levels 0/5/6), so there's nothing for a filesystem to detect or
optimize for.

Are you saying there is no difference between a RAID1 and a non-raid
device as far as xfs is concerned?

What if you use hardware RAID?

When you look at [1], it tells you to specify su and sw with hardware
RAID and says it detects everything automatically with md-RAID. It doesn´t
have an example with RAID1 but one with RAID10 --- however, why would that
make a difference? Aren´t there stripes in a RAID1? If you read from both
disks in a RAID1 simultaneously, you have to wait out the latency of both
disks before you get the data at full speed, and it might be better to use
stripes with them as well and read multiple parts of the data at the same
time.

[1]:
http://xfs.org/index.php/XFS_FAQ#Q:_How_to_calculate_the_correct_sunit.2Cswidth_values_for_optimal_performance

> The chunk size above is for the md-RAID write-intent bitmap; that's not
> exposed information (for any RAID system that I'm aware of, software or
> hardware) or something that filesystems can optimize for.

Oh, ok. How do you know what stripe size was picked by mdadm? It seemd a
good idea to go with defaults as far as possible.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] xfs not getting it right?

2017-09-20 Thread Chris Adams

Once upon a time, hw  said:
> I was expecting that the correct stripe size and stripe width would be used.

RAID level 1 has no stripe size or width.
-- 
Chris Adams 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] glib update problems

2017-09-20 Thread Valeri Galtsev


On Wed, September 20, 2017 10:40 am, Jason Welsh wrote:
> any idea how to get out of this pickle?
>
> [root@oem /home/jason]$yum update glibc
> Loaded plugins: product-id, rhnplugin, search-disabled-repos, security
> This system is receiving updates from RHN Classic or Red Hat Satellite.

This tells me that this system is RedHat Enterprise. So the question is
for the admin of your RedHat satellite server. This is why I at some point
decided to go with CentOS instead of RedHat Enterprise (CentOS is roughly
speaking "binary replica" of RedHat Enterprise). This way you are not
"hostage" of whatever RedHat satellite server admins do to that server,
and in an emergency you get what you need when you need without regard of
"man in the middle" - satellite server, which does its job protecting
RedHat customers, but has to be "man in the middle" which might become
evil for you under right (or wrong ;-) circumstances.

That is why someone suggested you to consider CentOS.

Valeri

> Setting up Update Process
> Resolving Dependencies
> --> Running transaction check
> ---> Package glibc.x86_64 0:2.12-1.209.el6_9.1 will be updated
> ---> Package glibc.x86_64 0:2.12-1.209.el6_9.2 will be an update
> --> Processing Dependency: glibc-common = 2.12-1.209.el6_9.2 for
> package: glibc-2.12-1.209.el6_9.2.x86_64
> --> Running transaction check
> ---> Package glibc-common.x86_64 0:2.12-1.209.el6_9.1 will be updated
> --> Processing Dependency: glibc-common = 2.12-1.209.el6_9.1 for
> package: glibc-2.12-1.209.el6_9.1.i686
> ---> Package glibc-common.x86_64 0:2.12-1.209.el6_9.2 will be an update
> --> Finished Dependency Resolution
> Error: Package: glibc-2.12-1.209.el6_9.1.i686 (@rhel-6-server-rpms)
>  Â Â Â Â Â Â Â Â Â Â  Requires: glibc-common = 2.12-1.209.el6_9.1
>  Â Â Â Â Â Â Â Â Â Â  Removing: glibc-common-2.12-1.209.el6_9.1.x86_64
> (@rhel-6-server-rpms)
>  Â Â Â Â Â Â Â Â Â Â Â Â Â Â  glibc-common = 2.12-1.209.el6_9.1
>  Â Â Â Â Â Â Â Â Â Â  Updated By: glibc-common-2.12-1.209.el6_9.2.x86_64
> (rhel6xbase)
>  Â Â Â Â Â Â Â Â Â Â Â Â Â Â  glibc-common = 2.12-1.209.el6_9.2
>  Â Â Â Â Â Â Â Â Â Â  Available: glibc-common-2.12-1.166.el6_7.8.x86_64
> (rhel6xupdates)
>  Â Â Â Â Â Â Â Â Â Â Â Â Â Â  glibc-common = 2.12-1.166.el6_7.8
> **
> yum can be configured to try to resolve such errors by temporarily
> enabling
> disabled repos and searching for missing dependencies.
> To enable this functionality please set 'notify_only=0' in
> /etc/yum/pluginconf.d/search-disabled-repos.conf
> **
>
> Error: Package: glibc-2.12-1.209.el6_9.1.i686 (@rhel-6-server-rpms)
>  Â Â Â Â Â Â Â Â Â Â  Requires: glibc-common = 2.12-1.209.el6_9.1
>  Â Â Â Â Â Â Â Â Â Â  Removing: glibc-common-2.12-1.209.el6_9.1.x86_64
> (@rhel-6-server-rpms)
>  Â Â Â Â Â Â Â Â Â Â Â Â Â Â  glibc-common = 2.12-1.209.el6_9.1
>  Â Â Â Â Â Â Â Â Â Â  Updated By: glibc-common-2.12-1.209.el6_9.2.x86_64
> (rhel6xbase)
>  Â Â Â Â Â Â Â Â Â Â Â Â Â Â  glibc-common = 2.12-1.209.el6_9.2
>  Â Â Â Â Â Â Â Â Â Â  Available: glibc-common-2.12-1.166.el6_7.8.x86_64
> (rhel6xupdates)
>  Â Â Â Â Â Â Â Â Â Â Â Â Â Â  glibc-common = 2.12-1.166.el6_7.8
>  Â You could try using --skip-broken to work around the problem
>  Â You could try running: rpm -Va --nofiles --nodigest
> [root@oem /home/jason]$
>
> Jason
>
> --
>
> ___
> 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] glib update problems

2017-09-20 Thread Christian, Mark

On Wed, 2017-09-20 at 11:40 -0400, Jason Welsh wrote:
> any idea how to get out of this pickle?
> 
> 
> Error: Package: glibc-2.12-1.209.el6_9.1.i686 (@rhel-6-server-rpms)
> Requires: glibc-common = 2.12-1.209.el6_9.1
> Removing: glibc-common-2.12-1.209.el6_9.1.x86_64 
> (@rhel-6-server-rpms)
> glibc-common = 2.12-1.209.el6_9.1
> Updated By: glibc-common-2.12-1.209.el6_9.2.x86_64 (rhel6xbase)
> glibc-common = 2.12-1.209.el6_9.2
> Available: glibc-common-2.12-1.166.el6_7.8.x86_64 
> (rhel6xupdates)
> glibc-common = 2.12-1.166.el6_7.8
>   You could try using --skip-broken to work around the problem
>   You could try running: rpm -Va --nofiles --nodigest
> [root@oem /home/jason]$
> 
> Jason
Depending on what dependencies you have, you might consider:
"yum remove glibc.i686"
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] xfs not getting it right?


Stephen John Smoogen wrote:

On 20 September 2017 at 10:47, hw  wrote:


Hi,

xfs is supposed to detect the layout of a md-RAID devices when creating the
file system, but it doesn´t seem to do that:


# cat /proc/mdstat
Personalities : [raid1]
md10 : active raid1 sde[1] sdd[0]
  499976512 blocks super 1.2 [2/2] [UU]
  bitmap: 0/4 pages [0KB], 65536KB chunk


# mkfs.xfs /dev/md10p2
meta-data=/dev/md10p2isize=512agcount=4, agsize=30199892
blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=0, sparse=0
data =   bsize=4096   blocks=120799568, imaxpct=25
 =   sunit=0  swidth=0 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal log   bsize=4096   blocks=58984, version=2
 =   sectsz=512   sunit=0 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0


# mkfs.xfs -f -d su=64m,sw=2 /dev/md10p2
meta-data=/dev/md10p2isize=512agcount=16, agsize=7553024
blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=0, sparse=0
data =   bsize=4096   blocks=120799568, imaxpct=25
 =   sunit=16384  swidth=32768 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal log   bsize=4096   blocks=58984, version=2
 =   sectsz=512   sunit=8 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0


The 64MB chunk size was picked my mdadm automatically.  The device is made
from two disks, and xfs either doesn´t figure that out, or it decided to
ignore the layout of the underlying RAID.

Am I doing something wrong here, or is xfs in Centos somehow different?
Do, or must, we always specify the apporpriate values for su and sw or
did xfs ignore them because what it picked is better?



I don't know enough to answer, but I do have a question.. what were
you expecting xfs to do (and what filesystems do that?) Thanks


I was expecting that the correct stripe size and stripe width would be used.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] glib update problems

2017-09-20 Thread Jason Welsh

ha! yes we use centos quite a bit. I was assuming (wrongly) that this 
server was one of them..


oops, my bad.


Jason


On 09/20/2017 11:44 AM, John Hodrien wrote:

On Wed, 20 Sep 2017, Jason Welsh wrote:


any idea how to get out of this pickle?


Have you considered using CentOS?

jh
___
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] glib update problems

2017-09-20 Thread John Hodrien


On Wed, 20 Sep 2017, Jason Welsh wrote:


any idea how to get out of this pickle?


Have you considered using CentOS?

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

Re: [CentOS] Block internet access for some users on the LAN ?

2017-09-20 Thread James B. Byrne


On Monday, September 18, 2017 1:04 PM, Nicolas Kovacs wrote"
>
> This year the school's director wants to completely block Internet
> access for all the student's personal devices.
>

The silent premise in this request is that all student Internet access
occurs through the school's gateway.  Which is of course false.

If the objective is to prevent misuse of school resources for
non-education purposes then the premise, while faulty, is fine.  If
the objective is to restrict students' Internet access in its entirety
then this is doomed to fail.

Have you clarified with the director that only access through your
gateway can be affected by this policy and that student devices with
cellular data plans will still have access?

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

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

[CentOS] glib update problems

2017-09-20 Thread Jason Welsh


any idea how to get out of this pickle?

[root@oem /home/jason]$yum update glibc
Loaded plugins: product-id, rhnplugin, search-disabled-repos, security
This system is receiving updates from RHN Classic or Red Hat Satellite.
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package glibc.x86_64 0:2.12-1.209.el6_9.1 will be updated
---> Package glibc.x86_64 0:2.12-1.209.el6_9.2 will be an update
--> Processing Dependency: glibc-common = 2.12-1.209.el6_9.2 for 
package: glibc-2.12-1.209.el6_9.2.x86_64

--> Running transaction check
---> Package glibc-common.x86_64 0:2.12-1.209.el6_9.1 will be updated
--> Processing Dependency: glibc-common = 2.12-1.209.el6_9.1 for 
package: glibc-2.12-1.209.el6_9.1.i686

---> Package glibc-common.x86_64 0:2.12-1.209.el6_9.2 will be an update
--> Finished Dependency Resolution
Error: Package: glibc-2.12-1.209.el6_9.1.i686 (@rhel-6-server-rpms)
   Requires: glibc-common = 2.12-1.209.el6_9.1
   Removing: glibc-common-2.12-1.209.el6_9.1.x86_64 
(@rhel-6-server-rpms)

   glibc-common = 2.12-1.209.el6_9.1
   Updated By: glibc-common-2.12-1.209.el6_9.2.x86_64 (rhel6xbase)
   glibc-common = 2.12-1.209.el6_9.2
   Available: glibc-common-2.12-1.166.el6_7.8.x86_64 
(rhel6xupdates)

   glibc-common = 2.12-1.166.el6_7.8
**
yum can be configured to try to resolve such errors by temporarily enabling
disabled repos and searching for missing dependencies.
To enable this functionality please set 'notify_only=0' in 
/etc/yum/pluginconf.d/search-disabled-repos.conf

**

Error: Package: glibc-2.12-1.209.el6_9.1.i686 (@rhel-6-server-rpms)
   Requires: glibc-common = 2.12-1.209.el6_9.1
   Removing: glibc-common-2.12-1.209.el6_9.1.x86_64 
(@rhel-6-server-rpms)

   glibc-common = 2.12-1.209.el6_9.1
   Updated By: glibc-common-2.12-1.209.el6_9.2.x86_64 (rhel6xbase)
   glibc-common = 2.12-1.209.el6_9.2
   Available: glibc-common-2.12-1.166.el6_7.8.x86_64 
(rhel6xupdates)

   glibc-common = 2.12-1.166.el6_7.8
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
[root@oem /home/jason]$

Jason

--

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

Re: [CentOS] update to 7.4

2017-09-20 Thread Jerry Geis

Thanks all for the thoughts. I have no issues with 7.4 - this was clearly
"freek" accident while updating, either internet connection closed on me or
something. I brought the unit back here, I tried a few of the suggestions -
wasn't really working for me. So I just re-installed 7.4 and all was fine.

Thanks again.

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

Re: [CentOS] update to 7.4

2017-09-20 Thread John Hodrien


On Wed, 20 Sep 2017, Gregory P. Ennis wrote:


This happened to me on one of the units during a 7.4 upgrade, and the only
way for the system to work for me was to use the previous os.

I tried to use the yum remove kernal 7.4 , but yum tried to remove all of
the kernels instead of just that last one installed.  I obviously aborted
the command.


Uninstall a specific kernel, e.g.:

yum remove kernel-3.10.0-693.2.2.el7.x86_64


Looks like 7.4 has some major problems.


I've seen no major problems so far, having updated a fair few machines.

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

Re: [CentOS] xfs not getting it right?

2017-09-20 Thread Chris Adams

Once upon a time, hw  said:
> xfs is supposed to detect the layout of a md-RAID devices when creating the
> file system, but it doesn´t seem to do that:
> 
> 
> # cat /proc/mdstat
> Personalities : [raid1]
> md10 : active raid1 sde[1] sdd[0]
>   499976512 blocks super 1.2 [2/2] [UU]
>   bitmap: 0/4 pages [0KB], 65536KB chunk

RAID 1 has no "layout" (for RAID, that usually refers to striping in
RAID levels 0/5/6), so there's nothing for a filesystem to detect or
optimize for.

The chunk size above is for the md-RAID write-intent bitmap; that's not
exposed information (for any RAID system that I'm aware of, software or
hardware) or something that filesystems can optimize for.

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

Re: [CentOS] upgrade or install to Centos 7.4.1708


Gregory P. Ennis wrote:



I upgraded from 7.3 to 7.4 over the weekend.  Everything went well
except that I can't login because the screen is black with a cursor.

If reboot boot the 7.3 kernel 3.10.0-514.26.2.el7.x86_64 kernel
everything works just fine, so my guess is that there's a kernel issue
with the hardware, specifically the Skylake processor.

Has anyone else run into this problem and if so can how I resolve the
problem other than using the previous kernel?


Hm, I didn´t connect a monitor after the upgrade, but I found that
hp-health crashes, and a core dump is created with the new kernel :(
That´s a DL380 with an x5690.

Is HP going to update their software, or is RH going to fix this?


ASUSTeK COMPUTER INC.  Z170M-PLUS
VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz Skylake

Any help with this would be greatly appreciated.

Pete



Pete,

I have had various assortment of problems with 7.4 to the point that I
quit upgrading the rest of our PC's with 7.4 until the problems are
identified and fixed.  The only work around that I could come up with is
to use the last 7.3 os which at least made each unit usable.

As you know, most of the time these upgrades have been seamless because
the Centos team has done a wonderful job.  However, the upgrade to 7.4
has some problems, and I decided to stop the upgrade of our remaining
units until 7.4 works as well as 7.3.

Greg

___
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] xfs not getting it right?

2017-09-20 Thread Stephen John Smoogen

On 20 September 2017 at 10:47, hw  wrote:
>
> Hi,
>
> xfs is supposed to detect the layout of a md-RAID devices when creating the
> file system, but it doesn´t seem to do that:
>
>
> # cat /proc/mdstat
> Personalities : [raid1]
> md10 : active raid1 sde[1] sdd[0]
>   499976512 blocks super 1.2 [2/2] [UU]
>   bitmap: 0/4 pages [0KB], 65536KB chunk
>
>
> # mkfs.xfs /dev/md10p2
> meta-data=/dev/md10p2isize=512agcount=4, agsize=30199892
> blks
>  =   sectsz=512   attr=2, projid32bit=1
>  =   crc=1finobt=0, sparse=0
> data =   bsize=4096   blocks=120799568, imaxpct=25
>  =   sunit=0  swidth=0 blks
> naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
> log  =internal log   bsize=4096   blocks=58984, version=2
>  =   sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none   extsz=4096   blocks=0, rtextents=0
>
>
> # mkfs.xfs -f -d su=64m,sw=2 /dev/md10p2
> meta-data=/dev/md10p2isize=512agcount=16, agsize=7553024
> blks
>  =   sectsz=512   attr=2, projid32bit=1
>  =   crc=1finobt=0, sparse=0
> data =   bsize=4096   blocks=120799568, imaxpct=25
>  =   sunit=16384  swidth=32768 blks
> naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
> log  =internal log   bsize=4096   blocks=58984, version=2
>  =   sectsz=512   sunit=8 blks, lazy-count=1
> realtime =none   extsz=4096   blocks=0, rtextents=0
>
>
> The 64MB chunk size was picked my mdadm automatically.  The device is made
> from two disks, and xfs either doesn´t figure that out, or it decided to
> ignore the layout of the underlying RAID.
>
> Am I doing something wrong here, or is xfs in Centos somehow different?
> Do, or must, we always specify the apporpriate values for su and sw or
> did xfs ignore them because what it picked is better?
>

I don't know enough to answer, but I do have a question.. what were
you expecting xfs to do (and what filesystems do that?) Thanks

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

Re: [CentOS] update to 7.4

On 9/19/2017 9:51 AM, Jerry Geis wrote:
> I was doing an update to 7.4 and somewhere in middle the machine died.
>
> If I drop back to a previous kernel the machine is alive. So how do I say
> "forget the previous yum update" and start all over and do it again.
>
> Booting into the new kernel I get a kernel fault. So going back one level
> on teh boot screen solves that - I just need to start the update again. How
> is that?

I think I'd try

 yum remove kernel-(broken version)
 yum update

-

This happened to me on one of the units during a 7.4 upgrade, and the
only way for the system to work for me was to use the previous os. 

I tried to use the yum remove kernal 7.4 , but yum tried to remove all
of the kernels instead of just that last one installed.  I obviously
aborted the command.

Looks like 7.4 has some major problems.

Greg

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

[CentOS] xfs not getting it right?



Hi,

xfs is supposed to detect the layout of a md-RAID devices when creating the
file system, but it doesn´t seem to do that:


# cat /proc/mdstat
Personalities : [raid1]
md10 : active raid1 sde[1] sdd[0]
  499976512 blocks super 1.2 [2/2] [UU]
  bitmap: 0/4 pages [0KB], 65536KB chunk


# mkfs.xfs /dev/md10p2
meta-data=/dev/md10p2isize=512agcount=4, agsize=30199892 blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=0, sparse=0
data =   bsize=4096   blocks=120799568, imaxpct=25
 =   sunit=0  swidth=0 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal log   bsize=4096   blocks=58984, version=2
 =   sectsz=512   sunit=0 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0


# mkfs.xfs -f -d su=64m,sw=2 /dev/md10p2
meta-data=/dev/md10p2isize=512agcount=16, agsize=7553024 blks
 =   sectsz=512   attr=2, projid32bit=1
 =   crc=1finobt=0, sparse=0
data =   bsize=4096   blocks=120799568, imaxpct=25
 =   sunit=16384  swidth=32768 blks
naming   =version 2  bsize=4096   ascii-ci=0 ftype=1
log  =internal log   bsize=4096   blocks=58984, version=2
 =   sectsz=512   sunit=8 blks, lazy-count=1
realtime =none   extsz=4096   blocks=0, rtextents=0


The 64MB chunk size was picked my mdadm automatically.  The device is made
from two disks, and xfs either doesn´t figure that out, or it decided to
ignore the layout of the underlying RAID.

Am I doing something wrong here, or is xfs in Centos somehow different?
Do, or must, we always specify the apporpriate values for su and sw or
did xfs ignore them because what it picked is better?

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

Re: [CentOS] upgrade or install to Centos 7.4.1708



I upgraded from 7.3 to 7.4 over the weekend.  Everything went well 
except that I can't login because the screen is black with a cursor.

If reboot boot the 7.3 kernel 3.10.0-514.26.2.el7.x86_64 kernel 
everything works just fine, so my guess is that there's a kernel issue 
with the hardware, specifically the Skylake processor.

Has anyone else run into this problem and if so can how I resolve the 
problem other than using the previous kernel?

ASUSTeK COMPUTER INC.  Z170M-PLUS
VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz Skylake

Any help with this would be greatly appreciated.

Pete



Pete,

I have had various assortment of problems with 7.4 to the point that I
quit upgrading the rest of our PC's with 7.4 until the problems are
identified and fixed.  The only work around that I could come up with is
to use the last 7.3 os which at least made each unit usable.

As you know, most of the time these upgrades have been seamless because
the Centos team has done a wonderful job.  However, the upgrade to 7.4
has some problems, and I decided to stop the upgrade of our remaining
units until 7.4 works as well as 7.3.

Greg

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

Re: [CentOS] selinux prevents lighttpd from printing

2017-09-20 Thread Johnny Hughes

On 09/20/2017 07:19 AM, hw wrote:
> hw wrote:
>>
>> Hi,
>>
>> how do I allow CGI programs to print (using 'lpr -P some-printer
>> some-file.pdf') when
>> lighttpd is being used for a web server?
>>
>> When selinux is permissive, the printer prints; when it´s enforcing,
>> the printer
>> does not print, and I´m getting the log message '/bin/lpr: Permission
>> denied'.
>>
>> 'getsebool -a | grep http' doesn´t show any boolean I could make out
>> to be responsible
>> for this.
>>
>> Any idea what I need to do/change to allow printing without disabling
>> selinux?
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
> 
> Nobody knows?


Look in your audit logs while in permissive mode and you should see the
issue in there, the wiki has details:

https://wiki.centos.org/HowTos/SELinux#head-798c98ef37cb8a00425a048152113b7a7dc14f1b



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

Re: [CentOS] selinux prevents lighttpd from printing