Hans Manz schrieb:
Dimitri Puzin schrieb:
Of course you could do all that with SQL, but LDAP is
optimized for just this purpose. I could elaborate this point, if you wish.
Please.
If you don't mind I would postpone this. *ehem* :-) Basically it boils
down to simplicity and performance
On Thursday 22 March 2007 13:31, Dimitri Puzin wrote:
...
By the way, bacula is a really neat piece of software -- despite of not
yet beeing complete -- and I've had been glad if bacula at this stage
existed seven years ago.
Yeah, long time ago I've switched from commercial products to
Dimitri Puzin schrieb:
IMHO is the configuration not as much distributed as LDAP was designed
for/to pull real benefit from it. The most important configuration is
the one from bacula-dir and there is usually only one instance of it
running on the network. Another moreless single thing is the
Hello!
You replied to me only, I assume by accident. Therefore I quote your
mail to the list. This is ok, hopefully.
Dimitri Puzin schrieb:
If not already requested anywhere, LDAP support would be a sexy feature
(configuration, job definitions, etc.).
Hmm, to me, it would seem more
I am just starting down the LDAP path for our network and already I can
see how it can supplant and tie together at least 6 disparate databases
we use into a unified whole, while simultaneously being more flexible and
providing more useable functionality.
It has the potential to be extremely
Hans Manz schrieb:
Hello!
Hi,
You replied to me only, I assume by accident. Therefore I quote your
mail to the list. This is ok, hopefully.
Oops, that wasn't my intention. Thanks.
Dimitri Puzin schrieb:
If not already requested anywhere, LDAP support would be a sexy feature
Alan Brown schrieb:
I am just starting down the LDAP path for our network and already I can
see how it can supplant and tie together at least 6 disparate databases
we use into a unified whole, while simultaneously being more flexible
and providing more useable functionality.
It has the
Dimitri Puzin schrieb:
Of course you could do all that with SQL, but LDAP is
optimized for just this purpose. I could elaborate this point, if you wish.
Please.
If you don't mind I would postpone this. *ehem* :-) Basically it boils
down to simplicity and performance for specific purposes
Hello!
If not already requested anywhere, LDAP support would be a sexy feature
(configuration, job definitions, etc.).
/hm
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and
HM schrieb:
Hello!
If not already requested anywhere, LDAP support would be a sexy feature
(configuration, job definitions, etc.).
/hm
I reply to myself just to clarify what I mean. A google search on
site:bacula.org ldap did not give me anything, so maybe this idea was
not disussed,
HM schrieb:
If not already requested anywhere, LDAP support would be a sexy feature
(configuration, job definitions, etc.).
http://www.bacula.org/?page=feature-request
Ralf
-
Take Surveys. Earn Cash. Influence the
On Friday 14 July 2006 15:36, Alan Brown wrote:
Nothing major here.
Kern:
When doing a 'status storage' it would be extremely handy to know
whether jobs are:
1: spooling to disk
2: flushing the spool
3: waiting to flush
This is only applicable when spooling is enabled (of
On Mon, 14 Aug 2006, Kern Sibbald wrote:
On Friday 14 July 2006 15:36, Alan Brown wrote:
Nothing major here.
Kern:
When doing a 'status storage' it would be extremely handy to know
whether jobs are:
1: spooling to disk
2: flushing the spool
3: waiting to flush
This is only
Centos-admin schrieb:
Hello,
Hi,
Has a feature been requested to have full GNU Readline support embedded
in bconsole ? Is it feasible ?
It would be nice, If we could get it to ignore blank lines in history!
IMHO it is there for a long time already.
[EMAIL
When running concurrent jobs and data spooling, there is no indication of
which jobs are being spooled or despooled
As an example, take part of the output of several adjacent jobs:
15-Jul 18:49 msslay-sd: User specified spool size reached.
15-Jul 18:49 msslay-sd: Writing spooled data to
Nothing major here.
Kern:
When doing a 'status storage' it would be extremely handy to know
whether jobs are:
1: spooling to disk
2: flushing the spool
3: waiting to flush
This is only applicable when spooling is enabled (of course).
How hard would this be to implement?
I had 20 jobs
Hello,
Has a feature been requested to have full GNU Readline support embedded
in bconsole ? Is it feasible ?
It would be nice, If we could get it to ignore blank lines in history !
also, shouldn't the 'autodisplay' command be a toggle that doesn't need
a switch ?
Cheers,
Brian.
17 matches
Mail list logo
