peterr at gasullivan.com
Wed Nov 7 12:31:26 GMT 2001
This is a so called private Ip range, class C to be precise. These ip
addresses are free for use in an internal netwerk and are non routable
www.learnhowtosubnet.com will help you out more.
Network Support Specialist
peterr at gasullivan.com
tel 0 (31)- (0) -73-6223213
MCP , MCSE 2000 + S
There is no such thing as a perpetually secure solution. There is no
such thing as an "install and forget" web application; not when security
is a goal.
Auto-updaters and the like may help, but they will not take the place of
a policy of management, audit, and continued education.
From: Pieter-Bas IJdens [mailto:pbijdens at emea.mi4.org.uk]
Sent: woensdag 7 november 2001 12:34
To: dshield at dshield.org
Subject: Re: [Dshield] DShield.py
<< File: atomic.c >> > > You could try hard linking the file, instead
of copying it.
> Isn't 'cp' supposed to be atomic? Or is only 'mv' safe?
The problem here is that there are updates taking place between the 'cp'
the old log file, and the rotation. In these cases, using hard linking
allows you to fill the time-gap between the copy and the unlink action
the old log file. Atomicity of cp plays no role here.
Hint: This is also very useful when backing up database files that get
replaced after a checkpoint has been sucessfully made to a shadow file.
you hard link the original first, then even if the file gets unlinked
replaced during the backup, you still consistently back up the old data
backing up the linked file instead.
All you do know with cp is that you never get trash (random data). But
that's just because the order of the cached write and the file length
is done correctly in the filesystem implementations. Atomicity is not
specified in the manual, nor in the info pages, so I would never assume
is atomic in any way.
The 'mv', 'rm' and 'ln' commands are safe because they don't have any
on the file data. I tested a cross-filesystem move on linux 2.4.12 while
writing a 32MB file and the md5sum says mv is not atomic for the
On the local fileysstem the results were always identical. Note that the
readback by the writing process detectes no anomalies ever. This is
while the file is open it always operates on the local data, regardless
what you do with the file [even if you unlink it]. You should maybe play
with this yourself. Please find attached the code I used to perform
quick experiments. That and two shell windows suffice to re-create them.
More information about the list