[CentOS] Public mirror synchronization failing
Hello, Our CentOS public mirror synchronization is failing since yesterday, with the log files showing the following "Permission denied" messages. It seems that my server is not able to access some of the files; any leads on to how to resolve it? rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.3PYmPD" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.7ryULv" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.8K1cYn" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.KoVhZw" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.NihJX5" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.O44pIw" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.O6PlFu" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.PFLTdf" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.PuBBXM" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.W4ppDL" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.brAhov" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.cuN3VQ" (in centos): Permission denied (13) rsync: send_files failed to open "/7.4.1708/atomic/x86_64/repo/tmp/tmp.fAEi2g" (in centos): Permission denied (13) -- *Unsub Shafiq* Inara Technologies (Pvt) Ltd. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] KeePassX replacement
> -Original Message- > From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of H > Sent: den 21 september 2017 00:35 > To: centos@centos.org > Subject: Re: [CentOS] KeePassX replacement > > 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... Incidentally a colleague suggested Lastpass. He however uses it with a YUBI-dongle though. Installed Googles Authenticator on my Android phone to test stuff, which is "sort of" a similar take as the dongle. Do any of you also use a Yubi-dongle for securing stuff like this? I feel it seems like a hassle with another gadget to keep track of. -- //Sorin ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] owncloud on CentOS - I have problems installing/updating recently
> -Original Message- > From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Nicolas > Kovacs > Sent: den 20 september 2017 18:55 > To: centos@centos.org > Subject: Re: [CentOS] owncloud on CentOS - I have problems > installing/updating recently > > > Does anybody have any suggestion? Am I the only one (thus, making my > > "pilot error"), or others have the same? Did someone find workaround? > > 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. Not just you Valeri. Thought it was a bit fishy as well, but figured I'd, as Nicolas mentions, doing a uninstall and then reinstall things might solve the problems. -- //Sorin ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 7 yum Issue
We have been following the email list discussion regarding recent problems with yum and the upgrade to the most current CentOS 7. We have also tried some of the remedies suggested or recommended. None of these measures has yielded success, and it is not totally clear whether or not our most recent yum issues have the same root cause as those experienced by others. Fortunately, our yum execution after the most recent updates came available was on one of our virtual machines. This is a CentOS 7 system running on VirtualBox and hosted on a Windows 7 system. It is typically used for verifying system updates and applications before they are introduced to regular Intel-based systems. This virtual CentOS 7 system has also been faithfully updated for over a year by using yum and accepting all updates when they become available. The truly remarkable thing is that yum does not finish with any identifiable errors. In fact it does not finish at all and seems to be in a continuous loop of some kind that has run up to ten minutes, so far. Information scrolling by seems to repeat every few seconds with the names of a set of packages repeating over and over. Many of the messages indicate package conflicts or a dependency problem of some kind. This "loop" never allows progress to the point where one would answer yes or no the to the updates. With no end in sight, we chose to kill the yum process. Shut down and restart of the current CentOS system yields a system that appears to work well with no issues related to killing the yum process. Four separate yum update sessions have been attempted, and all have been killed. All data has been backed up properly and our application reload plan is in place, with the exception of some from epel which have caused previous problems, that others have noticed recently also. Our current plan is to remove the current CentOS 7 virtual system and install the newest CentOS 7 available. We have no plans to run yum update on any other CentOS 7 systems. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] KeePassX replacement
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?
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
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
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
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
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?
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
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?
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?
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
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
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
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
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 ?
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
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
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
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?
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?
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
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
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? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [OT] CentOS, PHP & OwnCloud/Nextcloud: the version dilemma
On 09/20/17 04:42, Pete Biggs wrote: Straying OT ... On Tue, September 19, 2017 1:42 pm, Nux! wrote: Unfortunately the same can be said about Ruby, RoR, Python etc etc etc. It is not as much true about languages themselves (though it is true, and I for one call python "sneaky snake" just because of that ;-), as about Yeah, in addition to my reaction to "you're using *whitespace* as a syntax element?!", I had an early dislike of python, when each new sub-release broke things that had worked in the previous. +1 As a sysadmin/programmer I really detest using indents to denote lexical level. But when I have ever expressed such opinions I am invariably shouted down and told that it makes programming easier and I'm just an elitist nerd. And don't get me started on the incompatible point releases. That's not to say I don't indent ALL THE TIME, it certainly makes it far easier to read - don't let me get started about any HTML editor/word processor, that left justifies *completely* - but that it's a syntactic element, equivalent to semicolon in most other languages, disturbs me. Enforcing good style by compiler... mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [OT] CentOS, PHP & OwnCloud/Nextcloud: the version dilemma
Straying OT ... > > On Tue, September 19, 2017 1:42 pm, Nux! wrote: > > > Unfortunately the same can be said about Ruby, RoR, Python etc etc etc. > > > > It is not as much true about languages themselves (though it is true, and > > I for one call python "sneaky snake" just because of that ;-), as about > > > Yeah, in addition to my reaction to "you're using *whitespace* as a syntax > element?!", I had an early dislike of python, when each new sub-release > broke things that had worked in the previous. > +1 As a sysadmin/programmer I really detest using indents to denote lexical level. But when I have ever expressed such opinions I am invariably shouted down and told that it makes programming easier and I'm just an elitist nerd. And don't get me started on the incompatible point releases. P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS, PHP & OwnCloud/Nextcloud: the version dilemma
On 19 September 2017 at 21:15, wrote: > Valeri Galtsev wrote: > > > > On Tue, September 19, 2017 1:42 pm, Nux! wrote: > >> Unfortunately the same can be said about Ruby, RoR, Python etc etc etc. > > > > It is not as much true about languages themselves (though it is true, and > > I for one call python "sneaky snake" just because of that ;-), as about > > Yeah, in addition to my reaction to "you're using *whitespace* as a syntax > element?!", I had an early dislike of python, when each new sub-release > broke things that had worked in the previous. > > > For what it's worth at this time I'd use one of the PHP7 options with the upstream https://www.hogarthuk.com/?q=node/15 Getting the owncloud and nextcloud EPEL packages updated are on my to-do list, but family and work matters have limited my time in the recent months. The EPEL versions cannot go to the latest though due to the minimum PHP version jump. At this point I'd recommend you use the upstream archive (just untar/unzip it) and the most recent PHP in either IUS, remi or SCL (depending which repo you feel more comfortable with ... see my article for the differences but they are all trustworthy). James ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos