Re: [CentOS] Custom ISO With Post Installation Scripts
> Hmm... > > I am doing this with a KS for C7 and my /etc/rc.d/rc.local script get > executed just fine on > boot up without doing anything other than putting it in /etc/rc.d/ > > # ls -al /etc/rc.d/ > total 72 > drwxr-xr-x 10 root root 4096 May 18 07:37 . > drwxr-xr-x 121 root root 12288 Jun 8 08:19 .. > drwxr-xr-x 2 root root 4096 May 18 15:06 init.d > drwxr-xr-x 2 root root 4096 May 18 14:56 rc0.d > drwxr-xr-x 2 root root 4096 May 18 14:56 rc1.d > drwxr-xr-x 2 root root 4096 May 24 10:21 rc2.d > drwxr-xr-x 2 root root 4096 May 24 10:21 rc3.d > drwxr-xr-x 2 root root 4096 May 24 10:21 rc4.d > drwxr-xr-x 2 root root 4096 May 24 10:21 rc5.d > drwxr-xr-x 2 root root 4096 May 18 14:56 rc6.d > -rwxr-xr-x 1 root wheel 20080 May 18 09:14 rc.local > > A little investigation shows that the problem was with the script that is supposed to execute, I used a simple script and it worked, actually the problem was #!/bin/bash was on the second line and not the first, bit embarrassing but glad that it is working. Thanks, guys. -- Kind Regards Earl Ramirez ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS7: Setting up ldap over TLS in kickstart file
On 06/14/2018 01:01 AM, Patrick Begou wrote: In my kickstart file I use: auth --useshadow --enableldaptls --enablecache --passalgo=sha512 --enableldap --enableldapauth --ldapserver="ldaps://my.ldap.server.fr" --ldapbasedn=dc=my,dc=base,dc=dn Then in a post install script I download the server and ca certificates and stops nslcd that I do not use: You probably can avoid setting up nslcd in the first place: auth --useshadow --passalgo=sha512 --enablesssd --enablesssdauth --enableldap --ldapserver="ldaps://my.ldap.server.fr" --ldapbasedn=dc=my,dc=base,dc=dn echo "TLS_REQCERT allow">>/etc/openldap/ldap.conf cd /etc/openldap/cacerts/ && wget http://xxx.xxx.xxx.xxx/Softwares7/LDAPCERTS/ca-bundle.crt && ln -s ca-bundle.crt $(openssl x509 -hash -in ca-bundle.crt -noout).0 cd /etc/openldap/certs/ && wget http://xxx.xxx.xxx.xxx/Softwares7/LDAPCERTS/server.crt See the man page for update-ca-trust. I *think* you need to do something more like: cd /etc/pki/ca-trust/source/anchors/ wget http://xxx.xxx.xxx.xxx/Softwares7/LDAPCERTS/ca-bundle.crt update-ca-trust extract ...you shouldn't have to do anything with the server's cert specifically. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Updated krb5 rpm package altered existing krb5.conf - No go
On 06/14/2018 09:30 AM, m...@tdiehl.org wrote: On Thu, 14 Jun 2018, Richard Grainger wrote: I looked at the spec file in the source RPM for the krb5-libs package and it it has the correct %config(noreplace) directive next to that file in the %files section, so this is mysterious. I too can confirm this behavior. # rpm -qa krb\* --triggers triggerun scriptlet (using /bin/sh) -- krb5-libs < 1.15.1-13 if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then sed -i '1i # Other applications require this directory to perform krb5 configuration.\nincludedir /etc/krb5.conf.d/\n' /etc/krb5.conf fi Looks like that's the culprit. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Custom ISO With Post Installation Scripts
On 06/14/2018 01:24 PM, Earl A Ramirez wrote: > On 11 June 2018 at 01:57, Prasad K wrote: > >> If your distro is using systemd then rc.local will not get executed by >> default. >> Enable rc-local.service : "systemctl enable rc-local.service". >> >> > Thanks, Prasad > > I tried that and unfortunately, that service did not start after the server > was rebooted; therefore the script was not called by > systemd-rc-local-generator. > > Will continue to investigate and report back > Hmm... I am doing this with a KS for C7 and my /etc/rc.d/rc.local script get executed just fine on boot up without doing anything other than putting it in /etc/rc.d/ # ls -al /etc/rc.d/ total 72 drwxr-xr-x 10 root root 4096 May 18 07:37 . drwxr-xr-x 121 root root 12288 Jun 8 08:19 .. drwxr-xr-x 2 root root 4096 May 18 15:06 init.d drwxr-xr-x 2 root root 4096 May 18 14:56 rc0.d drwxr-xr-x 2 root root 4096 May 18 14:56 rc1.d drwxr-xr-x 2 root root 4096 May 24 10:21 rc2.d drwxr-xr-x 2 root root 4096 May 24 10:21 rc3.d drwxr-xr-x 2 root root 4096 May 24 10:21 rc4.d drwxr-xr-x 2 root root 4096 May 24 10:21 rc5.d drwxr-xr-x 2 root root 4096 May 18 14:56 rc6.d -rwxr-xr-x 1 root wheel 20080 May 18 09:14 rc.local -- Stephen Clark *NetWolves Managed Services, LLC.* Sr. Applications Architect Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Custom ISO With Post Installation Scripts
On 11 June 2018 at 01:57, Prasad K wrote: > If your distro is using systemd then rc.local will not get executed by > default. > Enable rc-local.service : "systemctl enable rc-local.service". > > Thanks, Prasad I tried that and unfortunately, that service did not start after the server was rebooted; therefore the script was not called by systemd-rc-local-generator. Will continue to investigate and report back -- Kind Regards Earl Ramirez ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Kernel Support
On 06/14/18 11:23, Stephen John Smoogen wrote: On 14 June 2018 at 12:16, Peter Kjellström wrote: On Thu, 14 Jun 2018 10:12:30 -0500 Valeri Galtsev wrote: On 06/14/18 10:00, Peter Kjellström wrote: On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi wrote: ... The src.rpm for that kernel is probably available somewhere. I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it). ... I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else. GPL requires to provide source if everything derived from the original source to everybody, not only to customers. And RedHat was ever compliant with GPL. Kudos to RedHat! So, if there exist patched kernels of out of support life, they should be downloadable somewhere somehow. No you are minunderstanding the GPL. You are only required to provide source to those who got the binary artifact(s). They then have the full GPL rights to further modify etc. In many cases the binaries are distributed to everyone and then so is the source. In other cases (such as RHEL) only source is provided to everyone (but that is fine too). Consider a simpler case: I make a copy of a existing GPL pkg. I modify this and use it myself. I do not have to share my changes with anyone. My copy is still GPL though.. ..so if I give a copy of the source to a friend it no longer matters (to him/her) wether I made that source public before or not. They can modify or not and make available publicly or not. Had I sent my friend a binary copy he/she would have had the right to require me to also hand over the source. None of us would have any obligations to a 3rd party. To back up Peter on this, here are some relevant links from the FSF. https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic Yep, found it myself. I stand corrected. Valeri The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization. But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL. Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you. https://www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA Does the GPL allow me to develop a modified version under a nondisclosure agreement? (#DevelopChangesUnderNDA) Yes. For instance, you can accept a contract to develop changes and agree not to release your changes until the client says ok. This is permitted because in this case no GPL-covered code is being distributed under an NDA. You can also release your changes to the client under the GPL, but agree not to release them to anyone else unless the client says ok. In this case, too, no GPL-covered code is being distributed under an NDA, or under any additional restrictions. The GPL would give the client the right to redistribute your version. In this scenario, the client will probably choose not to exercise that right, but does have the right. There are other questions in the FAQ which also cover this. /Peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos -- Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Kernel Support
On 06/14/18 11:16, Peter Kjellström wrote: On Thu, 14 Jun 2018 10:12:30 -0500 Valeri Galtsev wrote: On 06/14/18 10:00, Peter Kjellström wrote: On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi wrote: ... The src.rpm for that kernel is probably available somewhere. I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it). ... I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else. GPL requires to provide source if everything derived from the original source to everybody, not only to customers. And RedHat was ever compliant with GPL. Kudos to RedHat! So, if there exist patched kernels of out of support life, they should be downloadable somewhere somehow. No you are minunderstanding the GPL. It turns out you are absolutely right. You only have provide modified source to users to whom you distribute derived work. Found it here: https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic I stand corrected. Thanks! Valeri You are only required to provide source to those who got the binary artifact(s). They then have the full GPL rights to further modify etc. In many cases the binaries are distributed to everyone and then so is the source. In other cases (such as RHEL) only source is provided to everyone (but that is fine too). Consider a simpler case: I make a copy of a existing GPL pkg. I modify this and use it myself. I do not have to share my changes with anyone. My copy is still GPL though.. ..so if I give a copy of the source to a friend it no longer matters (to him/her) wether I made that source public before or not. They can modify or not and make available publicly or not. Had I sent my friend a binary copy he/she would have had the right to require me to also hand over the source. None of us would have any obligations to a 3rd party. /Peter -- Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Updated krb5 rpm package altered existing krb5.conf - No go
On Thu, 14 Jun 2018, Richard Grainger wrote: On Wed, Jun 13, 2018 at 6:56 PM G?tz Reinicke wrote: /etc/krb5.conf I looked at the spec file in the source RPM for the krb5-libs package and it it has the correct %config(noreplace) directive next to that file in the %files section, so this is mysterious. I too can confirm this behavior. I do not know why it gets modified but adding the include line breaks self compiled samba DC installations because of the difference in kerberos types used with samba and Red Hat. I suspect that this should be filed as a bug in upstream bugzilla since it does not look like Centos modified the krb5-libs spec file. Presently, to work around the problem, I have ansible fix the file after updates. Regards, -- Tom m...@tdiehl.org ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Kernel Support
On 14 June 2018 at 12:16, Peter Kjellström wrote: > On Thu, 14 Jun 2018 10:12:30 -0500 > Valeri Galtsev wrote: > >> On 06/14/18 10:00, Peter Kjellström wrote: >> > On Thu, 14 Jun 2018 16:26:27 +0200 >> > Gianluca Cecchi wrote: >> > ... >> The src.rpm for that kernel is probably available somewhere. >> >>> >> >>> I'm fairly certain you cannot download the SRPM for EUS kernels. >> >>> You might if you're a Red Hat customer paying for that product >> >>> (but don't take my word for it). >> > ... >> >> I agree for the format of release (SRPM), but in any case Red Hat >> >> should provide the sources for the changes, as the kernel is >> >> GPL-2.0 Then one can manually try to merge them in a patched >> >> kernel in some way... Gianluca >> > >> > Redhat of course complies with the GPL and provide source to the >> > customers that get access to the binary packages. They are not >> > required to provide the sources to anyone else. >> >> GPL requires to provide source if everything derived from the >> original source to everybody, not only to customers. And RedHat was >> ever compliant with GPL. Kudos to RedHat! So, if there exist patched >> kernels of out of support life, they should be downloadable somewhere >> somehow. > > No you are minunderstanding the GPL. > > You are only required to provide source to those who got the binary > artifact(s). They then have the full GPL rights to further modify etc. > In many cases the binaries are distributed to everyone and then so is > the source. In other cases (such as RHEL) only source is provided to > everyone (but that is fine too). > > Consider a simpler case: I make a copy of a existing GPL pkg. I modify > this and use it myself. I do not have to share my changes with anyone. > > My copy is still GPL though.. > > ..so if I give a copy of the source to a friend it no longer matters > (to him/her) wether I made that source public before or not. They can > modify or not and make available publicly or not. > > Had I sent my friend a binary copy he/she would have had the right to > require me to also hand over the source. > > None of us would have any obligations to a 3rd party. > To back up Peter on this, here are some relevant links from the FSF. https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization. But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL. Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you. https://www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA Does the GPL allow me to develop a modified version under a nondisclosure agreement? (#DevelopChangesUnderNDA) Yes. For instance, you can accept a contract to develop changes and agree not to release your changes until the client says ok. This is permitted because in this case no GPL-covered code is being distributed under an NDA. You can also release your changes to the client under the GPL, but agree not to release them to anyone else unless the client says ok. In this case, too, no GPL-covered code is being distributed under an NDA, or under any additional restrictions. The GPL would give the client the right to redistribute your version. In this scenario, the client will probably choose not to exercise that right, but does have the right. There are other questions in the FAQ which also cover this. > /Peter > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos -- Stephen J Smoogen. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Kernel Support
On Thu, 14 Jun 2018 10:12:30 -0500 Valeri Galtsev wrote: > On 06/14/18 10:00, Peter Kjellström wrote: > > On Thu, 14 Jun 2018 16:26:27 +0200 > > Gianluca Cecchi wrote: > > ... > The src.rpm for that kernel is probably available somewhere. > >>> > >>> I'm fairly certain you cannot download the SRPM for EUS kernels. > >>> You might if you're a Red Hat customer paying for that product > >>> (but don't take my word for it). > > ... > >> I agree for the format of release (SRPM), but in any case Red Hat > >> should provide the sources for the changes, as the kernel is > >> GPL-2.0 Then one can manually try to merge them in a patched > >> kernel in some way... Gianluca > > > > Redhat of course complies with the GPL and provide source to the > > customers that get access to the binary packages. They are not > > required to provide the sources to anyone else. > > GPL requires to provide source if everything derived from the > original source to everybody, not only to customers. And RedHat was > ever compliant with GPL. Kudos to RedHat! So, if there exist patched > kernels of out of support life, they should be downloadable somewhere > somehow. No you are minunderstanding the GPL. You are only required to provide source to those who got the binary artifact(s). They then have the full GPL rights to further modify etc. In many cases the binaries are distributed to everyone and then so is the source. In other cases (such as RHEL) only source is provided to everyone (but that is fine too). Consider a simpler case: I make a copy of a existing GPL pkg. I modify this and use it myself. I do not have to share my changes with anyone. My copy is still GPL though.. ..so if I give a copy of the source to a friend it no longer matters (to him/her) wether I made that source public before or not. They can modify or not and make available publicly or not. Had I sent my friend a binary copy he/she would have had the right to require me to also hand over the source. None of us would have any obligations to a 3rd party. /Peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Kernel Support
On 06/14/2018 08:00 AM, Peter Kjellström wrote: On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi wrote: ... The src.rpm for that kernel is probably available somewhere. I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it). ... I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else. /Peter Yes that's why I said somewhere. At least in the past there have been people who made their own mirrors of RHEL exclusive source packages (which the GPL allows). I don't know who does now, but someone somewhere probably does. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS7: Setting up ldap over TLS in kickstart file
On Thu, 14 Jun 2018, Patrick Begou wrote:
Hi,
I'm facing a problem with setting up LDAP+TLS client authentication in a
kickstart script on CentOS7 for several days.
Setting up manualy the config with system-config-authentication works but I
need to automate this in kickstart for deploying cluster nodes.
This show that the server side is running fine.
At this time the message is
#systemctl status sssd
|
sssd[be[default]][2732]: Could not start TLS encryption. error:14090086:SSL
routines:ssl3_get_server_certificate:certificate verify failed (self signed
certificate)|
In my kickstart file I use:
auth --useshadow --enableldaptls --enablecache --passalgo=sha512
--enableldap --enableldapauth --ldapserver="ldaps://my.ldap.server.fr"
--ldapbasedn=dc=my,dc=base,dc=dn
Then in a post install script I download the server and ca certificates and
stops nslcd that I do not use:
echo "TLS_REQCERT allow">>/etc/openldap/ldap.conf
cd /etc/openldap/cacerts/ && wget
http://xxx.xxx.xxx.xxx/Softwares7/LDAPCERTS/ca-bundle.crt && ln -s
ca-bundle.crt $(openssl x509 -hash -in ca-bundle.crt -noout).0
cd /etc/openldap/certs/ && wget
http://xxx.xxx.xxx.xxx/Softwares7/LDAPCERTS/server.crt
cd /
systemctl disable nslcd
I'm unable to see what system-config-authentication is doing more in it's
setup.
Thanks for your help
I'm a bit stumped. My recipe was similar:
authconfig --enableshadow --passalgo=sha512 --enablefingerprint --enableldap
--enableldapauth --ldapserver=ldap.ourcompany.com
--ldapbasedn=dc=ourcompany,dc=com --enablecache --enableldaptls
then, in %post:
curl http://www.ourcompany.com/ca/ca.crt \
-s -o /etc/openldap/cacerts/ca.ourcompany.com.pem
/usr/sbin/cacertdir_rehash /etc/openldap/cacerts
And that did the trick.
The main difference is that you install a bundle of certifcates rather
than a single one. There are two issues:
1. Hashing a certificate bundle does no good as far as I know. Hashes
only work on a single cert, right?
2. Unless told otherwise, openssl looks in only one place for a cert
bundle: ${OPENSSLDIR}/cert.pem (where the value of OPENSSLDIR can
be discovered by running "openssl version -d").
You might take a peek at the ldap_tls_cacertdir discussion in the
sssd-ldap(5) man page, which specifies that certificates should be in
individual files.
My suggestion would be to isolate the CA certificate used to sign your
LDAP server certs, install that as a separate file in
ldap_tls_cacertdir, and run cacertdir_rehash to get the hash correct.
--
Paul Heinlein
heinl...@madboa.com
45°38' N, 122°6' W
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
[CentOS-announce] CEBA-2018:1838 CentOS 7 linux-firmware BugFix Update
CentOS Errata and Bugfix Advisory 2018:1838
Upstream details at : https://access.redhat.com/errata/RHBA-2018:1838
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
940bc02535d7fd581dba6d53f939ed13dbf9a7cb78f23a22db0b94d6dbdbc980
iwl1000-firmware-39.31.5.1-62.2.el7_5.noarch.rpm
722a5873cbe15ee2c12aaac92f04ec012daca4b9d524037d358ebeeeb9e3f65b
iwl100-firmware-39.31.5.1-62.2.el7_5.noarch.rpm
21a7b490b6736e116524cb3c6b676a8428323d6c90dee62694bb9b73cd86e1d9
iwl105-firmware-18.168.6.1-62.2.el7_5.noarch.rpm
0838322f12f12d545404810b33a006f7d9e981e1d9e758de14b7a8aadb143d4d
iwl135-firmware-18.168.6.1-62.2.el7_5.noarch.rpm
d0190f3079c3b729cefdb4fbdbfaea858778cce7d7214d636595657bdd4c43b4
iwl2000-firmware-18.168.6.1-62.2.el7_5.noarch.rpm
c7a7cc8c5195e291ffc2ff8b647e642135f050611379e86c1d9c980439b80c67
iwl2030-firmware-18.168.6.1-62.2.el7_5.noarch.rpm
a7f1d6426f6bd1440610f0b929971737c9fc24039bf88413cb43e21ad4ae1657
iwl3160-firmware-22.0.7.0-62.2.el7_5.noarch.rpm
12d43466da1c3c8055403ddcac8b4efba651ee35393fba897162cf86abcf0e0e
iwl3945-firmware-15.32.2.9-62.2.el7_5.noarch.rpm
6fd48dfeef9416d6fa7636a89be2875c892335d89af6970b62aede43a8dc5e5c
iwl4965-firmware-228.61.2.24-62.2.el7_5.noarch.rpm
5d5ff923fe6beb5904d43a5660b2f65d14a88fb5ae2f865ea10d2e17115a7360
iwl5000-firmware-8.83.5.1_1-62.2.el7_5.noarch.rpm
5ae3fa0eab138bb889e46725795724617047134f1c5c04113e6235c16761ee4c
iwl5150-firmware-8.24.2.2-62.2.el7_5.noarch.rpm
8136f0d62b4419c840f101ca64c93e334ad6aa92e3e3d6fff37620069308f5b1
iwl6000-firmware-9.221.4.1-62.2.el7_5.noarch.rpm
a0f96e3088e72ab8de9846ee75bc6460116b73b77db1bcdacde1a00dd1f7a076
iwl6000g2a-firmware-17.168.5.3-62.2.el7_5.noarch.rpm
5cbe19cd8a9be34c3ece1ea1ded527db0ccd5f8919c8a6b9ce29358b7dedc4ac
iwl6000g2b-firmware-17.168.5.2-62.2.el7_5.noarch.rpm
8d7274ccd14611cb5214163c944b2834330984aa5906b68a49e28a8b82b8f7c1
iwl6050-firmware-41.28.5.1-62.2.el7_5.noarch.rpm
73ad0e98045b5da8a2600789197ec98c58ee605d83c3c24547bd8e498bdc9072
iwl7260-firmware-22.0.7.0-62.2.el7_5.noarch.rpm
03a7febf9a8380d07216ef53dd9d7ef78a684a61acc8006916d515d9cdb23583
iwl7265-firmware-22.0.7.0-62.2.el7_5.noarch.rpm
b3eae0bc8cf3c427455ce5108efe07c3a76b7cdf8a3ad69342720b716b9ce864
linux-firmware-20180220-62.2.git6d51311.el7_5.noarch.rpm
Source:
b23b4d21947a38e5fb5353c3b49ee8d271cd779ad6ecb6509472c5bf345658e8
linux-firmware-20180220-62.2.git6d51311.el7_5.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS
___
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
Re: [CentOS] CentOS Kernel Support
On 06/14/18 10:00, Peter Kjellström wrote: On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi wrote: ... The src.rpm for that kernel is probably available somewhere. I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it). ... I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else. GPL requires to provide source if everything derived from the original source to everybody, not only to customers. And RedHat was ever compliant with GPL. Kudos to RedHat! So, if there exist patched kernels of out of support life, they should be downloadable somewhere somehow. On the other hand, I will not raise any issue about source of these patched ancient kernels, as my sympathy as human is on RedHat's side: I know how much work that is, and programmers who do that have to feed their families. (This is why BSD style license which is different from GPL in this respect does make sense either). Valeri /Peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos -- Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Kernel Support
On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi wrote: ... > > > The src.rpm for that kernel is probably available somewhere. > > > > I'm fairly certain you cannot download the SRPM for EUS kernels. > > You might if you're a Red Hat customer paying for that product (but > > don't take my word for it). ... > I agree for the format of release (SRPM), but in any case Red Hat > should provide the sources for the changes, as the kernel is GPL-2.0 > Then one can manually try to merge them in a patched kernel in some > way... Gianluca Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else. /Peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Kernel Support
On Thu, Jun 14, 2018 at 3:07 PM, Jonathan Billings wrote: > On Wed, Jun 13, 2018 at 11:16:55PM -0700, Alice Wonder wrote: > > > You might be able to pay Red Hat for an Extended Update Support > > > release of RHEL7 that has a similar version > > > (kernel-3.10.0-514.51.1.el7) but support ends November 30 2018. > > > > > > https://access.redhat.com/articles/rhel-eus > > > > > > > The src.rpm for that kernel is probably available somewhere. > > I'm fairly certain you cannot download the SRPM for EUS kernels. You > might if you're a Red Hat customer paying for that product (but don't > take my word for it). > > EUS 7.3.x support is going away soon enough that the real answer is to > plan to migrate to supported RHEL/CentOS kernels. > > I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Kernel Support
On Wed, Jun 13, 2018 at 11:16:55PM -0700, Alice Wonder wrote: > > You might be able to pay Red Hat for an Extended Update Support > > release of RHEL7 that has a similar version > > (kernel-3.10.0-514.51.1.el7) but support ends November 30 2018. > > > > https://access.redhat.com/articles/rhel-eus > > > > The src.rpm for that kernel is probably available somewhere. I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it). EUS 7.3.x support is going away soon enough that the real answer is to plan to migrate to supported RHEL/CentOS kernels. -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Updated krb5 rpm package altered existing krb5.conf - No go
On Wed, Jun 13, 2018 at 6:56 PM Götz Reinicke wrote: > /etc/krb5.conf > I looked at the spec file in the source RPM for the krb5-libs package and it it has the correct %config(noreplace) directive next to that file in the %files section, so this is mysterious. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS7: Setting up ldap over TLS in kickstart file
Hi, I'm facing a problem with setting up LDAP+TLS client authentication in a kickstart script on CentOS7 for several days. Setting up manualy the config with system-config-authentication works but I need to automate this in kickstart for deploying cluster nodes. This show that the server side is running fine. At this time the message is #systemctl status sssd | sssd[be[default]][2732]: Could not start TLS encryption. error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate)| In my kickstart file I use: auth --useshadow --enableldaptls --enablecache --passalgo=sha512 --enableldap --enableldapauth --ldapserver="ldaps://my.ldap.server.fr" --ldapbasedn=dc=my,dc=base,dc=dn Then in a post install script I download the server and ca certificates and stops nslcd that I do not use: echo "TLS_REQCERT allow">>/etc/openldap/ldap.conf cd /etc/openldap/cacerts/ && wget http://xxx.xxx.xxx.xxx/Softwares7/LDAPCERTS/ca-bundle.crt && ln -s ca-bundle.crt $(openssl x509 -hash -in ca-bundle.crt -noout).0 cd /etc/openldap/certs/ && wget http://xxx.xxx.xxx.xxx/Softwares7/LDAPCERTS/server.crt cd / systemctl disable nslcd I'm unable to see what system-config-authentication is doing more in it's setup. Thanks for your help Patrick || -- === | Equipe M.O.S.T. | | | Patrick BEGOU | mailto:patrick.be...@grenoble-inp.fr | | LEGI| | | BP 53 X | Tel 04 76 82 51 35 | | 38041 GRENOBLE CEDEX| Fax 04 76 82 52 71 | === ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Kernel Support
On 06/13/2018 02:33 PM, Jonathan Billings wrote: On Jun 13, 2018, at 4:47 PM, Ken Young wrote: Is anyone on the mailing list aware of anyone who supports older versions of CentOS kernels? Particularly, I am interested in getting security patches added to kernel-3.10.0-514.10.2.el7.src.rpm. Please let me know. As far as CentOS support, only the latest kernel is supported. This really means that *you* are now the only support for old kernels. You might be able to pay Red Hat for an Extended Update Support release of RHEL7 that has a similar version (kernel-3.10.0-514.51.1.el7) but support ends November 30 2018. https://access.redhat.com/articles/rhel-eus The src.rpm for that kernel is probably available somewhere. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
