Discuss January 2017

discuss@lists.centos.org

125 participants
118 discussions

Mate and USB headphones
by Alice Wonder 07 Jan '17

07 Jan '17

Logitech H540 headphones were working fine. Suddenly stopped. Sound Preferences says they are disabled but gives no hints on how to enable them, or how they became disabled. Tried rebooting, unplugging them, etc. Anyone know what is going on? This motherboard doesn't have onboard sound, this USB is my only option. And GNOME simply isn't usable for me, I used GNOME for years but GNOME 3 literally gets in my way all the freaking time trying to force me to do things the new way that just aren't conductive to my thinking style - so MATE is what I use. I have no clue how these headphones became "disabled" or how to change them back to enabled.

3 4

gmail.com rejection of e-mail on a Centos 6 sendmail server related to reverse ipv6 lookups
by Gregory P. Ennis 07 Jan '17

07 Jan '17

Everyone, I have been working on a gmail.com rejection of mail problem related to one of our CentOS 6 mail servers, that was not present on our Centos 7 mail server. At first I just routed the transfer of mail to the Centos 7 sever and the problem was solved, but continued working on the Centos 6 sendmail problem when I had time available. I finally had some time to debug the problem and found some interesting things that I thought of which others may benefit. The following represents the steps I took as well as my own conclusions that may or may not be correct, but I did find a fix to the problem. It was interesting that this problem does not exist for the sendmail of Centos 7, but it did exist for the sendmail of Centos 6. My setup for both sendmail.mc files for 6 and 7 were almost the same. It turns out that the sendmail of Centos 6 and 7 apparently using ipv6 as the default transmission of mail, if ipv6 is not available on Centos 7 it drops back to ipv4, but it does not drop back to ipv4 in Centos 6. Also apparently google does a reverse record lookup on ipv6 connection, and if there is a mismatch then google fails the transfer. I was able to get this far by putting in a debug value of 29 in sendmail.mc and then comparing logs created on our Centos 6 and Centos 7 server. I tried to turn off ipv6 on sendmail.mc on the Centos 6 server by the use of the switch : DAEMON_OPTIONS(`Name=MTA-v4, Family=inet') Unfortunately, this prevented the transfer of all mail so I removed it from sendmail.mc. Further looking at other posts on the internet seems to indicate that sendmail now requires ipv6 to be active to transfer any mail at all. I found the following post that described a fix to the problem. http://serverfault.com/questions/512615/how-to-stop-sendmail-sending-ma il-from-ipv6-instead-of-ipv4/824833#824833 When I added the following with '1.2.3.4' being the ipv4 address of the Centos 6 server that had the problem, the mail to gmail.com worked perfectly. CLIENT_OPTIONS(`Family=inet6,Addr=::ffff:1.2.3.4')dnl If any of the rest of you have had this difficulty I hope this helps. Greg Ennis

1 0

CDB tables in Centos7 Postfix ?
by Tim Smith 07 Jan '17

07 Jan '17

Hi, It seems the default binaries don't have CDB tables compiled into them ? Now, I know Centos isn't Ubuntu, but on Ubuntu there is an optional package in the main distribution "postfix-cdb - CDB map support for Postfix". I can't find anything similar using "yum search", so I'm guessing that's not an option. Unless anyone else here corrects me otherwise, I'm guessing it's back to 'old-school' compile and install myself ? Thanks ! Tim

3 4

sshd problem on reboot
by Alessandro Baggi 07 Jan '17

07 Jan '17

Hi list, I have a dedicated server managed through ssh and this morning I have upgraded my system from 7.2 to 7.3. After yum finished his work, and rebooted my server. After reboot I tried to log in with ssh and got "Connection refused". I've noticed that all public services were online. So I've contacted my provider to get access to the server and I've noticed that ssh was started with my specified port. I've tried to log locally on server and I got connection refused. So I've ridden logs and got: error: bind to port MYPORT in LOCALIP failed: cannot assign requested address. I've restarted sshd and problem "was solved". Now I can't try to replicate this error because I can't reboot the server. My addressing config is: Port PORT AddressFamily inet ListenAddress LOCALIP ListenAddress 127.0.0.1 #ListenAddress :: What can cause this problem? Thanks in advance.

2 1

kickstart problems since 7.3
by Gordon Messmer 06 Jan '17

06 Jan '17

I just tried a kickstart setup for the first time since 7.3 and got an error similar to the error in this unresolved Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1278260 Has anyone successfully done a kickstart setup using 7.3 on x86_64? I'd imagine this is part of QA, so the answer is almost certainly "yes," but I'm not sure where to start debugging this. I got a working system by supplying the URL to the 7.2 release instead of the current URL.

2 2

Strange (?) device.map in CentOS 7 VM installations
by Nikolaos Milas 06 Jan '17

06 Jan '17

Hello, After repeated failing efforts to restore CentOS 7 backups (taken using mondorescue software), I have found that all my CentOS 7 installations (VMs under KVM) have the same /boot/grub2/device.map, which seemingly refers to two HDs, although the VMs in fact include only one (virtual) HD. For example: /boot/grub2/device.map # this device map was generated by anaconda (hd0) /dev/vda (hd1) /dev/vda Here is the hardware of the VM: # parted -l Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/centos-swap: 2147MB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0.00B 2147MB 2147MB linux-swap(v1) Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/centos-root: 18.8GB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0.00B 18.8GB 18.8GB xfs Model: Virtio Block Device (virtblk) Disk /dev/vda: 21.5GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 525MB 524MB primary xfs boot 2 525MB 21.5GB 20.9GB primary lvm This is NOT the case with my CentOS 5 and CentOS 6 VMs, which all have a "correct" device map, with a single (hda0) entry. Is the above behavior expected? If not, what should be the expected way of operation and what may be the cause of it? I am trying to understand where something may be going wrong, so please help. Many Thanks! Nick

5 8

mlx4_0 Initializing and... (infiniband)
by lejeczek 06 Jan '17

06 Jan '17

... Initializing.. hi all, I've a a very basic setup, directly two boxes via two MHEH28-XTC and I cannot activate them. One peculiar thing is I get (randomly & !often): [85947.090496] AMD-Vi: Event logged [ [85947.090539] IO_PAGE_FAULT device=09:00.7 domain=0x0000 address=0x00000000f6ffb000 flags=0x0050] [85947.298509] AMD-Vi: Event logged [ [85947.298550] IO_PAGE_FAULT device=09:00.7 domain=0x0000 address=0x00000000f6ffb000 flags=0x0050] which is the card itself, judging by the device id Would you have and share some thoughts please? $ ./flint/mstflint -d 09:00.0 q # for both cards -W- Running quick query - Skipping full image integrity checks. Image type: FS2 FW Version: 2.9.1000 Device ID: 25408 Description: Node Port1 Port2 Sys image GUIDs: 0008f104039a62a0 0008f104039a62a1 0008f104039a62a2 0008f104039a62a3 MACs: 000000000000 000000000001 VSD: PSID: MT_04A0110001 $ ibstat CA 'mlx4_0' CA type: MT25408 Number of ports: 2 Firmware version: 2.9.1000 Hardware version: a0 Node GUID: 0x0008f104039a08dc System image GUID: 0x0008f104039a08df Port 1: State: Initializing Physical state: LinkUp Rate: 10 Base lid: 1 LMC: 0 SM lid: 1 Capability mask: 0x0259086a Port GUID: 0x0008f104039a08dd Link layer: InfiniBand Port 2: State: Down Physical state: Polling Rate: 10 Base lid: 0 LMC: 0 SM lid: 0 Capability mask: 0x0259086a Port GUID: 0x0008f104039a08de Link layer: InfiniBand in opensm log: Jan 06 17:00:28 817185 [F6D5A700] 0x01 -> sm_mad_ctrl_send_err_cb: ERR 3113: MAD completed in error (IB_TIMEOUT): SubnGet(NodeInfo), attr_mod 0x0, TID 0x1cd1 Jan 06 17:00:28 817200 [F6D5A700] 0x01 -> sm_mad_ctrl_send_err_cb: ERR 3120 Timeout while getting attribute 0x11 (NodeInfo); Possible mis-set mkey?

1 0

does your kdump work?
by lejeczek 06 Jan '17

06 Jan '17

hi all mine does not, and I've tampered with it in many ways, cannot get it to work. best, L.

1 0

Firefox Issue
by Chris Olson 06 Jan '17

06 Jan '17

Everyone is back at work and starting to use computers on our smallest network which has Internet access through a rather old Linksys router. Two systems were left on and screen-locked over the extra long weekend. There does not appear to have been any Internet access interruption in our absence. A Firefox browser on one system was left pointing to a commonly used web site: https://www.yahoo.com/. This Yahoo web page was not displayed when the user unlocked the screen and brought up the browser from the task bar. Instead, a site located at the link https://gaibacoupontec.com was displayed with a message indicating that there was an urgent Firefox update required. There was a button to download and to install the update. I killed the Firefox browser rather than getting rid of it with the X in the upper right hand corner. This event has the aroma of an unwanted cyber intrusion, which is why I killed the browser. I have also copied and stored the full URL displayed in the browser, but have only included the first part "https://gaibacoupontec.com" here so as not to tempt anyone to risk access. Is it possible that a new Firefox flaw has been detected and is being exploited for malicious purposes?

6 5

OpenSCAP failures to to OS version?
by Noam Bernstein 05 Jan '17

05 Jan '17

Hi - I’m running the OpenSCAP STIG profile on a new CentOS 7.1611 installation, and I get a few failures that look like this (output from openscap scan —verbosity INFO). I suspect this is because the openscap module is not accepting CentOS 7 as RHEL 7 for rules purposes, despite an early check for "Community Enterprise Operating System 7” which succeeds. 1. Am I correct in why it’s failing? 2. Is this a bug, or an accepted behavior given that CentOS isn’t actually RHEL? Noam I: oscap: Evaluating XCCDF rule 'accounts_password_pam_retry'. I: oscap: Evaluating definition 'oval:org.open-scap.cpe.rhel:def:7': Red Hat Enterprise Linux 7. I: oscap: Definition 'oval:org.open-scap.cpe.rhel:def:7' evaluated as false. I: oscap: Evaluating definition 'oval:org.open-scap.cpe.rhel:def:1007': Community Enterprise Operating System 7. I: oscap: Definition 'oval:org.open-scap.cpe.rhel:def:1007' evaluated as true. I: oscap: Adding external variable oval:ssg-var_password_pam_retry:var:1. I: oscap: Evaluating definition 'oval:ssg-accounts_password_pam_retry:def:1': Set Password retry Requirements. I: oscap: Criteria are extended by definition 'oval:ssg-installed_OS_is_rhel6:def:1'. I: oscap: Evaluating definition 'oval:ssg-installed_OS_is_rhel6:def:1': Red Hat Enterprise Linux 6. I: oscap: Definition 'oval:ssg-installed_OS_is_rhel6:def:1' evaluated as false. I: oscap: Evaluating textfilecontent54 test 'oval:ssg-test_password_pam_cracklib_retry:tst:1': check the configuration of /etc/pam.d/system-auth. I: oscap: Querying textfilecontent54 object 'oval:ssg-obj_password_pam_cracklib_retry:obj:1', flags: 0. I: oscap: Creating new syschar for textfilecontent54_object 'oval:ssg-obj_password_pam_cracklib_retry:obj:1'. I: probe_textfilecontent54: Opening file '/etc/pam.d/system-auth'. I: oscap: State 'oval:ssg-state_password_pam_retry:ste:1' references external_variable 'oval:ssg-var_password_pam_retry:var:1'. I: oscap: Test 'oval:ssg-test_password_pam_cracklib_retry:tst:1' requires that at least one object defined by 'oval:ssg-obj_password_pam_cracklib_retry:obj:1' exists on the system. I: oscap: 0 objects defined by 'oval:ssg-obj_password_pam_cracklib_retry:obj:1' exist on the system. I: oscap: No item matching object 'oval:ssg-obj_password_pam_cracklib_retry:obj:1' was found on the system. (flag=does not exist) I: oscap: Test 'oval:ssg-test_password_pam_cracklib_retry:tst:1' evaluated as false. I: oscap: Criteria are extended by definition 'oval:ssg-installed_OS_is_rhel7:def:1'. I: oscap: Evaluating definition 'oval:ssg-installed_OS_is_rhel7:def:1': Red Hat Enterprise Linux 7. I: oscap: Definition 'oval:ssg-installed_OS_is_rhel7:def:1' evaluated as false. I: oscap: Evaluating textfilecontent54 test 'oval:ssg-test_password_pam_pwquality_retry:tst:1': check the configuration of /etc/pam.d/system-auth. I: oscap: Querying textfilecontent54 object 'oval:ssg-obj_password_pam_pwquality_retry:obj:1', flags: 0. I: oscap: Creating new syschar for textfilecontent54_object 'oval:ssg-obj_password_pam_pwquality_retry:obj:1'. I: probe_textfilecontent54: Opening file '/etc/pam.d/system-auth'. I: oscap: State 'oval:ssg-state_password_pam_retry:ste:1' references external_variable 'oval:ssg-var_password_pam_retry:var:1'. I: oscap: Test 'oval:ssg-test_password_pam_pwquality_retry:tst:1' requires that at least one object defined by 'oval:ssg-obj_password_pam_pwquality_retry:obj:1' exists on the system. I: oscap: 1 objects defined by 'oval:ssg-obj_password_pam_pwquality_retry:obj:1' exist on the system. I: oscap: All items matching object 'oval:ssg-obj_password_pam_pwquality_retry:obj:1' were collected. (flag=complete) I: oscap: In test 'oval:ssg-test_password_pam_pwquality_retry:tst:1' all of the collected items must satisfy these states: 'oval:ssg-state_password_pam_retry:ste:1'. I: oscap: Entity 'subexpression'='3' of item '106534257' matches corresponding entity in state 'oval:ssg-state_password_pam_retry:ste:1'. I: oscap: Item '106534257' compared to state 'oval:ssg-state_password_pam_retry:ste:1' with result true. I: oscap: Test 'oval:ssg-test_password_pam_pwquality_retry:tst:1' evaluated as true. I: oscap: Criteria are extended by definition 'oval:ssg-installed_OS_is_fedora:def:1'. I: oscap: Evaluating definition 'oval:ssg-installed_OS_is_fedora:def:1': Installed operating system is Fedora. I: oscap: Definition 'oval:ssg-installed_OS_is_fedora:def:1' evaluated as false. I: oscap: Evaluating textfilecontent54 test 'oval:ssg-test_password_pam_pwquality_retry:tst:1': check the configuration of /etc/pam.d/system-auth. I: oscap: Test 'oval:ssg-test_password_pam_pwquality_retry:tst:1' evaluated as true. I: oscap: Definition 'oval:ssg-accounts_password_pam_retry:def:1' evaluated as false.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss January 2017