SafeKeep

Dimi,

Can you update the RPM spec file with the following patch.  Obviously,
the ChangeLog diffs can be ignored, and the Version is TBD.

I've also attached the README.Fedora file, which is listed.

Thanks
Frank

On Thu, 2011-03-03 at 12:18 -0500, Dimi Paun wrote: 
> Hi folks,
> 
> I'm done with changes for 1.3.2, anything else
> before I push out a release?
> 

--- safekeep.spec.in	2011-02-27 15:46:49.000000000 +1100
+++ /home/frank/Src/rpmbuild/safekeep-1.3.1/safekeep.spec	2011-02-27 18:24:15.000000000 +1100
@@ -1,5 +1,5 @@
 %define name    safekeep
-%define version TBD
+%define version 1.3.1
 %define release 1
 %define homedir %{_localstatedir}/lib/%{name}
 
@@ -12,9 +12,11 @@
 License:        GPLv2+
 URL:            http://safekeep.sourceforge.net
 Source0:        http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
+Source1:	README.Fedora
 BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildArch:      noarch
+BuildRequires:	xmlto, asciidoc > 6.0.3
 
 %description
 SafeKeep is a client/server backup system which enhances the
@@ -65,6 +67,7 @@
 
 %prep
 %setup -q
+cp %{SOURCE1} ./
 
 %build
 make build
@@ -99,6 +102,7 @@
 %{_bindir}/safekeep
 %{_mandir}/man1/safekeep.1*
 %doc AUTHORS COPYING LICENSE README TODO samples/client-script-sample.sh
+%doc README.Fedora
 
 %files client
 %defattr(-,root,root,-)
@@ -116,6 +120,10 @@
 %doc samples/sample.backup
 
 %changelog
+* Sun Feb 27 2011 Frank Crawford <frank@...> 1.3.1-1
+  - Latest upstream release 
+  - Refresh changelog from upstream
+
 * Mon Nov 22 2010 Dimi Paun <dimi@...> 1.3.1-1
   - Fix a few serios errors preventing safekeep from running.
   - Better reporting of client messages and exceptions.
@@ -170,6 +178,9 @@
   - Add some clarifications to the documentation
   - Add support for FreeBSD
 
+* Fri Oct 19 2007 Jef Spaleta <jspaleta@...> 1.0.3-2
+  - Added README.Fedora with explanation of client subpackaging.
+
 * Fri Oct 19 2007 Dimi Paun <dimi@...> 1.0.3-1
   - Clarify licensing in lite of the new GPLv3 license;
   - New --force option to handle unexpected problems with the data repository;

On Sat, 2011-03-05 at 18:40 +1100, Frank Crawford wrote:
> 
> Can you update the RPM spec file with the following patch.  Obviously,
> the ChangeLog diffs can be ignored, and the Version is TBD.
> 
> I've also attached the README.Fedora file, which is listed.

OK, I've included the changes, but I've integrated the README.Fedora
into the rest of the package, as there is nothing Fedora-specific in it.

I think we should be ready to go.

-- 
Dimi Paun <dimi@...>
Lattica, Inc.

Dimi,

I've pulled down the latest CVS and will give it a go for a few days.

Frank

On Sun, 2011-03-06 at 12:52 -0500, Dimi Paun wrote: 
> On Sat, 2011-03-05 at 18:40 +1100, Frank Crawford wrote:
> > 
> > Can you update the RPM spec file with the following patch.  Obviously,
> > the ChangeLog diffs can be ignored, and the Version is TBD.
> > 
> > I've also attached the README.Fedora file, which is listed.
> 
> OK, I've included the changes, but I've integrated the README.Fedora
> into the rest of the package, as there is nothing Fedora-specific in it.
> 
> I think we should be ready to go.
>

Folks,

Okay, I've pushed 1.3.2 into both Fedora rawhide and test for F15
release.  It should come out sometime in the near future.

Does anyone know of any reason not to push it out for Fedora F13 and
F14?  I know I haven't extensively tested the issues with key
deployment, so do people believe that has been fixed in this version?

Frank

On Wed, 2011-03-09 at 23:15 +1100, Frank Crawford wrote: 
> Dimi,
> 
> I've pulled down the latest CVS and will give it a go for a few days.
> 
> Frank
> 
> On Sun, 2011-03-06 at 12:52 -0500, Dimi Paun wrote: 
> > On Sat, 2011-03-05 at 18:40 +1100, Frank Crawford wrote:
> > > 
> > > Can you update the RPM spec file with the following patch.  Obviously,
> > > the ChangeLog diffs can be ignored, and the Version is TBD.
> > > 
> > > I've also attached the README.Fedora file, which is listed.
> > 
> > OK, I've included the changes, but I've integrated the README.Fedora
> > into the rest of the package, as there is nothing Fedora-specific in it.
> > 
> > I think we should be ready to go.
> > 
> 
> 
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Safekeep-devel mailing list
> Safekeep-devel@...
> https://lists.sourceforge.net/lists/listinfo/safekeep-devel
>

On Thu, 2011-03-03 at 10:29 -0500, Dimi Paun wrote: 
> On Sun, 2011-02-27 at 18:52 +1100, Frank Crawford wrote:
> > How stable do people feel 1.3.1 is?  I've noticed that Fedora is still
> > using 1.2.1, and I'm using a hacked version on my systems, so I'm not
> > 100% sure of 1.3.1.
> 
> It's got a small typo, so we need a new release.
> About your hacked version, any interesting fixes
> that should make it to CVS?
> 
I don't think so, as I'm sure I pushed most of them back a while ago, so
it is more likely that the current 1.3.1 has the same things even if
slightly different coding.

The only item of importance I have noticed is in the spec file, since it
wouldn't build out of the "box" under Fedora.  It needs a BuildRequire
asciidoc, although I will send the full diff shortly.

Frank

On Tue, 2011-03-01 at 22:40 +1100, Frank Crawford wrote:
> So, Dimi, others, should these patches be pushed into the Fedora F15
> release?

I think so -- I'm looking at them right now, so expect them
to land in CVS shortly, or if not, will get a reply on the list.

-- 
Dimi Paun <dimi@...>
Lattica, Inc.

On Mon, 2011-02-28 at 17:29 +0000, Oliver Henshaw wrote:
> * The inverted check for rc in call() that's already been fixed (svn
> r734).
> * do_spawn returning stdout as a single multi-line string instead of
> the array of lines that most of the
> call() users have been adapted to expect
> 
> I've made a fix for the second problem, and followed it with a small
> change to parse_authorized_keys() so
> that it accepts the output from call() without further manipulation.
> I've also modified the new check for a null
> string in parse_authorized_keys() (svn r733) so that it fits in better
> with the changes.

Hi Oliver,
Thanks for the patches! They all made it to SVN (nice patches BTW :)).

> I also noticed a couple of places where safekeep encounters something
> unexpected but carries on. For instance, should safekeep carry on if
> snapshot creation failed? Arguably, making a backup is the most
> important thing but does the administrator really expect to be running
> client scripts and making db dumps on the live system (rather than a
> throwaway snapshot)?

Yes, this is by design. LVN snapshotting is not all that reliable,
and we concluded that having the backup is more important than
having everything go perfect. I still think that it is the right
thing to do, and it goes in line with the philosophy behind safekeep:
  - have reasonable defaults so that the user gets the most
    intuitive/sane behaviour out-of-the-box
  - avoid unnecessary switches and configuration options to avoid
    overwhelming the user.
However, it if you feel very strongly against this, I'd be interested
to hear a counter-argument.

> Another example is the key status/key deploy code - this is not a
> problem in 1.3.1 but the behaviour changed as a side effect of svn
> r733: if safekeep fails to read the authorized keys file due to an
> error in ssh then it will treat it as empty. In which case 'safekeep
> --keys --status' will print a misleading error message and 'safekeep
> --keys --deploy' will attempt to deploy all the keys to the client.
> Maybe this is completely harmless, after all if there was an error
> while reading there will probably be an error while writing. But I
> still wonder if it would be best to bail out at this point. In which
> case, patch 1/3 should be amended.

Yeah, this one we should probably bail out with a clearer message,
as it is a constant source of frustration and confusion.

-- 
Dimi Paun <dimi@...>
Lattica, Inc.