ebl Allow binaries in an other location

[bacula/bacula] / bacula / projects

diff --git a/bacula/projects b/bacula/projects
index 1611914f27fe86c61e734bdf8b0aa172b283c164..b41e63e3151f1759ec4ee0fcd8390a66b23eee76 100644 (file)
--- a/bacula/projects
+++ b/bacula/projects
@@ -855,7 +855,71 @@ Item 25:  Archival (removal) of User Files to Tape
 
 
 
-========= Added since the last vote =================
+========= New Items since the last vote =================
+
+Item 26: Add a new directive to bacula-dir.conf which permits inclusion of all subconfiguration files in a given directory
+Date:   18 October 2008
+Origin: Database, Lda. Maputo, Mozambique
+Contact:Cameron Smith / cameron.ord@database.co.mz 
+Status: New request
+
+What: A directive something like "IncludeConf = /etc/bacula/subconfs" Every
+      time Bacula Director restarts or reloads, it will walk the given
+      directory (non-recursively) and include the contents of any files
+      therein, as though they were appended to bacula-dir.conf
+
+Why: Permits simplified and safer configuration for larger installations with
+      many client PCs.  Currently, through judicious use of JobDefs and
+      similar directives, it is possible to reduce the client-specific part of
+      a configuration to a minimum.  The client-specific directives can be
+      prepared according to a standard template and dropped into a known
+      directory.  However it is still necessary to add a line to the "master"
+      (bacula-dir.conf) referencing each new file.  This exposes the master to
+      unnecessary risk of accidental mistakes and makes automation of adding
+      new client-confs, more difficult (it is easier to automate dropping a
+      file into a dir, than rewriting an existing file).  Ken has previously
+      made a convincing argument for NOT including Bacula's core configuration
+      in an RDBMS, but I believe that the present request is a reasonable
+      extension to the current "flat-file-based" configuration philosophy.
+ 
+Notes: There is NO need for any special syntax to these files.  They should
+       contain standard directives which are simply "inlined" to the parent
+       file as already happens when you explicitly reference an external file.
+
+ Item n: List inChanger flag when doing restore.
+ Origin: Jesper Krogh<jesper@krogh.cc>
+   Date:   17 oct. 2008
+ Status:
+
+   What: When doing a restore the restore selection dialog ends by telling stuff 
+      like this:
+  The job will require the following
+   Volume(s)                 Storage(s)                SD Device(s)
+   ===========================================================================
+    000741L3                  LTO-4                     LTO3 
+    000866L3                  LTO-4                     LTO3 
+    000765L3                  LTO-4                     LTO3 
+    000764L3                  LTO-4                     LTO3 
+    000756L3                  LTO-4                     LTO3 
+    001759L3                  LTO-4                     LTO3 
+    001763L3                  LTO-4                     LTO3 
+    001762L3                  LTO-4                     LTO3 
+    001767L3                  LTO-4                     LTO3 
+
+   When having an autochanger, it would be really nice with an inChanger 
+   column so the operator knew if this restore job would stop waiting for 
+   operator intervention. This is done just by selecting the inChanger flag 
+   from the catalog and printing it in a seperate column.
+
+
+   Why:    This would help getting large restores through minimizing the 
+      time spent waiting for operator to drop by and change tapes in the library.
+
+  Notes: [Kern] I think it would also be good to have the Slot as well,
+      or some indication that Bacula thinks the volume is in the autochanger
+      because it depends on both the InChanger flag and the Slot being
+      valid.
+
 
 Item 1:   Implement an interface between Bacula and Amazon's S3.
   Date:   25 August 2008
@@ -1107,6 +1171,22 @@ Item  n:  make changing "spooldata=yes|no" possible for
 
   Notes:  ./.
 
+Item 1:   Implement an option to modify the last written date for volumes
+Date:     16 September 2008
+Origin:   Franck (xeoslaenor at gmail dot com)
+Status:   Proposing
+What:     The ability to modify the last written date for a volume
+Why:      It's sometime necessary to jump a volume when you have a pool of volume
+          which recycles the oldest volume at each backup.
+          Sometime, it needs to cancel a set of backup (one day
+          backup, completely) and we want to avoid that bacula
+          choose the volume (which is not written at all) from
+          the cancelled backup (It has to jump to next volume).
+          in this case, we just need to update the written date
+          manually to avoir the "oldest volume" purge.
+Notes:    An option can be add to "update volume" command (like 'written date'
+          choice for example)
+
 ============= Empty Feature Request form ===========
 Item  n:  One line summary ...
   Date:   Date submitted 
@@ -1428,4 +1508,3 @@ Item h10: Clustered file-daemons
    Notes: Kern: I don't understand the request enough to be able to
           implement it. A lot more design detail should be presented
           before voting on this project.
-