Discuss

discuss@lists.centos.org

2 participants
34758 discussions

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 07 Jan '17

07 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

Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
by lakhera2017 05 Jan '17

05 Jan '17

I am trying to copy(~7TB of data using rsync) between two server in same data center in the backend its using EMC VMAX3 After copying ~30-40GB of data multipath start failing Dec 15 01:57:53 test.example.com multipathd: 360000970000196801239533037303434: Recovered to normal mode Dec 15 01:57:53 test.example.com multipathd: 360000970000196801239533037303434: remaining active paths: 1 Dec 15 01:57:53 test.example.com kernel: sd 1:0:2:20: [sdeu] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [root@test log]# multipath -ll |grep -i fail |- 1:0:0:15 sdq 65:0 failed ready running - 3:0:0:15 sdai 66:32 failed ready running We are using default multipath.conf HBA driver version 8.07.00.26.06.8-k HBA model QLogic Corp. ISP8324-based 16Gb Fibre Channel to PCI Express Adapter OS: CentOS 64-bit/2.6.32-642.6.2.el6.x86_64 Hardware:Intel/HP ProLiant DL380 Gen9 Already verified this solution and checked with EMC everything looks good https://access.redhat.com/solutions/438403 Some more info - There is no drop/error packet on the network side. Filesystem is mounted with noatime,nodiratime Filesystem ext4(Already tried xfs but same error) LVM is in striped mode(Started with linear option and then converted to striped) Already disabled THP echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled Whenever multipath start failing process goes to D state System firmware upgraded Tried with latest version of qlogic driver Tried with different scheduler(noop,deadline,cfq) Tried with different tuned profile(enterprise-storage) Vmcore collected during the time of issue I am able to collect vmcore during the time of issue KERNEL: /usr/lib/debug/lib/modules/2.6.32-642.6.2.el6.x86_64/vmlinux DUMPFILE: vmcore [PARTIAL DUMP] CPUS: 36 DATE: Fri Dec 16 00:11:26 2016 UPTIME: 01:48:57 LOAD AVERAGE: 0.41, 0.49, 0.60 TASKS: 1238 NODENAME: test.example.com RELEASE: 2.6.32-642.6.2.el6.x86_64 VERSION: #1 SMP Wed Oct 26 06:52:09 UTC 2016 MACHINE: x86_64 (2297 Mhz) MEMORY: 511.9 GB PANIC: "BUG: unable to handle kernel NULL pointer dereference at 0000000000000018" PID: 15840 COMMAND: "kjournald" TASK: ffff884023446ab0 [THREAD_INFO: ffff88103def4000] CPU: 2 STATE: TASK_RUNNING (PANIC) -- View this message in context: http://centos.1050465.n5.nabble.com/Result-hostbyte-DID-ERROR-driverbyte-DR… Sent from the CentOS mailing list archive at Nabble.com.

2 2

puppetmaster after updating to 7.3
by Fred Wittekind 05 Jan '17

05 Jan '17

Any one else having issues starting the puppetmaster service after updating to 7.3? Looks like a SELinux issue, I couldn't find an existing bug report, but, seems like I shouldn't be the first one to trip on this issue. # grep puppet audit.log | audit2allow #============= puppetmaster_t ============== allow puppetmaster_t puppetagent_exec_t:file { execute execute_no_trans getattr ioctl open read }; selinux-policy-3.13.1-102.el7_3.7.noarch selinux-policy-targeted-3.13.1-102.el7_3.7.noarch puppet-server-3.6.2-3.el7.noarch (from EPEL) puppet-3.6.2-3.el7.noarch (from EPEL)

2 2

CentOS-announce Digest, Vol 143, Issue 3
by centos-announce-request＠centos.org 05 Jan '17

05 Jan '17

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. Release for CentOS 7.3.1611 on ARM64/AArch64 (Jim Perrin) ---------------------------------------------------------------------- Message: 1 Date: Wed, 4 Jan 2017 11:45:51 -0600 From: Jim Perrin <jperrin(a)centos.org> To: centos-announce(a)centos.org, Conversations around CentOS on ARM hardware <arm-dev(a)centos.org> Subject: [CentOS-announce] Release for CentOS 7.3.1611 on ARM64/AArch64 Message-ID: <f1f44f97-e8e0-da6f-3afc-9a168b37b3ea(a)centos.org> Content-Type: text/plain; charset=utf-8 I am pleased to announce the general availability of CentOS Linux 7 (1611) for AArch64/ARM64 machines. == Changes The kernel has been rebased from 4.2.0 to 4.5.0, and includes several patches recently merged into the upstream. The kernel patches and modifications can be found at https://git.centos.org/summary/sig-altarch!kernel.git in the sig-altarch7-aarch64 branch. == Download You can download new images and isos via http://mirror.centos.org/altarch/7/isos/aarch64/ Images and sha256sums: 1513f5325accfd32ac7973a9b24e401c829ece24da78e24d021e507e877f930e CentOS-7-aarch64-Everything.iso f7ae6bae6c2cc177134d7f8f3808e0f457537c4cd48a119620f50d18ff7bb908 CentOS-7-aarch64.img.xz 48776338f8c8994a9499f07e3af847253cf7235c6aac635a8418a2028ec675cf CentOS-7-aarch64-NetInstall.iso f7ae6bae6c2cc177134d7f8f3808e0f457537c4cd48a119620f50d18ff7bb908 CentOS-7-aarch64-rolling.img.xz 238b1ebf22a0ff894064e6ed2ac35ee02a6503657a40ad51f2eee7afc8229e75 CentOS-7-aarch64-rootfs-7.3.1611.tar.xz == Known Issues 1. Mustang based boards must be on the most recent firmware version, otherwise the network may lose connectivity when using 4.5.0-19+ based kernels. Please ensure your hardware is running the most recent firmware available to avoid network issues. 2. Merlin based boards should be on the most recent firmware version, in order to take full advantage of recent kernel improvements. 3. Some ThunderX based boards have been reported to have MAC address inconsistency when using older firmware versions. Please make sure you have the most recent firmware applied to your hardware to avoid network issues. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 ------------------------------ Subject: Digest Footer _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce ------------------------------ End of CentOS-announce Digest, Vol 143, Issue 3 ***********************************************

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