[CentOS] yum list "available" versus "updates", and centosplus versioning
quite possibly more a yum question than a centos question, but i'm a bit confused about the difference between listing "available" packages versus "updates" packages. short example -- listing what the yum man page suggests should be "available" for installation, restricting myself to centosplus: $ yum list available --disablerepo=\* --enablerepo=centosplus ... snip ... Available Packages kernel-plus.x86_643.10.0-693.17.1.el7.centos.plus centosplus kernel-plus-abi-whitelists.noarch 3.10.0-693.17.1.el7.centos.plus centosplus kernel-plus-devel.x86_64 3.10.0-693.17.1.el7.centos.plus centosplus kernel-plus-doc.noarch3.10.0-693.17.1.el7.centos.plus centosplus kernel-plus-headers.x86_643.10.0-693.17.1.el7.centos.plus centosplus kernel-plus-tools.x86_64 3.10.0-693.17.1.el7.centos.plus centosplus kernel-plus-tools-libs.x86_64 3.10.0-693.17.1.el7.centos.plus centosplus kernel-plus-tools-libs-devel.x86_64 3.10.0-693.17.1.el7.centos.plus centosplus perf.x86_64 3.10.0-693.17.1.el7.centos.plus centosplus postfix.x86_642:2.10.1-6.0.1.el7.centos centosplus postfix-perl-scripts.x86_64 2:2.10.1-6.0.1.el7.centos centosplus postfix-sysvinit.noarch 2:2.10.1-6.0.1.el7.centos centosplus python-perf.x86_643.10.0-693.17.1.el7.centos.plus centosplus $ first, i always thought "yum list available" would list only packages that i did not *already* have installed, and if i wanted to list installed packages eligible for update, i would run: $ yum list updates --disablerepo=\* --enablerepo=centosplus Updated Packages postfix.x86_642:2.10.1-6.0.1.el7.centos centosplus python-perf.x86_643.10.0-693.17.1.el7.centos.plus centosplus $ as you can see, the alleged updates are also listed as "available" from the first command -- has it always been this way? if so, i guess i just never noticed. (is there a way to list *only* available, uninstalled packages with some sort of filter?) more curiously, some of the available packages from the centosplus repo have a package version that says merely "centos", not "centos.plus": postfix.x86_642:2.10.1-6.0.1.el7.centos centosplus postfix-perl-scripts.x86_64 2:2.10.1-6.0.1.el7.centos centosplus postfix-sysvinit.noarch 2:2.10.1-6.0.1.el7.centos centosplus ^^ is that deliberate? it would seem to have the potential for confusion if one searches later for packages based on that string. finally, the alleged update for python-perf: python-perf.x86_643.10.0-693.17.1.el7.centos.plus centosplus would seem to match *exactly* the currently installed numeric version on my system: $ rpm -q python-perf python-perf-3.10.0-693.17.1.el7.x86_64 $ that is, both seem to be "3.10.0-693.17.1.el7", so how would this constitute an available "update"? perhaps there's something fundamental about version numbering and the centosplus repo i'm missing here. rday ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux breaks Squid's ssl_crtd helper
On 03/09/2018 05:18 AM, Nicolas Kovacs wrote: Do allow this access for now by executing: # ausearch -c 'ssl_crtd' --raw | audit2allow -M my-sslcrtd # semodule -i my-sslcrtd.pp Unfortunately the suggested solution doesn't work Start by running "ausearch -c 'ssl_crtd' --raw" by itself. Try to determine whether or not all of the affected files are mentioned in that output. Typically, to generate a complete policy, you'll need to run in permissive mode while you operate the system, so that all of the things that you want to allow are recorded. Many services that need a new policy will generate more than one AVC denial, and in enforcing mode they'll terminate or at least cease processing the labeled resources that they need after the first denial. In permissive mode, you should get a better list of exceptions that are required, because AVCs are recorded, but the application isn't actually denied permission to those resources. When your logs are complete, remove the old module and generate a new one according to the directions from sealert. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] kpartx can not detach
Am 07.03.2018 um 19:35 schrieb Jim Perrin : > > On 03/07/2018 04:48 AM, Leon Fauster wrote: >> OS: EL6 - sometimes I use >> >> kpartx -a /mnt/.../lvdisk.img >> >> to map the partitions and mount them via >> >> /dev/mapper/loop0pX >> >> After using the disk (unmounting it) I noticed that >> detaching such mapping via kpartx -d does not result >> in freeing up the loop devices. Results: System reboots >> shows that the filesystem where lvdisk.img is located >> can't be unmounted. >> >> lsof, fuser, ps does not show any usage. Even removing the >> device node via >> >> dmsetup remove /dev/mapper/loop0pX >> >> does not help. Trying to unmount the underlying filesystem >> still shows /mnt: device is busy. >> >> Any other suggestions would be greatly appreciated! > > > Do you have an open shell/terminal session hanging out in the /mnt > directory you used? With some heuristic I got following results (briefly): Jumping into the image/file directory and adding the partition map (kpartx -a) and removing it (kpartx -d) works! So the output of losetup between this two activities shows: losetup -a /dev/loop0: [0821]:130822 (kvm-system-centos6_x86_64-devel-lv_vm_intern_spare.img) but when adding the partition map with an absolut _long_ path detaching/deleting the map doesn't work. losetup -a /dev/loop0: [0821]:130822 (/mnt/pool/VirtLibrary/3-live/kvm-system-centos6_x86_64-devel-l*) shortening the path and adding the partition map with an absolut path and removing it works again. losetup -a /dev/loop0: [0821]:130822 (/mnt/kvm-system-centos6_x86_64-devel-lv_vm_intern_spare.img) So, is kpartx or the underlying loop handle limited to a 64 character long file pointer? Anyway, at least I can work around it ... -- LF ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux breaks Squid's ssl_crtd helper
Le 10/03/2018 à 18:18, Gordon Messmer a écrit : > Start by running "ausearch -c 'ssl_crtd' --raw" by itself. Try to > determine whether or not all of the affected files are mentioned in that > output. > > Typically, to generate a complete policy, you'll need to run in > permissive mode while you operate the system, so that all of the things > that you want to allow are recorded. Many services that need a new > policy will generate more than one AVC denial, and in enforcing mode > they'll terminate or at least cease processing the labeled resources > that they need after the first denial. In permissive mode, you should > get a better list of exceptions that are required, because AVCs are > recorded, but the application isn't actually denied permission to those > resources. > > When your logs are complete, remove the old module and generate a new > one according to the directions from sealert. OK, I found the solution. This is actually a bug in Squid's default SELinux policy, but it can be corrected manually. https://blog.microlinux.fr/squid-https-centos/#configuration Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
