On Saturday 25 May 2019 01:21:41 pm Nathan Stratton Treadway wrote: > (updating the Subject line in an attempt to keep the discussion > subthreads separate...) > > On Sat, May 25, 2019 at 03:44:12 -0400, Gene Heskett wrote: > > On Friday 24 May 2019 10:37:15 am Chris Hassell wrote: > > > On 5/22/19 11:47 AM, Nathan Stratton Treadway wrote: > > > > You can find the full set of patches in the source repo on > > > > Salsa, i.e. in your web broswer at: > > > > > > > > https://salsa.debian.org/debian/amanda/tree/master/debian/patche > > > >s > > > > > > I just pushed a branch up (3_5-deb-patches or something) that > > > includes their latest work against their "master". > > > > > > Some things seem quite reasonable. > > > > I wandered around on salsa, without finding an obviously ready to > > download tarball that wasn't prehistoric. Or a src deb. > > The Salsa repo is for the official Debian packages. I don't believe > there is any reason for you to download from it -- you should use the > Zmanda release tar files (or for bleeding edge, the Zmanda github > repo) directly. git clone $$$$$$$$$$ please. What I got from github last required i completely redo my paaswd and group files and still insisted it was amandabackup. I just checked the first client machine and there is only backup in either group or passwd. So there's never been an amandabackup on those wheezy nachines, Thats straight debian built clients, right straight from the debian repos. Thats why this amandabackup as the user was a total surprise to me. Serves zero useful purpose and breaks compatibility all over the place. All the clients use one access control file the lives in /var/backups/.amandahosts and is softlinked to /etc/amandahosts. And contains:
localhost root amindexd amidxtaped coyote.coyote.den amanda amdump Basicly telling that client the the server known as coyote.coyote.den has rights to run the client software named in order to do the backup. And its been that way for close to a decade. I had apt flush the official debs from this machine, since they were built apparently by at least 2 people, who could not make up their mind who owned what, so there was no way to get them all on the same page. I spent 4 days trying various chowns trying to get it all talking to each other and came to the conclusion that one config had built the client deb, and another has built the server debs and never the twain could meet without a huge argument about who owned what. Frankly the salsa version has come closer than the others to actually running But something was telling the clients to look in /usr/local when they were and are in /usr since they are legit debs. Or the error message from the server running amcheck is fubar. No better defined than the error message is, I haven't a clue where to look for a missing file it thinks ought to be owned by root with 0600 perms. I tried the zmanda version of 3.5.0 and came to the conclusion that it had been poisoned as very little of it would build regardless of what I fed autoconf. If you want us to use that as the basis to move forward, them somebody is going to have to sort that basket of rattlesnakes and restore it to buildable. All those clients ran flawlessly using 3.3.7 built on wheezy. I think I might yet have a copy of that tarball but enough has changed between wheezy and stretch that it doesn't want to build. While I'm belly aching, whats this JSON.pm it needs, its not in the stretch repo's. And I just tried to rebuild 3.3.7p1, bails out here on the make, but never before used a crypt function. I'll unpack the tarball again. I don't think its clean. > (I only posted that link here in order for Chris to take a look at the > patches found over there.) > > On Sat, May 25, 2019 at 04:14:29 -0400, Gene Heskett wrote: > > I just tried to rub what I do have and it makes zero difference > > whether I am amanda or backup (theres no amandabackup user in the pw > > file so I can't even become amandabackup. And as amanda or as > > backup I get thrown out of running amcheck, with no permissions > > exits. > > > > Go back to the amanda:disk or amanda:backup model for starters. > > This is insane!!! > > Gene, > > The choice of which user (and group) is used depends on the binaries > you have installed. The problems you are currently running into > result from switching back and fourth between package sources -- > something which will always cause all kinds of trouble. > > The official Debian Amanda packages have always[*] used user=backup, > group=backup. > No they have not! > The Zmanda Debian packages have always[*] used user=amandabackup, > group=disk for the Amanda programs (as documented on No they have not!> > http://wiki.zmanda.com/index.php/Amanda_packages_from_Zmanda_downloads >_page ). > > If you are trying to have user=amanda, then that must come from > building your own binaries from source... > > So the question is what are you trying to accomplish now? Right at the moment I have one problem remaining in an install of 3.4.3 built from a tarball, and in cleaning up the amandahosts file I find the 2 of the 4 clients are expecting amandabackup and 2 of them expecting backup to come calling, so I've fixed the amandahosts files and the clients are happy, but the client on this machine is being refused, and I may have to go hacking on my group and passwd files to get it fixed. Theres a boatload of perl errors at the top of an amcheck, looks like this, and I can get them even with the 3.3.7p1 build backup@coyote:/home/amanda/amanda-3.4.3$ /usr/local/sbin/amcheck Daily Amanda Tape Server Host Check ----------------------------- NOTE: Holding disk '/usr/dumps': 1477252 MB disk space available, using 1476752 MB Can't locate JSON.pm in @INC (you may need to install the JSON module) (@INC contains: /usr/local/share/perl/5.24.1 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/local/share/perl/5.24.1/Amanda/Message.pm line 29. BEGIN failed--compilation aborted at /usr/local/share/perl/5.24.1/Amanda/Message.pm line 29. Compilation failed in require at /usr/local/share/perl/5.24.1/Amanda/Config.pm line 3078. BEGIN failed--compilation aborted at /usr/local/share/perl/5.24.1/Amanda/Config.pm line 3078. Compilation failed in require at /usr/local/share/perl/5.24.1/Amanda/Util.pm line 586. BEGIN failed--compilation aborted at /usr/local/share/perl/5.24.1/Amanda/Util.pm line 586. Compilation failed in require at /usr/local/libexec/amanda/amcheck-device line 25. BEGIN failed--compilation aborted at /usr/local/libexec/amanda/amcheck-device line 25. NOTE: conf info dir '/usr/local/var/amanda/Daily/curinfo' does not exist it will be created on the next run NOTE: index dir '/usr/local/var/amanda/Daily/index' does not exist it will be created on the next run Server check took 0.084 seconds Amanda Backup Client Hosts Check -------------------------------- ERROR: coyote: selfcheck request failed: Connection refused Client check: 5 hosts checked in 10.011 seconds. 1 problem found. (brought to you by Amanda 3.4.3) backup@coyote:/home/amanda/amanda-3.4.3$ So what do I do to clean up this mess? > I think you are only causing yourself trouble switching back and > fourth from self-built to either sort of Debian packages. > yes I likely am, but I want to get something running too. We've gone a month now with no buildable code from anyplace. > Have you decided to give up using your gh.cf build script, in favor of > using one or the other flavor of Debian packages from now on? Not no but hell no, using my script I always have painless continuity from version to version. I have edited it a bit since someone has been playing tiddly winks with the owner:group just to satisfy their personal paranoia. And since I'm using vtapes, I am slowly adding to the --without-such-and-such-devices/options. > > If not, you should de-install any amanda*.deb files currently > installed, and make sure you don't try to use (at least on this > particular server) any .deb files going forward (and avoid following > any .deb-related build instructions as well). Did that about 4am this morning just so they would not be in the way or path. Now, exactly where do I pull the latest tarball from???? So we are at least on the same page and can figure out what the other is saying. > > Then we can focus here on what's needed to get you back to some > working system with your self-built, non-packaged binaries... I've always prided myself on running the bleeding edge in hopes my canary dies before some ill conceived idea gets embeded too deeply in this code. I take that chance of getting cut willingly, playing canary is my contribution to the betterment of this unique backup idea. But dammit, I'm bleeding to death here. > Nathan > > [*] "always" meaning: definitely for the past decade or two, and > probably since the very first version of each flavor of packages... > I've been an amanda promoter/supporter since 1998. Thats 2 decades now... > > ---------------------------------------------------------------------- >------ Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic > region Ray Ontko & Co. - Software consulting services - > http://www.ontko.com/ GPG Key: > http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key > fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 Copyright 2019 by Maurice E. Heskett Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
