Discuss April 2019

discuss@lists.centos.org

89 participants
83 discussions

Re: [CentOS] Issues when updating CentOS 7
by Jyrki Tikka 08 Apr '19

08 Apr '19

>I wanted to update my CentOS 7 install this morning and I started>getting the errors from below. >Any ideas on a fix? Certainly! >Error: Package: python34-xapps-overrides-1.0.4-13.el7.x86_64 (@epel) > Requires: xapps(x86-64) = 1.0.4-13.el7 > Removing: xapps-1.0.4-13.el7.x86_64 (@epel) > xapps(x86-64) = 1.0.4-13.el7 > Updated By: xapps-1.0.4-14.el7.x86_64 (epel) > xapps(x86-64) = 1.0.4-14.el7 > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest The package python34-xapps-overrides-1.0.4-13.el7.x86_64 has been replacedby python36-xapps-overrides-1.0.4-14.el7.x86_64 and yum can't handle it.Sometimes the problem will be solved within reasonable time but sometimes it'sjust simpler to remove and reinstall some offending package. Just remove xapps (yum remove xapps) and note which packages are removed with it.On my systems these packages were removed: Packages Altered: Erase python2-xapps-overrides-1.0.4- 13.el7.x86_64 @epel Erase python34-xapps-overrides-1.0.4- 13.el7.x86_64 @epel Erase xapps-1.0.4- 13.el7.x86_64 @epel Erase xed-1.6.2- 3.el7.x86_64 @epel Then reinstall xapps, xed, python2-xapps-overrides andinstall python36- xapps-overrides like so: Packages Altered: Install python2-xapps-overrides-1.0.4- 14.el7.x86_64 @epel Install python36-xapps-overrides-1.0.4- 14.el7.x86_64 @epel Install xapps-1.0.4- 14.el7.x86_64 @epel Install xed-1.6.2- 3.el7.x86_64 @epel <(*) Jyrki

3 2

Automatic updates applying after reboot
by Gestió Servidors 08 Apr '19

08 Apr '19

Hello, I have noticed something I consider "a bug". Running a CentOS-7-x86_64 with kernel 3.10.0-327.13.1 and Gnome 3.14.x, my systems detects some available updates, notifies me at top bar and, if I close session, Gnome ask me if I want to apply these "pending" updates and, then, execute "shutdown" or "restart". My questions/problems are two: * this automatic updates check runs in both root session and not a root session, so if a "normal" user login, that user could logout and APPLY updates (system reboots and, during boot, updates system). I consider these situation VERY DANGEROUS, because a normal user should not be able to apply updates * what daemon controls automatic updates? pakagekit? What RPM? gnome-packagekit-updater? I NEED to disable this feature. By the moment, the only solution I have found is disablinig packagekit daemon (systemctl disable packagekit) and remove RPM "gnome-packagekit-updater". Thanks.

1 0

Issues when updating CentOS 7
by Stelian Iancu 05 Apr '19

05 Apr '19

Hi all, I wanted to update my CentOS 7 install this morning and I started getting the errors from below. Any ideas on a fix? They seem to be related to cinnamon which I actually don't use at all (the machine was prepared by our IT at work and they install both Gnome and Cinnamon by default). Since I don't use it, I guess an option would be to remove it altogether and then I will probably not have the update issues anymore. But I would still try to find a proper way to solve this Thanks in advance! Here is the output from yum update: Resolving Dependencies --> Running transaction check ---> Package cinnamon-menus.x86_64 0:3.6.0-3.el7 will be updated ---> Package cinnamon-menus.x86_64 0:3.6.0-4.el7 will be an update ---> Package cinnamon-screensaver.x86_64 0:3.6.1-3.el7 will be updated ---> Package cinnamon-screensaver.x86_64 0:3.6.1-4.el7 will be an update --> Processing Dependency: python36-gobject(x86-64) for package: cinnamon-screensaver-3.6.1-4.el7.x86_64 --> Processing Dependency: python36-setproctitle(x86-64) for package: cinnamon-screensaver-3.6.1-4.el7.x86_64 --> Processing Dependency: python36-xapp for package: cinnamon-screensaver-3.6.1-4.el7.x86_64 --> Processing Dependency: python36-xapps-overrides(x86-64) for package: cinnamon-screensaver-3.6.1-4.el7.x86_64 ---> Package code.x86_64 0:1.32.3-1552607091.el7 will be updated ---> Package code.x86_64 0:1.33.0-1554390950.el7 will be an update ---> Package freerdp.x86_64 0:1.0.2-15.el7 will be updated ---> Package freerdp.x86_64 0:1.0.2-15.el7_6.1 will be an update ---> Package freerdp-libs.x86_64 0:1.0.2-15.el7 will be updated ---> Package freerdp-libs.x86_64 0:1.0.2-15.el7_6.1 will be an update ---> Package freerdp-plugins.x86_64 0:1.0.2-15.el7 will be updated ---> Package freerdp-plugins.x86_64 0:1.0.2-15.el7_6.1 will be an update ---> Package google-chrome-stable.x86_64 0:73.0.3683.86-1 will be updated ---> Package google-chrome-stable.x86_64 0:73.0.3683.103-1 will be an update ---> Package mint-y-theme.noarch 0:1.2.4-1.el7 will be updated ---> Package mint-y-theme.noarch 0:1.2.4-2.el7 will be an update ---> Package python2-crypto.x86_64 0:2.6.1-15.el7 will be updated ---> Package python2-crypto.x86_64 0:2.6.1-16.el7 will be an update ---> Package python2-pyxdg.noarch 0:0.25-6.el7 will be updated ---> Package python2-pyxdg.noarch 0:0.25-7.el7 will be an update ---> Package python2-xapps-overrides.x86_64 0:1.0.4-13.el7 will be updated ---> Package python2-xapps-overrides.x86_64 0:1.0.4-14.el7 will be an update ---> Package python34.x86_64 0:3.4.9-2.el7 will be obsoleted --> Processing Dependency: python(abi) = 3.4 for package: python34-gobject-base-3.22.0-4.el7.x86_64 --> Processing Dependency: python(abi) = 3.4 for package: python34-gobject-3.22.0-4.el7.x86_64 --> Processing Dependency: python(abi) = 3.4 for package: python34-xapp-1.0.1-8.el7.noarch --> Processing Dependency: python(abi) = 3.4 for package: python34-xapps-overrides-1.0.4-13.el7.x86_64 --> Processing Dependency: python(abi) = 3.4 for package: python34-setproctitle-1.1.6-2.el7.x86_64 --> Processing Dependency: python(abi) = 3.4 for package: python34-psutil-2.2.1-5.el7.x86_64 --> Processing Dependency: python(abi) = 3.4 for package: python34-cairo-1.10.0-24.el7.x86_64 ---> Package python34-libs.x86_64 0:3.4.9-2.el7 will be obsoleted --> Processing Dependency: libpython3.4m.so.1.0()(64bit) for package: python34-3.4.9-3.el7.x86_64 --> Processing Dependency: libpython3.4m.so.1.0()(64bit) for package: python34-setproctitle-1.1.6-2.el7.x86_64 --> Processing Dependency: libpython3.4m.so.1.0()(64bit) for package: python34-cairo-1.10.0-24.el7.x86_64 --> Processing Dependency: libpython3.4m.so.1.0()(64bit) for package: python34-psutil-2.2.1-5.el7.x86_64 ---> Package python34-psutil.x86_64 0:2.2.1-4.el7 will be updated ---> Package python34-psutil.x86_64 0:2.2.1-5.el7 will be an update ---> Package python36.x86_64 0:3.6.6-5.el7 will be obsoleting ---> Package python36-libs.x86_64 0:3.6.6-5.el7 will be obsoleting ---> Package xapps.x86_64 0:1.0.4-13.el7 will be updated --> Processing Dependency: xapps(x86-64) = 1.0.4-13.el7 for package: python34-xapps-overrides-1.0.4-13.el7.x86_64 ---> Package xapps.x86_64 0:1.0.4-14.el7 will be an update --> Running transaction check ---> Package python34.x86_64 0:3.4.9-2.el7 will be updated ---> Package python34.x86_64 0:3.4.9-3.el7 will be an update ---> Package python34-libs.x86_64 0:3.4.9-2.el7 will be updated ---> Package python34-libs.x86_64 0:3.4.9-3.el7 will be an update ---> Package python36-gobject.x86_64 0:3.22.0-6.el7 will be installed --> Processing Dependency: python36-gobject-base(x86-64) = 3.22.0-6.el7 for package: python36-gobject-3.22.0-6.el7.x86_64 --> Processing Dependency: python36-cairo(x86-64) for package: python36-gobject-3.22.0-6.el7.x86_64 ---> Package python36-setproctitle.x86_64 0:1.1.6-3.el7 will be installed ---> Package python36-xapp.noarch 0:1.0.1-9.el7 will be installed --> Processing Dependency: python36-psutil for package: python36-xapp-1.0.1-9.el7.noarch ---> Package python36-xapps-overrides.x86_64 0:1.0.4-14.el7 will be installed ---> Package xapps.x86_64 0:1.0.4-13.el7 will be updated --> Processing Dependency: xapps(x86-64) = 1.0.4-13.el7 for package: python34-xapps-overrides-1.0.4-13.el7.x86_64 --> Running transaction check ---> Package python36-cairo.x86_64 0:1.10.0-25.el7 will be installed ---> Package python36-gobject-base.x86_64 0:3.22.0-6.el7 will be installed ---> Package python36-psutil.x86_64 0:2.2.1-5.el7 will be installed ---> Package xapps.x86_64 0:1.0.4-13.el7 will be updated --> Processing Dependency: xapps(x86-64) = 1.0.4-13.el7 for package: python34-xapps-overrides-1.0.4-13.el7.x86_64 --> Finished Dependency Resolution Error: Package: python34-xapps-overrides-1.0.4-13.el7.x86_64 (@epel) Requires: xapps(x86-64) = 1.0.4-13.el7 Removing: xapps-1.0.4-13.el7.x86_64 (@epel) xapps(x86-64) = 1.0.4-13.el7 Updated By: xapps-1.0.4-14.el7.x86_64 (epel) xapps(x86-64) = 1.0.4-14.el7 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest

2 1

Seek some help on operating system drivers. Thanks!
by JICHUN LIU 05 Apr '19

05 Apr '19

Hello, I am a user of CentOS 7.6. I came here for help. I recently bought a microserver called HPE Proliant MicroServer Gen10(X3216 APU). CentOS 7.6 was installed for it. I found that the fan of the machine would keep turning and the noise was very loud. I searched everywhere but I couldn't find any way out. Pardon my ignorance showing. I don’t know where to seek help. When I use sensors-detect: Sorry, no sensors were detected. Either your system has no sensors, or they are not supported, or they are connected to an I2C or SMBus adapter that is not supported. If you find out what chips are on your board, check http://www.lm-sensors.org/wiki/Devices for driver status. Some info about my microserver: [root@centos7 ~]# lsb_release -a LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: CentOS Description: CentOS Linux release 7.6.1810 (Core) Release: 7.6.1810 Codename: Core [root@centos7 ~]# lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Complex 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wani [Radeon R5/R6/R7 Graphics] (rev 87) 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Host Bridge 00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Port 00:02.5 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Port 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Host Bridge 00:08.0 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 1578 00:09.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 157d 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 20) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 49) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 49) 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 4a) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 5 01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller (rev 11) 02:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe 02:00.1 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe

2 2

git.centos.org : Delayed migration
by Fabian Arrotin 05 Apr '19

05 Apr '19

Due to unexpected circumstances , we have to delay the git.centos.org migration. I'll post an update when we'll have all details, but it seems it would be only delayed for some days. Thanks for your comprehending, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

1 0

New post message
by Konstantin Msk 05 Apr '19

05 Apr '19

Hello! On my server PC i have Centos 7 installed. CentOS Linux release 7.6.1810. There are four arrays RAID1 (software RAID) md124 - /boot/efi md125 - /boot md126 - /bd md127 - / I have configured booting from both drives, everything works fine if both drives are connected. But if I disable any drive from which RAID1 is built the system crashes, there is a partial boot and as a result the Entering emergency mode. By all rules RAID1 in case of similar failure of one of disks the system has to recognize this moment at loading, analyze that from the array only one disk is available and forcibly assemble inactive RAID array in case it is degraded in the mode when the second disk is missing may be... In Debian system this problem does not occur, the initramfs runs the script /scripts/local-block/mdadm builds the array from one dostoinogo disc ( lack of drive is not important, it's either a drive failure or disconnection from power-random or not random). In this script You can see the following ...... if [ "$COUNT" = "$MAX" ] then # Poor man's mdadm-last-resort@.service for incremental devices mdadm -q --run /dev/md?* # And last try for all others mdadm -q --assemble --scan --run rm -f /run/count.mdadm.initrd .... Why in server Centos 7 this problem is still not solved? Will this be fixed in upcoming releases? Best Regards AndersonGH

3 6

Ark vs. RAR files under CentOS 7
by Nicolas Kovacs 05 Apr '19

05 Apr '19

Hi, Over the past weeks, I've configured and fine-tuned a bells-and-whistles desktop based on CentOS 7 and KDE, which I've documented in detail on my blog: * https://www.microlinux.fr/poste-de-travail-entreprise-centos-7-kde/ So far I have one single thing that's not working. It's a little detail, but I'm sure it will come bite me, since I know some of my users need this functionality. Ark (KDE's archive manager) can't handle RAR files, even though unrar is installed under the hood. It looks like I have to rebuild Ark to get this functionality. Before I do that, I thought I'd rather ask if there is a more straightforward solution to this. Some third-party repositories (like Nux-Dextop) offer rebuilt packages like k3b-freeworld or audacity-freeworld with extended functionality. Does anybody know of an ark-freeworld package that's out there somewhere? Cheers from the sunny South of France, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32

1 0

Kickstart putting /boot on sda2 (anaconda partition enumeration)?
by Bryce Evans 04 Apr '19

04 Apr '19

Does anyone know how anaconda partitioning enumerates disk partitions when specified in kickstart? I quickly browsed through the anaconda installer source on github but didn't see the relevant bits. I'm using the centOS 6.10 anaconda installer. Somehow I am ending up with my swap partition on sda1, /boot on sda2, and root on sda3. for $REASONS I want /boot to be the partition #1 (sda1) My kickstart storage config looks like this: bootloader --location=mbr --driveorder=sda,sdb zerombr ignoredisk --only-use=sda,sdb clearpart --all --drives=sda,sdb part raid.boot0 --size 1000 --ondrive=sda part raid.swap0 --size 8192 --ondrive=sda part raid.root0 --size 8000 --grow --ondrive=sda part raid.boot1 --size 1000 --ondrive=sdb part raid.swap1 --size 8192 --ondrive=sdb part raid.root1 --size 8000 --grow --ondrive=sdb raid /boot --fstype ext4 --device md0 --level=RAID1 raid.boot1 raid.boot0 raid swap --fstype swap --device md1 --level=RAID1 raid.swap1 raid.swap0 raid / --fstype ext4 --device md2 --level=RAID1 raid.root1 raid.root0 The anaconda-ks.cfg file that gets written out to /root (after kickstart finishes) looks like this: #zerombr # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work #clearpart --all --drives=sda,sdb #ignoredisk --only-use=sda,sdb #raid /boot --fstype=ext4 --level=1 --device=md0 raid.008018 raid.008002 #raid swap --level=1 --device=md1 raid.008017 raid.008001 #raid / --fstype=ext4 --level=1 --device=md2 raid.008019 raid.008003 #part raid.008001 --size=8192 #part raid.008002 --size=1000 #part raid.008003 --grow --size=8000 #part raid.008017 --size=8192 #part raid.008018 --size=1000 #part raid.008019 --grow --size=8000 I'm assuming that my swap is being put on sda1 because for some reason that partition gets the lowest numeric value in the name (raid.008001) But I don't see why that is happening, nor am I sure how to tell anaconda that I want /boot on the first partition (other than doing it in %pre) I cannot specify the 'onpart=sda1' option because I use 'clearpart' in the script, and according to the docs: "If the clearpart command is used, then the --onpart command cannot be used on a logical partition." The partition table on disk ends up looking as such: bash-4.1# parted /dev/sda GNU Parted 2.1 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: HP LOGICAL VOLUME (scsi) Disk /dev/sda: 480GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 8591MB 8590MB primary raid 2 8591MB 9640MB 1049MB primary ext4 boot, raid 3 9640MB 480GB 470GB primary raid Anyone know where I should be looking, or have a workaround besides doing my partitioning in %pre? Thanks

3 2

Re: [CentOS] nobody:nobody
by Mark LaPierre 04 Apr '19

04 Apr '19

On 4/3/19 6:43 AM, mark wrote: > On 04/02/19 20:21, Mark LaPierre wrote: >> Hey Y'all, >> >> For the last week or more I've been trying to get NFS and OpenLDAP to >> play nice with each other. I've pretty much worn the Google machine >> out trying to find a solution. I've found several that said "Solved" >> but none of those solutions solved my nobody:nobody problem. >> >> In the past I've used NFS in conjunction with NIS to share home >> directories from my NFS server but I read that NIS is deprecated in >> favor of LDAP so, being a sucker for new ideas, I decided I would use >> LDAP too like the big boys do. I think I'm regretting this decision. >> Now the question: >> >> Is there something I need to configure on the client side of the >> relationship that all the Google wisdom has failed to mention? All the > > I'd assume: have you edited /etc/idmapd.conf, and at least put in your > domain? Then started the imapd daemon? > > Btw, when you go to C 7, there's no imapd daemon, but you still need to > edit that file. > > mark >> guides/tutorial/etc... talk extensively about configuring the server, >> many giving conflicting information, but have nothing to say about the >> client. I've even found a couple that talk about configuring CentOS 6 >> but contain commands found only in CentOS 7. Makes one go hmmm? >> >> Here's the basic details: >> Server: >> CentOS 6 >> openldap-2.4.40-16.el6.i686 >> openldap-clients-2.4.40-16.el6.x86_64 >> perl-LDAP-0.40-3.el6.noarch >> sssd-ldap-1.13.3-60.el6_10.2.x86_64 >> openldap-2.4.40-16.el6.x86_64 >> openldap-servers-2.4.40-16.el6.x86_64 >> python-ldap-2.3.10-1.el6.x86_64 >> apr-util-ldap-1.3.9-3.el6_0.1.x86_64 >> smbldap-tools-0.9.6-4.el6.noarch >> nfs-utils-lib-1.1.5-13.el6.x86_64 >> nfs4-acl-tools-0.3.3-8.el6.x86_64 >> nfs-utils-1.2.3-78.el6_10.1.x86_64 >> >> Client: >> CentOS 7 KVM VM running on the server >> sssd-ldap-1.16.2-13.el7_6.5.x86_64 >> python-ldap-2.4.15-2.el7.x86_64 >> openldap-2.4.44-21.el7_6.x86_64 >> nfs4-acl-tools-0.3.3-19.el7.x86_64 >> nfs-utils-1.3.0-0.61.el7.x86_64 >> libnfsidmap-0.25-19.el7.x86_64 >> >> Both machines are fully updated. >> >> Would you like to see any of the myriad of configuration files for >> these applications? Just ask and you shall receive. Please be sure >> to tell me if you want the file from the server or the client hey. >> > > Content of idmapd.conf: Server: [General] #Verbosity = 0 # The following should be set to the local NFSv4 domain name # The default is the host's DNS domain name. #Domain = local.domain.edu Domain = peach.patch.mylan Client: [General] #Verbosity = 0 # The following should be set to the local NFSv4 domain name # The default is the host's DNS domain name. #Domain = local.domain.edu Domain = poppy.patch.mylan Now one more question. The imap daemon is a mail server. How is it that I need a mail server running to make LDAP and NFS work? Doesn't seem to make sense to me. -- _ °v° /(_)\ ^ ^ Mark LaPierre Registered Linux user No #267004 https://linuxcounter.net/ ****

4 5

nobody:nobody
by Mark LaPierre 03 Apr '19

03 Apr '19

Hey Y'all, For the last week or more I've been trying to get NFS and OpenLDAP to play nice with each other. I've pretty much worn the Google machine out trying to find a solution. I've found several that said "Solved" but none of those solutions solved my nobody:nobody problem. In the past I've used NFS in conjunction with NIS to share home directories from my NFS server but I read that NIS is deprecated in favor of LDAP so, being a sucker for new ideas, I decided I would use LDAP too like the big boys do. I think I'm regretting this decision. Now the question: Is there something I need to configure on the client side of the relationship that all the Google wisdom has failed to mention? All the guides/tutorial/etc... talk extensively about configuring the server, many giving conflicting information, but have nothing to say about the client. I've even found a couple that talk about configuring CentOS 6 but contain commands found only in CentOS 7. Makes one go hmmm? Here's the basic details: Server: CentOS 6 openldap-2.4.40-16.el6.i686 openldap-clients-2.4.40-16.el6.x86_64 perl-LDAP-0.40-3.el6.noarch sssd-ldap-1.13.3-60.el6_10.2.x86_64 openldap-2.4.40-16.el6.x86_64 openldap-servers-2.4.40-16.el6.x86_64 python-ldap-2.3.10-1.el6.x86_64 apr-util-ldap-1.3.9-3.el6_0.1.x86_64 smbldap-tools-0.9.6-4.el6.noarch nfs-utils-lib-1.1.5-13.el6.x86_64 nfs4-acl-tools-0.3.3-8.el6.x86_64 nfs-utils-1.2.3-78.el6_10.1.x86_64 Client: CentOS 7 KVM VM running on the server sssd-ldap-1.16.2-13.el7_6.5.x86_64 python-ldap-2.4.15-2.el7.x86_64 openldap-2.4.44-21.el7_6.x86_64 nfs4-acl-tools-0.3.3-19.el7.x86_64 nfs-utils-1.3.0-0.61.el7.x86_64 libnfsidmap-0.25-19.el7.x86_64 Both machines are fully updated. Would you like to see any of the myriad of configuration files for these applications? Just ask and you shall receive. Please be sure to tell me if you want the file from the server or the client hey. -- _ °v° /(_)\ ^ ^ Mark LaPierre Registered Linux user No #267004 https://linuxcounter.net/ ****

2 1

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss April 2019