Re: [CentOS] iptables question

2014-06-16 Thread John R Pierce
On 6/16/2014 8:52 PM, Chuck Campbell wrote:
> I ran a script after fail2ban was started. It looks like this:
> #!/bin/sh
> iptables -A INPUT -s 116.10.191.0/24 -j DROP
> iptables -A INPUT -s 183.136.220.0/24 -j DROP
> iptables -A INPUT -s 183.136.221.0/24 -j DROP
> iptables -A INPUT -s 183.136.222.0/24 -j DROP
> iptables -A INPUT -s 183.136.223.0/24 -j DROP
> iptables -A INPUT -s 122.224.11.0/24 -j DROP
> iptables -A INPUT -s 219.138.0.0/16 -j DROP
>
> so, how do I get them in front of the RH-Firewall-1-INPUT, or do I add them to
> that chain?

use -I (insert) rather than -A (append).

OR

specify chain RH-Firewall-1-INPUT rather than INPUT

OR, better

use system-config-firewall rather than running your own iptables 
commands.this manages the rules used by the RH firewall scripts 
invoked by the iptables service which is run at boot time.

also, if you do manually add iptables rules, you can use `service 
iptables save` to remember these changes, instead of running them from 
your own scripts.  these changes get saved to /etc/sysconfig/iptables






-- 
john r pierce  37N 122W
somewhere on the middle of the left coast

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] iptables question

2014-06-16 Thread Chuck Campbell

>>>
>>>
>> As John R Pierce mentioned one of your first rule in the chain is
>> "RH-Firewall-1-INPUT  all  --  anywhere anywhere", this
>> simply mean everything with "DROP" after it will be ignored. iptables
>> will work its way down the chain, therefore you have to options
>> 1. remove that line or
>> 2. move it at the bottom of the chain.
>
> I am clearly missing some emails, because I didn't see a reply from John R 
> Pierce. My apologies.
> I appreciate you restating this. I'll try to go make sense of iptables, given 
> the insight,
>
> thanks,
> -chuck
>

OK, I went to the list archive and found the email in question. Also, one after 
it that asked how I added these rules.

I ran a script after fail2ban was started. It looks like this:
#!/bin/sh
iptables -A INPUT -s 116.10.191.0/24 -j DROP
iptables -A INPUT -s 183.136.220.0/24 -j DROP
iptables -A INPUT -s 183.136.221.0/24 -j DROP
iptables -A INPUT -s 183.136.222.0/24 -j DROP
iptables -A INPUT -s 183.136.223.0/24 -j DROP
iptables -A INPUT -s 122.224.11.0/24 -j DROP
iptables -A INPUT -s 219.138.0.0/16 -j DROP

so, how do I get them in front of the RH-Firewall-1-INPUT, or do I add them to 
that chain?

-chuck



-- 
ACCEL Services, Inc.| Specialists in Gravity, Magnetics |  (713)993-0671 ph.
 |   and Integrated Interpretation   |  (713)993-0608 fax
448 W. 19th St. #325|Since 1992 |  (713)306-5794 cell
  Houston, TX, 77008 |  Chuck Campbell   | campb...@accelinc.com
 |  President & Senior Geoscientist  |

  "Integration means more than having all the maps at the same scale!"

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] iptables question

2014-06-16 Thread Chuck Campbell
On 6/16/2014 9:44 PM, Earl Ramirez wrote:
> On Mon, 2014-06-16 at 21:42 -0500, Chuck Campbell wrote:
>> All of the suggestions are graciously accepted, however, I was actually 
>> asking
>> what I was doing wrong with iptables, and why, with the rules I put in place,
>> someone was still able to connect to my machine.
>>
>> I understand there might be better ways, but if I don't understand what I did
>> wrong last time, how am I going to figure out how to deny all, then allow
>> selected, ehrn I can't seem to allow all and deny selected.
>>
>> There must be a misunderstanding on my part about how iptables are supposed 
>> to work.
>>
>> -chuck
>>
>>
> As John R Pierce mentioned one of your first rule in the chain is
> "RH-Firewall-1-INPUT  all  --  anywhere anywhere", this
> simply mean everything with "DROP" after it will be ignored. iptables
> will work its way down the chain, therefore you have to options
> 1. remove that line or
> 2. move it at the bottom of the chain.

I am clearly missing some emails, because I didn't see a reply from John R 
Pierce. My apologies.
I appreciate you restating this. I'll try to go make sense of iptables, given 
the insight,

thanks,
-chuck

-- 
ACCEL Services, Inc.| Specialists in Gravity, Magnetics |  (713)993-0671 ph.
 |   and Integrated Interpretation   |  (713)993-0608 fax
448 W. 19th St. #325|Since 1992 |  (713)306-5794 cell
  Houston, TX, 77008 |  Chuck Campbell   | campb...@accelinc.com
 |  President & Senior Geoscientist  |

  "Integration means more than having all the maps at the same scale!"

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] iptables question

2014-06-16 Thread Earl Ramirez
On Mon, 2014-06-16 at 21:42 -0500, Chuck Campbell wrote:
> All of the suggestions are graciously accepted, however, I was actually 
> asking 
> what I was doing wrong with iptables, and why, with the rules I put in place, 
> someone was still able to connect to my machine.
> 
> I understand there might be better ways, but if I don't understand what I did 
> wrong last time, how am I going to figure out how to deny all, then allow 
> selected, ehrn I can't seem to allow all and deny selected.
> 
> There must be a misunderstanding on my part about how iptables are supposed 
> to work.
> 
> -chuck
> 
> 

As John R Pierce mentioned one of your first rule in the chain is 
"RH-Firewall-1-INPUT  all  --  anywhere anywhere", this
simply mean everything with "DROP" after it will be ignored. iptables
will work its way down the chain, therefore you have to options
1. remove that line or 
2. move it at the bottom of the chain.


-- 


Kind Regards
Earl Ramirez
GPG Key: http://trinipino.com/PublicKey.asc


signature.asc
Description: This is a digitally signed message part
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] iptables question

2014-06-16 Thread Chuck Campbell
All of the suggestions are graciously accepted, however, I was actually asking 
what I was doing wrong with iptables, and why, with the rules I put in place, 
someone was still able to connect to my machine.

I understand there might be better ways, but if I don't understand what I did 
wrong last time, how am I going to figure out how to deny all, then allow 
selected, ehrn I can't seem to allow all and deny selected.

There must be a misunderstanding on my part about how iptables are supposed to 
work.

-chuck


-- 
ACCEL Services, Inc.| Specialists in Gravity, Magnetics |  (713)993-0671 ph.
 |   and Integrated Interpretation   |  (713)993-0608 fax
448 W. 19th St. #325|Since 1992 |  (713)306-5794 cell
  Houston, TX, 77008 |  Chuck Campbell   | campb...@accelinc.com
 |  President & Senior Geoscientist  |

  "Integration means more than having all the maps at the same scale!"

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] iptables question

2014-06-16 Thread Keith Keller
[previous article hasn't appeared on gmane yet]

On 2014-06-16, Eliezer Croitoru  wrote:
> On 06/17/2014 01:46 AM, Bret Taylor wrote:
>> Get rid of fail2ban, it's not needed. Just write a proper firewall.
> Are you series??
> There are applications that fail2ban offers them things which others 
> just can't..

Indeed, fail2ban and their ilk (e.g. my new favorite, sshguard) modify
iptables rules in response to excessive failed login attempts.  A
''proper firewall'' with just static iptables rules can't do that.
And with so many pwn3d hosts out there being used to bounce attacks off
of, it is foolish to rely on static rules alone to fend off these
attacks.

Much better of course are static firewall rules that blocks off all but
a few whitelisted hosts.  But that is much less flexible for users.

--keith



-- 
kkel...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] iptables question

2014-06-16 Thread Eliezer Croitoru
On 06/17/2014 01:46 AM, Bret Taylor wrote:
> Get rid of fail2ban, it's not needed. Just write a proper firewall.
Are you series??
There are applications that fail2ban offers them things which others 
just can't..

If you can email me the ip for your servers and also the root password 
and allow me in your INPUT all over the place I will leave you a message 
in the server.(hope you understand jokes)

All The Bests,
Eliezer
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] iptables question

2014-06-16 Thread Eliezer Croitoru
On 06/17/2014 01:11 AM, John R Pierce wrote:
> On 6/16/2014 2:58 PM, Chuck Campbell wrote:
>> >Chain INPUT (policy ACCEPT)
>> >target prot opt source   destination
>> >fail2ban-VSFTPD  tcp  --  anywhere anywheretcp 
>> >dpt:ftp
>> >fail2ban-SSH  tcp  --  anywhere anywheretcp dpt:ssh
>> >RH-Firewall-1-INPUT  all  --  anywhere anywhere
>> >DROP   all  --  116.10.191.0/24  anywhere
>> >DROP   all  --  183.136.220.0/24 anywhere
>> >DROP   all  --  183.136.221.0/24 anywhere
>> >DROP   all  --  183.136.222.0/24 anywhere
>> >DROP   all  --  183.136.223.0/24 anywhere
>> >DROP   all  --  122.224.11.0/24  anywhere
>> >DROP   all  --  219.138.0.0/16   anywhere
How did you added these rules?
using manual command line tools or automatically by fail2ban?

Eliezer
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] iptables question

2014-06-16 Thread John R Pierce
On 6/16/2014 2:58 PM, Chuck Campbell wrote:
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> fail2ban-VSFTPD  tcp  --  anywhere anywheretcp dpt:ftp
> fail2ban-SSH  tcp  --  anywhere anywheretcp dpt:ssh
> RH-Firewall-1-INPUT  all  --  anywhere anywhere
> DROP   all  --  116.10.191.0/24  anywhere
> DROP   all  --  183.136.220.0/24 anywhere
> DROP   all  --  183.136.221.0/24 anywhere
> DROP   all  --  183.136.222.0/24 anywhere
> DROP   all  --  183.136.223.0/24 anywhere
> DROP   all  --  122.224.11.0/24  anywhere
> DROP   all  --  219.138.0.0/16   anywhere
>
> ...
>
> Chain RH-Firewall-1-INPUT (2 references)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywhere
> ACCEPT icmp --  anywhere anywhereicmp any
> ACCEPT esp  --  anywhere anywhere
> .
> .
> .
>
> Yet in my logwatch emails, I see this, long after the iptables rules are in
> place to drop some ip ranges:

RH-Firewall-1-INPUT is being invoked prior to your DROP rules, and is 
ACCEPTing all packets.



-- 
john r pierce  37N 122W
somewhere on the middle of the left coast

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] iptables question

2014-06-16 Thread Frank Cox
On Mon, 16 Jun 2014 16:58:18 -0500
Chuck Campbell wrote:

> Why is this ip range still able to attempt connections? Have I done something
> wrong with my address ranges, or added them in the wrong place?

Have you considered taking the opposite approach and allowing only the IP 
addresses that you want to allow and blocking everything else?  That would be a 
lot easier to keep track of and manage.

I personally don't allow password logins on any of the ssh connections that I 
look after.

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] iptables question

2014-06-16 Thread Always Learning

On Mon, 2014-06-16 at 16:58 -0500, Chuck Campbell wrote:

> I'm running fail2ban to attempt to block malicious brute-force password
> dictionary attacks against ssh.

You could:-

(1) Change the SSHD port to something obscure.

(2) Restrict access to the SSHD port, using iptables, to a group of
approved IP addresses.

Regards,
-- 
Paul.
England, EU.

   Centos, Exim, Apache. Linux is the future. Micro$oft is the past.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


[CentOS] iptables question

2014-06-16 Thread Chuck Campbell
I'm running fail2ban to attempt to block malicious brute-force password
dictionary attacks against ssh. They seem to be rolling through a block of ip
addresses as the source to defeat this kind of screening, so I've set some ip
addresses to be blocked in iptables. Here is the output of iptables -L (edited):

Chain INPUT (policy ACCEPT)
target prot opt source   destination
fail2ban-VSFTPD  tcp  --  anywhere anywheretcp dpt:ftp
fail2ban-SSH  tcp  --  anywhere anywheretcp dpt:ssh
RH-Firewall-1-INPUT  all  --  anywhere anywhere   
DROP   all  --  116.10.191.0/24  anywhere   
DROP   all  --  183.136.220.0/24 anywhere   
DROP   all  --  183.136.221.0/24 anywhere   
DROP   all  --  183.136.222.0/24 anywhere   
DROP   all  --  183.136.223.0/24 anywhere   
DROP   all  --  122.224.11.0/24  anywhere   
DROP   all  --  219.138.0.0/16   anywhere   

Chain FORWARD (policy ACCEPT)
target prot opt source   destination
RH-Firewall-1-INPUT  all  --  anywhere anywhere   
REJECT all  --  anywhere anywherereject-with icmp-ho
st-prohibited

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain RH-Firewall-1-INPUT (2 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere   
ACCEPT icmp --  anywhere anywhereicmp any
ACCEPT esp  --  anywhere anywhere   
.
.
.

Yet in my logwatch emails, I see this, long after the iptables rules are in
place to drop some ip ranges:

 - pam_unix Begin 

 sshd:
Authentication Failures:
   root (116.10.191.166): 1 Time(s)
   root (116.10.191.167): 1 Time(s)
   root (116.10.191.170): 1 Time(s)
   root (116.10.191.173): 1 Time(s)
   root (116.10.191.179): 1 Time(s)
   root (116.10.191.182): 1 Time(s)
   root (116.10.191.186): 1 Time(s)
   root (116.10.191.199): 1 Time(s)
   root (116.10.191.203): 1 Time(s)
   root (116.10.191.211): 1 Time(s)
   root (116.10.191.219): 1 Time(s)
   root (116.10.191.223): 1 Time(s)
   root (116.10.191.226): 1 Time(s)
   root (116.10.191.228): 1 Time(s)
   root (116.10.191.237): 1 Time(s)


 - SSHD Begin 


 Failed logins from:
 
116.10.191.165: 4 times
116.10.191.181: 3 times
116.10.191.201: 4 times
116.10.191.207: 4 times
116.10.191.218: 4 times
116.10.191.231: 4 times
116.10.191.234: 3 times
116.10.191.235: 4 times
116.10.191.239: 4 times

If they keep going through this ip block, they will still get 255 attempts at
the root password and 1020 attempts at other login/password combinations before
they are blocked by fail2ban.

Why is this ip range still able to attempt connections? Have I done something
wrong with my address ranges, or added them in the wrong place?

thanks,
-chuck

-- 
ACCEL Services, Inc.| Specialists in Gravity, Magnetics |  (713)993-0671 ph.
|   and Integrated Interpretation   |  (713)993-0608 fax
448 W. 19th St. #325|Since 1992 |  (713)306-5794 cell
 Houston, TX, 77008 |  Chuck Campbell   | campb...@accelinc.com
|  President & Senior Geoscientist  |

 "Integration means more than having all the maps at the same scale!"

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Question about clustering

2014-06-16 Thread Digimer
On 16/06/14 02:55 PM, m.r...@5-cent.us wrote:
> Digimer wrote:
>> On 16/06/14 02:19 PM, John R Pierce wrote:
>>> On 6/16/2014 10:55 AM, Digimer wrote:
 The main downside to fabric fencing is that the failed node will have
 no
 chance of recovering without human intervention. Further, it places the
 onus on the admin to not simply unfence the node without first doing
 proper cleanup/recovery. For these reasons, I always recommend power
 fencing (IPMI, PDUs, etc).
>>>
>>> how does power fencing change your first 2 statements in any fashion ?
>>> as I see it, it would make manual recovery even harder, as you couldn't
>>> even power up the failed system without first disconnecting it from the
>>> network
>>>
>>> When I have used network fencing, I've left the admin ports live, that
>>> way, the operator can access the system console to find out WHY it is
>>> fubar, and put it in a proper state for recovery.   of course, this
>>> implies you have several LAN connections, which is always a good idea
>>> for a clustered system anyways.
>>
>> Most power fencing methods are set to "reboot", which is "off -> verify
>> -> try to boot", with the "try to boot" part not effecting success of
>> the overall fence call. In my experience (dozens of clusters going back
>> to 2009), this has always left the nodes booted, save for cases where
>> the node itself had totally failed. I also do not start the cluster on
>> boot in most cases, so the node is there and waiting for an admin to
>> login, in a clean state (no concept of cluster state in memory, thanks
>> to the reboot).
>>
>> If you're curious, this is how I build my clusters. It also goes into
>> length on the fencing topology and rationale:
>>
>> https://alteeve.ca/w/AN!Cluster_Tutorial_2
>
> One can also set the cluster nodes to failover, and when the failed node
> comes up, to *not* try to take back the services, leaving it in a state
> for you to fix it.
>
>  mark, first work on h/a clusters 1997-2001

Failover and recovery are secondary to fencing. The surviving node(s) 
can't begin recovery until the lost node is in a known state. To make an 
assumption about the node's state (by, for example, assuming that no 
access to the node is sufficient to determine it is off) is to risk a 
split-brain. Even something as relatively "minor" as a floating IP can 
potentially cause problems with ARP, for example.

Cheers

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without 
access to education?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Question about clustering

2014-06-16 Thread m . roth
Digimer wrote:
> On 16/06/14 02:19 PM, John R Pierce wrote:
>> On 6/16/2014 10:55 AM, Digimer wrote:
>>> The main downside to fabric fencing is that the failed node will have
>>> no
>>> chance of recovering without human intervention. Further, it places the
>>> onus on the admin to not simply unfence the node without first doing
>>> proper cleanup/recovery. For these reasons, I always recommend power
>>> fencing (IPMI, PDUs, etc).
>>
>> how does power fencing change your first 2 statements in any fashion ?
>> as I see it, it would make manual recovery even harder, as you couldn't
>> even power up the failed system without first disconnecting it from the
>> network
>>
>> When I have used network fencing, I've left the admin ports live, that
>> way, the operator can access the system console to find out WHY it is
>> fubar, and put it in a proper state for recovery.   of course, this
>> implies you have several LAN connections, which is always a good idea
>> for a clustered system anyways.
>
> Most power fencing methods are set to "reboot", which is "off -> verify
> -> try to boot", with the "try to boot" part not effecting success of
> the overall fence call. In my experience (dozens of clusters going back
> to 2009), this has always left the nodes booted, save for cases where
> the node itself had totally failed. I also do not start the cluster on
> boot in most cases, so the node is there and waiting for an admin to
> login, in a clean state (no concept of cluster state in memory, thanks
> to the reboot).
>
> If you're curious, this is how I build my clusters. It also goes into
> length on the fencing topology and rationale:
>
> https://alteeve.ca/w/AN!Cluster_Tutorial_2

One can also set the cluster nodes to failover, and when the failed node
comes up, to *not* try to take back the services, leaving it in a state
for you to fix it.

mark, first work on h/a clusters 1997-2001

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Question about clustering

2014-06-16 Thread Digimer
On 16/06/14 02:19 PM, John R Pierce wrote:
> On 6/16/2014 10:55 AM, Digimer wrote:
>> The main downside to fabric fencing is that the failed node will have no
>> chance of recovering without human intervention. Further, it places the
>> onus on the admin to not simply unfence the node without first doing
>> proper cleanup/recovery. For these reasons, I always recommend power
>> fencing (IPMI, PDUs, etc).
>
> how does power fencing change your first 2 statements in any fashion ?
> as I see it, it would make manual recovery even harder, as you couldn't
> even power up the failed system without first disconnecting it from the
> network
>
> When I have used network fencing, I've left the admin ports live, that
> way, the operator can access the system console to find out WHY it is
> fubar, and put it in a proper state for recovery.   of course, this
> implies you have several LAN connections, which is always a good idea
> for a clustered system anyways.

Most power fencing methods are set to "reboot", which is "off -> verify 
-> try to boot", with the "try to boot" part not effecting success of 
the overall fence call. In my experience (dozens of clusters going back 
to 2009), this has always left the nodes booted, save for cases where 
the node itself had totally failed. I also do not start the cluster on 
boot in most cases, so the node is there and waiting for an admin to 
login, in a clean state (no concept of cluster state in memory, thanks 
to the reboot).

If you're curious, this is how I build my clusters. It also goes into 
length on the fencing topology and rationale:

https://alteeve.ca/w/AN!Cluster_Tutorial_2

Cheers


-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without 
access to education?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Question about clustering

2014-06-16 Thread John R Pierce
On 6/16/2014 10:55 AM, Digimer wrote:
> The main downside to fabric fencing is that the failed node will have no
> chance of recovering without human intervention. Further, it places the
> onus on the admin to not simply unfence the node without first doing
> proper cleanup/recovery. For these reasons, I always recommend power
> fencing (IPMI, PDUs, etc).

how does power fencing change your first 2 statements in any fashion ?  
as I see it, it would make manual recovery even harder, as you couldn't 
even power up the failed system without first disconnecting it from the 
network

When I have used network fencing, I've left the admin ports live, that 
way, the operator can access the system console to find out WHY it is 
fubar, and put it in a proper state for recovery.   of course, this 
implies you have several LAN connections, which is always a good idea 
for a clustered system anyways.


-- 
john r pierce  37N 122W
somewhere on the middle of the left coast

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] SELinux issue?

2014-06-16 Thread Chuck Campbell
On 6/16/2014 10:13 AM, m.r...@5-cent.us wrote:
> Chuck Campbell wrote:
>> I've recently built a new mail server with centos6.5, and decided to bite
>> the bullet and leave SELinux running. I've stumbled through making
> things work
>> and am mostly there.
>>
>> I've got my own spam and ham corpus as mbox files in
>> /home/user/Mail/learned.
>> These files came from my backup of the centos 5 server this machine is
>> replacing.
>>
>> The folder is owned by the user (the following is run as root):
>> ls -laF learned
>> drw---. 6 user group   4096 Jun 10 03:35 ./
>> drw---. 6 user group  35864Jun 10 03:35 ../
>> drw---. 6 user group   4096 Jun 10 03:35 2004/
>> -rw---. 6 user group 155296 Jun 10 03:35 2014_10_Jun_learned_spam
>> -rw---. 6 user group 996584 Jun 10 03:35 2014_10_Jun_learned_ham
>>
>> also as root:
>> ls -laZlearned
>> drw---. 6 user group unconfined_u:object_r:mail_spool_t:s0.
>> drw---. 6 user group unconfined_u:object_r:mail_spool_t:s0..
>> drw---. 6 user group unconfined_u:object_r:mail_spool_t:s02004
>> -rw---. 6 user group
>> system_u:object_r:mail_spool_t:s02014_10_Jun_learned_spam
>> -rw---. 6 user group
>> system_u:object_r:mail_spool_t:s02014_10_Jun_learned_ham
>>
>> When I do the same as the user, I get this:
>> ls -laF learned
>> ls: cannot access learned/2004: Permission denied
>> ls: cannot access 2014_10_Jun_learned_spam: Permission denied
>> ls: cannot access 2014_10_Jun_learned_ham: Permission denied
> 
> Yup, you will. The *directories* have to be executable for you to look in
> them.
>
>   mark
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

I don't know how, after all these years, that bit on knowledge escaped me.

Thanks, it works perfectly now.

-chuck


-- 
ACCEL Services, Inc.| Specialists in Gravity, Magnetics |  (713)993-0671 ph.
|   and Integrated Interpretation   |  (713)993-0608 fax
448 W. 19th St. #325|Since 1992 |  (713)306-5794 cell
 Houston, TX, 77008 |  Chuck Campbell   | campb...@accelinc.com
|  President & Senior Geoscientist  |

 "Integration means more than having all the maps at the same scale!"

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Question about clustering

2014-06-16 Thread Digimer
On 16/06/14 01:36 PM, John R Pierce wrote:
> On 6/16/2014 2:39 AM, Alessandro Baggi wrote:
>> Hi Digimer,
>> there is a chance to make fencing without hardware, but only software?
>
> the most common fence in TCP connected systems is to disable the
> ethernet ports of the fenced system, done via a 'smart ethernet
> switch'.   if you're using shared fiber storage, then you fence via the
> fiber switch.  a more extreme fence is to switch off the power to the
> fenced system via a 'smart PDU'.

Disconnecting a lost node from the network is a process called "Fabric 
Fencing". It is not the most common, at least not these days. In the 
past, fencing was done primarily at the fabric switch to disconnect the 
node from shared storage, however this isn't as common anymore. These 
days, as you say, you can do something similar by turning down managed 
switch ports.

The main downside to fabric fencing is that the failed node will have no 
chance of recovering without human intervention. Further, it places the 
onus on the admin to not simply unfence the node without first doing 
proper cleanup/recovery. For these reasons, I always recommend power 
fencing (IPMI, PDUs, etc).

digimer

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without 
access to education?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Question about clustering

2014-06-16 Thread John R Pierce
On 6/16/2014 2:39 AM, Alessandro Baggi wrote:
> Hi Digimer,
> there is a chance to make fencing without hardware, but only software?

the most common fence in TCP connected systems is to disable the 
ethernet ports of the fenced system, done via a 'smart ethernet 
switch'.   if you're using shared fiber storage, then you fence via the 
fiber switch.  a more extreme fence is to switch off the power to the 
fenced system via a 'smart PDU'.


-- 
john r pierce  37N 122W
somewhere on the middle of the left coast

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] SELinux issue?

2014-06-16 Thread Daniel J Walsh

On 06/16/2014 11:13 AM, m.r...@5-cent.us wrote:
> Chuck Campbell wrote:
>> I've recently built a new mail server with centos6.5, and decided to bite
>> the bullet and leave SELinux running. I've stumbled through making
> things work
>> and am mostly there.
>>
>> I've got my own spam and ham corpus as mbox files in
>> /home/user/Mail/learned.
>> These files came from my backup of the centos 5 server this machine is
>> replacing.
>>
>> The folder is owned by the user (the following is run as root):
>> ls -laF learned
>> drw---. 6 user group   4096 Jun 10 03:35 ./
>> drw---. 6 user group  35864Jun 10 03:35 ../
>> drw---. 6 user group   4096 Jun 10 03:35 2004/
>> -rw---. 6 user group 155296 Jun 10 03:35 2014_10_Jun_learned_spam
>> -rw---. 6 user group 996584 Jun 10 03:35 2014_10_Jun_learned_ham
>>
>> also as root:
>> ls -laZlearned
>> drw---. 6 user group unconfined_u:object_r:mail_spool_t:s0.
>> drw---. 6 user group unconfined_u:object_r:mail_spool_t:s0..
>> drw---. 6 user group unconfined_u:object_r:mail_spool_t:s02004
>> -rw---. 6 user group
>> system_u:object_r:mail_spool_t:s02014_10_Jun_learned_spam
>> -rw---. 6 user group
>> system_u:object_r:mail_spool_t:s02014_10_Jun_learned_ham
>>
>> When I do the same as the user, I get this:
>> ls -laF learned
>> ls: cannot access learned/2004: Permission denied
>> ls: cannot access 2014_10_Jun_learned_spam: Permission denied
>> ls: cannot access 2014_10_Jun_learned_ham: Permission denied
> 
> Yup, you will. The *directories* have to be executable for you to look in
> them.
>
>   mark
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
I think this is more of a DAC issue as Mark has said. 

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


[CentOS] Odd issue: power_saving

2014-06-16 Thread m . roth
On a running system, I was just logging in, and it took for-bloody-ever. I
run top, and ok, a load of 5 still shouldn't do that; we have folks that
do put real loads on these systems. But top shows me power_saving
frequently coming to the top, with a 94% - 100% CPU usage, and there's two
threads of power_saving. Add to this that I don't *ever* remember seeing
such a kernel thread.

So, can I kill either or both threads? Googling some, I see someone
suggesting:
acpi_pad.disable=1 already added in grub.conf ;-) (after having `modprobe
-r acpi_pad`, which solves directly the load issue)

Good idea or not?

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] SELinux issue?

2014-06-16 Thread m . roth
Chuck Campbell wrote:
>
> I've recently built a new mail server with centos6.5, and decided to bite
> the bullet and leave SELinux running. I've stumbled through making
things work
> and am mostly there.
>
> I've got my own spam and ham corpus as mbox files in
> /home/user/Mail/learned.
> These files came from my backup of the centos 5 server this machine is
> replacing.
>
> The folder is owned by the user (the following is run as root):
> ls -laF learned
> drw---. 6 user group   4096 Jun 10 03:35 ./
> drw---. 6 user group  35864Jun 10 03:35 ../
> drw---. 6 user group   4096 Jun 10 03:35 2004/
> -rw---. 6 user group 155296 Jun 10 03:35 2014_10_Jun_learned_spam
> -rw---. 6 user group 996584 Jun 10 03:35 2014_10_Jun_learned_ham
>
> also as root:
> ls -laZlearned
> drw---. 6 user group unconfined_u:object_r:mail_spool_t:s0.
> drw---. 6 user group unconfined_u:object_r:mail_spool_t:s0..
> drw---. 6 user group unconfined_u:object_r:mail_spool_t:s02004
> -rw---. 6 user group
> system_u:object_r:mail_spool_t:s02014_10_Jun_learned_spam
> -rw---. 6 user group
> system_u:object_r:mail_spool_t:s02014_10_Jun_learned_ham
>
> When I do the same as the user, I get this:
> ls -laF learned
> ls: cannot access learned/2004: Permission denied
> ls: cannot access 2014_10_Jun_learned_spam: Permission denied
> ls: cannot access 2014_10_Jun_learned_ham: Permission denied

Yup, you will. The *directories* have to be executable for you to look in
them.

  mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] issue_discards in lvm.conf

2014-06-16 Thread m . roth
Dan Hyatt wrote:
>I worked in the SSD lab at STEC for a while, testing SSD's and fixing
> SSD's that failed...

> I knew how to blow up the drives, run them well beyond the capacity of
> spinner drives. But then I would flash the firmware and the drive would
> be good as new.  I would be running about 200 music videos at the same
> time to get enough throughput to cause it to crash. The goal was to find
> *when* they blew up, so we could limit them in firmware before then.

Interesting. But did you ever stick one in a microwave? (Someone else's,
that is ) Or aim an oxy-acetylene torch at it, he asks, innocently? I
don't have an EMP gun handy
>
> We all know manufacturers know how to make benchmarks lie. They told me
> which tests to run to make our drives blow away the spinners, and which
> ones not to do. The very fragmented drives RO, SSD blew away the
> spinners, but Writting sequentially (both blank drives to start) there
> was little difference.

Oh, the ones that aggravate me are the ones who limit what you can do,
like WD, then the others, who changed the firmware starting in '09, so
that you *couldn't* change the TLER from 2 min to 7 sec

   mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


[CentOS] SELinux issue?

2014-06-16 Thread Chuck Campbell

I've recently built a new mail server with centos6.5, and decided to bite the 
bullet and leave SELinux running. I've stumbled through making things work and 
am mostly there.

I've got my own spam and ham corpus as mbox files in /home/user/Mail/learned. 
These files came from my backup of the centos 5 server this machine is 
replacing.

The folder is owned by the user (the following is run as root):
ls -laF learned
drw---. 6 user group   4096 Jun 10 03:35 ./
drw---. 6 user group  35864Jun 10 03:35 ../
drw---. 6 user group   4096 Jun 10 03:35 2004/
-rw---. 6 user group 155296 Jun 10 03:35 2014_10_Jun_learned_spam
-rw---. 6 user group 996584 Jun 10 03:35 2014_10_Jun_learned_ham

also as root:
ls -laZlearned
drw---. 6 user group unconfined_u:object_r:mail_spool_t:s0.
drw---. 6 user group unconfined_u:object_r:mail_spool_t:s0..
drw---. 6 user group unconfined_u:object_r:mail_spool_t:s02004
-rw---. 6 user group 
system_u:object_r:mail_spool_t:s02014_10_Jun_learned_spam
-rw---. 6 user group 
system_u:object_r:mail_spool_t:s02014_10_Jun_learned_ham


When I do the same as the user, I get this:
ls -laF learned
ls: cannot access learned/2004: Permission denied
ls: cannot access 2014_10_Jun_learned_spam: Permission denied
ls: cannot access 2014_10_Jun_learned_ham: Permission denied
total 0
d ? ? ? ? ? ./
d ? ? ? ? ? ../
d ? ? ? ? ? 2004/
- ? ? ? ? ? 2014_10_Jun_learned_spam
- ? ? ? ? ? 2014_10_Jun_learned_ham

and this:
ls -laFZ learned
ls: cannot access learned/2004: Permission denied
ls: cannot access 2014_10_Jun_learned_spam: Permission denied
ls: cannot access 2014_10_Jun_learned_ham: Permission denied
total 0
d ? ?   ./
d ? ? ../
d ? ? 2004/
- ? ? 2014_10_Jun_learned_spam
- ? ? 2014_10_Jun_learned_ham

The user's process to feed the spam and ham to spamassassin fails when trying 
to 
write to the directories, even though the files are owned by user:group

What, precisely is wrong here? I don't get any AVC entries in 
/var/log/audit/audit.log, so I'm at a loss as to what to try next. Should this 
directory not be target mail_spool_t? Any guesses?

-chuck

-- 
ACCEL Services, Inc.| Specialists in Gravity, Magnetics |  (713)993-0671 ph.
 |   and Integrated Interpretation   |  (713)993-0608 fax
448 W. 19th St. #325|Since 1992 |  (713)306-5794 cell
  Houston, TX, 77008 |  Chuck Campbell   | campb...@accelinc.com
 |  President & Senior Geoscientist  |

  "Integration means more than having all the maps at the same scale!"

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] issue_discards in lvm.conf

2014-06-16 Thread Dan Hyatt
   I worked in the SSD lab at STEC for a while, testing SSD's and fixing 
SSD's that failed...

When I was working in the lab on the Zuess  drives (First enterprise 
class SSD drive) . When the drives came back from our customers hosed, 
all we had to do was re-flash the firmware (helps if you have the 
software and the firmware to reflash the drives, the hardware was your 
basic server).  I don't know about you problem, or which manufacturing 
process drives you are using...but the Zeuss drives only needed a 
firmware reflash.

This was just a 2u server with a software program that would allow me to 
reflash the drives.

There were 2 kinds of SSD drives (2 manufacturing processes). The 
consumer grade which had a MTF of 2 years, and/or X writes.   There was 
the other process, enterprise class drives which had a MTF of ~ (yes 
infinity) theory was they would never fail.

I knew how to blow up the drives, run them well beyond the capacity of 
spinner drives. But then I would flash the firmware and the drive would 
be good as new.  I would be running about 200 music videos at the same 
time to get enough throughput to cause it to crash. The goal was to find 
*when* they blew up, so we could limit them in firmware before then.

We all know manufacturers know how to make benchmarks lie. They told me 
which tests to run to make our drives blow away the spinners, and which 
ones not to do. The very fragmented drives RO, SSD blew away the 
spinners, but Writting sequentially (both blank drives to start) there 
was little difference.

When our customers (the major SAN manufacturers) returned the drives. 
There was one of two things wrong with them...
1. They got a drive with a bad firmware version. Reflash and it is fixed.
2. Their design was good enough for spinner drives but did not follow 
the standard for [SAS|FIBER]  and we found the problem, advised them 
what it was so they could change thier design.

I remember when I dropped a $40k sample...lab manager looked at 
me...stared at me...then burst out laughing. The enterprise SSD's were 
nearly indestructible and when someone dropped on for the first time, 
they would *try* to look angry, but then would burst into laughter at 
the nervous engineer.

If I got any details slightly off, hey it was a decade ago!   :)


On 6/12/2014 1:29 PM, James B. Byrne wrote:
>
> On Thu Jun 12 17:21:43 UTC 2014, John R Pierce pierce at hogranch.com wrote:
>
>> On 6/12/2014 10:12 AM, m.roth at 5-cent.us wrote:
>>> We use two methods: for the drives that are totally dead, or*sigh*  the
>>> SCSI drives, they get deGaussed. For SATA that's still running, we use
>>> DBAN.*Great*  software. From what I've read, one pass would probably be
>>> good enough, given how data's written these days. With my name certifying
>>> it, I do paranoid, and tell DBAN the full 7-pass, DoD 5220.22-M. I
>>> *really*  don't think anyone's getting anything off that.
>> if the drive has remapped tracks, there's stale data on there you can't
>> erase with DBAN.
>>
>>> We don't have any SSDs, so I can't speak to that. Bet you could deGauss
>>> them, easily enough. Or maybe stick 'em on a burner on a stove to get over
>>> the Curie point*
>> degaussing would do nothing to flash memory, its semiconductor,
>> not magnetic.
> An EMP gun on the other hand. . .
>

-- 
  
Dan Hyatt

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Question about clustering

2014-06-16 Thread Digimer
No. For fencing to be worthwhile, it *must* work when the node is in any 
state. For this, it must be independent of node. A great way to see why 
is to test crashing the node (echo c > /proc/sysrq-trigger) or simply 
cutting the power to the node. With the node totally disabled, the 
surviving peer will fail to fence and, not being allowed to make 
assumptions, block.

On 16/06/14 05:39 AM, Alessandro Baggi wrote:
> Hi Digimer,
> there is a chance to make fencing without hardware, but only software?
>
>
> Il 15/06/2014 17:28, Digimer ha scritto:
>> On 15/06/14 08:54 AM, Alessandro Baggi wrote:
>>> Another question is about fencing. I've ridden that a cluster must have
>>> fencing to be considered as such. On CentOS 6.5 there is stonith that
>>> concerns node level fencing. For this type of fencing I must have ilo,
>>> ilom, drac, and other. It's possible to have fencing without Light-out
>>> devices, blade power control device and other? There are other device
>>> that can be used for fencing? Supposing a 2 node cluster with two server
>>> assembled (no hp, dell, sun, ibm..) how I can implement fencing with
>>> stonith? I can run a cluster without fencing and what implies do not use
>>> fencing?
>>
>> A lot of odd problems go away once fencing is working. So this is a good
>> time to sort this out, then go back and see if your problems remain.
>>
>> A very good way to fence machines without IPMI (etc) is to use an
>> external switched PDU, like the APC AP7900 (or your country version on).
>>
>> http://www.apc.com/resource/include/techspec_index.cfm?base_sku=ap7900
>>
>> If your budget is tight, I have seen these models frequently go on sale
>> for ~$200 (Canadian).
>>
>> These work be allowing another node to log into the PDU and turn off the
>> power going to the lost/failed node. Please do note that the brand of
>> switched PDU you buy matters. For a device to work for fencing, it must
>> be possible for the cluster to talk to it. This is done using a "fence
>> handler", and there are many types that are supported (APC, Eaton, etc).
>> So if you want to get a different make/model, please first make sure
>> there is a fence handler.
>>
>> Once you get this setup, see if your problems remain. If so, there is a
>> good clustering mailing list at:
>>
>> https://www.redhat.com/mailman/listinfo/linux-cluster
>>
>> And if you're on freenode, #linux-cluster is also very good.
>>
>> Cheers!
>>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without 
access to education?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


Re: [CentOS] Question about clustering

2014-06-16 Thread Alessandro Baggi
Hi Digimer,
there is a chance to make fencing without hardware, but only software?


Il 15/06/2014 17:28, Digimer ha scritto:
> On 15/06/14 08:54 AM, Alessandro Baggi wrote:
>> Another question is about fencing. I've ridden that a cluster must have
>> fencing to be considered as such. On CentOS 6.5 there is stonith that
>> concerns node level fencing. For this type of fencing I must have ilo,
>> ilom, drac, and other. It's possible to have fencing without Light-out
>> devices, blade power control device and other? There are other device
>> that can be used for fencing? Supposing a 2 node cluster with two server
>> assembled (no hp, dell, sun, ibm..) how I can implement fencing with
>> stonith? I can run a cluster without fencing and what implies do not use
>> fencing?
>
> A lot of odd problems go away once fencing is working. So this is a good
> time to sort this out, then go back and see if your problems remain.
>
> A very good way to fence machines without IPMI (etc) is to use an
> external switched PDU, like the APC AP7900 (or your country version on).
>
> http://www.apc.com/resource/include/techspec_index.cfm?base_sku=ap7900
>
> If your budget is tight, I have seen these models frequently go on sale
> for ~$200 (Canadian).
>
> These work be allowing another node to log into the PDU and turn off the
> power going to the lost/failed node. Please do note that the brand of
> switched PDU you buy matters. For a device to work for fencing, it must
> be possible for the cluster to talk to it. This is done using a "fence
> handler", and there are many types that are supported (APC, Eaton, etc).
> So if you want to get a different make/model, please first make sure
> there is a fence handler.
>
> Once you get this setup, see if your problems remain. If so, there is a
> good clustering mailing list at:
>
> https://www.redhat.com/mailman/listinfo/linux-cluster
>
> And if you're on freenode, #linux-cluster is also very good.
>
> Cheers!
>

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos