On 07/15/2015 01:24 PM, Dmitry Yemanov wrote:
> 15.07.2015 13:14, Alex Peshkoff wrote:
>
>> I worry more about SQL-based management. Creating first user is required
>> step not only for initializing security3.fdb, it's also required when
>> new security database (non-default) is to be added to the
On 07/15/2015 01:24 PM, Dmitry Yemanov wrote:
> 15.07.2015 13:14, Alex Peshkoff wrote:
>
>> I worry more about SQL-based management. Creating first user is required
>> step not only for initializing security3.fdb, it's also required when
>> new security database (non-default) is to be added to the
On 07/15/2015 03:48 PM, Walter R. Ojeda Valiente wrote:
> Well, my point of view is that SYSDBA should not to exist at all. Any
> hacker knows: "there is a SYSDBA superuser, I just need to get the password
> now"
>
> At installation time or first run of GSEC the user should have the option
> of cho
Well, my point of view is that SYSDBA should not to exist at all. Any
hacker knows: "there is a SYSDBA superuser, I just need to get the password
now"
At installation time or first run of GSEC the user should have the option
of choice the name and the password of the superuser. Both of them.
Secu
15.07.2015 13:14, Alex Peshkoff wrote:
> I worry more about SQL-based management. Creating first user is required
> step not only for initializing security3.fdb, it's also required when
> new security database (non-default) is to be added to the server. May be
> play this trick if an explicit user
On 07/15/2015 01:00 PM, Dmitry Yemanov wrote:
> 15.07.2015 12:41, Alex Peshkoff wrote:
>
>> On 07/15/2015 12:20 AM, Claudio Valderrama C. wrote:
>>
>>> same as the strange need of
>>> using sysdba to add sysdba to complete the command:
>>>
>>> gsec -add sysdba -pw masterkey -user sysdba
>>>
>>> Ale
15.07.2015 12:41, Alex Peshkoff wrote:
> On 07/15/2015 12:20 AM, Claudio Valderrama C. wrote:
>
>> same as the strange need of
>> using sysdba to add sysdba to complete the command:
>>
>> gsec -add sysdba -pw masterkey -user sysdba
>>
>> Alex may say that one sysdba is the embedded admin and the o
On 07/15/2015 12:20 AM, Claudio Valderrama C. wrote:
> same as the strange need of
> using sysdba to add sysdba to complete the command:
>
> gsec -add sysdba -pw masterkey -user sysdba
>
> Alex may say that one sysdba is the embedded admin and the other is the user
> that will be added to the secu
On 07/14/2015 11:56 PM, Walter R. Ojeda Valiente wrote:
> Reading the excellent (as usual) document of Helen Borrie: Firebird 3.0
> Release Notes (for Firebird 3.0 Beta 2) I have some doubts:
>
> First, it says that for choicing the working modes (models) I need to put
> values 0 or 1 at SharedCach
> -Original Message-
> From: Carlos H. Cantu [mailto:lis...@warmboot.com.br]
> Sent: Martes, 14 de Julio de 2015 21:24
>
> Btw, seems that firebird.conf from today's snapshot doesn't
> has SharedCache and SharedDatabase parameters anymore.
> Instead, you will find just a new parameters
Title: Re: [Firebird-devel] Firebird 3, execution modes
Btw, seems that firebird.conf from today's snapshot doesn't has SharedCache and SharedDatabase parameters anymore. Instead, you will find just a new parameters name "ServerMode".
[]s
Carlos
http://www.firebirdnews
> -Original Message-
> From: Walter R. Ojeda Valiente
> [mailto:sistemas2000profesio...@gmail.com]
> Sent: Martes, 14 de Julio de 2015 17:56
>
> First, it says that for choicing the working modes (models) I
> need to put values 0 or 1 at SharedCache and SharedDatabase.
> Ok with that.
Reading the excellent (as usual) document of Helen Borrie: Firebird 3.0
Release Notes (for Firebird 3.0 Beta 2) I have some doubts:
First, it says that for choicing the working modes (models) I need to put
values 0 or 1 at SharedCache and SharedDatabase. Ok with that.
But then it says that the ex
13 matches
Mail list logo
