After the 7.2 upgrade boost-openmpi-1.53.0-25 was installed, along
with openmpi-1.10.0-10. The old openmpi was then replaced with compat-
openmpi16-1.6.4-10. All fine.
Except boost-openmpi has a dependency on the old libmpi.so.1 and the
new openmpi has libmpi.so.12:
# ldd libboost_mpi-mt.so.1.53.0
linux-vdso.so.1 => (0x00007ffe8c182000)
libboost_serialization-mt.so.1.53.0 => /lib64/libboost_serialization-mt.so.1.53.0 (0x00007f39da4d2000)
…
[View More]libmpi.so.1 => not found
libmpi_cxx.so.1 => /usr/lib64/openmpi/lib/libmpi_cxx.so.1 (0x00007f39da2b6000)
librt.so.1 => /lib64/librt.so.1 (0x00007f39da0ae000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f39d9da5000)
libm.so.6 => /lib64/libm.so.6 (0x00007f39d9aa3000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f39d988d000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f39d9670000)
libc.so.6 => /lib64/libc.so.6 (0x00007f39d92af000)
libmpi.so.12 => /usr/lib64/openmpi/lib/libmpi.so.12 (0x00007f39d8fcc000)
libopen-rte.so.12 => /usr/lib64/openmpi/lib/libopen-rte.so.12 (0x00007f39d8d4f000)
libopen-pal.so.13 => /usr/lib64/openmpi/lib/libopen-pal.so.13 (0x00007f39d8aac000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f39d88a8000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f39d86a4000)
libhwloc.so.5 => /lib64/libhwloc.so.5 (0x00007f39d8476000)
/lib64/ld-linux-x86-64.so.2 (0x00007f39da987000)
libnuma.so.1 => /lib64/libnuma.so.1 (0x00007f39d8269000)
libpciaccess.so.0 => /lib64/libpciaccess.so.0 (0x00007f39d805f000)
libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f39d7cf6000)
libz.so.1 => /lib64/libz.so.1 (0x00007f39d7adf000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f39d78ba000)
We have tried switching to using compat-openmpi - but then the programs
don't find the boost library.
There are other ways around it (setting the LD_LIBRARY_PATH variable or
putting in symlinks so things are found), but they seem to throw
segfaults with the code.
Presumably this is just a packaging/compiling error - is there anyway
to trigger an update for the boost-openmpi package?
Pete
[View Less]
I am out of the office until 26/12/2015.
Estaré ausente de la oficina, para cualquier apoyo que necesites favor de
contactar a Edson Cota
Email: edson.cota(a)nextel.com.mx
Note: This is an automated response to your message "CentOS Digest, Vol
131, Issue 21" sent on 12/21/2015 6:00:02 AM.
This is the only notification you will receive while this person is away.
“Este mensaje y cualquier archivo que se adjunte al mismo es propiedad de GRUPO IUSACELL y podría contener información privada y …
[View More]privilegiada para uso exclusivo del destinatario. Si usted ha recibido esta comunicación por error, no está autorizado para copiar, retransmitir, utilizar o divulgar este mensaje ni los archivos adjuntos. En este caso por favor notifique inmediatamente al remitente por este mismo conducto. Gracias.”
[View Less]
Trying to specify the "installation source" in the configuration of
netinstall for centos 7 (7.1). Three places on the web said
mirror.centos.org/centos/7/os/x86_64/
But that configuration page probes, then it says, "Error setting up base
repository".
What's the magic needed?
Also, if anyone knows specs for epel and others, they might help too.
Thanks.
Send CentOS-announce mailing list submissions to
centos-announce(a)centos.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-request(a)centos.org
You can reach the person managing the list at
centos-announce-owner(a)centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."
…
[View More]Today's Topics:
1. CEBA-2015:2668 CentOS 6 watchdog FASTTRACK BugFix Update
(Johnny Hughes)
2. CESA-2015:2671 Important CentOS 5 jakarta-commons-collections
Security Update (Johnny Hughes)
----------------------------------------------------------------------
Message: 1
Date: Sun, 20 Dec 2015 17:40:13 +0000
From: Johnny Hughes <johnny(a)centos.org>
To: centos-announce(a)centos.org
Subject: [CentOS-announce] CEBA-2015:2668 CentOS 6 watchdog FASTTRACK
BugFix Update
Message-ID: <20151220174013.GA28981(a)n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2015:2668
Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-2668.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
d7a9fb01a178a2dbb1a93d5e5ca7d8744e26ade820da1e95c8250d4a88d7acd2 watchdog-5.6-5.el6.i686.rpm
x86_64:
9a8101cf52bba32ec1e6c653683ec5468aeb81ec972785136023c2a2f19923ec watchdog-5.6-5.el6.x86_64.rpm
Source:
d5a4e034185b85e189da7bdf77fad1bf1fea5ff8bf41e18da4f214966b075792 watchdog-5.6-5.el6.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos(a)irc.freenode.net
Twitter: @JohnnyCentOS
------------------------------
Message: 2
Date: Mon, 21 Dec 2015 11:17:35 +0000
From: Johnny Hughes <johnny(a)centos.org>
To: centos-announce(a)centos.org
Subject: [CentOS-announce] CESA-2015:2671 Important CentOS 5
jakarta-commons-collections Security Update
Message-ID: <20151221111735.GA12735(a)chakra.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2015:2671 Important
Upstream details at : https://rhn.redhat.com/errata/RHSA-2015-2671.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
3e91e8870eb490c06269ba53179728b3afbe6df74144a5033bd5d762591f3b3b jakarta-commons-collections-3.2-2jpp.4.i386.rpm
e204902787c9476bbeee8f399eef182ddbe8dac776d6ddd23850498558ed4399 jakarta-commons-collections-javadoc-3.2-2jpp.4.i386.rpm
81ca9f0edcf5d0cde39f5f6f81c7535ddd5f01c444e731e3387b947751f2a696 jakarta-commons-collections-testframework-3.2-2jpp.4.i386.rpm
1401ddec74229e5f7bb0da50a3d5c47b7912a2276296284096394f73c37a85b6 jakarta-commons-collections-testframework-javadoc-3.2-2jpp.4.i386.rpm
ab3d96dfe6aebc3c7b4f7ce7f0f307ddc210b1885e72ccf2d14bb9427bcd315a jakarta-commons-collections-tomcat5-3.2-2jpp.4.i386.rpm
x86_64:
74add7a4f0f7879d2108f06e5216602dd05963b88c7984b6d247d136578dc449 jakarta-commons-collections-3.2-2jpp.4.x86_64.rpm
48eb0f726e79b462a8505f7960481006a6c252bccbf37a3cccbb416030b48da8 jakarta-commons-collections-javadoc-3.2-2jpp.4.x86_64.rpm
0934cf0cb13caf4cbac653a13895b933648e40a76a4d900c8b08d1a51d2a5231 jakarta-commons-collections-testframework-3.2-2jpp.4.x86_64.rpm
314c67cfaf4bef3c95326d83fa164d64c3ede371d7c712e40598e12eebe42064 jakarta-commons-collections-testframework-javadoc-3.2-2jpp.4.x86_64.rpm
356b54c0aded684d0d0b7f5ecc056c2f62f666011c84c342b95a6863b4499b87 jakarta-commons-collections-tomcat5-3.2-2jpp.4.x86_64.rpm
Source:
1470c341f4d068e5c6fe3f8dc619f4a2be4ab7c0b720a54dd15a80a3fe1d5502 jakarta-commons-collections-3.2-2jpp.4.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos(a)irc.freenode.net
Twitter: JohnnyCentOS
------------------------------
_______________________________________________
CentOS-announce mailing list
CentOS-announce(a)centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
End of CentOS-announce Digest, Vol 130, Issue 9
***********************************************
[View Less]
My workhorse server is a SuperMicro with their H8DM8-2 motherboard. For
many years it ran CentOS 5.x and 6.x until the boot drive failed last
year. I installed a 1TB SSD as /dev/sda and planned to install CentOS 7 on
it, replacing CentOS 6.5 on the failed drive. Unfortunately every CentOS 7
media I tried, either optical disk or USB thumb drive, breaks down just a
few seconds after selecting "Install..."
The H8DM8-2 motherboard is based on the nVidia MPC55 Pro and NEC uPD720400
chipsets. It has …
[View More]an on-board Adaptec AIC-7902W dual-channel SCSI
controller and companion Zero-Channel RAID card. It has twin AMD Opteron
HE processors and 32GB of registered ECC DDR2 memory. The RAID array is
populated with ten Fujitsu 300GB 15K SCSI3 drives.
I took it into a friendly Linux shop where they reviewed / verified all of
my work and confirmed the boot-time problem. Two hours into the effort, my
friend plugged in a bootable Windows 10 thumb drive and to our amazement,
it came up very normally. So did another thumb drive with a Fedora 23
installation image. So there's nothing wrong with my hardware.
We believe the problem is due to Red Hat compiling RHEL7 without at least
one old device driver that I still need. My friend thinks we should build
an installation disk from a modified CentOS 7 live CD kickstart file and a
CentOS-Plus kernel. While that may work, I think there may be a simpler
boot-time kernel option I could use to successfully install from a stock
ISO.
Does anyone have any suggestions for boot-time options I could try?
--Doc Savage
Fairview Heights, IL
[View Less]
I'm not on the yum / RPM list and I don't know that I want to join just
to discuss this but with respect GPG keys - it is a classic example of
trust on first use.
The first time yum installs a package, it asks to import the GPG key
used to sign the packages. Most people accept without validating the key.
This is potentially exploitable because most repositories are http
What if there was a DNS TXT record that corresponds with the repository,
with the fingerprint of the key?
The DNS …
[View More]record could be DNSSEC secured (I believe Fedora already uses
DNSSEC - some of their servers anyway) and yum could refuse to ask if
the fingerprint of the key it is importing does not match the DNSSEC
secured fingerprint.
Something like TXT record for
_rpmkey.security.centos.org.
could be requested for the fingerprint for security(a)centos.org
Advantage over gpg keyrings is that it can be implemented by anyone
without needing to manage your keys with specific gpg keyrings, which
has always been messy.
When yum is first asked to import a key, it refuses if it can not DNSSEC
validate the fingerprint.
After it DNSSEC validates the fingerprint, it can then does what it
currently does, where the user can verify they trust the key.
To get a fingerprint in the centos.org zone and signed by DNSSEC would
not be easy for a malicious packager to do.
Furthermore when a signing key has been compromised (happened with
Fedora once) changing the DNS record would prevent the key from being
imported in the future, and could even prevent packages signed by that
key from being installed in the future even if the key is already imported.
For offline yum usage, a switch could be used to tell yum not to do the
DNS lookup and DNSSEC validation.
Thoughts?
[View Less]
Recent power management discussions plugged into one of our
current frustrations, namely the interaction of the screen
lock and power-save features on Intel/CentOS 6 platforms.
We certainly would not have guessed that locking the screen
would inhibit going into the power-save mode, but it sure
seems to do exactly that on some of our test platforms.
If one leaves the desktop idle for the timeout period, the
computer sleeps. If one locks the screen and then leaves
the machine idle, the …
[View More]computer does not sleep. We were
hoping that this "feature" was isolated to just our older
Dell desktop machine hardware and firmware, but it appears
elsewhere as well.
Possibly more interesting is that most of our systems were
loaded with CentOS 6.X almost two years ago and have been
updated at least weekly ever since. This new power-save
scenario has appeared just within the last three weeks,and our investigations have not discovered the cause ora solution.
[View Less]
Thinkpad T410 running CentOS 7 with the Mate desktop (Gnome 3 is too
demanding on video capabilities for this hardware)
Under CentOS 7.1 - the laptop would sleep when I closed the lid.
It no longer does. I can tell because the laptop remains warm when I
close the lid now, mail filters in Thunderbird run when the lid is
closed, and it doesn't need to re-establish wifi when opening.
This is dangerous because thinkpads cool through the keyboard.
The battery usage monitor also no longer …
[View More]works. It shows 99% battery
even as the laptop starts giving its warning beep that the battery is
exhausted and it is about to shut down.
Anyone know what broke with the update to 7.2 and how to fix it?
No 3rd party kernel modules are involved.
--
-=-
Sent my from my laptop, may not be able to respond timely
[View Less]
Hello,
I have a big problem with fail2ban and firewalld on my new system.
I have a server running (CentOS 7.1) and run a Update to 7.2 on this system
all is working ?
BUT I install a new system with CentOS 7 1511 on this systems fail2ban don't
work anymore. I have this error or more, in the firewalld
2015-12-19 08:39:55 ERROR: COMMAND_FAILED: '/sbin/iptables -w2 -t filter -I
INPUT_direct 1 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-
sshd src -j REJECT --reject-with …
[View More]icmp-port-unreachable' failed: iptables
v1.4.21: Set fail2ban-sshd doesn't exist.
Try `iptables -h' or 'iptables --help' for more information.
Is on 7.2 some missing or not installed
I installed fail2ban from the epel repo.
Thanks for a answer,
--
mit freundlichen Grüßen / best regards,
Günther J. Niederwimmer
[View Less]