1

Topic: Transfer of users at migration with FB2.5 on 3.0

The people how it is possible to transfer users from FB 2.5 on FB 3.0?
In 2,5 they lived in the centralized basis security2.fdb, in 3.0 users live in the database. At some DB it is a lot of users, and to the existing password access can be problematic. Here also it would be desirable to load what that in the image from security2.fdb in a new DB.
If who knows a method - prompt please.

2

Re: Transfer of users at migration with FB2.5 on 3.0

Sirius220;
Firebird3\misc\upgrade\security

3

Re: Transfer of users at migration with FB2.5 on 3.0

hvlad, it is Very grateful

4

Re: Transfer of users at migration with FB2.5 on 3.0

hvlad wrote:

Sirius220;
Firebird3\misc\upgrade\security

Script will create users with new random passwords and type them to you.
It's your responsibility to notify users about new passwords.
The pancake, i.e. passwords in any way cannot be transferred? Here an ambush

5

Re: Transfer of users at migration with FB2.5 on 3.0

Sirius220;
For Srp - in any way. For Legacy - it is possible to try.
And the script is not cut in a stone, it can be finished under the needs

6

Re: Transfer of users at migration with FB2.5 on 3.0

hvlad,
If to understand authorization and enciphering of passwords, it would be probably possible and to make, but here I do not think.
How it turns out, a script  a file security2.fdb so that approached under FB3 and if users to transfer to the basis that users lived in my basis it turns out that it is necessary to copy to itself table RDB$USERS?

7

Re: Transfer of users at migration with FB2.5 on 3.0

Sirius220 wrote:

if to understand authorization and enciphering of passwords

In any way. Earlier passwords were ciphered DES, and now MD5. That is, storable  it turns out a miscellaneous. And from  to recover the password and it  with another  it is impossible, for this purpose it is necessary to know the initial password.

8

Re: Transfer of users at migration with FB2.5 on 3.0

kdv, it is good, then other question. Anywhere plainly it is not described, where and as it is adjusted WHERE, users of a DB will be stored in exterior basis of type security3.fdb or in the most working database.
Very slightly parameter SecurityDatabase which can be defined for each DB is mentioned. If I set it in database.conf with an addition to the same basis
atp = D:\DELPHI\DB\ATP.IB
{
SecurityDatabase = atp
}
That to be connected generally to a DB it is impossible, the error is produced:
CANNOT format message 13:98 - message file C:\Windows\system32\firebird.msg not found.
Install incomplete, please read the Compatibility chapter in the release notes for this version.
Here small retreat. Manually supposed firebird.msg in system32 and FB has been installed by a standard method. Generally it is not clear why here swears.
In an ideal: whether it is possible to register somewhere in a config, what in all DB of this server users are in the same DB?
Well also does not prevent to import the expanded description by a part:
The flag Is added
MON$SEC_DATABASE
Type of used basis
The safety data. Value of a flag can accept three values
-
Default/Self/Other

Where and as these Default/Self/Other switch

9

Re: Transfer of users at migration with FB2.5 on 3.0

Sirius220 wrote:

Install incomplete, please read the Compatibility chapter in the release notes for this version.

Read?

Sirius220 wrote:

In an ideal: whether it is possible to register somewhere in a config, what in all DB of this server users are in the same DB?

No, it is impossible. The basis with users is underlined for each specific DB, if users not in regular security3.fdb.

10

Re: Transfer of users at migration with FB2.5 on 3.0

kdv wrote:

is not present, it is impossible. The basis with users is underlined for each specific DB

And here if at developers  hands reached to make databases.conf on , as
fbtrace.conf - It would be possible.

11

Re: Transfer of users at migration with FB2.5 on 3.0

kdv wrote:

it is passed...
Read?

In a file Firebird_v3.0.3.ReleaseNotes.pdf which judging by the text should approach - is undressed Compatibility with old versions
But there I did not note concerning my problem

12

Re: Transfer of users at migration with FB2.5 on 3.0

Sirius220;
To read all three subsections:
Initializing the Security Database
Legacy Authentication
Upgrading a v.2.x Security Database

13

Re: Transfer of users at migration with FB2.5 on 3.0

hvlad, I thank, which as found, made. All is finite it becomes through one place. On good a part of operation with users, safety adjustment on all  it (is centralized) demands cardinal finishing.  still looks, and after all it already release.

14

Re: Transfer of users at migration with FB2.5 on 3.0

Sirius220;
Actually to store users always in the DB it is silly. At least because there is a heap of service operations which cannot use a DB. Well or for example creation of a new DB.

15

Re: Transfer of users at migration with FB2.5 on 3.0

Simonov Denis;
And if is  on which 10 same bases which represent access to the software to other organizations and from  programs can create the users, and the fact that names of type TB (security regulation) will be created in both DB and does not jam one another at creation of the new user with such name.

16

Re: Transfer of users at migration with FB2.5 on 3.0

Sirius220;
Thanks for rather specific and detailed response.
We is mandatory consider all stated remarks.
With impatience we wait for new so valuable instructions.
Such answer was expected?

17

Re: Transfer of users at migration with FB2.5 on 3.0

Sirius220 wrote:

Syrovato still looks, and after all it already release.

Where you were when there was a possibility to test  Alpha and Beta to release? Where your sentences at a development cycle 3.0 in fbdevel? Where though one registered  in ?

18

Re: Transfer of users at migration with FB2.5 on 3.0

hvlad;
Trolling? smile Yes, it was expected such, well or similar to refine a product.
I can state particulars of that as it would be desirable to see, therefore as at all different tasks. Certainly I do not consider that you are obliged to do as I want (as it is required under the task), simply one is necessary to someone, and someone another.
But the most important thing if there was a centralized adjustment in firebird.conf that in all bases users are stored in the basis is would be super. Automatic change databases.conf if needed would be possible (already to ourselves) to make a script what . What for?
There is a necessity for the new client to tear a new DB. The manager imports the data to the form, pushes a button and the start pure basis is copied with the necessary name in the necessary directory, corrected databases.conf for creation , and  receives a line for connection to a DB, that's all. Yes, time is corrected databases.conf that not a problem to add and SecurityDatabase I do not argue, simply somehow it was expected big  adjustments

19

Re: Transfer of users at migration with FB2.5 on 3.0

Sirius220 wrote:

There is a necessity for the new client to tear a new DB. The manager imports the data to the form, pushes a button and the start pure basis is copied with the necessary name in the necessary directory, corrected databases.conf for creation , and  receives a line for connection to a DB, that's all. Yes, time is corrected databases.conf that not a problem to add and SecurityDatabase I do not argue, simply somehow it was expected big  adjustments

Who hinders to write such utility on developments independently? Why all think that to developers of a kernel any more that to do as to write the elementary scripts which any student is capable to write.

20

Re: Transfer of users at migration with FB2.5 on 3.0

Simonov Denis;
If at me not so it turns out to write fairly that in English, and after all  and in  it is necessary to write to a bug on it therefore I and did not take part in testing. Yes if it is fair, at that point in time such and it was not required. Then  FB2.5, and now it is simple  the task that I wrote hardly above, and here I start to understand with that that is.
(To criticize always easily, well except that variant that around wood, the critic is connected, and at criticized a trunk smile))), all it is impossible to provide children if that I do not criticize that, in itself it I know, simply unknown earlier the moments here are now clarified

21

Re: Transfer of users at migration with FB2.5 on 3.0

Denis wrote:

Who hinders to write such utility on developments independently? Why all think that to developers of a kernel any more that to do as to write the elementary scripts which any student is capable to write.

Not-not, it not to you the claim, it is clear that we write also to you to make something similar even did not think, it was simply not clear about users at first and unpleasantly about losses of passwords.

22

Re: Transfer of users at migration with FB2.5 on 3.0

Sirius220;
I not the developer of a kernel, if that

23

Re: Transfer of users at migration with FB2.5 on 3.0

Simonov Denis;
Well in the documentation were lit, and I by name do not remember developers, and it is not important smile

24

Re: Transfer of users at migration with FB2.5 on 3.0

Sirius220 wrote:

it is unpleasant about losses of passwords

Not probably to change the hashing algorithm and thus to save passwords. If it is necessary to save passwords is LegacyAuth, but it is considered become outdated and exists for compatibility with client libraries fb 2.5

25

Re: Transfer of users at migration with FB2.5 on 3.0

Simonov Denis, most likely (precisely I do not know) at DES and MD5 different length of a line. For , the transferred passwords it would be possible, looking on length of a line, to apply old algorithm, for new - new and to create in new algorithm.
For example, if now to do passage with 2,5 on 3 me gobble simply up. Each of 40 users if bites one time (and some can and more) there will be only a backbone smile)))