Discuss

discuss@lists.centos.org

34758 discussions

Anaconda: inst.repo doesn't work.
by dE 06 Feb '15

06 Feb '15

Although you can choose this in the installer, isnt the provided values supposed to be the default? I tired the following inst.repo=hd:/dev/sdb1:/repo Result: /dev/sdb1 is not mounted. inst.repo=nfs:[fc00::6009]:/home/auser/repo Result: NFS is not mounted even the correct ip is set by passing ip= parameters. Of course I tested the NFS share using CentOS itself. Thanks for any assistance!

2 2

Another Fedora decision
by Chris Murphy 06 Feb '15

06 Feb '15

Warren Young wyml at etr-usa.com Tue Feb 3 00:32:15 UTC 2015 > Are you telling me you cannot memorize a series of 8 characters that do > not violate those rules? Keep in mind the original context isn't for production computers, it's testing Fedora. Many testers do dozens of installs per week, some do dozens per day. The password requirement is pretty annoying, I for one haven't tested it since I worked with the first build that includes the change. Why? While ostensibly it's an 8 character minimum, pwquality is sufficiently capricious that 8 characters is frequently insufficient. I tried about a dozen times and failed, gave up, and went with an ill advised 10 character password that I forgot within 30 minutes after the installation was complete. The problem is the decision to stop innovating ways to incentivize irrational users into producing stronger passwords voluntarily, and instead bringing out boxing gloves to make everyone do it by force. It's inherently adversarial. Someone else made an analogy with the anti-immunization camp. The analogy has some fatal flaws, but one of the ways it works is the irrational reaction component. As it turns out if you call these people names, tell them it's safe, give them all the facts, they just become even more intractable because it's not even about that. Making it compulsory is likely to do the same thing and worse. The way to do it is to establish incentives. If you want your kid going to public schools of any grade, then immunization is a prerequisite. Of course it's your choice, ultimately. Good luck with private school. Here too what's going on is a lack of a mechanism to tie default services with a sufficiently acceptable password. e.g. a checkbox for sshd being enabled is grayed out, not even checkable, so long as the password is crap. Or iterate upon the basic concept which is, you get something for something, bring the user along and get them to change their behavior rather than poking them in the eyeball without any respect to the use case. Windows, OS X, iOS, Android, have much weaker password enforcement than is currently in Fedora 21 and older (and RHEL 7 and older). There's no password even required on mobile devices. I can use a 4 digit PIN to get money out of an ATM. Context, use case, and other mitigation mechanisms are relevant. And the debate is whether a stronger password requirement is really worth, e.g. having root remote login enabled by default on Fedora Server. Whereas sshd isn't enabled on Fedora Workstation. Over on Windows and OS X Servers (try not to laugh, stay on topic!), the expectation is you bring over a USB keyboard, or connect with serial or ethernet console. You opt into remote services explicitly. I’m the first to fight boneheaded “password security” schemes like a > required change every N weeks, but this is not that. Actually I put it in the category of rearranging the deck chairs. It's a debate about very weak vs weak passwords. And I think this will just cause some people to consider their less crap password to now be fair or strong. If we really want strong passwords, we're talking in the vicinity of a compulsory 20+ character password (or passphrase rather). No need to tell me how you feel about that, I'm pretty confident I can predict the response. > (Another gripe of mine: this recent trend toward using some “cloud” login > as your OS login. Apple, Microsoft, and Google are now all doing this! ) It's a good gripe, I don't like it either. However at least Apple and Microsoft have direct paths to work around this seeming requirement. I don't know about ChromeBooks, but certainly on my Android (actually cyanogen) phone I don't have to use a password at all for the phone itself, just services. > (Though, if this server will be used via SSH, it might be a good idea to > do that anyway. SSH keys — optionally with passphrases — are more secure > than even quite a long human-memorizable password. Disable password auth > and use keys.) Yes and it's under discussion to make keys compulsory by default rather than passwords for at least root remote logins. Hard to setup compared to a password. But once that's done it's actually easier to use. -- Chris Murphy

1 0

Re: [CentOS] Another Fedora decision
by Valeri Galtsev 05 Feb '15

05 Feb '15

On Thu, February 5, 2015 12:45 pm, m.roth(a)5-cent.us wrote: > Valeri Galtsev wrote: >> On Thu, February 5, 2015 10:08 am, Always Learning wrote: > <snip> >>>> I know, I know, everybody is reasonable, it is just I didn't have my >>>> coffee yet... >>> >>> Your logic is amazingly good for a coffee drinker. >>> >> No, I wasn't born here though I live here, so I don't take to my heart >> any >> jokes about people living in one of the colonies you lost ;-) Just >> stealing it from some movie I like. Still didn't have chance for my >> morning coffee yet (which I deserve: I was working hard all morning). >> Don't take me too seriously too, just get nice cup of tea (or wait till >> morning for it) ;-) > > Get in, 09:00: tea, British-strength*, w/ milk > Noon, ditto, w/ lunch. > Mid-afternoon, *strong* (not "office") coffee (Cafe Bustelo), vs. the > mid-afternoon sleepiness. Yes. Using my brother's joke, whole life is struggle: before lunch with hunger, after lunch with sleepiness... Valeri > > First full-time job, I went from 6 or so cups of office coffee to my own > mint tea in six months.... USan-born. > > mark > > * Per George Orwell's mid-forties essay: at least 4-5 min of brewing with > boiling water.** > > ** From an article in the Guardian a few months ago: "Sorry, Americans, > the teabag has to actually be *in* the mug, not merely in the room." > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++

1 0

build c7 packages for i686 using mock
by Gordon Messmer 05 Feb '15

05 Feb '15

This might be an embarrassingly simple question. How are people building multi-arch library packages on CentOS 7? On older releases one could "mock -r epel-6-i386" and "mock -r epel-6-x86_64" to build a library twice. With no 32-bit release, there's no epel-7-i386 target for mock. Specifying --target=i386 or --arch-i386 both fail. Do we have to set up the environment manually and rpm --rebuild inside the mock root?

4 5

Re: [CentOS] Another Fedora decision
by James B. Byrne 05 Feb '15

05 Feb '15

On Wed, February 4, 2015 16:55, Warren Young wrote: >> On Feb 4, 2015, at 12:16 PM, Lamar Owen <lowen(a)pari.edu> wrote: >> >> Again, the real bruteforce danger is when your /etc/shadow is >> exfiltrated by a security vulnerability > > Unless you have misconfigured your system, anyone who can copy > /etc/shadow already has root privileges. They do not need to crack > your passwords now. You are already boned. > > > My thought exactly. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@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

4 5

Re: [CentOS] Another Fedora decision
by James B. Byrne 05 Feb '15

05 Feb '15

On Wed, February 4, 2015 17:55, Warren Young wrote: > > But of course the same people fighting this move to more secure > password minima are the same ones that turn off SELinux. > Ah. Sorry, NO. First, we are not talking about a more secure password minima. We are discussing an arbitrary change made to an installer program that adversely impacts usability and that only has a tenuous connection to security on a production system. A change which assumes that people installing RHEL systems lack the competence to alter system account passwords subsequent to installation. Second, while I have serious concerns with the delusions respecting security that this fascination with 'strong' passwords evidences I do not turn off SELinux on any of my production servers. Excepting one which to date I have been unable to get to run the critical (third-party) application it hosts with SELinux switched on (short of a custom module which effectively gives http access to the whole host anyway). And that server is hardened against Internet access via other means and only runs this one application. You need to paint with a finer brush I think. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@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

1 0

Re: [CentOS] Another Fedora decision
by James B. Byrne 05 Feb '15

05 Feb '15

On Wed, February 4, 2015 17:16, Lamar Owen wrote:. > > Now, I have seen this happen, on a system in the wild, where the very > first thing the attacker did was grab a copy of /etc/shadow, even with > an interactive reverse shell and root access being had. So even when > you recover your system from the compromise you have the risk of all > those passwords being known, and unfortunately people have a habit of > using the same password on more than one system. > > Further, lists of usernames and passwords have market value. > And the arbitrary change made to Anaconda deals with this difficulty how, exactly? Look, I am neither for nor against setting arbitrary standards for user-passwords. In fact, his is what I do to generate system passwords: cat /proc/sys/kernel/random/entropy_avail 3459 openssl enc -base64 <<< $(head -c 32 /dev/random) | \ sed 's/$....$/\1:/g; s/.$//' BuRd:f8qU:yY8M:pbtO:uDlw:D53k:whW+:eJtC:z8Tc:4zlo:hiIK and discard the ':' which I provide simply to make it easier for me to read and type the damn things (once). My belief is that trust in such passwords is totally misplaced. However, if such things makes you feel comfortable (like avoiding crossing paths with a black cat or walking under ladders) then that is your affair and who am I to disagree with your choice. The change to Anaconda is not an issue because of what it is but for how it was done; arbitrarily, without community input, and without consideration of other points of view. That arrogant act was then excused under the rubric of 'increased security'. It that part which irritates me. My indulgence in raising this issue at all is to highlight the inappropriate responses that the human desire to do 'something', 'anything', no matter how pointless, so often trump considered reflective contemplation of the problems and what options are available to deal with them. I am tired of reading of so much wasteful nonsense being excused under the general heading of 'security'. And so I call people out on it now. Prove to me that any increase of cost imposed on me by your decision actually improves my security to a degree that the benefit is measurably greater than the cost. And DO NOT discount my time as having no value. If you cannot prove that then just b*gger *ff. I may have to put up with that crap for want of any viable alternative but, I am not going to nod sagely and pretend that I agree just because currently that is the socially acceptable way of receiving such professions of belief. It is BS. It has always been BS. And it will always be BS. There are no secure methods of public communication. One can only attempt to increase the expense of surveillance to the point where the value of the information received is less than the cost of getting it. If someone values it highly enough then no amount of expense is going to dissuade them and they will have it, eventually. If the cost of surveillance is cheap enough then everything will be surveyed and everyone will have access to your information. But surely, it is the choice of the parties owning the information to decide how much value it has and exactly how much expense is justified in protecting it? Access to computer systems has to considered from the point of view of eventual compromise. Is not if, it is when, you are compromised. The critical considerations are: how will you detect it; how much penetration will result from each potential point of entry before it is detected; and how much effort will it take to recover? -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@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

1 0

Re: [CentOS] Another Fedora decision
by James B. Byrne 05 Feb '15

05 Feb '15

On Tue, February 3, 2015 14:01, Valeri Galtsev wrote: > > On Tue, February 3, 2015 12:39 pm, Les Mikesell wrote: >> On Tue, Feb 3, 2015 at 12:24 PM, Valeri Galtsev >> <galtsev(a)kicp.uchicago.edu> wrote: >>> >>> Sounds so I almost have to feel shame for securing my boxes no >>> matter what job vendor did ;-) >> >> Yes, computers and the way people access them are pretty much a >> commodity now. If you are spending time building something exotic >> for a common purpose, isn't that a waste? > > Do I have to take that people who are not sysadmins themselves just > hate an existence of sysadmins? > I had a friend, now deceased, who worked as an RCA colour TV technician when he was very young. In the 1950s he would be sent to the homes of people having trouble adjusting the colour settings on their new RCA's. That was system administration then. Who needs them now? We are dinosaurs. People do not hate us. They just do not understand why we are still around. Other than lifting the display into a comfortable position for viewing the latest MacBooks cannot even be physically opened for servicing (by a user) as far as I can discover. An iPhone is a sealed unit. Both devices are orders of magnitude more powerful computers than the i486 I first installed RH on. The point Les makes is entirely correct. The systems we install should not require the degree of slavish attention to arcane details that is necessary to make them both useful and safe to use. That said, the original issue remains, making manual configuration slightly more cumbersome than it already is. That this is done solely in order to make a claim that it somehow improves security is, in my opinion, self-defeating. It is certainly a deceit. Whether it is self-delusion or overt pretence I have no idea. One might question why *nix distributions insist on providing a known point of attack to begin with. Why does user 0 have to be called root? Why not beatlebailey, cinnamon or pasdecharge? If brute forcing passwords is the problem then why not make it ever more difficult by forcing crackers to guess what the superuser name is to begin with? Oh, I know. Too much software exists that presumes that the superuser name is root. Evidently adherence to that convention is valued more highly than providing security. God forbid that one simply check for user 0. I seldom use root other than for peer-to-peer rsync via password-less login. Consequently I do not really care whether Anaconda forces me to use 32 character Base64 encoded passwords for root or none at all. I just cannot bear to stand by and read the BS about how anything of that nature improves security. It is just self-deception. Twenty years ago it might have had some validity, although I doubt it. Things that are hard to remember tend to get written down. Things that are written down tend to be read by eyes other than those that were intended. The whole matter of attending to the risk of brute force password discovery rather misses the point. Amateurs hack systems, professionals hack people. No matter how resistant your password is to brute force discovery, it only takes one careless mistake to have it revealed by an incautious or suitably deceived sysadmin. Look up 'Robin Sage' and the follow on study 'Emily Williams' and then ask yourself: How does a strong password on the root account deal with that? I really wonder sometimes if the software development people that write so much about security 'best-practice' have much of a clue about how penetrations are actually carried out. For example, how many of you have ever plugged a USB key into one of your hosts? If you have then you have permanently compromised the security of that system and nothing, short of pulling the entire USB controller, can ever undo it; and not even then I suspect. You may not, probably have not (yet), have been infected, but then you will never know for sure whether you have or not. There are so many computer control systems that are embedded in the devices we call computers that the attack surface is incomprehensibly large. And most of these embedded systems are completely open to exploitation; at the fabrication level. The Internet is not even the preferred vector. Have you ever used a USB charging station in an airport for your laptop, tablet or phone? Too bad. Have you ever plugged a personal device into one of your hosts at work via USB or Thunderbolt (not likely for the latter I admit)? Oh well. At least you can increase the strength of your root password. Is your home or business network device provided to you by your provider? Has it been changed (upgraded) recently without your request (or even with it)? I have to SSH tunnel all of my traffic on my home network now because traffic through my (recently upgraded) xxxxxx provided yyyyy router phones home to yyyyy; and I cannot stop it short of jail-breaking, which is in violation of my terms of service (AND I have to pay rent for this device). This is not paranoia, this is observed activity. (Sorry about the xxxxx yyyyy stuff, but on consideration I would rather not run the risk of being harassed by either or both of the two major corporations involved.) Sometimes I just cannot bear to think about this stuff anymore. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@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

7 11

Re: [CentOS] UC multipathd
by Rushton Martin 05 Feb '15

05 Feb '15

>-----Original Message----- >From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On >Behalf Of Alexander Dalloz >Sent: 04 February 2015 22:44 >To: CentOS mailing list >Subject: Re: [CentOS] multipathd > >Am 04.02.2015 um 15:02 schrieb Rushton Martin: >> Our cluster was supplied with two IBM DS3400 RAID arrays connected >> with fibre channel. Both are old and one is failing so we bought an >> IBM >> V3700 to replace it. The V3700 complained that we were using the >> IBM's RDAC driver (true) and we were advised to change to using Linux >> multipath. I've done that but the default configuration for the >> DS3400s > >So you switched from IBM's proprietary multipath driver to the native >Linux multipathing. Correct? Yes. We were told to do so by the suppliers of the V3700. > >> is: >> device { >> vendor IBM >> product 1726-4xx >> path_checker rdac >> features 1 queue_if_no_path >> hardware_handler 1 rdac >> prio_callout /sbin/mpath_prio_rdac /dev/%n >> no_path_retry 300 >> rr_min_io 1000 >> } > >The right settings are documented here: > >https://access.redhat.com/solutions/85223 Thanks, I shall investigate. The stanza I've used was the one that multipath itself supplies. >Yoi should be a little more specific about the conflict you see. The V3700 GUI reports: "Error 1624 : Controller configuration has unsupported RDAC mode" Attempting to run the fix results in two messages: ----%<------- Incorrect controller configuation It is detected that storage system ds3400-01 has been incorrectly configured. The storage system configuration has an unsupported RDAC mode. ----%<------- Incorrect configuration The storage system named ds3400-01 has been configured to use a failover mode called RDAC. This failover mode is not supported by the system, and will prevent the system from causing managed disks to fail over between controller A and controller B when required. Resolve this by setting the host type in the storage system configuration as defined in the IBMÂ® Storage ITE Software Configuration Guide. If available, the correct host type will be "IBM TS SAN VCE". Once the issue has been resolved, click Next to continue. The following additional information may help with correcting the problem: Storage system name: ds3400-01 WWNN (Worldwide Node Name): XX:XX:XX:XX:XX:XX:XX:XX WWPN (Worldwide Port Number): XX:XX:XX:XX:XX:XX:XX:XX Problem type : Unsupported RDAC Mode Set ----%<------- The fix then runs, but reports the same 1624 error. > >> The V3700 is still complaining and I note the "path checker rdac" and >> mpath_prio_rdac lines. Is this rdac the same as IBM's RDAC, and if so >> how can I get rid of it? > >The DS3400 is an OEM product, provided by NetApp. RDAC is the the name of >the hardware access type originally for LSI Corp controllers, later on >NetApp. > >mpath_prio_rdac is code from the Linux kernel. > >> OS is CentOS 5.3 (yes, I know - upgrade), filesystem is GPFS. > >Update! Not upgrade. That old piece of software is full of well known >severe security issues and bugs already fixed. There is not really an >excuse to not properly maintain a system. Off-net machine. Updates are non-trivial, download is over a slow broadband (between 500K and 1M) and takes well over 24 hours continuously. Then I've still got to burn or copy to transfer. >Alexander > >_______________________________________________ >CentOS mailing list >CentOS(a)centos.org >http://lists.centos.org/mailman/listinfo/centos This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. QinetiQ may monitor email traffic data and also the content of email for the purposes of security. QinetiQ Limited (Registered in England & Wales: Company Number: 3796233) Registered office: Cody Technology Park, Ively Road, Farnborough, Hampshire, GU14 0LX http://www.qinetiq.com.

1 0

Re: [CentOS] UC multipathd
by Rushton Martin 05 Feb '15

05 Feb '15

Yep, that's what I do at home. The trouble for off-net machines is the download time - over 24 hours for CentOS 7 + epel, and then copy over. If you don't grab everything, the one package you miss is the one that stops the update. :-( >-----Original Message----- >From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On >Behalf Of John R Pierce >Sent: 04 February 2015 19:01 >To: centos(a)centos.org >Subject: Re: [CentOS] multipathd > >On 2/4/2015 6:02 AM, Rushton Martin wrote: >> OS is CentOS 5.3 (yes, I know - upgrade) > >at least patch CentOS 5. 5.3 is a snapshot from 6 years ago (2009), >there've been 6 years of updates to CentOS 5 since that point, both >security and bug fixes. `yum update` would bring you up to CentOS the >.11 update plus security/bug fixes since. > > > >-- >john r pierce 37N 122W >somewhere on the middle of the left coast > >_______________________________________________ >CentOS mailing list >CentOS(a)centos.org >http://lists.centos.org/mailman/listinfo/centos This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. QinetiQ may monitor email traffic data and also the content of email for the purposes of security. QinetiQ Limited (Registered in England & Wales: Company Number: 3796233) Registered office: Cody Technology Park, Ively Road, Farnborough, Hampshire, GU14 0LX http://www.qinetiq.com.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss