Discuss February 2015

discuss@lists.centos.org

153 participants
159 discussions

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

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss February 2015