Re: Amflush Problem - Again!
Hello: About your questions about clipping the contents - No, that's the full uncensored log/output of amflush :) And about the problem, I found the solution - a weird one. I moved stuff from 20060216 out of the holding space to some other place and then amflush worked. I am wondering what could be going wrong here. I haven't still tried amflushing 20060216 contents to the tape yet, but I feel it might just work too. I post the results to this list soon. But, what is making amflush not flush data to tape? Incase if it is facing problems maybe from OS or with something else, shouldn't it complain? Regards, Rohit - Original Message - From: "Gene Heskett" <[EMAIL PROTECTED]> To: Sent: Friday, March 03, 2006 10:22 PM Subject: Re: Amflush Problem - Again! On Friday 03 March 2006 09:01, Jon LaBadie wrote: I have no suggestion Rohit, But a question for developers. Amflush output: -bash-2.05b$ /usr/sbin/amflush -f DailySet1 Scanning /backup/amanda_hold/DailySet1... 20060216: found Amanda directory. 20060223: found Amanda directory. 20060302: found Amanda directory. Multiple Amanda directories, please pick one by letter: A. 20060216 B. 20060223 C. 20060302 Select directories to flush [A..C]: [ALL] B C Today is: 20060303 Flushing dumps in 20060223, 20060302 to tape drive "/dev/nst0". Expecting tape TLS-Set-1-05 or a new tape. (The last dumps were to tape TLS-Set -1-04) Are you sure you want to do this [yN]? y amflush: datestamp 20060303 driver: pid 15642 executable driver version 2.4.3 driver: send-cmd time 0.005 to taper: START-TAPER 20060303 driver: adding holding disk 0 dir /backup/amanda_hold/DailySet1 size 2234040 reserving 2234040 out of 2234040 for degraded-mode dumps taper: pid 15643 executable taper version 2.4.3 taper: page size is 4096 taper: buffer size is 32768 taper: buffer[00] at 0x400d5000 taper: buffer[01] at 0x400dd000 taper: buffer[02] at 0x400e5000 taper: buffer[03] at 0x400ed000 taper: buffer[04] at 0x400f5000 taper: buffer[05] at 0x400fd000 taper: buffer[06] at 0x40105000 taper: buffer[07] at 0x4010d000 taper: buffer[08] at 0x40115000 taper: buffer[09] at 0x4011d000 taper: buffer[10] at 0x40125000 taper: buffer[11] at 0x4012d000 taper: buffer[12] at 0x40135000 taper: buffer[13] at 0x4013d000 taper: buffer[14] at 0x40145000 taper: buffer[15] at 0x4014d000 taper: buffer[16] at 0x40155000 taper: buffer[17] at 0x4015d000 taper: buffer[18] at 0x40165000 taper: buffer[19] at 0x4016d000 taper: buffer structures at 0x40175000 for 240 bytes taper: read label `TLS-Set-1-05' date `X' taper: wrote label `TLS-Set-1-05' date `20060303' Why is so much detail being shown to the user of amflush? Do they really care about the taper buffers? Do they really care that the driver is starting taper? Aren't those messages more suitable for a silent log file or a debug file? BTW driver seems like it is doing unneeded things for an amflush, like setting a degraded mode, allocating holding disk, ... I agree Jon, this is too much detail and not enough info at the same time. To the original poster Rohit: Did you purchance clip it off just about the place where it might have gotten interesting? I feel that what we want to know may be there, but we didn't get to see it. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: Odd amrecover and amverify issue in 2.5.0b2
Anthony, On Thursday 02 March 2006 21:30, Anthony Valentine wrote: > When I run amverify, I get errors at the beginning and the end of the > status mail, however it shows the complete tape listing in the middle. > Here it the output, edited for length (let me know if you want to see > the entire output): Two questions: 1) Did you rewind the tape before running amverify? It will not rewind the tape itself. 2) Did Amanda hit the end of the tape when it was being written, or did it use the tape only partially? My guess is that you did not rewind the tape (if not, do so, and try it again), and that the tape was completely used; in that case, the last file on the tape will show up as short. Cheers, --Ian -- Wiki for Amanda documentation: http://wiki.zmanda.com/
Re: to configure or not to configure this is the question
If you make the directory to be backed up visible to the backup server over samba, it should be as simple as adding that directories to you DLE's. Assuming of course that you have media that has space to handle the added entry. Making sure the Windows server dir is visible with the right permission could be some work, depending on your configuration. Thanks tk gil naveh wrote: Hi, We have Amanda backing up our Solaris servers for about a year. So far we are very happy with Amanda. Recently I was requested to use Amanda to backup some of our Window server. In order to do so, I have to configure Amanda with Smbclient. Does it mean that I have do – reconfigure + make + make install from start – or is there another way more graceful to add the Smbclient configuration to Amanda. Many thanks, Gil -- Ram "TK" Krishnamurthy Amanda Wiki: http://wiki.zmanda.com Amanda Forums:http://forums.zmanda.com
Re: to configure or not to configure this is the question
On Fri, Mar 03, 2006 at 10:07:23AM -0600, gil naveh wrote: > > Recently I was requested to use Amanda to backup some of our Window server. > > In order to do so, I have to configure Amanda with Smbclient. > > Does it mean that I have do - reconfigure + make + make install from start - > or is there another way more graceful to add the Smbclient configuration to > Amanda. > I looked at my configure command line and see nothing about samba/smbclient. Perhaps more important is whether or not configure was able to find smbclient when it ran. In your source tree, check if your Makefile's (built by configure) have a line like 'SAMBA_CLIENT = /usr/sfw/bin/smbclient'. BTW this should be on the amanda client which will access the windows system. That amanda client may or may not also be your amanda server. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: to configure or not to configure this is the question
On Friday 03 March 2006 11:07, gil naveh wrote: >Hi, > > > >We have Amanda backing up our Solaris servers for about a year. So far > we are very happy with Amanda. > >Recently I was requested to use Amanda to backup some of our Window > server. > >In order to do so, I have to configure Amanda with Smbclient. > >Does it mean that I have do - reconfigure + make + make install from > start - or is there another way more graceful to add the Smbclient > configuration to Amanda. If you still have the src's that should be easy enough. You did use a script to configure it originally I hope? I have for years, so installing each new snapshot as it is released is a 10 minute job job here, worst case. I've even posted that script here a few times, a search of the list archive should spit it out. But I switched to vtapes about a year ago, so my script got simplified. OTOH, if not, you may want to consider doing it in two steps if there is room for the windows data available on the solaris drives, one could do an rsync of the windows stuff first, and then backup the local version. Samba doesn't handle ctimes well, so you'll quite often get level 0 backups every night on files that have not changed. rsync'd versions of a file will not be updated if there has been no change to the original, but this is not determined from file dates, rsync uses crc checksums to determine changes. If a change has occurred the new version is kept and the old one deleted as it works. Therefore amanda incrementals work with the exception that if a change has occurred the whole file is new and therefore gets a level 0. This is usually better than samba doing a level 0 of nearly everything in most cases. Also, for recovery, rsync is quite easily reversable. We've been doing rsync only for several machines at the tv station and its worked rather nicely, with hardware failure recoveries often recovered the same day if good hardware is on the shelf. We run rsync into day of week directories on a big raid so we can back up before the onset of a drive failure to recover. >Many thanks, > >Gil -- Cheers Gil, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: Amflush Problem - Again!
On Friday 03 March 2006 09:01, Jon LaBadie wrote: >I have no suggestion Rohit, But a question for developers. > >> Amflush output: >> -bash-2.05b$ /usr/sbin/amflush -f DailySet1 >> Scanning /backup/amanda_hold/DailySet1... >> 20060216: found Amanda directory. >> 20060223: found Amanda directory. >> 20060302: found Amanda directory. >> >> Multiple Amanda directories, please pick one by letter: >> A. 20060216 >> B. 20060223 >> C. 20060302 >> Select directories to flush [A..C]: [ALL] B C >> >> Today is: 20060303 >> Flushing dumps in 20060223, 20060302 to tape drive "/dev/nst0". >> Expecting tape TLS-Set-1-05 or a new tape. (The last dumps were to >> tape TLS-Set >> -1-04) >> Are you sure you want to do this [yN]? y >> amflush: datestamp 20060303 >> driver: pid 15642 executable driver version 2.4.3 >> driver: send-cmd time 0.005 to taper: START-TAPER 20060303 >> driver: adding holding disk 0 dir /backup/amanda_hold/DailySet1 size >> 2234040 reserving 2234040 out of 2234040 for degraded-mode dumps >> taper: pid 15643 executable taper version 2.4.3 >> taper: page size is 4096 >> taper: buffer size is 32768 >> taper: buffer[00] at 0x400d5000 >> taper: buffer[01] at 0x400dd000 >> taper: buffer[02] at 0x400e5000 >> taper: buffer[03] at 0x400ed000 >> taper: buffer[04] at 0x400f5000 >> taper: buffer[05] at 0x400fd000 >> taper: buffer[06] at 0x40105000 >> taper: buffer[07] at 0x4010d000 >> taper: buffer[08] at 0x40115000 >> taper: buffer[09] at 0x4011d000 >> taper: buffer[10] at 0x40125000 >> taper: buffer[11] at 0x4012d000 >> taper: buffer[12] at 0x40135000 >> taper: buffer[13] at 0x4013d000 >> taper: buffer[14] at 0x40145000 >> taper: buffer[15] at 0x4014d000 >> taper: buffer[16] at 0x40155000 >> taper: buffer[17] at 0x4015d000 >> taper: buffer[18] at 0x40165000 >> taper: buffer[19] at 0x4016d000 >> taper: buffer structures at 0x40175000 for 240 bytes >> taper: read label `TLS-Set-1-05' date `X' >> taper: wrote label `TLS-Set-1-05' date `20060303' > >Why is so much detail being shown to the user of amflush? >Do they really care about the taper buffers? >Do they really care that the driver is starting taper? >Aren't those messages more suitable for a silent log file >or a debug file? > >BTW driver seems like it is doing unneeded things for >an amflush, like setting a degraded mode, allocating >holding disk, ... I agree Jon, this is too much detail and not enough info at the same time. To the original poster Rohit: Did you purchance clip it off just about the place where it might have gotten interesting? I feel that what we want to know may be there, but we didn't get to see it. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
to configure or not to configure this is the question
Hi, We have Amanda backing up our Solaris servers for about a year. So far we are very happy with Amanda. Recently I was requested to use Amanda to backup some of our Window server. In order to do so, I have to configure Amanda with Smbclient. Does it mean that I have do – reconfigure + make + make install from start – or is there another way more graceful to add the Smbclient configuration to Amanda. Many thanks, Gil
Re: ip_conntrack_amanda problem with Linux kernel 2.6
Yes, apart from loading "ip_conntrack_amanda" module I also have next rule on the iptables config: ACCEPT all -- anywhere anywherestate RELATED,ESTABLISHED So I don't know if this is a specific issue of the Scientific Linux distribution, Is anybody using amanda client on a SCientific Linux 4.x with iptables activated? Thanks again Jorge On Fri, 2006-03-03 at 14:57, Matt Hyclak wrote: > On Fri, Mar 03, 2006 at 02:39:50PM +0100, Jorge Izquierdo (UAM) enlightened > us: > > We use Scientific Linux 4.2 with kernel 2.6.9-22.0.1.EL and also with > > Scientific Linux 4.0 2.6.9-5.0.5.EL the same problem > > > > Not sure what to tell you then, these kernels all worked on my CentOS boxes. > You are allowing RELATED traffic back in to the box, right? > > Matt -- Jorge Izquierdo e-mail: [EMAIL PROTECTED] Laboratorio de FÃsica de Altas EnergÃas Universidad Autonoma de Madrid.Phone: 34 91 497 3976 Cantoblanco, 28049 Madrid, Spain.
Re: question about external drives
On Friday 03 March 2006 04:13, Geert Uytterhoeven wrote: > That sounds actually good to me... > - disk capacity is increasing a lot, > - disk transfer speeds are also increasing, but less compared to > capacity, - disk latency (seek times) is improving very slowly. All of this is true, but the time it takes to seek across a disk is still only a few ms. If you consider latency as "time to seek across so many MB", then seek times are actually improving considerably. Consider: Hard disk: 6ms to seek across 200GB (.03 ms/GB) DVD: 125ms to seek across 2.2GB (56 ms/GB) CD: 95ms to seek across 325MB (290 ms/GB) As you can see, the penalty of a seek in data terms is three orders of magnitude higher for DVD than for a modern hard disk. You will not get better performance on your hard disk by using UDF. Cheers, --Ian -- Wiki for Amanda documentation: http://wiki.zmanda.com/
Re: Amflush Problem - Again!
I have no suggestion Rohit, But a question for developers. > > Amflush output: > -bash-2.05b$ /usr/sbin/amflush -f DailySet1 > Scanning /backup/amanda_hold/DailySet1... > 20060216: found Amanda directory. > 20060223: found Amanda directory. > 20060302: found Amanda directory. > > Multiple Amanda directories, please pick one by letter: > A. 20060216 > B. 20060223 > C. 20060302 > Select directories to flush [A..C]: [ALL] B C > > Today is: 20060303 > Flushing dumps in 20060223, 20060302 to tape drive "/dev/nst0". > Expecting tape TLS-Set-1-05 or a new tape. (The last dumps were to tape > TLS-Set > -1-04) > Are you sure you want to do this [yN]? y > amflush: datestamp 20060303 > driver: pid 15642 executable driver version 2.4.3 > driver: send-cmd time 0.005 to taper: START-TAPER 20060303 > driver: adding holding disk 0 dir /backup/amanda_hold/DailySet1 size 2234040 > reserving 2234040 out of 2234040 for degraded-mode dumps > taper: pid 15643 executable taper version 2.4.3 > taper: page size is 4096 > taper: buffer size is 32768 > taper: buffer[00] at 0x400d5000 > taper: buffer[01] at 0x400dd000 > taper: buffer[02] at 0x400e5000 > taper: buffer[03] at 0x400ed000 > taper: buffer[04] at 0x400f5000 > taper: buffer[05] at 0x400fd000 > taper: buffer[06] at 0x40105000 > taper: buffer[07] at 0x4010d000 > taper: buffer[08] at 0x40115000 > taper: buffer[09] at 0x4011d000 > taper: buffer[10] at 0x40125000 > taper: buffer[11] at 0x4012d000 > taper: buffer[12] at 0x40135000 > taper: buffer[13] at 0x4013d000 > taper: buffer[14] at 0x40145000 > taper: buffer[15] at 0x4014d000 > taper: buffer[16] at 0x40155000 > taper: buffer[17] at 0x4015d000 > taper: buffer[18] at 0x40165000 > taper: buffer[19] at 0x4016d000 > taper: buffer structures at 0x40175000 for 240 bytes > taper: read label `TLS-Set-1-05' date `X' > taper: wrote label `TLS-Set-1-05' date `20060303' > Why is so much detail being shown to the user of amflush? Do they really care about the taper buffers? Do they really care that the driver is starting taper? Aren't those messages more suitable for a silent log file or a debug file? BTW driver seems like it is doing unneeded things for an amflush, like setting a degraded mode, allocating holding disk, ... -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: ip_conntrack_amanda problem with Linux kernel 2.6
On Fri, Mar 03, 2006 at 02:39:50PM +0100, Jorge Izquierdo (UAM) enlightened us: > We use Scientific Linux 4.2 with kernel 2.6.9-22.0.1.EL and also with > Scientific Linux 4.0 2.6.9-5.0.5.EL the same problem > Not sure what to tell you then, these kernels all worked on my CentOS boxes. You are allowing RELATED traffic back in to the box, right? Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263
Re: ip_conntrack_amanda problem with Linux kernel 2.6
We use Scientific Linux 4.2 with kernel 2.6.9-22.0.1.EL and also with Scientific Linux 4.0 2.6.9-5.0.5.EL the same problem Jorge On Fri, 2006-03-03 at 13:15, Matt Hyclak wrote: > On Fri, Mar 03, 2006 at 01:04:11PM +0100, Jorge Izquierdo (UAM) enlightened > us: > > We are using amanda software to backup our servers and workstations > > onour department and we have a problem with the iptables configurations > > ofsome of the amanda clients. > > > > The problem is with the stations with Linux with kernel version > > 2.6. Using the same configuration as in Linux with kernel 2.4 for the > > iptables software the ones with kernel 2.6 reports an error when trying > > to make the backup because the server cannot connect to TCP ports > > suggested by the client. Those ports are not opened by default on the > > iptables configuration, the ip_conntrack_amanda module loaded from the > > /etc/sysconfig/iptables-config file, should open those ports (ramdomly > > chosed by the client) related to the first connection. > > > > So it seems that the ip_conntrack_amanda module on kernel 2.6 does not > > work properly. Any ideas? Any bug? One posible solution could be to open > > the range of ports from which client randomly select the port to dump > > the backup to server. Does anybody knows what this range is in the > > amanda-client RPM package or how to discover it? > > > > Thanks in advance if anybody may help me. > > > > What version of 2.6? There was an off-by-one type of error in Fedora Core > 2's kernels at one point around 2.6.5, I think. ip_conntrack_amanda works > just fine on my CentOS (RHEL) 4 machines, which is 2.6.9. All I do on > clients is allow udp 10080 through and load ip_conntrack_amanda. > > Matt -- Jorge Izquierdo e-mail: [EMAIL PROTECTED] Laboratorio de FÃsica de Altas EnergÃas Universidad Autonoma de Madrid.Phone: 34 91 497 3976 Cantoblanco, 28049 Madrid, Spain.
Amflush Problem - Again!
Hello All:
After a very long time, maybe after 2 years or so, I started seeing amflush
problems again. No configuration was changed and nothing was touched too.
Amflush refuses to backup stuff left in the holding space to the tape. My
tape drive blinks with activity as soon as I start amflush, but it soon
stops. I checked all the logs, but I do not see any errors. I also tried
changing the permissions of the files left in the hold.. even that didn't
help.
Can anyone please let me what is going wrong? Here is my OS/Amanda info:
OS: Redhat 9.0
Kernel: 2.4.20-30.9
Amanda: amanda-client-2.4.3-4, amanda-server-2.4.3-4,amanda-2.4.3-4
Amanda outputs:
*** THE DUMPS DID NOT FINISH PROPERLY!
The dumps were flushed to tape TLS-Set-1-05.
The next tape Amanda expects to use is: TLS-Set-1-06.
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 0:00
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min)0:00 0:00 0:00
Tape Size (meg) 0.00.00.0
Tape Used (%) 0.00.00.0
Filesystems Taped 0 0 0
Avg Tp Write Rate (k/s) -- -- --
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
Server1 /etc NO FILE TO FLUSH -
Server1 /hNO FILE TO FLUSH -
Server1 /vl NO FILE TO FLUSH -
Server1 /vm NO FILE TO FLUSH -
Server1 /vw NO FILE TO FLUSH -
Server2 /etc NO FILE TO FLUSH -
Server2 /h2AM NO FILE TO FLUSH -
Server2 /h2NZ NO FILE TO FLUSH -
Server2 /h3NZ NO FILE TO FLUSH -
Server2 /hAM NO FILE TO FLUSH -
Server2 /hNZ NO FILE TO FLUSH -
Server2 /vm NO FILE TO FLUSH -
Server2 /vw NO FILE TO FLUSH -
Server3 /etc NO FILE TO FLUSH -
Server3 /hAM NO FILE TO FLUSH -
Server3 /hNZ NO FILE TO FLUSH -
Server3 /rp NO FILE TO FLUSH -
Server3 /vm NO FILE TO FLUSH -
Server3 /vw NO FILE TO FLUSH -
(brought to you by Amanda version 2.4.3)
[EMAIL PROTECTED] DailySet1]# ls -lR
.:
total 16
drwxrwxrwx2 amanda disk 4096 Feb 16 03:32 20060216
drwxrwxrwx2 amanda disk 4096 Feb 23 04:40 20060223
drwx--2 amanda disk 4096 Mar 2 05:24 20060302
drwx--2 amanda disk 4096 Mar 3 10:55 20060303
./20060216:
total 3466424
-rwxrwxrwx1 amanda disk 3546147489 Feb 16 02:27 Server3._hNZ.0
./20060223:
total 5354568
-rwxrwxrwx1 amanda disk 5477712861 Feb 23 04:40 Server2._h2AM.0
./20060302:
total 3577020
-rw---1 amanda disk 3659285789 Mar 2 05:24 Server3._hAM.0
./20060303:
total 0
Amflush output:
-bash-2.05b$ /usr/sbin/amflush -f DailySet1
Scanning /backup/amanda_hold/DailySet1...
20060216: found Amanda directory.
20060223: found Amanda directory.
20060302: found Amanda directory.
Multiple Amanda directories, please pick one by letter:
A. 20060216
B. 20060223
C. 20060302
Select directories to flush [A..C]: [ALL] B C
Today is: 20060303
Flushing dumps in 20060223, 20060302 to tape drive "/dev/nst0".
Expecting tape TLS-Set-1-05 or a new tape. (The last dumps were to tape
TLS-Set
-1-04)
Are you sure you want to do this [yN]? y
amflush: datestamp 20060303
driver: pid 15642 executable driver version 2.4.3
driver: send-cmd time 0.005 to taper: START-TAPER 20060303
driver: adding holding disk 0 dir /backup/amanda_hold/DailySet1 size 2234040
reserving 2234040 out of 2234040 for degraded-mode dumps
taper: pid 15643 executable taper version 2.4.3
taper: page size is 4096
taper: buffer size is 32768
taper: buffer[00] at 0x400d5000
taper: buffer[01] at 0x400dd000
taper: buffer[02] at 0x400e5000
taper: buffer[03] at 0x400ed000
taper: buffer[04] at 0x400f5000
taper
Re: ip_conntrack_amanda problem with Linux kernel 2.6
On Fri, Mar 03, 2006 at 01:04:11PM +0100, Jorge Izquierdo (UAM) enlightened us: > We are using amanda software to backup our servers and workstations > onour department and we have a problem with the iptables configurations > ofsome of the amanda clients. > > The problem is with the stations with Linux with kernel version > 2.6. Using the same configuration as in Linux with kernel 2.4 for the > iptables software the ones with kernel 2.6 reports an error when trying > to make the backup because the server cannot connect to TCP ports > suggested by the client. Those ports are not opened by default on the > iptables configuration, the ip_conntrack_amanda module loaded from the > /etc/sysconfig/iptables-config file, should open those ports (ramdomly > chosed by the client) related to the first connection. > > So it seems that the ip_conntrack_amanda module on kernel 2.6 does not > work properly. Any ideas? Any bug? One posible solution could be to open > the range of ports from which client randomly select the port to dump > the backup to server. Does anybody knows what this range is in the > amanda-client RPM package or how to discover it? > > Thanks in advance if anybody may help me. > What version of 2.6? There was an off-by-one type of error in Fedora Core 2's kernels at one point around 2.6.5, I think. ip_conntrack_amanda works just fine on my CentOS (RHEL) 4 machines, which is 2.6.9. All I do on clients is allow udp 10080 through and load ip_conntrack_amanda. Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263
ip_conntrack_amanda problem with Linux kernel 2.6
Hi everybody! We are using amanda software to backup our servers and workstations onour department and we have a problem with the iptables configurations ofsome of the amanda clients. The problem is with the stations with Linux with kernel version 2.6. Using the same configuration as in Linux with kernel 2.4 for the iptables software the ones with kernel 2.6 reports an error when trying to make the backup because the server cannot connect to TCP ports suggested by the client. Those ports are not opened by default on the iptables configuration, the ip_conntrack_amanda module loaded from the /etc/sysconfig/iptables-config file, should open those ports (ramdomly chosed by the client) related to the first connection. So it seems that the ip_conntrack_amanda module on kernel 2.6 does not work properly. Any ideas? Any bug? One posible solution could be to open the range of ports from which client randomly select the port to dump the backup to server. Does anybody knows what this range is in the amanda-client RPM package or how to discover it? Thanks in advance if anybody may help me. Jorge -- Jorge Izquierdo e-mail: [EMAIL PROTECTED] Laboratorio de FÃsica de Altas EnergÃas Universidad Autonoma de Madrid.Phone: 34 91 497 3976 Cantoblanco, 28049 Madrid, Spain.
Re: question about external drives
On Thu, 2 Mar 2006, Ian Turner wrote:
> On Thursday 02 March 2006 12:31, you wrote:
> > Does UDF support a modern permissions system though? I thought it
> > didn't, because it was designed for optical media...
>
> Yes. It is designed to be a superset of all common filesystems, feature-wise.
> So it has support for NT ACLs, POSIX ACLs, UNIX permissions, Apple file types
> and resource forks, etc.
>
> I dunno if Windows is OK with UDF on a hard disk, though I have heard of
> seeing it on USB flash sticks.
>
> Also, UDF is optimized for devices with high seek times -- it tries very hard
> to avoid fragmentation, which might actually be suboptimal on hard disks.
That sounds actually good to me...
A while ago I read somewhere that we should start to treat hard drives more
like tape drives:
- disk capacity is increasing a lot,
- disk transfer speeds are also increasing, but less compared to capacity,
- disk latency (seek times) is improving very slowly.
Hence currently it takes much longer to copy an average disk than it took a few
years ago.
And while raw transfer speeds are great, as soon as you need a seek, it
degrades a lot.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
