Re: [CentOS] yum/RPM and Trust on First Use

[Always Learning]

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] Serial Communication

[John R Pierce]

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] LDAP create home directories

[Bill Howe]

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] yum/RPM and Trust on First Use

[Alice Wonder]

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

Re: [CentOS] LDAP create home directories

[Bill Howe]

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

Re: [CentOS] LDAP create home directories

[Tim Dunphy]

>
> 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.
> > > >
> 

[CentOS] LDAP create home directories

[Tim Dunphy]

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] LDAP create home directories

[Tim Dunphy]

>
> 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] yum/RPM and Trust on First Use

[Alice Wonder]

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] playing DVDs on C7

[Fred Smith]

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] fail2ban problem new installation

[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

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

Re: [CentOS-virt] kvm-qemu-ev in testing

[Gena Makhomed]

On 30.11.2015 19:02, Jean-Marc LIGER wrote:


Is it possible to add patch
https://bugzilla.redhat.com/show_bug.cgi?id=1248758
into qemu-kvm-ev from Red Hat, oVirt and cbs/centos ?



Could you rediff this patch for qemu-kvm-ev 2.3.0 series ?


I am already wasting too many time for this patch...

--
Best regards,
 Gena
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS] CentOS-announce Digest, Vol 130, Issue 8

[centos-announce-request]

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 :

[CentOS] Serial Communication

[Chris Olson]

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

Re: [CentOS] fail2ban problem new installation CentOS 1511

[Günther J . Niederwimmer]

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

[Gordon Messmer]

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

[CentOS] fail2ban problem new installation

[Günther J . Niederwimmer]

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