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 t
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 product
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 pe
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
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
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
>>> (co
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 po
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 meani
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 Fut
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 disu
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 you'll
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
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 ena
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 Volume.
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 PROTECTED]:~/src/bacula-1.3
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.
---
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 run
17 matches
Mail list logo
