On Sunday 26 May 2019 04:48:59 am Gene Heskett wrote:
> On Saturday 25 May 2019 11:46:46 pm Nathan Stratton Treadway wrote:
> > On Sat, May 25, 2019 at 21:38:39 -0400, Gene Heskett wrote:
> > > Same install dvd for 4 of them because this machines wheezy
> > > install was also done with that same dvd. 4 different passwd and
> > > group settings, yet it all just worked.
> >
> > These differences simply show that you used different methods
> > (offical Debian v.s. Zmanda Debian v.s. non-Debianianized-build,
> > etc.) to install Amanda on those various machines.
> >
> > This is perfectly fine; the hard rules Amanda has about user/group
> > ownership etc. are specific to each machine, so you can
> > mix-and-match across machines just fine.
> >
> > What you want to avoid doing is changing paradigms on a particular
> > box (and especially not on the server) -- and thus the need to be
> > sure to stick with your own build script on your server.
> >
> > (Note that the "backup" user and groups, UID/GUI 34, are included in
> > the base Debian install, so they will exist on _all_ Debian machines
> > -- while "amanda" or "amandabackup" must have been created sometime
> > after the initial installation, either manually or as part of a
> > .deb-package installation script.)
> >
> > > Now I think I have all the clients but this machine working, so
> > > maybe its time to go see what I have to do to my passwd and group
> > > files to make 3.5.1, built with my script, just work. Then
> > > incorporate those changes into GenesAmandaHelper and make that
> > > work, making it version 0.62, too.
> >
> > "Coyote" is your Amanda server, right? Is that the system you are
> > referring to ("this machine") here? (If you have problems with some
> > other client, that's a separate issue and should probably be in its
> > own thread.)
> >
> > Unless you deleted the "amanda" user recently, you should not have
> > to change anything in passwd or group to get back to using your
> > script-build binaries.
> >
> > If you changed ownerships of some files or directories while trying
> > to get the package-installed version working, those will probably
> > need to be changed back to "amanda" (i.e. restored to the way they
> > were).
> >
> > > The zmanda copy was last touched 6 months ago according to git.
> > > And only came as a tar.zip.
> > >
> > > So where do I get a tarball that incorporates the work done here
> > > over the last couple months?
> >
> > (You should make sure you get back to a working system [i.e.
> > resolving all permission/ownership problems] using what you have
> > built from previously, before trying to switch to something new.)
> >
> > There hasn't been a "release" since 3.5.1, so there are no release
> > tarballs that have anything newer than that.
> >
> > You can pull a tarball down from github, but off hand I don't
> > believe that will be more convienient than building from a local git
> > checkout.
> >
> > However, as far as I can tell, there hasn't been any
> > actually-interesting changes committed to the repo since the 3.5.1
> > release. (What has been committed is the mentioned-on-this-list
> > packaging changes for RPM and Debian, which don't apply to you, plus
> > a few other minor changes which don't seem interesting either.... )
> >
> > But if you are ready to try building from the repo (in preparation
> > for the time in the hopefully-near future when there are interesting
> > changes there), you would follow the instructions in Chris's 9 May
> > 2019 message, e.g.
> >
> > $ cd <your-Zmanda-github-repo-clone-directory>
> > $ git checkout -b 3_5mine origin/3_5
> >
> > (this checks out the origin/3_5 branch, at the same time creating a
> > local branch called "3_5mine"; you can pick a different name if you
> > like. The idea is that you want to be working in a locally-named
> > branch so that any changes you make to files while you are
> > workingcan be saved to that branch, separate from the upstream
> > branch.)
> >
> > Then, from that checkout directory, run your gh.cf script to kick
> > off the build (first making sure the --with-security-file= line is
> > what you want it to be)... and see what happens....
>
> My script has never had that line, as its using
> --with-bsd-security --with-amandahosts \
> and that has worked for around a decade using the repos .deb clients.
> Do I need to change that?
>
> Also the listed /tmp/amanda-dbg dir is full of stuff from dpkg and
> friends, some of it quite a bit newer that the install. And the perms
> are wrong for amanda's use too. So this upcoming build will
> use /var/log/amanda-dbg so I can set its perms for amanda's use.
> Created & done.
>
> So here goes nothing. ./gh.cf is next. "configure not found", run
> autogen first? yes. Now configure is done, make as amanda is running.
>
> I get most of the perms fixed, two gotchas remain
> Now the $config "Daily" is being lost in the error report:
> amanda@coyote:~/amanda$ /usr/local/sbin/amcheck Daily
> parse error: could not open conf
> file '/usr/local/etc/amanda/amanda.conf': Permission denied
>
> where did the daily go? ls -l of /usr/local/etc/amanda:
> so whats the proper chmod to apply to that chain of dirs and files.
>
> I'm going back to bed, up because of leg cramps.
>
> > Nathan
Back up about 7:30, rebuilt the vtapes to get rid of an error caused
by wrong path to executable in my mkvtapes script, amanda now likes that.
but I cannot seem to fix this erronious error.
amanda@coyote:~/amanda$ /usr/local/sbin/amcheck Daily
Amanda Tape Server Host Check
-----------------------------
NOTE: Holding disk '/usr/dumps': 1477480 MB disk space available, using 1476980
MB
slot 1: volume 'Dailys-1'
Will write to volume 'Dailys-1' in slot 1.
NOTE: skipping tape-writable test
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.337 seconds
Amanda Backup Client Hosts Check
--------------------------------
ERROR: coyote: selfcheck request failed: file/dir '/usr/local/etc'
(/usr/local/etc/amanda-security.conf) is writable by the group
ERROR: shop: selfcheck request failed: file/dir '/usr/local/etc'
(/usr/local/etc/amanda-security.conf) is writable by the group
ERROR: picnc: selfcheck request failed: file/dir '/usr/local/etc'
(/usr/local/etc/amanda-security.conf) is writable by the group
ERROR: GO704: selfcheck request failed: file/dir '/usr/local/etc'
(/usr/local/etc/amanda-security.conf) is writable by the group
ERROR: lathe: selfcheck request failed: file/dir '/usr/local/etc'
(/usr/local/etc/amanda-security.conf) is writable by the group
Client check: 5 hosts checked in 13.184 seconds. 5 problems found.
(brought to you by Amanda 3.5.1.git.19364c7b)
Your were correct, amanda-security.conf does not exist on any client.
amanda@coyote:~/amanda$ ls -l /usr/local/etc/
total 48
drwx------ 3 amanda backup 4096 May 26 04:17 amanda
-rw-r--r-- 1 amanda backup 55 Jul 17 2014 amanda-client.conf
-rwx------ 1 root staff 2033 May 26 08:41 amanda-security.conf
and as you can see, is not writeable by group but /etc/group
can effect that, so here is a couple grep's
root@coyote:amanda-3.5.1$ grep amanda /etc/group
mail:x:8:gene,amanda
amanda:x:1001:backup
root@coyote:amanda-3.5.1$ grep backup /etc/group
disk:x:6:gene,backup
backup:x:34:
amanda:x:1001:backup
Maybe fresh eyeballs can see whats wrong, my plastic ones sure aren't. :(
Thanks Nathan, and all.
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>
