Re: [CentOS] playing DVDs on C7
On Fri, Dec 18, 2015 at 12:29:05PM -0500, Fred Smith wrote: > On Fri, Dec 18, 2015 at 09:32:53AM -0500, Lamar Owen wrote: > > On 12/17/2015 08:33 PM, Fred Smith wrote: > > >Hi all! > > > > > >I'm trying to finish setting up my newly upgraded C7 system. > > > > > >It's on the same hardware I ran C6 on for several years. on C6 I had no > > >trouble playing DVDs (after installing tons of packages and libdvdcss). > > > > > I have found that whether VLC will play a DVD is somewhat dependent > > on the DVD. I have played DVD's through VLC successfully on my > > CentOS 7 system using the nux package stack, incidentally, but there > > are several DVD's in my collection that will not play with the VLC > > in nux dextop. But I also purchased (the very first version a > > number of years ago) and keep support updated for the Fluendo > > OnePlay DVD player (fully legal, licensed, DVD playback) and it both > > works perfectly on CentOS 7 and plays those titles that VLC has > > trouble with (like the DVD copy included in the Bluray edition of > > Titanic). > > I don't play a LOT of DVDs, but on, e.g., C6 on the same hardware > I don't recall ever having onefail to play with VLC. > > In looking at the source package for libdvdcss, last night, I see there > are 3 different ways of cracking the encryption that it supports. The > default one is to try to crack each file's encryption, with the down-side > that it may fail entirely. there is also an option to crack the DISC's > key which can then be used to decrypt each file. from the description > it sounds as if the disc option might be better even though it isn't > the default. > > If all else fails I will try hacking around with that option. OK, I haven't gotten very far, but there is one interesting observation: vlc plays my homemade NON-encrypted DVDs just fine (except for the DVD menus, on which for some reason it errors). This kinda hints that VLC is not finding/opening libdvdcss even though I'm using the one from the nux repos, same as the source of the VLC RPM I have. One would think that nux's VLC would work with nux's libdvdcss, but this evidence makes me wonder... If nux is here, or if anyone here uses nux's vlc and libdvdcss with SUCCESS, I'd appreciate hearing from them. Fred PS: I'm not having any luck compiling libdvdcss from source... using rpmbuild to create a RPM I keep getting errors about "unpackaged files found", and can't figure out why or how to solve it (yes I've googled for solutions). -- Fred Smith -- fre...@fcshome.stoneham.ma.us - "For the word of God is living and active. Sharper than any double-edged sword, it penetrates even to dividing soul and spirit, joints and marrow; it judges the thoughts and attitudes of the heart." Hebrews 4:12 (niv) -- ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum/RPM and Trust on First Use
On 12/19/2015 10:27 AM, Always Learning wrote: On Sat, 2015-12-19 at 09:49 -0800, Alice Wonder wrote: DNS verification solves that issue. How reliably safe is that ? Crack the DNS access and inflict viruses, trojans etc. with authorised impunity ? Happy Christmas. No, if you manage to crack the DNS you can not do anything but a DOS attack unless you also managed the get the DNSSEC signing key, which does not need (and should not be) to be on the DNS server. Manage to get the signing key, and the only consequence is the attacker can make fraudulent DNS entries that would validate - same as with GPG or any other private / public key cryptographic signatures. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LDAP create home directories
>
> Check /var/log/secure for why the directory is not able to be created.
> Might be selinux, is that enabled? (sestatus)
Good catch! It was indeed SELinux preventing the directory from being
created. Disabling it allows that to happen. For instance I just created a
new test user in LDAP:
#ssh odun...@ops2.example.com
odun...@ops2.example.com's password:
Creating directory '/home/odunphy'.
_ ____
| | ___| / _ \ _ __ ___|___ \
_ | | |_| | | | '_ \/ __| __) |
| |_| | _| | |_| | |_) \__ \/ __/
\___/|_| \___/| .__/|___/_|
|_|
[odunphy@ops2 ~]$
And it works fine! :) Turns out the host that had directory creation
working properly before had SELinux disabled.
When I look at the audit log this is what I found:
type=AVC msg=audit(1450562436.438:2148162): avc: denied { entrypoint }
for pid=17881 comm="sshd" path="/usr/sbin/mkhomedir_helper" dev="vda1"
ino=1048040 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:object_r:oddjob_mkhomedir_exec_t:s0 tclass=file
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to
allow this access.
So I just created the selinux module file and installed it:
[root@ops2:~] #grep ssh /var/log/audit/audit.log | audit2allow -M ssh-mkdir
IMPORTANT ***
To make this policy package active, execute:
semodule -i ssh-mkdir.pp
[root@ops2:~] #semodule -i ssh-mkdir.pp
And all is well with the world. Directories are created on login with LDAP
now.
#ssh odun...@ops2.example.com
odun...@ops2.example.com's password:
Creating directory '/home/odunphy'.
Last login: Sat Dec 19 17:00:36 2015 from ool-4571a4a2.dyn.optonline.net
_ ____
| | ___| / _ \ _ __ ___|___ \
_ | | |_| | | | '_ \/ __| __) |
| |_| | _| | |_| | |_) \__ \/ __/
\___/|_| \___/| .__/|___/_|
|_|
[odunphy@ops2 ~]$
Thanks for your help!
Tim
On Sat, Dec 19, 2015 at 4:49 PM, Bill Howe wrote:
> Check /var/log/secure for why the directory is not able to be created.
>
> Might be selinux, is that enabled? (sestatus)
> On Dec 19, 2015 15:40, "Tim Dunphy" wrote:
>
> > >
> > > You may also need to restart sssd or nslcd, depending upon which one is
> > > running the backed ldap connection service on the clients.
> >
> >
> > Hmm.. I got a different result after restarting nclcd. Instead of logging
> > me in and just complaining that it couldn't create the home directory, it
> > still complains about not creating the home directory, but now it doesn't
> > let me in:
> >
> > #ssh tdun...@ops2.example.com
> >
> > tdun...@ops2.example.com's password:
> >
> > Creating directory '/home/tdunphy'.
> >
> > Unable to create and initialize directory '/home/tdunphy'.
> >
> > Last login: Sat Dec 19 15:29:54 2015
> >
> >
> > _ ____
> >
> > | | ___| / _ \ _ __ ___|___ \
> >
> > _ | | |_| | | | '_ \/ __| __) |
> >
> > | |_| | _| | |_| | |_) \__ \/ __/
> >
> > \___/|_| \___/| .__/|___/_|
> >
> > |_|
> > Connection to ops2.example.com closed.
> >
> > I think I preferred it when it would let me in and complain!! LOL
> >
> > I can still get in with my non-LDAP admin account fortunately.
> >
> > Ok, any other thoughts?
> >
> > Thanks,
> > Tim
> >
> > On Sat, Dec 19, 2015 at 4:34 PM, Bill Howe wrote:
> >
> > > You may also need to restart sssd or nslcd, depending upon which one is
> > > running the backed ldap connection service on the clients.
> > > On Dec 19, 2015 14:25, "Tim Dunphy" wrote:
> > >
> > > > Hey guys,
> > > >
> > > > I've setup an LDAP server on our network. I'm using OpenLDAP.
> > > >
> > > > It was really easy to use the authconfig-tui to generate the
> > > nsswitch.conf
> > > > and ldap.conf files that would allow user authentication.
> > > >
> > > > But when users would log in, the system wasn't creating the home
> > > > directories.
> > > >
> > > > I found one command that would correct that:
> > > >
> > > > authconfig --enablemkhomedir --update
> > > >
> > > > After that logging in with an LDAP user to that machine would create
> > the
> > > > home directories.
> > > >
> > > > But that only worked on the first machine. Running the command on
> other
> > > > machines would have no effect. Which is odd. You would think it would
> > be
> > > > consistent.
> > > >
> > > > Even after copying over the entire contents of /etc/pam.d from the
> > > working
> > > > machine to the non-working machine and making sure that the
> non-working
> > > > machine had the same /etc/nsswitch.conf /etc/openldap/ldap.conf as
> the
> > > one
> > > > that worked. It still doesn't create the home directories when LDAP
> > users
> > > > log in.
> > > >
> > > > The non-working machine also has the required librariy file:
> > > >
> > > > -rw
Re: [CentOS] LDAP create home directories
Check /var/log/secure for why the directory is not able to be created. Might be selinux, is that enabled? (sestatus) On Dec 19, 2015 15:40, "Tim Dunphy" wrote: > > > > You may also need to restart sssd or nslcd, depending upon which one is > > running the backed ldap connection service on the clients. > > > Hmm.. I got a different result after restarting nclcd. Instead of logging > me in and just complaining that it couldn't create the home directory, it > still complains about not creating the home directory, but now it doesn't > let me in: > > #ssh tdun...@ops2.example.com > > tdun...@ops2.example.com's password: > > Creating directory '/home/tdunphy'. > > Unable to create and initialize directory '/home/tdunphy'. > > Last login: Sat Dec 19 15:29:54 2015 > > > _ ____ > > | | ___| / _ \ _ __ ___|___ \ > > _ | | |_| | | | '_ \/ __| __) | > > | |_| | _| | |_| | |_) \__ \/ __/ > > \___/|_| \___/| .__/|___/_| > > |_| > Connection to ops2.example.com closed. > > I think I preferred it when it would let me in and complain!! LOL > > I can still get in with my non-LDAP admin account fortunately. > > Ok, any other thoughts? > > Thanks, > Tim > > On Sat, Dec 19, 2015 at 4:34 PM, Bill Howe wrote: > > > You may also need to restart sssd or nslcd, depending upon which one is > > running the backed ldap connection service on the clients. > > On Dec 19, 2015 14:25, "Tim Dunphy" wrote: > > > > > Hey guys, > > > > > > I've setup an LDAP server on our network. I'm using OpenLDAP. > > > > > > It was really easy to use the authconfig-tui to generate the > > nsswitch.conf > > > and ldap.conf files that would allow user authentication. > > > > > > But when users would log in, the system wasn't creating the home > > > directories. > > > > > > I found one command that would correct that: > > > > > > authconfig --enablemkhomedir --update > > > > > > After that logging in with an LDAP user to that machine would create > the > > > home directories. > > > > > > But that only worked on the first machine. Running the command on other > > > machines would have no effect. Which is odd. You would think it would > be > > > consistent. > > > > > > Even after copying over the entire contents of /etc/pam.d from the > > working > > > machine to the non-working machine and making sure that the non-working > > > machine had the same /etc/nsswitch.conf /etc/openldap/ldap.conf as the > > one > > > that worked. It still doesn't create the home directories when LDAP > users > > > log in. > > > > > > The non-working machine also has the required librariy file: > > > > > > -rwxr-xr-x. 1 root root 11176 Aug 18 10:56 > > > /usr/lib64/security/pam_mkhomedir.so > > > > > > So how can I fix this? How can I get the system to create home > > directories > > > for LDAP users automatically? > > > > > > Thanks, > > > Tim > > > > > > > > > > > > -- > > > GPG me!! > > > > > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > > ___ > > > CentOS mailing list > > > CentOS@centos.org > > > https://lists.centos.org/mailman/listinfo/centos > > > > > ___ > > CentOS mailing list > > CentOS@centos.org > > https://lists.centos.org/mailman/listinfo/centos > > > > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LDAP create home directories
> > You may also need to restart sssd or nslcd, depending upon which one is > running the backed ldap connection service on the clients. Hmm.. I got a different result after restarting nclcd. Instead of logging me in and just complaining that it couldn't create the home directory, it still complains about not creating the home directory, but now it doesn't let me in: #ssh tdun...@ops2.example.com tdun...@ops2.example.com's password: Creating directory '/home/tdunphy'. Unable to create and initialize directory '/home/tdunphy'. Last login: Sat Dec 19 15:29:54 2015 _ ____ | | ___| / _ \ _ __ ___|___ \ _ | | |_| | | | '_ \/ __| __) | | |_| | _| | |_| | |_) \__ \/ __/ \___/|_| \___/| .__/|___/_| |_| Connection to ops2.example.com closed. I think I preferred it when it would let me in and complain!! LOL I can still get in with my non-LDAP admin account fortunately. Ok, any other thoughts? Thanks, Tim On Sat, Dec 19, 2015 at 4:34 PM, Bill Howe wrote: > You may also need to restart sssd or nslcd, depending upon which one is > running the backed ldap connection service on the clients. > On Dec 19, 2015 14:25, "Tim Dunphy" wrote: > > > Hey guys, > > > > I've setup an LDAP server on our network. I'm using OpenLDAP. > > > > It was really easy to use the authconfig-tui to generate the > nsswitch.conf > > and ldap.conf files that would allow user authentication. > > > > But when users would log in, the system wasn't creating the home > > directories. > > > > I found one command that would correct that: > > > > authconfig --enablemkhomedir --update > > > > After that logging in with an LDAP user to that machine would create the > > home directories. > > > > But that only worked on the first machine. Running the command on other > > machines would have no effect. Which is odd. You would think it would be > > consistent. > > > > Even after copying over the entire contents of /etc/pam.d from the > working > > machine to the non-working machine and making sure that the non-working > > machine had the same /etc/nsswitch.conf /etc/openldap/ldap.conf as the > one > > that worked. It still doesn't create the home directories when LDAP users > > log in. > > > > The non-working machine also has the required librariy file: > > > > -rwxr-xr-x. 1 root root 11176 Aug 18 10:56 > > /usr/lib64/security/pam_mkhomedir.so > > > > So how can I fix this? How can I get the system to create home > directories > > for LDAP users automatically? > > > > Thanks, > > Tim > > > > > > > > -- > > GPG me!! > > > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > ___ > > CentOS mailing list > > CentOS@centos.org > > https://lists.centos.org/mailman/listinfo/centos > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] LDAP create home directories
You may also need to restart sssd or nslcd, depending upon which one is running the backed ldap connection service on the clients. On Dec 19, 2015 14:25, "Tim Dunphy" wrote: > Hey guys, > > I've setup an LDAP server on our network. I'm using OpenLDAP. > > It was really easy to use the authconfig-tui to generate the nsswitch.conf > and ldap.conf files that would allow user authentication. > > But when users would log in, the system wasn't creating the home > directories. > > I found one command that would correct that: > > authconfig --enablemkhomedir --update > > After that logging in with an LDAP user to that machine would create the > home directories. > > But that only worked on the first machine. Running the command on other > machines would have no effect. Which is odd. You would think it would be > consistent. > > Even after copying over the entire contents of /etc/pam.d from the working > machine to the non-working machine and making sure that the non-working > machine had the same /etc/nsswitch.conf /etc/openldap/ldap.conf as the one > that worked. It still doesn't create the home directories when LDAP users > log in. > > The non-working machine also has the required librariy file: > > -rwxr-xr-x. 1 root root 11176 Aug 18 10:56 > /usr/lib64/security/pam_mkhomedir.so > > So how can I fix this? How can I get the system to create home directories > for LDAP users automatically? > > Thanks, > Tim > > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] LDAP create home directories
Hey guys, I've setup an LDAP server on our network. I'm using OpenLDAP. It was really easy to use the authconfig-tui to generate the nsswitch.conf and ldap.conf files that would allow user authentication. But when users would log in, the system wasn't creating the home directories. I found one command that would correct that: authconfig --enablemkhomedir --update After that logging in with an LDAP user to that machine would create the home directories. But that only worked on the first machine. Running the command on other machines would have no effect. Which is odd. You would think it would be consistent. Even after copying over the entire contents of /etc/pam.d from the working machine to the non-working machine and making sure that the non-working machine had the same /etc/nsswitch.conf /etc/openldap/ldap.conf as the one that worked. It still doesn't create the home directories when LDAP users log in. The non-working machine also has the required librariy file: -rwxr-xr-x. 1 root root 11176 Aug 18 10:56 /usr/lib64/security/pam_mkhomedir.so So how can I fix this? How can I get the system to create home directories for LDAP users automatically? Thanks, Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Serial Communication
On 12/19/2015 4:24 AM, Chris Olson wrote: Is there some fundamental difference between these methods of output to the driver that might trip us up as we simplify the scripts and port to new computer platforms? assuming 'serial' means RS232 asynch, the biggest tripup is that new computers don't COME with any serial ports, they are considered 'legacy', so you end up having to use USB Serial port adapters, many of which are nearly junk.stick with the FTDI based USB-Serial adapters from reliable companies for the best results. If this is RS422 or some other sort of high speed serial, that requires special adapters, well, the biggest problem will be that new computers are almost entirely PCI-Express, both ISA and original parallel PCI are history, so you may need to find and qualify new adapter boards. as far as how to best write your programs and scripts, well, thats up to whatever techniques your development engineers are most comfortable with. Me, I'd probably be doing something like that in Perl or maybe Python (even tho that would require me to learn more python). -- john r pierce, recycling bits in santa cruz ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum/RPM and Trust on First Use
On Sat, 2015-12-19 at 09:49 -0800, Alice Wonder wrote: > DNS verification solves that issue. How reliably safe is that ? Crack the DNS access and inflict viruses, trojans etc. with authorised impunity ? Happy Christmas. -- Regards, Paul. England, EU. England's place is in the European Union. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum/RPM and Trust on First Use
On 12/19/2015 02:12 AM, Gordon Messmer wrote: On 12/15/2015 07:05 PM, Alice Wonder wrote: 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. While that is true, it is important to note that yum will only import keys that are already installed on disk, in /etc/pki/rpm-gpg. Which means that only keys that were *previously* installed from a trusted source can be added to the trust database. Initially, that set comes from your install media. Assuming that you verified the sum of the media you used for installation, this is a reasonably secure mechanism. With third party repositories the key and configuration file is often distributed separately. That's the potential attack vector for trojan keys. If you're going to verify the key against a DNS record for every package you install, forever, why have a GPG keyring at all? Well I'm not a big fan of GPG keyrings to be honest, it is a difficult system for users and contains abandoned keys and compromised keys that aren't revoked because the owner can't revoke them if they lost their private key. DNS verification solves that issue. -- -=- Sent my from my laptop, may not be able to respond timely ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Serial Communication
Many years ago, we began scrapping the RTOS approach for some of our timing-critical applications. Our first applications were based on Solaris real-time extensions and served well us well for many years. Then came the era of shaky support for Intel Solaris and we moved many applications to Linux. There appeared to be no actual need for special real-time features with a good Linux distribution kernel and a GHz processors. One of our most productive applications involves special test equipment computers that drive high speed serial ports. The original development of these systems had the "added benefit" of helping us to learn udev rules. The serial communication is very flexible and most of it is script driven. A current need to update computing platforms is driving script review. There appears to be a bit of variety in outputs to the serial drivers. The echo of a string with redirection to the serial driver, cat of a file with redirection to the serial driver and dd of=/dev/ are methods used at various places in the scripts. It is not at all clear what drove the choice of the output method at various points in the application. In addition, changing the method of output has not succeeded in breaking most of the applications. Is there some fundamental difference between these methods of output to the driver that might trip us up as we simplify the scripts and port to new computer platforms? Thanks in advance for any assistance. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 130, Issue 8
Send CentOS-announce mailing list submissions to centos-annou...@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-requ...@centos.org You can reach the person managing the list at centos-announce-ow...@centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. Release for CentOS AltArch 7 (1511) on x86_64 (Karanbir Singh) -- Message: 1 Date: Sat, 19 Dec 2015 00:47:23 + From: Karanbir Singh To: CentOS Announcements List Subject: [CentOS-announce] Release for CentOS AltArch 7 (1511) on x86_64 Message-ID: <5674a91b.40...@centos.org> Content-Type: text/plain; charset=utf-8 I would like to announce the general availability of the following CentOS AltArch 7 Releases: * CentOS AltArch 7 (1511) for i686 * CentOS AltArch UserLand 7 (1511) for Armhfp * CentOS AltArch 7 (1511) for PowerPC64 (TechPreview) * CentOS AltArch 7 (1511) for PowerPC8 LE (TechPreview) We anticipate CentOS AltArch 7 (1511) for Aarch64 will be ready for release within the coming days, and will be announced independently. The CentOS AltArch SIG is a group of people working to build alternative architecture support derived from CentOS Linux's sources. You can find more details about the AltArch group at https://wiki.centos.org/SpecialInterestGroup/AltArch including details on how to get involved and ways to get help for architecture specific issues. Releases under the AltArch SIG are hosted at http://mirror.centos.org/altarch/ and available from external mirrors via rsync, http, ftp as usual, however under the /altarch/ path. Yum configs shipped in the altarch builds points at mirror.centos.org instead of mirrorlist or the external mirrors, as we are still working through the mechanics to facilitate the wider mirrorlist process. We hope to have this in place within the next 2 months, and updates to the yum configs will be issued, when ready, via an updated centos-release rpm. We are hosting a CentOS Dojo in Brussels, Belgium on the 29th Jan 2016. Lots of the key people working on the AltArch builds will be present there and it would be a great forum to engage with these groups. You can get the details for the event at https://wiki.centos.org/Events/Dojo/Brussels2016 including the registration links. In order to bootstrap these builds, we have turned on direct downloads of this content from mirror.centos.org. We do encourage people with the capacity to help seed with external mirrors. Details on howto run a CentOS Mirror are available at https://wiki.centos.org/HowTos/CreatePublicMirrors A key part of our AltArch plans is to make resources available to all the other SIG's in the CentOS environment, so they are able to build, test, deliver their content for these architectures. We are working on setting things up, and hope to start rolling out altarch support for https://cbs.centos.org/ in the first quarter of 2016. If you are engaged in any of the SIGs and would like to find out more details, please come along to our buildsystems meeting that takes place on Mondays in #centos-devel on irc.freenode.net. Details on this meeting and the other SIG meetings can be found in our community meetings calendar published at https://www.centos.org/community/calendar/ . Bug reports and feedback about specific packages should be filed at https://bugs.centos.org/ against the relevant package name, for project CentOS Linux 7, in the same manner as you would for x86_64. However, do mention the architecture as applicable. CentOS AltArch 7 (1511) for i686 : This architecture build supports 32-bit Intel/AMD x86 machines and 32 bit IOT x86 boards. SIG Notes: https://wiki.centos.org/SpecialInterestGroup/AltArch/i386 * CentOS-7-i386-DVD-1511.iso sha256sum : 6af64d8371ed8fb95a56c99530f0dc3eb287e58f72c009c686db0fb80c39f83f direct link : http://mirror.centos.org/altarch/7/isos/i386/CentOS-7-i386-DVD-1511.iso * CentOS-7-i386-Everything-1511.iso sha256sum : 918e0ade9f642c93531c414defeecfc9b2c2a9589d57642d690e46e42b0af82a direct link : http://mirror.centos.org/altarch/7/isos/i386/CentOS-7-i386-Everything-1511.iso * CentOS-7-i386-LiveGNOME-1511.iso sha256sum : a03af3c7f6c75c74e1da5d1551ceaf5922427762c5cd6503f4f5e972737134ed direct link : http://mirror.centos.org/altarch/7/isos/i386/CentOS-7-i386-LiveGNOME-1511.iso * CentOS-7-i386-LiveKDE-1511.iso sha256sum : 9fdef81423b872c361bac3ac55718822b4420de1645a4da8d7a255ae500965fc direct link : http://mirror.centos.org/altarch/7/isos/i386/CentOS-7-i386-LiveKDE-1511.iso * CentOS-7-i386-Minimal-1511.iso sha256sum : df6edebec370bdee59e67eb70fab7ddc2fcf4c437803ca9e3213552b3908c4e1 direct link : http://mirror.centos.org/al
Re: [CentOS] fail2ban problem new installation CentOS 1511
Hello, Am Saturday 19 December 2015, 09:37:14 schrieb Tony Mountifield: > In article <1612557.81lQ3GSSy2@techz>, > > Günther J. Niederwimmer wrote: > > 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 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, > > Do you have the ipset RPM installed? rpm -q ipset Yes this is installed :-(, I look it before I wrote ;-). > Cheers > Tony -- mit freundlichen Grüßen / best regards, Günther J. Niederwimmer ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum/RPM and Trust on First Use
On 12/15/2015 07:05 PM, Alice Wonder wrote: 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. While that is true, it is important to note that yum will only import keys that are already installed on disk, in /etc/pki/rpm-gpg. Which means that only keys that were *previously* installed from a trusted source can be added to the trust database. Initially, that set comes from your install media. Assuming that you verified the sum of the media you used for installation, this is a reasonably secure mechanism. This is potentially exploitable because most repositories are http http repositories don't impact the security of this mechanism in any way. If you're worried about the package verification process, the big risk that exists in the current implementation (assuming that you trust your install media) is that users are allowed to install repositories that are configured with both gpgcheck=0 AND an http:// URL. That combination could lead to a compromise through a MITM attack, but only if a third-party repository is added, and that repo doesn't provide any security at all. The DNS 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. ... When yum is first asked to import a key, it refuses if it can not DNSSEC validate the fingerprint. And what should it do at sites where there's no DNSSEC validation available? Are they unable to install packages? Should it fall back to its current behavior? I think that's an important question, because if you're trying to improve security in the face of a MITM attack, you have to be able to demonstrate that security is actually better *during an attack*. If a MITM can simply cause the client to fall back to its current behavior in order to launch a hypothetical attack, your solution isn't suitable. 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. If you're going to verify the key against a DNS record for every package you install, forever, why have a GPG keyring at all? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] fail2ban problem new installation
In article <1612557.81lQ3GSSy2@techz>, Günther J. Niederwimmer wrote: > 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 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, Do you have the ipset RPM installed? rpm -q ipset Cheers Tony -- Tony Mountifield Work: t...@softins.co.uk - http://www.softins.co.uk Play: t...@mountifield.org - http://tony.mountifield.org ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] fail2ban problem new installation
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 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 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
