Bug#519567: bacula doesn't use /etc/mailname to set the domain part of outgoing emails

2009-12-26 Thread Kern Sibbald
bacula fails to use /etc/mailname when setting the sender address in
outgoing status emails:

It seems to me that the above suggestion is system dependent. bsmtp is a 
general mail sending program and attempts to use only Unix and Windows well 
defined OS calls.  As such I don't think the above suggestion is appropriate.

The bsmtp program is provided as an optional mail sending program, so you are 
free to use any other program.

Unless someone can show me a system independent way to change this, from the 
upstream perspective, we don't plan any changes.

Best regards,

Kern
Bacula project manager



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#544090: FTBFS on alpha: invalid pointer conversion

2009-12-26 Thread Kern Sibbald
John,

I think the patch attached  to this email (hopfully uploaded properly) will 
fix the Alpha problem.  

I've finally decided it was better to add detection code because various 
machines use long unsigned int and others use int for the ioctl(fd, 
req, ...) req argument.  In addition, at least on my machine, the man pages 
say it is int, but /usr/include/sys/ioctl.h says it is unsigned long 
int ...

Kern
commit 78c64f1757419550411778b75f1018727d8f4e18
Author: Kern Sibbald k...@sibbald.com
Date:   Sat Dec 26 14:50:29 2009 +0100

Attempt to autoconfig ioctl_req_t

diff --git a/bacula/autoconf/config.h.in b/bacula/autoconf/config.h.in
index 632f9c0..754a44d 100644
--- a/bacula/autoconf/config.h.in
+++ b/bacula/autoconf/config.h.in
@@ -452,6 +452,9 @@
declares uintmax_t. */
 #undef HAVE_INTTYPES_H_WITH_UINTMAX
 
+/* Set if ioctl request is unsigned long int */
+#undef HAVE_IOCTL_ULINT_REQUEST
+
 /* Whether to enable IPv6 support */
 #undef HAVE_IPV6
 
@@ -617,6 +620,9 @@
 /* Define to 1 if you have the `snprintf' function. */
 #undef HAVE_SNPRINTF
 
+/* Set if socklen_t exists */
+#undef HAVE_SOCKLEN_T
+
 /* Define to 1 if you have the stdarg.h header file. */
 #undef HAVE_STDARG_H
 
diff --git a/bacula/autoconf/configure.in b/bacula/autoconf/configure.in
index 8a91a31..3147036 100644
--- a/bacula/autoconf/configure.in
+++ b/bacula/autoconf/configure.in
@@ -1859,7 +1859,31 @@ AC_CACHE_CHECK(for socklen_t, ba_cv_header_socklen_t,
)
]
 )
-test $ba_cv_header_socklen_t = yes  AC_DEFINE(HAVE_SOCKLEN_T)
+test $ba_cv_header_socklen_t = yes  AC_DEFINE(HAVE_SOCKLEN_T, 1, [Set if socklen_t exists])
+
+dnl --
+dnl Check for ioctl request type
+dnl --
+AC_CACHE_CHECK(for ioctl_req_t, ba_cv_header_ioctl_req_t,
+   [
+   AC_TRY_COMPILE(
+	  [
+	  #include sys/types.h
+	  #include sys/ioctl.h
+	  ], [
+	  unsigned long int req;
+	  int fd;
+	  ioctl(fd, req);
+	  ], [
+	 ba_cv_header_ioctl_req_t=yes
+	  ], [
+	 ba_cv_header_ioct_req_t_t=no
+	  ]
+   )
+   ]
+)
+test $ba_cv_header_ioctl_req_t = yes  AC_DEFINE(HAVE_IOCTL_ULINT_REQUEST, 1, [Set if ioctl request is unsigned long int])
+
 
 dnl --
 dnl Check for bigendian
diff --git a/bacula/configure b/bacula/configure
index b9c4dce..65d7dd1 100755
--- a/bacula/configure
+++ b/bacula/configure
@@ -32468,11 +32468,83 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
 fi
 { echo $as_me:$LINENO: result: $ba_cv_header_socklen_t 5
 echo ${ECHO_T}$ba_cv_header_socklen_t 6; }
-test $ba_cv_header_socklen_t = yes  cat confdefs.h \_ACEOF
+test $ba_cv_header_socklen_t = yes 
+cat confdefs.h \_ACEOF
 #define HAVE_SOCKLEN_T 1
 _ACEOF
 
 
+{ echo $as_me:$LINENO: checking for ioctl_req_t 5
+echo $ECHO_N checking for ioctl_req_t... $ECHO_C 6; }
+if test ${ba_cv_header_ioctl_req_t+set} = set; then
+  echo $ECHO_N (cached) $ECHO_C 6
+else
+
+   cat conftest.$ac_ext _ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h conftest.$ac_ext
+cat conftest.$ac_ext _ACEOF
+/* end confdefs.h.  */
+
+	  #include sys/types.h
+	  #include sys/ioctl.h
+
+int
+main ()
+{
+
+	  unsigned long int req;
+	  int fd;
+	  ioctl(fd, req);
+
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (ac_try=$ac_compile
+case (($ac_try in
+  *\* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+  *) ac_try_echo=$ac_try;;
+esac
+eval echo \\$as_me:$LINENO: $ac_try_echo\) 5
+  (eval $ac_compile) 2conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 conftest.err
+  rm -f conftest.er1
+  cat conftest.err 5
+  echo $as_me:$LINENO: \$? = $ac_status 5
+  (exit $ac_status); }  {
+	 test -z $ac_c_werror_flag ||
+	 test ! -s conftest.err
+   }  test -s conftest.$ac_objext; then
+
+	 ba_cv_header_ioctl_req_t=yes
+
+else
+  echo $as_me: failed program was: 5
+sed 's/^/| /' conftest.$ac_ext 5
+
+
+	 ba_cv_header_ioct_req_t_t=no
+
+
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+
+
+fi
+{ echo $as_me:$LINENO: result: $ba_cv_header_ioctl_req_t 5
+echo ${ECHO_T}$ba_cv_header_ioctl_req_t 6; }
+test $ba_cv_header_ioctl_req_t = yes 
+cat confdefs.h \_ACEOF
+#define HAVE_IOCTL_ULINT_REQUEST 1
+_ACEOF
+
+
+
 { echo $as_me:$LINENO: checking for bigendian 5
 echo $ECHO_N checking for bigendian... $ECHO_C 6; }
 if test ${ba_cv_bigendian+set} = set; then
diff --git a/bacula/src/baconfig.h b/bacula/src/baconfig.h
index f725630..e93c98c 100644
--- a/bacula/src/baconfig.h
+++ b/bacula/src/baconfig.h
@@ -53,7 +53,11 @@
 #define ETIME ETIMEDOUT
 #endif
 
-#define ioctl_req_t long unsigned int
+#ifdef HAVE_IOCTL_ULINT_REQUEST
+#define ioctl_req_t unsigned long int
+#else
+#define ioctl_req_t int
+#endif
 
 #ifdef PROTOTYPES
 # define __PROTO(p) p
@@ -643,16 +647,9 @@ int  m_msg(const char *file, int line

Bug#544090: FTBFS on alpha: invalid pointer conversion

2009-09-20 Thread Kern Sibbald
Thank you for the most recent information. That and what John wrote made me 
realize that currently distinguish OS types, but in most of the code not 
machine architecture.  In your case, it is apparently a different definition 
that depends on architecture.  

I think this is rather easy to fix, but I need one more confirmation in order 
to do it correctly.  After doing your ./configure on the alpha, would you 
please copy the contents of bacula-source/src/host.h into the bug report. 
If it has 

#define DISTNAME alpha 

then I understand the problem and can create a patch.

Regards,

Kern



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#453940: bacula - default label format does not match documentation

2008-08-03 Thread Kern Sibbald
The documentation was not correct in that it did not take into account the 
fact that volumes may be deleted from the pool.  In fact, what the code 
attempts to do is to create unique volume names without reusing old ones.

I have updated the manual to say:

   If no variable expansion characters are found in the string, the Volume
   name will be formed from the {\bf format} string appended with the
   a unique number that increases.  If you do not remove volumes from the
   pool, this number should be the number of volumes plus one, but this
   is not guaranteed. The unique number will be edited as four
   digits with leading zeros.  For example, with a {\bf Label Format =
   File-}, the first volumes will be named {\bf File-0001}, {\bf
   File-0002}, ...

This will appear in version 2.4.3 and later versions.

A number of changes have been made to the algorithm in between your version 
and the current 2.4.2 version. Note, the unique number is not necessarily the 
MediaId as the MediaId pertains to all pools.

I recommend to close this bug report.

Kern
Bacula Project Manager.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#475139: Inconsistencies should not cause a tape to be marked in error

2008-08-03 Thread Kern Sibbald
Whenever Bacula marks a tape in error, it clearly prints that fact and why in 
the Job Report, so it is not quite accurate to say that it is impossible to 
distinguish between such a case and a case of a /real/ tape error..   Note, 
more recent versions of Bacula permit logging job reports to the database and 
easy access to that info using the GUI bat program. 

Just the same, having an additional state such as Inconsistent is a 
possibility.  I will add it to our TODO list, but have not really decided 
whether or not to do it.  In any case, it is a good deal of work to add a new 
state, including a major update of the database, so even if it is approved, 
don't count on it any time soon.

If you want to ensure that this will become a project, please see:  
www.bacula.org - Feature Requests and follow the procedure outlined there.

Kern
Bacula Project Manager



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#461942: bacula-traymonitor: no manpage for bacula-tray-monitor

2008-08-03 Thread Kern Sibbald
This is possibly a confusion due to the Debian package name being 
bacula-traymonitor, and the Bacula upstream named being bacula-tray-monitor.
The upstream code does have a bacula-tray-monitor manpage that is installed 
during make install

Kern
Bacula Project Manager



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#442185: Debian Bug report #442185 bacula: configuration files in the Debian manner

2008-08-03 Thread Kern Sibbald
In re-reading my response to your requests, I realize that I misunderstood. 
Sorry. What you are requesting is indeed possible.  From the upstream point 
of view, the problem I have is that although, it is a very good way of 
organizing the conf files for larger organizations, it complicates the 
install/configuration for new users, and it does not correspond to the 
current documentation examples.

I will consider adding documentation of this kind of a configuration setup in 
a future version and even possibly adding an alternate default configuration 
file that uses it (on TODO list).  However until that is done, upstream, we 
cannot make this change.  Of course, the John might consider it appropriate 
for the Debian package.

Kern 
Bacula Project Manager



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#445867: Bug #445867 bacula-director-pgsql: crash apparently caused by bad config file

2007-11-05 Thread Kern Sibbald
The crash is not a bug but the only system independent way I have found to 
cause Bacula to dump when there is some error.  In this case, it is a user 
syntax error that seems to be reasonably clear from the error messages.  Once 
the error messages are printed, Bacula induces a Seg Fault.

This bug report should be closed.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#435627: Debian Bug report#435627 bacula-sd: change suggestion for mtx-changer script

2007-11-05 Thread Kern Sibbald
This is corrected in version 2.2.6 which will be released in the next few 
weeks.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#441621: Debian Bug report #441621 All bacula daemons do not release STDOUT/STDERR on daemonization

2007-11-05 Thread Kern Sibbald
Fixed upstream.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#442884: Debian Bug report #442884 Default MySQL table format contains a redundant index

2007-11-05 Thread Kern Sibbald
Fixed upstream in 2.2.6.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#391949: Debian Bug report #391949 Please have text console ignore ConsoleFont, not error out

2007-11-05 Thread Kern Sibbald
I'm not planning to implement this request since ConsoleFont is not a valid 
directive for bconsole.  If you don't want error messages, please use two 
different 
conf files.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#440276: Debian Bug report #440276 bconsole errors when monitoring systems connect to bacula ports

2007-11-05 Thread Kern Sibbald
Those messages are included so that users can detect security violations.  It 
is a daemon message so if you want you can direct it anywhere you want, but I 
have no intention of removing it.  At some time I may move them into a 
security message class so that they can be bit bucketed if you are not 
worried about security.  You should definitely prevent non-bacula or at least 
non-bacula compatible programs from probing its ports.

No change planned in the near future.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#442185: Debian Bug report #442185 bacula: configuration files in the Debian manner

2007-11-05 Thread Kern Sibbald
I don't particularly like programs that include every file in a subdirectory, 
so it is not likely that I'll be implementing this personally, because Bacula 
already has an include method using @.  However, if you really want this, I 
suggest that someone submit a patch.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#446809: Debian Bug report logs - #446809 CVE-2007-5626 unauthorized disclosure of information via clear-text passwords used in command line arguments

2007-11-05 Thread Kern Sibbald
There is no simple solution that works in all cases that I am aware of.  This 
potential security problem (no worse than configuring your conf file with 
world read permission) has been documented for quite a long time in the 
manual.  

We've added additional documentation to the scripts in question warning the 
user of security problems.

No other changes planned.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#386920: bacula-director-common: do not require exim4 or mail-transport-agent pkgs, just suggest instead.

2006-12-06 Thread Kern Sibbald
This appears to be a packaging problem because Bacula by default uses only 
mail or its own bsmtp program for emailing Job reports.  The only thing 
necessary to have Bacula work out of the box is a valid user id and an smtp 
address.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#396913: Schedule WeeklyCycle should be MonthlyCycle

2006-12-06 Thread Kern Sibbald
Technically you are correct if you look from the stand point of Full backups.  
However, it has been called that a long time and no one really seems to be 
confused.  I'll accept a patch for it on the bacula-devel list, but I don't 
think it is worth tweaking the files, and *all* the documentation that would 
need to be changed.

I've taken note of this, but promise nothing.  I recommend closing this bug 
report.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#396921: bacula-director-pgsql depends on sqlite3?!

2006-12-06 Thread Kern Sibbald
I agree, the PostgreSQL version of Bacula should not need SQLite3.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#391966: Control-Z in text console hangs console, not suspends

2006-12-06 Thread Kern Sibbald
The Bacula console does not support ctl-z for suspending it.  This is not a 
bug, but a feature, and implementation of suspending is highly unlikely 
unless some user contributes an appropriate patch.

If you want to submit a patch, please submit it to the bacula-devel list. If 
you wish to submit a feature request, then please see www.bacula.org and 
click on the Feature Request menu item.

I recommend closing this bug report.  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#383357: bacula-director-pgsql: make_catalog_backup has hardcoded path to wrong version of pg_dump

2006-12-06 Thread Kern Sibbald
This is very likely some packaging problem somewhere because the Bacula 
configure script automatically updates the make_catalog_backup script to have 
the correct path to the appropriate database dump program.  The full path is 
not put on an environment variable, so it may seem that it is hard coded, but 
that is not the case.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#371890: lower priority for mtx

2006-12-06 Thread Kern Sibbald
Bacula by default installs a script that uses mtx.  The problem for a packager 
is that there is no easy way to know if the user really has an autochanger or 
not.  Most packages including all the rpms require mtx by default to avoid 
any problem the user might have later.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#391492: Fails to init supplemental groups

2006-12-06 Thread Kern Sibbald
There are two possible issues here.  One is a packaging issue. If you package 
Bacula to run as non-root, which can be done for both the Director and the 
Storage daemon, then the packager must ensure that any new userid or group is 
created when installing the package.  For example, often the Director runs as 
bacula:bacula, and the SD as bacula:disk.

The second issue here is Bacula itself. It must be started as root, then drops 
to the user/group specified on the command line.  Due to the excessively 
complex Unix API for dropping to a different group, the code in version 
1.38.11 did not get it completely correct.  This is fixed in 1.39.x. The 
result is that it is often easier to run the Storage daemon in group root 
otherwise you can run into permission problems attempting to access tape 
devices.  In any case, if Bacula needs access to certificate files, then you 
*must* either run the appropriate component as root or modify the permissions 
on the certificate directories and files so that Bacula can access them.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#388027: Auto reconnect to DB when connection dropped?

2006-12-06 Thread Kern Sibbald
It seems to me that there are a few issues here:

1. If you shutdown or upgrade a database while Bacula is running a Job, then 
Bacula will fail.  The solution is: don't do that.  Bacula has no explicit 
code to reconnect to a database after the database is successfully opened, 
and we don't plan to add any such code as it would render the data less 
secure.

2. It is possible that the network (if that is what you setup) connection 
between Bacula and the database server could be broken.  In that case, since 
it is the database's client libraries that established the connection, it is 
their responsibility to manage the connection and reconnect if it is 
possible.  If the database API supplies a call or flag that requests the 
client libraries to reconnect, we will (and in the case of MySQL where this 
exists do) use the API/flag.  However, this still leaves it to the client 
libraries to manage the interface.

3. With most databases, you can set them up to use sockets rather than TCP/IP 
providing the database and the Director run on the same machine.  This might 
reduce any disconnects that would occur via TCP/IP.

4. Bacula has a connection to the database open only when it is actually 
running a job, so if this error occurs, and the client library cannot 
reconnect by itself, Bacula will take the conservative point of view and fail 
the job.

5. There was one case of MySQL recently releasing a new version where they 
changed the API/flag that requests reconnect.  This unfortunately resulted in 
a few dropped connections until we modified the Bacula code to correspond to 
the new MySQL coding.  This should no longer be an issue if you are running 
any version of 1.38.11.

6. Some of the test results reported indicate that there may be a bug with 
specific versions of MySQL.

The manual has pointers to how to resolve these disconnect issues for MySQL 
where they seem more common (I have never had one ...).

Providing there are no Debian specific modifications to the cats directory 
source code, I recommend closing this bug report as there is no planned 
change to Bacula and no known bug in version 1.38.11 or greater.  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#371883: bacula-director-pgsql: upgrade from 1.36 fails

2006-12-06 Thread Kern Sibbald
I haven't read all the details of this bug report, but it seems to me that the 
basic problem is that normally in major Bacula upgrade, e.g. 1.36.x - 1.38, 
Bacula has new table formats.  This has nothing to do with upgrading the SQL 
engine, but is due to the fact that the Bacula SQL table format has changed.

Updating the table require running a special update script that is supplied 
with the new release of Bacula.  If you do not run the script, you will get 
an error such as:

bacula-dir:  Fatal error: Version error for database bacula. Wanted 9, got 8

as reported in this bug.  This indicates that Bacula was upgraded, but 
Bacula's tables were not upgraded.

The upgrade can either be done manually by invoking the appropriate update 
script, or it can be automatically done when installing the new package (the 
rpms do an automatic update for the user).

The procedure (what to do, where to find the script) is documented in the 
ReleaseNotes file.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#376679: bacula: Upgrade to 1.38.11 broke autochanger config.

2006-12-05 Thread Kern Sibbald
I've taken another look at this bug report, and am convinced that my comment 
of 9 Oct remains valid. The user did not upgrade his Storage daemon 
configuration to include the new Autochanger resource, and thus Bacula fails 
to function correctly.

I recommend that this bug be closed and marked as not a bug or user 
configuration error.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#379605: in file-selection mode bacula-console-wx issues .dir instead of dir

2006-10-09 Thread Kern Sibbald
wx-console had a number of bugs which were fixed, and unfortunately some of 
those required making non-downward compatible changes, which is inevitable.  
The .dir is in fact correct, but for it to work correctly, you must use the 
same Director version (1.38.x) and not an older version.

You will be better off running everything on version 1.38.11.

I recommend closing this as a not a bug since we never can guarantee proper 
functioning of all components between different major versions (in general 
all 1.38.x components are compatible, but not 1.36.x to 1.38.x).

Regards,

Kern


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#387838: bacula-director-mysql: segfault

2006-10-09 Thread Kern Sibbald
The Bacula manual recommends that you test your conf files with ./bacula-xx 
-t ...

This will clearly indicate what is wrong and where (in 99.9% of the cases).

If you run Bacula as a daemon, due to the flexibility in Bacula error message 
handling, it is very hard to get the user's attention, so Bacula attempts to 
produce a traceback, which for some reason in your case seems to be 
configured incorrectly.  This also would have indicated what the problem is.

Finally, yes Bacula does use SEGFAULT to generate tracebacks when it aborts, 
because it is the only portable way of doing so (the Unix abort() is not 
portable).

This is not a bug and should be closed.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#376679: bacula: Upgrade to 1.38.11 broke autochanger config.

2006-10-09 Thread Kern Sibbald
It is hard to be sure, but most likely you did not upgrade your bacula-sd.conf 
file as is required for autochangers in switching from 1.38.11.  As very 
clearly indicated in the Release Notes and the manual, Bacula 1.38.11 
requires a new Autochanger resource in order to function correctly with 
Autochangers.

If you didn't add an Autochanger resource, that is most surely your problem.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#380220: bacula-director-mysql: Start fails with *** glibc detected *** free(): invalid pointer: 0x080ea648

2006-10-09 Thread Kern Sibbald
This kind of problem is almost always due to the fact that Bacula was linked 
against one version of mysql (e.g. 4.x) and you are using a different version 
(e.g. 5.x).

I'm not a Debian user, so I cannot give the best advice, but in general, 
either check what was linked in the original package you loaded, or rebuild 
Bacula on your current system linking against your current mysql libraries.

Another similar possiblity, but probably pretty unlikely on Debian, is that 
you have several different mysqls loaded on your system, possibly in 
different locations, as often happens when upgrading from 4.x to 5.x.  Bacula 
may be picking up or using header files from an old installation but using 
the shared objects from a newer installation.

Regards,

Kern


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#387838: bacula-director-mysql: segfault

2006-10-09 Thread Kern Sibbald
On Monday 09 October 2006 18:15, John Goerzen wrote:
 On Mon, Oct 09, 2006 at 05:57:00PM +0200, Kern Sibbald wrote:
  Finally, yes Bacula does use SEGFAULT to generate tracebacks when it 
aborts, 
  because it is the only portable way of doing so (the Unix abort() is not 
  portable).
  
  This is not a bug and should be closed.
 
 Thank you for the clear explanation.  I have closed the report.
 
 Just to clarify for the submitter: Kern is saying that this is not a bug
 unless you also get segfaults in the test mode.  If you try it and do
 get segfaults there, let me know, and we'll pursue it further.

Yes, thanks for the clarification -- you are correct.  

The Bacula conf file scanner has never been what I would call super good, 
but it should not seg fault on a valid conf file or it is a bug.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#383332: bacula: backup is slow

2006-10-09 Thread Kern Sibbald
From the statistics you show, the backup does not appear slow to me.  The 
reason you might think it is slow is because you are comparing apples and 
oranges.  

On the one hand, you measure the time to to a non-compressed tar on a local 
machine sending the output down an extremely hi-speed bit bucket.

On the other hand, you measure the time of Bacula using compression sending 
real data to another process via TCP/IP (even though it might be on the same 
machine).

To do a better comparison, you could run tar including the z option so that it 
does compression.  In addition, you should send the output of tar across the 
network and write it to either a file or a tape (whatever Bacula is using).

At that point, providing you are always doing Full backups on Bacula (and not 
Incremental of Differential), you will probably find that the total Bacula 
time is not terribly greater than tar.  That said, Bacula will amost always 
be slower than tar because it does a whole lot more -- in addition to 
checksuming all the data Bacula writes to the Volume, which I am not sure tar 
does, Bacula also interfaces to a database and stores a lot of information 
about the job.

If you want to do additional performance testing you can look at 
bacula-source/src/version.h.  There are various configuration parameters 
that you can turn on/off and then re-build Bacula and measure the performance 
of particular parts.  Performance testing is a highly evolved science as well 
as an art, and it is not always easy.   For example, if you are going to do 
any timing experiments as you did, you *must* on Unix systems re-run the test 
at least 10 times, throw out the first two timings, then take an average of 
the remaining 8.  If you don't do this, your timing tests will have no 
meaning due to the memory cacheing that Unix does.

Best regards,

Kern



Bug#374427: bacula-director-pgsql: Does not work with ident sameuser

2006-06-29 Thread Kern Sibbald
Hello,

This is indeed a problem, and not one that I consider an upstream bug. The 
basic problem is that Bacula cecks if it can open the database prior to 
becoming a daemon and thus prior to dropping root privilege.  It is the only 
way, it can properly print the message and exit.

When it attempts to connect to the database the first time, Bacula will be 
running as root, but it will use the correct database name and the correct 
user id and password.  If you have set the Bacula database to *require* that 
the user id specified corresponds to the Unix user id that is running, then 
you will need to configure the Bacula database to either accept root or 
bacula logins.  

Otherwise, a simpler method is to allow any user to log into the bacula 
database providing he has the userid and password for the database.  This 
makes more sense because there are a lot of applications such as bacula-web 
that need to be able to read/write the Bacula database.

I don't consider this an upstream bug, but rather a problem of administration 
of database access to be resolved at installation time.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#360530: bacula-common: tcpwrapper config not documented

2006-06-29 Thread Kern Sibbald
Hello,

Yes, the tcpwrappers name that the daemons look for in libwrap is not the 
daemon name.  This is because there can be multiple simultaneous Bacula 
daemons running on the same machine.  They simply use different .conf files.

The fact that you must use the daemon Name as defined in the .conf file has 
long been documented in several places in the manual (the --with-tcpwrapper 
section and the Security chapter).  The security chapter goes into detail on 
how to setup and test tcpwrappers.

Since the manual is some 500 pages, the information is not always easy to 
find, but it is now indexed.  I don't think it appropriate to add this level 
of detail to the man pages.

I recommend closing this bug report.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#342111: bacula-sd: Bad autochanger loaded drive 0 command: ERR=Child exited with code 1

2006-06-29 Thread Kern Sibbald
Hello,

This kind of problem happens frequently if the SD is not being run as root and 
there are not sufficient permissions for the SD to access the script or the 
directory in which the script resides.   Make sure that the user (don't count 
on the group as changing the group on the command line does not function 
correctly) that the SD is running under can actually access the directory 
and the script.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#367643: man page for dbcheck is wrong

2006-06-29 Thread Kern Sibbald
Hello,

I have recently integrated all the man pages into the upstream Bacula source 
code, and I noticed this problem and corrected it.  I've also added more 
substance to some of the man pages and hope to get through them all in the 
next few months.

This correction will appear upstream in version 1.40.0


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#363273: bacula should be able to schedule commands in advance

2006-06-29 Thread Kern Sibbald
Hello,

Bacula is fully multiple threaded, which means you can issue Bacula commands 
at any time.  Each command must complete (e.g. database listing, ...) prior 
to issuing the next command, and in some cases, if you attempt to use a tape 
drive to label a tape and the drive is busy, the command will fail (i.e. 
return an error).

If you want such an item as you are suggestion (and I don't really think it is 
needed), please submit a Feature Request to the bacula-users email list.  
Note, the precise details of a Feature Request are described on the 
www.bacula.org web site.

I recommend closing this bug.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#369541: bacula: split parts from bacula-dir.conf

2006-06-29 Thread Kern Sibbald
Hello,

I think you have some good ideas here that a number of users would want. The 
best way to get something like this implemented is to do it yourself (after 
discussing it on the bacula-users list), then submit a patch against the 
current CVS to the bacula-devel list.

If you wish to submit this as a Feature Request, the best procedure is to 
follow the Feature request procedures as outlined on the www.bacula.org web 
site then submit it to the bacula-users list and either defend your ideas or 
wrap in their suggestions. When there seems to be a consensus (more or less) 
I will accept the Feature request and add it to our projects list.

I recommend closing this bug report and submitting a Bacula feature request.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#352287: /usr/sbin/btape: btape seg faults when handling a device error

2006-06-29 Thread Kern Sibbald
Hello,

The programs such as btape that need a drive to work ABORT when it cannot 
find/open the drive.  The only portable way of ensuring the program ABORTs is 
to generate a seg fault, so the behavior you have noted is a bit unusual but 
normal.

I recommend closing this bug report.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#252305: bacula-console-gnome: Looks in wrong place for configuration file Date:

2006-06-29 Thread Kern Sibbald
Hello,

No configuration paths of any kind are programmed into the binaries.  Thus 
they look where you have specified on the command line for their 
configuration file.  If you don't specify one, they look in the current 
directory, and then die if one is not found.

If you want a simple one line command that runs the console, simply create a 
shell script that adds the proper path to the configuration file, or create 
an appropriate icon on your desktop.

No change upstream is necessary.

I recommend closing this bug report.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#314301: bacula-doc missing section on FileSet

2006-06-29 Thread Kern Sibbald
Hello, 

There was indeed a problem in producing the document because under certain 
circumstances LaTeX does not permit includes within includes.  This caused 
the missing section.

This has been *long* ago corrected.   If someone would like to correct this, 
edit docs/manual/dirdconf.tex and change the line that reads:

\include{fileset}

to

\input{fileset}

then rebuild the document.

I recommend closing the bug.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#367424: [Bacula-devel] FW: Bug#367424: bacula-sd: Debian build with debug symbols

2006-05-24 Thread Kern Sibbald
Hello,

The debug listing below confirms that the problem is coming from the
foreach... loop that is examining the Devices attached to the Autochanger.
It is impossible for the pointer to be NULL, which is apparently what is
happening, which indicates to me a g++ bug.

Could you tell me what version of g++ you are using?

Possible solutions:

1. Verify that #define HAVE_GCC 1 is set in src/config.h
2. add -O0 (- oh zero) or rather replace the -02 compile option with -O0.
3. add -fno-strict-aliasing to the compile options, in which case the -O2
should be able to be used.

Concerning the impact of -O0. Well, obviously if -fno-strict-aliasing -O2
works, it will be more efficient.  However, between having the SD crash
and running with no optimization, I personally would quickly choose -O0
:-)

All this is quite frustrating to me, because in more than 5 years, I have
never seen a compiler problem (bug), and in the last 6 months, there have
been a rash of these kinds of strict aliasing problems that arise
because of optimization or over optimization.  Every case I have seen has
been with a 4.x compiler ...

 - Forwarded message from Marcus Meyer [EMAIL PROTECTED] -

 From: Marcus Meyer [EMAIL PROTECTED]
 Date: Tue, 23 May 2006 15:57:27 +0200
 Reply-To: Marcus Meyer [EMAIL PROTECTED], [EMAIL PROTECTED]
 To: Debian Bug Tracking System [EMAIL PROTECTED]
 Subject: Bug#367424: bacula-sd: Debian build with debug symbols

 Package: bacula-sd
 Version: 1.38.9-9
 Followup-For: Bug #367424

 Hi!

 Now I've compiled the debian source with debug symbols.


 Here is, wat i did:

 apt-get source bacula
 cd bacula-1.38.9/
 DEB_BUILD_OPTIONS=noopt nostrip dpkg-buildpackage -rfakeroot -us -uc -B


 After the build I copy the bacula-sd from
 bacula-1.38.9/debian/tmp-build-mysql/src/stored/bacula-sd to
 /usr/sbin/bacula-sd then I started the daemon with /etc/init.d/bacula-sd
 start.



 The error was:

 Starting Bacula Storage daemon: 23-Mai 15:45 bacula-sd: Fatal Error
 because: Bacula interrupted by signal 11: Segmentation violation
 Kaboom! bacula-sd, bacula-sd got signal 11. Attempting traceback.
 Kaboom! exepath=/usr/sbin/
 Calling: /usr/sbin/btraceback /usr/sbin/bacula-sd 6989
 Traceback complete, attempting cleanup ...


 And the traceback:

 Using host libthread_db library /lib/tls/libthread_db.so.1.
 [Thread debugging using libthread_db enabled]
 [New Thread -1213532480 (LWP 6989)]
 0xb7ea71fe in __waitpid_nocancel () from /lib/tls/libpthread.so.0
 $1 = bacula-sd, '\0' repeats 20 times
 $2 = 0x80b4870 bacula-sd
 $3 = 0x80b4898 /usr/sbin/bacula-sd
 $4 = MySQL
 $5 = 0x80a57f8 1.38.9 (02 May 2006)
 $6 = 0x80a270d i486-pc-linux-gnu
 $7 = 0x80a2706 debian
 $8 = 0x80a26f5 testing/unstable
 #0  0xb7ea71fe in __waitpid_nocancel () from /lib/tls/libpthread.so.0
 #1  0x080900c3 in signal_handler (sig=11) at signal.c:159
 #2  signal handler called
 #3  0x0804e70a in init_autochangers () at autochanger.c:48
 #4  0x0804c8b0 in main (argc=value optimized out, argv=value optimized
 out) at stored.c:401

 Thread 1 (Thread -1213532480 (LWP 6989)):
 #0  0xb7ea71fe in __waitpid_nocancel () from /lib/tls/libpthread.so.0
 #1  0x080900c3 in signal_handler (sig=11) at signal.c:159
 #2  signal handler called
 #3  0x0804e70a in init_autochangers () at autochanger.c:48
 #4  0x0804c8b0 in main (argc=value optimized out, argv=value optimized
 out) at stored.c:401
 #0  0xb7ea71fe in __waitpid_nocancel () from /lib/tls/libpthread.so.0
 #0  0xb7ea71fe in __waitpid_nocancel () from /lib/tls/libpthread.so.0
 No symbol table info available.
 #1  0x080900c3 in signal_handler (sig=11) at signal.c:159
 159  waitpid(pid, NULL, 0);   /* wait for child to produce
 dump */
 Current language:  auto; currently c++
 be = {SMARTALLOC = {No data fields}, buf_ = 0x99816a54 Address
 0x99816a54 out of bounds, berrno_ = 65522866}
 sigdefault = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0},
 sa_mask = {__val = {2147483647, 4294967294, 4294967295 repeats 30
 times}},
   sa_flags = 0, sa_restorer = 0xc5a58668}
 argv = {0x0, 0x0, 0x0, 0x0}
 pid_buf = 6989, '\0' repeats 15 times
 buf =
 /tmp/\000Qi\202\234·Óð\016-M^p\203\227¬ÂÙñ\n$?[x\226µÕæø\v\0374Jay\222¬Çã\000\036=]n\200\223§?Òé\001\0324Ok\210?Ååö\b\033/DZq\211¢?×ó\020.Mm~\220£·Ìâù\021*D_{\230¶Õõ\006\030+?
 pid = 6990
 btpath = /usr/sbin/btraceback, '\0' repeats 379 times
 #2  signal handler called
 No symbol table info available.
 #3  0x0804e70a in init_autochangers () at autochanger.c:48
 48   if (!device-changer_command  changer-changer_command)
 {
 device = (DEVRES *) 0x0
 OK = true
 changer = (AUTOCHANGER *) 0x80b6938
 #4  0x0804c8b0 in main (argc=value optimized out, argv=value optimized
 out) at stored.c:401
 401OK = init_autochangers();
 ch = value optimized out
 no_signals = 0
 test_config = 0
 thid = 0
 uid = 0xbfdf9f0e bacula
 gid = 0xbfdf9f18 tape
 #0  0x in ?? ()
 No symbol table info available.
 #0  0x in ?? ()
 No symbol table info 

Bug#296648: [Apcupsd-users] debian bug request

2005-03-01 Thread Kern Sibbald
On Friday 25 February 2005 11:01, Samuele Giovanni Tonon wrote:
 hi,
 A bug request was filled against debian:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=296648

 i think that this is most a feature than a bug, however, what the user
 pointed out (that MAX_SLAVE is hardcoded instead of staying in conf
 file) is quite interesting.

Yes, a limit of 20 slaves is complied into apcupsd. While this is not the way 
I would have coded it, one must remember that such practices were prevalent 
at the time apcupsd was written and are quite common today.  

A limit of 20 is actually reasonable since having more handling more than 20 
slaves increases significantly the possibility that the master does not have 
the time to notify all the slaves before shutdown, particularly if there are 
network problems due to a router/hub being down due to a power failure.

The recommended alternative is to use the NIS networking rather than the 
Master/Slave networking. This is documented in the manual. There is no limit 
to the number of NIS slaves nor the same problem of notification.

If the user would like to submit a patch, and it is written in the current 
apcupsd style, the apcupsd project will be happy to accept it. Otherwise, 
this is not an item high on our priority list.

I recommend closing the bug report.

Best regards, Kern


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#295823: [Bacula-users] Bug#295823: bacula-director-mysql: Unknown table 'delCandidates'

2005-02-18 Thread Kern Sibbald
Hello,

Thanks for the bug report. In the future, it would be helpful to send
them to [EMAIL PROTECTED] instead of the bacula-users
list.

This is actually a bug in MySQL, or at least the version you are using
since, unless I am mistaken, the SQL standard requires table names to be
case independent. 

Just the same, I have corrected the Bacula code in both the 1.36.2
stream (to be released shortly) and the 1.37 development stream.

Thanks for the patch.

On Fri, 2005-02-18 at 12:29 +0100, Lupe Christoph wrote:
 Package: bacula-director-mysql
 Version: 1.36.1-1
 Severity: normal
 Tags: patch
 
 Subject: bacula-director-mysql: Unknown table 'delCandidates'
 Package: bacula-director-mysql
 Version: 1.36.1-1
 Severity: normal
 
 A restore job just printed
 
 18-Feb 11:51 antalya-dir: Begin pruning Jobs.
 18-Feb 11:51 antalya-dir: Query failed: SELECT DISTINCT DelCandidates.JobId 
 FROM Job,DelCandidates WHERE (Job.JobTdate1098355884 AND 
 delCandidates.JobStatus!='T') OR (Job.JobTDate1098355884 AND Job.ClientId=1 
 AND Job.Type='R'): ERR=Unknown table 'delCandidates' in where clause
 18-Feb 11:51 antalya-dir: Pruned 0 Jobs for client antalya-fd from catalog.
 18-Feb 11:51 antalya-dir: Begin pruning Files.
 18-Feb 11:51 antalya-dir: No Files found to prune.
 18-Feb 11:51 antalya-dir: End auto prune.
 
 There is a typo in src/dird/sql_cmds.c (still there in CVS, file version
 1.48). Patch attached.
 
 -- System Information:
 Debian Release: 3.1
   APT prefers testing
   APT policy: (990, 'testing'), (100, 'unstable')
 Architecture: i386 (i686)
 Kernel: Linux 2.4.27-lpc.7.k7
 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
 
 Versions of packages bacula-director-mysql depends on:
 ii  bacula-common   1.36.1-1 Network backup, recovery and 
 verif
 ii  bacula-director-common  1.36.1-1 Network backup, recovery and 
 verif
 ii  debconf 1.4.30.11Debian configuration management 
 sy
 ii  libc6   2.3.2.ds1-20 GNU C Library: Shared libraries 
 an
 ii  libgcc1 1:3.4.3-6GCC support library
 ii  libmysqlclient124.0.23-4 mysql database client library
 ii  libssl0.9.7 0.9.7e-2 SSL shared libraries
 ii  libstdc++5  1:3.3.5-8The GNU Standard C++ Library v3
 ii  libwrap07.6.dbs-6Wietse Venema's TCP wrappers 
 libra
 ii  mysql-client4.0.23-4 mysql database client binaries
 ii  zlib1g  1:1.2.2-3compression library - runtime
 
 -- debconf information:
 * bacula-director-mysql/remove_catalog_on_purge: false
 * bacula-director-mysql/db_host: localhost
 * bacula-director-mysql/create_tables: true
 * bacula-director-mysql/mysql_root_username: lupe
 * bacula-director-mysql/db_user: bacula
 
 -- System Information:
 Debian Release: 3.1
   APT prefers testing
   APT policy: (990, 'testing'), (100, 'unstable')
 Architecture: i386 (i686)
 Kernel: Linux 2.4.27-lpc.7.k7
 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
 
 Versions of packages bacula-director-mysql depends on:
 ii  bacula-common   1.36.1-1 Network backup, recovery and 
 verif
 ii  bacula-director-common  1.36.1-1 Network backup, recovery and 
 verif
 ii  debconf 1.4.30.11Debian configuration management 
 sy
 ii  libc6   2.3.2.ds1-20 GNU C Library: Shared libraries 
 an
 ii  libgcc1 1:3.4.3-6GCC support library
 ii  libmysqlclient124.0.23-4 mysql database client library
 ii  libssl0.9.7 0.9.7e-2 SSL shared libraries
 ii  libstdc++5  1:3.3.5-8The GNU Standard C++ Library v3
 ii  libwrap07.6.dbs-6Wietse Venema's TCP wrappers 
 libra
 ii  mysql-client4.0.23-4 mysql database client binaries
 ii  zlib1g  1:1.2.2-3compression library - runtime
 
 -- debconf information:
 * bacula-director-mysql/remove_catalog_on_purge: false
 * bacula-director-mysql/db_host: localhost
 * bacula-director-mysql/create_tables: true
 * bacula-director-mysql/mysql_root_username: lupe
 * bacula-director-mysql/db_user: bacula
-- 
Best regards, Kern



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#274752: [Apcupsd-users] Re: apcupsd debian bugs and feature requested

2005-02-14 Thread Kern Sibbald
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=285316
Docbook is no longer used for apcupsd. The directory will remain for a
few releases for historical reference. The manual has now been converted
to texinfo format, so it is found in apcupsd/doc/texi. To build it
simply cd to that directory and type make. If you have the texinfo
tools loaded (including TeX), you will get the manual -- see the
Makefile for details. Note, TeX generates a good number of warning
messages, which you can ignore.

Please note that I am very unsatisfied with the texinfo manual, so will
be converting it to LaTeX in the next several months.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#87728: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87728

2005-02-14 Thread Kern Sibbald
The problem here is that the only person who understands the po stuff
left the project. Since you do not seem to be too sure about the problem
(I think it's not necessary to make this distinction), and I don't
know anything about this stuff the best tactic is to do nothing.

Now, if someone understands how gettext works and can take the time to
explain it to me ([EMAIL PROTECTED]), I'll be happy to try to clean up
these annoying points.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#286612: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286612

2005-02-14 Thread Kern Sibbald
I may be missing something, but I don't see the need for this feature.
You can do what you want today by simply modifying apccontrol to do your
action script rather than complicating apcupsd.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#294256: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294256

2005-02-14 Thread Kern Sibbald
If the submitter of this bug report would like us to include his idea in
the apcupsd release, we will be glad to do so. For that to happen, we
will need a small document describing it and how to use it as well as
the full script. I'm not sure we will integrate it into the mainstream
code (I reserve judgment on this ...), but at a minimum we can include
the script and the document in our examples directory.

Send the full script and document to [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#286613: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286613

2005-02-14 Thread Kern Sibbald
This is a good idea. I've added it to the things to do for the next or
subsequent release.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#287739: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287739

2005-02-14 Thread Kern Sibbald
I believe that we have given you the tools necessary to do what you want
by using apcupsd.conf directives and event scripts. This is discussed in
the release notes in a recent release -- if not the current release then
look in doc/techlogs.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]