Hello again,
On Thu, 15 Mar 2012, Forrest Aldrich wrote:
> ... Why not just delete it when the build is finished?
> Then it's most unlikely to get corrupted. :)
LOL no, I'm concerned about /usr/local becoming corrupted - the binary
NFS mount that we want to use on our production systems.
Ge
On 03/14/2012 10:14 AM, Forrest Aldrich wrote:
In our case, it's all the same revision/OS (RHEL 5.x) -- we have both
32- and 64-bit to contend with, therefore 2 separate builds ...
I understand that. What I don't understand is why you don't just build
your own RPM and have your mail filter
On Wed, Mar 14, 2012 at 6:14 PM, Forrest Aldrich wrote:
>> There you go making life difficult for yourself again. Why not set up
>> your own ClamAV database mirror?
>
> I'm not sure how to do this; however, we have only about 4 or 5 machines
> that poll for virus updates. And the mirror would b
On 3/14/12 7:43 AM, G.W. Haywood wrote:
Hello again,
On Wed, 14 Mar 2012, Forrest Aldrich wrote:
What's happening is the clamav installation (make install) creates a
file *.tmp and removes it. This is why the process failed because I
mount the directory read-only on most of the systems to pr
Hello again,
On Wed, 14 Mar 2012, Forrest Aldrich wrote:
What's happening is the clamav installation (make install) creates a
file *.tmp and removes it. This is why the process failed because I
mount the directory read-only on most of the systems to prevent
corruption. This is easily resolved b
On 3/13/12 1:02 PM, Pierre Dehaen wrote:
No, I just install on a few mail filtering machines, all Solaris... and the
script is not automated:
it asks for confirmation before doing each step and it shows output of
commands, so you can
stop the script, verify, fix, etc, and restart, skip some s
[ .. ]
I do this to keep the same code available to all my systems. I have
separate mounts for 32- and 64-bit.
For something like ClamAV, I don't see the point. You seem to be
making it harder for yourself than it needs to be.
This is a matter of opinion :-) My goal is to have the code all NF
From: deha...@drever.be
> > To: clamav-users@lists.clamav.net
> > Date: Tue, 13 Mar 2012 15:32:40 +0100
> > Subject: Re: [clamav-users] Compiling and installing from an NFS mount
> >
> > Hmm, my script is a bit more complex as it:
> > - unzip & untar
> >
gt; To: clamav-users@lists.clamav.net
> Date: Tue, 13 Mar 2012 15:32:40 +0100
> Subject: Re: [clamav-users] Compiling and installing from an NFS mount
>
> Hmm, my script is a bit more complex as it:
> - unzip & untar
> - configure
> - make && make check
> - backs
Hmm, my script is a bit more complex as it:
- unzip & untar
- configure
- make && make check
- backs up the current clamav directory (who knows...)
- backs up the configuration files
- disable the clamav service (I'm running on Solaris)
- make uninstall (from the previous build directory)
- make in
Hi there,
On Tue, 13 Mar 2012, Forrest Aldrich wrote:
I've run into a quirky issue with installing ClamAV from an NFS mount.
It's what you're doing that's quirky. :)
I do this to keep the same code available to all my systems. I have
separate mounts for 32- and 64-bit.
For something like
The option I use to do these sorts of installs when I have binary compatible
systems is to do a "make" for each type, then just "make install" off the NFS
mount.
--Bryan
On Mar 12, 2012, at 5:33 PM, Forrest Aldrich wrote:
> I've run into a quirky issue with installing ClamAV from an NFS mount.
On Mon, Mar 12, 2012 at 5:33 PM, Forrest Aldrich wrote:
> Without digging into how this works, I believe I see what's going on -- but
> I wonder if there's a clever way around this. I really don't want to go
> through and change the mounts to read-write -- they are read-only for a
> reason -- o
On Mar 12, 2012, at 2:33 PM, Forrest Aldrich wrote:
> I've run into a quirky issue with installing ClamAV from an NFS mount. I do
> this to keep the same code available to all my systems. I have separate
> mounts for 32- and 64-bit.
>
> For ClamAV, the installation will fail because the NFS mo
14 matches
Mail list logo
