Re: [SCIENTIFIC-LINUX-USERS] Calibre current

[Pat Riehecky]

Perhaps a flatpak?

https://flathub.org/apps/details/com.calibre_ebook.calibre

On 1/30/20 11:04 AM, Yasha Karant wrote:

I attempted to upgrade Calibre to the current production release.  It
fails to run (I can post my question) but the response given is:

SL7 is based on RHEL7 and uses GCC 4.9 (see
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_solutions_19458&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=VIryM0aQaNiX0n1xowynI6HPID-GSk5v8GbrCq2fldM&s=eWpq7f1FsG6R3tgnKBPi__pLLLgTrtRmzb2uWLpjkWg&e=
 ).

Solution?: wait for RHEL8, install a proper desktop linux distro or
follow 
https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.redhat.com_blog_2...gcc-2D8-2Dclang-2D6_&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=VIryM0aQaNiX0n1xowynI6HPID-GSk5v8GbrCq2fldM&s=H94UEqdoz0IpzxgBa16hgbaiKAzxsoIQhIrbgUt9XbM&e=

End quote.

I always thought that SL was a proper desktop (user interface GUI)
Linux, and not just Debian/Ubuntu derivatives or SUSE.

Calibre needs RuntimeError: Failed to load icu with error:
/lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by
/opt/calibre/lib/libicui18n.so.64)

Is the required lib available for SL7 without disrupting the OS per se?

If not, does anyone know the last Calibre that does work with SL7?

Any help would be appreciated.

Yasha Karant
ykar...@gmail.com


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Security ERRATA Important: kernel on SL6.x i386/x86_64

[Pat Riehecky]

That is correct, one fixes a CPU bug and another fixes the GPU bug.

Pat

On 11/14/19 1:13 PM, Steven C Timm wrote:

is that right--2 different SL6 kernel updates in 2 days?

Steve


*From:* owner-scientific-linux-err...@listserv.fnal.gov 
 on behalf of Farhan 
Ahmed 

*Sent:* Thursday, November 14, 2019 12:16 PM
*To:* scientific-linux-errata 
*Subject:* Security ERRATA Important: kernel on SL6.x i386/x86_64
Synopsis:  Important: kernel security update
Advisory ID:   SLSA-2019:3878-1
Issue Date:    2019-11-14
CVE Numbers:   CVE-2019-0155
--

Security Fix(es):

* hw: Intel GPU blitter manipulation can allow for arbitrary kernel memory
write (CVE-2019-0155)

For more details about the security issue(s), including the impact, a CVSS
score, acknowledgments, and other related information, refer to the CVE
page(s) listed in the References section.

--

SL6
  x86_64
    kernel-2.6.32-754.24.3.el6.x86_64.rpm
    kernel-debug-2.6.32-754.24.3.el6.x86_64.rpm
    kernel-debug-debuginfo-2.6.32-754.24.3.el6.i686.rpm
    kernel-debug-debuginfo-2.6.32-754.24.3.el6.x86_64.rpm
    kernel-debug-devel-2.6.32-754.24.3.el6.i686.rpm
    kernel-debug-devel-2.6.32-754.24.3.el6.x86_64.rpm
    kernel-debuginfo-2.6.32-754.24.3.el6.i686.rpm
    kernel-debuginfo-2.6.32-754.24.3.el6.x86_64.rpm
kernel-debuginfo-common-i686-2.6.32-754.24.3.el6.i686.rpm
kernel-debuginfo-common-x86_64-2.6.32-754.24.3.el6.x86_64.rpm
    kernel-devel-2.6.32-754.24.3.el6.x86_64.rpm
    kernel-headers-2.6.32-754.24.3.el6.x86_64.rpm
    perf-2.6.32-754.24.3.el6.x86_64.rpm
    perf-debuginfo-2.6.32-754.24.3.el6.i686.rpm
    perf-debuginfo-2.6.32-754.24.3.el6.x86_64.rpm
    python-perf-debuginfo-2.6.32-754.24.3.el6.i686.rpm
    python-perf-debuginfo-2.6.32-754.24.3.el6.x86_64.rpm
    python-perf-2.6.32-754.24.3.el6.x86_64.rpm
  i386
    kernel-2.6.32-754.24.3.el6.i686.rpm
    kernel-debug-2.6.32-754.24.3.el6.i686.rpm
    kernel-debug-debuginfo-2.6.32-754.24.3.el6.i686.rpm
    kernel-debug-devel-2.6.32-754.24.3.el6.i686.rpm
    kernel-debuginfo-2.6.32-754.24.3.el6.i686.rpm
kernel-debuginfo-common-i686-2.6.32-754.24.3.el6.i686.rpm
    kernel-devel-2.6.32-754.24.3.el6.i686.rpm
    kernel-headers-2.6.32-754.24.3.el6.i686.rpm
    perf-2.6.32-754.24.3.el6.i686.rpm
    perf-debuginfo-2.6.32-754.24.3.el6.i686.rpm
    python-perf-debuginfo-2.6.32-754.24.3.el6.i686.rpm
    python-perf-2.6.32-754.24.3.el6.i686.rpm
  noarch
    kernel-abi-whitelists-2.6.32-754.24.3.el6.noarch.rpm
    kernel-doc-2.6.32-754.24.3.el6.noarch.rpm
    kernel-firmware-2.6.32-754.24.3.el6.noarch.rpm

- Scientific Linux Development Team


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Missing zoneinfo files in sl:7 docker image

[Pat Riehecky]

I've got a new container build staged up : 
https://github.com/docker-library/official-images/pull/6824


This will ship the full tzdata zone list.  I will recommend bind 
mounting the zoneinfo from the host to ensure all files are updated, but 
this provides a suitable fallback.


Pat

On 10/18/19 9:30 AM, Pat Riehecky wrote:

I'll take a look.

I believe the initial plan was to pull zone info in via something 
dynamic from the host, but I don't honestly remember...


Pat

On 10/18/19 5:02 AM, Duncan MacLeod wrote:

Hi all,

I think there's an issue with the sl:7 docker image (at least the one 
that's available as of today, Oct 18 2019, digest included below), 
namely that tzdata is quoted as installed, but the actual contents of 
that package aren't there. This breaks functionality in 
python-dateutil, which is unfortunate. If I yum reinstall tzdata, 
this resolves the issue. A verbose terminal output that demonstrates 
the problem is included below.


Can this image be rebuilt so that the files are present? Apologies if 
this is the wrong place to report bugs*.



Thanks
Duncan

*the dockerhub page for sl (https://hub.docker.com/_/sl 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__hub.docker.com_-5F_sl&d=DwMGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=ZMb0auIJuVlRjqQ0G-k96lwDm1D3P8ZpSMXKo03iiEA&s=CUyJ2djp5M5iniuhQrqgXwS9RzUrWsTODF1BfPDxSXg&e=>) 
tells me to report issues to 
(https://github.com/scientificlinux/sl-docker/issues 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_scientificlinux_sl-2Ddocker_issues&d=DwMGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=ZMb0auIJuVlRjqQ0G-k96lwDm1D3P8ZpSMXKo03iiEA&s=6PBzqzmX4C9nV2F0NBMlLSMP6MYeq5fUG5Xwq1PjqeU&e=>), 
but that link redirects to the equivalent pulls page because the repo 
has issues disabled)


$ docker run -it sl:7
Unable to find image 'sl:7' locally
7: Pulling from library/sl
2eea7837af89: Already exists
Digest: 
sha256:9670b9e70c98c9617ad5e804e481788f17b7efc2d63b006e9732fd8fabd866e3

Status: Downloaded newer image for sl:7
[root@3bcb3a5d96cd /]# yum -y -q update
[root@3bcb3a5d96cd /]# yum list installed | grep tzdata
tzdata.noarch                             2019c-1.el7          installed
[root@3bcb3a5d96cd /]# yum install tzdata
Loaded plugins: ovl
Package tzdata-2019c-1.el7.noarch already installed and latest version
Nothing to do
[root@3bcb3a5d96cd /]# ls -lrt /usr/share/zoneinfo
ls: cannot access /usr/share/zoneinfo: No such file or directory
[root@3bcb3a5d96cd /]# yum reinstall tzdata
Loaded plugins: ovl
Resolving Dependencies
--> Running transaction check
---> Package tzdata.noarch 0:2019c-1.el7 will be reinstalled
--> Finished Dependency Resolution

Dependencies Resolved


 Package             Arch                Version       Repository     
           Size


Reinstalling:
 tzdata              noarch              2019c-1.el7       
sl-security              475 k


Transaction Summary

Reinstall  1 Package

Total download size: 475 k
Installed size: 1.9 M
Is this ok [y/d/N]: y
Downloading packages:
tzdata-2019c-1.el7.noarch.rpm                | 475 kB  00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : tzdata-2019c-1.el7.noarch                             
     1/1
  Verifying  : tzdata-2019c-1.el7.noarch                             
     1/1


Installed:
  tzdata.noarch 0:2019c-1.el7

Complete!
[root@3bcb3a5d96cd /]# ls -lrt /usr/share/zoneinfo
total 432
-rw-r--r--  1 root root   4463 Feb 19  2019 iso3166.tab

--
Duncan Macleod
macleo...@cardiff.ac.uk <mailto:macleo...@cardiff.ac.uk>| 
macleo...@caerdydd.ac.uk <mailto:macleo...@caerdydd.ac.uk>

Sêr Cymru COFUND Fellow| Cymrawd Sêr Cymru COFUND
Cardiff University Gravity Exploration Institute| Sefydliad Archwilio 
Disgyrchiant Prifysgol Caerdydd


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Missing zoneinfo files in sl:7 docker image

[Pat Riehecky]

I'll take a look.

I believe the initial plan was to pull zone info in via something 
dynamic from the host, but I don't honestly remember...


Pat

On 10/18/19 5:02 AM, Duncan MacLeod wrote:

Hi all,

I think there's an issue with the sl:7 docker image (at least the one 
that's available as of today, Oct 18 2019, digest included below), 
namely that tzdata is quoted as installed, but the actual contents of 
that package aren't there. This breaks functionality in 
python-dateutil, which is unfortunate. If I yum reinstall tzdata, this 
resolves the issue. A verbose terminal output that demonstrates the 
problem is included below.


Can this image be rebuilt so that the files are present? Apologies if 
this is the wrong place to report bugs*.



Thanks
Duncan

*the dockerhub page for sl (https://hub.docker.com/_/sl 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__hub.docker.com_-5F_sl&d=DwMGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=ZMb0auIJuVlRjqQ0G-k96lwDm1D3P8ZpSMXKo03iiEA&s=CUyJ2djp5M5iniuhQrqgXwS9RzUrWsTODF1BfPDxSXg&e=>) 
tells me to report issues to 
(https://github.com/scientificlinux/sl-docker/issues 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_scientificlinux_sl-2Ddocker_issues&d=DwMGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=ZMb0auIJuVlRjqQ0G-k96lwDm1D3P8ZpSMXKo03iiEA&s=6PBzqzmX4C9nV2F0NBMlLSMP6MYeq5fUG5Xwq1PjqeU&e=>), 
but that link redirects to the equivalent pulls page because the repo 
has issues disabled)


$ docker run -it sl:7
Unable to find image 'sl:7' locally
7: Pulling from library/sl
2eea7837af89: Already exists
Digest: 
sha256:9670b9e70c98c9617ad5e804e481788f17b7efc2d63b006e9732fd8fabd866e3

Status: Downloaded newer image for sl:7
[root@3bcb3a5d96cd /]# yum -y -q update
[root@3bcb3a5d96cd /]# yum list installed | grep tzdata
tzdata.noarch                             2019c-1.el7        installed
[root@3bcb3a5d96cd /]# yum install tzdata
Loaded plugins: ovl
Package tzdata-2019c-1.el7.noarch already installed and latest version
Nothing to do
[root@3bcb3a5d96cd /]# ls -lrt /usr/share/zoneinfo
ls: cannot access /usr/share/zoneinfo: No such file or directory
[root@3bcb3a5d96cd /]# yum reinstall tzdata
Loaded plugins: ovl
Resolving Dependencies
--> Running transaction check
---> Package tzdata.noarch 0:2019c-1.el7 will be reinstalled
--> Finished Dependency Resolution

Dependencies Resolved


 Package             Arch                Version     Repository       
         Size


Reinstalling:
 tzdata              noarch              2019c-1.el7     sl-security   
           475 k


Transaction Summary

Reinstall  1 Package

Total download size: 475 k
Installed size: 1.9 M
Is this ok [y/d/N]: y
Downloading packages:
tzdata-2019c-1.el7.noarch.rpm              | 475 kB  00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : tzdata-2019c-1.el7.noarch                               
 1/1
  Verifying  : tzdata-2019c-1.el7.noarch                               
 1/1


Installed:
  tzdata.noarch 0:2019c-1.el7

Complete!
[root@3bcb3a5d96cd /]# ls -lrt /usr/share/zoneinfo
total 432
-rw-r--r--  1 root root   4463 Feb 19  2019 iso3166.tab

--
Duncan Macleod
macleo...@cardiff.ac.uk <mailto:macleo...@cardiff.ac.uk>| 
macleo...@caerdydd.ac.uk <mailto:macleo...@caerdydd.ac.uk>

Sêr Cymru COFUND Fellow| Cymrawd Sêr Cymru COFUND
Cardiff University Gravity Exploration Institute| Sefydliad Archwilio 
Disgyrchiant Prifysgol Caerdydd


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Security ERRATA Moderate: cockpit on SL7.x x86_64

[Pat Riehecky]

I believe that SL7 is currently in sync with what RH publishes.  The 
cockpit packages are a bit of a mess in what they produce and if they go 
into extras, base, or neither


Pat

On 9/3/19 2:17 PM, Peed, Andrew (GE Healthcare) wrote:

I notice that cockpit-selinux, cockpit-packagekit, and cockpit-tests were not 
included in this update. Will those packages be rebuilt so that they stay in 
sync?

Thanks,
-- Andy

-Original Message-
From: owner-scientific-linux-err...@listserv.fnal.gov 
 On Behalf Of Farhan Ahmed
Sent: Wednesday, March 13, 2019 12:38 PM
To: scientific-linux-err...@listserv.fnal.gov
Subject: EXT: Security ERRATA Moderate: cockpit on SL7.x x86_64

Synopsis: Moderate: cockpit security update
Advisory ID:   SLSA-2019:0482-1
Issue Date:2019-03-13
CVE Numbers:   CVE-2019-3804
--

Security Fix(es):

* cockpit: Crash when parsing invalid base64 headers (CVE-2019-3804)
--

SL7
   x86_64
 cockpit-173.2-1.el7.x86_64.rpm
 cockpit-bridge-173.2-1.el7.x86_64.rpm
 cockpit-debuginfo-173.2-1.el7.i686.rpm
 cockpit-debuginfo-173.2-1.el7.x86_64.rpm
 cockpit-ws-173.2-1.el7.i686.rpm
 cockpit-ws-173.2-1.el7.x86_64.rpm
 cockpit-doc-173.2-1.el7.x86_64.rpm
 cockpit-173.2-1.el7.src.rpm
   noarch
 cockpit-system-173.2-1.el7.noarch.rpm
 cockpit-machines-ovirt-173.2-1.el7.noarch.rpm

- Scientific Linux Development Team


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] SL 7.7 Isos - Naming Issue

[Pat Riehecky]

Good catch, I'll get those fixed up shortly.

Pat

On 8/23/19 2:36 PM, S. Tindall wrote:
There appears to be a 7.6 vs 7.7 naming issue with the DVD isos on the 
mirrors in the .../7.7/... channel:


 Scientific-7.6-Install-Dual-Layer-DVD-x86_64.iso   14-Aug-2019  
14:11  8.0G

 Scientific-7.7-Everything-DVD-x86_64.iso 14-Aug-2019  14:48  9.8G

Since both are recent dates, I suspect a simple naming issue.

Steve


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] XFS memory allocation deadlock

[Pat Riehecky]

I believe the solution is two fold:

- The SL 7.7 kernel will help prevent the problem from reoccurring 
(currently in sl-testing, scheduled for release Monday)

- Existing fragmentation should probably be cleaned up via xfs_fsr[1]

Pat

[1] 
https://blog.codecentric.de/en/2017/04/xfs-possible-memory-allocation-deadlock-kmem_alloc/


On 8/21/19 8:10 PM, Bill Maidment wrote:

Hi
During copying a large file (about 200GB) to a backup hard drive, I am 
getting a multitude of XFS possible memory allocation deadlock messages.

RedHat Portal shows the following:

XFS issues "possible memory allocation deadlock in kmem_alloc" messages
Solution Verified - Updated August 9 2019 at 2:51 AM - English
Issue

    Seeing file system access issues on XFS based file systems.
    dmesg shows continuous entries with:

    XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250)

Does anyone know what the solution is? And if SL7 will get this 
solution soon?




--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Yum update problem

[Pat Riehecky]

Hello,

I believe xorgxrdp is coming from EPEL, which is built against the 7.7 
errata.


I've got the 7.7 security errata staged up in sl-testing.  It is 
scheduled for release next week.


Pat

On 8/18/19 8:39 PM, jdowjunkm...@earthlink.net wrote:

/etc/cron.daily/0yum-daily.cron:

Failed to check for updates with the following error message:
Failed to build transaction: xorgxrdp-0.2.10-4.el7.x86_64 requires 
xorg-x11-server-Xorg(x86-64) = 1.20.4



{^_^} Joanne


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Kickstart for uEFI boot

[Pat Riehecky]

I've attached a slightly edited kickstart from my last EFI test 
install.  It seems to work for me


Pat

On 8/14/19 2:34 PM, Glenn (Gedaliah) Wolosh wrote:

Hi,

Just got a brandy new Dell which only supports uEFI boot for internal 
disk. Been tearing my hair out trying to get this to work with my 
kickstart. I either get “No bootable devices found” or or a grub> 
prompt. Does anyone have a working kickstart configuration for uEFI 
boot I can start from?


Thanks.
___
Gedaliah Wolosh
Senior Academic and Research Computing Specialist
IST Academic and Research Computing Systems (ARCS)
NJIT
GITC 2203
973 596 5437
gwol...@njit.edu <mailto:gwol...@njit.edu>



--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

#version=DEVEL
# System authorization information
auth --enableshadow --passalgo=sha512
# Use network installation
url --url="http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/os/";
repo --name="security" 
--baseurl=http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/updates/security/

# Use graphical install
graphical
# Run the Setup Agent on first boot
firstboot --enable
ignoredisk --only-use=sda
# Keyboard layouts
keyboard --vckeymap=us --xlayouts='us'
# System language
lang en_US.UTF-8

# Network information
network  --bootproto=dhcp

# Root password
rootpw --iscrypted $6$byb.gIcR5V$ky
# System services
services --enabled="chronyd"
# System timezone
timezone America/Chicago --isUtc

# X Window System configuration information
xconfig  --startxonboot
# System bootloader configuration
bootloader --append=" crashkernel=auto" --location=mbr --boot-drive=sda
# Partition clearing information
clearpart --initlabel --list=sda4
# Disk partitioning information
part /boot/efi --fstype="efi" --onpart=sda2 
--fsoptions="umask=0077,shortname=winnt" --label=EFI
part pv.323 --fstype="lvmpv" --ondisk=sda --size=237199
part biosboot --fstype="biosboot" --noformat --onpart=sda1
part /boot --fstype="xfs" --onpart=sda3 --label=/boot
volgroup scientific --pesize=4096 pv.323
logvol swap  --fstype="swap" --size=8192 --name=swap --vgname=scientific
logvol /  --fstype="xfs" --size=204800 --label="/" --name=root 
--vgname=scientific

%packages
@^general-purpose-system
@base
@core
@fonts
@gnome-desktop
@guest-agents
@guest-desktop-agents
@input-methods
@internet-browser
@multimedia
@print-client
@x11
chrony
kexec-tools
yum

%end

Re: [SCIENTIFIC-LINUX-USERS] No Scientific Linux 8 planned?

[Pat Riehecky]

Hello,

Since the announcement we've been working with the CentOS folks as well 
as our counterparts at CERN to integrate our work and expertise.


Thus far the SL team has been active in assistance with the CentOS 8 QA 
process and OS customization.


We intend to keep these lists open at least until the end of life for SL7.

Pat

On 8/3/19 6:45 PM, Nico Kadel-Garcia wrote:

Looking back, I see that there is no plan to publish a Scientific
Linux 8 release, and Fermilabs will be using CentOS 8 going forward.

I hope the developers and support that Scientific Linux has had can be
migrated to the CentOS community, and that Red Hat is improved by the
result. I especially hope that the recent purchase of Red Hat by IBM
is good for the work people have done and appreciated.

Is there any plan to shut down these mailing lsists? It's been really
quitet out there.

Nico Kadel-Garcia


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Problem with recent docker packages?

[Pat Riehecky]

I've dropped a possible fix package in the sl-testing repo.

Can you try it to see if this resolves your issue?

On 6/10/19 1:05 PM, Pat Riehecky wrote:

I'll look into this.

Pat

On 6/10/19 9:59 AM, Phil Gold wrote:

I've been having two problems with the newest docker packages in the
sl-extras repository for Scientific Linux 7.  I'm not sure where to 
report

them so hopefully someone here will help.


The first problem appears to be one of packaging.  The systemd unit file
for docker-1.13.1-96.gitb2f74b2.sl7.x86_64 contains references to
`rhel-push-plugin.socket`, which is not present in any Scientific Linux
packages, as far as I can tell.  I have to remove all references to that
unit file in order to start docker.  The previous RPM
(1.13.1-94.gitb2f74b2.sl7) did not have this problem.


The second problem is that I cannot `docker exec` things in some (but 
not
all) of my containers.  For the ones that fail, I get the following 
error

message:

 rpc error: code = 2 desc = oci runtime error: exec failed: 
container_linux.go:235: starting container process caused 
"process_linux.go:110: decoding init error from pipe caused \"read 
parent: connection reset by peer\""


This looks to me a lot like bug #1655214 in the Red Hat Bugzilla:

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1655214&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=cUDmEKgsvyvfXqxPWpSYuUAAT0eU2MkIq2JcEGVEAUY&s=td7JS4nXUFG8wQzmEEoEIlnKTwj8InHnoIurYBnXeX4&e=

Unfortunately, that bug was closed with Red Hat's 
1.13.1-88git07f3374.el7

docker RPM, whereas I'm seeing problems with Scientific Linux's
1.13.1-96.gitb2f74b2.sl7 and 1.13.1-94.gitb2f74b2.sl7 docker RPMs.

Is it possible I'm doing something wrong, or is this a bug that 
should be
reported?  If it's a bug, where should I report it (and my other 
problem)?

I haven't found anything for Scientific Linux like Red Hat's Bugzilla
instance.

Just in case it's relevant, I have four different images I've tested
things with.  All of them are from the Docker Hub registry.

  * mariadb:10 has problems.  It's ultimately based on ubuntu:bionic.

  * mediawiki:1.31 has problems.  It's ultimately based on
    debian:stretch-slim.

  * centos/httpd-24-centos7 does not have problems.  It's ultimately 
based

    on centos:7.

  * dperson/samba:latest has problems.  It's ultimately based on
    alpine:latest.

`docker exec` works properly on all of them when I'm using the
docker-1.13.1-91.git07f3374.sl7 RPM from the sl-extras repository.  The
problems consistently appear, both in my images and in the base images,
with any later RPMs.





--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Problem with recent docker packages?

[Pat Riehecky]

I'll look into this.

Pat

On 6/10/19 9:59 AM, Phil Gold wrote:

I've been having two problems with the newest docker packages in the
sl-extras repository for Scientific Linux 7.  I'm not sure where to report
them so hopefully someone here will help.


The first problem appears to be one of packaging.  The systemd unit file
for docker-1.13.1-96.gitb2f74b2.sl7.x86_64 contains references to
`rhel-push-plugin.socket`, which is not present in any Scientific Linux
packages, as far as I can tell.  I have to remove all references to that
unit file in order to start docker.  The previous RPM
(1.13.1-94.gitb2f74b2.sl7) did not have this problem.


The second problem is that I cannot `docker exec` things in some (but not
all) of my containers.  For the ones that fail, I get the following error
message:

 rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:235: starting 
container process caused "process_linux.go:110: decoding init error from pipe caused 
\"read parent: connection reset by peer\""

This looks to me a lot like bug #1655214 in the Red Hat Bugzilla:

   
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1655214&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=cUDmEKgsvyvfXqxPWpSYuUAAT0eU2MkIq2JcEGVEAUY&s=td7JS4nXUFG8wQzmEEoEIlnKTwj8InHnoIurYBnXeX4&e=

Unfortunately, that bug was closed with Red Hat's 1.13.1-88git07f3374.el7
docker RPM, whereas I'm seeing problems with Scientific Linux's
1.13.1-96.gitb2f74b2.sl7 and 1.13.1-94.gitb2f74b2.sl7 docker RPMs.

Is it possible I'm doing something wrong, or is this a bug that should be
reported?  If it's a bug, where should I report it (and my other problem)?
I haven't found anything for Scientific Linux like Red Hat's Bugzilla
instance.

Just in case it's relevant, I have four different images I've tested
things with.  All of them are from the Docker Hub registry.

  * mariadb:10 has problems.  It's ultimately based on ubuntu:bionic.

  * mediawiki:1.31 has problems.  It's ultimately based on
debian:stretch-slim.

  * centos/httpd-24-centos7 does not have problems.  It's ultimately based
on centos:7.

  * dperson/samba:latest has problems.  It's ultimately based on
alpine:latest.

`docker exec` works properly on all of them when I'm using the
docker-1.13.1-91.git07f3374.sl7 RPM from the sl-extras repository.  The
problems consistently appear, both in my images and in the base images,
with any later RPMs.



--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Rsync issue with SL7 repository

[Pat Riehecky]

Hello,

I'm not showing anything weird going on with rsync today.

I'll see about kicking the daemon just to be safe

Pat

On 1/2/19 10:04 PM, Bill Maidment wrote:

Hi
If anyone is not on holiday, is there a problem with the rsync server?
I've received the following errors twice today.

 Getting SL7x/x86_64/iso   at: Thu Jan  3 13:16:27 AEDT 2019
receiving incremental file list

sent 43 bytes  received 119 bytes  46.29 bytes/sec
total size is 3,030  speedup is 18.70
receiving incremental file list
Scientific-7.6-Everything-DVD-x86_64.iso
rsync: connection unexpectedly closed (4845638 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) 
[receiver=3.1.2]
rsync: connection unexpectedly closed (62 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) 
[generator=3.1.2]


Cheers
Bill Maidment


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Problems with radeon since Xorg 1.20 updates

[Pat Riehecky]

I'd be surprised in the patch[1] made any difference on Radeon systems.  
The code there is really only related to udev probing.


There was a large jump in the ati driver from 7.5 to 7.6.  My initial 
thoughts are in that direction...


Pat

[1] 
https://gitlab.freedesktop.org/xorg/xserver/commit/0816e8fca6194dfb4cc94c3a7fcb2c7f2a921386


On 12/3/18 11:29 AM, Gilles Detillieux wrote:
Thanks for the feedback, Andreas. That saves me some testing time. It 
looks like the security bug 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_security_cve_cve-2D2018-2D14665&d=DwIDbA&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=VStRhNQ03emrmYLjFAIDre-xzZT0Ho_w1biFWTQSbtc&s=pGQ8kJ1ceFEdtE90n9wkzNyf0BcBKbllIvhnPdeLWjc&e=) 
needs physical access to the console to exploit. Fortunately that 
shouldn't be a problem in our environment, where the users are more 
interested in hacking neurons.


I noticed in the Errata message for the xorg-x11-server update, it 
says "The SL Team added a fix for upstream bug 1650634". I'm wondering 
if this bug fix 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1650634&d=DwIDbA&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=VStRhNQ03emrmYLjFAIDre-xzZT0Ho_w1biFWTQSbtc&s=vz7Ui2PF_YcxXFRgPhPceXRL1HuDpy8255vaqI-vmbE&e=) 
broke things for the Radeon drivers. Seems a more likely cause than 
the CVE fix for an argument handling issue. That fix was to support 
the SL 7.6 upgrade on nVidia hardware. I'll have to see if the 7.6 
upgrade (now available) makes the problem go away for the radeon 3000. 
If not, I'll likely downgrade Xorg to 1.19 on our systems till I hear 
of a fix for this.


Thanks again,
Gilles

On 2018-12-03 10:52, Andreas Nowack wrote:
I would exclude the kernel as source of the problem since downgrade 
to Xorg 1.19 removes all the error messages and problems. (But due to 
security bugs, Xorg 1.19 is not a real option).


Best regards,
  Andreas






--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

SL 7.6 RC 2 x86_64 is now available for testing

[Pat Riehecky]

Scientific Linux 7.6 RC x86_64

These are the notes for the "RC" of Scientific Linux 7.6

Please also review TUV's 7.6 Release Notes for major upstream changes.

This will be published as SL 7.6 on Dec 3 2018 unless any critical bugs
are reported.

--

THIS IS NOT FOR PRODUCTION.

This is for testing.  Please report back any issues to

    scientific-linux-de...@fnal.gov


DOWNLOAD

http://ftp.scientificlinux.org/linux/scientific/7.6/x86_64/os/images/boot.iso
http://ftp.scientificlinux.org/linux/scientific/7.6/x86_64/iso/

---

Major Differences from Upstream 7.6



Scientific Linux features the Xorg fix listed in bugzilla 1650634.

---

Major Differences from SL 7.5



sl-release is updated to use the 7.6 repos.

PackageKit has initial support for notification of SL7 minor release 
upgrades.

  To use this feature you must install sl7-upgrade.



KNOWN ISSUES



Cinnamon desktop from EPEL7 prevents upgrades due to caribou and gnome-shell
https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/thread/3URMFE6D4AYY3B2PIS5KS6PVDJIADO2L/ 

Re: [SCIENTIFIC-LINUX-USERS] Yum update issue

[Pat Riehecky]

I'm showing xorgxrdp-0.2.8-3.el7.x86_64 is an EPEL7 package which is 
tracking RHEL7 and has RHSA-2018:3410, and RHSA-2018:3059.


The SL equivalent packages are on hold pending 
https://bugzilla.redhat.com/show_bug.cgi?id=1650634


There are packages available in the sl-testing repo, but I'd recommend 
reading the bugzilla in full.


Pat

On 11/21/18 12:35 PM, jdow wrote:

Four days running on SL7x:


Failed to check for updates with the following error message:
Failed to build transaction: xorgxrdp-0.2.8-3.el7.x86_64 requires 
xorg-x11-server-Xorg(x86-64) = 1.20.1



Latest available, and installed, is 1.19.5-5.el7

{^_^}   Joanne


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

SL7.6 RC, SLSA-2018:3410, and SLSA-2018:3059 on hold

[Pat Riehecky]

Internal testing uncovered a critical bug with SLSA-2018:3410 and 
SLSA-2018:3059 on systems with nVidia hardware.


With some nVidia cards running the nouveau driver X fails to start and 
Xorg.0.log contains a large number of errors[1].


This bug can be replicated on TUV's 7.6 install media.

We've filed a bug upstream[2] to see about addressing this issue.

Until a clear workaround is discovered, the SL7.6 release, 
SLSA-2018:3410, and SLSA-2018:3059 are on hold.


Other published SL7.6 errata will be published as projected on November 
26 2018.


The proprietary nVidia driver[3] is not impacted by this bug.

Thanks for you patience,
SL Team

[1] (EE) FBDEV(1): FBIOPUTCMAP: Invalid argument
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1650634
[3] kmod-nvidia-340xx-340.107-2.el7_6.elrepo.x86_64 tested from elrepo.org

--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] kickstart & kdump

[Pat Riehecky]

I can recommend: 
https://rhinstaller.github.io/anaconda-addon-development-guide/


On 11/01/2018 12:21 PM, Stephen Berg (Code 7309) wrote:

Thanks, that appears to be exactly what I was looking for.

Now to dig more into addon's since I haven't spun up on them yet.

On 11/1/18 11:59 AM, Pat Riehecky wrote:

I believe you'll want to add this to your kickstart for SL7:



%addon com_redhat_kdump --disable --reserve-mb='auto'

%end


On 11/01/2018 11:41 AM, Stephen Berg (Code 7309) wrote:
Is there an option to disable kdump from within a kickstart file 
during a pxeboot install? I'd like to default to kdump being 
disabled but haven't found the right option in kickstart to disable 
it automatically.









--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] kickstart & kdump

[Pat Riehecky]

I believe you'll want to add this to your kickstart for SL7:



%addon com_redhat_kdump --disable --reserve-mb='auto'

%end


On 11/01/2018 11:41 AM, Stephen Berg (Code 7309) wrote:
Is there an option to disable kdump from within a kickstart file 
during a pxeboot install? I'd like to default to kdump being disabled 
but haven't found the right option in kickstart to disable it 
automatically.




--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] freeipmi update

[Pat Riehecky]

The sl-release rpm is supposed to fix that as part of the %post scripts.

Alas, it appears there is yet-another-bug there

Pat

On 09/14/2018 09:42 AM, Alec Habig wrote:

Patrick Riehecky writes:

Can I see the output of :
cat /etc/yum/vars/slreleasever

Ahh, that could be it: "7.4".

I did an upgrade-in-place, installing sl-release-7.5-2.sl7.x86_64,
cleaning the yum cache, and updating.  That apparently didn't update
this file.

That file (which is owned by the sl-release package) did not update the
number.  Interestingly,

   $ rpm --verify sl-release

shows no changes to the files.

   $ cat /etc/redhat-release
   Scientific Linux release 7.5 (Nitrogen)

does what you'd expect.

Checking on some other machines that were originally installed as 7.3
and upgraded in place twice, they're at 7.3 also.

Manually changing /etc/yum/vars/slreleasever to 7.5 gets me loads of
updates, including the freeipmi.

So: short summary: upgrading sl-release does change TUV's release tag,
but not the SL release tag file, and does not notice that fact on a
verify.  The procedure which served me well for many 6.x upgrades needs
one more tweak for 7.x upgrades!

Is this expected behavior, or is there somethign to be tweaked with the
sl-release rpm (or its scripts)?

thanks!

    Alec



--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Repository directory permission problem

[Pat Riehecky]

That is very odd

I Show:
[root@testvm linux]# ls -la scientific
total 128
drwxr-xr-x. 29 root root 2048 Jul  5 10:42 .
drwxr-xr-x.  7 root root 2048 Apr  3  2017 ..
lrwxrwxrwx.  1 root root    2 Sep 29  2015 6 -> 6x
drwxr-xr-x.  4 root root 2048 Mar  3  2011 6.0
drwxr-xr-x.  4 root root 2048 Jul 28  2011 6.1
drwxr-xr-x.  4 root root 2048 Jul  5 10:45 6.10
drwxr-xr-x.  4 root root 2048 Feb  7  2012 6.2
drwxr-xr-x.  4 root root 2048 Jul 26  2012 6.3
drwxr-xr-x.  4 root root 2048 Mar 25  2013 6.4
drwxr-xr-x.  4 root root 2048 Jan 22  2014 6.5
drwxr-xr-x.  4 root root 2048 Nov  6  2014 6.6
drwxr-xr-x.  4 root root 2048 Aug 20  2015 6.7
drwxr-xr-x.  4 root root 2048 Jul  8  2016 6.8
drwxr-xr-x.  4 root root 2048 Apr 11  2017 6.9
drwxr-xr-x.  8 root root 2048 Dec 18  2013 6rolling
drwxr-xr-x.  6 root root 2048 Jul 10 09:37 6x
lrwxrwxrwx.  1 root root    2 Oct  3  2014 7 -> 7x
drwxr-xr-x.  3 root root 2048 Oct  3  2014 7.0
drwxr-xr-x.  3 root root 2048 Apr  7  2015 7.1
drwxr-xr-x.  3 root root 2048 Jan 26  2016 7.2
drwxr-xr-x.  3 root root 2048 Jan  9  2017 7.3
drwxr-xr-x.  3 root root 2048 Aug 28  2017 7.4
drwxr-xr-x.  3 root root 2048 May  2 10:01 7.5
drwxr-xr-x.  6 root root 2048 Oct 13  2014 7rolling
drwxr-xr-x.  7 root root 2048 May 10 08:49 7x
drwxr-xr-x.  3 root root 2048 Apr  8  2013 documents
drwxr-xr-x.  5 root root 2048 Sep  7  2010 graphics
drwxr-xr-x. 14 root root 2048 Aug  7 14:06 livecd
drwxr-xr-x.  2 root root 2048 Nov 29  2017 mirrorlist
drwxr-xr-x. 43 root root 4096 Apr  3  2017 obsolete
drwxr-xr-x.  2 root root 6144 Mar 28  2016 stats


On 09/08/2018 01:31 PM, Stuart Anderson wrote:

The repo directories appear to have lost execute permission?


rsync rsync.scientificlinux.org::scientific

drw-r--r--  2,048 2018/07/05 08:42:48 .
lrwxrwxrwx  2 2015/09/29 14:51:55 6
lrwxrwxrwx  2 2014/10/03 14:12:14 7
drw-r--r--  2,048 2011/03/03 08:23:28 6.0
drw-r--r--  2,048 2011/07/28 09:18:49 6.1
drw-r--r--  2,048 2018/07/05 08:45:19 6.10


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] apply automatic updates

[Pat Riehecky]

That is a bit of a complex question.  From the SL side I can point you 
towards: 
http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/release-notes/#_sl_provides_automatic_updates


On 08/10/2018 11:11 AM, Ken Teh wrote:
I noticed that apply_updates in /etc/yum/yum-cron.conf is set to No on 
a centos 7 system while it is set to Yes on SL7x.


Is there any reason not to set to yes for centos?  I have cron job 
that emails the user assigned to the desktop to reboot their machine 
when updates have been installed. With apply_updates set to No, the 
job fails to detect the install with 'yum history'. I can fix this but 
I was wondering if there is some reason why I shouldn't configure the 
daily yum cron the same way, ie, apply_updates=yes.


Thanks.


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Possible Distribution Servers Downtime - July 20 2018 to July 22 2018

[Pat Riehecky]

Hello,

The Scientific Linux distribution servers may be unavailable from Today 
July 20 2018 15:00 CDT (Chicago) until July 22 2018 16:00 CDT(Chicago).


Downloads, yum operations, and mirror syncs may fail against the 
following hosts:


* rsync.scientificlinux.org
* ftp.scientificlinux.org
* ftp1.scientificlinux.org
* ftp2.scientificlinux.org

Additionally www.scientificlinux.org is expected to be unavailable 
during this entire interval.


For your local time you can run:
 date -d '2018-07-20 15:00 CDT'
 date -d '2018-07-22 16:00 CDT'

Thank you for your patience while we perform this maintenance.

SL Team

--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Possible Distribution Servers Downtime - July 20 2018 to July 22 2018

[Pat Riehecky]

Hello,

The Scientific Linux distribution servers may be unavailable from July 
20 2018 15:00 CDT (Chicago) until July 22 2018 16:00 CDT(Chicago).


Downloads, yum operations, and mirror syncs may fail against the 
following hosts:


* rsync.scientificlinux.org
* ftp.scientificlinux.org
* ftp1.scientificlinux.org
* ftp2.scientificlinux.org

Additionally www.scientificlinux.org is expected to be unavailable 
during this entire interval.


For your local time you can run:
 date -d '2018-07-20 15:00 CDT'
 date -d '2018-07-22 16:00 CDT'

Thank you for your patience while we perform this maintenance.

SL Team

--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Scientific Linux 6.10 i386/x86_64 now published

[Pat Riehecky]

I rebuilt the repodata, in theory it should work now with a 'yum clean all'

Pat

On 07/10/2018 10:32 AM, Pat Riehecky wrote:
I'll take a look.  You can remove libreport-plugin-rhtsupport from 
your system as it is not useful for SL systems.


Pat

On 07/10/2018 10:31 AM, Gilbert E. Detillieux wrote:

Anyone else seeing this, when trying to update from 6.9 to 6.10?...

Error: Package: libreport-plugin-rhtsupport-2.0.9-33.el6.x86_64 
(@sl/6.9)

   Requires: libreport = 2.0.9-33.el6
   Removing: libreport-2.0.9-33.el6.x86_64 (@sl/6.9)
   libreport = 2.0.9-33.el6
   Updated By: libreport-2.0.9-34.sl6.x86_64 (sl)
   libreport = 2.0.9-34.sl6

I've done "yum clean expire-cache", and even "yum clean all", and it 
makes no difference regarding the above error.


Gilbert

On 10/07/2018 9:37 AM, Pat Riehecky wrote:

Scientific Linux 6.10 i386/x86_64  July 10, 2018

According to the upstream lifecycle guide, 6.10 is expected to be the
final release of EL6 with only important security errata or critical 
bug

fixes going forward.


Please run:  yum clean expire-cache

Full release notes at 
https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_linux_scientific_6.10_i386_os_sl-2Drelease-2Dnotes-2D6.10.html&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=Q337bL6KDARMFw4xh8_ZxnaCb_SIhuN2shVSpjrlNVg&s=pWnEWYxKTJcsLhOfGK5CciunA9G-2rnzq2a7kljVpjg&e=


--- 


DOWNLOAD INFO
--- 



Install Images:

https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_linux_scientific_6x_i386_iso_&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=Q337bL6KDARMFw4xh8_ZxnaCb_SIhuN2shVSpjrlNVg&s=yIf6--rrEiiHTfLxSae-oI9tAE1AS9pz6a--CUnh3S8&e= 

https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_linux_scientific_6x_x86-5F64_iso_&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=Q337bL6KDARMFw4xh8_ZxnaCb_SIhuN2shVSpjrlNVg&s=oYvjRSZU-zQuG28KEYZyQ8FSluNaqD22nPcAWuDtGMY&e= 



--- 


Major Differences from SL 6.9
---- 



sl-release
 Updated to use the 6.10 repos

OpenAFS
 Updated to 1.6.22.3






--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: Scientific Linux 6.10 i386/x86_64 now published

[Pat Riehecky]

I'll take a look.  You can remove libreport-plugin-rhtsupport from your 
system as it is not useful for SL systems.


Pat

On 07/10/2018 10:31 AM, Gilbert E. Detillieux wrote:

Anyone else seeing this, when trying to update from 6.9 to 6.10?...

Error: Package: libreport-plugin-rhtsupport-2.0.9-33.el6.x86_64 (@sl/6.9)
   Requires: libreport = 2.0.9-33.el6
   Removing: libreport-2.0.9-33.el6.x86_64 (@sl/6.9)
   libreport = 2.0.9-33.el6
   Updated By: libreport-2.0.9-34.sl6.x86_64 (sl)
   libreport = 2.0.9-34.sl6

I've done "yum clean expire-cache", and even "yum clean all", and it 
makes no difference regarding the above error.


Gilbert

On 10/07/2018 9:37 AM, Pat Riehecky wrote:

Scientific Linux 6.10 i386/x86_64  July 10, 2018

According to the upstream lifecycle guide, 6.10 is expected to be the
final release of EL6 with only important security errata or critical bug
fixes going forward.


Please run:  yum clean expire-cache

Full release notes at 
https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_linux_scientific_6.10_i386_os_sl-2Drelease-2Dnotes-2D6.10.html&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=Q337bL6KDARMFw4xh8_ZxnaCb_SIhuN2shVSpjrlNVg&s=pWnEWYxKTJcsLhOfGK5CciunA9G-2rnzq2a7kljVpjg&e=


--- 


DOWNLOAD INFO
--- 



Install Images:

https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_linux_scientific_6x_i386_iso_&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=Q337bL6KDARMFw4xh8_ZxnaCb_SIhuN2shVSpjrlNVg&s=yIf6--rrEiiHTfLxSae-oI9tAE1AS9pz6a--CUnh3S8&e= 

https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_linux_scientific_6x_x86-5F64_iso_&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=Q337bL6KDARMFw4xh8_ZxnaCb_SIhuN2shVSpjrlNVg&s=oYvjRSZU-zQuG28KEYZyQ8FSluNaqD22nPcAWuDtGMY&e= 



--- 


Major Differences from SL 6.9
 



sl-release
     Updated to use the 6.10 repos

OpenAFS
 Updated to 1.6.22.3




--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] SL:7 Rootfs required for ARM64v8

[Pat Riehecky]

On 06/28/2018 05:08 AM, Amrita kumari wrote:

I am working on Docker for SL:7 for Arm64v8 architecture, which has dependency 
over rootfs for SL:7 image.

Can you let me know, how can proceed w.r.t. this?

My current approach is to use CENTOS:7 rootfs for SL:7 and then do required 
modifications.
But this again requires support from Scientific linux community to host mirrors 
and URL to support ARM64v8 at their server just like they are doing it for 
X86_64 architecture.

Do let me know if using CENTOS rootfs is right approach for Docker image or 
should I follow something else to resolve dependency.

Regards,
Amrita


Hello,

We are not currently building for ARM64.  At this time there are no
plans for ARM support for Scientific Linux.


If this changes, we will announce it to the SL community.


Pat

--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Hm - SLBA-2018:1066-1 (from sl-fastbugs) is broken

[Pat Riehecky]

Thanks for the report, I'll have this fixed shortly.

Pat

On 06/28/2018 07:34 AM, jdow wrote:

/etc/cron.daily/0yum-daily.cron:

Update notice SLBA-2018:1066-1 (from sl-fastbugs) is broken, or a bad 
duplicate, skipping.
You should report this problem to the owner of the sl-fastbugs 
repository.
If you are the owner, consider re-running the same command with 
--verbose to see the exact data that caused the conflict.
Update notice SLBA-2018:1424-1 (from sl-fastbugs) is broken, or a bad 
duplicate, skipping.


{^_^}


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] report this problem to the owner of the sl-fastbugs repository.

[Pat Riehecky]

Thanks for the report, I'll have this fixed shortly.

Pat

On 06/28/2018 07:32 AM, Jeff & Marian Shrowder wrote:

(2) **
# yum --disablerepo epel check-update
ended with ...

Update notice SLBA-2018:1066-1 (from sl-fastbugs) is broken, or a bad 
duplicate, skipping.
You should report this problem to the owner of the sl-fastbugs 
repository.
If you are the owner, consider re-running the same command with 
--verbose to see the exact data that caused the conflict.
Update notice SLBA-2018:1424-1 (from sl-fastbugs) is broken, or a bad 
duplicate, skipping.
# 


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Where is CVE-2018-3665 patch for SL6?

[Pat Riehecky]

Upstream doesn't show a fix published:
https://access.redhat.com/security/cve/cve-2018-3665

Pat

On 06/26/2018 03:23 PM, Mike Ely wrote:

It's been a while since that was released (at least for Centos7) and I'm
wondering if there's a plan to release this for SL6 as well.


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Problem with selinux since Kernel Update

[Pat Riehecky]

Looks like libselinux was required for a rebuild.

A fixed package is on the way out now.

Pat

On 05/25/2018 05:17 AM, Maarten wrote:


Hello Scot,

I installed the most recent version of the policy but still have the 
same problem on all systems:


libsepol-2.5-8.1.sl7.x86_64

libsepol.policydb_read: policydb version 31 does not match my version 
range 15-30

invalid binary policy



On Thu, May 24, 2018 at 17:11, Scott Reid  wrote:

Hi Orion,

Thank you for the report. A new version of libsepol has been
pushed out which should address your problem.

Thanks!

On 5/23/18, 5:26 PM,
"owner-scientific-linux-us...@listserv.fnal.gov
<mailto:owner-scientific-linux-us...@listserv.fnal.gov> on behalf
of Orion Poplawski"
mailto:owner-scientific-linux-us...@listserv.fnal.gov> on behalf
of or...@nwra.com <mailto:or...@nwra.com>> wrote:

On 05/15/2018 05:45 PM, Orion Poplawski wrote:

On 05/15/2018 05:41 PM, Orion Poplawski wrote:

On 05/15/2018 12:23 PM, Maarten wrote:

I have the same problem on all of my systems, running
the same package
versions and kernel, also under 7.5:

libsepol.policydb_read: policydb version 31 does not
match my version
range 15-30
invalid binary policy

3.10.0-862.2.3.el7.x86_64

policycoreutils-2.5-22.el7.x86_64
checkpolicy-2.5-6.el7.x86_64
selinux-policy-targeted-3.13.1-192.el7_5.3.noarch
policycoreutils-python-2.5-22.el7.x86_64
selinux-policy-3.13.1-192.el7_5.3.noarch

sl-release-7.5-2.sl7.x86_64

On 05/11/2018 07:29 AM, Klaus Steinberger wrote:

Am 04.05.2018 um 13:06 schrieb Steven C Timm:

Did you just update the kernel or also all the
other security updates
that came out.


The problem is also after upgrading to SL 7.5:

[root@dmz-sv-mirror01 ~]# audit2allow -a -m local
libsepol.policydb_read: policydb version 31 does
not match my version
range 15-30
invalid binary policy ???\T

[root@dmz-sv-mirror01 ~]# uname -a
Linux dmz-sv-mirror01.physik.uni-muenchen.de
3.10.0-862.2.3.el7.x86_64 #1 SMP
Tue May 8 14:55:36 CDT 2018 x86_64 x86_64 x86_64
GNU/Linux
[root@dmz-sv-mirror01 ~]# rpm -q -a | grep policy
policycoreutils-2.5-22.el7.x86_64
policycoreutils-python-2.5-22.el7.x86_64
checkpolicy-2.5-6.el7.x86_64
selinux-policy-targeted-3.13.1-192.el7_5.3.noarch
selinux-policy-3.13.1-192.el7_5.3.noarch
[root@dmz-sv-mirror01 ~]#

Sincerly,
Klaus



I see this as well.  Very strange since the message and
constants appear to
be defined in libsepol, and since that is updated I don't
see how the
policydb version can be wrong.

# strings /usr/lib64/libsepol.so.1 | grep 'version range'
policydb version %d does not match my version range %d-%d
policydb module version %d does not match my version range
%d-%d
# rpm -q libsepol
libsepol-2.5-8.1.el7.x86_64



Ah, but there is a libsepol-static package - so if packages
were incorrectly
built against the older version of that, that would explain
the problem.



Ping?  I think this is a pretty serious issue with the SL7.5
packages.  I
don't see this with CentOS or RHEL.

-- 
Orion Poplawski

Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com <mailto:or...@nwra.com>
Boulder, CO 80301

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.nwra.com_&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=K5IsmKIlfeGD3zuXIueSwQ&m=HOrUKrdX0_RlnX8W2Rv3LAamiLNAjjE-5-bEaEhgGV0&s=jhQsxCFCn_mwuHV1RYyI1eTN2PZLmTZz9BKjcZPSQWg&e=



--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] "Update notice SLBA-2018:0764-1 (from sl-security) is broken, or a bad duplicate," etc again

[Pat Riehecky]

Right, I'll get it sorted

Pat

On 05/25/2018 03:10 AM, Winnie Lacesso wrote:

Happy Friday!

Happening again:

[root@lcgnetmon02 ~]# yum clean all
Loaded plugins: fastestmirror
Cleaning repos: EGI-trustanchors sl sl-security
Cleaning up everything
Maybe you want: rm -rf /var/cache/yum, to also free up space taken by orphaned 
data from disabled or removed repos
Cleaning up list of fastest mirrors

[root@lcgnetmon02 ~]# yum check-update
Loaded plugins: fastestmirror
Determining fastest mirrors
  * sl: ftp2.scientificlinux.org
  * sl-security: ftp2.scientificlinux.org
EGI-trustanchors
 | 2.5 kB  00:00:00
sl  
 | 3.8 kB  00:00:00
sl-security 
 | 2.9 kB  00:00:00
(1/6): EGI-trustanchors/primary_db  
 |  59 kB  00:00:00
(2/6): sl-security/x86_64/updateinfo
 |  20 kB  00:00:00
(3/6): sl/x86_64/group_gz   
 | 113 kB  00:00:00
(4/6): sl/x86_64/updateinfo 
 | 2.5 MB  00:00:01
(5/6): sl/x86_64/primary_db 
 | 5.1 MB  00:00:04
(6/6): sl-security/x86_64/primary_db
 | 1.3 MB  00:00:05
Update notice SLBA-2018:0764-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
You should report this problem to the owner of the sl-security repository.
If you are the owner, consider re-running the same command with --verbose to 
see the exact data that caused the conflict.


client info:
[root@lcgnetmon02 ~]# lsb_release -a
LSB Version::core-4.1-amd64:core-4.1-noarch
Distributor ID: Scientific
Description:Scientific Linux release 7.5 (Nitrogen)
Release:7.5
Codename:   Nitrogen

hopefully fix soon eh?


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Security ERRATA Important: kernel on SL6.x i386/x86_64

[Pat Riehecky]

2-696.30.1.el6.i686.rpm
       kernel-debuginfo-2.6.32-696.30.1.el6.i686.rpm
       kernel-debuginfo-common-i686-2.6.32-696.30.1.el6.i686.rpm
       kernel-devel-2.6.32-696.30.1.el6.i686.rpm
       kernel-headers-2.6.32-696.30.1.el6.i686.rpm
       perf-2.6.32-696.30.1.el6.i686.rpm
       perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
       python-perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
       python-perf-2.6.32-696.30.1.el6.i686.rpm
     noarch
       kernel-abi-whitelists-2.6.32-696.30.1.el6.noarch.rpm
       kernel-doc-2.6.32-696.30.1.el6.noarch.rpm
       kernel-firmware-2.6.32-696.30.1.el6.noarch.rpm

- Scientific Linux Development Team



--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org




--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Create bootable ISO that can be copied to a USB key

[Pat Riehecky]

Hello,

Are you creating the custom iso with pungi or a different tool?

Pat

On 05/24/2018 01:17 PM, Bill wrote:

I am creating a custom installation ISO using kickstart.  This install ISO is 
based on SL 7.2.

When I burn a DVD from this ISO I can boot from the DVD and the install menu 
come up as expected.

When I use dd to copy the ISO to a USB key and try to boot from the USB key the 
install menu does not appear and the system boots from the hard drive.

I tried using dd to copy the SL7.2 ISO to a USB key.  When I try to boot from 
this USB key the install menu comes up as expected.

What files on the SL7.2 have to do with booting from the USB key?

Is there a mkisofs option I should be using to make booting USB key work?


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Security ERRATA Important: kernel on SL6.x i386/x86_64

[Pat Riehecky]

Hi Bill,

Our internal test VMs are KVM guests on SL 6.9 with an AMD server. I'm 
not seeing this problem there.


Are there any more details you can share?

Pat

On 05/22/2018 09:20 PM, Bill Maidment wrote:

Hi
The new kernel caused
PANIC early exception 0d 10 . error 0 rc2
on a KVM SL 6.9 x86_64 guest
AMD server and all other guests running SL7.5 are all runn ing OK on their new 
kernel

Reverting to the previous SL 6.9 kernel gave me back my guest machine
Cheers
Bill
  
  
-Original message-

From:Scott Reid 
Sent: Wednesday 23rd May 2018 4:33
To: scientific-linux-err...@listserv.fnal.gov
Subject: Security ERRATA Important: kernel on SL6.x i386/x86_64

Synopsis:  Important: kernel security and bug fix update
Advisory ID:   SLSA-2018:1651-1
Issue Date:    2018-05-22
CVE Numbers:   CVE-2018-3639
--

Security Fix(es):

* An industry-wide issue was found in the way many modern microprocessor
designs have implemented speculative execution of Load & Store
instructions (a commonly used performance optimization). It relies on the
presence of a precisely-defined instruction sequence in the privileged
code as well as the fact that memory read from address to which a recent
memory write has occurred may see an older value and subsequently cause an
update into the microprocessor's data cache even for speculatively
executed instructions that never actually commit (retire). As a result, an
unprivileged attacker could use this flaw to read privileged memory by
conducting targeted cache side-channel attacks. (CVE-2018-3639)

Note: This issue is present in hardware and cannot be fully fixed via
software update. The updated kernel packages provide software side of the
mitigation for this hardware issue. To be fully functional, up-to-date CPU
microcode applied on the system is required.

In this update mitigations for x86 (both 32 and 64 bit) architecture are
provided.

Bug Fix(es):

* Previously, an erroneous code in the x86 kexec system call path caused a
memory corruption. As a consequence, the system became unresponsive with
the following kernel stack trace:

'WARNING: CPU: 13 PID: 36409 at lib/list_debug.c:59
__list_del_entry+0xa1/0xd0 list_del corruption. prev->next should be
dd03fddeeca0, but was (null)'

This update ensures that the code does not corrupt memory. As a result,
the operating system no longer hangs.
--

SL6
   x86_64
     kernel-2.6.32-696.30.1.el6.x86_64.rpm
     kernel-debug-2.6.32-696.30.1.el6.x86_64.rpm
     kernel-debug-debuginfo-2.6.32-696.30.1.el6.i686.rpm
     kernel-debug-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
     kernel-debug-devel-2.6.32-696.30.1.el6.i686.rpm
     kernel-debug-devel-2.6.32-696.30.1.el6.x86_64.rpm
     kernel-debuginfo-2.6.32-696.30.1.el6.i686.rpm
     kernel-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
     kernel-debuginfo-common-i686-2.6.32-696.30.1.el6.i686.rpm
     kernel-debuginfo-common-x86_64-2.6.32-696.30.1.el6.x86_64.rpm
     kernel-devel-2.6.32-696.30.1.el6.x86_64.rpm
     kernel-headers-2.6.32-696.30.1.el6.x86_64.rpm
     perf-2.6.32-696.30.1.el6.x86_64.rpm
     perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
     perf-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
     python-perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
     python-perf-debuginfo-2.6.32-696.30.1.el6.x86_64.rpm
     python-perf-2.6.32-696.30.1.el6.x86_64.rpm
   i386
     kernel-2.6.32-696.30.1.el6.i686.rpm
     kernel-debug-2.6.32-696.30.1.el6.i686.rpm
     kernel-debug-debuginfo-2.6.32-696.30.1.el6.i686.rpm
     kernel-debug-devel-2.6.32-696.30.1.el6.i686.rpm
     kernel-debuginfo-2.6.32-696.30.1.el6.i686.rpm
     kernel-debuginfo-common-i686-2.6.32-696.30.1.el6.i686.rpm
     kernel-devel-2.6.32-696.30.1.el6.i686.rpm
     kernel-headers-2.6.32-696.30.1.el6.i686.rpm
     perf-2.6.32-696.30.1.el6.i686.rpm
     perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
     python-perf-debuginfo-2.6.32-696.30.1.el6.i686.rpm
     python-perf-2.6.32-696.30.1.el6.i686.rpm
   noarch
     kernel-abi-whitelists-2.6.32-696.30.1.el6.noarch.rpm
     kernel-doc-2.6.32-696.30.1.el6.noarch.rpm
     kernel-firmware-2.6.32-696.30.1.el6.noarch.rpm

- Scientific Linux Development Team




--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Security ERRATA Important: kernel on SL7.x x86_64

[Pat Riehecky]

An updated gcc that supports this option is scheduled for publication on 
Tuesday.


Pat

On 03/08/2018 11:46 AM, Gilles Detillieux wrote:
I realize this problem was likely introduced by upsteam updates, but I 
thought I'd point it out here anyway so you're aware of it. An 
unintended consequence of this latest kernel update is that it breaks 
recompilation of third-party kernel modules. The new kernel was built 
with CONFIG_RETPOLINE enabled, so presumably with a compiler that 
supports it, but that updated compiler hasn't been released through a 
corresponding security ERRATA update. (Not yet, anyway.) When I try to 
build a third-party device driver, I get the following error:


make[1]: Entering directory `/usr/src/kernels/3.10.0-693.21.1.el7.x86_64'
arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y, but not supported by 
the compiler. Toolchain update recommended..  Stop.

make[1]: Leaving directory `/usr/src/kernels/3.10.0-693.21.1.el7.x86_64'
make: *** [default] Error 2

Is an update of the compiler toolchain for RHEL7/SL7 through the usual 
update repos forthcoming? Until then, I don't think I can use this 
kernel update on systems that rely on that 3rd party driver.


Thanks,
Gilles

On 2018-03-07 16:16, Pat Riehecky wrote:

Synopsis:  Important: kernel security and bug fix update
Advisory ID:   SLSA-2018:0395-1
Issue Date:    2018-03-06
CVE Numbers:   CVE-2017-7518
    CVE-2017-12188
--

Security Fix(es):

* Kernel: KVM: MMU potential stack buffer overrun during page walks
(CVE-2017-12188, Important)

* Kernel: KVM: debug exception via syscall emulation (CVE-2017-7518,
Moderate)
--

SL7
   x86_64
 kernel-3.10.0-693.21.1.el7.x86_64.rpm
 kernel-debug-3.10.0-693.21.1.el7.x86_64.rpm
 kernel-debug-debuginfo-3.10.0-693.21.1.el7.x86_64.rpm
 kernel-debug-devel-3.10.0-693.21.1.el7.x86_64.rpm
 kernel-debuginfo-3.10.0-693.21.1.el7.x86_64.rpm
kernel-debuginfo-common-x86_64-3.10.0-693.21.1.el7.x86_64.rpm
 kernel-devel-3.10.0-693.21.1.el7.x86_64.rpm
 kernel-headers-3.10.0-693.21.1.el7.x86_64.rpm
 kernel-tools-3.10.0-693.21.1.el7.x86_64.rpm
 kernel-tools-debuginfo-3.10.0-693.21.1.el7.x86_64.rpm
 kernel-tools-libs-3.10.0-693.21.1.el7.x86_64.rpm
 perf-3.10.0-693.21.1.el7.x86_64.rpm
 perf-debuginfo-3.10.0-693.21.1.el7.x86_64.rpm
 python-perf-3.10.0-693.21.1.el7.x86_64.rpm
 python-perf-debuginfo-3.10.0-693.21.1.el7.x86_64.rpm
 kernel-tools-libs-devel-3.10.0-693.21.1.el7.x86_64.rpm
   noarch
 kernel-abi-whitelists-3.10.0-693.21.1.el7.noarch.rpm
 kernel-doc-3.10.0-693.21.1.el7.noarch.rpm

- Scientific Linux Development Team




--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Question on Python 3.5.x on HELiOS 6.9

[Pat Riehecky]

For Python 3.5 I'd recommend use of SoftwareCollections.

These are packaged up at an external repo:
https://www.softwarecollections.org/en/scls/rhscl/rh-python35/

Pat

On 02/22/2018 02:06 PM, Harsha Purushotham wrote:

Hi,

I am trying to include Python 3.5.x for custom applications on HELiOS 
6.9. I would like to know if Python 3 package RPMs can be downloaded 
from Scientific Linux Packages. If yes, what would the link be.


Best regards,
Harsha


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Yum update fails with conflict between device-mapper-event and lvm2-libs

[Pat Riehecky]

Can I have you run:

yum clean expire-cache

and try again?

On 01/05/2018 04:35 AM, Jean-Michel Barbet wrote:

Hello all,

Trying to update to recent kernel, in the list of updated package
there are 4 device-mapper updated packages and it looks like that
the new device-mapper-event.x86_64 0:1.02.117-12.el6 conflicts with
the installed lvm2-libs-2.02.100-8.el6.x86_64 :


yum update
Loaded plugins: priorities, security
Setting up Update Process
715 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package device-mapper.x86_64 0:1.02.79-8.el6 will be updated
---> Package device-mapper.x86_64 0:1.02.117-12.el6 will be an update
---> Package device-mapper-event.x86_64 0:1.02.79-8.el6 will be updated
---> Package device-mapper-event.x86_64 0:1.02.117-12.el6 will be an 
update
---> Package device-mapper-event-libs.x86_64 0:1.02.79-8.el6 will be 
updated
---> Package device-mapper-event-libs.x86_64 0:1.02.117-12.el6 will be 
an update

---> Package device-mapper-libs.x86_64 0:1.02.79-8.el6 will be updated
---> Package device-mapper-libs.x86_64 0:1.02.117-12.el6 will be an 
update

---> Package kernel.x86_64 0:2.6.32-696.18.7.el6 will be installed
---> Package kernel-firmware.noarch 0:2.6.32-696.10.3.el6 will be updated
---> Package kernel-firmware.noarch 0:2.6.32-696.18.7.el6 will be an 
update

---> Package kernel-headers.x86_64 0:2.6.32-696.10.3.el6 will be updated
---> Package kernel-headers.x86_64 0:2.6.32-696.18.7.el6 will be an 
update

---> Package kpartx.x86_64 0:0.4.9-72.el6 will be updated
---> Package kpartx.x86_64 0:0.4.9-100.el6 will be an update
---> Package microcode_ctl.x86_64 1:1.17-17.el6 will be updated
---> Package microcode_ctl.x86_64 1:1.17-25.2.el6_9 will be an update
---> Package nagios-common.x86_64 0:4.3.2-5.el6 will be updated
---> Package nagios-common.x86_64 0:4.3.4-7.el6 will be an update
---> Package nrpe.x86_64 0:3.1.1-1.el6 will be updated
---> Package nrpe.x86_64 0:3.2.0-6.el6 will be an update
---> Package tzdata.noarch 0:2017b-1.el6 will be updated
---> Package tzdata.noarch 0:2017c-1.el6 will be an update
--> Processing Conflict: device-mapper-event-1.02.117-12.el6.x86_64 
conflicts lvm2-libs < 2.02.111

--> Finished Dependency Resolution
Error: device-mapper-event conflicts with lvm2-libs-2.02.100-8.el6.x86_64


This is not a new story but I am wondering if someting has been
forgotten upstream and if other sites are seeing the same...

Thank you.

JM



--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

RE: Distribution Servers Downtime - 2 hours on Nov 29 2017 14:00 CST

[Pat Riehecky]

Hello,

The Scientific Linux distribution servers will be unavailable for about 
2 hours at November 29 2017 14:00 CST (Chicago).


Downloads, yum operations, and mirror syncs will fail against the 
following hosts:


* rsync.scientificlinux.org
* ftp.scientificlinux.org
* ftp1.scientificlinux.org
* ftp2.scientificlinux.org


For your local time you can run date -d '2017-11-29 14:00 CST'

Thank you for your patience while we perform this maintenance.

Pat Riehecky

Distribution Servers Downtime - 2 hours on Nov 29 2017 14:00 CST

[Pat Riehecky]

Hello,

The Scientific Linux distribution servers will be unavailable for about 
2 hours at November 29 2017 14:00 CST (Chicago).


Downloads, yum operations, and mirror syncs will fail against the 
following hosts:


* rsync.scientificlinux.org
* ftp.scientificlinux.org
* ftp1.scientificlinux.org
* ftp2.scientificlinux.org


For your local time you can run date -d '2017-11-29 14:00 CST'

Thank you for your patience while we perform this maintenance.

Pat Riehecky

Re: [SCIENTIFIC-LINUX-USERS] Laptop HDD spin down when idle

[Pat Riehecky]

On 10/27/2017 03:10 PM, D Greig wrote:

On 27/10/17 20:46, Pat Riehecky wrote:



On 10/27/2017 02:17 PM, D Greig wrote:

On 27/10/17 17:24, D Greig wrote:

Hi,

I am looking for help on how to stop/disable the HDD spin down option



I should add that the laptop has a fresh(yesterday) install of SL7.4.

"hdparm" was not present on the system, so I installed it from SL repo.

Now I am unsure as to the safest way to use it for the task.

In the past spindown is disabled by default.



This should probably get you going: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.archlinux.org_index.php_hdparm-23Persistent-5Fconfiguration-5Fusing-5Fudev-5Frule&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=C1UH-_9koxexcg6HnyvwhfaZYbBiIvZquLGNYTxC38I&s=Ng2gXtcH7z8wLQGWIyJC_oBiIH6sRt2h1_41pCY7GEg&e= 





Hi Pat,

That led to a fix.

Many thanks.

hdparm -B 255 /dev/sda
Sorted it.

now:
[root@mu dg]# hdparm -B /dev/sda

/dev/sda:
 APM_level    = off
[root@mu dg]# hdparm -B /dev/sda

/dev/sda:
 APM_level    = off

I can understand spindown might be useful on battery, quite dangerous 
on AC.


There used to be an option in "power manager", but not on SL7.4.



You may want to set laptop-mode depending on your usage - 
https://www.kernel.org/doc/Documentation/laptops/laptop-mode.txt


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Laptop HDD spin down when idle

[Pat Riehecky]

On 10/27/2017 02:17 PM, D Greig wrote:

On 27/10/17 17:24, D Greig wrote:

Hi,

I am looking for help on how to stop/disable the HDD spin down option



I should add that the laptop has a fresh(yesterday) install of SL7.4.

"hdparm" was not present on the system, so I installed it from SL repo.

Now I am unsure as to the safest way to use it for the task.

In the past spindown is disabled by default.



This should probably get you going: 
https://wiki.archlinux.org/index.php/hdparm#Persistent_configuration_using_udev_rule


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] clock skew too great ** EXTERNAL **

[Pat Riehecky]

If memory serves, SL7 has "Less Brittle Kerberos"[1] where as SL6 does 
not.  This could account for why one works and the other does not.


Pat

[1] https://fedoraproject.org/wiki/Features/LessBrittleKerberos

On 10/18/2017 07:10 PM, Stephen Isard wrote:

On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold  wrote:


On Wed, 18 Oct 2017, Howard, Chris wrote:


Is it possible the two boxes are talking to two different servers?

as the initial post mentioned and showed it was using remote
host lists to a pool alias, almost certainly --

Oh, I took the question to be about the kerberos server.  Yes, you are right,
ntpd -q returns different results on the two machines.  However, as I said in 
the original post, the time on the two machines is the same to within a very 
small amount., well within the five minute tolerance used by kerberos.  So I 
don't understand why it should matter that the two machines have arrived at the 
same time by syncing with different servers.


as a way around, set up ONE unit to act as the local master,
and then sync against it, to get 'site coherent' time

Could you tell me how to do this, or point me at a document that does?

Thanks.


[a person with more than one clock is never quite _sure_ what
time is correct ;) ]


for extra geek points, spend $25 on AMZN, and get a GPS USB
dongle; run a local top strata server (the first three
lintes of the following)

[root@router etc]# ntpq -p
 remote   refid  st t when poll reach   delay
offset  jitter
=
GPS_NMEA(0) .GPS.0 l-   1600.000
0.000   0.000
SHM(0)  .GPS.0 l-   1600.000
0.000   0.000
SHM(1)  .PPS.0 l-   1600.000
0.000   0.000
+ntp1.versadns.c .PPS.1 u  665 1024  377   51.817
-12.510  19.938
*tock.usshc.com  .GPS.1 u  294 1024  377   34.608
-8.108  10.644
+clmbs-ntp1.eng. 130.207.244.240  2 u  429 1024  377   31.520
-5.674   7.484
+ntp2.sbcglobal. 151.164.108.15   2 u  272 1024  377   23.117
-6.825  10.479
+ntp3.tamu.edu   165.91.23.54 2 u 1063 1024  377   63.723
-3.319  16.813
[root@router etc]#


configuring ntp.conf is not all that hard

-- Russ herrold


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] yumex failed to update SL7x to current

[Pat Riehecky]

Please run 'yum downgrade libgpod'

On 09/18/2017 11:51 AM, Yasha Karant wrote:
I used yumex to update SL7 production to current SL7production 
release. The update failed with the following diagnostics:


Dependency Resolution Errors:

Package: libgpod-0.8.3-14.el7.x86_64 (@epel)
    Requires: libimobiledevice.so.4()(64bit)
    Removing: libimobiledevice-1.1.5-6.el7.x86_64 (@anaconda)
    libimobiledevice.so.4()(64bit)
    Updated By: libimobiledevice-1.2.0-1.el7.x86_64 (sl-security)
   ~libimobiledevice.so.6()(64bit)Package: 
libgpod-0.8.3-14.el7.x86_64 (@epel)

    Requires: libusbmuxd.so.2()(64bit)
    Removing: usbmuxd-1.0.8-11.el7.x86_64 (@anaconda)
    libusbmuxd.so.2()(64bit)
    Obsoleted By: usbmuxd-1.1.0-1.el7.x86_64 (sl-security)
    Not found
    Updated By: usbmuxd-1.1.0-1.el7.x86_64 (sl-security)
    Not foundPackage: libgpod-0.8.3-14.el7.x86_64 (@epel)
    Requires: libplist.so.1()(64bit)
    Removing: libplist-1.10-4.el7.x86_64 (@anaconda)
    libplist.so.1()(64bit)
    Updated By: libplist-1.12-3.el7.x86_64 (sl-security)
   ~libplist.so.3()(64bit)

Where does one find the "Not found" packages, and/or what changes need 
to be made to configuration files (e.g., simply not updating which 
packages from the yumex list)?  I understand that epel is not part of 
the FNAL SL base, but I know that persons with epel knowledge do read 
this list.  sl-security should be an SL issue; it appears: Obsoleted 
By: usbmuxd-1.1.0-1.el7.x86_64 (sl-security)

    Not found

Yasha Karant



--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

SL7.4 Release Candidate status

[Pat Riehecky]

Hello,

This email is a status update on Scientific Linux 7.4.

The Scientific Linux 7.4 Release Candidate was published on August 28 
2017.  There is a serious bug in the upstream provided iptables and 
ip6tables services[1] which may result in the firewall being disabled 
rather than enabled.


The Scientific Linux team considers this to be a release blocking issue.

We are following the upstream bug reports closely and have published a 
SL bugfix package in the 'sl-testing'[2] repo.  If an official fix is 
not forthcoming soon, we will consider building the SL bugfix package 
into the release.


Thanks,

Scientific Linux Team

[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1477413
https://bugzilla.redhat.com/show_bug.cgi?id=1481207
https://bugzilla.redhat.com/show_bug.cgi?id=1486803


[2]
http://ftp.scientificlinux.org/linux/scientific/7rolling/testing/x86_64/repoview/

--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] latest openssh update in SL7 breaks hostbased authentication?

[Pat Riehecky]

You might want to check for new/changed options from 6.6

https://www.openssh.com/releasenotes.html#7.4

Pat

On 08/25/2017 11:20 AM, Gilbert E. Detillieux wrote:
I was relying on host-based authentication (using RSA keys) between 
hosts in a cluster, and since the latest update to openssh under SL7, 
that seems to no longer work.  These are the specific packages that 
were installed as part of the recent yum update:


openssh-7.4p1-11.el7.x86_64.rpm
openssh-askpass-7.4p1-11.el7.x86_64.rpm
openssh-clients-7.4p1-11.el7.x86_64.rpm
openssh-server-7.4p1-11.el7.x86_64.rpm

Any ideas why this stopped working?  Any ideas what I need to tweak to 
get it working again?




--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

Re: [SCIENTIFIC-LINUX-USERS] Security ERRATA Important: jasper on SL6.x, SL7.x i386/x86_64

[Pat Riehecky]

Not sure why they didn't make it out, should be there now.

Pat

On 07/26/2017 08:32 AM, Andrew C Aitchison wrote:

On Wed, 10 May 2017, Pat Riehecky wrote:


Synopsis:  Important: jasper security update
Advisory ID:   SLSA-2017:1208-1
Issue Date:2017-05-09



SL6
 x86_64
   jasper-1.900.1-21.el6_9.x86_64.rpm
   jasper-debuginfo-1.900.1-21.el6_9.i686.rpm
   jasper-debuginfo-1.900.1-21.el6_9.x86_64.rpm


I can find most of these, but not the jasp-debuginfo packages.
If they could be added to the usual places that would be great.


   jasper-libs-1.900.1-21.el6_9.i686.rpm
   jasper-libs-1.900.1-21.el6_9.x86_64.rpm
   jasper-devel-1.900.1-21.el6_9.i686.rpm
   jasper-devel-1.900.1-21.el6_9.x86_64.rpm
   jasper-utils-1.900.1-21.el6_9.x86_64.rpm


Thanks,

Re: [SCIENTIFIC-LINUX-USERS] How to tie a system to a specific update of Scientific Linux?

[Pat Riehecky]

On 07/24/2017 03:03 PM, Ed Agoff wrote:

I'm looking for a solution similar to what's described in:
https://access.redhat.com/solutions/238533

"yum --releasever=7.2 update" for example, doesn't work for me on a 
new SL7.2 installation. Yum will still pull down v7.3 packages.



I believe you should set slreleasever[1] to your target version or 
remove yum-conf-sl7x.


Pat


[1] 
http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/release-notes/#_using_sl_yum_variables

Re: [SCIENTIFIC-LINUX-USERS] gridengine packages for SL7?

[Pat Riehecky]

On 07/11/2017 02:18 PM, Gilbert E. Detillieux wrote:
I have an older compute cluster running SL6, on which I had installed 
SGE (formerly Sun Grid Engine), using the gridengine packages that 
were available in EPEL 6.  I'm setting up a new cluster running SL7, 
and am looking for similar gridengine packages (possibly for a more 
current version of the software). EPEL 7 doesn't have it, and none of 
the other repos I typically use don't have it either.


Has anyone here used gridengine under SL7, CentOS 7 and/or RHEL 7?  If 
so, did you find a repo that had a compatible build of gridengine?  Or 
did you rebuild from source?


Thanks,
Gilbert



While I don't have a real answer for you, you may want to file a but up 
at https://bugzilla.redhat.com/enter_bug.cgi?classification=Fedora to 
have gridengine branched for EPEL7.


Pat

Addressing rpcbind crashes in SLSA-2017:1267

[Pat Riehecky]

A recent security update to rpcbind (SLSA-2017:1267) contained a bug 
that causes rpcbind to crash under some conditions. The specific 
conditions involve the interaction between ypbind, ypserv, and IPv6 
addresses within rpcbind.


The fix (SLBA-2017:1435 and SLBA-2017:1436) is currently available in 
the fastbugs repos. But given that there is potential for a significant 
unplanned outage when the latest rpcbind security update is applied, and 
that many SL systems do not install fastbugs by default, we will push 
SLBA-2017:1435 to security.


Publication of a non-security package to older releases is something the 
SL Team generally does only to permit the installation of security 
updates. We're making an exception for this case.


On June 19 2017, SLBA-2017:1435 and SLBA-2017:1436 will be published for 
all SL6 and SL7 releases so that it supersedes SLSA-2017:1267 in a 
default yum update operation

Re: [SCIENTIFIC-LINUX-USERS] docker-1.12.6-11.el7.x86_64 not working with systemd

[Pat Riehecky]

On 04/21/2017 12:13 PM, Denice wrote:

However the corresponding container-selinux package
requires policycoreutils >= 2.5-11.  That version of policycoreutils is
not yet published in the SL updates tree, but should appear soon - it
is in fastbugs, so you would need to enable fastbugs to update it. 


I show that version published: 
http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/updates/fastbugs/repoview/policycoreutils.html


Pat

Re: [SCIENTIFIC-LINUX-USERS] docker-1.12.6-11.el7.x86_64 not working with systemd

[Pat Riehecky]

I'm not seeing any errors on my boxes.

Pat

On 04/20/2017 02:12 AM, Mikkel Kruse Johnsen wrote:

Hi

After an update to "docker-1.12.6-11.el7.x86_64" the service is unable 
to start.


# systemctl start docker.service
Failed to start docker.service: Unit not found.

disable/enable/stop is working.

I see that the ending is "sl7" where the old package is "el7". What is 
the SL changes. Anyone know how to fix this ?



Downgrading:
# yum downgrade docker.x86_64 2:1.12.5-14.el7 docker-common.x86_64 
2:1.12.6-11.el7 docker-client.x86_64 2:1.12.6-11.el7

At is works again.


--
Mikkel Kruse Johnsen mailto:mik...@xmedicus.com>>
XMedicus ApS

Re: [SCIENTIFIC-LINUX-USERS] SL5 initrd.img

[Pat Riehecky]

I believe that is all generated via the buildinstall script from the 
anaconda-runtime rpm under /usr/lib/anaconda-runtime.


If memory serves it spits out usage information if you don't provide any 
args.


Pat

On 04/18/2017 02:48 PM, Mark Stodola wrote:
Is there a resource/information/script on generating the initrd.img 
used in the SL5 installation media?  I'm trying to inject kernel-lt 
from ELrepo in place of the usual one.  Replacing vmlinuz is easy, but 
I'm not sure where to start getting the initrd updated with the 
appropriate kernel modules.


I already know how to unpack the initrd, but I'm unsure how/where the 
modules included in it are selected, gathered, and supporting files 
created.


-Mark

Re: [SCIENTIFIC-LINUX-USERS] Trouble installing SL6 on Dell 7910

[Pat Riehecky]

The 6.9 release candidate should be published soon.  That may be worth 
testing on this hardware.


Pat

On 04/11/2017 08:33 AM, Eero Volotinen wrote:

try booting with acpi=off and update bios to latest first.

also try with ubuntu live to test, if hardware works with linux :)

--
Eero

2017-04-11 16:30 GMT+03:00 Dan McDaniel 
>:


We just got a Dell Precision R7910. The net install CD hangs at
"detecting hardware." I can boot the LiveCD, but not the install CD.
I've tried both 6.7 and 6.8.

Has anyone run into this? Any work-arounds?

-- 
Dan McDaniel

Re: [SCIENTIFIC-LINUX-USERS] fermilab-conf_doe-banner-console is not fully uninstalled by yum remove

[Pat Riehecky]

On 04/06/2017 07:09 AM, Dan wrote:

On Sun, 2 Apr 2017, Dan wrote:


Yesterday, I accidentally (as part of a more general yum install
invocation with some wildcards in it) ran:
yum install fermilab-conf_doe-banner-console
This wrote a passage of text to /etc/motd, causing a vaguely
threatening message, purporting to constitute a legally-binding
contract, to appear on screen at boot time.
However, subsequently running
yum remove fermilab-conf_doe-banner-console
does not remove the passage of text from /etc/motd, and does not stop
the message from appearing at boot time.


Well, thanks to Pat's swift production of a new version of
fermilab-conf_doe-banner-console (followed by another cycle of yum
install and yum remove by me), the text has now been deleted from
/etc/motd.

Unfortunately, the threatening-sounding message is still appearing at
boot time.  Digging a little deeper, I think this may be because

yum install fermilab-conf_doe-banner-login-screen

writes the relevant text into
, and a subsequent

yum remove fermilab-conf_doe-banner-login-screen

doesn't remove the text from that file.  Pat, I think you're the
maintainer of that package too, right?  Any chance of a similar fix
there, please?



I'll take a look!

Pat

Re: [SCIENTIFIC-LINUX-USERS] fermilab-conf_doe-banner-console is not fully uninstalled by yum remove

[Pat Riehecky]

Hi Dan,

Thanks for the report.  I own this package and I'll see about getting it 
fixed.


Pat

On 04/02/2017 11:22 AM, Dan wrote:

Dear All,

I installed SL7.3 a few weeks ago - thanks for a great distro.

However, I've discovered the following behaviour which I think
constitutes a bug:

Yesterday, I accidentally (as part of a more general yum install
invocation with some wildcards in it) ran:

yum install fermilab-conf_doe-banner-console

This wrote a passage of text to /etc/motd, causing a vaguely
threatening message, purporting to constitute a legally-binding
contract, to appear on screen at boot time.

However, subsequently running

yum remove fermilab-conf_doe-banner-console

does not remove the passage of text from /etc/motd, and does not stop
the message from appearing at boot time.

Is there some sort of upstream bugzilla to which someone can pass this
on, please?

Re: [SCIENTIFIC-LINUX-USERS] is the sha256sum of SL-7.3-x86_64-netinst.iso correct?

[Pat Riehecky]

Good catch.  Somehow the signature got reverted to the RC image.

The correct signature is 
68992289a1163250ba064c23baa8c4b23d11e5dc0562de41971bdf9c2ad42415


I'll get a new set of SHA files posted.  Sorry for the error.

On 04/01/2017 03:06 AM, Fred Liu wrote:

Hi,

Is the following hash the correct one?

13650ef94c16024285fd9dadebba4d62a33c0de5ac611314bf8e3d6afb956a3a  
SL-7.3-x86_64-netinst.iso


Thanks.

Fred

Re: [SCIENTIFIC-LINUX-USERS] Server going to uncommanded sleep or suspend

[Pat Riehecky]

I've seen GDM suspending the box after too much time without 
interaction.  My fix:


echo '[org.gnome.settings-daemon.plugins.power]' > 
/usr/share/glib-2.0/schemas/disable_powermgmt.gschema.override
echo sleep-inactive-ac-timeout=0 >> 
/usr/share/glib-2.0/schemas/disable_powermgmt.gschema.override
echo idle-dim=false >> 
/usr/share/glib-2.0/schemas/disable_powermgmt.gschema.override


glib-compile-schemas /usr/share/glib-2.0/schemas


Pat




On 03/09/2017 12:14 PM, Konstantin Olchanski wrote:

Hi, there. I wonder if anybody else is seeing the same problem with el7:

The symptoms are: no ping, dead video, dead keyboard. After power cycle,
syslog shows that the system has attempted to go into sleep or suspend
or whatever they call it.

This is very strange, usualy a system will go into suspend mode when you
close the laptop lid, but these are not laptops. They are normal desktop
machines (and at least in one case, there is no local user to blame for
pressing the "sleep" button).

So what's in the syslog:
- normal activity (systemd spam)
- network manager reports "sleep requested"
- some kind of nm_dispatcher activity
- systemd reaches sleep and suspend targets.
- continues spewing sundry messages, never recovers (never goes into actual 
sleep).

The machine is effectively dead after network manager put the network 
interfaces to sleep.

The best google-advice I see it to disable the systemd sleep and suspend 
targets:
systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target 
systemd-suspend.service systemd-hybrid-sleep.service
(now waiting for this machine to go to sleep).

It is very worrysome that the syslog does not say who initiated the 
sleep/suspend sequence.

That would be a show stopper for el7 - servers randomly going offline into 
uncommanded sleep/suspend.
It does seem to happen rarely, but I have seen 3 or 4 machines do it at least 
once, so not rare enough.

Any ideas?


K.O.


Here is the syslog contents:

Mar  3 15:50:01 daqbackup systemd: Starting Session 1599 of user root.
Mar  3 15:50:01 daqbackup systemd: Started Session 1602 of user root.
Mar  3 15:50:01 daqbackup systemd: Starting Session 1602 of user root.
Mar  3 15:50:16 daqbackup NetworkManager[1076]:   [1488585016.1046] 
manager: sleep
requested (sleeping: no  enabled: yes)
Mar  3 15:50:16 daqbackup NetworkManager[1076]:   [1488585016.1052] 
manager:
sleeping...
Mar  3 15:50:16 daqbackup NetworkManager[1076]:   [1488585016.1061] 
manager:
NetworkManager state is now ASLEEP
Mar  3 15:50:16 daqbackup dbus-daemon: dbus[846]: [system] Activating via 
systemd: service
name='org.freedesktop.nm_dispatcher' 
unit='dbus-org.freedesktop.nm-dispatcher.service'
Mar  3 15:50:16 daqbackup dbus[846]: [system] Activating via systemd: service
name='org.freedesktop.nm_dispatcher' 
unit='dbus-org.freedesktop.nm-dispatcher.service'
Mar  3 15:50:16 daqbackup systemd: Cannot add dependency job for unit 
microcode.service,
ignoring: Unit is not loaded properly: Invalid argument.
Mar  3 15:50:16 daqbackup systemd: Starting Network Manager Script Dispatcher 
Service...
Mar  3 15:50:16 daqbackup dbus-daemon: dbus[846]: [system] Successfully 
activated service
'org.freedesktop.nm_dispatcher'
Mar  3 15:50:16 daqbackup dbus[846]: [system] Successfully activated service
'org.freedesktop.nm_dispatcher'
Mar  3 15:50:16 daqbackup systemd: Started Network Manager Script Dispatcher 
Service.
Mar  3 15:50:16 daqbackup nm-dispatcher: req:1 'connectivity-change': new 
request (4 scripts)
Mar  3 15:50:16 daqbackup nm-dispatcher: req:1 'connectivity-change': start 
running ordered
scripts...
Mar  3 15:50:21 daqbackup systemd-logind: Delay lock is active (UID 42/gdm, PID 
3237/gnome-
shell) but inhibitor timeout is reached.
Mar  3 15:50:21 daqbackup systemd: Reached target Sleep.
Mar  3 15:50:21 daqbackup systemd: Starting Sleep.
Mar  3 15:50:21 daqbackup systemd: Starting Suspend...
Mar  3 15:50:21 daqbackup systemd-sleep: Suspending system...
Mar  3 15:54:11 daqbackup kernel: PM: Syncing filesystems ... done.
Mar  3 15:54:11 daqbackup kernel: Freezing user space processes ... (elapsed 
0.046 seconds)
done.

Re: [SCIENTIFIC-LINUX-USERS] yum update on SL7

[Pat Riehecky]

Removing yum-conf-sl7x should perform the task.

http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/release-notes/#_sl_specific_behavior_changes

Pat

On 01/27/2017 11:56 AM, Werf, C.G. van der (Carel) wrote:

On SL5 and SL6 it was easy to prevent yum from updating to a new release, by 
disabling sl5x.repo or sl6x.repo.
Still updates for the current release were found.

On SL7 only the sl7x.repo is installed by default.
How can I prevent SL7.2 from upgrading to SL7.3, but still find updates for 
SL7.2 ?


Regards,
Carel

Re: [SCIENTIFIC-LINUX-USERS] update notice?

[Pat Riehecky]

lsb_release comes out of redhat-lsb-core .

Description : The Linux Standard Base (LSB) Core module support provides the
: fundamental system interfaces, libraries, and runtime 
environment

: upon which all conforming applications and libraries depend.

Personally, I put it on every system I manage.  But that is me, YMMV.

Based on what you've sent I think I've got it cleaned up.

Can you run:
yum --enablerepo=* clean expire-cache
yum check-update

and see if the problem is resolved?

Pat

On 01/26/2017 10:58 AM, Gilbert E. Detillieux wrote:

Pat,

I've attached two transcript files...  The first one (script.txt) is 
from a newly set-up SL 7.2 system that I upgraded to 7.3 yesterday.  
The other (script2.txt) is from an older system, that's gone through 
upgrades from 7.1 to 7.2, then to 7.3, and has a more substantial set 
of packages and repos installed.


I should add that I see the error messages about the update notices 
when I run "yum check-update", but not when I run "yum update".  (I 
think I was seeing it on the latter command as well, at least 
initially, but it's possible that it stopped doing that on an earlier 
run of "yum clean all" I ran yesterday.)  I don't know if that's to be 
expected or not.


BTW, I don't seem to have the "lsb_release" command installed. Know 
what package I might find that in?


Thanks,
Gilbert

On 26/01/2017 10:22 AM, Pat Riehecky wrote:

Can I have you send me the output of the following:

yum --enablerepo=* clean expire-cache
yum repolist
lsb_release -a
cat /etc/yum/vars/slreleasever
yum makecache
find /var/cache/yum/x86_64/ -type f -name repomd.xml -ls -exec sha1sum
{} \;

Pat



On 01/26/2017 10:06 AM, Gilbert E. Detillieux wrote:

Pat, I'm seeing these same errors, even after a "yum clean all".  This
is just since yesterday's upgrade from SL 7.2 to 7.3, on many boxes.

Gilbert

On 26/01/2017 8:39 AM, Pat Riehecky wrote:

Hello,

Can I have you run a

yum clean all

and see if the problem persists?

Pat

On 01/26/2017 01:12 AM, Maarten wrote:

What do these messages mean? It says to contact the repo owner?

etc/cron.daily/0yum-daily.cron:

Not using downloaded repomd.xml because it is older than what we 
have:

  Current   : Wed Jan 25 20:54:42 2017
  Downloaded: Wed Jan 25 20:54:25 2017
Update notice SLBA-2015:2562-1 (from sl-security) is broken, or a bad
duplicate, skipping.
You should report this problem to the owner of the sl-security
repository.
Update notice SLBA-2016:1445-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:1526-1 (from sl-security) is broken, or a bad
duplicate, skipping.

...

Update notice SLSA-2017:0021-1 (from sl-security) is broken, or a bad
duplicate, skipping.

Re: [SCIENTIFIC-LINUX-USERS] update notice?

[Pat Riehecky]

Can I have you send me the output of the following:

yum --enablerepo=* clean expire-cache
yum repolist
lsb_release -a
cat /etc/yum/vars/slreleasever
yum makecache
find /var/cache/yum/x86_64/ -type f -name repomd.xml -ls -exec sha1sum {} \;

Pat



On 01/26/2017 10:06 AM, Gilbert E. Detillieux wrote:
Pat, I'm seeing these same errors, even after a "yum clean all".  This 
is just since yesterday's upgrade from SL 7.2 to 7.3, on many boxes.


Gilbert

On 26/01/2017 8:39 AM, Pat Riehecky wrote:

Hello,

Can I have you run a

yum clean all

and see if the problem persists?

Pat

On 01/26/2017 01:12 AM, Maarten wrote:

What do these messages mean? It says to contact the repo owner?

etc/cron.daily/0yum-daily.cron:

Not using downloaded repomd.xml because it is older than what we have:
  Current   : Wed Jan 25 20:54:42 2017
  Downloaded: Wed Jan 25 20:54:25 2017
Update notice SLBA-2015:2562-1 (from sl-security) is broken, or a bad
duplicate, skipping.
You should report this problem to the owner of the sl-security
repository.
Update notice SLBA-2016:1445-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:1526-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:1528-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:1540-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2096-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2168-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2171-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2184-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2187-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2211-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2257-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2267-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2276-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2285-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2290-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2331-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2356-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2374-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2396-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2397-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2403-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2404-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2431-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2443-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2446-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2467-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2471-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2526-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2536-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2611-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2612-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2660-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLBA-2016:2879-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLEA-2015:2281-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLEA-2016:0154-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLEA-2016:0463-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLEA-2016:0517-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLEA-2016:0683-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLEA-2016:1982-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLEA-2016:2053-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLEA-2016:2154-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLEA-2016:2158-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLEA-2016:2266-1 (from sl-security) is broken, or a bad
duplicate, skipping.
Update notice SLEA-2016:2275

Re: [SCIENTIFIC-LINUX-USERS] update notice?

[Pat Riehecky]

On 01/26/2017 10:15 AM, Stephan Wiesand wrote:

On Jan 26, 2017, at 16:32 , Maarten wrote:


And great work for releasing 7.3!! :)

Has it actually been released? Can't find an announcement to that effect...


It is out officially, I'll see if the email went missing somewhere.

Pat

Re: [SCIENTIFIC-LINUX-USERS] update notice?

[Pat Riehecky]

Hello,

Can I have you run a

yum clean all

and see if the problem persists?

Pat

On 01/26/2017 01:12 AM, Maarten wrote:

What do these messages mean? It says to contact the repo owner?

etc/cron.daily/0yum-daily.cron:

Not using downloaded repomd.xml because it is older than what we have:
  Current   : Wed Jan 25 20:54:42 2017
  Downloaded: Wed Jan 25 20:54:25 2017
Update notice SLBA-2015:2562-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
You should report this problem to the owner of the sl-security 
repository.
Update notice SLBA-2016:1445-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:1526-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:1528-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:1540-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2096-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2168-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2171-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2184-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2187-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2211-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2257-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2267-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2276-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2285-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2290-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2331-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2356-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2374-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2396-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2397-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2403-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2404-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2431-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2443-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2446-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2467-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2471-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2526-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2536-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2611-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2612-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2660-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLBA-2016:2879-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2015:2281-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:0154-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:0463-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:0517-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:0683-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:1982-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:2053-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:2154-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:2158-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:2266-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:2275-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:2277-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:2278-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:2281-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:2287-1 (from sl-security) is broken, or a bad 
duplicate, skipping.
Update notice SLEA-2016:2288-1 (from sl-sec

Re: [SCIENTIFIC-LINUX-USERS] broken files in 7.0 update

[Pat Riehecky]

Do you have the path to where you are seeing that?

I'm showing:

-rw-r--r--   58904 2014/05/14 08:46:57 
7.0/x86_64/os/Packages/pangomm-devel-2.34.0-3.el7.x86_64.rpm
-rw-r--r--   58904 2014/05/14 08:46:57 
7.1/x86_64/os/Packages/pangomm-devel-2.34.0-3.el7.x86_64.rpm
-rw-r--r--   58904 2014/05/14 08:46:57 
7.2/x86_64/os/Packages/pangomm-devel-2.34.0-3.el7.x86_64.rpm
-rw-r--r--   58904 2014/05/14 08:46:57 
7.3/x86_64/os/Packages/pangomm-devel-2.34.0-3.el7.x86_64.rpm


Pat

On 01/18/2017 01:50 AM, Paul Myers wrote:

Hi Pat

Looks like you may have missed a package

-rw-r--r-- 1 5 5   14M Nov 12  2008 
pangomm-devel-2.34.0-3.el7.x86_64.rpm



Regards
Paul Myers
Maths IT


On Tue, 2017-01-17 at 09:01 -0600, Pat Riehecky wrote:

Interesting.  I've rebuilt the links on the rsync host.

Perhaps that will help.

On 01/16/2017 07:21 PM, Yan Xiaofei wrote:


Hi Pat Riehecky,

After mirror from rsync server I get these files:
[root@mirror security]# ls -al p11-kit-trust-0.20.7-3.el7.x86_64.rpm
-rw-r--r-- 7 root root 14873679 Nov 13  2008 
p11-kit-trust-0.20.7-3.el7.x86_64.rpm

[root@mirror security]# ls -al pciutils-libs-3.5.1-1.el7.x86_64.rpm
-rw-r--r-- 10 root root 150040 Nov 12  2008 
pciutils-libs-3.5.1-1.el7.x86_64.rpm


I check other public mirror site. All these file were broken.
Here is a example, I download file from CERN:
# wget 
http://linuxsoft.cern.ch/scientific/7.0/x86_64/updates/security/p11-kit-trust-0.20.7-3.el7.x86_64.rpm

# ls -al p11-kit-trust-0.20.7-3.el7.x86_64.rpm
-rw-r--r-- 1 root root 14873679 Nov 13  2008 
p11-kit-trust-0.20.7-3.el7.x86_64.rpm


Another file is
pacemaker-libs-1.1.15-11.el7.x86_64.rpm 
<http://linuxsoft.cern.ch/scientific/7.0/x86_64/updates/security/pacemaker-libs-1.1.15-11.el7.x86_64.rpm>  
Could you please check these problem. We can not yum update because 
of this.


Regards
Xiaofei 
在 2017-1-17 0:40, Pat Riehecky 写道:



I show:

[riehecky@hostname test]$ rsync -avh 
rsync://rsync.scientificlinux.org/scientific/7.0/x86_64/updates/security/pci*

receiving incremental file list
-rw-r--r--   94440 2016/11/11 11:03:27 
pciutils-3.5.1-1.el7.x86_64.rpm
-rw-r--r--   34756 2016/11/11 10:54:46 
pciutils-devel-3.5.1-1.el7.i686.rpm
-rw-r--r--   34724 2016/11/11 11:03:27 
pciutils-devel-3.5.1-1.el7.x86_64.rpm
-rw-r--r--   37408 2016/11/11 10:54:17 
pciutils-devel-static-3.5.1-1.el7.i686.rpm
-rw-r--r--   38552 2016/11/11 11:03:27 
pciutils-devel-static-3.5.1-1.el7.x86_64.rpm
-rw-r--r--   46008 2016/11/11 10:54:45 
pciutils-libs-3.5.1-1.el7.i686.rpm
-rw-r--r--   46100 2016/11/11 11:03:27 
pciutils-libs-3.5.1-1.el7.x86_64.rpm


sent 32 bytes  received 251 bytes  566.00 bytes/sec
total size is 331.99K  speedup is 1173.10
[riehecky@hostname test]$ rsync -avh 
rsync://rsync.scientificlinux.org/scientific/7.0/x86_64/updates/security/p11*

receiving incremental file list
-rw-r--r--  105704 2015/03/09 08:08:46 
p11-kit-0.20.7-3.el7.i686.rpm
-rw-r--r--  108624 2015/03/09 08:11:25 
p11-kit-0.20.7-3.el7.x86_64.rpm
-rw-r--r--   22116 2015/03/09 08:08:45 
p11-kit-devel-0.20.7-3.el7.i686.rpm
-rw-r--r--   22076 2015/03/09 08:14:27 
p11-kit-devel-0.20.7-3.el7.x86_64.rpm
-rw-r--r--   56480 2015/03/09 08:11:26 
p11-kit-doc-0.20.7-3.el7.noarch.rpm
-rw-r--r--  127976 2015/03/09 08:13:43 
p11-kit-trust-0.20.7-3.el7.x86_64.rpm


sent 32 bytes  received 233 bytes  530.00 bytes/sec
total size is 442.98K  speedup is 1671.61

being presented by the server.

On 01/16/2017 08:51 AM, Yan Xiaofei wrote:

Hello

There are some broken files in 7.0 update security directory.
One of the file is : 
rsync://rsync.scientificlinux.org/scientific/7.0/x86_64/updates/security/p11-kit-trust-0.20.7-3.el7.x86_64.rpm
Another file is pciutils-libs-3.5.1-1.el7.x86_64. All the file's 
date is 2008.

Could anybody fix this error.

Thanks very much!
Xiaofei

Re: [SCIENTIFIC-LINUX-USERS] SL7.3 release date?

[Pat Riehecky]

January 25 2017 is our projected release date

On 01/17/2017 03:49 PM, Maarten wrote:

Not to sound impatient, but is there an ETA of SL7.3 yet?

On 2016-12-01 22:44, Maarten wrote:

Hello Bonnie,

Great!! Thanks for the fast reply! :)

On 2016-12-01 22:36, Bonnie King wrote:

Hi Maarten,

On 12/01/2016 03:30 PM, Maarten wrote:


When is SL7.3 expected to be released?


We're working on the release, but we don't have an ETA for you yet.

Re: [SCIENTIFIC-LINUX-USERS] broken files in 7.0 update

[Pat Riehecky]

Interesting.  I've rebuilt the links on the rsync host.

Perhaps that will help.

On 01/16/2017 07:21 PM, Yan Xiaofei wrote:


Hi Pat Riehecky,

After mirror from rsync server I get these files:
[root@mirror security]# ls -al p11-kit-trust-0.20.7-3.el7.x86_64.rpm
-rw-r--r-- 7 root root 14873679 Nov 13  2008 
p11-kit-trust-0.20.7-3.el7.x86_64.rpm

[root@mirror security]# ls -al pciutils-libs-3.5.1-1.el7.x86_64.rpm
-rw-r--r-- 10 root root 150040 Nov 12  2008 
pciutils-libs-3.5.1-1.el7.x86_64.rpm


I check other public mirror site. All these file were broken.
Here is a example, I download file from CERN:
# wget 
http://linuxsoft.cern.ch/scientific/7.0/x86_64/updates/security/p11-kit-trust-0.20.7-3.el7.x86_64.rpm

# ls -al p11-kit-trust-0.20.7-3.el7.x86_64.rpm
-rw-r--r-- 1 root root 14873679 Nov 13  2008 
p11-kit-trust-0.20.7-3.el7.x86_64.rpm


Another file is
pacemaker-libs-1.1.15-11.el7.x86_64.rpm 
<http://linuxsoft.cern.ch/scientific/7.0/x86_64/updates/security/pacemaker-libs-1.1.15-11.el7.x86_64.rpm>  
Could you please check these problem. We can not yum update because of 
this.


Regards
Xiaofei
在 2017-1-17 0:40, Pat Riehecky 写道:

I show:

[riehecky@hostname test]$ rsync -avh 
rsync://rsync.scientificlinux.org/scientific/7.0/x86_64/updates/security/pci*

receiving incremental file list
-rw-r--r--   94440 2016/11/11 11:03:27 
pciutils-3.5.1-1.el7.x86_64.rpm
-rw-r--r--   34756 2016/11/11 10:54:46 
pciutils-devel-3.5.1-1.el7.i686.rpm
-rw-r--r--   34724 2016/11/11 11:03:27 
pciutils-devel-3.5.1-1.el7.x86_64.rpm
-rw-r--r--   37408 2016/11/11 10:54:17 
pciutils-devel-static-3.5.1-1.el7.i686.rpm
-rw-r--r--   38552 2016/11/11 11:03:27 
pciutils-devel-static-3.5.1-1.el7.x86_64.rpm
-rw-r--r--   46008 2016/11/11 10:54:45 
pciutils-libs-3.5.1-1.el7.i686.rpm
-rw-r--r--   46100 2016/11/11 11:03:27 
pciutils-libs-3.5.1-1.el7.x86_64.rpm


sent 32 bytes  received 251 bytes  566.00 bytes/sec
total size is 331.99K  speedup is 1173.10
[riehecky@hostname test]$ rsync -avh 
rsync://rsync.scientificlinux.org/scientific/7.0/x86_64/updates/security/p11*

receiving incremental file list
-rw-r--r--  105704 2015/03/09 08:08:46 p11-kit-0.20.7-3.el7.i686.rpm
-rw-r--r--  108624 2015/03/09 08:11:25 
p11-kit-0.20.7-3.el7.x86_64.rpm
-rw-r--r--   22116 2015/03/09 08:08:45 
p11-kit-devel-0.20.7-3.el7.i686.rpm
-rw-r--r--   22076 2015/03/09 08:14:27 
p11-kit-devel-0.20.7-3.el7.x86_64.rpm
-rw-r--r--   56480 2015/03/09 08:11:26 
p11-kit-doc-0.20.7-3.el7.noarch.rpm
-rw-r--r--  127976 2015/03/09 08:13:43 
p11-kit-trust-0.20.7-3.el7.x86_64.rpm


sent 32 bytes  received 233 bytes  530.00 bytes/sec
total size is 442.98K  speedup is 1671.61

being presented by the server.

On 01/16/2017 08:51 AM, Yan Xiaofei wrote:

Hello

There are some broken files in 7.0 update security directory.
One of the file is : 
rsync://rsync.scientificlinux.org/scientific/7.0/x86_64/updates/security/p11-kit-trust-0.20.7-3.el7.x86_64.rpm
Another file is pciutils-libs-3.5.1-1.el7.x86_64. All the file's 
date is 2008.

Could anybody fix this error.

Thanks very much!
Xiaofei

Re: [SCIENTIFIC-LINUX-USERS] srpms?

[Pat Riehecky]

On 01/12/2017 02:56 PM, Mark Stodola wrote:

I'm pretty sure there is a yum command to fetch the source rpm as well


I usually use:

yumdownloader --source mycoolpackagename


Pat

Re: [SCIENTIFIC-LINUX-USERS] Scientific Linux 5 three Month Warning - SL5 End Of Life

[Pat Riehecky]

Correction:

THREE months remain

On 12/22/2016 01:27 PM, Pat Riehecky wrote:

Hello,

Following the upstream release cycle, Scientific Linux 5 will reach
End of Life March 31 2017.

After this date no additional updates will be published for Scientific 
Linux 5.  This means no security updates for SL5 will be published 
after March 31 2017.


After March 31 2017:
- The installation trees will be moved into the obsolete directory.
- Kickstart and yum operations against the old repository locations
will no longer work.

The files themselves will remain available under the 'obsolete' 
directory.


Users of Scientific Linux 5 should evaluate options for migrating to 
an actively maintained operating system.


Scientific Linux 6 and Scientific Linux 7 are actively maintained at
this time.

Scientific Linux 5 Six Month Warning - SL5 End Of Life

[Pat Riehecky]

Hello,

Following the upstream release cycle, Scientific Linux 5 will reach
End of Life March 31 2017.

After this date no additional updates will be published for Scientific 
Linux 5.  This means no security updates for SL5 will be published after 
March 31 2017.


After March 31 2017:
- The installation trees will be moved into the obsolete directory.
- Kickstart and yum operations against the old repository locations
will no longer work.

The files themselves will remain available under the 'obsolete' directory.

Users of Scientific Linux 5 should evaluate options for migrating to an 
actively maintained operating system.


Scientific Linux 6 and Scientific Linux 7 are actively maintained at
this time.

Re: [SCIENTIFIC-LINUX-USERS] Security ERRATA Moderate: libguestfs and virt-p2v on SL7.x x86_64

[Pat Riehecky]

It looks like our package parser dropped virt-p2v and virt-v2v from the 
list.


I'll get them out the door in the next 5 minutes.

Pat

On 12/16/2016 03:48 AM, Stephan Wiesand wrote:

On 14 Dec 2016, at 19:07, Scott Reid  wrote:

Synopsis:  Moderate: libguestfs and virt-p2v security, bug fix, and 
enhancement update
Advisory ID:   SLSA-2016:2576-2
Issue Date:2016-11-03
CVE Numbers:   CVE-2015-8869
--

Virt-p2v is a tool for conversion of a physical server to a virtual guest.

The following packages have been upgraded to a newer upstream version:
libguestfs (1.32.7), virt-p2v (1.32.7).


Hmm, looks like virt-p2v is not actually in the package list?

In addition, I get this when trying to update a system which has virt-*v*2v 
installed:

Error: Package: 1:virt-v2v-1.28.1-1.55.el7.x86_64 (@7.2server)
   Requires: libguestfs = 1:1.28.1-1.55.el7
   Removing: 1:libguestfs-1.28.1-1.55.el7.x86_64 (@7.2server)
   libguestfs = 1:1.28.1-1.55.el7
   Updated By: 1:libguestfs-1.32.7-3.el7.x86_64 (7.2errata_C)
   libguestfs = 1:1.32.7-3.el7

- Stephan


Security Fix(es):

* An integer conversion flaw was found in the way OCaml's String handled
its length. Certain operations on an excessively long String could trigger
a buffer overflow or result in an information leak. (CVE-2015-8869)

Note: The libguestfs packages in this advisory were rebuilt with a fixed
version of OCaml to address this issue.

Additional Changes:
--

SL7
  x86_64
libguestfs-1.32.7-3.el7.x86_64.rpm
libguestfs-debuginfo-1.32.7-3.el7.x86_64.rpm
libguestfs-java-1.32.7-3.el7.x86_64.rpm
libguestfs-tools-c-1.32.7-3.el7.x86_64.rpm
libguestfs-xfs-1.32.7-3.el7.x86_64.rpm
perl-Sys-Guestfs-1.32.7-3.el7.x86_64.rpm
python-libguestfs-1.32.7-3.el7.x86_64.rpm
libguestfs-devel-1.32.7-3.el7.x86_64.rpm
libguestfs-gfs2-1.32.7-3.el7.x86_64.rpm
libguestfs-gobject-1.32.7-3.el7.x86_64.rpm
libguestfs-gobject-devel-1.32.7-3.el7.x86_64.rpm
libguestfs-java-devel-1.32.7-3.el7.x86_64.rpm
libguestfs-rescue-1.32.7-3.el7.x86_64.rpm
libguestfs-rsync-1.32.7-3.el7.x86_64.rpm
lua-guestfs-1.32.7-3.el7.x86_64.rpm
ocaml-libguestfs-1.32.7-3.el7.x86_64.rpm
ocaml-libguestfs-devel-1.32.7-3.el7.x86_64.rpm
ruby-libguestfs-1.32.7-3.el7.x86_64.rpm
virt-dib-1.32.7-3.el7.x86_64.rpm
  noarch
libguestfs-inspect-icons-1.32.7-3.el7.noarch.rpm
libguestfs-tools-1.32.7-3.el7.noarch.rpm
libguestfs-bash-completion-1.32.7-3.el7.noarch.rpm
libguestfs-gobject-doc-1.32.7-3.el7.noarch.rpm
libguestfs-javadoc-1.32.7-3.el7.noarch.rpm
libguestfs-man-pages-ja-1.32.7-3.el7.noarch.rpm
libguestfs-man-pages-uk-1.32.7-3.el7.noarch.rpm

- Scientific Linux Development Team

Re: [SCIENTIFIC-LINUX-USERS] Firefox 45.5.1 ?

[Pat Riehecky]

Hi Andrew,

Sorry for the delay.

This update should be published for SL on Wednesday along with a number 
of other security updates.


Pat

On 12/08/2016 03:38 AM, Andrew C Aitchison wrote:

I see firefox-45.5.1 in 7rolling/testing
http://ftp.scientificlinux.org/linux/scientific/7rolling/testing/x86_64/7.3-security/firefox-45.5.1-1.el7_3.x86_64.rpm 


but nothing for SL6 nor anything in the security updates.
Is there a problem rebuilding this critical update ?

https://rhn.redhat.com/errata/RHSA-2016-2843.html
The same bug is also in Thunderbird:
https://rhn.redhat.com/errata/RHSA-2016-2850.html

Thanks,

Re: [SCIENTIFIC-LINUX-USERS] 7.3?

[Pat Riehecky]

The 7.3 security errata is in the sl-testing repo at this time.

Pat

On 11/30/2016 08:36 PM, ToddAndMargo wrote:

What is the latest gossip on 7.3?  Any sign of it in our future?

Re: [SCIENTIFIC-LINUX-USERS] missing httpd24-libnghttp2

[Pat Riehecky]

Did you see: 
https://listserv.fnal.gov/scripts/wa.exe?A2=ind1611&L=SCIENTIFIC-LINUX-ERRATA&F=&S=&P=1819 
?


On 11/22/2016 02:06 PM, Devin A. Bougie wrote:

Hi, All.  It appears that httpd24-libnghttp2 is missing from SL6.  This 
prevents yum updates on systems that have httpd24-httpd or any httpd24 modules 
installed.

For example:
--
yum update httpd24-httpd
Loaded plugins: priorities, security
Setting up Update Process
...
--> Finished Dependency Resolution
Error: Package: httpd24-httpd-2.4.18-11.sl6.x86_64 (softwarecollections)
Requires: libnghttp2-httpd24.so.14()(64bit)
  You could try using --skip-broken to work around the problem
  You could try running: rpm -Va --nofiles --nodigest
--

And in particular:
--

Package Arch Version Repository Size

Removing:
httpd24-httpd x86_64 2.4.12-4.sl6.2 @softwarecollections/6.6 3.6 M
Removing for dependencies:
httpd24-httpd-devel x86_64 2.4.12-4.sl6.2 @softwarecollections/6.6 770 k
perl516-mod_perl x86_64 2.0.8-5.20130221svn1448242.el6
@softwarecollections/6.5 6.0 M
perl516-mod_perl-devel x86_64 2.0.8-5.20130221svn1448242.el6
@softwarecollections/6.5 917 k
python27-mod_wsgi x86_64 3.4-12.el6 @softwarecollections/6.5 199 k
python33-mod_wsgi x86_64 3.4-14.el6 @softwarecollections/6.5 203 k
ruby193-mod_passenger40 x86_64 4.0.18-11.el6 @softwarecollections/6.5 566 k

Transaction Summary

Remove 7 Package(s)
--

For what it's worth, it is available from the centos repo at:
http://mirror.centos.org/centos/6/sclo/x86_64/rh/httpd24/httpd24-libnghttp2-1.7.1-1.el6.x86_64.rpm

Many thanks,
Devin

Re: [SCIENTIFIC-LINUX-USERS] Why is anaconda-debuginfo not in the ISO?

[Pat Riehecky]

Hi Benjamin,

I was a bit surprised to see this.  The anaconda-debuginfo shouldn't 
have been in the x86_64/os/Packages repo.  You've discovered an 
interesting bug!


I've got it fixed up for SL 7.3.  The state in the DVD is the expected 
state; the inclusion of anaconda-debuginfo in the Packages repo is 
incorrect.


Pat

On 10/25/2016 08:44 AM, Benjamin Lefoul wrote:

Hi!

I created a filesystem repo for a future isolated system.
I got the EVERYTHING ISO, mounted it, copied everything in Packages to
/repo and used "createrepo". Then I added my repo "myrepo" to myself to
test and I noticed this:

[root@generic ~]# yum repolist
Loaded plugins: langpacks
repo id   repo name status
myrepoMY_REPO   9.044
sl/x86_64 Scientific Linux 7x - x86_64  9.045

There is one less package in myrepo than in the sl repo. Which one?
[root@generic ~]# repoquery -qa --repoid=sl > sl
[root@generic ~]# repoquery -qa --repoid=myrepo > myrepo
[root@generic ~]# diff sl myrepo
220d219
< anaconda-debuginfo-0:21.48.22.56-1.sl7.1.x86_64

[root@generic ~]# yum info anaconda-debuginfo
Loaded plugins: langpacks
Available Packages
Name: anaconda-debuginfo
Arch: x86_64
Version : 21.48.22.56
Release : 1.sl7.1
Size: 279 k
Repo: sl/x86_64
Summary : Debug information for package anaconda
URL : http://fedoraproject.org/wiki/Anaconda
License : GPLv2+ and MIT
Description : This package provides debug information for package
 : anaconda. Debug information is useful when developing
 : applications that use this package or when debugging
 : this package.

What has this poor package done to deserve to be excluded from the
SL-7.2-Everything-Dual-Layer-DVD-x86_64-2016-02-02.iso?

Regards,

Benjamin Lefoul

Re: [SCIENTIFIC-LINUX-USERS] CVE-2016-5195: mad cow disease

[Pat Riehecky]

Published.

On 10/22/2016 12:58 PM, Andrew Z wrote:


Pat and team,
Do we have an estimate on the world shattering vulnerability  ?

//world shattering - is a sarcasm.

Re: [SCIENTIFIC-LINUX-USERS] Kernel Local Privilege Escalation - CVE-2016-5195

[Pat Riehecky]

Thanks for the report, I'll be watching closely for an errata package.

Pat

On 10/20/2016 08:13 AM, Steven Haigh wrote:

(Reproduced below)

Red Hat Product Security has been made aware of a vulnerability in the
Linux kernel that has been assigned CVE-2016-5195. This issue was
publicly disclosed on October 19, 2016 and has been rated as Important.

Background Information

A race condition was found in the way the Linux kernel's memory
subsystem handled the copy-on-write (COW) breakage of private read-only
memory mappings. An unprivileged local user could use this flaw to gain
write access to otherwise read-only memory mappings and thus increase
their privileges on the system.

This could be abused by an attacker to modify existing setuid files with
instructions to elevate privileges. An exploit using this technique has
been found in the wild.

Impacted Products

The following Red Hat Product versions are impacted:

Red Hat Enterprise Linux 5
Red Hat Enterprise Linux 6
Red Hat Enterprise Linux 7
Red Hat Enterprise MRG 2
Attack Description and Impact

This flaw allows an attacker with a local system account to modify
on-disk binaries, bypassing the standard permission mechanisms that
would prevent modification without an appropriate permission set. This
is achieved by racing the madvise(MADV_DONTNEED) system call while
having the page of the executable mmapped in memory.

Take Action

All Red Hat customers running the affected versions of the kernel are
strongly recommended to update the kernel as soon as patches are
available. Details about impacted packages as well as recommended
mitigation are noted below. A system reboot is required in order for the
kernel update to be applied.

Mitigation

Please reference bug 1384344 for detailed mitigation steps.

Updates for Affected Products

A kpatch for customers running Red Hat Enterprise Linux 7.2 or greater
is available. Please open a support case to gain access to the kpatch.

--- END ADVICE ---

Possible mitigation for the issue:

https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13

There are currently no fixed packages available anywhere to resolve this.

Scientific Linux 5 Six Month Warning - SL5 End Of Life

[Pat Riehecky]

Hello,

Following the upstream release cycle, Scientific Linux 5 will reach End 
of Life March 31 2017.


After this date no additional updates will be published for Scientific 
Linux 5.  This means no security updates for SL5 will be published after 
March 31 2017.


After March 31 2017:
- The installation trees will be moved into the obsolete directory.
- Kickstart and yum operations against the old repository locations will 
no longer work.


The files themselves will remain available under the 'obsolete' directory.

Users of Scientific Linux 5 should evaluate options for migrating to an 
actively maintained operating system.


Scientific Linux 6 and Scientific Linux 7 are actively maintained at 
this time.

Re: [SCIENTIFIC-LINUX-USERS] 6x/x86_64/os/repodata/repomd.xml broken

[Pat Riehecky]

That is weird, I'd swear my tests of that completed ok

I've dropped the repodata signature and rebuilt the repomd.xml.  Can I 
have you test again?


Pat

On 10/05/2016 05:03 PM, Mike Ely wrote:

Hi,

Thanks for doing this. Can you please re-check? While the updated repmod.xml
worked for yum it didn't work for anaconda/kickstart, which threw errors
indicating malformed repodata.

Our fix was to run genpkgmetadata.py followed by createrepo -g repodata/comps-
sl6-x86_64.xml

Regards,
Mike Ely


I've rebuilt the repomd.  Please run yum makecache to verify it.

Pat

On 10/05/2016 05:02 AM, Petersen, Boris wrote:

Hey list,

could someone of the admins please recreate the repo metadata for
6x/x86_64/os? It seems to be broken.

$ ls -l os/repodata/repomd.xml
-rw-r--r-- 1 root root 3903 Oct  3 15:58 os/repodata/repomd.xml
$ sha256sum os/repodata/repomd.xml
b1774fccf1363b06a238a7f67c0b01bd02d134f6e32483f505845608dadf7c2d
os/repodata/repomd.xml $ yum-repo-verify -qr os/

ERROR: repo os has broken REPOMD.XML:
failed to load repomd.xml.

Thanks
Boris

Re: [SCIENTIFIC-LINUX-USERS] 6x/x86_64/os/repodata/repomd.xml broken

[Pat Riehecky]

I've rebuilt the repomd.  Please run yum makecache to verify it.

Pat

On 10/05/2016 05:02 AM, Petersen, Boris wrote:

Hey list,

could someone of the admins please recreate the repo metadata for 6x/x86_64/os? 
It seems to be broken.

$ ls -l os/repodata/repomd.xml
-rw-r--r-- 1 root root 3903 Oct  3 15:58 os/repodata/repomd.xml
$ sha256sum os/repodata/repomd.xml
b1774fccf1363b06a238a7f67c0b01bd02d134f6e32483f505845608dadf7c2d  
os/repodata/repomd.xml
$ yum-repo-verify -qr os/
ERROR: repo os has broken REPOMD.XML:
   failed to load repomd.xml.

Thanks
Boris

Re: [SCIENTIFIC-LINUX-USERS] Problem with listserv

[Pat Riehecky]

On 09/30/2016 09:28 AM, FRANCHISSEUR Robert LMD wrote:

Hello,

I just received a mail from lists...@listserv.fnal.gov
saying :

You have been automatically  removed from the SCIENTIFIC-LINUX-USERS list
(Mailing  list for  Scientific  Linux  users worldwide)  as  a result  of
repeated delivery error reports from  your mail system.


- The failing address is rob...@franchisseur.fr.

- The first error was reported on 2016-08-30.

- Since then, a total of 2 delivery errors have been received.

- The last  reported error was: 5.6.0 552 5.6.0  Headers too large (32768
max)


I don't understand what happened but I see that there are tons of lines
like :


X-MS-Office365-Filtering-Correlation-Id: c68f046b-a396-4aeb-d01f-08d3e8ecc238
X-Microsoft-Exchange-Diagnostics-untrusted: ...
X-Microsoft-Antispam-Untrusted: UriScan:;...
X-Microsoft-Exchange-Diagnostics-untrusted: ...
X-Microsoft-Antispam-PRVS: 

in the last mails I received from scientific-linux-users list


Am I the only one with this problem ?

Help will be highly appreciated.




I have seen some sites that dislike the size of the headers from the 
FNAL listserv.


Pat

Re: [SCIENTIFIC-LINUX-USERS] possible mistake in website

[Pat Riehecky]

Nice catch, I'll get the documents updated!

Pat

On 09/20/2016 08:24 AM, Andrew Hart wrote:


Hi,

Mainly just checking this is working but also, the final example from 
http://ftp.scientificlinux.org/linux/scientific/7x/contexts/#_naming_your_context


doesn’t match the rules.

Context names have a few rules:

·The name may only contain the following:

olower case Latin characters

ointegers

·For clarity, the name should be obviously associated with the 
computing context


Examples:

·cdfrun2

·cms2015

·fermilab

·SLlive

Re: [SCIENTIFIC-LINUX-USERS] Transparent Screen Lock for Enterprise Linux

[Pat Riehecky]

Neat!

Any chance you can get it into EPEL?

Pat


On 07/15/2016 10:41 AM, Devin A. Bougie wrote:

Cornell's Laboratory for Accelerator-based ScienceS and Education (CLASSE) is 
pleased to share our Transparent Screen Lock for Enterprise Linux.  Tested on 
SL6/7 and GPLv2 licensed, this software provides a transparent screen lock over 
one's desktop.  A configurable list of groups are able to unlock the screen, 
and logs document who unlocked the screen when.

This software has been used for over two years and proven useful in kiosk and 
operational environments where graphical displays need to stay running, 
updating, and visible, but to comply with various security policies the screen 
must lock after defined periods of inactivity.

To download the code or contribute to the project, please visit us on github.  
Additional issue reports and any code contributions would be greatly 
appreciated.

https://github.com/CLASSE-CornellUniversity/EnterpriseLinux-TransparentScreenLock

Re: [SCIENTIFIC-LINUX-USERS] what runs libvirt?

[Pat Riehecky]

On 06/24/2016 09:48 AM, Ken Teh wrote:
I was trying to set up dnsmasq and discovered it's already running. 
Apparently as part of libvirt.  Why is libvirt started?  What starts it?


I tried looking through systemd output but the only thing about 
systemd that I can understand are its services.  Everything else is so 
far gobbledy-gook.


Perhaps:

systemctl status 

will help track it down.

Pat

Re: [SCIENTIFIC-LINUX-USERS] Snap - the better,higher,faster etc

[Pat Riehecky]

On 06/17/2016 04:40 PM, Andrew Z wrote:


I understand it is very lame to refer to a technical article on 
cio.com . and yet I'll try :)


http://www.cio.com/article/3085079/linux/goodbye-rpm-and-deb-hello-snaps.html

I never heard of it and just wonder how much of real value is in this 
new system.




Related LWN : http://lwn.net/Articles/691309/

Re: [SCIENTIFIC-LINUX-USERS] Scientific linux 6.7 to 7.x

[Pat Riehecky]

Hello,

There is no approved approach.

http://ftp.scientificlinux.org/linux/scientific/7x/x86_64/release-notes/#_upgrading_from_sl_6

Pat

On 05/12/2016 03:19 PM, John Black wrote:

Is there away to upgrade with yum form SL 6x to SL 7x?

Thank you

John

Re: [SCIENTIFIC-LINUX-USERS] repodata error for SL5 sl-testing

[Pat Riehecky]

On 03/06/2014 11:47 AM, Franchisseur Robert wrote:

Hello,

I got the following error messages with yum :

sl-testing/primary_db   
 | 1.2 kB 00:00
http://ftp1.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/8596812757300b1d87f2682aff7d323fdeb5dd8ee28c11009e5980cb5cd4be14-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
sl-testing/primary_db   
 | 1.2 kB 00:00
http://ftp2.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/8596812757300b1d87f2682aff7d323fdeb5dd8ee28c11009e5980cb5cd4be14-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
sl-testing/primary_db   
 | 1.2 kB 00:00
ftp://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/8596812757300b1d87f2682aff7d323fdeb5dd8ee28c11009e5980cb5cd4be14-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
sl-testing/primary_db   
 | 1.2 kB 00:00
http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/8596812757300b1d87f2682aff7d323fdeb5dd8ee28c11009e5980cb5cd4be14-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
Error: failure: 
repodata/8596812757300b1d87f2682aff7d323fdeb5dd8ee28c11009e5980cb5cd4be14-primary.sqlite.bz2
 from sl-testing: [Errno 256] No more mirrors to try.




That's weird,  I'll rebuild the testing repodata..

There's nothing in their right now so it should only take a few seconds.

Pat

--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] missing update to boost-devel.i686

[Pat Riehecky]

On 09/06/2013 11:25 AM, Konstantin Olchanski wrote:

Hi, there! Nightly updates of SL6.4 are bombing because of missing 
boost-devel.i686 update in fastbugs:

--> Finished Dependency Resolution
Error: Package: boost-devel-1.41.0-17.el6_4.i686 (@triumfcs-mirror-sl-fastbugs)
Requires: boost = 1.41.0-17.el6_4
Removing: boost-1.41.0-17.el6_4.x86_64 
(@triumfcs-mirror-sl-fastbugs)
boost = 1.41.0-17.el6_4
Updated By: boost-1.41.0-18.el6.x86_64 (triumfcs-mirror-sl-fastbugs)
boost = 1.41.0-18.el6
Available: boost-1.41.0-11.el6_1.2.x86_64 (sl)
boost = 1.41.0-11.el6_1.2
Available: boost-1.41.0-15.el6_4.x86_64 (sl-security)
boost = 1.41.0-15.el6_4
  You could try using --skip-broken to work around the problem

Indeed, the update -devel.i686 is absent:

[root@titan01 ~]# yum list boost-devel boost-devel.i686
Loaded plugins: refresh-packagekit, security
Installed Packages
boost-devel.i6861.41.0-17.el6_4 
 @triumfcs-mirror-sl-fastbugs
boost-devel.x86_64  1.41.0-17.el6_4 
 @triumfcs-mirror-sl-fastbugs
Available Packages
boost-devel.x86_64  1.41.0-18.el6   
 triumfcs-mirror-sl-fastbugs
[root@titan01 ~]#


P.S. Time to renew my eternal complaint -

?!?WHY DO BUSTED UPDATES TO SOME JUNK PACKAGE BLOCK ALL SECURITY UPDATES?!?

Why can't "they" fix it already now (in yum, in yum-autoupdate, etc)?

(The CERN version of yum-autoupdate does not block security updates).


P.P.S. Yes, right, there was this bike accident a while back, so maybe no fix 
in yum. RIP.




The upstream release of boost (BA-2013:1187-1) does not list 
boost-devel-1.41.0-18.el6.i686.rpm within the x86_64 tree.  Thus it was not 
placed in the x86_64 tree.  We have followed the published upstream package 
lists.  When this was published repoclosure did complain which is why I 
verified the package list against upstream before announcing the update.


Is their documentation inaccurate in this regard - does it not match what 
they've actually done?


As for the CERN package, their code is significantly different from the SL 
package.  Their update script appears to utilize --skip-broken on all update 
operations (I've not fully read the script at this time, but this appears true 
for SLC5 and SLC6 systems).  Is this a feature you wish to be available for 
the SL package?  Since I'm not aware of any previous discussion on this and 
have only spent a few moments thinking about it while my lunch microwaves, I 
officially commit to nothing.  If you wish to open a dialog on this, you may.



Pat


PS, unrelated to boost, I've got a few patches posted to fedora's bugzilla for 
adding a few of the yum-autoupdate features to yum-cron-3.4.3.  It already has 
a boolean to enable 'skip-broken' in its configuration files.  I don't believe 
that version can be loaded onto any SL systems - requires python 2.7.


--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

My mother always said, "When you think someone should do
something, don't forget you are a someone too."

Re: [SCIENTIFIC-LINUX-USERS] SL5 sl-testing repo problem.

[Pat Riehecky]

On 08/30/2013 01:31 PM, Franchisseur Robert wrote:

-- Le (On) 2013-08-30 -0500 à (at) 12:57:22 Pat Riehecky écrivit (wrote): --


On 08/30/2013 12:46 PM, Franchisseur Robert wrote:

Hello,
  
on myy SL5.9 desktop a :


yum --enablerepo=* info idesk

gives checksum error on sl-testing.



That is surprising, the testing repodata hasn't changed in months

There were some obsolete packages in there which have already been released
so I've archived them and rebuilt the metadata for that repo.

May I suggest

yum --enablerepo=sl-testing clean expire-cache


I had done a yum clean all

I just did

yum --enablerepo=sl-testing clean expire-cache

but I now got different messages (Damaged repomd.xml file )

http://ftp1.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/repomd.xml:
 [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://ftp2.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/repomd.xml:
 [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
sl-testing  
 |0 B 00:00
ftp://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/repomd.xml:
 [Errno -1] Error importing repomd.xml for sl-testing: Damaged repomd.xml file
Trying other mirror.
http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/repomd.xml:
 [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://ftp1.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
http://ftp2.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
sl-testing/primary_db   
 |0 B 00:00
ftp://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
Error: failure: 
repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2
 from sl-testing: [Errno 256] No more mirrors to try.




All righty, lets try it one more time.

I've dumped the repodata and built a new repo for testing from scratch.

Pat



--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] SL5 sl-testing repo problem.

[Pat Riehecky]

On 08/30/2013 12:46 PM, Franchisseur Robert wrote:

Hello,
  
on myy SL5.9 desktop a :


yum --enablerepo=* info idesk

gives checksum error on sl-testing.


sl-testing  
 | 2.9 kB 00:00
sl-testing/primary_db   
 | 9.2 kB 00:00
http://ftp1.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
sl-testing/primary_db   
 | 9.2 kB 00:00
http://ftp2.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
sl-testing/primary_db   
 | 9.2 kB 00:00
ftp://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
sl-testing/primary_db   
 | 9.2 kB 00:00
http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
sl-testing/primary_db   
 | 9.2 kB 00:01
http://ftp1.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
sl-testing/primary_db   
 | 9.2 kB 00:00
http://ftp2.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
sl-testing/primary_db   
 | 9.2 kB 00:00
ftp://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
sl-testing/primary_db   
 | 9.2 kB 00:00
http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2:
 [Errno -3] Error performing checksum
Trying other mirror.
Error: failure: 
repodata/d580b8a9f1ffacdf4ae9f410fbbc8f33b0a0ec1012544f634d18d8a9fc297f4c-primary.sqlite.bz2
 from sl-testing: [Errno 256] No more mirrors to try.




That is surprising, the testing repodata hasn't changed in months

There were some obsolete packages in there which have already been released so 
I've archived them and rebuilt the metadata for that repo.


May I suggest

yum --enablerepo=sl-testing clean expire-cache

--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: peculiar statd/mountd problem

[Pat Riehecky]

In the past I've used this file for /etc/sysconfig/nfs on SL6.

LOCKD_TCPPORT=31001
LOCKD_UDPPORT=31001
MOUNTD_PORT=31002
RQUOTAD_PORT=31003
STATD_OUTGOING_PORT=31004
STATD_PORT=31005

I can't speak for SL 5

On 06/26/2013 01:38 PM, Steven C Timm wrote:

According to the man pages for rpc.statd it is possible to specify a fixed port 
for that daemon at startup.  I've never tried.

Steve Timm


-Original Message-
From: owner-scientific-linux-us...@listserv.fnal.gov 
[mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Steven C 
Timm
Sent: Wednesday, June 26, 2013 1:34 PM
To: Eve V. E. Kovacs; scientific-linux-users
Cc: Patrick Riehecky
Subject: RE: peculiar statd/mountd problem

I have a SLF5 system which is only an NFS client but I see the same issue that 
rpc.statd is running on a different port for UDP than it is for TCP.  We have 
seen some strange issues with the automount on this system failing a couple of 
times to mount the remote client system.  Wonder if this is related to what you 
are seeing.  It could be.

Steve Timm


-Original Message-
From: owner-scientific-linux-us...@listserv.fnal.gov 
[mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Eve V. E. 
Kovacs
Sent: Wednesday, June 26, 2013 1:24 PM
To: scientific-linux-users
Cc: Patrick Riehecky
Subject: peculiar statd/mountd problem

We have an SL5.5 nfs server that has developed an odd problem.
We have configured /etc/sysconfig/nfs to assign port numbers for the various 
services, 662 for statd and 892 for mountd, in particular.
For reasons unknown, rpc.statd, in addition to running on port 662 as directed, 
has grabbed port 892 for running udp.

We see, on the server:
rpc.statd 2412 rpcuser3u  IPv4   7443   UDP *:662
rpc.statd 2412 rpcuser6u  IPv4   7434   UDP *:892
rpc.statd 2412 rpcuser7u  IPv4   7446   TCP *:662 (LISTEN)

Since 892 was the port that was assigned to mountd, it caused mountd to fail, 
and hence nfs mounts from the clients to fail.

We have switched mountd to run on port 895 for the time being, so we are 
functional, but we would like to understand what happened.
We are running an identical backup server, and interestingly, there, the extra 
port being grabbed by statd is 982 not 892!

Has anyone else seen this behavior, or have any idea why the two servers are 
behaving differently?
Presumably this extra port for statd is being assigned by portmap.
Is there any way to fix this port assigment so that we don't get a collision 
like this in the future?

Thanks
Eve

ps. we tried booting to the previous kernel but that did not fix the problem
***
Eve Kovacs
Argonne National Laboratory,
Room L-177, Bldg. 360, HEP
9700 S. Cass Ave.
Argonne, IL 60439 USA
Phone: (630)-252-6208
Fax:   (630)-252-5047
email: kov...@anl.gov
*******



--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] SL6.4 broken VNC

[Pat Riehecky]

On 04/29/2013 11:24 AM, Konstantin Olchanski wrote:

Hello, there - the SL6.4 update broke VNC - the GLX extension is missing and
OpenGL programs do not work (glxinfo, glxgears).

Upstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=956752
Upstream errata: http://rhn.redhat.com/errata/RHBA-2013-0780.html
Corrected upstream package: tigervnc-1.1.0-5.el6_4.1.src.rpm

This is very bad breakage, can this fix be expedited to the SL 6.4 errata 
quickly quickly quickly?



This update will be released per our usual schedule - typically non-security 
packages are released on Tuesday mornings Illinois time.


Pat

--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] compiling 32 app on 64 machine

[Pat Riehecky]

On 04/19/2013 11:19 AM, Konstantin Olchanski wrote:

On Fri, Apr 19, 2013 at 09:06:41AM -0400, Nico Kadel-Garcia wrote:

On Fri, Apr 19, 2013 at 8:58 AM, Andrew Z  wrote:

Hello,
  i'e been trying to compile the 32 bit app (
https://bitcointalk.org/index.php?topic=167229.0) on my 64 machine.

In general, don't bother trying to cross-compile.


In general, cross-compile works just fine.





For building SL we use mock and cross compile through that.

You can find some sample mock configs in the sl-addons repo

http://ftp.scientificlinux.org/linux/scientific/6x/addons/x86_64/

Pat

--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Scientific Linux 6.4 RC2 - posted for testing

[Pat Riehecky]

irrors

Mailing Lists

scientific-linux-users@fnal.gov - Users of Scientific Linux supporting
  each other
scientific-linux-de...@fnal.gov - Development of Scientific Linux
scientific-linux-annou...@fnal.gov - Announcements concerning Scientific
 Linux
scientific-linux-err...@fnal.gov -  Announcements about Security Errata
scientific-linux-mirr...@fnal.gov - Announcements about Scientific Linux
related to mirroring



--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] IPMI broken in SL6 until OpenIPMI update is released

[Pat Riehecky]

On 03/22/2013 06:29 PM, Vladimir Mosgalin wrote:

Hello everybody.

I rebooted with current kernel from sl-security (2.6.32-358.2.1.el6) and
discovered that IPMI completely stopped working. Service
/etc/init.d/ipmi prints "FAILED" when starting, /dev/ipmi* device isn't
created and so on.

TUV introduced change in 6.4 - kernel ipmi support is compiled in
(CONFIG_IPMI_SI=y instead of =m in previous versions), so
init script is supposed to just activate it, instead of old code that
loads module & such. Package with fixed initscript is available as
OpenIPMI-2.0.16-14: https://rhn.redhat.com/errata/RHBA-2013-0492.html

However, currently SL6 offers new kernel, but old OpenIPMI from 6.3, so
everything IPMI-related refuses to work until user manually rebuilds &
updates to that SRPM.



Thank you for the bug report.

An updated package is being pushed at this time.

Pat

--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] Wrong file readdir on NFS client

[Pat Riehecky]

On 03/20/2013 07:55 AM, Akemi Yagi wrote:

On Wed, Mar 20, 2013 at 1:22 AM, Antonietta Donzella
 wrote:

Hi,
I share directories on a Scientific linux cluster by using nfs tool.
SLC6 kernel 2.6.32-279.22.1.el6.x86_64
nfs-utils-1.2.3-26.el6.x86_64

After a server-client shutdown, a disagreeable event occurred.
By making ls list on a nfs client shared directory, duplicated entries for
some files are shown.
Other files and sub-directories are non visible. The problem is not present
on the nfs server.
The directory don't contain an enormous number of files:

On the server:
#ls |wc -l
330
#du -s
8855740

On the client:
#ls |wc -l
ls: reading directory .: Too many levels of symbolic links
120
n.b. there are only two symbolic links and they are not changed after the
shutdown; however, the problem is not cleared if I remove them. #du -s
not responding
#dmesg
some entries:
...
NFS: directory images/dp contains a readdir loop.Please contact your server
vendor. The file: .. has duplicate cookie 683570819
NFS: directory images/dp contains a readdir loop.Please contact your server
vendor. The file: .. has duplicate cookie 683570819
__ratelimit: 2 callbacks suppressed
NFS: directory images/green contains a readdir loop.Please contact your
server vendor. The file: 57.png has duplicate cookie 1694199390
NFS: directory images/green contains a readdir loop.Please contact your
server vendor. The file: 57.png has duplicate cookie 1694199390
...

I've tried to boot the system with the older kernel-2.6.32-279.el6.x86_64,
and with the new kernel 2.6.32-358.2.1.el6.x86_64 but the bug is not
cleared. Any ideas?

Many thanks in advance
Antonietta

Looks like you are affected by a known bug. It is probably the same as this one:

http://bugs.centos.org/view.php?id=6241

If so, there is no fix at the moment unfortunately.

Akemi


I've heard an rumor that disabling dir_index on the 'EXT' family of 
filesystems will work around the behavior.


This information is presented without recommendation.

Pat

--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] Security ERRATA Low: ipa on SL6.x i386/x86_64

[Pat Riehecky]

On 03/20/2013 08:41 AM, Sean Murray wrote:

Hi

I cant configure ipa to as dns, please see bottom.

On 03/04/2013 09:09 PM, Pat Riehecky wrote:

Synopsis: Low: ipa security, bug fix and enhancement update
Issue Date: 2013-02-21
CVE Numbers: CVE-2012-4546
--

It was found that the current default configuration of IPA servers did not
publish correct CRLs (Certificate Revocation Lists). The default configuration
specifies that every replica is to generate its own CRL; however, this can
result in inconsistencies in the CRL contents provided to clients from
different Identity Management replicas. More specifically, if a certificate is
revoked on one Identity Management replica, it will not show up on another
Identity Management replica. (CVE-2012-4546)
--

SL6
x86_64
ipa-client-3.0.0-25.el6.x86_64.rpm
ipa-debuginfo-3.0.0-25.el6.x86_64.rpm
ipa-python-3.0.0-25.el6.x86_64.rpm
ipa-admintools-3.0.0-25.el6.x86_64.rpm
ipa-server-3.0.0-25.el6.x86_64.rpm
ipa-server-selinux-3.0.0-25.el6.x86_64.rpm
ipa-server-trust-ad-3.0.0-25.el6.x86_64.rpm
i386
ipa-client-3.0.0-25.el6.i686.rpm
ipa-debuginfo-3.0.0-25.el6.i686.rpm
ipa-python-3.0.0-25.el6.i686.rpm
ipa-admintools-3.0.0-25.el6.i686.rpm
ipa-server-3.0.0-25.el6.i686.rpm
ipa-server-selinux-3.0.0-25.el6.i686.rpm
ipa-server-trust-ad-3.0.0-25.el6.i686.rpm

The following packages were added for dependency resolution
SL6
x86_64
certmonger-0.61-3.el6.x86_64.rpm
mod_nss-1.0.8-18.el6.x86_64.rpm
nss-3.14.0.0-12.el6.i686.rpm
nss-3.14.0.0-12.el6.x86_64.rpm
nss-devel-3.14.0.0-12.el6.i686.rpm
nss-devel-3.14.0.0-12.el6.x86_64.rpm
nss-pkcs11-devel-3.14.0.0-12.el6.i686.rpm
nss-pkcs11-devel-3.14.0.0-12.el6.x86_64.rpm
nss-sysinit-3.14.0.0-12.el6.x86_64.rpm
nss-tools-3.14.0.0-12.el6.x86_64.rpm
nss-util-3.14.0.0-2.el6.i686.rpm
nss-util-3.14.0.0-2.el6.x86_64.rpm
nss-util-devel-3.14.0.0-2.el6.i686.rpm
nss-util-devel-3.14.0.0-2.el6.x86_64.rpm
policycoreutils-2.0.83-19.24.el6.x86_64.rpm
policycoreutils-gui-2.0.83-19.24.el6.x86_64.rpm
policycoreutils-newrole-2.0.83-19.24.el6.x86_64.rpm
policycoreutils-python-2.0.83-19.24.el6.x86_64.rpm
policycoreutils-sandbox-2.0.83-19.24.el6.x86_64.rpm

i386
certmonger-0.61-3.el6.i686.rpm
mod_nss-1.0.8-18.el6.i686.rpm
nss-3.14.0.0-12.el6.i686.rpm
nss-devel-3.14.0.0-12.el6.i686.rpm
nss-pkcs11-devel-3.14.0.0-12.el6.i686.rpm
nss-sysinit-3.14.0.0-12.el6.i686.rpm
nss-tools-3.14.0.0-12.el6.i686.rpm
nss-util-3.14.0.0-2.el6.i686.rpm
nss-util-devel-3.14.0.0-2.el6.i686.rpm
policycoreutils-2.0.83-19.24.el6.i686.rpm
policycoreutils-gui-2.0.83-19.24.el6.i686.rpm
policycoreutils-newrole-2.0.83-19.24.el6.i686.rpm
policycoreutils-python-2.0.83-19.24.el6.i686.rpm
policycoreutils-sandbox-2.0.83-19.24.el6.i686.rpm


I think bind-dyndb-ldap-2.3.2 needs to be added to that dependency list.

On attempting to configure ipa-server-3.0.0 for dns it complains the 
bind-dyndb-ldap
is not installed. On installing it says it needs 2.3.2 but only 
1.1.0-0.9.b1.el6_3.1 is available.
It is however available in 6.4 though, where 3.0.0 will happily run more 
than likely.


Although the source packages
http://ftp.scientificlinux.org/linux/scientific/6.4/SRPMS/vendor/bind-dyndb-ldap-1.1.0-0.9.b1.el6_3.1.src.rpm 


is the latest but
http://ftp.scientificlinux.org/linux/scientific/6.4/i386/os/Packages/bind-dyndb-ldap-2.3-2.el6.i686.rpm 


I cant find the src to build it myself.

There was mention of a similar problem in the transition from 6.1 to 6.2 at
http://listserv.fnal.gov/scripts/wa.exe?A2=ind1201&L=scientific-linux-users&T=0&P=6283 



Must I simply wait for 6.4 ?

Thanks
Sean




I'm pushing the updated bind-dyndb-ldap package at this time.  It should be 
available in the next 45 minutes.


Pat


--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] java in firefox

[Pat Riehecky]

On 03/13/2013 06:57 PM, Yasha Karant wrote:

On 03/09/2013 09:02 AM, Lamar Owen wrote:

On 03/07/2013 08:38 PM, Yasha Karant wrote:

We have bioinformatics visualization applications that require a java
plugin enabled web browser.   The only plugin from Oracle/Sun Java
that works is:

URL:  http://java.com/en/download/linux_manual.jsp
Java Downloads for Linux
Recommended Version 7 Update 17

 Linux RPM filesize: 54.7 MB Instructions After installing
Java, you will need to enable Java in your browser.
Linux filesize: 45.9 MB Instructions
Linux x64 * filesize: 44.6 MB Instructions
Linux x64 RPM * filesize: 52.8 MB Instructions32-bit version
for Java applet and Java Web Start suppor
* Please use the 32-bit version for Java applet and Java Web Start
support.

End quote from java.com
...
Has anyone else encountered this problem and does anyone have a
work-around?

Since Scientific Linux 6 and CentOS 6 are so similar, the CentOS wiki
content is applicable:
http://wiki.centos.org/TipsAndTricks/PluginsFor64BitFirefox

I am personally running 64-bit Firefox and the Sun/Oracle Java 17
(CentOS 6.4 x86_64, fully updated this morning):

[lowen@dhcp-pool146 ~]$ java -version
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
[lowen@dhcp-pool146 ~]$ rpm -qa|grep firefox
firefox-17.0.3-1.el6.centos.x86_64
[lowen@dhcp-pool146 ~]$ rpm -qa|grep jre
jre-1.7.0_17-fcs.x86_64
[lowen@dhcp-pool146 ~]$

 From about:plugins in Firefox:
+++
Enabled plugins
Find more information about browser plugins at mozilla.org.
Find updates for installed plugins at mozilla.com/plugincheck.
Help for installing plugins is available from plugindoc.mozdev.org.
Java(TM) Plug-in 1.7.0_17

 File: libnpjp2.so
 Version:
 Java plug-in for NPAPI-based browsers.
...
+++

I've attached a jpg of the run on the Oracle java testing page..
(might not make it to the list, so copying directly to Yasha).

The instructions pointed to by the CentOS wiki page at
http://wiki.centos.org/HowTos/JavaRuntimeEnvironment worked here, as far
as I remember, since it has been a few months since I initially got it
working.

Oracle's docs are wrong about 64 bit Firefox and the 64-bit plugin for
applets.  I haven't tried Webstart, so don't know if that works or not.
I seem to remember some things being a pain to find (the Java console,
perhaps, to be able to clear the java cache?), but it works for the
applets I need.

I don't know why the Oracle docs still say that the 32-bit plugin and
browser is required; I haven't experienced any issues with the applets
that I have run.  And mixing in the 32-bit stuff really complicates things.



From: http://wiki.centos.org/TipsAndTricks/PluginsFor64BitFirefox

Note: CentOS-5 ships with java-1.6.0-openjdk but the x86_64 
java-1.6.0-openjdk-plugin package is missing. There is still no native Java 
plugin for CentOS-6.


End quote.

We are using SL 6x x86-64, presumably "the same" as CentOS 6,  as both are 
direct ports of TUV EL6.  It is claimed on the above URL that there is no 
native Java plugin for CentOS 6, although your experience with the Oracle 
64bit Java package indicates that there is such a plugin.


SL6 ships with icedtea-web on x86_64.  This is a java plugin for web browsers.

I can't speak to the Oracle side of things, but there is a native java plugin 
for x86_64 in SL.


SL 6.4 BETA has the following:

$ rpm -qi  icedtea-web
Name: icedtea-web  Relocations: (not relocatable)
Version : 1.2.2 Vendor: Scientific Linux
Release : 3.el6 Build Date: Fri 22 Feb 2013 
07:13:06 AM CST

Install Date: Fri 01 Mar 2013 03:08:15 PM CST  Build Host: sl6.fnal.gov
Group   : Applications/Internet Source RPM: 
icedtea-web-1.2.2-3.el6.src.rpm
Size: 869794   License: LGPLv2+ and GPLv2 with 
exceptions

Signature   : DSA/SHA1, Fri 22 Feb 2013 09:47:56 AM CST, Key ID b0b4183f192a7d7d
Packager: Scientific Linux
URL : http://icedtea.classpath.org/wiki/IcedTea-Web
Summary : Additional Java components for OpenJDK
Description :
The IcedTea-Web project provides a Java web browser plugin, an implementation
of Java Web Start (originally based on the Netx project) and a settings tool to
manage deployment settings for the aforementioned plugin and Web Start
implementations.


Pat

--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] ath9k wifi dropouts

[Pat Riehecky]

On 03/14/2013 04:50 AM, Steven Haigh wrote:

On 14/03/13 16:20, Steven Haigh wrote:

On 14/03/13 09:42, Steven Haigh wrote:

On 03/14/2013 01:54 AM, Matt Lewandowsky wrote:

On Wed, 13 Mar 2013 19:27:48 +1100, From: net...@crc.id.au


So, as far as the access point goes, it seems the client disassociates
itself, then associates again.

The PC seems think that the access point has gone away, and
disconnects.

Strange.



When your system thinks the AP has gone away, do any other associated
clients believe this, as well? Do you see this behavior if one of them
does large amounts of traffic?


Interestingly, no. The laptop didn't either under the Windows 7 drivers.
It just seems under linux now, it drops out.

What is driving me insane is that work has a WRT54GL router running
dd-wrt and that *doesn't* drop out. I have a WRT54GS running dd-wrt and
it does.

I've been trying different versions of dd-wrt at home - thinking maybe
that is where the issue lies - but as yet, I haven't managed to track it
down.



As a data point here, I'm going to try installing Fedora 18 (urrgh) to
see if it still drops out. Don't worry, I'll be back - but I need more
info ;)



Ok - so now I am completely confused. Fedora 18 was up for 2 hours, not a 
single wifi dropout.


The output of 'iw event -t' shows:
1363253967.217613: wlan0 (phy #0): scan started
1363253970.972935: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 
2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1363253970.974107: wlan0 (phy #0): connection quality monitor event: RSSI 
went below threshold

1363254087.216325: wlan0 (phy #0): scan started
1363254090.968303: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 
2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1363254090.975328: wlan0 (phy #0): connection quality monitor event: RSSI 
went below threshold

1363254207.218842: wlan0 (phy #0): scan started
1363254210.965364: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 
2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1363254210.972594: wlan0 (phy #0): connection quality monitor event: RSSI 
went below threshold
1363254282.979366: wlan0 (phy #0): connection quality monitor event: RSSI 
went below threshold


Not a single drop... One thing I noticed is that I think the 'unknown event' 
in the SL wireless output is the connection quality notice above.


So. Where to go from here?

Fedora 18:
kernel-3.8.2-206
wireless-tools-29-8.1

SL6.4
kernel-3.8.2 (from elrepo)
wireless-tools-29-5.1.1

Pat: Any ideas? Now I'm stumped unless I file a bug upstream? As its not a 
EL kernel though, they may just tell me to go away. Yet my bug remains about 
the EEEPC module on the stock x86_64 kernels. *sigh*




It is a long shot, but is there anything interesting in the differences 
between the packages you've listed?


Perhaps a bug fix in wireless-tools-29-8.1 or a patch to ath9k in 
kernel-3.8.2-206 may be the key here


Pat


--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] ath9k wifi dropouts

[Pat Riehecky]

On 03/12/2013 04:03 PM, Steven Haigh wrote:

On 13/03/13 02:58, Steven Haigh wrote:

On 03/13/2013 02:54 AM, Pat Riehecky wrote:

On 03/12/2013 05:45 AM, Steven Haigh wrote:

On 12/03/13 21:03, Steven Haigh wrote:

Hi all,

I've been trying to figure out the cause of this... It seems I'll be
using the wifi without issue, then NetworkManager will indicate that it
is reconnecting. It seems to happen randomly with no real pattern.

iw events -t shows:
4b:d6:98:14:48 -> 00:0f:66:c5:2d:6b reason 3: Deauthenticated because
sending station is leaving (or has left) the IBSS or ESS
1363082116.240481: wlan0 (phy #0): disconnected (local request)

1363082122.323703: wlan0 (phy #0): auth 00:0f:66:c5:2d:6b ->
1c:4b:d6:98:14:48 status: 0: Successful
1363082122.344295: wlan0 (phy #0): assoc 00:0f:66:c5:2d:6b ->
1c:4b:d6:98:14:48 status: 0: Successful
1363082122.347571: wlan0 (phy #0): connected to 00:0f:66:c5:2d:6b

Interestingly, I've only had this problem under linux. The access point
is stable and works fine with the same card under Windows 7 - as
well as
our smart phones etc etc. The access point hasn't changed in a
number of
years (4+).

At the moment, I'm using the kernel-ml from elrepo until I can get the
eeepc module re-enabled for 64 bit kernels from our wondering upstream
provider. (Battery life dies to about 3.5 hours instead of 5+ with it!)

I've tried 'iwconfig wlan0 power off' to disable power management from
the wifi adapter, but the dropouts still seem to randomly happen.
The AP
is secured with WPA2-PSK (AES+TKIP) - not sure if that makes a
difference...

Does anyone have any thoughts in troubleshooting this?



I should note as well that I added the following to a new file called
/etc/modprobe.d/wireless.conf:
options ath9k nohwcrypt=1

This doesn't seem to have made a difference.



I've got one of these at home and I see similar behavior - it drops out
rather often.  I've not found a fix...


Dang! Its rather annoying to say the least. I've even tried kernel 3.8.2
(which has the eeepc_laptop module included in the 64 bit kernel.

Might have to do some more research



This is interesting. I'm sitting at work using the exact same brand / model 
access point as I have at home - yet it hasn't dropped out once. I'm 
wondering if I should factory reset the one at home and see if it makes a 
difference.


Pat: What type of router / AP do you have?



I've got a WRT54GL (tomato-wrt)

Pat


--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] mod_wsgi version?

[Pat Riehecky]

On 03/08/2013 03:36 PM, Ken Teh wrote:
I'm having trouble getting mod_wsgi to work.  There is a warning in the 
httpd logs that says mod_wsgi was compiled for Python 2.6.5; I am running 
2.6.6 which is the current version in the SL repo.


There are 2 mod_wsgi SRPMs - a 3.2.1 version and a 3.2.3 version, but there 
is only a 3.2.1 binary rpm.  Can someone clarify?


Should I grab the 3.2.3 srpm and rebuild it with my current python?  It's 
only a warning so I thought it would work but it's pretty obvious the 
WSGIScriptAlias directive has no effect.


Thanks!


mod_wsgi-3.2.3 was released with SL 6.3.  Are you running an older release?

Pat

--
Pat Riehecky
Scientific Linux developer
http://www.scientificlinux.org/