Discuss February 2019

discuss@lists.centos.org

97 participants
79 discussions

amanda broken pipe
by Helmut Drodofsky 16 Feb '19

16 Feb '19

Hello, we are using amanda for backup with 2 tape libraries. Last days we made CentOS 7 update to CentOS Linux release 7.6.1810 (Core) Includes from base repository: amanda-client-3.3.3-21.el7.x86_64 amanda-server-3.3.3-21.el7.x86_64 amanda-3.3.3-21.el7.x86_64 amanda-libs-3.3.3-21.el7.x86_64 deleted: version 3.3.3-17 Before the update (= version 3.3.3-17) we run to configs in parallel without any problem. After the update: the first startet config: OK The second started config: broken pipe. The information in the amanda Mail: ..... The next 3 tapes Amanda expects to use are: am503, am518, am519. The next 2 new tapes already labelled are: am511, am514 FAILURE DUMP SUMMARY: planner: ERROR Request to ph04.panama.int failed: error sending REQ: write error to: Broken pipe .... Same problem with amcheck if one amanda config is running: ... Amanda Backup Client Hosts Check -------------------------------- WARNING: ph04.panama.int: selfcheck request failed: error sending REQ: write error to: Broken pipe Client check: 1 host checked in 0.050 seconds. 1 problem found. (brought to you by Amanda 3.3.3) Any ideas or have I to go back to former version? -- Viele Grüße Helmut Drodofsky Internet XS Service GmbH Heßbrühlstraße 15 70565 Stuttgart Geschäftsführung Helmut Drodofsky HRB 21091 Stuttgart USt.ID: DE190582774 Fon: 0711 781941 0 <tel:+497117819410> Fax: 0711 781941 79 Mail: info(a)internet-xs.de www.internet-xs.de

1 0

Please Recommend Affordable and Reliable Cloud Storage for 50 TB of Data
by Turritopsis Dohrnii Teo En Ming 16 Feb '19

16 Feb '19

Hi, Could you recommend affordable and reliable cloud storage for 50 TB of data? Here are some important factors to consider: 1. Personal/non-commercial use. 2. Must be affordable, since I am unemployed most of the time and have super low levels of income for the past 12 years since I graduated from the National University of Singapore in 2007. 3. Cloud storage provider must not be a fly-by-night company, that is, it will not suddenly close down the next day. Please advise. Thank you. ===BEGIN EMAIL SIGNATURE=== The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html ******************************************************************************************** Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming ===END EMAIL SIGNATURE===

15 25

Aeskulap & kernel.x86_64 3.10.0-957.5.1.el7
by Gregory P. Ennis 16 Feb '19

16 Feb '19

Everyone, I wanted to report that the aeskulap dicom viewer available on the nux.dextop repositories is now working with the lastest kernel update : kernel.x86_64 3.10.0-957.5.1.el7. Thanks much to everyone!!! -- Greg Ennis

1 1

C7 basic install, HATE
by mark 15 Feb '19

15 Feb '19

I've got an old server, that I'm *trying* to rebuild from C6. Our regular key, with the kickstarts, etc, simply won't boot. Just a blank screen, and it never goes anywhere. So I'm trying to build it from a year-old regular installer. 100% of the time, the graphical screen is screwed. Resolution's so big that I cannot see the right-hand 10% or 15% of the screen. There doesn't seem to be any way that I've found yet to make it higher res, so I can read it. It's *not* the monitor's fault. It is an ancient Matrox video card... but I would have thought the VESA driver could handle it. Any suggestions? mark

5 7

/boot partition running out of space randomly. Please help!
by Sean Son 15 Feb '19

15 Feb '19

Hello all First off, I am running Oracle Linux 7.6 on a Hyper-V 2016 VM for a customer. I know this is not an Oracle Linux mailling list, but because Oracle Linux and CentOS are so similar, to an extent, I figured why not ask on here because someone MIGHT know the answer.. Here is the issue. I have a 600MB /boot partition allocated on a UEFI system. The /boot/efi partition is on a separate EFI partition. Recently, I noticed that this system has been crashing every few minutes and when I checked the disk space, I noticed that the /boot partition has zero free space available. I removed all of the old kernels and left the running kernel in place, in hopes that will free up some space. It freed up about 50MB or so, but then the system would crash again. After I would reboot the VM to bring the system back up, I ran a df -h /boot, and the results were reporting ZERO disk space again for the /boot partition.. It makes absolutely no sense how a partition which is generally static UNLESS you move something into it, is running out of space after space has been manually freed up in the partition! What boggles me even more is that when I do an ls -lh /boot, the file systems do not add up to 600M (well 594M) at all. See below: df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 2.8G 0 2.8G 0% /dev tmpfs 2.8G 0 2.8G 0% /dev/shm tmpfs 2.8G 8.5M 2.8G 1% /run tmpfs 2.8G 0 2.8G 0% /sys/fs/cgroup /dev/mapper/VolGroup00-LogVolRoot 30G 19G 12G 63% / /dev/sda2 594M 594M 0 100% /boot /dev/sda1 238M 9.7M 229M 5% /boot/efi /dev/mapper/VolGroup00-LogVolHome 3.3G 415M 2.9G 13% /home tmpfs 565M 0 565M 0% /run/user/54321 tmpfs 565M 0 565M 0% /run/user/1000 ]$ ls -lh /boot total 92M -rw-r--r-- 1 root root 179K Dec 12 22:52 config-4.14.35-1844.0.7.el7uek.x86_64 drwx------ 3 root root 16K Dec 31 1969 efi drwx------. 2 root root 21 Feb 8 15:55 grub2 -rw-------. 1 root root 54M Aug 28 12:31 initramfs-0-rescue-0287c4db206d4a9abe14f750b9091a01.img -rw------- 1 root root 22M Dec 21 17:24 initramfs-4.14.35-1844.0.7.el7uek.x86_64.img -rw-r--r-- 1 root root 329K Dec 12 22:52 symvers-4.14.35-1844.0.7.el7uek.x86_64.gz -rw-r--r-- 1 root root 3.6M Dec 12 22:52 System.map-4.14.35-1844.0.7.el7uek.x86_64 -rwxr-xr-x. 1 root root 6.1M Aug 28 12:31 vmlinuz-0-rescue-0287c4db206d4a9abe14f750b9091a01 -rwxr-xr-x 1 root root 7.2M Dec 12 22:52 vmlinuz-4.14.35-1844.0.7.el7uek.x86_64 I have no idea what is going on here and why the space keeps filling up and the VM crashing! ANY and all help will be greatly appreciated! Thanks! I am running the following kernel: 4.14.35-1844.0.7.el7uek.x86_64 Thanks! Sean S.

4 4

DNSSEC Questions
by Paul R. Ganci 15 Feb '19

15 Feb '19

Last weekend I had my DNSSEC keys expire. I discovered that they had expired the hard way... namely randomly websites could not be found and email did not get delivered. It seems that the keys were only valid for what I estimate was about 30 days. It is a real PITA to have update the keys, restart named and then update Godaddy with new digests. The first part of the problem is fairly manageable in the sense I already have a script that partially can do the job of updating the DNS server. However from what I can tell the only way I can update the DNSSEC of my 8 domains is via the Godaddy control panel GUI. So a couple of questions. 1.) Is anyone aware of anyway to update Godaddy DNSSEC data via a Centos 7 bash shell? I will contact Godaddy but I suspect I am SOL but thought I would ask here thinking somebody else may have already run into this issue. 2.) Assuming the answer to DNSSEC is no, can I at least have the keys last longer than they do by default. I am presently creating the keys via: > dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE zone > dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE zone It is very unclear to me given the dnssec-keygen man page how to set the date so that I could get 90 days or even more per key. The descriptions I found about constructing rolling keys was even more cryptic to me. For example, how do you use these switches: -A date/offset Sets the date on which the key is to be activated. After that date, the key will be included in the zone and used to sign it. If not set, and if the -G option has not been used, the default is "now". -D date/offset Sets the date on which the key is to be deleted. After that date, the key will no longer be included in the zone. (It may remain in the key repository, however.) -I date/offset Sets the date on which the key is to be retired. After that date, the key will still be included in the zone, but it will not be used to sign it. -P date/offset Sets the date on which a key is to be published to the zone. After that date, the key will be included in the zone but will not be used to sign it. If not set, and if the -G option has not been used, the default is "now". -R date/offset Sets the date on which the key is to be revoked. After that date, the key will be flagged as revoked. It will be included in the zone and will be used to sign it. Is it as simple as setting the -I and -R switches to something like +90d At least if I can get the DNS server to update via a cron job even if the 1st item will always have to be done manually that would be help. Thanks for your help. -- Paul (ganci(a)nurdog.com) Cell: (303)257-5208

3 5

question about upgrade qemu and libvirtd
by rong zhao 15 Feb '19

15 Feb '19

Hi Team, I am not sure if I should put my question here, I have googled long time, no explicit information found. Background: We need to support KVM encryption and decided to use LUKS. Refer to:https://libvirt.org/formatsecret.html#VolumeUsageType libvirtd and KVM should be able to support LUKS format disk directly. Unfortunately, seems that we need to use libvirt2.2+ and qemu 2.6+, because our current qemu-kvm version does not support luks format: And our hypervisor's OS is CentOS 7.2 with libvirt 2.0 and qemu-kvm 1.5.3 Question: Is there any safe way to upgrade to libvirt 2.2 and qemu 2.6? Safe way means: do not need to reboot hyper or VM, do not impact VM types support . Any suggestion is welcome. Thanks.

3 2

Centos bug 15570 - Not just a VBOX bug, can also reproduce on direct hardware install
by Steve Gomez 14 Feb '19

14 Feb '19

Ran into this rather frustrating bug when working with VBOX on a Windows 10 host. It should come as no surprise that I would hit this bug when installing CentOS, and also with RHEL 7 Server with GUI (since you get the same kernel). Based on information from your bug list, I was fortunately able to workaround the trouble with: wget https://people.centos.org/toracat/kernel/7/plus/bug15570new/kernel-3.10.0-9… wget https://people.centos.org/toracat/kernel/7/plus/bug15570new/kernel-devel-3.… yum -y localinstall kernel-3.10.0-957.1.3.bug15570.plus.el7.x86_64.rpm yum -y localinstall kernel-devel-3.10.0-957.1.3.bug15570.plus.el7.x86_64.rpm However, the bug lists seem to refer only to issues with VirtualBox. I have experienced the same symptom when installing on a "hardware" system (no hypervisor). The same commands above also provide a workaround here, but thought the flag should be raised for CentOS and RHEL that it doesn't seem to be just VBOX. Perhaps the priority of this issue should be raised further up the pole since I can't imagine it being a good experience for someone who doesn't know how to dig through a problem like this. The average bear would install something else and move on. In any case, thank you for the patch information. Look forward to a "real" fix soon. Other than that I'm really liking CentOS 7. SG

2 2

possible issue in Anaconda WRT processing %posttrans scriptlets?
by Brian Reichert 14 Feb '19

14 Feb '19

This sounds really weird, bear with me. I've put together a custom install CD derived from CentOS-7-x86_64-Minimal-1810.iso. I've added my RPMs in the mix, and have my dependencies lined up. The installation of the RPMs fail, from packaging.log: ... 15:42:35,741 INFO packaging: libwbclient-4.8.3-4.el7.x86_64 (320/432) 15:42:35,741 INFO packaging: samba-client-libs-4.8.3-4.el7.x86_64 (321/432) 15:42:35,742 INFO packaging: samba-libs-4.8.3-4.el7.x86_64 (322/432) 15:42:35,743 INFO packaging: samba-common-tools-4.8.3-4.el7.x86_64 (323/432) 15:42:35,743 INFO packaging: uid-admin-1-1.noarch (324/432) 15:42:35,743 INFO packaging: creating admin smbpasswd ... 15:42:35,743 INFO packaging: pdbedit: error while loading shared libraries: libwbclient.so.0: cannot open shared object file: No such file or directory 15:42:35,745 INFO packaging: error: %pre(uid-admin-1-1.noarch) scriptlet failed, exit status 127 15:42:35,745 INFO packaging: ==== end rpm scriptlet logs ==== To rewind this: - in my uid-admin RPM's %pre scriptlet, I invoke /usr/bin/pdbedit. - /usr/bin/pdbedit is provided by samba-common-tools. - samba-common-tools requires libwbclient. and we can see they have all gotten installed in the correct order. When I get to an alternate console, I did a search under /mnt/sysimage for libwbclient.so.0, and all I can find is this: /mnt/sysimage/usr/lib64/samba/wbclient/libwbclient.so.0 I can see that libwbclient's %posttrans scriptlet should have installed this shared library: # It has to be posttrans here to make sure all files of a previous version # without alternatives support are removed /usr/sbin/update-alternatives \ --install \ /usr/lib64/libwbclient.so.0.14 \ libwbclient.so.0.14-64 \ /usr/lib64/samba/wbclient/libwbclient.so.0.14 \ 10 /sbin/ldconfig Yet clearly, that didn't happen, and there's no dialog to the contrary. I was able to extract that scriptlet, and run it in the chrooted environment successfully. Is there something about anaconda-yum under CentOS 7 that does something counterintuitive WRT %posttrans scriptlets? -- Brian Reichert <reichert(a)numachi.com> BSD admin/developer at large

1 0

dont run cron.d- when cron.daily-scripts are running
by Leon Fauster 14 Feb '19

14 Feb '19

EL6 context: cronie-1.4.4-16.el6_8.2.x86_64 cronie-anacron-1.4.4-16.el6_8.2.x86_64 crontabs-1.10-33.el6.noarch I have some cron.d entries that execute scripts in minute intervals and I'm wondering how could an "official" way look like, to have a condition to not run cron.d entries when cron.daily scripts are running. Sure, I can hack something around file timestamps or so but that feels not so streamlined ... I'd really appreciate any ideas ... -- LF

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss February 2019