Re: if to fork Amanda

[Charles Curley]

On Tue, 7 May 2019 22:27:14 +
Chris Hassell  wrote:

> There we go!  Debian 9.0 looks good to me.
> 
> % bash autogen && ./packaging/deb/buildpkg

Chris, I am going to try duplicating your work.

One thing I have learned is to build test environments on throwaway
machines. I now use virtual machines, but used to use older spare
computers for the job. Re-install from the ground up. Keep a script or
two handy to move things from there.

I'll start by building a VM, and go from there.

-- 
"When we talk of civilization, we are too apt to limit the meaning of
the word to its mere embellishments, such as arts and sciences; but
the true distinction between it and barbarism is, that the one
presents a state of society under the protection of just and
well-administered law, and the other is left to the chance government
of brute force."
- The Rev. James White, Eighteen Christian Centuries, 1889
Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB
https://charlescurley.com

Re: if to fork Amanda

[Gene Heskett]

On Wednesday 08 May 2019 01:37:03 pm Debra S Baddorf wrote:

> > On May 7, 2019, at 9:38 PM, Gene Heskett 
> > wrote:
> >
> > echo "!! Warning !!!"
> > echo "Amanda needs to be configured and built by the"
> > echo "user amanda, but must be installed by user root."
>
> Is this actually still true?   I always configure and build and
> install as root. My backup account is OPERATOR though, so that could
> be why I’ve had no trouble?
>
> Deb Baddorf

IDK Deb, its been so long its not built any docs that I am just 
continuing a tradition thats worked herefor 20 years.


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 

Re: if to fork Amanda

[Jason L Tibbitts III]

> "CH" == Chris Hassell  writes:

CH> Most build systems these days recommend building entirely as a
CH> normal user (even Debian?) and the chown-and-other-ops are done with
CH> careful setuid privileges given to the build system.

CH> RPM and rpmbuild have been doing it that way for years.

Technically RPM doesn't even do that; none of the package build process
is ever done as root.  The proper ownership of the files is stored as
package metadata which gets applied when the package is installed.  The
ownership of the files at build time is immaterial.

We (Fedora and by extension RHEL) used to patch things so that the
Amanda makefile wouldn't try to call chown/chgrp.  Now we pass
BINARY_OWNER and SETUID_GROUP to the makefile with the current user info
so that those calls do nothing (which saves us from having to maintain a
patch).

 - J<

Re: if to fork Amanda

[Jean-Francois Malouin]

* Chris Hoogendyk  [20190508 14:08]:
> I've always done all the configure, build and install from root,
> using the --with-user=amanda and --with-group=amanda in configure.
> Then all my backup and administrative operations are done as user
> amanda. No problems going back 15 years or so.
> 
> On 5/8/19 1:37 PM, Debra S Baddorf wrote:
> >
> >>On May 7, 2019, at 9:38 PM, Gene Heskett  wrote:
> >>
> >>echo "!! Warning !!!"
> >>echo "Amanda needs to be configured and built by the"
> >>echo "user amanda, but must be installed by user root."
> >
> >Is this actually still true?   I always configure and build and install as 
> >root.
> >My backup account is OPERATOR though, so that could be why I’ve had no 
> >trouble?
> >
> >Deb Baddorf
> >
> -- 
> ---
> 
> Chris Hoogendyk
> 
> -
>O__   Systems Administrator
>   c/ /'_ --- Biology & Geosciences Departments
>  (*) \(*) -- 315 Morrill Science Center
> ~~ - University of Massachusetts, Amherst
> 
> 
> 
> ---
> 
> Erdös 4

My 2c: I've always configured and built as a mere user, specifying
--with-user=amanda --with-group=disk at the config step and installing as root. 

jf

Re: if to fork Amanda

[Chris Hoogendyk]

I've always done all the configure, build and install from root, using the --with-user=amanda and 
--with-group=amanda in configure. Then all my backup and administrative operations are done as user 
amanda. No problems going back 15 years or so.


On 5/8/19 1:37 PM, Debra S Baddorf wrote:



On May 7, 2019, at 9:38 PM, Gene Heskett  wrote:

echo "!! Warning !!!"
echo "Amanda needs to be configured and built by the"
echo "user amanda, but must be installed by user root."


Is this actually still true?   I always configure and build and install as root.
My backup account is OPERATOR though, so that could be why I’ve had no trouble?

Deb Baddorf


--
---

Chris Hoogendyk

-
   O__   Systems Administrator
  c/ /'_ --- Biology & Geosciences Departments
 (*) \(*) -- 315 Morrill Science Center
~~ - University of Massachusetts, Amherst



---

Erdös 4

Re: if to fork Amanda

[Chris Hassell]

Most build systems these days recommend building entirely as a normal
user (even Debian?) and the chown-and-other-ops are done with careful
setuid privileges given to the build system.

RPM and rpmbuild have been doing it that way for years.

On 5/8/19 11:37 AM, Debra S Baddorf wrote:
>
>> On May 7, 2019, at 9:38 PM, Gene Heskett  wrote:
>>
>>  echo "!! Warning !!!"
>>  echo "Amanda needs to be configured and built by the"
>>  echo "user amanda, but must be installed by user root."
>
> Is this actually still true?   I always configure and build and install as 
> root.
> My backup account is OPERATOR though, so that could be why I’ve had no 
> trouble?
>
> Deb Baddorf
>

Re: if to fork Amanda

[Debra S Baddorf]

> On May 7, 2019, at 9:38 PM, Gene Heskett  wrote:
> 
>   echo "!! Warning !!!"
>   echo "Amanda needs to be configured and built by the"
>   echo "user amanda, but must be installed by user root."


Is this actually still true?   I always configure and build and install as root.
My backup account is OPERATOR though, so that could be why I’ve had no trouble?

Deb Baddorf

Re: if to fork Amanda

[Gene Heskett]

On Wednesday 08 May 2019 01:48:03 am Jon LaBadie wrote:

> On Wed, May 08, 2019 at 12:01:42AM +, Chris Hassell wrote:
> > I don't allow a script to alter the repo unless it's in big neon.
>
> ...
>
> > It does (if I recall correctly) require a user "amandabackup" to
> > exist, but that's all.   The user 'amanda' (?), not so sure if
> > that's made in the build or not.
>
> The original ananda user was "amanda", not "amandabackup".  Some of us
> old codgers, who don't have staffers named "amanda"  still prefer the
> original user name.  I do it by having two users, amanda and
> amandabackup with the same uid/gid.
>
> jon

Neat solution Jon, from another of the old codgers.


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 

Re: if to fork Amanda

[Jon LaBadie]

On Wed, May 08, 2019 at 12:01:42AM +, Chris Hassell wrote:
> I don't allow a script to alter the repo unless it's in big neon.
> 
...
>
> It does (if I recall correctly) require a user "amandabackup" to exist, but 
> that's all.   The user 'amanda' (?), not so sure if that's made in the build 
> or not.

The original ananda user was "amanda", not "amandabackup".  Some of us
old codgers, who don't have staffers named "amanda"  still prefer the
original user name.  I do it by having two users, amanda and amandabackup
with the same uid/gid.

jon
-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)

Re: if to fork Amanda

[Gene Heskett]

On Tuesday 07 May 2019 08:01:42 pm Chris Hassell wrote:

> I don't allow a script to alter the repo unless it's in big neon.
>
> This is (btw) all placed in github ... so the actual clone is 'git
> clone'... and its mighty fast.  Far faster than a subversion copy or
> even a zip file.  I'd just try the below if you're okay with that.  
> (Where in anywhere is gh.cf?   I can't find it in the repo and I've
> never used a gh.cf once.)
Somebody made a front end for scripts that made sure you were the correct 
user, so I added by  my own  configure with the options I always used 
sorta hard coded. The name was easy, for gene hesketts config.

So here is gh.cf:

#!/bin/sh
# since I'm always forgetting to su amanda...
if [ `whoami` != 'amanda' ]; then
echo
echo "!! Warning !!!"
echo "Amanda needs to be configured and built by the"
echo "user amanda, but must be installed by user root."
echo
exit 1
fi
make clean
rm -f config.status config.cache
./configure --with-user=amanda \
--with-group=disk \
--with-owner=amanda \
--with-gnu-ld \
--prefix=/usr/local/ \
--with-debugging=/tmp/amanda-dbg/ \
--with-tape-server=coyote \
--with-bsdtcp-security --with-amandahosts \
--with-configdir=/usr/local/etc/amanda \
--enable-manpage-build  \
--with-readline \
--with-gnutar=/bin/tar
--with-security-file=/etc/amanda-security.conf
echo "sleeping for reading configures warnings"
echo "a make as amanda will continue after 75 seconds..."
sleep 75
make

Pretty simple, but guaranteed a build with consistant options.

I've also written a wrapper script so if the main drive explodes and 
kills all your goldfish 10 minutes after the backup is done, saves 
enough of the database to the tape such that a full bare metal recovery 
puts the machine in the state it was in when the LAST backup was done, a 
day later than amanda can do by itself.  Thats, in a slightly earlier 
version, on my web page as GenesAmandaHelper-0.61.
> To drag in the current work I pushed that's definitely this (for
> 3.5.1) you need to make a branch off of origin/3_5, which has those
> changes I made.
>
> It does (if I recall correctly) require a user "amandabackup" to
> exist, but that's all.   The user 'amanda' (?), not so sure if that's
> made in the build or not.
>
> So use this entirely as yourself in your home/tmpdir or somewhere ...
> (building isn't installing, so the security is far less)
>
> % git clone git://github.com/zmanda/amanda.git
>
> Then (still as yourself) ...
>
> % git checkout -b 3_5mine origin/3_5   # current target I'm assuming?
>
> % bash autogen && ./packaging/deb/buildpkg
>
> and with all the latest debian goodness it creates the debian packages
> which only then deserve a new user to install them.
>
> Give it a whirl, hopefully with a zippier little clone from git.
>
> -- CH
Printed for when I'm awake, its getting sleepy out now.  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 

Re: if to fork Amanda

[Gene Heskett]

On Tuesday 07 May 2019 08:01:42 pm Chris Hassell wrote:

> I don't allow a script to alter the repo unless it's in big neon.
>
> This is (btw) all placed in github ... so the actual clone is 'git
> clone'... and its mighty fast.  Far faster than a subversion copy or
> even a zip file.  I'd just try the below if you're okay with that.  
> (Where in anywhere is gh.cf?   I can't find it in the repo and I've
> never used a gh.cf once.)
Somebody made a front end for scripts that made sure you were the correct 
user, so I added by  my own  configure with the options I always used 
sorta hard coded. The name was easy, for gene hesketts config.

So here is gh.cf:


>
> To drag in the current work I pushed that's definitely this (for
> 3.5.1) you need to make a branch off of origin/3_5, which has those
> changes I made.
>
> It does (if I recall correctly) require a user "amandabackup" to
> exist, but that's all.   The user 'amanda' (?), not so sure if that's
> made in the build or not.
>
> So use this entirely as yourself in your home/tmpdir or somewhere ...
> (building isn't installing, so the security is far less)
>
> % git clone git://github.com/zmanda/amanda.git
>
> Then (still as yourself) ...
>
> % git checkout -b 3_5mine origin/3_5   # current target I'm assuming?
>
> % bash autogen && ./packaging/deb/buildpkg
>
> and with all the latest debian goodness it creates the debian packages
> which only then deserve a new user to install them.
>
> Give it a whirl, hopefully with a zippier little clone from git.
>
> -- CH
>
>
> On 5/7/19 4:31 PM, Gene Heskett wrote:
>
> On Tuesday 07 May 2019 06:27:14 pm Chris Hassell wrote:
>
> But that bailed out in about 11 lines:
> root@coyote:amanda-master$ su amanda -c "bash autogen
> && ./packaging/deb/buildpkg"
> See DEVELOPING for instructions on updating:
>  * gettext macros
>  * gnulib
>  * libtool files
> ..creating file lists
> config/set_full_version: line 21: conftemp.svn: Permission denied
> config/set_full_version: line 81: FULL_VERSION: Permission denied
> ..aclocal
> aclocal: error: config/amanda/version.m4:19: file 'FULL_VERSION' does
> not exist
> aclocal failed
>
> The amanda-master.zip unpacks with several different ownerships, so I
> made everything belong to amanda:amanda after unpacking it.  And I did
> the apt install without any objections from apt. I'll admit I'm lost.
> The system was uptodate earlier today.
>
>
>
>
> Copyright 2019 by Maurice E. Heskett
> Cheers, Gene Heskett



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 

Re: if to fork Amanda

[Chris Hassell]

I don't allow a script to alter the repo unless it's in big neon.

This is (btw) all placed in github ... so the actual clone is 'git clone'... 
and its mighty fast.  Far faster than a subversion copy or even a zip file.  
I'd just try the below if you're okay with that.   (Where in anywhere is gh.cf? 
  I can't find it in the repo and I've never used a gh.cf once.)

To drag in the current work I pushed that's definitely this (for 3.5.1) you 
need to make a branch off of origin/3_5, which has those changes I made.

It does (if I recall correctly) require a user "amandabackup" to exist, but 
that's all.   The user 'amanda' (?), not so sure if that's made in the build or 
not.

So use this entirely as yourself in your home/tmpdir or somewhere ... (building 
isn't installing, so the security is far less)

% git clone git://github.com/zmanda/amanda.git

Then (still as yourself) ...

% git checkout -b 3_5mine origin/3_5   # current target I'm assuming?

% bash autogen && ./packaging/deb/buildpkg

and with all the latest debian goodness it creates the debian packages which 
only then deserve a new user to install them.

Give it a whirl, hopefully with a zippier little clone from git.

-- CH


On 5/7/19 4:31 PM, Gene Heskett wrote:

On Tuesday 07 May 2019 06:27:14 pm Chris Hassell wrote:

But that bailed out in about 11 lines:
root@coyote:amanda-master$ su amanda -c "bash autogen
&& ./packaging/deb/buildpkg"
See DEVELOPING for instructions on updating:
 * gettext macros
 * gnulib
 * libtool files
..creating file lists
config/set_full_version: line 21: conftemp.svn: Permission denied
config/set_full_version: line 81: FULL_VERSION: Permission denied
..aclocal
aclocal: error: config/amanda/version.m4:19: file 'FULL_VERSION' does not
exist
aclocal failed

The amanda-master.zip unpacks with several different ownerships, so I
made everything belong to amanda:amanda after unpacking it.  And I did
the apt install without any objections from apt. I'll admit I'm lost.
The system was uptodate earlier today.




Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett

Re: if to fork Amanda

[Gene Heskett]

On Tuesday 07 May 2019 06:27:14 pm Chris Hassell wrote:

> There we go!  Debian 9.0 looks good to me.

Who were you? I always do this as amanda, sudo -i (enter pw, become root, 
then "su ananda -c "./gh.cf", which builds it as amanda.  When its done 
with no errors. then I'm still root, and root installs it. But this 
looks like the start of a new, much simpler script.

This autogets the patches from git?

I'll find out. :)
>
> % bash autogen && ./packaging/deb/buildpkg

I'll wrap this up in an su amanda -c "include above".

But that bailed out in about 11 lines:
root@coyote:amanda-master$ su amanda -c "bash autogen 
&& ./packaging/deb/buildpkg"
See DEVELOPING for instructions on updating:
 * gettext macros
 * gnulib
 * libtool files
..creating file lists
config/set_full_version: line 21: conftemp.svn: Permission denied
config/set_full_version: line 81: FULL_VERSION: Permission denied
..aclocal
aclocal: error: config/amanda/version.m4:19: file 'FULL_VERSION' does not 
exist
aclocal failed

The amanda-master.zip unpacks with several different ownerships, so I 
made everything belong to amanda:amanda after unpacking it.  And I did 
the apt install without any objections from apt. I'll admit I'm lost.
The system was uptodate earlier today.
>
> and then [magic happens] 
>
> ~/src/amanda #0$0 [..manda:3_5[origin/3_5:+4]]@DEB9$ ls -l *.deb
> -rw-r--r-- 1 hassell hassell 1298368 May  7 16:10
> amanda-backup-client_3.5.1.git.507ad0ab-1Debian99_amd64.deb -rw-r--r--
> 1 hassell hassell  101746 May  7 16:10
> amanda-backup-client-dbgsym_3.5.1.git.507ad0ab-1Debian99_amd64.deb
> -rw-r--r-- 1 hassell hassell 2085204 May  7 16:10
> amanda-backup-server_3.5.1.git.507ad0ab-1Debian99_amd64.deb -rw-r--r--
> 1 hassell hassell  140150 May  7 16:09
> amanda-backup-server-dbgsym_3.5.1.git.507ad0ab-1Debian99_amd64.deb
> ~/src/amanda #0$0 [..manda:3_5[origin/3_5:+4]]@DEB9$
>
> I'll stick my neck out and leave the changes on 3_5.  Not on master
> ... but they should work for you.
>
> % apt-get install ca-certificates xinetd perl gettext bsd-mailx
> dpkg-dev \ debhelper dump gnuplot-nox libtool mtx smbclient \
> libcurl4-gnutls-dev libncurses5-dev libreadline-dev libssl-dev \
> docbook-xsl swig xsltproc
>
> That's the sum-total after a pretty clean (after installing 'konsole')
> install of debian 9.  Let me know if your mileage fails to vary from
> 0.
>
> -- CH
>
>
> On 5/6/19 2:06 PM, Gene Heskett wrote:
>
>
>
>
> Chris, glad to here it. First, you won't find docs because the
> configure script in 3.5.1 is busted, welded solid to docbook-sxml 1.24
> and it hasn't even existed in a debian install for a decade. Stephan
> and I have both tried to fix it. look at about line 4520, I can't read
> it all that well because of a crappy choice in highlight colors my fav
> editor uses. But ANAICT the text there freezes the version it will
> accept while the text of the failure reports >=1.22. Doesn't make any
> diff because that particilar file doesn't exist in debian.
>
> Now, I'll unpack the zip if its not protected, that I managed to coax
> out of git-hub this morning. BRB. My gawd, unpacked its 20 megs! and
> its taking mc a while to copy it to /home/amanda/amanda-master in this
> new install. Done. Now I note there is not a "configure" but there is
> an "autogen", so I assume (theres that word again) that will make us
> look like idiots.  The next thing I note is that its all owned by
> root:root which is typical of useing a root session of mc to unpack a
> damned zip. We DON'T have this problem with tar.gz's so thats strike
> one. Since we usually build it as the amanda user in home amanda, just
> more of my local security. We normally chown -R amanda:amanda as the
> next step. Done.  Next is "cp ../gh.cf ."
> Done. gh.cf drives the configure script, but there isn't one.  Study
> up on "autogen" and await your reply.
>
> Is there anything I need to know before I invoke it?
>
> Copyright 2019 by Maurice E. Heskett
> Cheers, Gene Heskett



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 

Re: if to fork Amanda

[Chris Hassell]

There we go!  Debian 9.0 looks good to me.

% bash autogen && ./packaging/deb/buildpkg

and then [magic happens] 

~/src/amanda #0$0 [..manda:3_5[origin/3_5:+4]]@DEB9$ ls -l *.deb
-rw-r--r-- 1 hassell hassell 1298368 May  7 16:10 
amanda-backup-client_3.5.1.git.507ad0ab-1Debian99_amd64.deb
-rw-r--r-- 1 hassell hassell  101746 May  7 16:10 
amanda-backup-client-dbgsym_3.5.1.git.507ad0ab-1Debian99_amd64.deb
-rw-r--r-- 1 hassell hassell 2085204 May  7 16:10 
amanda-backup-server_3.5.1.git.507ad0ab-1Debian99_amd64.deb
-rw-r--r-- 1 hassell hassell  140150 May  7 16:09 
amanda-backup-server-dbgsym_3.5.1.git.507ad0ab-1Debian99_amd64.deb
~/src/amanda #0$0 [..manda:3_5[origin/3_5:+4]]@DEB9$

I'll stick my neck out and leave the changes on 3_5.  Not on master ... but 
they should work for you.

% apt-get install ca-certificates xinetd perl gettext bsd-mailx dpkg-dev \
debhelper dump gnuplot-nox libtool mtx smbclient \
libcurl4-gnutls-dev libncurses5-dev libreadline-dev libssl-dev \
docbook-xsl swig xsltproc

That's the sum-total after a pretty clean (after installing 'konsole') install 
of debian 9.  Let me know if your mileage fails to vary from 0.

-- CH


On 5/6/19 2:06 PM, Gene Heskett wrote:




Chris, glad to here it. First, you won't find docs because the configure
script in 3.5.1 is busted, welded solid to docbook-sxml 1.24 and it
hasn't even existed in a debian install for a decade. Stephan and I have
both tried to fix it. look at about line 4520, I can't read it all that
well because of a crappy choice in highlight colors my fav editor uses.
But ANAICT the text there freezes the version it will accept while the
text of the failure reports >=1.22. Doesn't make any diff because that
particilar file doesn't exist in debian.

Now, I'll unpack the zip if its not protected, that I managed to coax out
of git-hub this morning. BRB. My gawd, unpacked its 20 megs! and its
taking mc a while to copy it to /home/amanda/amanda-master in this new
install. Done. Now I note there is not a "configure" but there is
an "autogen", so I assume (theres that word again) that will make us
look like idiots.  The next thing I note is that its all owned by
root:root which is typical of useing a root session of mc to unpack a
damned zip. We DON'T have this problem with tar.gz's so thats strike
one. Since we usually build it as the amanda user in home amanda, just
more of my local security. We normally chown -R amanda:amanda as the
next step. Done.  Next is "cp ../gh.cf ."
Done. gh.cf drives the configure script, but there isn't one.  Study up
on "autogen" and await your reply.

Is there anything I need to know before I invoke it?

Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett

Re: if to fork Amanda

[Gene Heskett]

On Monday 06 May 2019 12:14:54 pm Chris Hassell wrote:

> Hello,
>
> I'm a major advocate for OSS in general here at Zmanda/BETSOL. I'm
> interested in giving a full-voiced support to the community of those
> who know Amanda works well for them.   Opinions may vary and projects
> fork for all reasons or no reason (as everyone has a right to) but I
> hope to help keep contributions and development all in one if we can.
>
> Firstly... Emails like this one help us know what priorities to devote
> back to community.  Our big push are special devices (to integrate
> into Amanda) and our ZMC UI and enterprise-scale maangement tools.  A
> few things:
>
> 1) There's no more development at the Sourceforge/SVN site and Git is
> caught up.
>
> I'm pretty sure we've integrated every single patch into Github-Git so
> far and so nothing is lost and everything is in place to develop at
> Github.  I think only two or three pull requests need to be handled
> (besides my own) now.  It's just been very slow and I only started
> here in Feb/March.
>
> 2) I'm also the build-o-mancer here and have gotten success on Debian
> ( think)
>
> I'll look for a test for Stretch but I'm pretty sure we can get it up
> and going too.  It just hasn't been a priority at times, but I have
> been able to get it built on the latest Fedora and Debian and Ubuntu
> and SLES (I think?) as well.   I'm currently spinning VMs for
> literally every OS-version we can find in order to test them all at
> unit-test level.
>
> 3) Our OSS is all of our Open-OSS.
>
> We may/may-not have good docs on line.  (Looking for those?) Still, I
> don't think Zmanda/BETSOL hosts those anyway.  I don't know what
> closed-source stuff we could paywall without catching heck (gawsh
> darnit!) in tons of ways.  The community deserves what the community
> contributes, even if Zmanda-employees did some in the past.
>
> In short ... hopefully we can solve a Debian-Stretch problem as needed
> as well as anything else.
>
>      -- CH
>
Chris, glad to here it. First, you won't find docs because the configure 
script in 3.5.1 is busted, welded solid to docbook-sxml 1.24 and it 
hasn't even existed in a debian install for a decade. Stephan and I have 
both tried to fix it. look at about line 4520, I can't read it all that 
well because of a crappy choice in highlight colors my fav editor uses.  
But ANAICT the text there freezes the version it will accept while the 
text of the failure reports >=1.22. Doesn't make any diff because that 
particilar file doesn't exist in debian.

Now, I'll unpack the zip if its not protected, that I managed to coax out 
of git-hub this morning. BRB. My gawd, unpacked its 20 megs! and its 
taking mc a while to copy it to /home/amanda/amanda-master in this new 
install. Done. Now I note there is not a "configure" but there is 
an "autogen", so I assume (theres that word again) that will make us 
look like idiots.  The next thing I note is that its all owned by 
root:root which is typical of useing a root session of mc to unpack a 
damned zip. We DON'T have this problem with tar.gz's so thats strike 
one. Since we usually build it as the amanda user in home amanda, just 
more of my local security. We normally chown -R amanda:amanda as the 
next step. Done.  Next is "cp ../gh.cf ."
Done. gh.cf drives the configure script, but there isn't one.  Study up 
on "autogen" and await your reply.

Is there anything I need to know before I invoke it?

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 

Re: if to fork Amanda

[Chris Nighswonger]

+1 ...

On Mon, May 6, 2019 at 1:25 PM Dustin J. Mitchell  wrote:

> On Mon, May 6, 2019 at 12:25 PM Chris Hassell 
> wrote:
>
>> I'm a major advocate for OSS in general here at Zmanda/BETSOL. I'm
>> interested in giving a full-voiced support to the community of those who
>> know Amanda works well for them.   Opinions may vary and projects fork
>> for all reasons or no reason (as everyone has a right to) but I hope to
>> help keep contributions and development all in one if we can.
>>
>
> I'm *really* happy to hear this and happy you're here :)
>
> Dustin
>

Re: if to fork Amanda

[Chris Hassell]

Hello,

I'm a major advocate for OSS in general here at Zmanda/BETSOL. I'm 
interested in giving a full-voiced support to the community of those who 
know Amanda works well for them.   Opinions may vary and projects fork 
for all reasons or no reason (as everyone has a right to) but I hope to 
help keep contributions and development all in one if we can.

Firstly... Emails like this one help us know what priorities to devote 
back to community.  Our big push are special devices (to integrate into 
Amanda) and our ZMC UI and enterprise-scale maangement tools.  A few 
things:

1) There's no more development at the Sourceforge/SVN site and Git is 
caught up.

I'm pretty sure we've integrated every single patch into Github-Git so 
far and so nothing is lost and everything is in place to develop at 
Github.  I think only two or three pull requests need to be handled 
(besides my own) now.  It's just been very slow and I only started here 
in Feb/March.

2) I'm also the build-o-mancer here and have gotten success on Debian ( 
think)

I'll look for a test for Stretch but I'm pretty sure we can get it up 
and going too.  It just hasn't been a priority at times, but I have been 
able to get it built on the latest Fedora and Debian and Ubuntu and SLES 
(I think?) as well.   I'm currently spinning VMs for literally every 
OS-version we can find in order to test them all at unit-test level.

3) Our OSS is all of our Open-OSS.

We may/may-not have good docs on line.  (Looking for those?) Still, I 
don't think Zmanda/BETSOL hosts those anyway.  I don't know what 
closed-source stuff we could paywall without catching heck (gawsh 
darnit!) in tons of ways.  The community deserves what the community 
contributes, even if Zmanda-employees did some in the past.

In short ... hopefully we can solve a Debian-Stretch problem as needed 
as well as anything else.

     -- CH

On 5/6/19 7:02 AM, Gene Heskett wrote:
> Well, I have now updated my main machine, and the amanda server to
> stretch, and updated to latest. But no version of amanda I have will
> build on stretch.
>
> Betsol has put up paywalls at zmanda so theres no source available there.
> Copyright 2019 by Maurice E. Heskett
> Cheers, Gene Heskett

Re: if to fork Amanda

[Gene Heskett]

On Monday 25 March 2019 02:40:56 pm Stefan G. Weichinger wrote:

> Am 20.03.19 um 18:53 schrieb Gene Heskett:
> > The sudden silence from JLM did beg for the question to be asked,
> > and I'm fairly famous for that, so it was mentioned.  I hope you are
> > well these days Dustin. I had to have a pacemaker installed back in
> > January. I guess its a sign of the 84 years that makes me the
> > resident old fart on some lists.
>
> And you are still welcome as an outstanding amanda user for years now
> ;-)
>
> best wishes for your heart, btw
>
> -

Well, I have now updated my main machine, and the amanda server to 
stretch, and updated to latest. But no version of amanda I have will 
build on stretch.

Betsol has put up paywalls at zmanda so theres no source available there.

>
> aside from that I'd like to keep the latest discussion alive.
>
> In some off-list emails the suggestion came up to prepare a
> github-repository forked off
>
> https://github.com/zmanda/amanda

So I dlded the amanda-master.zip from git-hub, but it will not register 
me because my email is already taken, and its the only one I have. I am 
a member at another project but its never sent me an email yet in the 
time since git-hub started. It seems nitros9 now has repos several 
places besides the hg based one I used for years. Nitros9 is what became 
of an aftermarket os for the trs-80 Color Computer, and now can be run 
on dragons too, which is the japanese version of the "coco" with a 
parport the coco doesn't have.  Modeled on unix w/o all the security 
stuff, nitros9 in the early days, is the main reason I've only owned a 
windows machine for about a month, which got wiped and mandrake 
installed when I found the windows drivers for its broadcom radio 
couldn't run the radio card in it.  So I really am a windows dummy. To 
me, windows IS a virus, to be medicated with a drive wipe and linux 
install.

Anyway, I'll soon find out if this zip will build on debian stretch.

More later, probably with some invective...
> (there are many: https://github.com/zmanda/amanda/network/members)
>
> *plus* the patches since early 2018 which only landed in
> sourceforge-svn:
>
> https://sourceforge.net/p/amanda/code/7719/log/?path=
>
> -
>
> I am currently trying to come up with that ... a bit of tooling around
> with "git svn" etc
>
> Any help welcome here.
>
> Based on that we would be able to merge some of the pull-requests
> filed here:
>
> https://github.com/zmanda/amanda/pulls
>
> if they are filed against the new repo again.
>
> And from there maybe roll some beta-tarballs and solve some issues:
>
> https://github.com/zmanda/amanda/issues
>
> I'd also suggest to move *some* of the bug-related threads over into
> github-Issue-threads then. IMO it's easier then to exactly relate the
> communications to the exact lines and patches in the code etc / but
> that's a detail for the future already.
>
> -
>
> The main question is if there are any amanda-hackers left here who are
> knowing the code well enough to take over the dev-work ... and want to
> contribute.
>
> So far JLM has stayed quiet for a year or so, we don't know.
>
> @JL: if you read this (I am quite sure), please know that we all
> appreciate your work done for this project and would like to at least
> read that you are doing well.
>
> Even better (for amanda) it would be if you could contribute again or
> help others to take over.
>
> -
>
> Maybe we just do what @Betsol (1) was waiting for: taking up the work
> ...
>
> I don't know.
>
> Just be assured that I would like to keep on contributing docs,
> questions, testing and maybe some organization work.
>
> Looking forward to any suggestions etc
>
> Stefan
>
> (1) ashwin.kris...@betsol.com  in CC: , just in case.



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 

RE: if to fork Amanda

[Chris Hassell]

> -Original Message-
> From: Stefan G. Weichinger 

> So you suggest skipping my try to svn2git here? Does that mean that you will
> come up with new patches etc in github and plan to sync those over to the
> betsol/sourceforge-svn-repo?

[Chris Hassell] 
Actually I am using the git-svn bridge and have pulled all of the subversion 
branches/tags into place in a local copy of the SVN version.  From there I act 
upon indication of any new git commits to any branch ... compare on the correct 
branch to add them and then apply them using the upstream 'git svn dcommit' 
command.

However it is.. the flow is pretty small at this point, but both sides need to 
remain identical.  It's just a matter of allowing a normal 'Github' workflow to 
help us out.

> Is ther ongoing work behind the scenes to deal with all the Issues and PRs on
> github already?

[Chris Hassell] 
I've mentioned that to my boss.  I, myself, am not a contributor on the github 
side.  We may be working with a skeleton crew to review and push through new 
PRs (some for modernizing the build just recently) so one would hope we can 
contact those few on Github and get some reviewing moving forward.  Our branch 
also has work for Unicode that has to be sent in as well.

Already we've seen one or two customer problems that were solved by upgrading 
from 3.5 to get some modern versions of files, so there's good reason to 
sharpen up the rest of the community version.
 
> I assume that as long the project looks that inactive it won't trigger any 
> activity
> and contributions either.

[Chris Hassell] 
Well, if any surprises are added on the subversion side it will be visible and 
we can handle that case-by-case.

> Moving to the more modern and widely accepted platform of github should help
> maybe.

[Chris Hassell] 
In my years of open source the only thing that truly kills off a project is the 
success of a different approach ... and even then there needs to be a clear 
path to migrate to it.  Open source should not have to apologize for keeping a 
project working and alive.  Those who need it create its very lifeblood, and 
that's a far better way to implement standards/infrastructure tools that can be 
trusted for LTS.

> greets, Stefan

Re: if to fork Amanda

[Stefan G. Weichinger]

Am 25.03.19 um 22:53 schrieb Chris Hassell:
> Hi all,
> 
> Actually here at BETSOL I'm tasked with getting changes from
> github-git converted into SVN commits.
> 
> Git at Github should be the main repo AFAIK.  It's been a bit quiet
> too long to treat it like the back end of the master-slave.  So long
> as we have the reverse able to work (without making a mess), then we
> shouldn't have a problem getting pull-requests (which I have soon)
> put through in Git and then become commits in SVN automatically (with
> author names etc..).
> 
> Though we would need to get admins responding to and working with
> merges in git.

Chris, hi and thanks for your feedback.

So you suggest skipping my try to svn2git here? Does that mean that you
will come up with new patches etc in github and plan to sync those over
to the betsol/sourceforge-svn-repo?

Is ther ongoing work behind the scenes to deal with all the Issues and
PRs on github already?

I assume that as long the project looks that inactive it won't trigger
any activity and contributions either.

Moving to the more modern and widely accepted platform of github should
help maybe.

greets, Stefan

RE: if to fork Amanda

[Chris Hassell]

Hi all,

Actually here at BETSOL I'm tasked with getting changes from github-git 
converted into SVN commits.  

Git at Github should be the main repo AFAIK.  It's been a bit quiet too long to 
treat it like the back end of the master-slave.  So long as we have the reverse 
able to work (without making a mess), then we shouldn't have a problem getting 
pull-requests (which I have soon) put through in Git and then become commits in 
SVN automatically (with author names etc..).

Though we would need to get admins responding to and working with merges in git.

-- CH 

> -Original Message-
> From: owner-amanda-hack...@amanda.org  hack...@amanda.org> On Behalf Of Chapman Flack
> Sent: Monday, March 25, 2019 3:15 PM
> To: li...@xunil.at; amanda-users@amanda.org
> Cc: Amanda Hackers ; Ashwin Krishna
> 
> Subject: Re: if to fork Amanda
> 
> On 3/25/19 2:40 PM, Stefan G. Weichinger wrote:
> > In some off-list emails the suggestion came up to prepare a
> > github-repository forked off
> >
> > https://github.com/zmanda/amanda
> >
> > (there are many:
> https://github.com/zmanda/amanda/network/members)
> >
> > *plus* the patches since early 2018 which only landed in sourceforge-svn:
> >
> > https://sourceforge.net/p/amanda/code/7719/log/?path=
> >
> > I am currently trying to come up with that ... a bit of tooling around
> > with "git svn" etc
> 
> I also am playing at that, though at the moment not working on it as
> assiduously as on some other unrelated things.
> 
> I'll report here if I get a successful result that preserves the continuity 
> of the
> past svn-to-git mirroring. (I won't be mad if somebody beats me to it.)
> 
> Meanwhile, I have at least made sure that
> 
> https://github.com/jcflack/amanda
> 
> is up to date with zmanda/amanda, up through svn r7714, the last one that
> seems to have landed there.
> 
> Regards,
> -Chap

Re: if to fork Amanda

[Stefan G. Weichinger]

Am 20.03.19 um 18:53 schrieb Gene Heskett:

> The sudden silence from JLM did beg for the question to be asked, and I'm 
> fairly famous for that, so it was mentioned.  I hope you are well these 
> days Dustin. I had to have a pacemaker installed back in January. I 
> guess its a sign of the 84 years that makes me the resident old fart on 
> some lists.

And you are still welcome as an outstanding amanda user for years now ;-)

best wishes for your heart, btw

-

aside from that I'd like to keep the latest discussion alive.

In some off-list emails the suggestion came up to prepare a
github-repository forked off

https://github.com/zmanda/amanda

(there are many: https://github.com/zmanda/amanda/network/members)

*plus* the patches since early 2018 which only landed in sourceforge-svn:

https://sourceforge.net/p/amanda/code/7719/log/?path=

-

I am currently trying to come up with that ... a bit of tooling around
with "git svn" etc

Any help welcome here.

Based on that we would be able to merge some of the pull-requests filed
here:

https://github.com/zmanda/amanda/pulls

if they are filed against the new repo again.

And from there maybe roll some beta-tarballs and solve some issues:

https://github.com/zmanda/amanda/issues

I'd also suggest to move *some* of the bug-related threads over into
github-Issue-threads then. IMO it's easier then to exactly relate the
communications to the exact lines and patches in the code etc / but
that's a detail for the future already.

-

The main question is if there are any amanda-hackers left here who are
knowing the code well enough to take over the dev-work ... and want to
contribute.

So far JLM has stayed quiet for a year or so, we don't know.

@JL: if you read this (I am quite sure), please know that we all
appreciate your work done for this project and would like to at least
read that you are doing well.

Even better (for amanda) it would be if you could contribute again or
help others to take over.

-

Maybe we just do what @Betsol (1) was waiting for: taking up the work ...

I don't know.

Just be assured that I would like to keep on contributing docs,
questions, testing and maybe some organization work.

Looking forward to any suggestions etc

Stefan

(1) ashwin.kris...@betsol.com  in CC: , just in case.