Re: Performance difference between two raid0 arrays on same drives?

Re: Performance difference between two raid0 arrays on same drives?

[Michel Bellais]

You're right, I thought about it too, but the fastest array is built with 
partitions closer to the centre of the disk, so it should be the slowest 
indeed.
The disks are big (180 Gb), the partitions represent less than 10% of it and 
follow each others.  It cannot explain 30% difference in performance.

I have created a third array on the disk, which is a copy of the slowest 
array. It has the same content. This last array shows much better performance 
than the original. And it is even closer to the centre...
So i really don't understand.
I intended to use raid0 to boost my pc at home, so it is not a crucial 
problem, i will use the late array i created.

Thank you for your answer!

Michel Bellais

On Saturday 12 July 2003 06:36 am, Gregory Leblanc wrote:
> On Fri, 2003-07-11 at 09:13, Michel wrote:
> > Hi!
> >
> > I have set two raid0 arrays on two hardrives, using 2x2 partitions. I did
> > a benchmark of the resulting arrays and one is much slower than the other
> > one. I used bonnie++ and hdparm for the tests. It showed that /dev/md0 is
> > 30% slower than /dev/md1.
> > /dev/md1 is really close to twice the performance of a single drive.
> > I set the arrays with the same parameters. md0 is built from 2x 5 Gb
> > while md1 is built from 2x2 Gb. The harddrives have the same partition
> > table. md0 is the closest to the begining of the drives.
> > The filessystem is Reiserfs on both arrays.
> > Everything works well, except i am curious about such a difference in
> > performances, since the arrays share the same hardware.
> > I am new to linux raid, i do not know if this is normal or weird.
>
> This is to be expected.  Partitions toward the "end" of the disk are
> written closer to the center of the platters, and as a result, data
> transfers suffer.  The drive spins at a constant number of revolutions
> per minute, making the linear velocity of the platter across the read
> head much higher at the outside of the disk than the outside.  HTH,
>       Greg

Re: Performance difference between two raid0 arrays on same drives?

[Gordon Henderson]

On Sat, 12 Jul 2003, Michel Bellais wrote:

> You're right, I thought about it too, but the fastest array is built with
> partitions closer to the centre of the disk, so it should be the slowest
> indeed.
> The disks are big (180 Gb), the partitions represent less than 10% of it and
> follow each others.  It cannot explain 30% difference in performance.
>
> I have created a third array on the disk, which is a copy of the slowest
> array. It has the same content. This last array shows much better performance
> than the original. And it is even closer to the centre...
> So i really don't understand.

Just a thought: What if modern disk manufacturers write from the inside
out, rather than traditionally from the outside in?

CD's are read from the inside out so we can have different size discs.

Or maybe the hard disk manufacturers cottoned on to the fact that most
people would benchmark freshly partitioned disks hoping the file would be
at the "start" so they make it on the inside and get a better benchmark?

Who knows! And I guess without taking one to bits to watch it work it's
going to be hard to find out...

Gordon

Re: Performance difference between two raid0 arrays on same drives?

[Mads Peter Bach]

Michel Bellais wrote:

> You're right, I thought about it too, but the fastest array is built with 
> partitions closer to the centre of the disk, so it should be the slowest 
> indeed.
> The disks are big (180 Gb), the partitions represent less than 10% of it and 
> follow each others.  It cannot explain 30% difference in performance.

You can test the performance across your drives with the program zcav 
(which should come with bonnie++ - if not, take a look at 
http://www.coker.com.au/bonnie++/)

-- 
Mads Peter Bach
Systemadministrator,  Det Humanistiske Fakultet, Aalborg Universitet
Kroghstræde 3 - 5.111, DK-9220 Aalborg Øst - (+45) 96358062
# whois MPB1-DK@whois.dk-hostmaster.dk

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Performance difference between two raid0 arrays on same drives?

[Michel Bellais]

it sounds tricky to me! 
But if some manufacturer inverts the partition order, that would be good for 
linux: usually windows is installed first and takes the best place on the 
drive, the penguin coming second.

On Saturday 12 July 2003 05:20 pm, Gordon Henderson wrote:
> On Sat, 12 Jul 2003, Michel Bellais wrote:
> > You're right, I thought about it too, but the fastest array is built with
> > partitions closer to the centre of the disk, so it should be the slowest
> > indeed.
> > The disks are big (180 Gb), the partitions represent less than 10% of it
> > and follow each others.  It cannot explain 30% difference in performance.
> >
> > I have created a third array on the disk, which is a copy of the slowest
> > array. It has the same content. This last array shows much better
> > performance than the original. And it is even closer to the centre...
> > So i really don't understand.
>
> Just a thought: What if modern disk manufacturers write from the inside
> out, rather than traditionally from the outside in?
>
> CD's are read from the inside out so we can have different size discs.
>
> Or maybe the hard disk manufacturers cottoned on to the fact that most
> people would benchmark freshly partitioned disks hoping the file would be
> at the "start" so they make it on the inside and get a better benchmark?
>
> Who knows! And I guess without taking one to bits to watch it work it's
> going to be hard to find out...
>
> Gordon
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Performance difference between two raid0 arrays on same drives?

[Michel Bellais]

I have done it with zcat!
The transfer rate decreases steadily from the beginning of the disk to the 
end. It doesn't look linear, but more like a square root..
The loss is about 50% at the end of the disk compared to the beginning.

The test shows that the decrease in performance is negligible in the first 10% 
of the disk, where the raid arrrays are.
So i have really no clue about this performance loss.

Thanks for the tip! It was interesting to test this drive.
Michel Bellais

>
> You can test the performance across your drives with the program zcav
> (which should come with bonnie++ - if not, take a look at
> http://www.coker.com.au/bonnie++/)
>
>--
>Mads Peter Bach
>Systemadministrator,  Det Humanistiske Fakultet, Aalborg Universitet
>Kroghstræde 3 - 5.111, DK-9220 Aalborg Øst - (+45) 96358062
># whois MPB1-DK@whois.dk-hostmaster.dk

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A simple question

[Donghui Wen]

Hi,
   I have a simple question:
    Can software raid survive one disk hot unplug when the raid is under
heavy load?

    During my test (3ware 7500-8 jbod mode, software raid 5), I ran bonnie++
on the
top of md and then unplugged one disk. I saw a lot of scsi disk errors from
dmesg, and then
scsi layer marked this disk offline. Finnally md detected disk failure and
mark this disk
as faulty. But bonnie++ still hangs there with state 'D' which could not be
killed by -9.

Thanks!

Donghui Wen

Re: A simple question

[Michiel Muhlenbaumer]

Correct

On 17 jan 2011, at 17:24, Ajit K Jena wrote:

> Hi,
> 
> I have been following ceph since some time now. I have
> a simple question about the practical situations where
> this could be deployed:
> 
>  Is ceph a clustered file system where a given path can
>  be mounted in parallel on many client systems (e.g. like
>  GFS, lustrefs, or oraclefs) ?
> 
> I am sorry if it is not the appropriate forum for questions
> such as this but I could not find any other mailing list
> on the ceph website.
> 
> Hoping for a quick response.
> 
> --ajit
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

---
Michiel Muhlenbaumer
CTO, Atrato IP Networks

(e) michiel.muhlenbaumer@atratoip.net
(t) +31 20 820 06 23
(m) +31 6 533 133 06

A simple question

[Ajit K Jena]

Hi,

I have been following ceph since some time now. I have
a simple question about the practical situations where
this could be deployed:

  Is ceph a clustered file system where a given path can
  be mounted in parallel on many client systems (e.g. like
  GFS, lustrefs, or oraclefs) ?

I am sorry if it is not the appropriate forum for questions
such as this but I could not find any other mailing list
on the ceph website.

Hoping for a quick response.

--ajit

Re: A Simple Question

[Grant Taylor]

Robb Bossley wrote:
> I have been using Linux for quite some time, and I really enjoy the
> power that is available with netfilter.  Thank you for all of your
> input into the development and testing of it.
> 
> I have used other people's scripts to configure my firewall for a
> number of years, though I usually rolled my own kernels for this.
> 
> I have been reading the mailing list posts and it seems that most of
> you who are very knowledgeable with netfilter would propose a default
> policy of DROP on both the INPUT and FORWARD chains.
> 
> iptables -P INPUT DROP
> iptables -P FORWARD DROP
>  
> However, I have noticed that a number of what I would consider to be
> strong contenders in the market use default policies of ACCEPT and
> then have a DROP rule at the end of the tables / chain.
> 
> iptables -P INPUT ACCEPT
> iptables -P FORWARD ACCEPT
> ...................................(other stuff here)..........................
> iptables -A INPUT -j DROP
> iptables -A FORWARD -j DROP
> 
> I'm confused.  Which is preferred for security and why?  (Or is this
> just six of one, half a dozen of another?)

IMHO both methods are just about equally as effective.  However I believe that by using the default policy of a chain you can save adding a rule that must be traversed and thus make the processing just slightly faster.  On the other hand you can only set default policies on built in chains and thus you must do your own ""policy equivalent at the end of user defined chains with the rules that you have noticed.  Thus for uniformity it may just be easier for some firewall authors to stick with the method that they know will work in EVERY chain than to have to remember which chain they are in.  To me this issue is really 5.5 of one dozen and 6.5 of another, close but not exactly the same.



Grant. . . .

Re: A Simple Question

[Jan Engelhardt]

>iptables -P INPUT DROP
>iptables -P FORWARD DROP
>VS
>iptables -P INPUT ACCEPT
>iptables -P FORWARD ACCEPT
>...(other stuff here)...
>iptables -A INPUT -j DROP
>iptables -A FORWARD -j DROP
>
>Which is preferred for security and why?

Both equally work well. It's just a matter from which side you tackle the 
problem. Compare with 3d-engine editing:

A Quake2 map starts with "air" and you got to add walls -
  that's like -P ACCEPT and -j REJECT/DROP

An Unreal map starts with "everything filled" and you got to subtract rooms -
  like -P DROP and -j ACCEPT

In fact, sometimes it is wise to alternate between the two methods within the 
same table. I've got this in some ruleset:

-P INPUT DROP
-p tcp -m multiport --dport someservices -j ACCEPT
(denying all other traffic)

-P OUTPUT ACCEPT
-o $internal -j DROP
(allowing all other interfaces)


Just like Apache's "Order allow,deny" if you need another inspiration for 
comparison.


Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/

Re: A Simple Question

[/dev/rob0]

On Tuesday 2005-August-09 19:11, Robb Bossley wrote:
> I have been reading the mailing list posts and it seems that most of
> you who are very knowledgeable with netfilter would propose a default
> policy of DROP on both the INPUT and FORWARD chains.
>
> iptables -P INPUT DROP
> iptables -P FORWARD DROP

Yes, but ...

> However, I have noticed that a number of what I would consider to be
> strong contenders in the market use default policies of ACCEPT and
> then have a DROP rule at the end of the tables / chain.
>
> iptables -P INPUT ACCEPT
> iptables -P FORWARD ACCEPT
> ...................................(other stuff
> here).......................... iptables -A INPUT -j DROP
> iptables -A FORWARD -j DROP

... this is simply another means to the same end.

> I'm confused.  Which is preferred for security and why?  (Or is this
> just six of one, half a dozen of another?)

It all depends on the "other stuff" in the middle. At my most complex 
site, I went for default ACCEPT policies because I had multiple types 
of internal interfaces. Even those have varying needs. It just seemed 
that an ACCEPT policy would be the simplest way to get the job done. 
Everything we don't want is dropped (or rejected), everything we do 
want is accepted.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

A Simple Question

[Robb Bossley]

I have been using Linux for quite some time, and I really enjoy the
power that is available with netfilter.  Thank you for all of your
input into the development and testing of it.

I have used other people's scripts to configure my firewall for a
number of years, though I usually rolled my own kernels for this.

I have been reading the mailing list posts and it seems that most of
you who are very knowledgeable with netfilter would propose a default
policy of DROP on both the INPUT and FORWARD chains.

iptables -P INPUT DROP
iptables -P FORWARD DROP
 
However, I have noticed that a number of what I would consider to be
strong contenders in the market use default policies of ACCEPT and
then have a DROP rule at the end of the tables / chain.

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
...................................(other stuff here)..........................
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP

I'm confused.  Which is preferred for security and why?  (Or is this
just six of one, half a dozen of another?)
-- 
As if you could kill time without injuring eternity.  The mass of men
live lives of quiet desperation.
- Henry David Thoreau

RE: A simple question

[Hudson Delbert J Contr 61 CS/SCBN]

I think there has been a bit of loss of direction from the initial thread.

programatically speaking NO services which allow traffic of any kind s/be
running
'out of the box'...

the fewer and smaller amount of code the more secure.

i.e.,,,if it ain't running you cant attack it....common sense....

re: bellovin, cheswick, farmer, wiezste, et al...

console should be how one initally accesses the box unless
we are speaking of a centrally managed security enclave scenario.

why take needless chances...

~piranha


> Just my two cents on this:

My two pennies :)

> If your firewall is designed correctly, there shouldn't be any network
> available services running baring SSH.

If you're using IPTables as a seperate firewall then wouldn't you just
want SSHD listening on the internal interface?

> Because of this, if a hacker gets into your firewall I assume that
> 99.9999% of the time, they'll have root access. Any hacker that could
> hack into your Linux box will be able to disable any iptables rules in
> a second. Hence, blocking the OUTPUT chain on a firewall does NOT
> secure you against hackers.

You're presuming that IPTables isn't protecting a single host.  If
you're using it on a desktop or a server filtering on the OUTPUT chain
gives you a huge gain in security.

-- 
"I think a church with a lightning rod shows a decided lack of confidence"

RE: A simple question

[Daniel Chemko]

> If you're using IPTables as a seperate firewall then wouldn't you just
> want SSHD listening on the internal interface?

> 
> You're presuming that IPTables isn't protecting a single host.  If
> you're using it on a desktop or a server filtering on the OUTPUT chain
> gives you a huge gain in security.

Very true on both points. You should only bind SSH to your secured
channels. Even then you'll have to be careful of internal staff/wormed
PC's trying to exploit the service. Good audit logging and IDS traps for
SSH exploits would be a good start.

In the other case of a desktop Linux, you are very true that OUTPUT
filtering will become more and more prevailent as desktop Linux matures.
I was strictly speaking about gateway/firewalls, not end-user
protection. I wouldn't doubt that someone will develop a netfilter
module along the lines of zonealarm and other 'personal' firewalls.

Re: A simple question

[Nick Drage]

On Thu, Aug 19, 2004 at 10:14:48AM -0700, Daniel Chemko wrote:
> Hudson Delbert J Contr 61 CS/SCBN wrote:
> > this should be a basic rule of netsec 101 ...
> > 
> > one should have to 'turn' on any allowed traffic out of the box.
> > 
> > i.e......the firewall should not allow ANY traffic by default until
> > specifically
> > 		TOLD TO DO SO BY THE ADMIN.
> > 
> > this is a good thing.

> Just my two cents on this:

My two pennies :)

> If your firewall is designed correctly, there shouldn't be any network
> available services running baring SSH.

If you're using IPTables as a seperate firewall then wouldn't you just
want SSHD listening on the internal interface?

> Because of this, if a hacker gets into your firewall I assume that
> 99.9999% of the time, they'll have root access. Any hacker that could
> hack into your Linux box will be able to disable any iptables rules in
> a second. Hence, blocking the OUTPUT chain on a firewall does NOT
> secure you against hackers.

You're presuming that IPTables isn't protecting a single host.  If
you're using it on a desktop or a server filtering on the OUTPUT chain
gives you a huge gain in security.

-- 
"I think a church with a lightning rod shows a decided lack of confidence"

RE: A simple question

[Daniel Chemko]

Hudson Delbert J Contr 61 CS/SCBN wrote:
> this should be a basic rule of netsec 101 ...
> 
> one should have to 'turn' on any allowed traffic out of the box.
> 
> i.e......the firewall should not allow ANY traffic by default until
> specifically
> 		TOLD TO DO SO BY THE ADMIN.
> 
> this is a good thing.


Just my two cents on this:

If your firewall is designed correctly, there shouldn't be any network
available services running baring SSH. Because of this, if a hacker gets
into your firewall I assume that 99.9999% of the time, they'll have root
access. Any hacker that could hack into your Linux box will be able to
disable any iptables rules in a second. Hence, blocking the OUTPUT chain
on a firewall does NOT secure you against hackers.

It does protect you against yourself if you really need it. For a
tightly regimented network with many admins of varying experience, this
might be a sane policy to implement. Beyond that, its simply beurocratic
overhead.

RE: A simple question

[Erick Sanz]

Sudheer,

I like to block all outgoing traffic in case that someone can take control
either from my firewall system or any other system in my network.

The firewall should be the most secure system in your network; however, like
any other system, it is still vulnerable to bugs and exploits.

If the firewall allows everything out, your system can turn out to be the
one used to attack other systems. It might bee too paranoid, but I like to
protect other people from having my systems attacking theirs.

Also, if you don't have a good system security policy, you might not realize
that your system was taken over until the gentleman with the nice black
suits
knock at your door  ....    =)

-- Just my two cents! maybe even less!




> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Sudheer
> Divakaran
> Sent: Wednesday, August 18, 2004 9:37 PM
> To: Netfilter mailing list
> Subject: A simple question
>
>
> Hi,
>
> In almost all IP Tables articles I've found that the default policy of
> all tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as
> far as INPUT and FORWARD tables are concerned, but I do not understand
> why should we set the default policy of OUTPUT chain to DROP.  OUTPUT
> chain is responsible for packets originating from the firewall itself.
> Whay should we DROP it?
>
> Thanks,
> Sudheer
>
>
>
> This email message has been scanned for viruses.
>



This email message has been scanned for viruses.

RE: A simple question

[Hudson Delbert J Contr 61 CS/SCBN]

this should be a basic rule of netsec 101 ...

one should have to 'turn' on any allowed traffic out of the box.

i.e......the firewall should not allow ANY traffic by default until
specifically
		TOLD TO DO SO BY THE ADMIN.

this is a good thing.



####################################
# delbert.hudson@losangeles.af.mil #
#        61cs/scbn, 3-0182         #
####################################


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Mark E.
Donaldson
Sent: Wednesday, August 18, 2004 9:19 PM
To: 'Sudheer Divakaran'; 'Netfilter mailing list'
Subject: RE: A simple question


 
In almost all IP Tables articles I've found that the default policy of all
tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as far as
INPUT and FORWARD tables are concerned, but I do not understand why should
we set the default policy of OUTPUT chain to DROP.  OUTPUT chain is
responsible for packets originating from the firewall itself.  
Whay should we DROP it?

Thanks,
Sudheer

What you say is indeed correct. Most of the articles on the subject do
recommend a default DROP on all three tables. However, I personally do set
my OUTPUT default to ACCEPT, while my FORWARD and INPUT are definitely set
to DROP. As you might expect, it is quite easy to DOS the firewall itself
when OUTPUT is set to DROP. And that is not a real good idea. However,
having said that, close scrutiny must be paid to what you allow out of the
firewall and the necessary rules must be in place.

RE: A simple question

[Jason Opperisano]

> Hi,
>
> In almost all IP Tables articles I've found that the default policy of
> all tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as
> far as INPUT and FORWARD tables are concerned, but I do not understand
> why should we set the default policy of OUTPUT chain to DROP.  OUTPUT
> chain is responsible for packets originating from the firewall itself.
> Whay should we DROP it?
>
> Thanks,
> Sudheer

two reasons i can think of:

1) your firewall is no better than any other machine in your network.  all of the machines behind it are only allowed out on specific ports to specific destinations, so why should the firewall be any different?

2) it helps lazy admins (i.e. me).  on more than one occasion i've found myself ssh'ed into a firewall and tried to go somewhere/do something and it didn't work; and i thought to myself "i probably shouldn't be doing this from the firewall."  it keeps you from treating the machine that is supposed to be the most locked down, tightly secured machine in the network like a common client.  for me anyways...

i only allow out ftp or http to the specific IP's of the machines that i update from (via apt or yum).

-j

RE: A simple question

[Torsten Luettgert]

On Don, 2004-08-19 at 06:18, Mark E. Donaldson wrote:
> As you might expect, it is quite easy to DOS the firewall itself
> when OUTPUT is set to DROP. And that is not a real good idea.

Please elaborate - why is it easy to DOS the firewall if the output
policy is DROP? You don't mean icmp/source-quench not getting
delivered or something?

> However, having said that, close scrutiny must be paid to what you
> allow out of the firewall and the necessary rules must be in place.

...which is why I personally use DROP as default policy for all
chains and explicitly allow everything I think necessary :-)

The only exception is in the mangle table, where I use ACCEPT
policies and just filter out the obvious spoofs, unclean frames
etc.

Greetings,
Torsten

Re: A simple question

[Dhananjoy Chowdhury]

Hi,
As far as my knowledge this is done so that the local processes on the
firewall machine itself cannot communicate with the outside world.
Mostly firewalls are set for FORWARDing so from security point of view
its better we set the OUTPUT chain to DROP.
But its again your choice waht you want to ACCEPT or DROP.


On Thu, 2004-08-19 at 08:06, Sudheer Divakaran wrote:
> Hi,
> 
> In almost all IP Tables articles I've found that the default policy of 
> all tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as 
> far as INPUT and FORWARD tables are concerned, but I do not understand 
> why should we set the default policy of OUTPUT chain to DROP.  OUTPUT 
> chain is responsible for packets originating from the firewall itself.  
> Whay should we DROP it?
> 
> Thanks,
> Sudheer
> 

RE: A simple question

[Mark E. Donaldson]

 
In almost all IP Tables articles I've found that the default policy of all
tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as far as
INPUT and FORWARD tables are concerned, but I do not understand why should
we set the default policy of OUTPUT chain to DROP.  OUTPUT chain is
responsible for packets originating from the firewall itself.  
Whay should we DROP it?

Thanks,
Sudheer

What you say is indeed correct. Most of the articles on the subject do
recommend a default DROP on all three tables. However, I personally do set
my OUTPUT default to ACCEPT, while my FORWARD and INPUT are definitely set
to DROP. As you might expect, it is quite easy to DOS the firewall itself
when OUTPUT is set to DROP. And that is not a real good idea. However,
having said that, close scrutiny must be paid to what you allow out of the
firewall and the necessary rules must be in place.

A simple question

[Sudheer Divakaran]

Hi,

In almost all IP Tables articles I've found that the default policy of 
all tables (INPUT,OUTPUT,FORWARD) set to DROP.  I can understand it as 
far as INPUT and FORWARD tables are concerned, but I do not understand 
why should we set the default policy of OUTPUT chain to DROP.  OUTPUT 
chain is responsible for packets originating from the firewall itself.  
Whay should we DROP it?

Thanks,
Sudheer

Re: A simple question

[Gianni Pucciani]

Ok Antony, thanks for the help and sorry for my second mail, I was a bit 
in a hurry yesterday ;-)
Maybe I have to review the TCP protocol...

Gianni
Antony Stone wrote:

>On Tuesday 06 April 2004 3:25 am, Gianni Pucciani wrote:
>
>  
>
>>Hi all,
>>I'm new to the use of iptable. I set this script for my home
>>workstation, but when I apply these rules anything stop functioning.
>>I guess I'm doing something stupid but this is my very first time with
>>iptables, so sorry.
>>    
>>
>
>The major problem with your ruleset is that you have no rules in either your 
>INPUT or OUTPUT chains to allow reply packets.
>
>My recommendation is to start simple, and add things bit by bit.   Then if 
>something goes wrong, you only need to look at the (simple) thing you added 
>most recently.
>
>For a home workstation, try the following ruleset (which will allow more 
>traffic than you say you want, but is still secure from the outside world).
>
>You can add more specific rules to allow only the correct traffic, and to 
>allow limited connections from the outside, as you want to.
>
>iptables -P INPUT DROP
>iptables -P OUTPUT DROP
>iptables -P FORWARD DROP
>iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>iptables -A OUTPUT -j ACCEPT
>
>Regards,
>
>Antony.
>
>  
>

A simple question

[Gianni Pucciani]

Hi all,
I'm new to the use of iptable. I set this script for my home 
workstation, but when I apply these rules anything stop functioning.
I guess I'm doing something stupid but this is my very first time with 
iptables, so sorry.
I use my workstation that is behind an adsl router. My workstation has a 
fixed ip, 192.168.1.2 and I'd like to use it for Tomcat server , ssh 
server and general client features.Can anyone give me some help?
Thanks

PS Comment are italian, but hope rules be quite clear...


#!/bin/sh
#G.P
#last update 050404
#Script di inizializzazione per settare un insieme di regole
#di packet filtering tramite iptables.

#definire le policy (comportamento di default)per le catene di default
/sbin/iptables -P INPUT DROP #ogni pacchetto in ingresso scartato
/sbin/iptables -P OUTPUT DROP #ogni pacchetto in uscita accettato
/sbin/iptables -P FORWARD DROP #ogni pacchetto di passaggio scartato

#flush di tutte le catene
/sbin/iptables --flush

#elimina le catene
/sbin/iptables -X miacatenain
/sbin/iptables -X miacatenaout


#creare una nuova catena
/sbin/iptables -N miacatenain
/sbin/iptables -N miacatenaout

#aggiungere una regola a INPUT e OUTPUT per passare
#dalle regole appena definite. Ogni pacchetto fa match e passa
#alla catena 'miacatena' corrispondente
/sbin/iptables -A INPUT -j miacatenain
/sbin/iptables -A OUTPUT -j miacatenaout

#######aggiungere le regole alla catena di ingresso#########

#ICMP
#Consentire traffico icmp
/sbin/iptables -A miacatenain -p icmp -j ACCEPT

#CUPS
#Consentire traffico cups in ingresso
/sbin/iptables -A miacatenain -p tcp --dport 632 -j ACCEPT
/sbin/iptables -A miacatenain -p udp --dport 632 -j ACCEPT


##EDONKEY
#Consentire traffico tcp alla porta 4663
/sbin/iptables -A miacatenain -p tcp --dport 4663 -j ACCEPT
/sbin/iptables -A miacatenain -p udp --dport 4663 -j ACCEPT

#SSH
#Consentire traffico ssh in ingresso

/sbin/iptables -A miacatenain -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A miacatenain -p udp --dport 22 -j ACCEPT

#TOMCAT
#Consentire traffico web in ingresso x Tomcat da ufficio
/sbin/iptables -A miacatenain -p tcp --dport 8080 -d 192.168.1.2 -s 
131.114.136.26 -j ACCEPT

#Consentire traffico web in ingresso x Tomcat da rete locale
/sbin/iptables -A miacatenain -p tcp --dport 8080 -d 192.168.1.2 -s 
192.168.1.0/255.255.255.0 -j ACCEPT

#LOOPBACK
#Consentire tutto il traffico tramite l'interfaccia di loopback
#/sbin/iptables -A miacatenain -i lo -j ACCEPT

#######aggiungere le regole alla catena di uscita#######

#Consentire connessioni ftp in ingresso
#/sbin/iptables -A miacatena -p tcp --dport 2020 e 21 in uscita
#/sbin/iptables -A miacatena -p tcp --dport

##EDONKEY
#Consentire traffico tcp alla porta 4663
/sbin/iptables -A miacatenaout -p tcp --dport 4663 -j ACCEPT
/sbin/iptables -A miacatenaout -p udp --dport 4663 -j ACCEPT

#DNS
#Consentire traffico dns in uscita
/sbin/iptables -A miacatenaout -p tcp --dport 53 -j ACCEPT
/sbin/iptables -A miacatenaout -p udp --dport 53 -j ACCEPT

#SMTP POP3
#Consentire traffico smtp
/sbin/iptables -A miacatenaout -p tcp --dport 25 -j ACCEPT
/sbin/iptables -A miacatenaout -p tcp --dport 110 -j ACCEPT

#SSH
#Consentire traffico SSH in uscita
/sbin/iptables -A miacatenaout -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A miacatenaout -p udp --dport 22 -j ACCEPT

#WEB
#Consentire traffico web in uscita
/sbin/iptables -A miacatenaout -p tcp --dport 80 -j ACCEPT

#LOOPBACK
#Consentire tutto il traffico tramite l'interfaccia di loopback
#/sbin/iptables -A miacatenain -i lo -j ACCEPT


#########applica le modifiche#########
/sbin/service iptables save

/sbin/service iptables restart

Re: A simple question

[Antony Stone]

On Tuesday 06 April 2004 3:25 am, Gianni Pucciani wrote:

> Hi all,
> I'm new to the use of iptable. I set this script for my home
> workstation, but when I apply these rules anything stop functioning.
> I guess I'm doing something stupid but this is my very first time with
> iptables, so sorry.

The major problem with your ruleset is that you have no rules in either your 
INPUT or OUTPUT chains to allow reply packets.

My recommendation is to start simple, and add things bit by bit.   Then if 
something goes wrong, you only need to look at the (simple) thing you added 
most recently.

For a home workstation, try the following ruleset (which will allow more 
traffic than you say you want, but is still secure from the outside world).

You can add more specific rules to allow only the correct traffic, and to 
allow limited connections from the outside, as you want to.

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j ACCEPT

Regards,

Antony.

-- 
Most people have more than the average number of legs.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: A Simple question

[chuckw]

Jad,

  Try this document.  It is a nice intro into how the gnu configure system
works.  With a few examples.  It will get you started, and as you get a
feel for how it all works, you can delve into the autoconf/automake/libtool
info documents.

Chuck
On Fri, Jun 27, 2003 at 01:56:31AM -0700, Jad Saklawi wrote:
> Hello guys, 
>   I am new to UNIX programing, i know how to write make files 
> any how i would like to write dynamic make files depending on the libraries 
> the user has, iv seen in many programs using the "./configure" and would like 
> to ask if any one has a tutorial on how to write Makefile.in files for my 
> programs so that they could be dynamically configured by ./configure 
>  
> Thanks for your help, Greets Jad 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A Simple question

[Glynn Clements]

Jad Saklawi wrote:

>   I am new to UNIX programing, i know how to write make files 
> any how i would like to write dynamic make files depending on the libraries 
> the user has, iv seen in many programs using the "./configure" and would like 
> to ask if any one has a tutorial on how to write Makefile.in files for my 
> programs so that they could be dynamically configured by ./configure 

I don't know about a tutorial, but autoconf (the tool which generates
configure scripts) has documentation in Info format ("info autoconf",
or "C-h C-i autoconf" in XEmacs).

-- 
Glynn Clements <glynn.clements@virgin.net>

A Simple question

[Jad Saklawi]

Hello guys, 
  I am new to UNIX programing, i know how to write make files 
any how i would like to write dynamic make files depending on the libraries 
the user has, iv seen in many programs using the "./configure" and would like 
to ask if any one has a tutorial on how to write Makefile.in files for my 
programs so that they could be dynamically configured by ./configure 
 
Thanks for your help, Greets Jad 

Re: A simple question

[David Love]

ed Wang wrote:
> I saw a lot of function define as _inline_ in Linux
> kernel.  What does the term _inline_  mean?  For the
> assembly inline statement, _asm_ should do the work.
> 
> Thanks for the help!
> 
> Ed 
> 


Feel free to correct me if I'm wrong...

 From my understanding, inline has asolutely nothing to do with 
assembly.  When a function is declared as inline, you're basically 
telling the compiler that anytime it runs into this function being 
called, to replace that call with the body of the function (to eliminate 
the overhead of making the function call).  It's great for small, little 
operations that are done extremely often.

-D.Love

A simple question

[ed Wang]

I saw a lot of function define as _inline_ in Linux
kernel.  What does the term _inline_  mean?  For the
assembly inline statement, _asm_ should do the work.

Thanks for the help!

Ed 

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: A simple question.

[Feng Xian]

If you do a make install, it will be copied to /boot directory
automatically;-)

Alex

On Mon, 7 May 2001, Hai Xu wrote:

> Dear all,
>
> After I compile and upgrade to a newer Kernel, do I need to copy the
> System.map from /usr/src/linux/ to /boot/System-xxxx and link it to
> System.map?
>
> Thanks in advance
> Hai Xu
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
        Feng Xian
   _o)     .~.      (o_
   /\\     /V\      //\
  _\_V    // \\     V_/_
         /(   )\
          ^^-^^
           ALEX

Re: A simple question.

[Robert M. Love]

On 07 May 2001 11:29:56 -0400, Hai Xu wrote:
> After I compile and upgrade to a newer Kernel, do I need to copy the
> System.map from /usr/src/linux/ to /boot/System-xxxx and link it to
> System.map

yes, you do. but System.map is only needed to do symbol lookups, for
times like debugging.

note most distributions link /boot/System.map to the correct System.map
(in boot) on startup. if your's does not, its a simple script:

ln -sf /boot/System.map-`uname -r` /boot/System.map


-- 
Robert M. Love
rml@tech9.net
rml@ufl.edu

A simple question.

[Hai Xu]

Dear all,

After I compile and upgrade to a newer Kernel, do I need to copy the
System.map from /usr/src/linux/ to /boot/System-xxxx and link it to
System.map?

Thanks in advance
Hai Xu