Feature #1049

Create interface for navigating filebucket

Added by Aaron Dummer over 5 years ago. Updated about 4 years ago.

Status:AcceptedStart date:
Priority:LowDue date:
Assignee:-% Done:

0%

Category:executables
Target version:-
Affected Puppet version:0.24.8 Branch:
Keywords:

Description

Currently if you want to restore a backup from a filebucket, you need to know the md5sum of the orignal file. If you do not have this information in your logs, you have to search the filebucket tree manually and hope to find a match.

Luke’s response is here: http://mail.madstop.com/pipermail/puppet-users/2008-February/006235.html

I request that this restoration functionality be available from a node. Something like:

filebucket --server mypuppetserver --node mynode --file /etc/passwd /home/johnp/restored_passwd

would return

r1  8192b Dec 03 07:14
r2  9012b Jan 15 08:19
r3  9489b Jan 28 10:20
Select file to restore [1-3]:

After making a selection, the file would be copied to /home/johnp/restored_passwd. The command would be extremely useful in cases of emergency.

Also, I think some sort of index database needs to be made of all filebucketed files to 1) make the suggested command much easier to implement, and 2) enable transactional functionality. A related feature would be a ‘total system rollback’, enabling you to specify a timestamp and all files would be returned to their state at said timestamp.

Related issues

Related to Puppet - Feature #1489: More security with remote filebuckets Accepted 08/03/2008

History

#1 Updated by Luke Kanies over 5 years ago

I agree that filebuckets aren’t much use in their current implementation unless you know the checksum of the file you’re looking for, but it’s pretty straightforward to make sure you know that information. For one, don’t lose your logs, or at least use central reporting.

At some point the logs will get rolled off, but by then it’s unlikely you’d be looking to restore anything that old.

And logging is always enabled by default, so it takes work to lose these checksums.

I can see your point about wanting this information, but it would be a very different service — it would need to keep track of what host stored the given checksum for what file, and then be able to look the file up by any of that information.

I’ll think about it, but as before, I’m unlikely to implement this.

#2 Updated by Aaron Dummer over 5 years ago

Luke, based on your comments, I don’t see how filebuckets are very useful without a way to easily retrive data from them.

To find the checksum of a file you wish to restore, you need to look in a logfile. If logging wasn’t enabled, or the logfile has been rotated/deleted, there is literally no way of determining the checksum.

Assuming for the sake of discussion that you don’t know the checksum, you need to hunt-and-peck your way through the backup tree, hoping to find the file you need.

Maybe this request needs to be ‘refactored’ and implemented in some other fashion, but there definitely needs to be a better way to restore backups than what exists currently.

#3 Updated by Luke Kanies over 5 years ago

If any kind of rollback were ever implemented, it would definitely be by checksum, not by file path.

The whole point of the filebucket is that it’s a way to store and look up files by checksum, not by path. The interface to filebuckets will change as we move to REST, and it will make even less sense to have an interface that looks files up by path rather than by checksum, based on the current design.

If someone else implements this, I’d accept the patch, but I’m certainly not planning on doing the work.

#4 Updated by Redmine Admin about 5 years ago

  • Status changed from 1 to Accepted

#5 Updated by James Turnbull about 4 years ago

  • Assignee deleted (Puppet Community)
  • Affected Puppet version set to 0.24.8

Also available in: Atom PDF