Discuss

discuss@lists.centos.org

34758 discussions

Re: [CentOS] multipathd
by Alexander Dalloz 04 Feb '15

04 Feb '15

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? > 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 Yoi should be a little more specific about the conflict you see. > 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. Alexander

1 0

Re: [CentOS] multipathd
by John R Pierce 04 Feb '15

04 Feb '15

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

1 0

Re: [CentOS] Traditional network interface naming scheme vs. persistent naming
by Niki Kovacs 04 Feb '15

04 Feb '15

Le 04/02/2015 18:48, m.roth(a)5-cent.us a écrit : > That directory, and that file, exist in CentOS, also, since 6. And the new > naming... it's*so* much easier to deal with... yeah, right, I'll run the > install, and wait till it hangs, so I can see that the NIC is named, what > was it, on that HP last month, oh, yeah, I need to use ip -f inet link, > far simpler than ifconfig, yes, it's ens3f0.... > > mark "why would I*possibly* prefer a same-on-every-box eth0?"* > > * For the satire-impaired, this is satire. LOL !!! After a bit more experimenting, looks like I've found a clean solution for this. Simply create the /etc/udev/rules.d/70-persistent-net.rules file from scratch and edit it like this: # /etc/udev/rules.d/70-persistent-net.rules # # eth0 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \ ATTR{address}=="00:1e:c9:42:84:7b", ATTR{type}=="1", \ KERNEL=="eth*", NAME="eth0" # eth1 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \ ATTR{address}=="00:30:f1:6a:2f:40", ATTR{type}=="1", \ KERNEL=="eth*", NAME="eth1" Reboot, and everything's working as expected. Cheers, Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32

1 0

Traditional network interface naming scheme vs. persistent naming
by Niki Kovacs 04 Feb '15

04 Feb '15

Hi, I'm currently experimenting with CentOS 7 in order to get a grasp of everything that's new. After having read the FAQ entry on network interface names, I decided to revert to the tradictional interface naming scheme by adding the relevant kernel options to the bootloader. This went well, I have now two interfaces names 'eth0' and 'eth1' as expected. In my office I have another server with two network interface cards, running Slackware64 14.1. On a stock Slackware installation, as soon as there is more than one NIC, the system creates a file /etc/udev/rules.d/70-persistent-net.rules, which looks like this: # PCI device 0x8086:/sys/devices/pci0000:00/0000:00:02.0/0000:02:00.0 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="2c:27:d7:15:54:a1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" # PCI device 0x8086:/sys/devices/pci0000:00/0000:00:04.0/0000:03:00.0 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:64:8a:4c:c2", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" Usually I have a 50 % chance of getting the network interface right (well, according to Murphy, I have more like a 100 % chance of getting it wrong the first time :oD). In that case, I simple edit the 70-persistent-net.rules file, permutate the "eth0" and "eth1" entries and then reboot. How would I go about that under CentOS with traditional interface names? The 70-persistent-net.rules file doesn't exist. Do I have to create it from scratch? Cheers, Niki Kovacs -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32

3 2

Setting up Samba as fileserver for existing Windows domain
by Chris Adams 04 Feb '15

04 Feb '15

This is probably covered in many places, but my Google-fu is failing. I have an existing office of Windows computers, in a domain, with a couple of Windows Server 2012 AD servers. I need to add a file server, so I'd prefer to use CentOS 7 and Samba to do it (because I know very little about Windows). However, I'm not finding a good how-to on that. When I search for "samba active directory" or "samba domain", the results are mostly about setting up Samba to be the domain controller, or join an AD domain as a controller, which I don't really want to do if I don't have to. Anybody have any tips, pointers, etc.? -- Chris Adams <linux(a)cmadams.net>

3 5

multipathd
by Rushton Martin 04 Feb '15

04 Feb '15

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 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 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? OS is CentOS 5.3 (yes, I know - upgrade), filesystem is GPFS. 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

user nobody can't access file
by Tim Dunphy 04 Feb '15

04 Feb '15

Hey guys, I need to give the 'nobody' user (which is what our apache runs as) no password access to a file, via sudo. This is what I've tried: nobody ALL=(ALL) NOPASSWD: /var/www/qa/launchpadnew/site/ftp_check.php But if I become the nobody user and try to access the file, it tries to prompt me for a password: -bash-3.2$ php /var/www/qa/launchpadnew/site/ftp_check.php [sudo] password for nobody: Can someone please point out for me where I'm going wrong? Cuz I don't see it!! Thanks ! :) Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

6 5

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

03 Feb '15

I think it well to recall that the change which instigated this tempest was not to the network operations of a RHEL based system but to the 'INSTALLER' process, Anaconda. Now, I might be off base on this but really, ask yourself: Who exactly uses an installer program? And what is the threat model being addressed by requiring that the installer set a suitably strong password for root? For what purpose? Because RHEL sets the sshd on and allows root access over ssh via password by default? Then is not the correct approach to disable that access instead? But wait! Is it not true that the network services are not started by default? So, exactly where is the threat? Does it not occur much, much later in the workflow than at the installer? Would it not be more sensible to require root access to start sshd (hummmm. . . is that not a requirement now?) and to ask for the root password at that time. And then of course, you could catch those sneaky people that change the root password after the install is complete. Surly, it is when starting network services that then, and only then, one should check that one of the following conditions are true: 1.) root access over the network is disabled; 2.) root access over the network is allowed via RSA only; 3.) if root can log in via ssh using a password then the root password must be strong? That process seems like something that could be setup in a network init script, upstart system job, or systemd service file without a great deal of effort. Why does arbitrarily requiring 'strengthening' of the root password have to go into the installer program? Yes, the alternative approach would adversely impact automatic system restarts. And your point? Is not the easy answer but to disallow root access over the network entirely; or to force the use of RSA certs for root logons? Are not these far, far superior approaches to dealing with this issue than requiring a 'strong' root password everywhere, all the time, regardless of what purpose the system is used for? This change to Anaconda is not security, it is theatre. It is directly equivalent to airport passenger security checks. Totally ineffectual but so intrusive and inconvenient that we have to believe that it works. For otherwise the inescapable conclusion is that we are all fools for putting up with it; and no-one likes to think of themselves as a fool. I call this the 'Buckley's Mixture' approach to social engineering. In any case, allowing an eight character password on credentials exposed to public network access is laughable. -- *** 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 3

Kickstart setup
by Ashley M. Kirchner 03 Feb '15

03 Feb '15

Is there a way to use kickstart to boot a machine into a manual setup process? Basically what I'm getting to is this, the machine doesn't not have a CD drive in it (nor can I add one), but I can boot it via kickstart. The install media is on the network. What I'd like to do is boot this machine up and rather than have kickstart do everything for me as far as installing the OS and packages, instead present me with a manual setup (that I can get to via vnc) where I get to pick what I want or don't want on the machine. After it's all done, I'm going to go through the anaconda files and generate a base kickstart for all future installs. Does anyone have an example kickstart file I can go off of to do that?

3 4

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

03 Feb '15

On Mon, February 2, 2015 21:34, PatrickD Garvey wrote: > OK, folks. You're doing a great job of describing the current milieu > with a rough description of some best practices. > > Now how about some specific sources you personally used to learn your > craft that we can use likewise? > > PatrickD > > Go to http://www.ccc.de/en/. Visit and view some of the videos of presentations from previous congresses and hackfests. Educate yourself on the threats. Once you see what you are up against then you will have some ideas about what questions to ask. Then you can find the material you need. -- *** 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

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