On Tue, May 28, 2002 at 08:19:27PM +0200, Tom Beer wrote:
> reffering to the mentioned Advisories I would like to know what
> the latest stable version of Amanda is, that is not affected.
> I thought that 2.4.2p2 is the latest, as mentioned a week or
> so ago on this list. Below, only 2.3.0.4 is m
On Mon, May 27, 2002 at 12:03:48PM -0400, John Cartwright wrote:
> I'm sure I'm not alone in my request for clarification regarding the
> recent BugTraq announcements... are we to expect a stable release with
> these fixes soon?
Or, (having re-read the advisory), what I *s
Hi
I'm sure I'm not alone in my request for clarification regarding the
recent BugTraq announcements... are we to expect a stable release with
these fixes soon?
Thanks
- John
On Tue, Jul 17, 2001 at 12:49:49PM -0500, John R. Jackson wrote:
> * Did you set the TAPE environment variable before doing the rewind
> and fsf commands? If so, what to? For instance, if it's set to
> a rewinding device name (e.g. /dev/rmt/0b), the fsf would advance
> out several
Hi
After completing the first dump cycle, I thought it was time to test Amanda,
to make sure that I could restore in case of emergency. It's a good thing
that I did. amrecover comes out with 'UNKNOWN file' whenever I try to
restore anything. I read the docs and tried to read the headers, and go
Hi
Further to my original 'Completely Stuck :-(' postings, (with major thanks to Nate
Haugo <[EMAIL PROTECTED]>), I have found what I believe to be the problem. Trussing
the inetd binary and attempting to connect to the amanda service reveals the following
error:
auditsys(36, 0xFFBEF4A0)
> OK, here's the next idea. Instead of running a script, run truss
> directly by changing the inetd.conf line to this:
>
> amanda dgram udp waitbackup /bin/truss amandad
>-fo /tmp/amandad.truss /opt/amanda/libexec/amandad
>
Hi
This didn't work. In fact, on further invest
>> bash-2.03# lsof -i | grep am
>> inetd 19686 root 11u IPv4 0xe1dfac2c0t0 UDP *:amanda (Idle)
>
> See, it's not (LISTEN), which means inetd has disabled the service
> because of a previous failure. kill -HUP it and see if the state
> changes.
I hate to disagree with you, but in my
Hi
> This says, as you sort of suspected, that inetd is not able to run
> amandad for some reason. It is, however listening on the port and so
> forth, so that part's configured properly.
Just to be sure:
bash-2.03# lsof -i | grep am
inetd 19686 root 11u IPv4 0xe1dfac2c0t0 UDP *:
Hi
Thanks to Paul and Martin for the advice, although it didn't solve the problem!
I thought the indexing services were optional, anyway?
- John
Hi
I'm hoping someone can shed some light on this one, basically I'm
convinced amandad never runs from inetd, and I"ve spent days on this
so far :-(
I'm trying to install Amanda on a Solaris 8 x86 box, where the client
and server are one and the same. Installation options were --with-
user=a
11 matches
Mail list logo
