Discuss

discuss@lists.centos.org

8 participants
34745 discussions

Unable to run TeamViewer 13 under Centos 7 (amd64)
by Manish Jain 19 Dec '17

19 Dec '17

Hi, I am writing a book about Unix (Linux / FreeBSD) and my book needs documentation for TeamViewer13 running under Centos 7 (64-bit). Unfortunately, running TeamViewer does not get me a GUI -- the install went smoothly and teamviewerd daemon is running. This happens only under Centos. Under Manjaro, the same tarball (teamviewer_13.0.5494_amd64.tar.xz) gets me a nice TeamViewer window. But I need documentation for Centos. I have tried reinstalling via rpm (teamviewer_13.0.5693.x86_64.rpm), but that does not improve things. With the teamviewer command, I just get "Launching TeamViewer GUI" - but nothing actually happens after that. Can anyone please help me fix the issue ? -- Thanks & Regards, Manish Jain

4 6

CentOS-announce Digest, Vol 154, Issue 3
by centos-announce-request＠centos.org 19 Dec '17

19 Dec '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. Announcing the release for Gluster 3.13 on CentOS Linux 7 x86_64 (Niels de Vos) 2. Announcing the release for Gluster 3.13 on CentOS Linux 6 x86_64 (Niels de Vos) ---------------------------------------------------------------------- Message: 1 Date: Thu, 14 Dec 2017 09:24:10 +0530 From: Niels de Vos <ndevos(a)redhat.com> To: centos-announce(a)centos.org Subject: [CentOS-announce] Announcing the release for Gluster 3.13 on CentOS Linux 7 x86_64 Message-ID: <20171214035410.GA11272@ndevos-x270> Content-Type: text/plain; charset="us-ascii" I am happy to announce the General Availability of Gluster 3.13 for CentOS 7 on x86_64. These packages are following the upstream Gluster Community releases, and will receive monthly bugfix updates. Gluster 3.13 is a Short-Term-Maintenance release, and will only receive updates until the next version (4.0) becomes available. The difference between Long-Term-Maintenance and Short-Term-Maintenance releases is explained on the Gluster release schedule page: https://www.gluster.org/community/release-schedule/ Users of CentOS 7 can now simply install Gluster 3.13 with only these two commands: # yum install centos-release-gluster313 # yum install glusterfs-server The centos-release-gluster313 package is delivered via CentOS Extras repos. This contains all the metadata and dependancy information, needed to install Gluster 3.13. Note that the standard centos-release-gluster (virtual) package is still available and points to the 3.12 version. This is intentional because 3.12 is a Long-Term-Maintenance version and does not require users to update the major versions avery couple of months. Some deployments may need to install the centos-release-gluster package as well as centos-release-gluster313 to fullfill dependencies for other projects (possibly for oVirt, there may be others). We have a quickstart guide specifically built around the packages are available, it makes for a good introduction to Gluster and will help get you started in just a few simple steps, this quick start is available at https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart More details about the packages that the Gluster project provides in the Storage SIG is available in the documentation: https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster The centos-release-gluster* repositories offer additional packages that enhance the usability of Gluster itself. Utilities and tools that were working with previous versions of Gluster are expected to stay working fine. If there are any proboems, or requests for additional tools and applications to be provided, just send us an email with your suggestions. The current list of packages that is (planned to become) available can be found here: https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs We welcome all feedback, comments and contributions. You can get in touch with the CentOS Storage SIG on the centos-devel mailing list ( https://lists.centos.org ) and with the Gluster developer and user communities at https://www.gluster.org/mailman/listinfo , we are also available on irc at #gluster on irc.freenode.net, and on twitter at @gluster . Cheers, Niels de Vos Storage SIG member & Gluster maintainer

1 0

kernel: blk_cloned_rq_check_limits: over max segments limit., Device Mapper Multipath, iBFT, iSCSI COMSTAR
by Tom Robinson 19 Dec '17

19 Dec '17

Hi, WARNING: Long post ahead I have an issue when starting multipathd. The kernel complains about "blk_cloned_rq_check_limits: over max segments limit". The server in question is configured for KVM hosting. It boots via iBFT to an iSCSI volume. Target is COMSTAR and underlying that is a ZFS volume (100GB). The server also has two infiniband cards providing four (4) more paths over SRP (SCSI RDMA Protocol). With multipathd in the initramfs and enabled at boot, I get five paths (but also now the blk_cloned_req_check_limits error) on boot. I/O on the boot volume also causes the multipaths to fail one after the other until only one path remains, issuing the kernel message "blk_cloned_rq_check_limits: over max segments limit" for each failed path. The paths then recover one after the other but have also 'frozen' the system (final path did not recover!) at which point all I can do is reset the power. (I/O can be KVM Guest read/write, running "dracut -f", copying an ISO to /var/lib/libvirt/images or 'dd'ing a 1GB file to /tmp). I have read: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/pd… I have read: https://access.redhat.com/solutions/2437991 I don't use GPFS: http://www-01.ibm.com/support/docview.wss?uid=ssg1S1009622 I actually have two servers with the exact same hardware configuration. Originally they were both CentOS 7 with the default install LVM partitioning structure. For the above host, I have re-installed and removed LVM as it complicated the issue further. It does appear to be somewhat more stable but results on I/O testing are now inconsistent. Things that have changed are: Not using LVM on the host. Freed up some storage reservations (removed snapshots) on the SAN. ENVIRONMENT: CentOS 7.4 System is iBFT boot (boots from iSCSI on 10G card to COMSTAR zfs volume) System also has Infiniband which provide another four (4) paths multipath is initialised in initramfs Kernel is 3.10.0-693.11.1.el7.x86_64 With respect to https://access.redhat.com/solutions/2437991 there is a recommendation to adjust the 'max_sectors_kb' for devices when seeing the kernel error I am encountering. To that end I have queried the /sys/block area for that information the below. For debugging, at boot, I have disabled multipathd service I wrote the below script to query /sys/block for block device information: # cat bin/max_sectors_kb #!/bin/bash printf "%-18s: %-37s %-15s %-18s\n" $sysblk "Sys Block Node" "Device" "max_sectors_kb" "max_hw_sectors_kb" for b in `ls /sys/block/` do sysblk=/sys/block/$b ls $sysblk/dm/name > /dev/null 2>&1 if [ $? -ne 0 ]; then vendor=`cat $sysblk/device/vendor` model=`cat $sysblk/device/model` name="$vendor $model" else name=`cat $sysblk/dm/name` fi max_sectors_kb=`cat $sysblk/queue/max_sectors_kb` max_hw_sectors_kb=`cat $sysblk/queue/max_hw_sectors_kb` printf "%-18s: %-37s %-15s %-18s\n" $sysblk "$name" $max_sectors_kb $max_hw_sectors_kb done The boot volume is identified by the multipath wwid 3600144f00000000000005a2769c70001. It's underlying device nodes are: sda, sdd, sde, sdk and sdj. Running the script after boot for the boot device I get this: # max_sectors_kb | grep -e 3600144f00000000000005a2769c70001 -e sda -e sdd -e sde -e sdk -e sdj -e max Sys Block Node : Device max_sectors_kb max_hw_sectors_kb /sys/block/dm-1 : 3600144f00000000000005a2769c70001 512 32767 /sys/block/dm-5 : 3600144f00000000000005a2769c70001p1 512 32767 /sys/block/dm-6 : 3600144f00000000000005a2769c70001p2 512 32767 /sys/block/dm-7 : 3600144f00000000000005a2769c70001p3 512 32767 /sys/block/sda : SUN COMSTAR 512 32767 /sys/block/sdd : SUN COMSTAR 512 512 /sys/block/sde : SUN COMSTAR 512 512 /sys/block/sdj : SUN COMSTAR 512 512 /sys/block/sdk : SUN COMSTAR 512 512 On starting multipathd service manually I get: Dec 18 12:46:41 lemans systemd: Starting Availability of block devices... Dec 18 12:46:41 lemans systemd: Starting Device-Mapper Multipath Device Controller... Dec 18 12:46:41 lemans systemd: Started Availability of block devices. Dec 18 12:46:41 lemans systemd: Started Device-Mapper Multipath Device Controller. Dec 18 12:46:41 lemans multipathd: 3600144f00000000000005a2769c70001: load table [0 209715200 multipath 1 queue_if_no_path 0 1 1 service-time 0 5 1 8:64 1 8:144 1 8:48 1 8:160 1 8:0 1] Dec 18 12:46:41 lemans multipathd: 3600144f0000000000000524a93b80002: load table [0 41943040 multipath 1 queue_if_no_path 0 1 1 service-time 0 5 1 8:80 1 8:176 1 8:96 1 8:192 1 8:16 1] Dec 18 12:46:41 lemans multipathd: 3600144f0000000000000524a94510003: load table [0 41943040 multipath 1 queue_if_no_path 0 1 1 service-time 0 5 1 8:112 1 8:208 1 8:128 1 8:224 1 8:32 1] Dec 18 12:46:41 lemans kernel: blk_cloned_rq_check_limits: over max segments limit. Dec 18 12:46:41 lemans kernel: device-mapper: multipath: Failing path 8:48. Dec 18 12:46:41 lemans kernel: device-mapper: multipath: Reinstating path 8:48. Dec 18 12:46:41 lemans multipathd: 3600144f00000000000005a2769c70001: event checker started Dec 18 12:46:41 lemans multipathd: 3600144f0000000000000524a93b80002: event checker started Dec 18 12:46:41 lemans multipathd: 3600144f0000000000000524a94510003: event checker started Dec 18 12:46:41 lemans multipathd: path checkers start up Dec 18 12:46:41 lemans kernel: blk_cloned_rq_check_limits: over max segments limit. Dec 18 12:46:41 lemans kernel: device-mapper: multipath: Failing path 8:64. Dec 18 12:46:41 lemans kernel: blk_cloned_rq_check_limits: over max segments limit. Dec 18 12:46:41 lemans kernel: device-mapper: multipath: Failing path 8:160. Dec 18 12:46:41 lemans multipathd: sde: mark as failed Dec 18 12:46:41 lemans multipathd: 3600144f00000000000005a2769c70001: remaining active paths: 4 Dec 18 12:46:41 lemans multipathd: sdk: mark as failed Dec 18 12:46:41 lemans multipathd: 3600144f00000000000005a2769c70001: remaining active paths: 3 Dec 18 12:46:42 lemans multipathd: 3600144f00000000000005a2769c70001: sde - directio checker reports path is up Dec 18 12:46:42 lemans kernel: device-mapper: multipath: Reinstating path 8:64. Dec 18 12:46:42 lemans multipathd: 8:64: reinstated Dec 18 12:46:42 lemans multipathd: 3600144f00000000000005a2769c70001: remaining active paths: 4 Dec 18 12:46:42 lemans multipathd: 3600144f00000000000005a2769c70001: sdk - directio checker reports path is up Dec 18 12:46:42 lemans kernel: device-mapper: multipath: Reinstating path 8:160. Dec 18 12:46:42 lemans multipathd: 8:160: reinstated Dec 18 12:46:42 lemans multipathd: 3600144f00000000000005a2769c70001: remaining active paths: 5 AND also the max_hw_sectors_kb is reduced to 512 for all but one device: # max_sectors_kb | grep -e 3600144f00000000000005a2769c70001 -e sda -e sdd -e sde -e sdk -e sdj -e max Sys Block Node : Device max_sectors_kb max_hw_sectors_kb /sys/block/dm-1 : 3600144f00000000000005a2769c70001 512 512 /sys/block/dm-5 : 3600144f00000000000005a2769c70001p1 512 512 /sys/block/dm-6 : 3600144f00000000000005a2769c70001p2 512 512 /sys/block/dm-7 : 3600144f00000000000005a2769c70001p3 512 512 /sys/block/sda : SUN COMSTAR 512 32767 /sys/block/sdd : SUN COMSTAR 512 512 /sys/block/sde : SUN COMSTAR 512 512 /sys/block/sdj : SUN COMSTAR 512 512 /sys/block/sdk : SUN COMSTAR 512 512 I don't understand the inconsistent manipulation of the max_hw_sectors_kb... ENABLING multipathd AT BOOT: Enabling the multipathd service at boot, I get lots of path failures and the blk_cloned_rq_check_limits error. From dmesg: [ 48.486407] sd 4:0:0:7: [sdo] Attached SCSI disk [ 49.460048] blk_cloned_rq_check_limits: over max segments limit. [ 49.461199] device-mapper: multipath: Failing path 8:48. [ 49.462284] blk_cloned_rq_check_limits: over max segments limit. [ 49.463392] device-mapper: multipath: Failing path 8:144. [ 49.469282] blk_cloned_rq_check_limits: over max segments limit. [ 49.470886] device-mapper: multipath: Failing path 8:176. [ 49.472560] blk_cloned_rq_check_limits: over max segments limit. [ 49.473893] device-mapper: multipath: Failing path 8:64. [ 49.847469] device-mapper: multipath: Reinstating path 8:48. [ 49.850403] device-mapper: multipath: Reinstating path 8:144. [ 49.853143] device-mapper: multipath: Reinstating path 8:176. [ 50.626291] blk_cloned_rq_check_limits: over max segments limit. [ 50.627539] device-mapper: multipath: Failing path 8:144. [ 50.628533] blk_cloned_rq_check_limits: over max segments limit. [ 50.629467] device-mapper: multipath: Failing path 8:176. [ 50.630441] blk_cloned_rq_check_limits: over max segments limit. [ 50.631379] device-mapper: multipath: Failing path 8:48. [ 54.859526] device-mapper: multipath: Reinstating path 8:64. [ 54.860050] device-mapper: multipath: Reinstating path 8:144. [ 54.860463] device-mapper: multipath: Reinstating path 8:176. [ 55.861034] device-mapper: multipath: Reinstating path 8:48. [ 59.811712] UDP: bad checksum. From 192.168.0.124:55913 to 255.255.255.255:15000 ulen 58 [ 59.999563] blk_cloned_rq_check_limits: over max segments limit. [ 59.999591] device-mapper: multipath: Failing path 8:48. [ 59.999650] blk_cloned_rq_check_limits: over max segments limit. [ 59.999675] device-mapper: multipath: Failing path 8:144. [ 59.999711] blk_cloned_rq_check_limits: over max segments limit. [ 59.999736] device-mapper: multipath: Failing path 8:64. [ 59.999773] blk_cloned_rq_check_limits: over max segments limit. [ 59.999798] device-mapper: multipath: Failing path 8:176. [ 61.055033] device-mapper: multipath: Reinstating path 8:64. [ 61.087458] blk_cloned_rq_check_limits: over max segments limit. [ 61.087495] device-mapper: multipath: Failing path 8:64. [ 62.077462] device-mapper: multipath: Reinstating path 8:48. [ 66.078675] device-mapper: multipath: Reinstating path 8:144. [ 66.079036] device-mapper: multipath: Reinstating path 8:176. [ 67.079827] device-mapper: multipath: Reinstating path 8:64. [ 115.197811] blk_cloned_rq_check_limits: over max segments limit. [ 115.197876] device-mapper: multipath: Failing path 8:176. [ 115.197952] blk_cloned_rq_check_limits: over max segments limit. [ 115.198007] device-mapper: multipath: Failing path 8:48. [ 115.198063] blk_cloned_rq_check_limits: over max segments limit. [ 115.198117] device-mapper: multipath: Failing path 8:144. [ 121.101670] device-mapper: multipath: Reinstating path 8:48. [ 121.102270] device-mapper: multipath: Reinstating path 8:144. [ 121.102645] device-mapper: multipath: Reinstating path 8:176. [ 205.275512] blk_cloned_rq_check_limits: over max segments limit. [ 205.275577] device-mapper: multipath: Failing path 8:48. [ 205.275695] blk_cloned_rq_check_limits: over max segments limit. [ 205.275752] device-mapper: multipath: Failing path 8:176. [ 205.277268] blk_cloned_rq_check_limits: over max segments limit. [ 205.277333] device-mapper: multipath: Failing path 8:144. Other information at this boot point: Multipath # multipath -ll 3600144f00000000000005a2769c70001 3600144f00000000000005a2769c70001 dm-1 SUN ,COMSTAR size=100G features='3 queue_if_no_path queue_mode mq' hwhandler='0' wp=rw `-+- policy='service-time 0' prio=1 status=active |- 0:0:0:0 sda 8:0 active ready running |- 2:0:0:0 sdd 8:48 active ready running |- 1:0:0:0 sde 8:64 active ready running |- 3:0:0:0 sdj 8:144 active ready running `- 4:0:0:0 sdl 8:176 active ready running Other information at this boot point: /sys/block info: # max_sectors_kb | grep -e 3600144f00000000000005a2769c70001 -e sda -e sdd -e sde -e sdk -e sdj -e max Sys Block Node : Device max_sectors_kb max_hw_sectors_kb /sys/block/dm-1 : 3600144f00000000000005a2769c70001 512 512 /sys/block/dm-7 : 3600144f00000000000005a2769c70001p1 512 32767 /sys/block/dm-8 : 3600144f00000000000005a2769c70001p2 512 32767 /sys/block/dm-9 : 3600144f00000000000005a2769c70001p3 512 32767 /sys/block/sda : SUN COMSTAR 512 32767 /sys/block/sdd : SUN COMSTAR 512 512 /sys/block/sde : SUN COMSTAR 512 512 /sys/block/sdj : SUN COMSTAR 512 512 /sys/block/sdk : SUN COMSTAR 512 512 AND when I restart multipathd the max_hw_sectors_kb resets to 512 on all but one device: # max_sectors_kb | grep -e 3600144f00000000000005a2769c70001 -e sda -e sdd -e sde -e sdk -e sdj -e max Sys Block Node : Device max_sectors_kb max_hw_sectors_kb /sys/block/dm-1 : 3600144f00000000000005a2769c70001 512 512 /sys/block/dm-7 : 3600144f00000000000005a2769c70001p1 512 512 /sys/block/dm-8 : 3600144f00000000000005a2769c70001p2 512 512 /sys/block/dm-9 : 3600144f00000000000005a2769c70001p3 512 512 /sys/block/sda : SUN COMSTAR 512 32767 /sys/block/sdd : SUN COMSTAR 512 512 /sys/block/sde : SUN COMSTAR 512 512 /sys/block/sdj : SUN COMSTAR 512 512 /sys/block/sdk : SUN COMSTAR 512 512 Setting max_sectors_kb in /etc/multipath.conf gives very inconsistent results. It's not actually possible to increase the setting past 512 consistently across all available paths as they are established with different hardware maximums (by kernel? driver?) on boot. And starting multipathd seems to change the (read only) value of max_hw_sectors_kb. I get alignment issues and unmountable volumes. Having removed LVM and tidying up SAN storage looks to have solved some issues. I still get the errors on boot. The inconsistencies in max_hw_sectors_kb for each path before and after starting multipathd (both in initramfs and during/after boot) still baffle me. All comments welcome. Any clues appreciated. Kind regards, Tom -- Tom Robinson IT Manager/System Administrator MoTeC Pty Ltd 121 Merrindale Drive Croydon South 3136 Victoria Australia T: +61 3 9761 5050 F: +61 3 9761 5051 E: tom.robinson(a)motec.com.au

1 0

Centos7: backup with rsync problem: "rsync: rsync_xal_set: lremovexattr(""/tmp/test/etc/fstab"", "security.selinux") failed: Permission denied (13)"
by Dario Lesca 18 Dec '17

18 Dec '17

If I run this command in order to backup /etc from remote server to local dir I get a lot of this message: [root@s-virt tmp]# rsync -a --delete --numeric-ids --relative --delete-excluded --compress --acls --xattrs rsync://server-dati/root/etc/ /tmp/test/ -v receiving incremental file list rsync: rsync_xal_set: lremovexattr(""/tmp/test/etc/fstab"","security.selinux") failed: Permission denied (13) rsync: rsync_xal_set: lremovexattr(""/tmp/test/etc/resolv.conf"","security.selinux") failed: Permission denied (13) rsync: rsync_xal_set: lremovexattr(""/tmp/test/etc/rsyncd.conf"","security.selinux") failed: Permission denied (13) rsync: rsync_xal_set: lremovexattr(""/tmp/test/etc/rsyncd.secrets"","security.selinux") failed: Permission denied (13) rsync: rsync_xal_set: lremovexattr(""/tmp/test/etc/lvm/archive/dati_00001-728488062.vg"","security.selinux") failed: Permission denied (13) rsync: rsync_xal_set: lremovexattr(""/tmp/test/etc/lvm/backup/dati"","security.selinux") failed: Permission denied (13) rsync: rsync_xal_set: lremovexattr(""/tmp/test/etc/samba/.smb.conf.swp"","security.selinux") failed: Permission denied (13) rsync: rsync_xal_set: lremovexattr(""/tmp/test/etc/samba/smb.conf"","security.selinux") failed: Permission denied (13) rsync: rsync_xal_set: lremovexattr(""/tmp/test/etc/systemd/system/multi-user.target.wants/rsyncd.service"","security.selinux") failed: Permission denied (13) sent 671 bytes received 49804 bytes 100950.00 bytes/sec total size is 30375007 speedup is 601.78 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1518) [generator=3.0.9] I have also try to "setenforce 0" but the result is the same It's possible to do a full backup of remote /etc with SElinux attrs to a local dir? Many thanks -- Dario Lesca (inviato dal mio Linux Fedora 27 Workstation)

1 0

Offsite hosted backup solutions
by Joseph L. Casale 18 Dec '17

18 Dec '17

Given all the vendors that provide this service with both Windows and Linux clients, Code42 is the only one I am aware of that supports sets. For me, this was essential to prioritize urgent data over low risk changes in the event a disaster occurs while a large directory is taking days to upload. I would use sets with priorities and any changed data that was important would interrupt data of negligible importance. This worked well, however Code42 always bothered me as the software delivery was low quality on Linux, it was a tar file and only implemented sysv scripts and they did not have a cli interface. I worked around this as long as I could until they retooled the app based on electron and as bad as the ui was, it got worse. At this point I would rather switch vendors. Anyone know of another that meets the criteria, from what I can see it doesn't look like any support sets? Thanks, jlc

5 5

Centos 7: avc: denied { reload } for auid=0 uid=0 gid=0 cmdline="/usr/bin/systemctl reload named-chroot.service" ....
by Dario Lesca 17 Dec '17

17 Dec '17

How to resolve this SElinux problem? type=USER_AVC msg=audit(1513478641.700:1920): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { reload } for auid=0 uid=0 gid=0 cmdline="/usr/bin/systemctl reload named-chroot.service" scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' type=USER_AVC msg=audit(1513478641.702:1921): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { reload } for auid=0 uid=0 gid=0 cmdline="/usr/bin/systemctl reload named-sdb.service" scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' type=USER_AVC msg=audit(1513478641.703:1922): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { reload } for auid=0 uid=0 gid=0 cmdline="/usr/bin/systemctl reload named-sdb-chroot.service" scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' type=USER_AVC msg=audit(1513478641.704:1923): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { reload } for auid=0 uid=0 gid=0 cmdline="/usr/bin/systemctl reload named-pkcs11.service" scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' Many thanks -- Dario Lesca (inviato dal mio Linux Fedora 27 Workstation)

1 0

GUI/X11 login and shells other than bash?
by Valeri Galtsev 16 Dec '17

16 Dec '17

Dear Experts, After one of updates that was released some time ago (a Month ago or maybe even earlier) I have noticed the following. On the machines with default runlevel 5 (sorry about old terminology, the new one is still confusing for me ;-) GUI/X11 login (display manager) lists only users whose default shell is bash. Or, at least users whose default shell is tcsh are not listed at all, and if they attempt to log in just by giving their UNIX username, their X11 session "crashes", meaning that after attempting to start, it just trows one back to GUI/X11 login screen. I really do not want to start this shell vs that shell flame war (especially that I myself prefer not tcsh but sh and/or bash for scripting...). But I respect my user's freedom of choosing default shell, so this is really big issue IMHO. I just wonder: does RedHat (CentOS's upstream vendor) dislike and is willing to eradicate all shells except for bash, or what I see is just my own pilot's error? Thanks in advance for all your answers. Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++

3 4

Traffic shaping on CentOS
by Kenneth Porter 16 Dec '17

16 Dec '17

I'm deploying a CentOS 7 box as a gateway and I'm trying to figure out how to set up traffic shaping. Historically I've used the Wondershaper script but apparently it's not deprecated in favor of superior queue management. I haven't yet found a packaged solution and I'm wondering what others do to configure this kind of thing. Apparently the new modules are available in many appliance router products (eg. OpenWrt and Streamboost). Perhaps someone here knows of an RPM that wraps this up for RH-based distros? <https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/> Here's an article arguing why Wondershaper was great in its day but is now bad for modern traffic flows. <https://www.bufferbloat.net/projects/bloat/wiki/Wondershaper_Must_Die/>

3 4

Question on CentoS 7.4 on nvidia
by Jerry Geis 15 Dec '17

15 Dec '17

I installed the elrepo kmod-nvidia and also the nvidia-detect and modules (see below). I had X working with the 3.10 from Centos - but video was freezing. SO I thought I would try the elrepo kernel. I installed that and X does not come up? How do I re-make the nvidia module for 4.14.5 kernel? I want to make sure the kmod kernel did it. I 'm thinking it did not. lspci | grep VGA says GT218 Or what do I look at now to see why X is not coming up? Thanks, Jerry uname -r 4.14.5-1.el7.elrepo.x86_64 grep EE /var/log/Xorg.0.log (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 136.998] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the [ 136.998] (EE) NVIDIA: system's kernel log for additional error messages and [ 136.998] (EE) NVIDIA: consult the NVIDIA README for details. [ 136.998] (EE) No devices detected. [ 136.998] (EE) [ 136.998] (EE) no screens found(EE) [ 136.998] (EE) [ 136.998] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 136.998] (EE) [ 137.004] (EE) Server terminated with error (1). Closing log file. uname -a rpm -qa | grep kernel kernel-3.10.0-693.el7.x86_64 kernel-tools-3.10.0-693.5.2.el7.x86_64 abrt-addon-kerneloops-2.1.11-48.el7.centos.x86_64 kernel-headers-3.10.0-693.5.2.el7.x86_64 kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64 kernel-devel-3.10.0-693.el7.x86_64 kernel-3.10.0-693.5.2.el7.x86_64 kernel-ml-4.14.5-1.el7.elrepo.x86_64 kernel-tools-libs-3.10.0-693.5.2.el7.x86_64 kernel-devel-3.10.0-693.5.2.el7.x86_64 [root@mediaport14 ~]# rpm -qa | grep kernel-ml kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64 kernel-ml-4.14.5-1.el7.elrepo.x86_64 # rpm -qa | grep nvidia kmod-nvidia-340xx-340.102-4.el7_4.elrepo.x86_64 nvidia-detect-384.90-1.el7.elrepo.x86_64 yum-plugin-nvidia-1.0.2-1.el7.elrepo.noarch nvidia-x11-drv-340xx-340.102-1.el7.elrepo.x86_64

7 8

Accessing crashed disk
by martin.wagner＠mailbit.io 15 Dec '17

15 Dec '17

Hi I have a Centos server that crashed, it would no longer boot. I thought it was the disk with the OS that was the problem so I bought a new one and did a fresh install and now the computer is again up and running. But I'm having problems with accessing the old failed disk. I can see it with gnome-disk-utility and it says that the disk is OK but has 8 bad sectors. I can mount the boot partition from it and I can decrypt the main partition. But then I can see no way to mount the main partition. It is a LVM physical volume. Any advice?

6 6

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