Re: Re: Cyrillic support for index files
>Most systems have a way to set the default "LC" environment
>variables (of which LANG is one) during boot, certainly before
>the network and inet is started. Perhaps this needs to be
>set on your hosts.
I try to set default environment for all system in /etc/sysconfig/i18n
SYSFONTACM=koi8-r
LANGUAGE=ru_RU.KOI8-R
SYSFONT=UniCyr_8x16
LANG=ru_RU.KOI8-R
This doesn't help...:-(
> Alternatively, and I don't know that this is allowed, in your
> {x}inetd config where it specifies the amandad command, you
> might be able to specify it like:
>
> LANG=XXX /pathto/amandad
[EMAIL PROTECTED] john]# cat /etc/xinetd.d/am*
# default: off
# description: The client for the Amanda backup system.\
# This must be on for systems being backed up\
# by Amanda.
service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= amanda
group = disk
server = /usr/lib/amanda/amandad
disable = no
only_from += 192.168.0.0/24
# bind= 192.168.0.2
env += LANG=ru_RU.KOI8-R LANGUAGE=ru_RU.KOI8-R
MPAGE=-CKOI8-R
passenv =
}
# default: off
#
# description: Part of the Amanda server package
service amandaidx
{
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
server = /usr/lib/amanda/amindexd
disable = no
only_from += 192.168.0.0/24
# bind= 192.168.0.2
env += LANG=ru_RU.KOI8-R LANGUAGE=ru_RU.KOI8-R
MPAGE=-CKOI8-R
passenv =
}
# default: off
#
# description: Part of the amanda server package
#
service amidxtape
{
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
server = /usr/lib/amanda/amidxtaped
disable = no
only_from += 192.168.0.0/24
# bind= 192.168.0.2
env += LANG=ru_RU.KOI8-R LANGUAGE=ru_RU.KOI8-R
MPAGE=-CKOI8-R
passenv =
}
This doesn't help too...:-(
May be child of amandad process change the system environment? How I can
check this?
Jon LaBadie
<[EMAIL PROTECTED]> Кому:
amanda-users@amanda.org
От: Копия:(СК: Евгений Ю
Сосунов/Sibancor)
owner-amanda-usersТема: Re: Cyrillic support
for index files
@amanda.org
09.06.2006 21:28
Срок ответа для:
amanda-users
On Fri, Jun 09, 2006 at 02:22:38PM +0700, å×ÇÅÎÉÊ à óÏÓÕÎÏ× wrote:
> Good day!
>
> Sorry for my English.
>
> I have installed and configured amanda.
>
...
>
> After that I modify ENVIRONMENT Variable "LANG" in crontab of amanda
user.
> But amdump which create index files still not working correctly. And
create
> index file like /\356\317\327\301\321 \320\301\320\313\301/
> /\356\317\327\301\321 \320\301\320\313\301 (2)/
> ... and e.t.c.
>
> Have you any suggestions how to decide this problem? May be I can set
> Variable "LANG" in amdump? How to do thi
Re: Amanda 2.5.0p2 on FreeBSD 4.11
Hello... Is the FreeBSD ports maintainer on the list? I have another ports error On Mon, 2006-06-12 at 18:35 -0400, amanda mail wrote: > Hi, > > I've done a "portuprade" on all my machines to Amanda 2.5.0p2 > Everthing has worked like a chmp for years but now amcheck DailySet1 > yields: > > Amanda Tape Server Host Check > - > WARNING: tapedev is null:, dumps will be thrown away Need correct tape drive, Has it always been that way? > Holding disk /var/amanda_hold: 22126684 kB disk space available, that's > plenty > NOTE: skipping tape checks > Server check took 0.009 seconds > > Amanda Backup Client Hosts Check > > ERROR: NAK amanda: access as operator not allowed from > [EMAIL PROTECTED]: /usr/local/etc/amanda/.amandahosts: > incorrect permissions; file must be accessible only by its owner chmod 600 /usr/local/etc/amanda/.amandahosts chown operator /usr/local/etc/amanda/.amandahosts > WARNING: lithium: selfcheck request failed: timeout waiting for ACK > Client check: 3 hosts checked in 30.141 seconds, 2 problems found > Dunno > (brought to you by Amanda 2.5.0p2) > > > Ideas? > > $ ls -al /usr/local/etc/amanda/.amandahosts > -rw-r- 1 operator operator 52 Jan 9 2005 > /usr/local/etc/amanda/.amandahosts > > Thank you very much for any help! > > Stan > > -- Christopher McCrory "The^W One of the guys that keeps the servers running" [EMAIL PROTECTED] http://www.pricegrabber.com Let's face it, there's no Hollow Earth, no robots, and no 'mute rays.' And even if there were, waxed paper is no defense. I tried it. Only tinfoil works.
Amanda 2.5.0p2 on FreeBSD 4.11
Hi, I've done a "portuprade" on all my machines to Amanda 2.5.0p2 Everthing has worked like a chmp for years but now amcheck DailySet1 yields: Amanda Tape Server Host Check - WARNING: tapedev is null:, dumps will be thrown away Holding disk /var/amanda_hold: 22126684 kB disk space available, that's plenty NOTE: skipping tape checks Server check took 0.009 seconds Amanda Backup Client Hosts Check ERROR: NAK amanda: access as operator not allowed from [EMAIL PROTECTED]: /usr/local/etc/amanda/.amandahosts: incorrect permissions; file must be accessible only by its owner WARNING: lithium: selfcheck request failed: timeout waiting for ACK Client check: 3 hosts checked in 30.141 seconds, 2 problems found (brought to you by Amanda 2.5.0p2) Ideas? $ ls -al /usr/local/etc/amanda/.amandahosts -rw-r- 1 operator operator 52 Jan 9 2005 /usr/local/etc/amanda/.amandahosts Thank you very much for any help! Stan
Re: filename ... has invalid characters
Hi Toralf, First off, I rather like your approach to configuration files. Good ;-) A little research shows that the explicit test was introduced to plug a security hole reported by PERL... See BUG #1353481 for more information. I see... [ ... ] I'm proposing an alternate solution to our mutual problems: Sanitize file name by simply rejecting any '..' path component in a configuration name. Right. Of course ".." might be used in clever ways to do some evil. Never thought of that. This should allow any arbitrary character in the configuration name and prevent any attempts to use a configuration outside of the amanda configuration directory. Toralf: will this work for you? Yes, this will be quite all right with me. - Toralf
Re: dump tape full?
On Mon, Jun 12, 2006 at 08:28:26PM +0200, Kristian Rink wrote: > > Hello John, all: > > and at first thanks for your comments... > > > Jon LaBadie schrieb: > >> to have completed without errors, but, running amverify ended up with > >> the following: > > > > This is just guesswork, given that I'm bad and don't run amverify. > ... > > >> amverify Full > >> Mo Jun 12 13:01:54 CEST 2006 > ... > >> Checked backer.planconnect.net.planc1.20060610.0 > >> End-of-Information detected. > >> Loading next slot... > >> ... ... > > To be a little more verbose on that, here's an excerpt taken from > yesterdays Full dump log (sizes): > > > [...] > Output Size (meg) 172568.1 172568.10.0 > Original Size (meg)372550.6 372550.60.0 > Avg Compressed Size (%)46.3 46.3-- > Filesystems Dumped7 7 0 > Avg Dump Rate (k/s) 1198.0 1198.0-- > [...] > Tape Size (meg)172568.1 172568.10.0 > Tape Used (%) 86.4 86.40.0 > Filesystems Taped 7 7 0 > [..] > USAGE BY TAPE: > LabelTime Size %NbNc > Back00 40:59 176709760k 86.4 7 0 > > > I'm not sure right now, but the way I understand this, we did back up > 372.5 gig of data (which seems reasonable looking at the RAID disk > usage), compressed to 172.5gig. Assuming that LTO-2 at this level is > capable of storing 200gig data, the 86.4% usage of that very (single) > tape do make sense. > > This way, the "End-Of-Information" message seems rather obscure... :o > Any more ideas, anyone? :) I tried the ultimate documentation, a run of amverify on my own data and a peek at the amverify source (a shell script). I think the "End of Information" message is a normal message, just a notice that it did not necessarily reach the physical end of the tape (a different part of the source). On my amverify run (a two vtape amdump run), I got basically the same information as you reported, including the "EOI" message at the end of each vtape. Also, in the source, after the loop running through the tapes is completed there is a section showing "if the file collecting defects has anything in it, cat it to the user with the message "Errors found: " preceeding it. Neither you nor I appear to have received such a message. It would be very easy to change that if statement to have an else clause printing "no errors found". Should you think that is desireable, submit an RFE to the amanda developers. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: filename ... has invalid characters
Hi Toralf, First off, I rather like your approach to configuration files. A little research shows that the explicit test was introduced to plug a security hole reported by PERL... See BUG #1353481 for more information. I'm piping in here, and expanding the audience to include amanda_hackers, since the change seems to impact my work on allowing spaces in file names. (Currently checked into sourceforge 2.5.1 branch.) The current check is a little too strict and will strip out spaces and control characters, all of which are valid according to POSIX rules. (POSIX allows any character except '/' or NULL is allowable.) I'm proposing an alternate solution to our mutual problems: Sanitize file name by simply rejecting any '..' path component in a configuration name. This should allow any arbitrary character in the configuration name and prevent any attempts to use a configuration outside of the amanda configuration directory. Toralf: will this work for you? Hackers: will this pass security muster? Regards, John - Original Message - From: "Toralf Lund" <[EMAIL PROTECTED]> To: "Amanda Mailing List" Sent: Monday, June 12, 2006 2:35 AM Subject: filename ... has invalid characters I'm now testing amanda 2.5.0p2. First problem: # amstatus ks/archive filename 'ks/archive' has invalid characters. I suppose the problem here is that I specified a filename containing "/", but I actually did this on purpose, and it has always worked in the past. I'm using multiple directory levels under /etc/amanda, you see - amanda.conf for the configuration I'm trying to refer to here is stored under /etc/amanda/ks/archive. I set it up like that because I wanted to group configs that would share data like the disklist. (So I have a /etc/amanda/ks/disklist referenced by several different /etc/amanda/ks/*/amanda.conf.) Maybe this was stupid, but it seemed like a good idea at the time... In any case, I'm wondering why an explicit test on the configuration name has (apparently) been introduced. Won't you find out soon enough anyway whether it is correct or not? (I mean, you just look for /etc/amanda//amanda.conf...) -- Toralf Lund
Re: dump tape full?
Hello John, all: and at first thanks for your comments... Jon LaBadie schrieb: >> to have completed without errors, but, running amverify ended up with >> the following: > > This is just guesswork, given that I'm bad and don't run amverify. Hmmm, honestly I am also bad most of the time but a little more careful right now - our backup system consists of an external SCSI-to-IDE RAID system and an LTO-2 autoloader; hosts on the network dump their data to the RAID system and amanda is about to hammer those data to tape at night (incremental) or weekend (full). The RAID system hasn't been in good condition lately after some of the drives went down, so I am worried about the state of my tape backup, as well... That's why I initially played around with amverify in order to see whether there actually _is_ anything backed up at all... :) >> amverify Full >> Mo Jun 12 13:01:54 CEST 2006 ... >> Checked backer.planconnect.net.planc1.20060610.0 >> End-of-Information detected. >> Loading next slot... >> ... >>> > Does the list of DLEs shown by amverify match the total of > what were expected? Yes. The way it looks until then, at least every DLEs have been processed and found backed up on tape. > Did the report that amdump mailed out report early on that > "Some dumps may have been left on the holding disk"? No, nothing like this. Looking at the report mails, everything is fine... > The questions above would help confirm this guess, but I suspect that > taper actually ran out of space on the tape. Whether the DLE it was > taping when it reached the end was backer.planconnect.net.planc1.20060610.0 > or the next DLE I don't know. When taper hits the end of the tape the > emailed report shows "successful tape usage", that is your 84%. The > remaining 16% might have been a partially taped DLE. To be a little more verbose on that, here's an excerpt taken from yesterdays Full dump log (sizes): [...] Output Size (meg) 172568.1 172568.10.0 Original Size (meg)372550.6 372550.60.0 Avg Compressed Size (%)46.3 46.3-- Filesystems Dumped7 7 0 Avg Dump Rate (k/s) 1198.0 1198.0-- [...] Tape Size (meg)172568.1 172568.10.0 Tape Used (%) 86.4 86.40.0 Filesystems Taped 7 7 0 [..] USAGE BY TAPE: LabelTime Size %NbNc Back00 40:59 176709760k 86.4 7 0 I'm not sure right now, but the way I understand this, we did back up 372.5 gig of data (which seems reasonable looking at the RAID disk usage), compressed to 172.5gig. Assuming that LTO-2 at this level is capable of storing 200gig data, the 86.4% usage of that very (single) tape do make sense. This way, the "End-Of-Information" message seems rather obscure... :o Any more ideas, anyone? :) Thanks for your patience and bye, Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
Re: When was bumppercent introduced?
Jean-Louis added "bumppercent" on 2004-04-06 according to ChangeLog. So, it has been around for sometime. I think you will need to use 2.4.5 or later to get this feature. It is documented in amanda.conf man page http://wiki.zmanda.com/index.php/Amanda.conf and in the example/amanda.conf. Thanks, Paddy On 6/12/06, Toralf Lund <[EMAIL PROTECTED]> wrote: I notice that the doc on amanda.org mentions a parameter "bumppercent". It is not mentioned in my local manual page. Is this a relatively new option? When was it introduced? I mean, what version do I have to install in order to get it? This variant is obviously a lot more flexible than bumpsize... -- Toralf Lund -- Amanda documentation: http://wiki.zmanda.com Amanda forums: http://forums.zmanda.com
Re: dump tape full?
On Mon, Jun 12, 2006 at 04:05:47PM +0200, Kristian Rink wrote: > > Hi all; > > being merrily running amanda for about three years now, right now our > tapes are slowly getting filled. This weekends full dump obviously seems > to have completed without errors, but, running amverify ended up with > the following: This is just guesswork, given that I'm bad and don't run amverify. > amverify Full > Mo Jun 12 13:01:54 CEST 2006 > > Loading current slot... > Using device /dev/nst0 > Volume Back00, Date 20060610 > Checked backer.planconnect.net.planc3.20060610.0 > Checked backer.planconnect.net.ablage.20060610.0 > Checked backer.planconnect.net.refast.20060610.0 > Checked backer.planconnect.net.backervar.20060610.0 > Checked backer.planconnect.net.jka.20060610.0 > Checked backer.planconnect.net.backercfg.20060610.0 > Checked backer.planconnect.net.planc1.20060610.0 > End-of-Information detected. > Loading next slot... > ... > Does the list of DLEs shown by amverify match the total of what were expected? > > Hmmm, there's currently only one tape inside the changer (the one of > last weekend), and, according to the amdump log files, last weekends > dump filled up about 84% of the tape. Did the report that amdump mailed out report early on that "Some dumps may have been left on the holding disk"? > > So: What does "End-of-Information" mean in this context? Is the tape > (for whichever reason) filled and amverify expecting more information on > another one? Did amverify actually finish checking all disks and see the > end of the dump? > ... > Checked backer.planconnect.net.planc1.20060610.0. > ... > > makes be believe the check of this part of the backup was successful The questions above would help confirm this guess, but I suspect that taper actually ran out of space on the tape. Whether the DLE it was taping when it reached the end was backer.planconnect.net.planc1.20060610.0 or the next DLE I don't know. When taper hits the end of the tape the emailed report shows "successful tape usage", that is your 84%. The remaining 16% might have been a partially taped DLE. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
dump tape full?
Hi all; being merrily running amanda for about three years now, right now our tapes are slowly getting filled. This weekends full dump obviously seems to have completed without errors, but, running amverify ended up with the following: ... amverify Full Mo Jun 12 13:01:54 CEST 2006 Loading current slot... Using device /dev/nst0 Volume Back00, Date 20060610 Checked backer.planconnect.net.planc3.20060610.0 Checked backer.planconnect.net.ablage.20060610.0 Checked backer.planconnect.net.refast.20060610.0 Checked backer.planconnect.net.backervar.20060610.0 Checked backer.planconnect.net.jka.20060610.0 Checked backer.planconnect.net.backercfg.20060610.0 Checked backer.planconnect.net.planc1.20060610.0 End-of-Information detected. Loading next slot... ... Hmmm, there's currently only one tape inside the changer (the one of last weekend), and, according to the amdump log files, last weekends dump filled up about 84% of the tape. So: What does "End-of-Information" mean in this context? Is the tape (for whichever reason) filled and amverify expecting more information on another one? Did amverify actually finish checking all disks and see the end of the dump? I'm confused here, and the amverify documentation unfortunately wasn't that helpful... For what I saw, ... Checked backer.planconnect.net.planc1.20060610.0. ... makes be believe the check of this part of the backup was successful, am I right on that? Can someone enlighten me (or point me where to read)? Thanks in advance and bye Kris -- Kristian Rink -- Programmierung/Systembetreuung planConnect GmbH * Strehlener Str. 12 - 14 * 01069 Dresden 0176 24472771 * [EMAIL PROTECTED]
Re: Is tape spanning documented anywhere?
On Mon, Jun 12, 2006 at 10:18:46AM +0200, Toralf Lund enlightened us: > I haven't been following the posts to this list too closely, or bothered > to upgrade amanda, for some time (since our existing setup *works*...), > so I didn't find out until right now that tape spanning is supported in > the current release. > > Anyhow, I'd really like to know more about how the spanning actually > works. Is it documented anywhere? http://www.amanda.org/docs and FAQ > still say that the option does not exist... > Try http://wiki.zmanda.org/index.php/Splitting_dumps_across_tapes Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263
Version 2.5.0p2: amstatus parse error for logfile from older version
I'm trying to run "amstatus" on existing logfiles after upgrading from
version 2.4.4p3 to 2.5.0p2. Unfortunately, the command will most of the
time fail with a message like:
amstatus ks --file /dumps/amanda/ks/log/amdump.1
Using /dumps/amanda/ks/log/amdump.1 from Thu Jun 8 17:04:30 CEST 2006
ERROR getting estimates 0 (909420) -1 (-1) -1 (-1) at
/usr/sbin/amstatus line 213, line 74.
The error seems to come from the following section of PERL code:
if(/getting estimates (-?\d) \(-2\) (-?\d) \(-2\) (-?\d) \(-2\)/) {
if($1 != -1) { $getest{$hostpart} .= ":$1:" };
if($2 != -1) { $getest{$hostpart} .= ":$2:" };
if($3 != -1) { $getest{$hostpart} .= ":$3:" };
}
else {
die("ERROR $_");
}
Which does not really make sense to me. Am I missing something, or does
the above match operator *require* a number of ocurreces of the string
"(-2)" (as opposed to "some value in brackets")?
Isn't the new amstatus expected to work with old logfiles?
- Toralf
filename ... has invalid characters
I'm now testing amanda 2.5.0p2. First problem: # amstatus ks/archive filename 'ks/archive' has invalid characters. I suppose the problem here is that I specified a filename containing "/", but I actually did this on purpose, and it has always worked in the past. I'm using multiple directory levels under /etc/amanda, you see - amanda.conf for the configuration I'm trying to refer to here is stored under /etc/amanda/ks/archive. I set it up like that because I wanted to group configs that would share data like the disklist. (So I have a /etc/amanda/ks/disklist referenced by several different /etc/amanda/ks/*/amanda.conf.) Maybe this was stupid, but it seemed like a good idea at the time... In any case, I'm wondering why an explicit test on the configuration name has (apparently) been introduced. Won't you find out soon enough anyway whether it is correct or not? (I mean, you just look for /etc/amanda//amanda.conf...) -- Toralf Lund
Is tape spanning documented anywhere?
I haven't been following the posts to this list too closely, or bothered to upgrade amanda, for some time (since our existing setup *works*...), so I didn't find out until right now that tape spanning is supported in the current release. Anyhow, I'd really like to know more about how the spanning actually works. Is it documented anywhere? http://www.amanda.org/docs and FAQ still say that the option does not exist... - Toralf
When was bumppercent introduced?
I notice that the doc on amanda.org mentions a parameter "bumppercent". It is not mentioned in my local manual page. Is this a relatively new option? When was it introduced? I mean, what version do I have to install in order to get it? This variant is obviously a lot more flexible than bumpsize... -- Toralf Lund
