port 1024 is not secure
Hi, i have a problem with my clients. I will test my tape server, the client is installed on the server. I*%ve found the error on the FAQ*%s site and i*%ve done all steps, but the error repeating all the time. What can i do??? I have changed the rights and owner of all amanda programs in the directories /usr/local/libexec and in /usr/local/sbin. Thank you for your answers Roshan
Re: missing result in amanda 2.4.2
Here's what's in sendsize.debug: sendsize: debug 1 pid 3614 ruid 11 euid 11 start time Mon Nov 27 23:11:42 2000 /usr/lib/amanda/sendsize: version 2.4.1p1 amandad.debug is pretty long, but also has references to 2.4.1p1. I guess the old one isn't gone. I'll try removing it "better", and then recompiling. Thanks, Dylan - Original Message - From: "John R. Jackson" [EMAIL PROTECTED] To: "Dylan Casey" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 28, 2000 12:36 AM Subject: Re: missing result in amanda 2.4.2 ... So, I downloaded 2.4.2, and after some stuggling with the configure command, got it setup. amcheck runs fine, but now _none_ of the disks get backed up! Here are the errors: ... What's in /tmp/amanda/sendsize*debug and amandad*debug on ettin? Dylan Casey John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
RE: Amanda.conf problems
Title: RE: Amanda.conf problems If I understand what you're doing, you never re-use a tape that you've made a full backup on, right? It also appears that you're using only one configuration to do all of your backups. If that is the case, and you want to use a new tape each Friday, the command you're looking for is `amadmin YOURCONFIG no-reuse YOURTAPE`, where YOURCONFIG is the name of your AMANDA configuration, and YOURTAPE is the name of the tape you used on Friday, and will not re-use. This will tell AMANDA that it should no longer consider that tape as part of your active tape rotation, and you will be able to use a new tape instead of your Monday tape. BTW, if you ever choose to recycle that tape, you can undo the 'no-reuse' option with 'reuse'. If this is not what you're trying to do, please post more details to the list and we'll take another swipe at it. -Original Message- From: Philippe Dogliani [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 28, 2000 8:03 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Amanda.conf problems Hello, Well I am going to try to explain my problem: On my sytem amanda is performing incremental backup every monday, tuesday, wednesday and thursday nights and a full backup is done every friday nights. I got a pool of 16 tapes (4 weeks) for the incremental and every friday morning I put a new tape for the full backup. My problem is that since several weeks, every friday it asks me for the monday night tape instead of a new one by changing in amanda.conf runspercycle 16 to runspercycle 20 and tapecycle 16 to tapecycle 20, it is ok But then on monday morning it ask me for a new tape instead of the monday night tape, by changing again runspercycle 20 to runspercycle 16 and tapecycle 20 to tapecycle 16 it is ok but the on the next friday the problem happens again... I don't know why Does someone can help me on that Thanks a lot Best regards Philippe -- -- -- Philippe Dogliani -- -- Mentor Graphics c/o CICA, -- -- 2229, route des cretes -- -- Sophia Antipolis, 06560 Valbonne, France -- -- Tel: (+33) 4 92 94 24 05 -- -- Fax: (+33) 4 92 94 24 61 -- -- http://www.inventra.com -- --
re: port 1024 is not secure
The command i use is: amcheck -c conf The out put: Amanda Backup Client Hosts Check ERROR: amanda1: [host amanda1.popken.de: port 1024 not secure] Client check: 1 host checked in 0.037 seconds, 1 problem found. I use the version Amanda 2.4.1p1. Thank you for your answers Roshan
bug ( fix): fsekk arg type mismatch
Bug:
The function fseek() should be given a long as a second
argument (see ANSI standard). Here a off_t was used.
They are not the same on all platforms.
OSes/Compiler:
These fixes were needed to make Amanda 2.4.1p1 compile
on one of the platforms (below). These changes were
carried forward to 2.4.2. I am not sure which platform
required this change, but this same code was subsequently
used to compile successfully on:
Solaris 2.4 gcc
Solaris 2.5.1 gcc
Solaris 2.6 gcc
Solaris 8 cc
AIX4.2.1cc
AIX4.3.3cc
FreeBSD3.x cc
HP-UX9.05 cc
HP-UX10.02 cc
Linux2.2gcc
Unixware2.1 cc
Hardware:
Irrelevant, but Exabyte 230D.
Index: client-src/sendsize.c
===
RCS file: /u/itsrc/cvs/backup/amanda/client-src/sendsize.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -u -r1.1.1.2 -r1.1.1.2.2.1
--- sendsize.c 2000/11/27 21:24:55 1.1.1.2
+++ sendsize.c 2000/11/27 22:13:05 1.1.1.2.2.1
@@ -479,7 +479,7 @@
amflock(1, "size");
- fseek(stdout, (off_t)0, SEEK_SET);
+ fseek(stdout, (long)0, SEEK_SET);
printf("%s %d SIZE %ld\n", est-amname, level, size);
fflush(stdout);
@@ -504,7 +504,7 @@
amflock(1, "size");
- fseek(stdout, (off_t)0, SEEK_SET);
+ fseek(stdout, (long)0, SEEK_SET);
printf("%s %d SIZE %ld\n", est-amname, level, size);
fflush(stdout);
@@ -531,7 +531,7 @@
amflock(1, "size");
- fseek(stdout, (off_t)0, SEEK_SET);
+ fseek(stdout, (long)0, SEEK_SET);
printf("%s %d SIZE %ld\n", est-amname, level, size);
fflush(stdout);
bug ( fix): networking functions length arg type mismatch
Bug:
Some networking functions take a pointer to a length.
These are supposed to be size_t, not int.
OSes/Compiler:
These fixes were needed to make Amanda 2.4.1p1 compile
on one of the platforms (below). These changes were
carried forward to 2.4.2. I am not sure which platform
required this change, but this same code was subsequently
used to compile successfully on:
Solaris 2.4 gcc
Solaris 2.5.1 gcc
Solaris 2.6 gcc
Solaris 8 cc
AIX4.2.1cc
AIX4.3.3cc
FreeBSD3.x cc
HP-UX9.05 cc
HP-UX10.02 cc
Linux2.2gcc
Unixware2.1 cc
Hardware:
Irrelevant, but Exabyte 230D.
Index: restore-src/amidxtaped.c
===
RCS file: /u/itsrc/cvs/backup/amanda/restore-src/amidxtaped.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -u -r1.1.1.2 -r1.1.1.2.2.1
--- amidxtaped.c2000/11/27 21:25:32 1.1.1.2
+++ amidxtaped.c2000/11/27 22:11:22 1.1.1.2.2.1
@@ -97,6 +97,7 @@
char **amrestore_args;
char *buf = NULL;
int i;
+size_t addrlen;
char *amrestore_path;
pid_t pid;
int isafile;
@@ -166,8 +167,8 @@
}
#endif
-i = sizeof (addr);
-if (getpeername(0, (struct sockaddr *)addr, i) == -1)
+addrlen = sizeof (addr);
+if (getpeername(0, (struct sockaddr *)addr, addrlen) == -1)
error("getpeername: %s", strerror(errno));
if (addr.sin_family != AF_INET || ntohs(addr.sin_port) == 20) {
error("connection rejected from %s family %d port %d",
Index: common-src/dgram.c
===
RCS file: /u/itsrc/cvs/backup/amanda/common-src/dgram.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -u -r1.1.1.2 -r1.1.1.2.2.1
--- dgram.c 2000/11/27 21:24:38 1.1.1.2
+++ dgram.c 2000/11/27 22:11:20 1.1.1.2.2.1
@@ -49,7 +49,8 @@
dgram_t *dgram;
int *portp;
{
-int s, len;
+int s;
+size_t len;
struct sockaddr_in name;
if((s = socket(AF_INET, SOCK_DGRAM, 0)) == -1)
@@ -158,7 +159,8 @@
{
fd_set ready;
struct timeval to;
-int size, addrlen, sock;
+int size, sock;
+size_t addrlen;
sock = dgram-socket;
Index: common-src/stream.c
===
RCS file: /u/itsrc/cvs/backup/amanda/common-src/stream.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -u -r1.1.1.2 -r1.1.1.2.2.1
--- stream.c2000/11/27 21:24:45 1.1.1.2
+++ stream.c2000/11/27 22:11:21 1.1.1.2.2.1
@@ -41,7 +41,8 @@
int *portp;
int sendsize, recvsize;
{
-int server_socket, len;
+int server_socket;
+size_t len;
#ifdef SO_KEEPALIVE
int on = 1;
int r;
@@ -211,7 +212,7 @@
/* don't care about these values */
static struct sockaddr_in addr;
-static int addrlen;
+static size_t addrlen;
int stream_accept(server_socket, timeout, sendsize, recvsize)
int server_socket, timeout, sendsize, recvsize;
Re: Problems with amanda and Red-Hat 7.0
"John R. Jackson" wrote:
Which it would be because it's UDP and telnet is TCP.
... (and it's the same with ports 10081 and 10082) ... which is the
reason why I guess selfcheck fails ... but I couldn't figure out why the
connection is refused given that there is no filter in the configuration
files!!
Maybe because xinetd isn't even listening?
Hi,
in order to test you guess I modified the amanda file in the
/etc/xinetd.d directory as follows :
service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= operator
group = disk
#server = /usr/lib/amanda/amandad
server = /tmp/tmpamanda
disable = no
}
and /tmp/tmpamanda is :
#!/bin/sh
echo "$(date): GOTCHA!!!" /tmp/amandalog
exit 0
with the following permissions :
-rwxr-xr-x1 operator disk 81 Nov 28 10:57 tmpamanda
Then I ran "amcheck DailySet1" the result was that no
/tmp/amandalog was produced ... so I think your guess is right and
xinetd is not listening on the amandad port.
netstat -a | grep amanda gives the following result :
tcp0 0 *:amandaidx *:*
LISTEN
udp0 0 *:amanda*:*
... so your guess was apparently right!! The problem now is ... how can
I make xinetd listen on the amandad port
Thanks in advance.
Bye, Antonino Casile
Re: Completely Stuck :-(
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 *:amanda (Idle) inetd 19686 root 12u IPv4 0xe26790ec0t0 TCP *:amandaidx (LISTEN) inetd 19686 root 13u IPv4 0xe1c0161c0t0 TCP *:amidxtape (LISTEN) When you ran amandad as user amanda, did you give it the full path as in the inetd.conf line? Something like: su amanda -c /opt/local/libexec/amandad And I assume it sat there for 30 seconds then dropped away? Yeah, works fine The script will run amandad but redirect stdout/stderr to another /tmp file. See if they have anything interesting to say. The script won't run from inetd either! It's like some sort of wierd permission problem, except 'root' and 'amanda' can both execute amandad manually. Any ideas? Obviously I'm not getting any debug info at all. I can't think of a reason why inetd would fail in this way ... Thanks - John
Why is it just sitting here?
I started a backup last night, manually running 'amdump DailySet1'. Now this
morning, amstatus reports that it is all done, except for one thing (the other
lines say "finished"):
navajo.hq.consys.com://vekol/data0 2715147k dumping to tape
The tape drive doesn't seem to be doing anything, usually the little green light
flashes when it's active. Right now it's just sitting there. The holding disk
just has an empty subdirectory in it. It seems to be stuck somehow. The hard
disk that //vekol/data is on isn't even being accessed, it's quiet (makes lots
of noise when it's being backed up).
Why is this one trying to dump directly to tape, instead of to the holding disk
first?
Why would it stall out like it seems to have done?
If it is actually stuck, I suppose I can kill the amdump process with a ctrl-C
command, but then a flush wouldn't do anything, because this data isn't on the
holding disk, right? I would have to do an amcleanup. And I wouldn't get the
emailed report, either, would I?
Is there any way of gracefully regaining control without just killing amdump?
Following is information for you experts out there who might have ideas. Thanks
in advance for any and all advice!
--- Eric Wadsworth
[EMAIL PROTECTED]
My holding disk has sixty gigabytes of available space (that's not a typo).
The tape can hold 20 gigs (40 compressed).
Information on this particular samba share:
This happens to be a directory on my own NT workstation. The 'data' samba share
is 7.2 Gigs in size, but some portions of this share have their permissions set
such that the backup operators cannot read them (security policy requires that a
particular project not be included in the backup) leaving about 5 gigs of data
to back up. I'm using compression, so the 2.7 gig number makes sense. Several
other NT boxes have similiar exclusions, and they backed up fine.
Here's the summary from amstatus. (Ignore the 2 failed entries, the user of that
NT box did a "shutdown" instead of logging out. Silly users.)
SUMMARY part real estimated
size size
partition : 39
estimated : 37 14376628k
failed : 2 0k
wait for dumping: 0 0k
dumping to tape : 12715147k
dumping : 00k0k
dumped : 36 12531488k 11661481k
wait for writing: 00k0k
writing to tape : 00k0k
failed to tape : 00k0k
taped : 36 12531488k 11661481k
3 dumpers idle : not-idle
taper writing, tapeq: 0
network free kps: 1970
holding space : 53545924
Here's the pertinent line from disklist:
navajo.hq.consys.com //vekol/deneb css-nt-workstations
Here's some lines from amanda.conf:
define dumptype css-global {
comment "CSS Global definitions"
index yes
program "GNUTAR"
}
define dumptype css-nt-workstations {
css-global
comment "User's Windows NT workstations"
priority medium
compress client best
}
Re: Why is it just sitting here?
Mine did this. It turned out the filesystem being dumped was just a little bigger
than my dump disk had free. What it turns out was happeneing is I was doing
Server compression so it was sending the filesystem to my server to compress
and it was then being written to tape directly. It wasn't streaming fast enough
for me to see without sitting for quite a while and watching the drive. I
litterally
had to cancel that nights backups and I let it run out of curiosity.
It finished and then the level 1 the next night ran great.
Do an "mt status -f /dev/tapedev". It will tell you if the device is locked or
busy.
Eric Wadsworth wrote:
I started a backup last night, manually running 'amdump DailySet1'. Now this
morning, amstatus reports that it is all done, except for one thing (the other
lines say "finished"):
navajo.hq.consys.com://vekol/data0 2715147k dumping to tape
The tape drive doesn't seem to be doing anything, usually the little green light
flashes when it's active. Right now it's just sitting there. The holding disk
just has an empty subdirectory in it. It seems to be stuck somehow. The hard
disk that //vekol/data is on isn't even being accessed, it's quiet (makes lots
of noise when it's being backed up).
Why is this one trying to dump directly to tape, instead of to the holding disk
first?
Why would it stall out like it seems to have done?
If it is actually stuck, I suppose I can kill the amdump process with a ctrl-C
command, but then a flush wouldn't do anything, because this data isn't on the
holding disk, right? I would have to do an amcleanup. And I wouldn't get the
emailed report, either, would I?
Is there any way of gracefully regaining control without just killing amdump?
Following is information for you experts out there who might have ideas. Thanks
in advance for any and all advice!
--- Eric Wadsworth
[EMAIL PROTECTED]
My holding disk has sixty gigabytes of available space (that's not a typo).
The tape can hold 20 gigs (40 compressed).
Information on this particular samba share:
This happens to be a directory on my own NT workstation. The 'data' samba share
is 7.2 Gigs in size, but some portions of this share have their permissions set
such that the backup operators cannot read them (security policy requires that a
particular project not be included in the backup) leaving about 5 gigs of data
to back up. I'm using compression, so the 2.7 gig number makes sense. Several
other NT boxes have similiar exclusions, and they backed up fine.
Here's the summary from amstatus. (Ignore the 2 failed entries, the user of that
NT box did a "shutdown" instead of logging out. Silly users.)
SUMMARY part real estimated
size size
partition : 39
estimated : 37 14376628k
failed : 2 0k
wait for dumping: 0 0k
dumping to tape : 12715147k
dumping : 00k0k
dumped : 36 12531488k 11661481k
wait for writing: 00k0k
writing to tape : 00k0k
failed to tape : 00k0k
taped : 36 12531488k 11661481k
3 dumpers idle : not-idle
taper writing, tapeq: 0
network free kps: 1970
holding space : 53545924
Here's the pertinent line from disklist:
navajo.hq.consys.com //vekol/deneb css-nt-workstations
Here's some lines from amanda.conf:
define dumptype css-global {
comment "CSS Global definitions"
index yes
program "GNUTAR"
}
define dumptype css-nt-workstations {
css-global
comment "User's Windows NT workstations"
priority medium
compress client best
}
--
:wq!
---
Robert L. Harris| Micros~1 :
Unix System Administrator |For when quality, reliability
at Agency.com | and security just aren't
\_ that important!
DISCLAIMER:
These are MY OPINIONS ALONE. I speak for no-one else.
FYI:
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
Re: Help regarding compiling.
i=B4m putting up amanda on another machine but always = when i do make soon inthe proccess i always get an error messages ... debug.c:45: initializer element is not constant debug.c: In function `debug_open': debug.c:83: `CLIENT_LOGIN' undeclared (first use in this function) ... I'm not sure what is causing this, but I also don't know how you set up your build. So I'd suggest you do a "make distclean", then run "./configure ..." again and then try the "make all" again. If it still does not work, please post the ./configure line you used and whether you have a config.local and what's in it. @ Gustav Helgi Haraldsson @=20 John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] P.S. Please turn off the "send as HTML, too" option in your mailer. It's just annoying and a waste of bandwidth.
Re: missing result in amanda 2.4.2
Hi, Thanks for the help. I removed 2.4.1p1 and installed 2.4.2 again. I had to do a couple of tries on the configuring, but eventually got it to work. The last problem was finding out that I had to put in the amandates file. Once I did that, everthing worked just fine with gnu tar (dump still doesn't work with the big disk). Thanks again, Dylan - Dylan P. Casey email:[EMAIL PROTECTED] Michigan State University office:517-432-0216 home:810-695-8615 On Tue, 28 Nov 2000, John R. Jackson wrote: ... So, I downloaded 2.4.2, and after some stuggling with the configure command, got it setup. amcheck runs fine, but now _none_ of the disks get backed up! Here are the errors: ... What's in /tmp/amanda/sendsize*debug and amandad*debug on ettin? Dylan Casey John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing result in amanda 2.4.2
Once I did that, everthing worked just fine with gnu tar ... Glad to hear it. (dump still doesn't work with the big disk). What do you mean? If you're using Linux, make sure you get the latest version of dump from SourceForge. It's maintanence was nil for a long time and it had serious problems, which have recently (months) become vastly improved. Dylan John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Where/how should bugs be reported?
I reported some bugs via sourceforge. That was a mistake. I tried again via email to this mailing list. These were replied to with an address of [EMAIL PROTECTED] So, where should bugs be reported? Any special format? Anything special I should do with context diffs if I have the fix? -- Gary Algier, WB2FWZ [EMAIL PROTECTED] +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033 This space intentionally left blank by the censors.
RE: dump question...
Title: RE: dump question... I thought I saw the 'fill the tape' explanation in the docs somewhere, I will go perusing. Your explanation is consistent with the behavior I see on my backups, though. -Original Message- From: Jens Bech Madsen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 28, 2000 10:21 AM To: amanda user Subject: Re: dump question... Bort, Paul [EMAIL PROTECTED] writes: Each tape contains a mixture of full and incremental backups. AMANDA picks the levels of backup for each disk by trying to fit as much data on tape after all of the required full backups are done. This minimizes tape hunting when you need to restore a file and also makes your backup runs a little more predictable in duration. It fits as much as possible to a tape? My experience is that it tries to make the backups equally big each time so the duration is predictable. My tapes certainly aren't filled every day. /Jens -- Jens Bech Madsen The Stibo Group, Denmark
Re: GNU tar estimates for vfat filesystems (Was: How do I checklevel 1 sizes?)
Conrad Hughes wrote: * If I understand correctly (and there's no guarantee that I do), the vfat change was to ensure that a file on a vfat FS would have the same inode number for the duration of a single mount; inodes need to be constructed in some manner on vfat because it doesn't actually have real inodes, and the previous mechanism meant that a file's inode wouldn't be constant (for example a rename would change it; this caused much gnashing of teeth among one crowd of people). This new mechanism means inodes are fixed for the duration of a mount, but if you umount and remount then you have no guarantee of continuity; this is now causing gnashing of teeth amoung another crowd. Since tar --listed-incremental seems to record inodes, it gets very confused if the machine umounts and mounts a vfat system between backups (as would inevitably be the case if you rebooted for example). I had the same problem, since I reboot my machine at least once day, i.e. between backup runs. So my solution was to avoid the use of tar with the "--listed-incremental=FILE" option and using "--incremental" instead. To achieve this I had to change the file config/config.h near line 628, undefining GNUTAR_LISTED_INCREMENTAL_DIR as shown below and recompile. #ifdef GNUTAR /* Used in sendbackup-gnutar.c */ /*#define GNUTAR_LISTED_INCREMENTAL_DIR "/usr/local/var/amanda/gnutar-lists"*/ #undef GNUTAR_LISTED_INCREMENTAL_DIR /* #undef ENABLE_GNUTAR_ATIME_PRESERVE */ #endif Backing up VFAT-partitions now works fine. On the other side however Linux-Directories with changes may use more backup-space. Cheers -- +---+ | Andreas Herren E-mail: [EMAIL PROTECTED] | +---+
Re: amrecover
On Nov 28, 2000, brian [EMAIL PROTECTED] wrote:
but once the process is finished, i get back the the amrecover
prompt, and i cannot find the stuff i wanted to be restored.
Note that stuff will be restored into a directory tree that mirrors
the tree of the backed up filesystem. So, if you restore bar/baz that
was originally in /foo, where /foo is the root of a filesystem (or a
subdirectory of / listed in the disklist), amrecover will get you
`bar/baz, not just `baz.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Amanda.conf problems
On Nov 28, 2000, Philippe Dogliani [EMAIL PROTECTED] wrote:
I got a pool of 16 tapes (4 weeks) for the incremental
and every friday morning I put a new tape for the full backup.
My problem is that since several weeks, every friday
it asks me for the monday night tape instead of a new one
We still haven't introduced psychic powers in Amanda, so it doesn't
know you want to feed it a new tape instead of the next one in the
cycle. However, it always says it will accept that tape or a new one,
so just ignore its advice.
by changing in amanda.conf runspercycle 16 to runspercycle 20
runspercycle is number of runs per *dump* cycle, not *tape* cycle, so
don't mess up with it. Since you have only one run with full backups,
it might be wise to have it set to 1, assuming you use some trick for
Amanda to only run incrementals on the other days.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Why is it just sitting here?
On Nov 28, 2000, Eric Wadsworth [EMAIL PROTECTED] wrote:
The mystery still exists, why is it writing directly to tape instead
of using the holding disk?
Look for `chunksize' in the man-page, the FAQ and/or the sample
configuration file.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
RE: dump question...
I want to offer a huge *Thanks* to Paul for writing that email. It answered a lot of my questions. Particularly, the below paragraph is useful... This is exactly what I needed to know right now! I'm about to add amdump to cron. Thanks, Paul! Eric On Tue, 28 Nov 2000, Bort, Paul wrote: Generally, once you have a list of disks you want to back up, they should be added to the disklist gradually over the course of dumpcycle backups, so that one tape doesn't have to try to hold too many level 0 backups at first. (AMANDA always starts with a level 0 for a new disk.)
Re: Why is it just sitting here?
Ah! This was it! Thanks so much! --- Eric Alexandre Oliva wrote: On Nov 28, 2000, Eric Wadsworth [EMAIL PROTECTED] wrote: The mystery still exists, why is it writing directly to tape instead of using the holding disk? Look for `chunksize' in the man-page, the FAQ and/or the sample configuration file. === Eric Wadsworthemail: [EMAIL PROTECTED] Conceptual Systems and Software http://www.consys.com ===
Re: missing result in amanda 2.4.2
I am running Linux. I have a dump 0.4b9-1 ... As I recall, that's **way** too old. ... Before I go to the work of installing it, are there good reasons to prefer dump to gnu-tar or vice versa? Oh, no. Here we go on this subject again :-). Yes, there are reasons. But for every one side A gives, side B has a counter, so it's mostly philosophical. Pick what you're comfortable with. I will throw in that GNU tar alters the last access time of every file backed up, and that's the main reason I don't use it. Dylan John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Completely Stuck :-(
Just to be sure: bash-2.03# lsof -i | grep am inetd 19686 root 11u IPv4 0xe1dfac2c0t0 UDP *:amanda (Idle) That's what my system looks like, too. To make my day and contradict Alexandre :-), lsof does not appear to report UDP ports as being in LISTEN state. So this looks OK. The script won't run from inetd either! ... 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 (adust as needed for paths and user name). This will dump the truss output in /tmp/amandad.truss. - John John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Problems with amanda and Red-Hat 7.0
and /tmp/tmpamanda is : #!/bin/sh echo "$(date): GOTCHA!!!" /tmp/amandalog That's not valid syntax. Using "$(cmd)" is ksh/bash only, not sh. Either change the #! line to run ksh or bash, or change $( to ` and ) to `, e.g.: echo "`date`: GOTCHA!!!" /tmp/amandalog so I think your guess is right and xinetd is not listening on the amandad port. netstat -a | grep amanda gives the following result : tcp0 0 *:amandaidx *:*LISTEN udp0 0 *:amanda*:* That last line says it **is** listening on the amanda port (or someone is). So xinetd appears to be more or less happy. It's something else wrong that amandad is not running. So I'll repeat one of my questions: have you gone through all of the tests in the FAQ? This problem is very common on new installations and the FAQ has at least two items specifically dealing with debugging what's wrong. Bye, Antonino Casile John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing result for...
Anyone have any ideas as to why I am getting this report back. ... localhost /var/log lev 0 FAILED [missing result for /var/log in localhost response] Does amcheck work? What's in /tmp/amanda/amandad*debug? How about sendsize*debug? Any core file in /tmp/amanda? Take a look at the amdump.1 file and see if it has anything interesting to say, especially towards the end. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
[Fwd: Problems with amanda and Red-Hat 7.0]
Hi,
So I'll repeat one of my questions: have you gone through all of the tests
in the FAQ? This problem is very common on new installations and the FAQ
has at least two items specifically dealing with debugging what's wrong.
Yes I did!!!
The problem here is xinetd ... I looked at the /var/log messages and I
got the following lines just after having run "amcheck DailySet1":
Nov 28 18:42:06 raffaello xinetd: xinetd startup succeeded
Nov 28 18:42:22 raffaello xinetd[14793]: refused connect from 128.197.61.90
From here you can see that xinetd is refusing to connect from
128.197.61.90 (which is the PC I am trying to make the amanda server run
on!!) ... the problem is that all the configuration files are ok ... at
least I think ...
My hosts.allow file is as follow :
imapd: localhost 128.197.61.90
in.telnetd: localhost 128.197.61.90 128.197.61.91 128.197.61.92
128.197.61.184 128.197.61.187 193.205.82.52
in.talkd: ALL
in.tftpd: localhost 128.197.61.90 128.197.61.91 128.197.61.92
in.fingerd: localhost 128.197.61.90 128.197.61.91 128.197.61.92
in.rlogind: localhost 128.197.61.90 128.197.61.91 128.197.61.92
in.rshd: localhost 128.197.61.90 128.197.61.91 128.197.61.92
in.ftpd: localhost 128.197.61.90 128.197.61.91 128.197.61.92
128.197.61.184 128.197.61.187
in.rexecd: localhost 128.197.61.90
rpc.cmsd: localhost 128.197.61.90
# httpd: localhost 128.197.61.91 128.197.61.92
portmap: localhost 128.197.61.90 128.197.61.91 128.197.61.92
128.197.61.95 128.197.61.96 128.197.61.97 128.197.61.184 128.197.61.187
xinetd.conf is :
defaults
{
instances = 60
log_type= SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST RECORD
}
includedir /etc/xinetd.d
and finally /etc/xinetd.d/amandad is :
service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= operator
group = disk
server = /usr/lib/amanda/amandad
disable = no
}
At this point I see no particular reason for xinetd to refuse
connections on port 10080 for the same host!!! Do you seee any??
Bye, Antonino Casile
Re: missing result for...
In addition to what you sent, I asked whether "amcheck -c config" worked and what was in /tmp/amanda/amandad*debug. It looks like sendsize is starting but never completing. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Client install
Hey John, How is installing for the clients different than for the server? That is not evident in anything I've read (README, INSTALL and the entire chapter online at www.amanda.org). Do I need to do the whole ./configure, make, make install process for each client? IT seems that's massive overkill. Randy Cordell __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: missing result in amanda 2.4.2
--- "John R. Jackson" [EMAIL PROTECTED] wrote: I am running Linux. I have a dump 0.4b9-1 ... As I recall, that's **way** too old. ... Before I go to the work of installing it, are there good reasons to prefer dump to gnu-tar or vice versa? Oh, no. Here we go on this subject again :-). Yes, there are reasons. But for every one side A gives, side B has a counter, so it's mostly philosophical. Pick what you're comfortable with. I will throw in that GNU tar alters the last access time of every file backed up, and that's the main reason I don't use it. I typed a reply, hit a key stroke and landed back in my inbox, so if this comes across twice that's why. I made note for myself that didn't include enough data for me to be able to decipher: "Tar --atime-preserve" But I do remember this keeps tar from changing the last-access time of files as it backs them up. This doesn't look like a tar option so is it an option for the configure script of AMANDA? If so does this resolve your issue with tar? I read that the amverify is much more reliable with tar than dump. That's good enough for me. Randy Cordell Dylan John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: missing result in amanda 2.4.2
On Nov 29, 2000, Randolph Cordell [EMAIL PROTECTED] wrote:
"Tar --atime-preserve" But I do remember this keeps tar from
changing the last-access time of files as it backs them up.
Which forces it to change the inode update time, that makes each file
seem out-of-date on the next run.
This doesn't look like a tar option
It is a GNU tar option.
so is it an option for the configure script of AMANDA?
Nope. You have to tweak some define in
client-src/send{size,backup-gnutar}.c for Amanda to use this option.
But you don't want to do that.
I read that the amverify is much more reliable with tar than dump.
Yep. amverify will only check a DUMP image if it was created on a
similar system as that on which you run amverify. Even then, restore
will only check the dump header. tar, OTOH, will go over the whole
tar image.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
HP-UX compiles
I fixed my own problem, added it to the FAQ-O-Matic (I hope that's OK), and humbly submit a correction for the HP-UX section of SYSTEM.NOTES. I think the first paragraph should read: You may run into an internal /bin/sh limit when running the configure script. The error message is: ./configure: sh internal 2K buffer overflow As of HP-UX 10.20, no such message is printed; instead you get an error about sed's failure to parse a pattern. The workaround is to use ksh: change the first line in the configure script from "#! /bin/sh" to "#! /usr/bin/ksh". Stephen Walton
mt status work-alike for HP-UX?
I've checked the FAQ and searched the list archives for this too: chg-manual locally fails because "status" is not a valid argument for the HP-UX 10.20 "mt" command. Is there a workaround? I'm willing to sit and change tapes for the occasional archival full backup. -- Stephen Walton, Professor of Physics and Astronomy, California State University, Northridge [EMAIL PROTECTED]
Re: [Fwd: Problems with amanda and Red-Hat 7.0]
Hi,
i assume in your hosts.deny you have something like ALL:ALL
to block every connect to ports not explicitly allowed in hosts.allow.
But in your hosts.allow i can't find a line allowing access from
128.197.61.90 to the amanda-ports.
probably it would be a good idea to include something like
ALL: 128.197.61.90
into hosts.allow to make shure all acesses from the local host
are allowed, because you shurely trust your own machine, don't you?
Christoph
Casile Antonino schrieb:
Hi,
So I'll repeat one of my questions: have you gone through all of the tests
in the FAQ? This problem is very common on new installations and the FAQ
has at least two items specifically dealing with debugging what's wrong.
Yes I did!!!
The problem here is xinetd ... I looked at the /var/log messages and I
got the following lines just after having run "amcheck DailySet1":
Nov 28 18:42:06 raffaello xinetd: xinetd startup succeeded
Nov 28 18:42:22 raffaello xinetd[14793]: refused connect from 128.197.61.90
From here you can see that xinetd is refusing to connect from
128.197.61.90 (which is the PC I am trying to make the amanda server run
on!!) ... the problem is that all the configuration files are ok ... at
least I think ...
My hosts.allow file is as follow :
imapd: localhost 128.197.61.90
in.telnetd: localhost 128.197.61.90 128.197.61.91 128.197.61.92
128.197.61.184 128.197.61.187 193.205.82.52
in.talkd: ALL
in.tftpd: localhost 128.197.61.90 128.197.61.91 128.197.61.92
in.fingerd: localhost 128.197.61.90 128.197.61.91 128.197.61.92
in.rlogind: localhost 128.197.61.90 128.197.61.91 128.197.61.92
in.rshd: localhost 128.197.61.90 128.197.61.91 128.197.61.92
in.ftpd: localhost 128.197.61.90 128.197.61.91 128.197.61.92
128.197.61.184 128.197.61.187
in.rexecd: localhost 128.197.61.90
rpc.cmsd: localhost 128.197.61.90
# httpd: localhost 128.197.61.91 128.197.61.92
portmap: localhost 128.197.61.90 128.197.61.91 128.197.61.92
128.197.61.95 128.197.61.96 128.197.61.97 128.197.61.184 128.197.61.187
xinetd.conf is :
defaults
{
instances = 60
log_type= SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST RECORD
}
includedir /etc/xinetd.d
and finally /etc/xinetd.d/amandad is :
service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= operator
group = disk
server = /usr/lib/amanda/amandad
disable = no
}
At this point I see no particular reason for xinetd to refuse
connections on port 10080 for the same host!!! Do you seee any??
Bye, Antonino Casile
Filesystem offline in cluster ENV
Here is the info from sendsize.debug ( client ) sendsize: getting size via dump for /u14 level 0 sendsize: running "/opt/amanda/libexec/rundump (/usr/sbin/ufsdump) 0Ssf 1048576 - /u14" running /opt/amanda/libexec/killpgrp DUMP: `/u14' is not on a locally mounted filesystem DUMP: The ENTIRE dump is aborted. sendbackup.debug has no errors and says index is created successfully for the other file systems. Any help is highly appreciated. Ruksana Siddiqui office: 03-9246-4848 mobile : 0419-342624 -Original Message- From: John R. Jackson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 22, 2000 5:02 AM To: Siddiqui, Ruksana Cc: [EMAIL PROTECTED] Subject: Re: Filesystem offline in cluster ENV When I'm backing a filesytem that's part of SUN cluster ENV i 'm getting the message: filessytem offline and it's not getting backed up. What does amcheck say? And please post all of the output, not a summary. What's in /tmp/amanda/sendsize*debug and sendbackup*debug on the client? Ruksana John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
