Possible fix for 3.3.8 that maybe relevant for 3.4.1
A user of amanda on Debian have sent me a patch to fix a problem in
amanda 3.3.8. I do not know enough perl to validate the patch. But a
quick look to the file, seams to not changed much between 3.3.8 and
amanda 3.4.1.
Can someone review the patch and give the opnion if it fix a problem
or not?
The patch for amanda 3.3.8 is:
--- /tmp/robot.pm 2016-12-27 09:41:57.285488949 -0700
+++ /usr/lib/amanda/perl/Amanda/Changer/robot.pm2016-12-27
09:41:34.045222046 -0700
@@ -2359,6 +2359,7 @@
use Amanda::Debug qw( debug warning );
use Amanda::MainLoop qw( :GIOCondition synchronized make_cb define_steps step
);
use Amanda::Device qw( :constants );
+use Carp;
sub new {
my $class = shift;
The URL to the bugreport is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849481
Kind regards
Jose M Calhariz
--
--
Quem ri por último não entendeu a piada...
signature.asc
Description: Digital signature
Re: Possible fix for 3.3.8 that maybe relevant for 3.4.1
Jose,
The patch is good and I committed it.
Thanks for reporting the issue.
Jean-Louis
On 03/01/17 02:51 PM, Jose M Calhariz wrote:
> A user of amanda on Debian have sent me a patch to fix a problem in
> amanda 3.3.8. I do not know enough perl to validate the patch. But a
> quick look to the file, seams to not changed much between 3.3.8 and
> amanda 3.4.1.
>
> Can someone review the patch and give the opnion if it fix a problem
> or not?
>
> The patch for amanda 3.3.8 is:
>
> --- /tmp/robot.pm 2016-12-27 09:41:57.285488949 -0700
> +++ /usr/lib/amanda/perl/Amanda/Changer/robot.pm 2016-12-27
> 09:41:34.045222046 -0700
> @@ -2359,6 +2359,7 @@
> use Amanda::Debug qw( debug warning );
> use Amanda::MainLoop qw( :GIOCondition synchronized make_cb define_steps
> step );
> use Amanda::Device qw( :constants );
> +use Carp;
>
> sub new {
> my $class = shift;
>
>
> The URL to the bugreport is:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849481
>
> Kind regards
> Jose M Calhariz
>
>
>
>
Disclaimer
The information contained in this communication from the sender is
confidential. It is intended solely for use by the recipient and others
authorized to receive it. If you are not the recipient, you are hereby notified
that any disclosure, copying, distribution or taking action in relation of the
contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been
automatically archived by Mimecast Ltd, an innovator in Software as a Service
(SaaS) for business. Providing a safer and more useful place for your human
generated data. Specializing in; Security, archiving and compliance. To find
out more visit the Mimecast website.
Re: short hostname vs FQDN
One benefit of FQDNames: If you try to backup (or restore) MyNode it will also backup MyNode1, MyNode2 , MyNodeAlso, MyNodeNot and anything else which starts with the same word.(I don’t get to control what my client nodes are named). With a FQDN I can backup only the node I want, by using MyNode.F.Q.D.N(if you get my gist). If you don’t HAVE the FQDN in the disklist file, then you can’t do that. I’ve also had issues with DLEs that are shorter forms of others, and had to use the “name” (“nickname?) field for those, so I have the control that I want. Deb Baddorf Fermilab > On Jan 2, 2017, at 6:14 PM, Jon LaBadie wrote: > > In my disklist file I have typically used just the > short name for my hosts rather than the FQDN versions. > I.e. the first line below rather than the second. > >vost Home /home comp-user-tar >vost.jgcomp.com Home /home comp-user-tar > > My server and all the clients are in the same domain > and ip-addr -> hostname queries to my local DNS returns > the short form rather than the FQDN. > > Are there any known places/situations where using the > short hostnames will definitely cause problems? > > The concern arose as I'm still trying to get amdump_client > working. At one point I switched to FQDN to see if that > was a problem but got the surprise error of "no DLEs for > host vost". The amanda server considered the requesting > system to be "vost", not "vost.jgcomp.com". I'm assuming > it picked that up from a DNS query. I see no way to > specify the host on the amdump_client command line. > > Jon > -- > Jon H. LaBadie j...@jgcomp.com > 11226 South Shore Rd. (703) 787-0688 (H) > Reston, VA 20190 (703) 935-6720 (C)
Re: how to access/dump files on a AD-member server
> On Jan 1, 2017, at 10:35 AM, Stefan G. Weichinger wrote: > > > The situation: > > server "backup" dumps files from fileserver "main" > > main is now a Samba ADS member server > > The path in the DLE is /mnt/daten, this is the shared samba-directory as > well. > > I chown-ed that directory to assign it to the AD group: > > # chown -R nobody:"domain users" /mnt/daten > # chmod -R 0660 /mnt/daten > > obviously now the amanda client can't access the files anymore > > # chmod -R 0666 /mnt/daten > > makes it work but I don't like that ... > > And I can't add the local dumpuser amanda to the group in the AD. > > How do you solve that most elegantly? > > --- have a great 2017 all! > > Stefan I’m not familiar with ADS, so this may not help. But, can you add your local backup user (amanda) to the “disk” group ? I have this in /etc/group: disk:x:6:root,operator (since I backup from operator) Deb Baddorf Fermilab
Re: how to access/dump files on a AD-member server
Am 2017-01-03 um 21:17 schrieb Debra S Baddorf: > I’m not familiar with ADS, so this may not help. But, can you add your > local backup user (amanda) > to the “disk” group ? > > I have this in /etc/group: > disk:x:6:root,operator > (since I backup from operator) That was one of my first thoughts and I tried that, didn't work in that case. As the files/dirs in the DLE-path belong to ADS-based user/group only (0660), users in group disk can't access them. At least that's my interpretation. Jon suggested 0770 instead (+x), haven't tested yet. Late here, more tomorrow.
Re: how to access/dump files on a AD-member server
> On Jan 3, 2017, at 4:08 PM, Stefan G. Weichinger wrote: > > Am 2017-01-03 um 21:17 schrieb Debra S Baddorf: > >> I’m not familiar with ADS, so this may not help. But, can you add your >> local backup user (amanda) >> to the “disk” group ? >> >> I have this in /etc/group: >> disk:x:6:root,operator >> (since I backup from operator) > > That was one of my first thoughts and I tried that, didn't work in that > case. > > As the files/dirs in the DLE-path belong to ADS-based user/group only > (0660), users in group disk can't access them. > > At least that's my interpretation. > > Jon suggested 0770 instead (+x), haven't tested yet. > > Late here, more tomorrow. > > Also — even when my backup user complains that it can’t read a disk (it complains during AMCHECK) it usually actually CAN back it up, because at that point, it is running as root. Still, I hate having to read past that all the time, in my AMCHECKs, so I do try to fix it. Deb
