 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Well, hey, why not do one an minute? Or even better, once per second?
>
> There is a point where it becomes stupid
Agreed. So it becomes a question of where you [subjectively] percieve
that point to be.
Personally, I have always had it set to update once per day, since our
supplier only releases updates once per week and I want to be able to
control exactly when all the PCs on our network will slow to a crawl for
20 minutes. I don't actually know how frequently or not Trend Micro
release them...
>> [Ooo... the thought of 50 machines all trying to hit the same server onc
>> per second over a 2 MB Internet link... that's not even funny.]
>
> Or one machine (server-type machine) hits the internet site and download the
> definition. All the other machines retrieve the definition from the local
> source.
Indeed, this would be the optimal solution.
> Do all your machines get patches straight from the internet as well?
Currently yes. Hopefully that will be rectified eventually.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The cycle goes like this:
>
> 1. Destructive virus is released.
>
> 2. It takes 72 hours for any AV companies to even notice it exists, much
> less obtain a useable sample for analysis.
>
> 3. It takes another 72 hours to analyse the virus and develop a virus
> definition for it.
>
> 4. The new definition is deployed.
>
> 5. Our server downloads and applies the definition.
>
> My point is, that's 144 hours between the virus being released and the
> virus definition being released. An extra 24 hours before the server picks
> up the new definition seems quite trivial by conparison. The virus has
> already had plenty of time to wreck your entire network, long before the
> AV vendor has anything to offer you...
Probably not, as I doubt the person who released the virus aimed it straight
at your network. Likely it took several days to build up worldwide before
it got into your network somehow.
> [Ooo... the thought of 50 machines all trying to hit the same server onc
> per second over a 2 MB Internet link... that's not even funny.]
Try having just one machine check and download the updates, then deal them
out to everyone on your network. That's how we do it here, as you say,
seems kinda stupid to have all your machines all downloading the same
software from the same place the whole time, especially with a limited
network link.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> My point is, that's 144 hours between the virus being released and the
>> virus definition being released. An extra 24 hours before the server
>> picks up the new definition seems quite trivial by conparison. The
>> virus has already had plenty of time to wreck your entire network,
>> long before the AV vendor has anything to offer you...
>
> Probably not, as I doubt the person who released the virus aimed it
> straight at your network. Likely it took several days to build up
> worldwide before it got into your network somehow.
Maybe you'll be unlucky. Most likely you won't. Either way, shaving 4
hours off the window of opportunity seems a little moot when the window
is theoretically hundreds of hours wide to start with, that's all.
>> [Ooo... the thought of 50 machines all trying to hit the same server
>> onc per second over a 2 MB Internet link... that's not even funny.]
>
> Try having just one machine check and download the updates, then deal
> them out to everyone on your network. That's how we do it here, as you
> say, seems kinda stupid to have all your machines all downloading the
> same software from the same place the whole time, especially with a
> limited network link.
Yes, our current solution does that, and hopefully the new software will
eventually be configured that way too. (It requires updating a server to
a newer version of Windows.)
As I said to Gail, our current AV solution tries to update once per day,
which is 7x more often than the actual update release frequency. Seems
fine to me. I don't know how often (if at all) our new provider releases
these things...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail Shaw nous apporta ses lumieres en ce 2008/01/08 10:57:
> "Invisible" <voi### [at] dev null> wrote in message
> news:47839baf$1@news.povray.org...
>
>> Well, hey, why not do one an minute? Or even better, once per second?
>
> There is a point where it becomes stupid
>
>> [Ooo... the thought of 50 machines all trying to hit the same server onc
>> per second over a 2 MB Internet link... that's not even funny.]
>
> Or one machine (server-type machine) hits the internet site and download the
> definition. All the other machines retrieve the definition from the local
> source.
>
> Do all your machines get patches straight from the internet as well?
>
>
Make that 50 servers from 50 corporations accessing your server every second or
so...
--
Alain
-------------------------------------------------
If That Phone Was Up Your Butt, Maybe You Could Drive A Little Better!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> [Ooo... the thought of 50 machines all trying to hit the same server onc
> per second over a 2 MB Internet link... that's not even funny.]
What? You *aren't* using a proxy so that the updates are only downloaded
once from the AV site and then transferred only via LAN??
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Maybe you'll be unlucky. Most likely you won't. Either way, shaving 4
> hours off the window of opportunity seems a little moot when the window
> is theoretically hundreds of hours wide to start with, that's all.
>
Do you think the same about deadlines? "We won't make it in time anyway,
so why even try?" Or the opposite: "We have plenty of time, so even
though we have an (easy) way to take 4 hours less, why bother?":
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I think at least some unix networked file systems support something
> similar to this. Typically if you list the contents of /home you will only
> see your own home directory and nobody else's. If you explicitly 'cd' to
> someone else's home directory (if it's allowed) it will appear under /home.
Yes. How I saw it done, however, required the configuration to be on
each client machine, rather than being maintained strictly at the
server. Maybe it's similar in Windows, too, tho.
Given the flexibility of UNIX in general and Linux in particular, tho,
I'm sure any problems could be worked around without much difficulty,
for some size company. For example, I can't imagine Google has to do
anything to bring up a new machine beyond booting a particular CD or
something. :-)
>> And, for example, Windows allows
>> some home directories to be mounted locally, others to be mounted
>> remotely on a variety of file servers, and there has to be some
>> mechanism to tell the "client" machine which is where.
>
> I don't know enough about file systems to be sure, but I would be
> surprised if this wasn't supported by any unix networked file system.
I think it's more just a question of how complex a configuration you can
specify, and not something to do with the file system as such. (Unless
you want to have multiple home directories mounted at once, in the same
directory, from different servers, of course.)
The main difference, I think, is that since you can't easily do
something that isn't built in to Windows, Microsoft puts more options in
obvious places in Windows than any given distribution of UNIX-like
systems does. But since Linux (et al) is more open, it's probably easier
to make it work *exactly* like you want it to. (And I think this
analysis applies to many, many aspects of those systems, too.)
BOCTAOE.
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Given the flexibility of UNIX in general and Linux in particular, tho,
> I'm sure any problems could be worked around without much difficulty,
*Everything* in Unix is a file. Unix *is* a file manager OS. Anything
you can imagine you could do with files and directories, is possible
in unix, if by nothing else, by a little programming.
I hear it's not even that hard to create your own file system driver
in unix (or at least linux). A friend of mine has written one which can
be used to create and mount compressed read-only file systems (with awesome
compression ratios).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott nous apporta ses lumieres en ce 2008/01/08 11:09:
>> The cycle goes like this:
>>
>> 1. Destructive virus is released.
>>
>> 2. It takes 72 hours for any AV companies to even notice it exists,
>> much less obtain a useable sample for analysis.
>>
>> 3. It takes another 72 hours to analyse the virus and develop a virus
>> definition for it.
>>
>> 4. The new definition is deployed.
>>
>> 5. Our server downloads and applies the definition.
>>
>> My point is, that's 144 hours between the virus being released and the
>> virus definition being released. An extra 24 hours before the server
>> picks up the new definition seems quite trivial by conparison. The
>> virus has already had plenty of time to wreck your entire network,
>> long before the AV vendor has anything to offer you...
>
> Probably not, as I doubt the person who released the virus aimed it
> straight at your network. Likely it took several days to build up
> worldwide before it got into your network somehow.
>
The worst virus out there are made to target one or only a few companies. They
are made to remain under the AV radars by limiting ther diffusion.
Very slow propagation to keep a minimal network impact. Very few machines
infected every day or weeks, with a relatively low stop therhold. But, as they
target juicy targets, the payof can be prety impressive.
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you downloaded and printed the
Renderman Interface documentation, so you'd have a little light reading to take
on holiday.
Alex McLeod a.k.a. Giant Robot Messiah
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Given the flexibility of UNIX in general and Linux in particular, tho,
>> I'm sure any problems could be worked around without much difficulty,
>
> *Everything* in Unix is a file.
I'm not sure what you're trying to express here. I meant that in the
UNIX setups I've seen with distributed sharing of home directories off a
central server, there's a bunch of information that has to be configured
at each client to make it work. I.e., if I want to log in with my home
directory on *this* client machine, I have to configure *this* client
machine to know where *my* directory is, rather than just point the
entire machine at the right server.
And what I was trying to express is "that's a pretty small problem to
solve in UNIX, if it bothers you."
For all I know, it's already been solved.
> Unix *is* a file manager OS. Anything
> you can imagine you could do with files and directories, is possible
> in unix, if by nothing else, by a little programming.
Not quite, but pretty close, ya. Not quite everything is a file, or you
wouldn't need other system calls. :-) The Amiga actually came much
closer to making everything a file than UNIX ever did.
> I hear it's not even that hard to create your own file system driver
> in unix (or at least linux).
Nor is it in Windows. Not sure what the point is.
(I already agreed it's not much of a problem. It's just one I've never
seen solved in a general way in UNIX. Maybe it is. :-)
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
