Discuss

discuss@lists.centos.org

3 participants
34748 discussions

Re: [CentOS] Centos 7 and backup solution
by Michael Schumacher 28 Jan '19

28 Jan '19

Sunday, January 27, 2019, 5:10:53 PM, you wrote: KP> rsync to a remote site and then BackupPC. (Use the BackupPC version 4 in KP> Software Collections.) I am using BackupPC too, but you don't need to rsync the data first. BackupPC can rsync data natively. I am using independent backup servers that are not accessible from the backup sources. Don't forget safety and integrity of your backed up data these days! Btw., it is not only a nice backup software, it is also very nice in recovering data through its web interface. best regards --- Michael Schumacher

1 0

How to get unrelease kernel, e.g. 3.10.0-341.el7
by wuzhouhui 28 Jan '19

28 Jan '19

Hi, I cloned https://git.centos.org/r/rpms/kernel.git and found that it only contains kernel version that CentOS released. So how do I get the kernel version that CentOS not release officialy, e.g. 3.10.0-341.el7 and 3.10.0-383.el7 (some kernel version I found in kernel.spec's changelog)? Thanks.

2 1

PXEBoot/Diskless client NFS issue
by John Cole 27 Jan '19

27 Jan '19

Hey CentOS list! I've got an oddity with a diskless client setup that I suspect is the result of the initrd.img I'm using, or some parameter I'm unaware -- or I need to build my own initrd image (and could use some assistance on what has to be done in that department) Testbed is defined as: VM A: ip: 192.168.250.10 with dhcp server, tftp server, nfs server VM B: pxeboot VM, with no local disk, bios set to pxe, same internal network as VM A Early on in the boot cycle, it grabs a DHCP address of 192.168.250.100, with correct mask, gw etc from VM A When I start the testbed setup: On the master VM I see log messages with the NIC of the client getting an address, and successfully loading pxelinux.0, pxelinux.cfg/default, vmlinuz and initrd.img. The PXE client on VM B boots up, downloads all the above images, unpacks and executes the inird image. I see drivers load and normal device registration for the nics just fine. After the PXE client VM shows the nic has its link up, this is where things go wrong... * The PXE client (that properly got an address in the 250 space to get its images) sends out a DHCP discover message as would be expected. * VM A responds with an offer of the same 192.168.250.100 address that was used to load * The PXE client comes back with a DHCPREQUEST for 192.168.85.128 * The DHCP server sends a DHCPNAK to the client, and offers the 250 address again. * The client never responds and the image seems to ignore the NAK/OFFER * Eventually the diskless client comes back with a dracut-initqueue message that (as a lease was not ACKed correctly reports) mount.nfs: Network is unreachable IF however, I run the identical configuration I mention above changing the addresses from 192.168.250.x to the 192.168.85.x space to match the initrd image request, everything works fine and the diskless client boots up normally and I get a command prompt. This would seem to indicate that I've got an otherwise working setup. The images I've always used for diskless boot are the ones prebuilt and posted on the centos mirrors site -- http://mirror.centos.org/centos/7/os/x86_64/images/pxeboot/ I've confirmed they and the pxeboot.0 file I'm using are the most recent being distributed. I've also unsuccessfully tried to use the ip parameters on the pxelinux.cfg/default line. As this seems to me as the most relevant config to post, here's what I've got there: label kiosk kernel kiosk/vmlinuz append initrd=kiosk/initrd.img ip=dhcp root=nfs:192.168.250.10:/var/lib/tftpboot/kiosk/root rw selinux=0 If other configs are requested, I'll gladly provide them, but again all works fine if I do this in the 192.168.85.x IP range. Once I've got this particular problem solved, I'm looking to boot up and bond BOTH NICs together, something I know should be possible, but I've not done myself yet. I believe that'd be handled in the append line as well. Any assistance in what I need to do to build a proper initrd image that doesn't suffer the problem of accepting a DHCP offered address, OR pointers to a config parameter I'm missing would be most appreciated. And a breadcrumb to help me with the dual nic once I'm out of the woods would be the "icing on the cake" but that's obviously a secondary concern right now! Thanks jc

2 2

10Gbps network interfaces under KVM
by Carlos Lopez 26 Jan '19

26 Jan '19

Hi all, Anyone knows if exists some plan to support Intel 10Gbps nics like for example 82575, 82576, 82580 or 82598EB Ethernet controllers under KVM for virtual guest like it does with e1000 driver? Regards, C. L. Martinez

2 1

Curl spec file
by Roee Agami 25 Jan '19

25 Jan '19

Hi, I saw this spec file for curl-7.29: https://git.centos.org/blob/rpms!curl.git/c7/SPECS!curl.spec And was wondering if you have one for a later version. And if not, how hard is it to modify the existing one to support later versions. Thanks! Roee.

4 7

CentOS-announce Digest, Vol 167, Issue 5
by centos-announce-request＠centos.org 25 Jan '19

25 Jan '19

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. CESA-2019:0109 Important CentOS 7 perl Security Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Jan 2019 15:18:07 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2019:0109 Important CentOS 7 perl Security Update Message-ID: <20190124151807.GA623(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2019:0109 Important Upstream details at : https://access.redhat.com/errata/RHSA-2019:0109 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 25fdf4603ff050c99e0733e5c87e956ae4d53958f5cc012c4aef9c96f0db06d7 perl-5.16.3-294.el7_6.x86_64.rpm a5c033d9f07ae7f3e1be74af0efbacba9a28182e49ebb1051e42f401d10df6bd perl-core-5.16.3-294.el7_6.x86_64.rpm d19952d11c7e8a1665de0c25c334a32fbffd15bc86daa5d1d830df8eab234f2e perl-CPAN-1.9800-294.el7_6.noarch.rpm c00e846544d902eea1cd6186e0b0ae97dc8c6e755c324e87f3efb7630aaf4c88 perl-devel-5.16.3-294.el7_6.i686.rpm afd580856968dd1ce74fc7ae4974dd1e0421892524e6fe415cd6300e1959f84e perl-devel-5.16.3-294.el7_6.x86_64.rpm 455397f649b77085744bc3a2e5e256d62d78c21147760b904f0189c21e6c90aa perl-ExtUtils-CBuilder-0.28.2.6-294.el7_6.noarch.rpm 71338d899e335e1fec8e5da0aa24df3400be530758d8380b35d356f07d43cf87 perl-ExtUtils-Embed-1.30-294.el7_6.noarch.rpm aeb5cb697a0edc60d2b4f014cad259620cb435aa0c1b2efead35bc3b60999ee7 perl-ExtUtils-Install-1.58-294.el7_6.noarch.rpm ee21a31de70c64daa1742260fc590203ef3bcb014c881813ada7a3acfb4178b9 perl-IO-Zlib-1.10-294.el7_6.noarch.rpm 2cde9e14351428a33484a57f9e4488ebe3bac607f549187208d0bf169ef85560 perl-libs-5.16.3-294.el7_6.i686.rpm 30bb4e65251eb02ae23fab59cd7833896ca241db385c6f5eea06c489ff00b416 perl-libs-5.16.3-294.el7_6.x86_64.rpm bac35a1f122bcc21c847ee41dc8f660c4a6d52794546eaa557fd036767ef8e8c perl-Locale-Maketext-Simple-0.21-294.el7_6.noarch.rpm a7428d0496b667350f611bbef32237b077e0974e1cff79e4398c0d882e19854a perl-macros-5.16.3-294.el7_6.x86_64.rpm b8f77bf6065bb12cb3fa1f33d0b98b40dabbb231900f41d8b6dbd5bfac7b4acd perl-Module-CoreList-2.76.02-294.el7_6.noarch.rpm 1bfaff78e1bf7696675b2748044beb6ffcd46cbb2a740381c725a617444d9ccb perl-Module-Loaded-0.08-294.el7_6.noarch.rpm 5ab7b507ade62e28bf44e8650b426b8604223314d334fdb7f0d545287086b356 perl-Object-Accessor-0.42-294.el7_6.noarch.rpm 494ab3285e32fd03fe75644fb429ea1250ae442b9cffafbed5a984faf11cffdd perl-Package-Constants-0.02-294.el7_6.noarch.rpm 54e0dadc78699063a7649857f51837a4a2f9299bb410460ad00e9e6c6490c928 perl-Pod-Escapes-1.04-294.el7_6.noarch.rpm 60d7c951435aaf2773a870bc884dbb0509021607f499c2ab06b82e9f3faf76f3 perl-tests-5.16.3-294.el7_6.x86_64.rpm 14342dea55b80183a11e039ca5bd54189467e2b09309717799725bb916dc6d16 perl-Time-Piece-1.20.1-294.el7_6.x86_64.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ 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 167, Issue 5 ***********************************************

1 0

C7, pulseaudio, multi-user setup
by wwp 24 Jan '19

24 Jan '19

Hello there, I'm on a CentOS7 laptop, in a Mate session w/ my default user, and in that desktop, I run apps from other users using sudo, su. It appears that apps started using sudo or in terminals+su, can't play sound: [pulseaudio] main.c: User-configured server at {f7ac68929370425d82f882c116a21597}unix:/run/user/1000/pulse/native, refusing to start/autospawn. User 1000 is my default user. I've searched and read a lot about this topic, and found many suggestions but none works so far. What's the correct way to allow all users to play sound in my default user's desktop session? Adding them all to the audio group doesn't seem to be enough (at least). Regards, -- wwp

1 0

dhcp-client should send hostname to dhcp/ dns server
by Ralf Prengel 24 Jan '19

24 Jan '19

Hallo, what is the right way in centos7 to configure the dhcp-client so that the system name is send to the dhcp/dns server (windows-domain). I found DHCP_HOSTNAME="Hostname" as entry in the device-config of the network-interface. Thanks for hints Ralf

1 0

C7, and my RAID
by mark 23 Jan '19

23 Jan '19

Ok, I think my only choice at this point is to delete and recreate the RAID, then restore from backup (oy, 7TB). I see that I can do an mdadm --remove /dev/md0, then, the page I see that on, suggests zeroing the superblocks. What would happen if I *don't* zero the superblocks before doing an mdadm --create? Would I just wind up back where I am? mark

1 0

Where is everyone?
by mark 23 Jan '19

23 Jan '19

There's usually a lot more traffic here. Just today, I've started wondering if a lot of folks who are usually here are on furlough, with the US gov't shutdown.... If so, my condolences, folks. mark

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