Re: Run as user amanda issues
On Tue, Oct 14, 2003 at 10:20:11AM -0500, Johnson, S wrote: In the amanda.conf, I've got the dump user configured as amanda. Any suggestions? A few questions: I can get amanda to run if I su amanda then run the job manually. You mean amcheck? amdump? Cron doesn't seems to want to run Amanda as root, not amanda. Where in cron is amanda run? (Usually in the crontab of the user you want it to run as. crontab -u amanda -e) -- Debating Unix flavors in the context of anything Microsoft is like talking about which ice cream flavor tastes least like sawdust with turpentine sauce. -- void
Odd disk space error message
I (re)-inserted a system into amanda's disklist and got a rather odd-looking error message. Backup host: % sudo -u backup amcheck -c sksp1 Password: Amanda Backup Client Hosts Check ERROR: curls: [dir /tmp/amanda needs 64KB, only has -2147483648KB available.] ERROR: curls: [dir /tmp/amanda needs 64KB, only has -2147483648KB available.] ERROR: curls: [dir /var/lib needs 64KB, only has -2147483648KB available.] Client check: 8 hosts checked in 10.913 seconds, 3 problems found (brought to you by Amanda 2.4.4) But on the host curls: % LC_ALL=C df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 16340380 7156816 8353512 47% / % LC_ALL=C df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 16G 6.9G 8.0G 47% / There is ample space and it does create /tmp/amanda and happily write the debug info there. I don't see what else could be wrong and at least the error should not be what (am|self)check claims it to be. Could there be an overflow in some check? I have never seen that message before (maybe since all the other systems are sanely partitioned ;). Both systems are debian on Linux on x86 with the packaged amanda. The other systems are working fine, as amcheck above says. -- It's perfectly fine to use the name of you pet or child as a password. How ever, for the sake of security, make sure the names of all your pets and children contain several non-alphanumeric characters. -- from .sig of Michael Honeyfield (unattributed)
Re: Skipped backups
On Fri, Jul 18, 2003 at 08:46:28AM -0500, Brendon Colby wrote: Last weekend, the data center operators did not put in Saturday and Sunday's tapes. Amanda still did the backup to the local disk of course. On Monday, the next tape was put in, and the backups continued on without complaint. I still have these two backups on disk though, and I'm not sure what to do with them. Do I flush them to the next tape and have them skip the rotation ahead one tape (a PITA)? What other options do I have in a situation like this? If you have the space, you could also run amdump early when there is no or wrong tape in and then when they put in the next tape, flush both the old backups and the ones that were supposed to go on that tape. Wouldn't that land the tapes in sync again? (Well, apart from one tape not getting used.) -- Dennis Ritchie: So fsck was originally called something else Question: What was it called? Dennis Ritchie: Well, the second letter was different. -- QA at Usenix
Re: Parallelized restores?
On Sat, Mar 22, 2003 at 09:24:19AM -0600, Kirk Strauser wrote: At 2003-03-22T05:03:53Z, Jon LaBadie [EMAIL PROTECTED] writes: I'm sure the amanda developers would echo the sentiment I saw on another list: Patches gratefully accepted. And conversely, patches gratefully generated if I'm not the only one who thinks this is a worthwhile idea. So, is it? Would anyone else like that functionality? It most certainly sounds like a godo thing, especially if doing full recovery or such. I can't say my life depends on it, but I think it's a good idea. -- Thou shalt not follow the Null Pointer, for at its end Madness and Chaos lie. -- From the .sig of Panu Mantyla
Re: raw device ownership permissions on SGI machine
On Tue, Mar 11, 2003 at 03:35:44PM -0800, Stephen D. Lane wrote: Greetings. I am using amanda to back up several clients, one of which is an SGI Origin workstation. This client was recently rebuilt from scratch to IRIX 6.5.19m (yesterday, as a matter of fact :), and I don't know if the following problem was present prior to the rebuild (it was at 6.5.18m, after having been upgraded from 6.5.3m). I do know that amanda was working fine. After I rebuilt the client, it had the following: 0 crw---1 root sys 0,125 Mar 11 15:26 /hw/rdisk/root As this is the device amcheck complains about when I tell it I want to back up the root partition, I made the following changes: 0 crw-rw1 amanda disk0,125 Mar 11 15:26 /hw/rdisk/root This is how it was configured before the rebuild, and amcheck is perfectly happy with this. If I reboot the machine, however, the device goes back to: 0 crw---1 root sys 0,125 Mar 11 15:26 /hw/rdisk/root Is anyone familiar with this behavior in IRIX? I am seriously contemplating a root cronjob... I believe the /hw filesystem is created on the fly like /proc or a devfs. Actually.. [EMAIL PROTECTED] uname IRIX64 [EMAIL PROTECTED] mount | grep hw /hw on /hw type hwgfs (rw) [EMAIL PROTECTED] man -k hwgfs hwgraph, hwgfs, hw (4) - hardware graph and hardware graph file system And from there, I find: Since hwgfs is a pseudo-filesystem whose files don't actually use any disk space, there is no persistent information associated with files under /hw. In particular, file attributes (mode, owner, group) are not stored across reboots under hwgfs. Rather, reasonable default are used for all hwgfs special files. These defaults can be changed in the normal ways (i.e. with chmod(1), chown(1), chgrp(1)), but the changes only last until the next time the system is rebooted. In order to supply the appearance of special file attributes that are persistent across reboots, hwgfs uses the ioconfig(1m) utility, controlled by the contents of the file /etc/ioperms. Nice to know this. I have not used amanda and dump on Irix so I haven't come across this. -- I suggest that you refrain from posting in a forum such as this one, in which you are clearly intellectually overmatched. Perhaps you should find a debating companion that more closely reflects your natural abilities, such as a rock. -- Jake, in the Monastery
Re: html reports (Was: columm widths)
On Thu, Jan 30, 2003 at 10:38:46AM -0800, Gordon Pritchard wrote: On Thu, 2003-01-30 at 09:47, Don Carlton wrote: Has anyone changed the mail report to produce html? Now, this is interesting! Currently, I'm e-mail bound, so currently when I have html reports, I used wget and sed/awk to reduce the data to an email. However, we're moving to a web-info page, which will be loaded with tons of mrtg graphs and all sorts of GUI info-at-a-glance. So, in 6 months time, amanda with html out, or snmp capability, would be cool! Well, if it was sent out to a suitable special account with html content or something clear enough that it can be parsed in html, you only need some procmail trickery to drop it into place.
Re: Backup is too slow - configuration?
On Wed, Jan 22, 2003 at 01:55:32PM -0500, Gene Heskett wrote: On Wednesday 22 January 2003 09:05, hochenaw wrote: we have an HP Surestore dlt vs80e and use hp dlt IV tapes (capacity 40/80GB) under linux. ... How can i activate software or hardware compression (cant find an entry in amanda.conf, just Client or Servers best in dumptypes-file)? Hardware depends on the os in use. Some os's have a choice of compressed or uncompressed drives in the device list and will turn the drives compression on and off according to the devicename you used to address it. Linux does not however, so one must find the switch setting on the drive itself that turns this on/off. ... Off is the generally recommended hardware setting for use with amanda because if the machines have the horsepower to do their own compressing, they can often beat the hardware compression by quite useable amounts, thereby putting more on the tape than the hardware compressor can. ... I use this in my /etc/modules.conf on Linux: post-install st mt datcomp off Which uses mt to switch off compression every time the module loader autoloads the scsi tape driver. -- Ah, young webmaster... Java leads to Shockwave. Shockwave leads to Realaudio. And Realaudio leads to suffering. -- Peter da Silva
Re: Connection to my floppy?
On Sat, Dec 14, 2002 at 07:06:11PM +0100, Thorsten Bremer wrote: when using Amanda I have this problem: with EVERY amanda-command (i.e. amcheck or amdump), first I see a connection to my floppy disk. When no disk is inserted, my console is filled with error-messages (end_request: I/O error, dev 02:00 (floppy), sector 0) and after some tries, the amanca-command started working. When using amdump, amanda do this before every new file on the holding disk, after that, he copies the data to the holding disk and started filling the tape as normal. I gave him a floppy-disk to eat (unformatted and formatted with FAT, Minix and so on), but I can see no change on the floppy-disk after that. After making a loud noise in my floppy, Amanda works perfectly :-) My question: What the hell will amanda do on my floppy? I didn't think that we really tries to store data on 1.44 MB :-)) How can I stop this behaviour. Are you running an automounter of any kind? I think amanda is just trying to determine something about the filesystem and stumbles across the automounter dirs (or links to autofs, which I use on workstations). At least that's what I thought and didn't look further into it. -- Once in Africa I lost the corkscrew and we were forced to live on food and water for weeks. -- Ernest Hemingway
Re: Fwd: Daily AMANDA PROBLEM: FIX BEFORE RUN, IF POSSIBLE
On Thu, Dec 05, 2002 at 11:28:21AM -0500, Mark Stosberg wrote: On Thu, 5 Dec 2002, O-Zone wrote: What's up ? ERROR: /dev/nst0: reading label: Input/output error (expecting tape Daily3 or a new tape) If you didn't put Daily3 in the drive, you may need to run amlabel to label the new tape. When we do it, it looks like this: su -m operator -c 'amlabel SumArch SUMARCH-43' I use and recommend sudo: sudo -u amanda amlabel foo1 foo_013 -- Validate me! Give me eternal digital life! Quote me in your .sigs! -- djc, in the Monastery
[no subject]
For a few days, things have not been going well in this backup set. I found out / (!) was full on the server and write to /tmp/amanda failed. That has been resolved now. Amcheck is ok for both -c and -s but at dump, this happens. The tape drive is DAT24 and I've successfully read and written to it with tar, dd, and amrestore. I don't really know how it could say /etc is way too big etc. It shouldn't be out of tape either. The size looks weird too. I thought I'd post this before I make a dummy config and start running more tests on it, in case anyone has ideas. All (but maybe one or two) machines are Linux (RH, Debian, RH6 server) and all are using vendor amanda's. Everything has worked smoothly for about 0.5-2 years for every machine. No changes apart from routine upgrades have been done to any of the systems lately. On Mon, Nov 18, 2002 at 09:25:42AM +0200, Amanda backup user wrote: These dumps were to tape sksp_023. *** A TAPE ERROR OCCURRED: [[writing file: No space left on device]]. Some dumps may have been left in the holding disk. Run amflush to flush them to tape. The next tape Amanda expects to use is: sksp_024. FAILURE AND STRANGE DUMP SUMMARY: powa /mnt/db lev 1 FAILED [dumps way too big, must skip incremental dumps] shaft /home lev 1 FAILED [dumps way too big, must skip incremental dumps] tunkki /etc lev 1 FAILED [dumps way too big, must skip incremental dumps] reactor/etc lev 1 FAILED [dumps way too big, must skip incremental dumps] tolppa /etc lev 1 FAILED [dumps way too big, must skip incremental dumps] palmu /etc lev 1 FAILED [dumps way too big, must skip incremental dumps] flowa /usr/local/Hughes lev 1 FAILED [dumps way too big, must skip incremental dumps] powa /etc lev 1 FAILED [dumps way too big, must skip incremental dumps] reactor/home lev 1 FAILED [dumps way too big, must skip incremental dumps] tolppa /var lev 1 FAILED [dumps way too big, must skip incremental dumps] palmu /home lev 1 FAILED [dumps way too big, must skip incremental dumps] tunkki /usr/home lev 1 FAILED [dumps way too big, must skip incremental dumps] tunkki /home lev 1 FAILED [dumps way too big, must skip incremental dumps] mail1 /home lev 1 FAILED [dumps way too big, must skip incremental dumps] powa /home lev 1 FAILED [dumps way too big, must skip incremental dumps] devil / lev 2 FAILED [dumps way too big, must skip incremental dumps] portti /etc lev 1 FAILED [dumps way too big, must skip incremental dumps] portti /home lev 1 FAILED [dumps way too big, must skip incremental dumps] powa /var lev 2 FAILED [dumps way too big, must skip incremental dumps] powa /usr/local lev 1 FAILED [dumps way too big, must skip incremental dumps] workspace /home lev 1 FAILED [dumps way too big, must skip incremental dumps] reactor/var lev 2 FAILED [dumps way too big, must skip incremental dumps] dev/home lev 2 FAILED [dumps way too big, must skip incremental dumps] portti /var lev 1 FAILED [dumps way too big, must skip incremental dumps] twinkle/var lev 1 FAILED [dumps way too big, must skip incremental dumps] devil /var lev 1 FAILED [dumps way too big, must skip incremental dumps] dev/var lev 2 FAILED [dumps way too big, must skip incremental dumps] palmu /var lev 1 FAILED [dumps way too big, must skip incremental dumps] twinkle/home lev 3 STRANGE powa /mnt/logs lev 3 STRANGE shaft /var lev 2 STRANGE flowa /home lev 0 FAILED [out of tape] flowa /home lev 0 FAILED [data write: Connection reset by peer] flowa /home lev 0 FAILED [dump to tape failed] STATISTICS: Total Full Daily Estimate Time (hrs:min)0:21 Run Time (hrs:min) 9:54 Dump Time (hrs:min)0:59 0:00 0:59 Output Size (meg) 706.90.0 706.9 Original Size (meg) 2772.80.0 2772.8 Avg Compressed Size (%)25.5--25.5 (level:#disks ...) Filesystems Dumped9 0 9 (1:2 2:4 3:3) Avg Dump Rate (k/s) 204.5-- 204.5 Tape Time (hrs:min)0:13 0:00 0:13 Tape Size (meg) 707.20.0 707.2 Tape Used (%) 6.20.06.2 (level:#disks ...) Filesystems Taped 9 0 9 (1:2 2:4 3:3) Avg Tp Write Rate (k/s) 930.1-- 930.1 FAILED AND STRANGE DUMP DETAILS: /-- twinkle/home lev 3 STRANGE sendbackup: start [twinkle:/home level 3] sendbackup: info BACKUP=/bin/tar sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end ? gtar: ./logs/access_log: file changed as we read it | Total bytes written:
Re:
On Mon, Nov 18, 2002 at 11:43:43AM +0100, Christoph Scheeder wrote: for me your amanda-report looks quite normal for the situation you're in. Amanda wrote 11,5GB of data to the tape, then ran into eot. This is a quite normal volume for 125meter/dds-3-tapes. That would be a good explanation. But where can I see the amount of data it got? The backups aren't on holding disk either, so it seems that many disks (dirs) are not getting backed up at all. The rest of the report shows amanda is completely out of sync, and it will try to get as much fulls of your disks as possible in the next runs. I think in a few days she will get back to her normal tapeusage. I'll clip the report a bit.. *** A TAPE ERROR OCCURRED: [[writing file: No space left on device]]. That does sound like out of tape. FAILURE AND STRANGE DUMP SUMMARY: powa /mnt/db lev 1 FAILED [dumps way too big, must skip incremental dumps] shaft /home lev 1 FAILED [dumps way too big, must skip incremental dumps] ... flowa /home lev 0 FAILED [out of tape] flowa /home lev 0 FAILED [data write: Connection reset by peer] flowa /home lev 0 FAILED [dump to tape failed] STATISTICS: Total Full Daily Estimate Time (hrs:min)0:21 Run Time (hrs:min) 9:54 Dump Time (hrs:min)0:59 0:00 0:59 Output Size (meg) 706.90.0 706.9 Original Size (meg) 2772.80.0 2772.8 Avg Compressed Size (%)25.5--25.5 (level:#disks ...) Filesystems Dumped9 0 9 (1:2 2:4 3:3) Avg Dump Rate (k/s) 204.5-- 204.5 Tape Time (hrs:min)0:13 0:00 0:13 Tape Size (meg) 707.20.0 707.2 Tape Used (%) 6.20.06.2 (level:#disks ...) Filesystems Taped 9 0 9 (1:2 2:4 3:3) Avg Tp Write Rate (k/s) 930.1-- 930.1 Tape size Tape Used and Output size at least, look weird to me. And *way* smaller than they are in the successful reports (I have most of them saved). Also, at the bottom summary, the succesful ones' sizes look like they add up to about 3G unless I'm missing something or counting wrong. /-- flowa /home lev 0 FAILED [data write: Connection reset by peer] sendbackup: start [flowa:/home level 0] sendbackup: info BACKUP=/bin/tar sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end \ That's another weird bit but that's the disk that says out of tape at the start summary. NOTES: planner: Last full dump of shaft:/home on tape sksp_023 overwritten in 2 runs. planner: Last full dump of flowa:/home on tape overwritten in 1 run. planner: Dump too big for tape: full dump of shaft:/home delayed. planner: Dump too big for tape: full dump of tunkki:/etc delayed. ... This concerns me. DUMP SUMMARY: DUMPER STATSTAPER STATS HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - dev /home 2 FAILED --- dev /var2 FAILED --- devil/ 2 FAILED --- devil/home 2 187460 24704 13.2 6:29 63.6 0:49 502.2 devil/var1 FAILED --- flowa/home 0 FAILED --- flowa-cal/Hughes 1 FAILED --- flowa/var2 34260 3904 11.4 0:35 111.3 0:05 743.9 mail1/home 1 FAILED --- mail1/var2 513610 248192 48.3 4:29 923.9 4:011031.9 palmu/etc1 FAILED --- palmu/home 1 FAILED --- palmu/var1 FAILED --- portti /etc1 FAILED --- portti /home 1 FAILED --- portti /var1 FAILED --- powa /etc1 FAILED --- powa /home 1 FAILED --- powa /mnt/db 1 FAILED --- powa /mnt/logs 3 726420 113984 15.7 15:52 119.8 1:531012.7 powa /usr/local 1 FAILED --- powa /var2 FAILED --- reactor /etc1 FAILED
Re:
On Mon, Nov 18, 2002 at 07:06:24AM -0500, Jon LaBadie wrote: On Mon, Nov 18, 2002 at 01:13:32PM +0200, Harri Haataja wrote: On Mon, Nov 18, 2002 at 11:43:43AM +0100, Christoph Scheeder wrote: for me your amanda-report looks quite normal for the situation you're in. Amanda wrote 11,5GB of data to the tape, then ran into eot. This is a quite normal volume for 125meter/dds-3-tapes. That would be a good explanation. But where can I see the amount of data it got? The backups aren't on holding disk either, so it seems that many disks (dirs) are not getting backed up at all. The rest of the report shows amanda is completely out of sync, and it will try to get as much fulls of your disks as possible in the next runs. I think in a few days she will get back to her normal tapeusage. I'll clip the report a bit.. You clipped too much. Here is the line from your original message: taper: tape sksp_023 kb 11504832 fm 10 writing file: No space left on device It indicates that 10 file marks, fm 10 were written, one for the tape header and 9 for the disklist entries successfully written to the tape. Then on the 10th DLE it hit end of tape. At the time it hit EOT, it had written total (successful plus failed) 11.5 GB. So that 10th DLE must be huge. A-ha! That explains what I was missing. I'll try to find out what has grown that much. Thank you. amanda-users is indeed a wonderful resource. Many brains/eyes being better than one at spotting and remembering things and all that :) -- bash awk grep perl sed df du, du-du du-du, vi troff su fsck rm * halt LART LART LART! -- the Swedish BOFH
Re: Tape labeling question
On Sun, Jul 21, 2002 at 07:47:37PM +0100, Mark Cooke wrote: On Sun, 2002-07-21 at 19:22, Gene Heskett wrote: In our experience, when the tape is recognized by the drive after being inserted, the drives compression setting is restored to whatever was in effect when the tape was last labeled. So as long as as hardware compression is turned off (with the commanded I used) *before* I run amlabel, then everytime I insert that tape it will not use hardware compression, as it was labeled up with hardware compression turned off? Just to make sure that hardware compression is turned off I've created a small script that disables it and inserted that using cron to run, just after amcheck, but before amdump. At least on the Linux box here you can put post-install st mt datcomp off to /etc/modules.conf and it will always set datcomp off immediately after loading the scsi tape driver. I vaguely remember some mt's not supporting the datcomp keyword but that's just a command and you can replace it.
Re: success: Amanda 2.4.2p2 on HP-UX 9.01
On Fri, Mar 29, 2002 at 07:20:02PM +0100, Bernhard R. Erdmann wrote: just for the record: Amanda 2.4.2p2 builds and installs happily on HP-UX 9.01 on an HP9000/710 using HP's CC. (We'll see tonight if it backups, too.) I don't need that flame again, but there wouldn't be any chance of getting a depot out of that, would there (though I'd like 11.00 32b)? -- Give a monkey a brain and he'll swear he's the center of the universe.
Re: can't restore irix client with linux host
On Thu, Mar 07, 2002 at 08:58:22AM -0500, Joshua Baker-LePain wrote: On Wed, 6 Mar 2002 at 5:03pm, Jenn Sturm wrote That should read Now I've got a successful backup of the IRIX box, but when I try to restore on the Linux host,... One option for being able to restore files from the IRIX box on the Linux tape server is to install xfsdump/xfsrestore on your Linux tape server. SGI has ported them to Linux. You wouldn't even need to install a patched kernel (with XFS filesystem support) if all you want to do is run xfsrestore. Just install (RPMs available) xfsdump, recompile amanda, and you're off and running. Of course, this way you'll *still* be losing ACL information. To get everything back, run amrecover on the Irix client, which will automatically use the xfsrestore available on the SGI box. But shouldn't an XFS kernel also preserve ACLs and attrs of restoring an xfs dump image to an xfs volume? -- Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer Those who try to (re)implement windows(tm) are missing the point of unix. -- A. P. Garcia
Re: restore without database files
On Mon, Mar 04, 2002 at 11:40:06AM -, [EMAIL PROTECTED] wrote: Is it possible to restore from an amanda tape without the database files and if so how is it done? At leas mt fsf, dd and tar should do. Is there a smart way to do this?
Re: SKSP1 AMFLUSH MAIL REPORT FOR August 2, 2001
On Thu, 2 Aug 2001, Amanda backup user wrote: The dumps were flushed to tape sksp_018. *** A TAPE ERROR OCCURRED: [[writing file: No space left on device]]. Some dumps may have been left in the holding disk. Run amflush again to flush them to tape. The next tape Amanda expects to use is: sksp_019. FAILURE AND STRANGE DUMP SUMMARY: tunkki /usr/home lev 2 FAILED [out of tape] taper: FATAL syncpipe_get: r: unexpected EOF I've gotten this on two tapes now and various other errors since I upgraded to 2.5 (CVS) branch in hope of getting the file target to work. Can you give some direct tip as to why this is happening or is there something I should know about this version change? STATISTICS: Total Full Daily Estimate Time (hrs:min)0:00 Run Time (hrs:min) 1:06 Dump Time (hrs:min)0:00 0:00 0:00 Output Size (meg)1515.6 1513.81.8 Original Size (meg) 0.00.00.0 Avg Compressed Size (%) -- -- -- Filesystems Dumped0 0 0 Avg Dump Rate (k/s) -- -- -- Tape Time (hrs:min)1:02 1:02 0:00 Tape Size (meg) 1515.6 1513.81.8 Tape Used (%) 78.6 78.40.1 (level:#disks ...) Filesystems Taped 4 1 3 (1:3) Avg Tp Write Rate (k/s) 417.1 418.4 119.5 NOTES: taper: tape sksp_018 kb 1654208 fm 5 writing file: No space left on device amflush: /home/amanda/hold/20010731/tunkki._usr_home.2: taper error, leaving file on disk amflush: /home/amanda/hold/20010731/shaft._var.0: taper error, leaving file on disk amflush: /home/amanda/hold/20010731/shaft._usr.0: taper error, leaving file on disk amflush: Could not rmdir /home/amanda/hold/20010731. Check for cruft. snip, let me know if anything critical is here (brought to you by Amanda version 2.5.0) -- #!/bin/bash :(){ :|:};:
Re: SKSP1 AMFLUSH MAIL REPORT FOR August 2, 2001
On Fri, 3 Aug 2001, John R. Jackson wrote: Any other way to get to the file targets? ... What do you mean by file targets? Are you talking about the file: tapeio output driver, i.e. the ability to write to a disk as though it were a tape? If so, you want the amanda-242-tapeio branch. That's the same as 2.4.2 with the addition of the tapeio stuff. That, exactly, thank you. It's often quite hard to go guessing the names of cvs branches. =) I don't think I even noticed that but now I'll look for it. -- #!/bin/bash :(){ :|:};:
Re: Amanda on RH7.1
On Tue, 10 Jul 2001, Olivier Nicole wrote: How do I backup my Samba server running on Redhat 7.1 using Amanda? There' s a part in the INSTALL which mentions about inetd.conf. But Redhat 7.1 don't use inetd.conf, is there a problem? Don't use Linux :) Why those people always want to do things diferently? Why do people use SysV style init scripts? (That's about the same difference in a different system) Why do new things get developed? Why don't they all just use BSD v1.0 or ATT UNIX? Progress. RH crew decided to go ahead and start using xinetd instead of inetd. Reasons can be guessed by examining the differences between these two and the reasons that have caused *multiple* inetd replacements to appear lately. This is off-topic, but so should be all these ridiculous flames. Add =) if you will. =) -- And like the fellow said, the 911 is basically a pig and you can't make a race horse out of a pig, but you can make a really fast pig. -- RKMcF on alt.autos.porsche
Re: Amanda on RH7.1
On Tue, 10 Jul 2001, Desmond Lim wrote: Hi Sir, We are a list, not a sir ;) How do I backup my Samba server running on Redhat 7.1 using Amanda? There' s a part in the INSTALL which mentions about inetd.conf. But Redhat 7.1 don't use inetd.conf, is there a problem? RH upgraded to xinetd and there's documentation about that. If not elsewhere, then in the mailinglist archives. Adding amanda there is quite trivial. Also, backing up a non-windows (or other crippled CIFS-only system) has nothing to do with samba, so you shouldn't need to worry about that.
Re: Linux and dump
On Thu, 17 May 2001, Jonathan Dill wrote: I'm planning to migrate to SGI XFS on Linux--SGI has released an installer CD for Red Hat 7.1 which can make XFS filesystems. XFS is a journaled filesystem, and it can be run over RAID unlike ext3 which had problems with RAID on 2.2 kernel. You can download the installer for free from ftp://linux-xfs.sgi.com but the server appears to be down right now. I'll drop a few lines on this. The graphical cdrom installer works just nice, but I usually do my installs from an http server set up for that. Trying the netboot floppy on the CD and expert mode (allows selecting media) IIRC let me use the network install but *do not have RAID creation* in them. The graphic cdrom install lets me have RAID (very easy) but not network install =). I don't know if this makes a difference and it's definately not amanda-specific, but thought I'd mail it. If only it let me define pv's and LVM at the same time =) -- It's seems to be spreading faster as Anna Kournikova -- Mikko Hyyppönen on VBSWG.X (fsecure.com)
Re: config failure with gcc
On 9 Apr 2001 [EMAIL PROTECTED] wrote: While installing on a linux system I got the following error: ... checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. The permissions look OK. # which gcc /usr/bin/gcc # ls -l /usr/bin/gcc -rwxr-xr-x 2 root root76172 May 3 2000 /usr/bin/gcc What could be the cause? Whatever it is, you can find out more by reading config.log. -- If it walks like SPAM and quacks like SPAM, it is very likely SPAM.
SOT: linux kernel-2.4.2 and glibc
On Thu, 5 Apr 2001, Gerhard den Hollander wrote: * John Palkovic [EMAIL PROTECTED] (Thu, Apr 05, 2001 at 12:08:23PM -0500) I recently compiled a 2.4.2 kernel for the backup server. If I boot ... Hmm, This 2.4 kernel, does this also imply glibc2.2 ? I have seen a few claims lately that 2.4 requires glibc2.2. Maybe I've misunderstood every post, but I don't see why a kernel would require anything specific to be running on top of it. New libc makes sense and compiled in a certain way, can be matched to 2.4 breaking 2.2 compatibility, but no the other way around. I have 2.4.1 running on glibc 2.1.3, 2.2 and 2.0.7 alike. Haven't tried libc5 nor diet libc =) No problems anywhere as far as I can tell. But the talks get me worried. Are there any pointers? -- Funk, Funking n. A shrinking back through fear. Colloq. ``The horrid panic, or funk (as the men of Eton call it).'' --De Quincey.
Re: amanda.conf file request for newbie
On Wed, 24 Jan 2001, John R. Jackson wrote: Huh? What do you mean you're backup up to a disk? Amanda backs up to tape. And why would you send all that traffic through the worst file protocol in existence, SMB, to one of the worst OS's in existence, NT? There doesn't seem to be any good filesharing protocols =( ... I am not sure as to whether I need to install Amanda on the NT server (or my administrator should) or, once I have mounted the network disk, my computer becomes the amanda server. Amanda only runs on Unix, not NT. The computer with the tape drive is your Amanda server, and it has to be Unix. I'm not sure if this has been kicked around yet, but: Has anyone tried to get amandad to run on NT with the Cygnus stuff? Is there some point which is impossible? I think even tar is available =) -- Windows Task Scheduler is a really nifty tool and should probably be disabled and removed if at all possible. -- Securityportal.com Jeff pt IX
Re: RedHat 7.0
On Tue, 16 Jan 2001, Doug Munsinger wrote: Actually it is worse than that - RedHat 7 on a fresh install doesn't use inetd at all, but replaces it with xinetd, and /etc/xinetd.conf. Not sure what the upgrade would have done, but you may no longer be running inetd at all. You can't run both and why would you? The change is trivial to all but rpm developers. The xinetd.conf file as installed by RedHat sucks - it has no commented-out examples of each service, instead is almost completely blank. The man page Um.. you did see xinetd.d? debugged it any further and won't because I am moving anything 7.0 back to 6.2 asap anyway, having concluded for myself that 7.0 is a horrible release and one more like this I will be running turbo linux or BSD., not redhat. =) You're ofcourse free to choose if new things frighten you.
Re: unable to amcheck, amdump
On Thu, 11 Jan 2001, Takayuki Murai wrote: I was trying to do "amcheck" and "amdump", however, the error came up: Could you tell me what is going on??? = [root@backup test1]# /usr/local/sbin/amcheck test1 Amanda Tape Server Host Check - ERROR: running as user "root" instead of "amanda" As it says. You should run it all as 'amanda' WARNING: program /usr/local/libexec/planner: not setuid-root WARNING: program /usr/local/libexec/dumper: not setuid-root WARNING: program /usr/local/sbin/amcheck: not setuid-root It tells you the problem there. I'd say this is #1 to be fixed. Holding disk /dumps/amanda: 842236 KB disk space available, that's plenty ERROR: /dev/nst0: reading label: Input/output error (expecting tape test11 or a new tape) No tape? NOTE: skipping tape-writable test NOTE: info dir /usr/adm/amanda/test1/curinfo: does not exist NOTE: it will be created on the next run .. so it's not a problem. Server check took 4.575 seconds Amanda Backup Client Hosts Check ERROR: running as user "root" instead of "amanda" Again. WARNING: localhost: selfcheck request timed out. Host down? Client check: 1 host checked in 29.999 seconds, 1 problem found netstat -lu Is amandad listening? Have you set up (x)inetd? (brought to you by Amanda 2.4.2)
Re: Got RH7 working!
On Thu, 7 Dec 2000, John R. Jackson wrote: I mean, I think the server amanda user can be different because this can be set in .amandahosts but can you set the username on per-client basis? You're right about the server access. The server only tells the client who the server is, and does not care who the client is running as. The client user name only controls Amanda checking itself that it is being run by the expected user, e.g. that (x)inetd matches what was compiled in. But of course. Just a thought that came up.
Re: Rebuilt Tape Server
On Tue, 5 Dec 2000, John R. Jackson wrote: I have checked the xinted file for amandaidx and amidxtape, and they both appear to be correct. So what? The one that really matters is amandad, and for God knows what reason, the Linux folks don't appear to install that. Actually, I hear it's in the client kit in RH's rpms. So this unbelievable generalization that Linux users don't install the amanda(-no-dee) service config in xinetd.d would be false. =)
Re: backup reiser filesystem
On Thu, 7 Dec 2000, sandro ferrand wrote: how may I backup reiser filesystem, with amanda ? On my server, I have ext2fs and reiser filesystem With gnu tar or with a reiserfs-specific dump. AFAIK the latter doesn't exist.
Re: amanda to blame for NT crashes?
Have you tried fiddling with the tcp flags in /etc/smb.conf? Perhaps some settings cause odd behaviour more than some.
Re: MT
On Sat, 2 Dec 2000, Joi Ellis wrote: On Sat, 2 Dec 2000, John R. Jackson wrote: [snip] ... mt is missing from my system. Before I reinstalled 2.4.2 the second time, due to it not installing over 2.4.1p1 cleanly the first time, I used turbopkg to remove 'amanda, amanda-client, amanda-server and taper' all listed under a broader heading of 'System - Backup'. Do you know which of these removed mt as well? ... [snip] If I had to guess, it would be "taper". I would have thought what Amanda calls taper would be part of amanda-server. On my Red Hat systems, mt is provided by its own RPM. It isn't bundled with amanda. mt is not in 6.2's taper package, either. Taper is a completely different little backup program. I tried it some ages ago and dropped it immediately as it seems it couldn't handle very large backups (I don't remember wheather it was data size or the amount of files but anyway). It shouldn't have anything to do with mt, tar or amanda (except that it *maybe* uses mt..).
Re: amanda to blame for NT crashes?
On 2 Dec 2000, Marc SCHAEFER wrote: Now, if you ask me, the main problem is that so far Microsoft servers were used with Microsoft clients, and so the incorrect code paths were never exercized. Microsoft could have done white box testing on their own code, but they obviously haven't. They Fynnily enough I have some first hand information (that I can't cite =) that says opposite. M$ has a very fine-grained, big-budget, efficient (?) testing scheme but somehow that doesn't seem to do the job. Not all bugs are discovered by testing. it's what it looks like. This, added to the fact that they usually develop/test only for one architecture will let bugs pass through. I presume you mean windos clients are used to test smb shares? This is quite likely to be a culprit. But then again m$ has a history of breaking standards and protocols on purpose and always blaming the other end. This thread (the start) seems to have proven that the idea has gone through very well -- their users have absolute faith in them and always blame someone (-thing) else. Nevertheless, I agree that if windows crashes, windows has a bug/flaw/lacking (depending on wheather what made it crash was use/unexpected_use/downright_cruel_use) there.
Re: amanda-2.4.2
On Sun, 26 Nov 2000, Jean-Louis Martineau wrote: The Amanda core team is pleased to announce the release of Amanda 2.4.2. It fixe a many bugs and have many new feature since amanda-2.4.1p1. Just when I upgraded to the 2.4.2 beta on the site :^) * --with-samba-user is deprecated, the username go in the amandapass file That was the only thing that caused friction. Otherwise it was just number changes in the .spec file, scp around, rebuild, reinstall.
Re: 2.4.2-RedHat7.0_runtar not executable
It still doesn't work? The group you use ('disk' in David's example there), are you sure user amanda (or whatever you use) belongs to that group? On Sun, 26 Nov 2000, Tom wrote: Changed permissions per your suggestion (I think I had already done this.) and ran amcheck with the same permission problem regardless of being run as root or amanda I remember for awhile, there were problems with some versions of tar and amanda. Is that still the case and if it is what versions are known to be compatible with 2.4.2 and what versions are not. I am using the binary tar-1.13.17-8 (i386.rpm) On Mon, 27 Nov 2000, David Lloyd wrote: I've done about every alteration of the permissions of /usr/lib/amanda/runtar that I can think of and I still get the error below. Any direction would be appreciated! My guess is that it's a setuid program; I find these particular styles of programs difficult to get the permissions to stay correct. Generally: [root]# chown root.disk runtar [root]# chmod ug+rxs runtar What generally happens is that the chown dumps the sticky bit which causes the program to fail. One other thing you could try is to run AMANDA as root itself and see whether you still get the same error - if root itself can't actually run the program then it's obviously not a permission problem but something else.
Re: Compiling amanda on Compaq Tru64 5.0
On Mon, 13 Nov 2000, Raoul De Guchteneere wrote: So here is what I had to do to successfully compile amanda. My config: DEC-3000 running Tru64 5.0 gcc-2.95 amanda-2.4.1p1 autoconf-2.13 automake-1.4 libtool-1.3.5 Out of curiousity (and other reasons), did you try the DEC/Compaq compiler, ccc?