On Monday 13 May 2019 12:53:22 pm Chris Hassell wrote: > > But, changing user to amanda is not yet completed, after changing > > the amanda file in /etc/xinetd.d to user=amanda and restarting > > xinetd, I get this at the end of an amcheck: > > > > WARNING: coyote: selfcheck request failed: tcpm_recv_token: invalid > > size: "amandad: must be executed as the \"backup\" user instead of > > the \"amanda\" user\n looking at where amandad is installed, its 99% > > root:root. Looking at my old wheezy install in > > /usr/local/libexec/amanda its 97% root:staff. > > > > So how do I fix this one? /etc/group says that amanda and backuo s/b > > aliases, same group IOW. > > [Chris Hassell] > /etc/group (and /etc/gshadow) handle groups, so the error message > would have to mention groups. > > /etc/passwd and /etc/shadow handle users. It's complaining about the > user "backup" versus the user "amanda".
both are in /etc/passwd. backup is user 34, whereas amanda is 1002 > > Where was this built? Was it the default-from-debian? Yes. > I may pull > that apart to see how they decided it should be built by default. Get all three of them at the debian stretch repo, by enabling the srcs in /etc/apt/sources.d. These are the amd64 binaries I am attempting to use. As to how it was built, there are far more ways to do that than there are ways to skin a cat, so decoding the binary debs is probably best. I could pull the source and see if my gh.cf script could build it, but its geared to working with tarballs where the autogen has already built the configure.in and Makefiles. Those I always build in /home/amanda as amanda who is a member of group disk. But this pile of stink that needs at least 4 users to execute various parts, and that not acceptable, not to mention a security hole big enough to run 88,000 lbs a swinging beef thru at 80 mph. One user, preferably amanda, who doesn't even have a login in the passwd file, and one group with just enough rights to get the job done is all it should take. Redhat started this BS of making everything root because at the time rpm was broken and gave everything the run of the place totally destroying the amanda security model. dpkg has always been able to do it right AFAIK. But the deb makers don't always get it, so they rarely build and package what you can do right with a tarball and a good makefile. One of the main reasons I wrote the original of that script, probably 18 years ago was so I'd always have version to version compatibility by have the options hard coded into the build. But with the git clone its changed in many incompatible ways and the script bales out quickly. I even built and installed about half of Dustions alpha4.00 releases with that same script back in 2012 when he was working on it full time for a few months, but now we have new cooks, each with his own idea of whats right. The last time there was an incompatible change was at 2.4 IIRC. And it was announced beforehand so everyone had a strategy worked out prior to that change. Now somebody, with a successful recipe thats worked for well over a decade, seems now to have been thrown under the bus, and he is upset. But if I can figure out, maybe like you and go get the srcs from the repo, and see if my script can make it. Perhaps by inserting an autogen stage. The present situation is for me a disaster when an attempt to install it with dpkg hangs over some gpg thing I've never used and likely never will, goes crazy and fiddles with the owner:group of something completely un-related, like /etc/nut, is intolerable. But I'll take suggestions about how to solve this present multiple users fiasco before I enable the srcs and try that. This no doubt puts you, Chris, in the middle of a cat fight you may not have bargained for, my apologies for that, but it is what it is. We, I don't think are intending to belittle your efforts, and I for one will say: Thanks Chris. 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>
