Re: Slow recover speeds was amrecover failures
Jerlique Bahn wrote: > It seems Amanda is going through the process of reading the whole tape and > therefore will take several hours to restore about 10Mb in selected files? Yes, it will do a read of the entire tape. There is a config file option called amrecover_do_fsf that if set to true will fsf your tape to the correct spot if your drive supports it, which is much faster than a linear read. > > My tape only seems to work at about 3 Mbps. The scsi disks it reads from > (holding space) and writes to are capable of much more than that (U320, raid > 5 array). Best way to figure this out is to post the report that gets emailed at the end of your run. It shows dump and tape speeds for each DLE and is very informative once you learn what you're looking for. Two possibilities: You're bypassing the holding disk and going directly to tape due to too small a holdingdisk or your reserve set too high to allow fulls to go there. Contention on the disk, especially if it is also used for other tasks, and compounded if inparallel is set very high. RAID5 is often not high-performance. I've seen some that do well on a single read or write, but seriously degrade with a few simultaneous operations. Either way, if the dump can't feed the tape fast enough, the tape keeps stopping and repositioning itself, vastly slowing your throughput (and wearing out your drive and tape). You might consider increasing tapebufs in your config to buffer more data in memory. Try dd-ing a large file from your disk to /dev/null, /dev/zero to your disk, and /dev/zero to a blank tape, and see what the limits of your particular hardware are. Frank > > JB > -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Slow recover speeds was amrecover failures
Hi Frank, > > ## This is from the changer.debug > > MT -> /usr/local/amanda/sbin/ammt -f > > DD -> /usr/local/amanda/sbin/amdd > > Args -> -slot next > > -> rewind /dev/nsa0 > > /dev/nsa0 rewind failed: Permission denied > Looks like this is your main problem, you don't have permissions to > the tape drive. Odd, since you say you are running amrecover as > root. Is the tape actually loaded in the drive? Can you (from the > command line) run 'mt -f /dev/nsa0 rewind' successfully? > >>> I agree, however from the command line I have full access: > >> On poking around my installation, the changer scripts are all > >> owned by my Amanda user, not root. Can you 'su -' to your Amanda > >> user and still run these commands? > > Easiest fix is probably add your user 'backup' to whatever group has > write permissions to your tape drive. I believe the docs recommend > making your backup user a member of whatever group owns the devices > on your OS to avoid problems such as this. You may also run into I missed this step. I'll have another read over it to ensure I haven't mucked anything else up :( > permissions problems on your backups as well. The tar wrapper is > suid root so it won't care, but if you use dump it needs access to > the disk device and can fail on permissions. >Not sure which fix I would recommend. If adding backup to the > group owning the tape device solves your problem, then go with that, > but if you foresee future issues with dump (I'm assuming the backup > group doesn't own your disks) you might want to go through the pain > of changing backup's group and chgrp-ing all Amanda's files. Many thanks for your advice. I've managed to get it to work by the addition of the backup user to the operator group - the same one which has permission to read/write on the tape drive. It seems Amanda is going through the process of reading the whole tape and therefore will take several hours to restore about 10Mb in selected files? My tape only seems to work at about 3 Mbps. The scsi disks it reads from (holding space) and writes to are capable of much more than that (U320, raid 5 array). JB
Re: amrecover failures
Jerlique Bahn wrote: >> Jerlique Bahn wrote: > I have recently configured Amanda to backup our data. I am now trying to > restore some of the data that I have backed up, and I am having >> problems > doing so. The client and server are the same machine. I have chg- >> manual > configured so that the first and last slot are both 1. I am running > amrecover as root. I am guessing that its because the changer think >> that it needs a different tape, but I cannot work out why. > # ammt -f /dev/nsa0 status > /dev/nsa0 status: ONLINE ds == 0x0001 er == 0x > > # amtape backup reset > changer: got exit: 0 str: 1 /dev/nsa0 > amtape: changer is reset, slot 1 is loaded. > > ## this is from /tmp/Amanda/amidxtaped > Looking for tape backup-1... > changer: got exit: 0 str: 0 1 1 > changer_query: changer return was 1 1 > changer_query: searchable = 0 > changer_find: looking for backup-1 changer is searchable = 0 > changer: got exit: 2 str: /usr/local/amanda/libexec/chg-manual: cannot > create /dev/tty: Device not configured I'm not very familiar with the chg-manual script, but as a wild guess you might have the wrong console device specified for your OS. >>> I don't think so, because the commands that are failing from within >>> chg-manual work if I type them in eg: >>> >>> SRV# echo "insert tape into slot $1 and press return" >/dev/tty >>> insert tape into slot and press return >>> SRV# read ANSWER >> >>> SRV# >>> > amidxtaped: could not load slot /usr/local/amanda/libexec/chg-manual:: > cannot create /dev/tty: Device not configured > amidxtaped: time 0.186: could not load slot > /usr/local/amanda/libexec/chg-manual:: cannot create /dev/tty: Device not > configu > red > amidxtaped: time 0.186: pid 5948 finish time Mon Jul 10 23:01:39 2006 > > > ## This is from the changer.debug > MT -> /usr/local/amanda/sbin/ammt -f > DD -> /usr/local/amanda/sbin/amdd > Args -> -slot next > -> rewind /dev/nsa0 > /dev/nsa0 rewind failed: Permission denied Looks like this is your main problem, you don't have permissions to the tape drive. Odd, since you say you are running amrecover as root. Is the tape actually loaded in the drive? Can you (from the command line) run 'mt -f /dev/nsa0 rewind' successfully? >>> I agree, however from the command line I have full access: >> On poking around my installation, the changer scripts are all >> owned by my Amanda user, not root. Can you 'su -' to your Amanda >> user and still run these commands? > > Ahh very good point!! I've been running it as root, and this is what is in > the Amanda.conf file but I compiled with user=backup. In inetd I'm running > the services as user root. > > SRV# su backup -c "/usr/local/amanda/sbin/ammt -f /dev/nsa0 rewind" > /dev/nsa0 rewind failed: Permission denied > > SRV# la /usr/local/amanda/sbin/ammt -rwxr-xr-x 1 backup backup 14857 Jul > 10 14:13 /usr/local/amanda/sbin/ammt > > SRV# la /usr/local/amanda/sbin/amdd -rwxr-xr-x 1 backup backup 13153 Jul > 10 14:13 /usr/local/amanda/sbin/amdd > > What do you think I should do? Easiest fix is probably add your user 'backup' to whatever group has write permissions to your tape drive. I believe the docs recommend making your backup user a member of whatever group owns the devices on your OS to avoid problems such as this. You may also run into permissions problems on your backups as well. The tar wrapper is suid root so it won't care, but if you use dump it needs access to the disk device and can fail on permissions. Not sure which fix I would recommend. If adding backup to the group owning the tape device solves your problem, then go with that, but if you foresee future issues with dump (I'm assuming the backup group doesn't own your disks) you might want to go through the pain of changing backup's group and chgrp-ing all Amanda's files. Frank > > JB > -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
RE: amrecover failures
> Jerlique Bahn wrote: > >>> I have recently configured Amanda to backup our data. I am now trying > >> to > >>> restore some of the data that I have backed up, and I am having > problems > >>> doing so. The client and server are the same machine. I have chg- > manual > >>> configured so that the first and last slot are both 1. I am running > >>> amrecover as root. I am guessing that its because the changer think > that > >> it needs a different tape, but I cannot work out why. > >>> # ammt -f /dev/nsa0 status > >>> /dev/nsa0 status: ONLINE ds == 0x0001 er == 0x > >>> > >>> # amtape backup reset > >>> changer: got exit: 0 str: 1 /dev/nsa0 > >>> amtape: changer is reset, slot 1 is loaded. > >>> > >>> ## this is from /tmp/Amanda/amidxtaped > >>> Looking for tape backup-1... > >>> changer: got exit: 0 str: 0 1 1 > >>> changer_query: changer return was 1 1 > >>> changer_query: searchable = 0 > >>> changer_find: looking for backup-1 changer is searchable = 0 > >>> changer: got exit: 2 str: /usr/local/amanda/libexec/chg-manual: cannot > >>> create /dev/tty: Device not configured > >> I'm not very familiar with the chg-manual script, but as a wild guess > >> you might have the wrong console device specified for your OS. > > > > I don't think so, because the commands that are failing from within > > chg-manual work if I type them in eg: > > > > SRV# echo "insert tape into slot $1 and press return" >/dev/tty > > insert tape into slot and press return > > SRV# read ANSWER > > > SRV# > > > >>> amidxtaped: could not load slot /usr/local/amanda/libexec/chg-manual:: > >>> cannot create /dev/tty: Device not configured > >>> amidxtaped: time 0.186: could not load slot > >>> /usr/local/amanda/libexec/chg-manual:: cannot create /dev/tty: Device > >> not > >>> configu > >>> red > >>> amidxtaped: time 0.186: pid 5948 finish time Mon Jul 10 23:01:39 2006 > >>> > >>> > >>> ## This is from the changer.debug > >>> MT -> /usr/local/amanda/sbin/ammt -f > >>> DD -> /usr/local/amanda/sbin/amdd > >>> Args -> -slot next > >>> -> rewind /dev/nsa0 > >>> /dev/nsa0 rewind failed: Permission denied > >> Looks like this is your main problem, you don't have permissions to > >> the tape drive. Odd, since you say you are running amrecover as > >> root. Is the tape actually loaded in the drive? Can you (from the > >> command line) run 'mt -f /dev/nsa0 rewind' successfully? > > > > I agree, however from the command line I have full access: > > On poking around my installation, the changer scripts are all > owned by my Amanda user, not root. Can you 'su -' to your Amanda > user and still run these commands? Ahh very good point!! I've been running it as root, and this is what is in the Amanda.conf file but I compiled with user=backup. In inetd I'm running the services as user root. SRV# su backup -c "/usr/local/amanda/sbin/ammt -f /dev/nsa0 rewind" /dev/nsa0 rewind failed: Permission denied SRV# la /usr/local/amanda/sbin/ammt -rwxr-xr-x 1 backup backup 14857 Jul 10 14:13 /usr/local/amanda/sbin/ammt SRV# la /usr/local/amanda/sbin/amdd -rwxr-xr-x 1 backup backup 13153 Jul 10 14:13 /usr/local/amanda/sbin/amdd What do you think I should do? JB
Re: amrecover failures
Jerlique Bahn wrote: >>> I have recently configured Amanda to backup our data. I am now trying >> to >>> restore some of the data that I have backed up, and I am having problems >>> doing so. The client and server are the same machine. I have chg-manual >>> configured so that the first and last slot are both 1. I am running >>> amrecover as root. I am guessing that its because the changer think that >> it needs a different tape, but I cannot work out why. >>> # ammt -f /dev/nsa0 status >>> /dev/nsa0 status: ONLINE ds == 0x0001 er == 0x >>> >>> # amtape backup reset >>> changer: got exit: 0 str: 1 /dev/nsa0 >>> amtape: changer is reset, slot 1 is loaded. >>> >>> ## this is from /tmp/Amanda/amidxtaped >>> Looking for tape backup-1... >>> changer: got exit: 0 str: 0 1 1 >>> changer_query: changer return was 1 1 >>> changer_query: searchable = 0 >>> changer_find: looking for backup-1 changer is searchable = 0 >>> changer: got exit: 2 str: /usr/local/amanda/libexec/chg-manual: cannot >>> create /dev/tty: Device not configured >> I'm not very familiar with the chg-manual script, but as a wild guess >> you might have the wrong console device specified for your OS. > > I don't think so, because the commands that are failing from within > chg-manual work if I type them in eg: > > SRV# echo "insert tape into slot $1 and press return" >/dev/tty > insert tape into slot and press return > SRV# read ANSWER > SRV# > >>> amidxtaped: could not load slot /usr/local/amanda/libexec/chg-manual:: >>> cannot create /dev/tty: Device not configured >>> amidxtaped: time 0.186: could not load slot >>> /usr/local/amanda/libexec/chg-manual:: cannot create /dev/tty: Device >> not >>> configu >>> red >>> amidxtaped: time 0.186: pid 5948 finish time Mon Jul 10 23:01:39 2006 >>> >>> >>> ## This is from the changer.debug >>> MT -> /usr/local/amanda/sbin/ammt -f >>> DD -> /usr/local/amanda/sbin/amdd >>> Args -> -slot next >>> -> rewind /dev/nsa0 >>> /dev/nsa0 rewind failed: Permission denied >> Looks like this is your main problem, you don't have permissions to >> the tape drive. Odd, since you say you are running amrecover as >> root. Is the tape actually loaded in the drive? Can you (from the >> command line) run 'mt -f /dev/nsa0 rewind' successfully? > > I agree, however from the command line I have full access: On poking around my installation, the changer scripts are all owned by my Amanda user, not root. Can you 'su -' to your Amanda user and still run these commands? Frank > > SRV# mt -f /dev/nsa0 rewind > > SRV# dd if=/dev/nsa0 bs=32k > AMANDA: TAPESTART DATE 20060623 TAPE backup-1 > 014 > 1+0 records in > 1+0 records out > 32768 bytes transferred in 3.319408 secs (9872 bytes/sec) > > SRV# mt -f /dev/nsa0 status > Mode Density Blocksize bpi Compression > Current: 0x42 variable 00x1 > -available modes- > 0:0x42 variable 00x1 > 1:0x42 variable 00x1 > 2:0x42 variable 00x1 > 3:0x42 variable 00x1 > - > Current Driver State: at rest. > - > File Number: 0 Record Number: 0Residual Count 0 > > JB > -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
RE: amrecover failures
> > I have recently configured Amanda to backup our data. I am now trying > to > > restore some of the data that I have backed up, and I am having problems > > doing so. The client and server are the same machine. I have chg-manual > > configured so that the first and last slot are both 1. I am running > > amrecover as root. I am guessing that its because the changer think that > it needs a different tape, but I cannot work out why. > > > > # ammt -f /dev/nsa0 status > > /dev/nsa0 status: ONLINE ds == 0x0001 er == 0x > > > > # amtape backup reset > > changer: got exit: 0 str: 1 /dev/nsa0 > > amtape: changer is reset, slot 1 is loaded. > > > > ## this is from /tmp/Amanda/amidxtaped > > Looking for tape backup-1... > > changer: got exit: 0 str: 0 1 1 > > changer_query: changer return was 1 1 > > changer_query: searchable = 0 > > changer_find: looking for backup-1 changer is searchable = 0 > > changer: got exit: 2 str: /usr/local/amanda/libexec/chg-manual: cannot > > create /dev/tty: Device not configured > > I'm not very familiar with the chg-manual script, but as a wild guess > you might have the wrong console device specified for your OS. I don't think so, because the commands that are failing from within chg-manual work if I type them in eg: SRV# echo "insert tape into slot $1 and press return" >/dev/tty insert tape into slot and press return SRV# read ANSWER > amidxtaped: could not load slot /usr/local/amanda/libexec/chg-manual:: > > cannot create /dev/tty: Device not configured > > amidxtaped: time 0.186: could not load slot > > /usr/local/amanda/libexec/chg-manual:: cannot create /dev/tty: Device > not > > configu > > red > > amidxtaped: time 0.186: pid 5948 finish time Mon Jul 10 23:01:39 2006 > > > > > > ## This is from the changer.debug > > MT -> /usr/local/amanda/sbin/ammt -f > > DD -> /usr/local/amanda/sbin/amdd > > Args -> -slot next > > -> rewind /dev/nsa0 > > /dev/nsa0 rewind failed: Permission denied > > Looks like this is your main problem, you don't have permissions to > the tape drive. Odd, since you say you are running amrecover as > root. Is the tape actually loaded in the drive? Can you (from the > command line) run 'mt -f /dev/nsa0 rewind' successfully? I agree, however from the command line I have full access: SRV# mt -f /dev/nsa0 rewind SRV# dd if=/dev/nsa0 bs=32k AMANDA: TAPESTART DATE 20060623 TAPE backup-1 014 1+0 records in 1+0 records out 32768 bytes transferred in 3.319408 secs (9872 bytes/sec) SRV# mt -f /dev/nsa0 status Mode Density Blocksize bpi Compression Current: 0x42 variable 00x1 -available modes- 0:0x42 variable 00x1 1:0x42 variable 00x1 2:0x42 variable 00x1 3:0x42 variable 00x1 - Current Driver State: at rest. - File Number: 0 Record Number: 0Residual Count 0 JB
Re: port NNNN not secure(newbie)
Mike Allen wrote: > Jon LaBadie wrote: >> On Mon, Jul 10, 2006 at 02:38:31PM -0700, Mike Allen wrote: >> >>> Jon LaBadie wrote: >>> On Mon, Jul 10, 2006 at 10:33:27AM -0700, Mike Allen wrote: > I'm using Amanda 2.4.5 with FreeBSD 5.4. > > 1. Backups on the NATed side of our firewall work fine. > > 2. Our tape server is on the NATed side of firewall. > > 3. Backups through the firewall fail when I run AMCHECK. >The error message is port not secure. > > I have attempted to research the environment variables 'tcpportrange', > 'udpportrange' and > 'portrange' and configure our firewall appropriately but with no success. > > Please tell me what I am doing wrong. Any help would be appreciated. > > > There are some user-supplied responses to that question in the FAQ-o-matic: http://amanda.sourceforge.net/fom-serve/cache/14.html See if any of them apply. Other info might be available at zmanda.com >>> Jon: >>> >>> Thanks for your reply. I had previously checked out Faq-O-Matic and >>> found nothing >>> new or useful to me for this problem. The problem may be in my >>> perseptions about this problem. >>> >>> Regarding the file 'site.config'. I would like to know the difference >>> between the >>> 'portrange' parameter and the 'tcpportrange' parameter. Am I supposed to >>> use both? >>> Does 'tcpportrange' override 'portrange' or what? >>> >>> I am afraid that much 'handholding' may be required to get me over this >>> problem! >>> >>> >> IIRC (I've not used port specification) portrange is the old synonym >> for tcpportrange. Assuming I'm correct, don't use portrange. >> >> But do use BOTH udpportrange and tcpportrange. >> >> Again, suggested by someone who has not used them. Mine is built with: --with-tcpportrange=4,40030 --with-udpportrange=920,940 I believe the tcp ports must be >1024 and the udp ports <1024 or you will get various errors and/or warnings. You might want to read the PORT.USAGE file in the docs directory to get an idea of how big a range you will need. >> >> jl >> > Assuming I have configured the TAPEHOST correctly using both > 'tcpportrange' and 'udpportrange', > do I do the identical configuration on the CLIENT with respect to > 'tcpportrange' and 'udpportrange'? Yes, they both need to be configured the same or they won't talk to each other. > I cannot find anything about this in the documentation > > I had another thought, I am using a Netgear model FSV338 for my > firewall. (I use the appropriate > settings for port-forwarding.) Could this be the problem? A potential problem, depending on how its configured. Keep in mind that unless the firewall is Amanda aware it may block the reverse connections from the client that go to different ports on the server than the ones the server initially used. That is the purpose of the portrange configuration, to limit the number of ports you need to open on your firewall between client and server. iptables (netfilter) has a module that is Amanda-aware and can allow the reverse connections as a 'related' match, even if you don't use portrange. > > How can I check this out? Besides looking in the Amanda logs for timeouts on client and server, tcpdump or other packet capturing tools will show what is happening where. Frank > > Mike > -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: port NNNN not secure(newbie)
Jon LaBadie wrote: On Mon, Jul 10, 2006 at 02:38:31PM -0700, Mike Allen wrote: Jon LaBadie wrote: On Mon, Jul 10, 2006 at 10:33:27AM -0700, Mike Allen wrote: I'm using Amanda 2.4.5 with FreeBSD 5.4. 1. Backups on the NATed side of our firewall work fine. 2. Our tape server is on the NATed side of firewall. 3. Backups through the firewall fail when I run AMCHECK. The error message is port not secure. I have attempted to research the environment variables 'tcpportrange', 'udpportrange' and 'portrange' and configure our firewall appropriately but with no success. Please tell me what I am doing wrong. Any help would be appreciated. There are some user-supplied responses to that question in the FAQ-o-matic: http://amanda.sourceforge.net/fom-serve/cache/14.html See if any of them apply. Other info might be available at zmanda.com Jon: Thanks for your reply. I had previously checked out Faq-O-Matic and found nothing new or useful to me for this problem. The problem may be in my perseptions about this problem. Regarding the file 'site.config'. I would like to know the difference between the 'portrange' parameter and the 'tcpportrange' parameter. Am I supposed to use both? Does 'tcpportrange' override 'portrange' or what? I am afraid that much 'handholding' may be required to get me over this problem! IIRC (I've not used port specification) portrange is the old synonym for tcpportrange. Assuming I'm correct, don't use portrange. But do use BOTH udpportrange and tcpportrange. Again, suggested by someone who has not used them. jl Assuming I have configured the TAPEHOST correctly using both 'tcpportrange' and 'udpportrange', do I do the identical configuration on the CLIENT with respect to 'tcpportrange' and 'udpportrange'? I cannot find anything about this in the documentation I had another thought, I am using a Netgear model FSV338 for my firewall. (I use the appropriate settings for port-forwarding.) Could this be the problem? How can I check this out? Mike
Re: port NNNN not secure(newbie)
On Mon, Jul 10, 2006 at 02:38:31PM -0700, Mike Allen wrote: > Jon LaBadie wrote: > >On Mon, Jul 10, 2006 at 10:33:27AM -0700, Mike Allen wrote: > > > >>I'm using Amanda 2.4.5 with FreeBSD 5.4. > >> > >>1. Backups on the NATed side of our firewall work fine. > >> > >>2. Our tape server is on the NATed side of firewall. > >> > >>3. Backups through the firewall fail when I run AMCHECK. > >>The error message is port not secure. > >> > >>I have attempted to research the environment variables 'tcpportrange', > >>'udpportrange' and > >>'portrange' and configure our firewall appropriately but with no success. > >> > >>Please tell me what I am doing wrong. Any help would be appreciated. > >> > >> > > > >There are some user-supplied responses to that question in the FAQ-o-matic: > > > > http://amanda.sourceforge.net/fom-serve/cache/14.html > > > >See if any of them apply. > > > >Other info might be available at zmanda.com > > > > > Jon: > > Thanks for your reply. I had previously checked out Faq-O-Matic and > found nothing > new or useful to me for this problem. The problem may be in my > perseptions about this problem. > > Regarding the file 'site.config'. I would like to know the difference > between the > 'portrange' parameter and the 'tcpportrange' parameter. Am I supposed to > use both? > Does 'tcpportrange' override 'portrange' or what? > > I am afraid that much 'handholding' may be required to get me over this > problem! > IIRC (I've not used port specification) portrange is the old synonym for tcpportrange. Assuming I'm correct, don't use portrange. But do use BOTH udpportrange and tcpportrange. Again, suggested by someone who has not used them. jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: port NNNN not secure(newbie)
Jon LaBadie wrote: On Mon, Jul 10, 2006 at 10:33:27AM -0700, Mike Allen wrote: I'm using Amanda 2.4.5 with FreeBSD 5.4. 1. Backups on the NATed side of our firewall work fine. 2. Our tape server is on the NATed side of firewall. 3. Backups through the firewall fail when I run AMCHECK. The error message is port not secure. I have attempted to research the environment variables 'tcpportrange', 'udpportrange' and 'portrange' and configure our firewall appropriately but with no success. Please tell me what I am doing wrong. Any help would be appreciated. There are some user-supplied responses to that question in the FAQ-o-matic: http://amanda.sourceforge.net/fom-serve/cache/14.html See if any of them apply. Other info might be available at zmanda.com Jon: Thanks for your reply. I had previously checked out Faq-O-Matic and found nothing new or useful to me for this problem. The problem may be in my perseptions about this problem. Regarding the file 'site.config'. I would like to know the difference between the 'portrange' parameter and the 'tcpportrange' parameter. Am I supposed to use both? Does 'tcpportrange' override 'portrange' or what? I am afraid that much 'handholding' may be required to get me over this problem! Thanks in advance for any help. Mike
Re: port NNNN not secure(newbie)
On Mon, Jul 10, 2006 at 10:33:27AM -0700, Mike Allen wrote: > I'm using Amanda 2.4.5 with FreeBSD 5.4. > > 1. Backups on the NATed side of our firewall work fine. > > 2. Our tape server is on the NATed side of firewall. > > 3. Backups through the firewall fail when I run AMCHECK. > The error message is port not secure. > > I have attempted to research the environment variables 'tcpportrange', > 'udpportrange' and > 'portrange' and configure our firewall appropriately but with no success. > > Please tell me what I am doing wrong. Any help would be appreciated. > There are some user-supplied responses to that question in the FAQ-o-matic: http://amanda.sourceforge.net/fom-serve/cache/14.html See if any of them apply. Other info might be available at zmanda.com -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
port NNNN not secure(newbie)
I'm using Amanda 2.4.5 with FreeBSD 5.4. 1. Backups on the NATed side of our firewall work fine. 2. Our tape server is on the NATed side of firewall. 3. Backups through the firewall fail when I run AMCHECK. The error message is port not secure. I have attempted to research the environment variables 'tcpportrange', 'udpportrange' and 'portrange' and configure our firewall appropriately but with no success. Please tell me what I am doing wrong. Any help would be appreciated. Mike
Re: amrecover failures
Jerlique Bahn wrote: > Hello, > > I have recently configured Amanda to backup our data. I am now trying to > restore some of the data that I have backed up, and I am having problems > doing so. The client and server are the same machine. I have chg-manual > configured so that the first and last slot are both 1. I am running > amrecover as root. I am guessing that its because the changer think that it > needs a different tape, but I cannot work out why. > > Any suggestions? > > amrecover> [cut] > amrecover> extract > > Extracting files using tape drive /dev/nsa0 on host 10.0.0.2. > The following tapes are needed: backup-1 > backup-5 > > Restoring files into directory /usr/recover > Continue [?/Y/n]? Y > > Extracting files using tape drive /dev/nsa0 on host 10.0.0.2. > Load tape backup-1 now > Continue [?/Y/n/s/t]? Y > EOF, check amidxtaped..debug file on 10.0.0.2. > amrecover: short block 0 bytes > UNKNOWN file > amrecover: Can't read file header > extract_list - child returned non-zero status: 1 > Continue [?/Y/n/r]? > > # ammt -f /dev/nsa0 status > /dev/nsa0 status: ONLINE ds == 0x0001 er == 0x > > # amtape backup reset > changer: got exit: 0 str: 1 /dev/nsa0 > amtape: changer is reset, slot 1 is loaded. > > > ## this is from /tmp/Amanda/amidxtaped > Looking for tape backup-1... > changer: got exit: 0 str: 0 1 1 > changer_query: changer return was 1 1 > changer_query: searchable = 0 > changer_find: looking for backup-1 changer is searchable = 0 > changer: got exit: 2 str: /usr/local/amanda/libexec/chg-manual: cannot > create /dev/tty: Device not configured I'm not very familiar with the chg-manual script, but as a wild guess you might have the wrong console device specified for your OS. > amidxtaped: could not load slot /usr/local/amanda/libexec/chg-manual:: > cannot create /dev/tty: Device not configured > amidxtaped: time 0.186: could not load slot > /usr/local/amanda/libexec/chg-manual:: cannot create /dev/tty: Device not > configu > red > amidxtaped: time 0.186: pid 5948 finish time Mon Jul 10 23:01:39 2006 > > > ## This is from the changer.debug > MT -> /usr/local/amanda/sbin/ammt -f > DD -> /usr/local/amanda/sbin/amdd > Args -> -slot next > -> rewind /dev/nsa0 > /dev/nsa0 rewind failed: Permission denied Looks like this is your main problem, you don't have permissions to the tape drive. Odd, since you say you are running amrecover as root. Is the tape actually loaded in the drive? Can you (from the command line) run 'mt -f /dev/nsa0 rewind' successfully? Frank > -> status /dev/nsa0 > /dev/nsa0 status failed: Permission denied > -> loaded <> > > > > JB > -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: communication between the amanda, dumper
[[ !!! PLEASE PLEASE -- KEEP THE CONVERSATION ON THE LIST It is not my job to answer these questions. Other more knowledgeable people on the list might jump in, and, they may even point out mistakes in my answer! ]] On 2006-07-10 15:54, silpa kala wrote: Hi, Thanks for ur information.I need some more clarifications. What is the input of chunker ? why the chunker is necessary? The input of the chunker is the backup data. Chunker writes this data to holdingdisk in small pieces. The main reason is that some filesystems cannot have files larger than 2 (or 4) Gigabyte. You may also have many holdingdisk, and chunker will write the chunks spread over the holdingdisk, not being limited by the size of one holdingdisk. In Amanda 2.4.5 and earlier, there was no "chunker" process: in those releases this feature was built in to dumper (see below). what is the input of dumper ? what is the output of dumper? For each backup, a "dumper" gets the instructions from driver to start that particular backup. There are many dumpers operating in parallel, each doing one disk-list-entry (DLE) at a time. The dumper is responsible to contact the client and get the backup started there. There is no real output of dumper, except the status of the backup when it is finished, which it communicates to driver. (So that driver can make an intellegent decision what to do next.) The purpose of a dumper program is to supervise the backup of one single disk-list-entry. Because Amanda starts many dumpers at once, there are many backups in progress at once too. TCP ports are used to connect transfer the data. (??I'm afraid I do not really understand "to connect transfer"...) Yes, the data is transferred using a TCP connection. Whether which module is used for the socket connection at the client side? (??What do you mean by "module"?) The server program "dumper" connects to the amanda UDP port 10080 and requests a "sendbackup". The server also sends a list of 2 or 3 TCP portnumbers containing the DATA, MESG (+error), and, if index was asked another one for the INDEX datastream. The client executes the correct handling program (for gnutar or for dump), making sure the stdout is connected to the DATA tcp port, and stderr is connected to the MESG tcp port and, if indexing is needed, the data-stream is actually duplicated with a tee-like mechanism, and fed in the gnutar/restore program with a table-of-contents option. The output of that stream is then connected to the tcp port that the server asked for the INDEX stream. Suppose if the backup size more than 65535 bytes. How the client module will send the backup? whether the backup data is divided into more than one packet. Please clarify ? This buffer size has nothing to do with the size of the backup. The send and receive buffer is a property of a TCP connection. (Phew! are you really sure you want to reorganize the socket code in Amanda?) Thanks In advance. -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: LVM snapshots
Just to be clear on the original question, xfs_freeze is not an lvm command. It's part of the xfs package xfsprogs. - toby bluhm philips medical systems, cleveland ohio [EMAIL PROTECTED] 440-483-5323 [EMAIL PROTECTED] wrote on 07/10/2006 03:10:52 AM: > On 2006-07-08 12:44, Josef Wolf wrote: > > On Fri, Jul 07, 2006 at 11:13:44PM +0200, Paul Bijnens wrote: > > > >> There are two approaches (maybe even many more -- I'm not the > >> specialist here). > >> > >> One approach is to let the snapshot mechanism understand the filesystem > >> and work on that level. That is how xfs and solaris ufs snapshots seem > >> to work. > >> > >> The other approach is a layer deeper: on the logical volume manager. > >> This implementation is not interested in where the inodes are located > >> or how directories and datablocks are layed out on disk. The LVM just > >> manages large blocks. The LVM2 snapshots in linux work on this layer. > > > > If the snapshot is on the driver layer, there is no way to ensure that > > the snapshot is consistent? Thus the snapshot would look like the power > > switch was turned off at that moment. Without journalling, data loss can > > be expected. I would rather not base my backups on such a mechanism... > > > >> Using method 1, you can probably get more optimized (quicker, using less > >> diskspace). Using method 2 is more general, and is is independent of > >> the filesystems on it. In my test setup I even managed to make a > >> snapshots of a vfat filesystem. > > > > I don't think vfat have journalling. > > > Yes, indeed! You better have journalling to be really useful. > > But after sync and with a "quiet" filesystem (if really necessary > unmount it) you *can* make a snapshot. > > It's not that snapshotting vfat is elegant, but it shows the power of > doing snapshots a on the blocklevel instead of on the filesystem level. > > > -- > Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 > Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 > http://www.xplanation.com/ email: [EMAIL PROTECTED] > *** > * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * > * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * > * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * > * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * > * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * > * ... "Are you sure?" ... YES ... Phew ... I'm out * > *** >
amrecover failures
Hello, I have recently configured Amanda to backup our data. I am now trying to restore some of the data that I have backed up, and I am having problems doing so. The client and server are the same machine. I have chg-manual configured so that the first and last slot are both 1. I am running amrecover as root. I am guessing that its because the changer think that it needs a different tape, but I cannot work out why. Any suggestions? amrecover> [cut] amrecover> extract Extracting files using tape drive /dev/nsa0 on host 10.0.0.2. The following tapes are needed: backup-1 backup-5 Restoring files into directory /usr/recover Continue [?/Y/n]? Y Extracting files using tape drive /dev/nsa0 on host 10.0.0.2. Load tape backup-1 now Continue [?/Y/n/s/t]? Y EOF, check amidxtaped..debug file on 10.0.0.2. amrecover: short block 0 bytes UNKNOWN file amrecover: Can't read file header extract_list - child returned non-zero status: 1 Continue [?/Y/n/r]? # ammt -f /dev/nsa0 status /dev/nsa0 status: ONLINE ds == 0x0001 er == 0x # amtape backup reset changer: got exit: 0 str: 1 /dev/nsa0 amtape: changer is reset, slot 1 is loaded. ## this is from /tmp/Amanda/amidxtaped Looking for tape backup-1... changer: got exit: 0 str: 0 1 1 changer_query: changer return was 1 1 changer_query: searchable = 0 changer_find: looking for backup-1 changer is searchable = 0 changer: got exit: 2 str: /usr/local/amanda/libexec/chg-manual: cannot create /dev/tty: Device not configured amidxtaped: could not load slot /usr/local/amanda/libexec/chg-manual:: cannot create /dev/tty: Device not configured amidxtaped: time 0.186: could not load slot /usr/local/amanda/libexec/chg-manual:: cannot create /dev/tty: Device not configu red amidxtaped: time 0.186: pid 5948 finish time Mon Jul 10 23:01:39 2006 ## This is from the changer.debug MT -> /usr/local/amanda/sbin/ammt -f DD -> /usr/local/amanda/sbin/amdd Args -> -slot next -> rewind /dev/nsa0 /dev/nsa0 rewind failed: Permission denied -> status /dev/nsa0 /dev/nsa0 status failed: Permission denied -> loaded <> JB
using amflush
Dear all, in my Amanda test lab, while trying to sort out my issues with hardware vs. software compression, amdump didn't run on 5 July last week (I subsequently put Amanda on hold to prevent amdump from running throughout the rest of the week). So now I have a directory on the holding disk named 20060705, and I know that I'm really supposed to flush this to tape. However, I don't actually care about that backup, and just need to get rid of it. I noticed that amflush's man pages say: "Amflush will look in the holding disks specified by the amanda.conf file in /etc/amanda/config for any non-empty Amanda work directories. It then prompts you to select a directory or to process all of the directories. The work directories in the holding disks are named by the date at the time amdump was run, e.g. 19910215." To get rid of that dump, can I simply delete that directory without harming Amanda or confusing anything...? Thank you. Joe -- View this message in context: http://www.nabble.com/using-amflush-tf1918197.html#a5251020 Sent from the Amanda - Users forum at Nabble.com.
Re: communication between the amanda, dumper
[ Please keep the information on the list -- other people may help too. ] On 2006-07-10 11:56, silpa kala wrote: Hi, I need some clarification on Amanda Internals. Driver will initiate the chunker process and driver will provide some information to the chunker process like name of the file for holding disk, hostname, level, datastamp etc., How the driver will send the information to the chunker? either through pipes ?I copied some lines Assuming you are using amanda 2.5.0p2... By UNIX sockets, see server-src/driverio.c lines 169 et.seq. from the amdump logfile. driver: send-cmd time 4.768 to chunker0: PORT-WRITE 00-1 /home/20060705194408/hostname._home_amanda-2.5.0p1-20060428_server-src.1 hostname feff9ffe07 /home/amanda-2.5.0p1-20060428/ server-src 1 2006:7:6:0:42:13 1048576 GNUTAR 6624 |;auth=BSD;no-record;index; chunker is trying to connect to one privileged port no. Driver will initiate the dumper process and driver will provide some information to dumper port no to connect(what chunker initiated for the particular port), hostname etc., driver: send-cmd time 4.778 to dumper0: PORT-DUMP 00-1 784 hostname feff9ffe07 /home/amanda-2.5.0p1-20060428/server-src NODEVICE 1 2006:7:6:0:42:13 GNUTAR |;auth=BSD;no-record;index; Is there any socket communication is required between the chunker and driver ? I got so much of confusion Chunker needs to be able to communicate some result back. Did the dump succeed? Need more diskspace? etc. See all the calls to putresult() in chunker.c with the amdump.1 log file. The contents i am sending here from the log file chunker: stream_accept: connection from 127.0.0.1.45601 dumper: stream_client: connected to 127.0.0.1.784 chunker: try_socksize: receive buffer size is 32768 dumper: stream_client: our side is 0.0.0.0.45601 dumper: try_socksize: send buffer size is 65536 What is the significance of this. Please explain? I'm still not sure what is unclear to you here. First you have to understand that there are multiple chunkers/dumpers. And the output of these is not sequential but intermingled in this single log file. Not perfect, indeed -- AAPW (all applicable patches welcome). Is that where the confusion is coming from? In the beginning all dumpers/chunkers are starting almost at once. Resulting in a lot of intermingled messages from all these processes. To get less confusion, start a backup with "inparralel 1". Then you get only one instance of each process, making the sequence much easier to follow. I need these clarifications. Please help me out to understand these funda. Did you have a look at the source code? I assume you are not satisfied with the use of the sockets as is now. What exactly are you trying to solve/fix ? -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Disapearing amanda label
Hello, A very strange thing just happened. I had a tape labeled ESSDUMP10 but I did amcheck and I got: su - backup "amcheck weekly -s weekly" Amanda Tape Server Host Check - Holding disk /BACKUP/holding: 72751 MB disk space available, using 72751 MB slot 1: read label `ESSDUMP08', date `20060627' slot 2: read label `ESSDUMP09', date `20060701' slot 3: not an amanda tape slot 4: read label `ESSDUMP11', date `20060708' slot 5: read label `ESSDUMP12', date `20060710' slot 6: read label `ESSDUMP13', date `20060520 On the last weekend the backup worked fine. I think that all the data is there (I hope). Is there a way to recover the label and correct date? The only thing I did was update from version 2.5.0 to 2.5.0p2 (i'm using the debian packages) Also get: amrestore /dev/nst0 amrestore: short file header block: 42 bytes amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: error reading file header: Input/output error Does anyone have an idea what could have trigered this? Best regards, Luis
Re: communication between the amanda, dumper
On 2006-07-10 10:31, silpa kala wrote: Hi, Please clarify me the below statements amandad: try_socksize: send buffer size is 65536 amandad: try_socksize: receive buffer size is 65536 amandad: time 4.786: bind_portrange2: trying port=778 amandad: time 4.786: stream_server: waiting for connection: 0.0.0.0.778 Where do I start? With the basic TCP/IP knowledge? Or with how Amanda uses port 778? or clarify the use of a buffer of size 65536 ? [...] dumper: try_socksize: send buffer size is 65536 dumper: try_socksize: receive buffer size is 65536 Please provide me the details why the importance of the socket communication. For communication between the parts of the program :) First explain us what is your problem with that. And you want to replace with something else? Why? What are trying to do? On the other hand, all of the answers are found in the source code. At least that is where I would get them. -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
communication between the amanda, dumper
Hi, Please clarify me the below statements amandad: try_socksize: send buffer size is 65536 amandad: try_socksize: receive buffer size is 65536 amandad: time 4.786: bind_portrange2: trying port=778 amandad: time 4.786: stream_server: waiting for connection: 0.0.0.0.778 amandad: try_socksize: send buffer size is 65536 amandad: try_socksize: receive buffer size is 65536 amandad: time 4.793: bind_portrange2: trying port=778 amandad: time 4.797: bind_portrange2: trying port=779 amandad: time 4.797: stream_server: waiting for connection: 0.0.0.0.779 amandad: try_socksize: send buffer size is 65536 amandad: try_socksize: receive buffer size is 65536 amandad: time 4.804: bind_portrange2: trying port=778 amandad: time 4.808: bind_portrange2: trying port=779 amandad: time 4.813: bind_portrange2: trying port=781 amandad: time 4.813: stream_server: waiting for connection: 0.0.0.0.781 amandad: time 4.813: sending REP pkt: amdump log file : dumper: stream_client: connected to 127.0.0.1.784 chunker: try_socksize: receive buffer size is 32768 dumper: stream_client: our side is 0.0.0.0.45601 dumper: try_socksize: send buffer size is 65536 dumper: bind_portrange2: trying port=778 dumper: dgram_bind: socket bound to 0.0.0.0.778 dumper: stream_client: connected to 192.61.224.88.778 dumper: stream_client: our side is 0.0.0.0.35926 dumper: try_socksize: send buffer size is 65536 dumper: try_socksize: receive buffer size is 65536 dumper: stream_client: connected to 192.61.224.88.779 dumper: stream_client: our side is 0.0.0.0.57235 dumper: try_socksize: send buffer size is 65536 dumper: try_socksize: receive buffer size is 65536 dumper: stream_client: connected to 192.61.224.88.781 dumper: stream_client: our side is 0.0.0.0.34217 dumper: try_socksize: send buffer size is 65536 dumper: try_socksize: receive buffer size is 65536 Please provide me the details why the importance of the socket communication. Thanks & Regards, silpakala __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
dumper, chunker and amandad communication
Hi, I need some clarification on Amanda Internals. Driver will initiate the chunker process and driver will provide some information to the chunker process like name of the file for holding disk, hostname, level, datastamp etc., How the driver will send the information to the chunker? either through pipes ?I copied some lines from the amdump logfile. driver: send-cmd time 4.768 to chunker0: PORT-WRITE 00-1 /home/20060705194408/hostname._home_amanda-2.5.0p1-20060428_server-src.1 hostname feff9ffe07 /home/amanda-2.5.0p1-20060428/ server-src 1 2006:7:6:0:42:13 1048576 GNUTAR 6624 |;auth=BSD;no-record;index; chunker is trying to connect to one privileged port no. Driver will initiate the dumper process and driver will provide some information to dumper port no to connect(what chunker initiated for the particular port), hostname etc., driver: send-cmd time 4.778 to dumper0: PORT-DUMP 00-1 784 hostname feff9ffe07 /home/amanda-2.5.0p1-20060428/server-src NODEVICE 1 2006:7:6:0:42:13 GNUTAR |;auth=BSD;no-record;index; Is there any socket communication is required between the chunker and driver ? I got so much of confusion with the amdump.1 log file. The contents i am sending here from the log file chunker: stream_accept: connection from 127.0.0.1.45601 dumper: stream_client: connected to 127.0.0.1.784 chunker: try_socksize: receive buffer size is 32768 dumper: stream_client: our side is 0.0.0.0.45601 dumper: try_socksize: send buffer size is 65536 What is the significance of this. Please explain? Amandad log file is also having the information below: amandad: try_socksize: send buffer size is 65536 amandad: try_socksize: receive buffer size is 65536 I think the above two log information is interconnected, what kind of information is sending and receiving by dumper or chunker or amandad? I need these clarifications. Please help me out to understand these funda. Thanks & Regards, Silpakala __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: LVM snapshots
On 2006-07-08 12:44, Josef Wolf wrote: On Fri, Jul 07, 2006 at 11:13:44PM +0200, Paul Bijnens wrote: There are two approaches (maybe even many more -- I'm not the specialist here). One approach is to let the snapshot mechanism understand the filesystem and work on that level. That is how xfs and solaris ufs snapshots seem to work. The other approach is a layer deeper: on the logical volume manager. This implementation is not interested in where the inodes are located or how directories and datablocks are layed out on disk. The LVM just manages large blocks. The LVM2 snapshots in linux work on this layer. If the snapshot is on the driver layer, there is no way to ensure that the snapshot is consistent? Thus the snapshot would look like the power switch was turned off at that moment. Without journalling, data loss can be expected. I would rather not base my backups on such a mechanism... Using method 1, you can probably get more optimized (quicker, using less diskspace). Using method 2 is more general, and is is independent of the filesystems on it. In my test setup I even managed to make a snapshots of a vfat filesystem. I don't think vfat have journalling. Yes, indeed! You better have journalling to be really useful. But after sync and with a "quiet" filesystem (if really necessary unmount it) you *can* make a snapshot. It's not that snapshotting vfat is elegant, but it shows the power of doing snapshots a on the blocklevel instead of on the filesystem level. -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
