Re: Debian: inetd required for amanda?
Jon LaBadie (Di 11 Jul 2017 22:28:56 CEST):
> On Tue, Jul 11, 2017 at 03:36:48PM +0200, Heiko Schlittermann wrote:
> > Jon LaBadie (Di 11 Jul 2017 15:27:47 CEST):
> >
> > > BTW the dash after ENVIRONMENT_FILE= is a typo?
> > > Or some systemd syntax.
> >
> > No, in is just a "conditional", if the file does not exist, it is not
> > treated as an error (as it would be without the dash).
> >
> With your normal accuracy I thought it might be some special syntax.
Sorry, probably I'm misinterpreting you…
It *is* special syntax for systemd's EnvironmentFile option.
EnvironmentFile=/etc/default/amanda
*requires* the file to exist. But
EnvironmentFile=-/etc/default/amanda
silently ignores the non-existing file (resulting in unset variables,
probably)
> > And, the Amanda Version I use (3.3.9) doesn't work with
> > ListenStream=10080
> > As the socket is an "combined" ipv4/ipv6 socket and probaby the client
> > doesn't use the proper function calls to get the peer address.
> > ListenStream=0.0.0.0:10080
> > solved this for me. One should investigate it a bit more probably.
>
> On these systems the null address is not needed.
> Perhaps because I've done nothing with IPv6.
I wrote a short Perl script to find the peers address on two of my systems
(both Debian9, using systemd 232) and put in there in place of amandad.
(Because with ListenStream=10080 amandad complained about the peer
address being 0.0.0.0, which is nonsens.)
#!/usr/bin/perl
use 5.24.1;
use strict;
use warnings;
use IO::Socket::INET;
use IO::Socket::INET6;
$| = 1;
eval { say 'v6: ', IO::Socket::INET6->new_from_fd(0, 'r+')->peerhost };
say "error: $@" if $@;
eval { say 'v4: ', IO::Socket::INET->new_from_fd(0, 'r+')->peerhost };
say "error: $@" if $@;
With ListenStream= I get an eval error for the INET socket. With
ListenStream=0.0.0.0: I get the peers IPv4 address in both cases
(IO::Socket::INET6 internally uses functions for both address families,
wheras IO::Socket::INET only expects AF_INET (ant not AF_INET6). I
think(!), amdand does about the same.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 -
signature.asc
Description: PGP signature
Re: Debian: inetd required for amanda?
On Tue, Jul 11, 2017 at 03:36:48PM +0200, Heiko Schlittermann wrote: > Jon LaBadie (Di 11 Jul 2017 15:27:47 CEST): > > > BTW the dash after ENVIRONMENT_FILE= is a typo? > > Or some systemd syntax. > > No, in is just a "conditional", if the file does not exist, it is not > treated as an error (as it would be without the dash). > With your normal accuracy I thought it might be some special syntax. > And, the Amanda Version I use (3.3.9) doesn't work with > > ListenStream=10080 > > As the socket is an "combined" ipv4/ipv6 socket and probaby the client > doesn't use the proper function calls to get the peer address. > > ListenStream=0.0.0.0:10080 > > solved this for me. One should investigate it a bit more probably. On these systems the null address is not needed. Perhaps because I've done nothing with IPv6. Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: Debian: inetd required for amanda?
Jon LaBadie (Di 11 Jul 2017 15:27:47 CEST): > > No, it just redirects the STDERR (if there is any) to > > the journal, and not to the client. Or needs amandad to send (stderr) > > output to the client? > > > Without investigation I assumed the log/debug files were written > via stderr. Probably they are opened separately. I suppose, they are opened by the daemon, becase xinetd doesn't have this functionality. > > Hm. If the environement file is already named "amanda", I do not see > > a reason to replicate "amanda" in the variable name. But I do not mind > > either. > > When you put it that way there probably is none. > I was thinking of possible future needs for more > "services" variables plus child processes inheriting > an environment containg "SERVICES". If a child depends on such an unspecific name as SERVICES, I cannot help :) > BTW the dash after ENVIRONMENT_FILE= is a typo? > Or some systemd syntax. No, in is just a "conditional", if the file does not exist, it is not treated as an error (as it would be without the dash). And, the Amanda Version I use (3.3.9) doesn't work with ListenStream=10080 As the socket is an "combined" ipv4/ipv6 socket and probaby the client doesn't use the proper function calls to get the peer address. ListenStream=0.0.0.0:10080 solved this for me. One should investigate it a bit more probably. -- Heiko signature.asc Description: PGP signature
Re: Debian: inetd required for amanda?
On Tue, Jul 11, 2017 at 10:40:36AM +0200, Heiko Schlittermann wrote: > Jon LaBadie (Di 11 Jul 2017 07:56:28 CEST): > > > > > > | StandardInput=socket > > > > > | StandardError=journal > > > > Does this prevent writing to amanda's normal log/debug files? > > No, it just redirects the STDERR (if there is any) to > the journal, and not to the client. Or needs amandad to send (stderr) > output to the client? > Without investigation I assumed the log/debug files were written via stderr. Probably they are opened separately. > > > Maybe this could be done via an env file /etc/default/amanda having > > > SERVICES="amdump amindexd amindxtaped…" > > > > > > and then extending the .service unit: > > > > > > EnvironmentFile=-/etc/default/amanda > > > ExecStart=/usr/lib/amanda/amandad -auth=bsdtcp $SERVICES > > > > I was not aware of this capability. I think I'd pick a more specific > > variable name, like AMANDAD_SERVICES. > > Hm. If the environement file is already named "amanda", I do not see > a reason to replicate "amanda" in the variable name. But I do not mind > either. When you put it that way there probably is none. I was thinking of possible future needs for more "services" variables plus child processes inheriting an environment containg "SERVICES". BTW the dash after ENVIRONMENT_FILE= is a typo? Or some systemd syntax. jl -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: Debian: inetd required for amanda?
Jon LaBadie (Di 11 Jul 2017 07:56:28 CEST):
> > > Added "After=local-fs.target". Debian may not even have
> > > the "local-fs.target", or they may have something similar.
> >
> > Do the "After=" dependencies matter for socket activated services?
> I don't know. Why do you think they may not matter?
Hm. I did some investigation.
The amanda.socket is WantedBy the sockets.target. This is
independend on the local-fs.target. So it may happen, that the
amanda.service starts before local-fs.target is complete.
So, yes, After=local-fs.target seems to be useful for the
amanda.service.
> > > > | StandardInput=socket
> > > > | StandardError=journal
>
> Does this prevent writing to amanda's normal log/debug files?
No, it just redirects the STDERR (if there is any) to
the journal, and not to the client. Or needs amandad to send (stderr)
output to the client?
> > Maybe this could be done via an env file /etc/default/amanda having
> > SERVICES="amdump amindexd amindxtaped…"
> >
> > and then extending the .service unit:
> >
> > EnvironmentFile=-/etc/default/amanda
> > ExecStart=/usr/lib/amanda/amandad -auth=bsdtcp $SERVICES
>
> I was not aware of this capability. I think I'd pick a more specific
> variable name, like AMANDAD_SERVICES.
Hm. If the environement file is already named "amanda", I do not see
a reason to replicate "amanda" in the variable name. But I do not mind
either.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 -
signature.asc
Description: PGP signature
Re: Amvault for the Compleat Dummy
On Tue, Jul 11, 2017 at 09:10:05AM +0200, Matthias Teege wrote: > How many tapes do you use for "vaulting" and how do you rotate the > tapes? Does the amvault job using the same settings as the daily job > to vtapes? It follows the storage profile. So you tell it the retention levels and rejects 'in use' tapes. Other than that remember that the tapecycle is only for planning and defaulting purposes, you can always use more 'tapes' than specified. > I'm doing dailys to vtapes which are smaller as my "real" tapes. If > I understand amvault correctly I can write more then one dump to tape > with something like 'amvault --src-timestamp "201707..." --dst-changer > vaulting-tape daily' but have to rotate the tapes "by hand". Yes, the only issue is to find an adequate filter for amvault since each invocation starts a new tape (the usual amanda "never append to a tape" rule). And anyway the amvault interface is still in flux so maybe one day there will be something like the file list of cpio (I want to vault this, this and this in one vaulting run) -- Lorenzo Marcantonio signature.asc Description: PGP signature
Re: Amvault for the Compleat Dummy
On Tue, Jul 11, 2017 at 08:36:16AM +0200, Lorenzo Marcantonio wrote: Hi! > On Tue, Jul 11, 2017 at 08:06:29AM +0200, Stefan G. Weichinger wrote: > > Sure, pls share for us to learn/copy/ask. > > The vaulting run is done with > > amvault DailySet --latest-fulls --dest-storage VAULT-STORAGE How many tapes do you use for "vaulting" and how do you rotate the tapes? Does the amvault job using the same settings as the daily job to vtapes? I'm doing dailys to vtapes which are smaller as my "real" tapes. If I understand amvault correctly I can write more then one dump to tape with something like 'amvault --src-timestamp "201707..." --dst-changer vaulting-tape daily' but have to rotate the tapes "by hand". Thanks! Matthias
