Weird approach to replace SYSDBA

[Yordan Yanakiev]

Hello.
I wonder if a database ( firebird 2.5 fire ) is opened as a text file with some text editor ( like Notepad++), and SYSDBA is replaced as binary text with an string with the same length ( this part is working ) - will this generally change the SYSDBA or it is hidden somewhere else as well ?

[Mark Rotteveel]

It will not make that user a global SYSDBA, but the user will have all
privileges that the SYSDBA user specifically had in that specific
database. And if SYSDBA was the database owner, the replacement user
will be the database owner.

Mark
--
Mark Rotteveel

[Elmar Haneke]

It certainly resides in security database too.

What do you intend with that hack?

Someone having direct access to database file can open it with a server on that he knows sysdba password - or with embedded stuff not using any passwords at all. No matter if the DB is "owned" by SYSDBA or some other username.

To protect database from direct access you can use database encryption. 

For v3 onwards you find plugin description in manuals or you can buy closed source plugins for that. 

For FB25 you have to enable the old encryption stuff normally disabled.

Am 13.10.23 um 09:55 schrieb Yordan Yanakiev:

Hello.
I wonder if a database ( firebird 2.5 fire ) is opened as a text file with some text editor ( like Notepad++), and SYSDBA is replaced as binary text with an string with the same length ( this part is working ) - will this generally change the SYSDBA or it is hidden somewhere else as well ?

--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/f476bfb6-19fe-4f66-abc6-0cb92b467d2an%40googlegroups.com.

[Yordan Yanakiev]

well I am trying to replace the SYSDBA user, which seems to be unreplaceable, and there is not direct tool which is doing it.

If there is such tool - please help me acquire it. 

[Mark Rotteveel]

On 13-10-2023 10:42, Yordan Yanakiev wrote:
> well I am trying to replace the SYSDBA user, which seems to be
> unreplaceable, and there is not direct tool which is doing it.
> If there is such tool - please help me acquire it.

You can't. The best you can do is make SYSDBA inactive or drop it (Srp),
or delete it directly from the security DB (Legacy_UserManager), but it
is not advisable to do so. It seems you try to get some form of security
through obscurity.

To give another user equivalent rights, it needs to have RDB$ADMIN in
the security database and in the specific database(s) that user needs to
manage.

Mark
--
Mark Rotteveel

[Yordan Yanakiev]

well.. the databases are directly placed on public server for access from everywhere in the word

since the clients need it this way. the only way is to be protected by removing SYSDBA and leave only randomly generated user.

yet the bases comes with the SYSDBA, and so far i had to pass trough a lot of procedures which resulting removing it, and these weird backup-restores from scripts, etc which sometimes render to not working, and had to redo the procedure.

So I am looking for faster way to remove the SYSDBA and replace it with new user which is owner of the all objects inside the specific database file.

[Dimitry Sibiryakov]

Yordan Yanakiev wrote 13.10.2023 10:57:
> well.. the databases are directly placed on public server for access from
> everywhere in the word
> since the clients need it this way.

Public Firebird server doesn't mean physical access to database file.

> the only way is to be protected by removing
> SYSDBA and leave only randomly generated user.

That's the right way to go.

> yet the bases comes with the SYSDBA

No, Firebird security doesn't work this way. Users are not kept in all
databases. They are only in security database.

> So I am looking for faster way to remove the SYSDBA and replace it with new user
> which is owner of the all objects inside the specific database file.

Learn basics about how Firebird works and you won't need to waste your time
to pointless tasks.

--
WBR, SD.

[Mark Rotteveel]

On 13-10-2023 10:57, Yordan Yanakiev wrote:
> well.. the databases are directly placed on public server for access
> from everywhere in the word

You shouldn't do that. At minimum require VPN access, or use some API
(e.g. a REST service) to mediate between the database and the rest of
the world, and control access.

> since the clients need it this way. the only way is to be protected by
> removing SYSDBA and leave only randomly generated user.
> yet the bases comes with the SYSDBA, and so far i had to pass trough a
> lot of procedures which resulting removing it, and these weird
> backup-restores from scripts, etc which sometimes render to not working,
> and had to redo the procedure.
> So I am looking for faster way to remove the SYSDBA and replace it with
> new user which is owner of the all objects inside the specific database
> file.

As I said, the best you can do is *drop* or alter inactive SYSDBA (if it
is a Srp user), or manually *delete* it from the security database (if
it is a Legacy_Auth user).

You can make a user the owner of a database by restoring the database
with that user (the user does need to have create database privileges in
recent versions).

You can also create a role called SYSDBA to prevent SYSDBA from
connecting to a specific database, or create a mapping to redirect
authentication attempts as SYSDBA to a different user (i.e. one without
privileges).

But all of that should only be done *after* you have granted at least
one user RDB$ADMIN in the database, and in the security database,
otherwise you may have locked yourself out.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

Yordan Yanakiev wrote 13.10.2023 10:57:

> the databases are directly placed on public server for access from everywhere in
> the word
> since the clients need it this way.

BTW, there are already established Firebird hosing over the Net such as (from
Google) https://www.mydreams.cz/cz/firebird-vps-hosting.html or
https://aws.amazon.com/marketplace/pp/prodview-fjwp7f7ss56xa
Did you consider using it instead of jumping into unknown waters yourself?

--
WBR, SD.

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-support wrote 13.10.2023 11:05:
>> well.. the databases are directly placed on public server for access from
>> everywhere in the word
>
> You shouldn't do that. At minimum require VPN access, or use some API (e.g. a
> REST service) to mediate between the database and the rest of the world, and
> control access.

With Firebird wire encryption there is no point to use VPN anymore. Also
Firebird has protection from brute force so REST layer only complicate things
and add another bug nest. Whatever attack can be done to Firebird is applicable
to it as well.

--
WBR, SD.

[Yordan Yanakiev]

The things is currently working this way, and it is not going to change anytime soon. 
Role based model is no-go. It is supporting old software which is no-go for it as well.

I would like to keep on the topic if possible. 

So - generally I got confused, please help me on the main topic:
- Will a raw string replacement of SYSDBA act in any way destructive ?
- Shall I regrant all privileges to all objects in the database to the newly user ?

- Do I need to do backup/restore once the above procedures are applied ?

- Is there another way or tool to replace the SYSDBA user in the database ?

[Dimitry Sibiryakov]

Yordan Yanakiev wrote 13.10.2023 13:45:
> So - generally I got confused, please help me on the main topic:
> - Will a raw string replacement of SYSDBA act in any way destructive ?

If is done in Notepad or MSWord - yes, it will destroy database completely
because the database is a binary file, not text.

> - Shall I regrant all privileges to all objects in the database to the newly user ?
> - Do I need to do backup/restore once the above procedures are applied ?
> - Is there another way or tool to replace the SYSDBA user in the database ?

There is no "SYSDBA user in the database" so there is nothing to replace at
first hand.
Name of database and objects owner is irrelevant if this user is not in
security database.
Database owner is changed by backup-restore. To change owner of objects you
need to recreate the database from script but as is said above - normally there
is no need for that.

--
WBR, SD.

[Yordan Yanakiev]

Weirdly 659 occurrences of SYSDBA inside the file. 
It is not a question if it is working or not as i said, since for sure it is exists inside the file.

Replacement works as I noted a few times. 

[Dimitry Sibiryakov]

Yordan Yanakiev wrote 13.10.2023 13:56:
> Weirdly 659 occurrences of SYSDBA inside the file.

Having string "SYSDBA" in file doesn't mean that there is SYSDBA user as I
already said. You should not care about irrelevant things.

--
WBR, SD.

[Yordan Yanakiev]

I am really confused now.

So, You are saying that Firebird 2.5 files ( not 3 and above ) not having SYSDBA, and I can open a database created with SYSDBA, and work with all of it's tables and do all possible changes with any user ?

[Dimitry Sibiryakov]

Yordan Yanakiev wrote 13.10.2023 14:07:
> So, You are saying that Firebird 2.5 files ( not 3 and above ) not having
> SYSDBA, and I can open a database created with SYSDBA, and work with all of it's
> tables and do all possible changes with any user ?

Yes, that's how every SQL server works: one user creates a database and
others connect and work with it.

--
WBR, SD.

[Tomasz Tyrakowski]

On 13.10.2023 at 14:07, Yordan Yanakiev wrote:
> I am really confused now.
> So, You are saying that Firebird 2.5 files ( not 3 and above ) not having
> SYSDBA, and I can open a database created with SYSDBA, and work with all of
> it's tables and do all possible changes with any user ?

Let's maybe try this way.
If the database file (the .fdb / .gdb file) is not directly accessible
for users (as it shouldn't be), but only accessible via the Firebird
server instance (requiring a login/password authentication), just set a
strong SYSDBA password, create user accounts, grant them appropriate
priviledges in the database, and you're good.
If, on the other hand, the database file is directly accessible,
changing SYSDBA to some random owner XYZ gives you nothing. Imagine I
copy this file to my machine, run a local Firebird server, create the
XYZ user (with a password I know) on my server and access the database -
I'm a DB owner now and can do anything.
If the database file is directly accessible, the above isn't even
necessary - one can bypass the security entirely and open it in embedded
(i.e. direct file access) mode, without the need of any user name or
password. The assumption is that if you can access the file on the OS
level (bypassing the server process), you're as good as the database owner.
So if you want any security at all, you just can't post the raw database
file for everyone to access. There's no way you can make it secure (if
you can bin-edit the file and change the owner, so can everybody else).

regards
Tomasz

[Yordan Yanakiev]

the databases ( there is about 400 of them ) are placed on public server, accessible freely from all around the world.

There is no limitation since the users switch networks, move around, etc.

Only User based rights to each db is granted with a generating random user/ password, but it tooks too long time to be done for a databases which is 10 GB and above right now.

[Dimitry Sibiryakov]

Yordan Yanakiev wrote 13.10.2023 14:41:
> the databases ( there is about 400 of them ) are placed on public server,

> accessible freely from all around the world > There is no limitation since the users switch networks, move around, etc.

Read carefully
https://firebirdsql.org/file/documentation/reference_manuals/user_manuals/html/qsg25.html
and
https://firebirdsql.org/file/documentation/html/en/refdocs/fblangref25/firebird-25-language-reference.html

> Only User based rights to each db is granted with a generating random user/
> password, but it tooks too long time to be done for a databases which is 10 GB
> and above right now.

You must be joking.
Once again: there is no users in databases.
Time to issue query "alter user set password" does not depend on size of
database.
Learn basic things about Firebird now before you spoiled everything, please.

--
WBR, SD.

[Tomasz Tyrakowski]

On 13.10.2023 at 14:41, Yordan Yanakiev wrote:
> the databases ( there is about 400 of them ) are placed on public server,
> accessible freely from all around the world.

What do you mean by that? Can I copy the database file (the actual
fdb/gdb file) to my local machine, or do I need to access it via a
Firebird server instance running on the public server, I don't have
access to the DB file and have to provide a valid Firebird user name and
password to access the data?

> There is no limitation since the users switch networks, move around, etc.
> Only User based rights to each db is granted with a generating random user/
> password, but it tooks too long time to be done for a databases which is 10
> GB and above right now.

What are "user based rights"? What users are you talking about? Firebird
users, filesystem users, other kind of users?

regards
Tomasz

[Yordan Yanakiev]

The most helpful group ever.

"read documentation" and "let's post something offtopic".
Classic.

[Tomasz Tyrakowski]

On 13.10.2023 at 16:20, Yordan Yanakiev wrote:
> The most helpful group ever.
> "read documentation" and "let's post something offtopic".
> Classic.

I don't see how trying to understand your situation and advice you
before you do something stupid is off topic, but have it your way.

Tomasz

[Dimitry Sibiryakov]

Yordan Yanakiev wrote 13.10.2023 16:20:
> "read documentation" and "let's post something offtopic".
> Classic.

Firebird is a complex SQL server with rather high threshold of entry. You
cannot manage it without any knowledge.

--
WBR, SD.

[Mark Rotteveel]

On 13-10-2023 13:53, 'Dimitry Sibiryakov' via firebird-support wrote:
>   There is no "SYSDBA user in the database" so there is nothing to
> replace at first hand.

There might not be a user in the database, but privileges are granted to
user SYSDBA explicitly in a database. Replacing SYSDBA with a different
username will transfer those privileges (and any object owned) to that
different username.

Mark
--
Mark Rotteveel

[Mark Rotteveel]

On 13-10-2023 09:55, Yordan Yanakiev wrote:

Maybe we need to start again:

What are you trying to achieve, and why? Why exactly do you want to
replace SYSDBA?

Why can't you just grant sufficient rights to another user?

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-support wrote 14.10.2023 9:31:
> There might not be a user in the database, but privileges are granted to user
> SYSDBA explicitly in a database.

Well... Privileges can be granted to SYSDBA but it is meaningless because the
engine compares user name to "SYSDBA" literally and if matched bypass all checks
completely.
That's why this user is so troublesome from security POV.

--
WBR, SD.

[Yordan Yanakiev]

The replacement is by request. This is not something I can manage. It is mandatory as given from the superiors.
 I can either do it or they will just move the things to someone else todo it their way.
 It is not something I can discuss "why", but as far as I understand there is something related to the host which rejecting if SYSDBA is present.
 Role based is a no-go as far as I understand. There is old software which can not or at least will not be rewritten, and with role based approach it just doesnt work by some reason, as far as I understand there is some store procedures which do admin stuff or something.
There is more than 400 clients which works in own database files, so we need to support them. They are using currently local databases, which now are move on a public server, and they need to direct access them from anywhere.
So far we were doing this user thingy from IBExpert by extracting the data and pushing it back to a new database with proper credentials.

 Yet for a large databases this is more than a pain, and with the crashes which occurring during the extraction and the regeneration the things is more than awful to be done at the moment.
 That's why I were looking for more convenient and fast way to do it.
 Seems like my problem is more than well known problem with practically hit-the-wall solutions which may or may not works, and usually all requests for help like mine as far as i saw were whiteknighted by "read the documentation" answers in the forums, and the documentation usually  face again the wall with this post : https://www.firebirdfaq.org/faq108/
This sends me to the idea of manually binary replacement in the file, and here I am. 

That's all more or less.

[Mark Rotteveel]

On 14-10-2023 17:10, Yordan Yanakiev wrote:
>  It is not something I can discuss "why", but as far as I understand
> there is something related to the host which rejecting if SYSDBA is present.

Binary searching an replacing SYSDBA is an odd solution. That is why you
get some pushback here. The "why" is important to know what problem
you're really trying to solve and to suggest a proper way forward. For
example, what is meant with "rejecting if SYSDBA is present".

Users are not part of the database itself, only privileges granted to
users, so if the concern is the existence of SYSDBA, then deleting it
from the security database should be sufficient. Any reference to SYSDBA
itself are then irrelevant, because that user cannot login.

If the problem is that historically SYSDBA has been used for database
access, then the solution is to grant sufficient privileges to another
user, and use that user moving forward.

Mark
--
Mark Rotteveel

[Yordan Yanakiev]

The databases were used previously locally on the user computers, with SYSDBA user.
As they are giving these databased now to put them on the server - we need to replace this user.

[Dimitry Sibiryakov]

Yordan Yanakiev wrote 14.10.2023 20:31:
> The databases were used previously locally on the user computers, with SYSDBA user.
> As they are giving these databased now to put them on the server - we need to
> replace this user.

But you need to replace the user in application's connection, not in the
database.

--
WBR, SD.

[Mark Rotteveel]

On 14-10-2023 20:31, Yordan Yanakiev wrote:
> The databases were used previously locally on the user computers, with
> SYSDBA user.
> As they are giving these databased now to put them on the server - we
> need to replace this user.

That doesn't mean you need to replace SYSDBA physically. You need to
grant sufficient privileges to the new user using GRANT[1].

[1]:
https://firebirdsql.org/file/documentation/html/en/refdocs/fblangref25/firebird-25-language-reference.html#fblangref25-security-privs-granting

--
Mark Rotteveel

[Yordan Yanakiev]

We've tried this about 12 years ago, and we have walked this road a few times already.
The database contains 300+ store procedures,  400+ triggers, 600+ generators, 230 tables, 60 views.. etc.. as well we do things over some system  tables.

As  well the user must be only related to this and none else db, as well it must be able to do system procedures remotely - like restoring, backuping etc. 

And above which is given means more mess and much harder to apply than the current things which we are doing.

[Dimitry Sibiryakov]

Yordan Yanakiev wrote 15.10.2023 10:59:
> The database contains 300+ store procedures,  400+ triggers, 600+ generators,
> 230 tables, 60 views.. etc.. as well we do things over some system  tables.
> As  well the user must be only related to this and none else db, as well it must
> be able to do system procedures remotely - like restoring, backuping etc.
> And above which is given means more mess and much harder to apply than the
> current things which we are doing.

Getting database creation script, search-and-replace, creating database,
pumping data. All these tasks can be fully automated using isql, sed and fbexport.

--
WBR, SD.

[Karol Bieniaszewski]

isn't it simpler to upgrade to Firebird 3 or 4 and use the RDB$ADMIN role?

 

Regards,

Karol Bieniaszewski

--

You received this message because you are subscribed to the Google Groups "firebird-support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/7c30ac2a-6527-3cee-d9f7-eaa4b85e7c6c%40ibphoenix.com.

 

[Dimitry Sibiryakov]

Karol Bieniaszewski wrote 15.10.2023 13:14:
> isn't it simpler to upgrade to Firebird 3 or 4 and use the RDB$ADMIN role?

They said "ancient application with no sources". Upgrade of SQL server under
such circumstances is next to impossible.

--
WBR, SD.

[Karol Bieniaszewski]

But this application have user name at start at all? If not, without source code changing user name is hard, binary file editing, but maybe it is a s text in executable…

 

Regards,

Karol Bieniaszewski

 

Od: 'Dimitry Sibiryakov' via firebird-support
Wysłano: niedziela, 15 października 2023 13:16
Do: firebird...@googlegroups.com
Temat: Re: [firebird-support] Weird approach to replace SYSDBA

 

Karol Bieniaszewski wrote 15.10.2023 13:14:

--

You received this message because you are subscribed to the Google Groups "firebird-support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/aae9a2b8-fb71-42a1-771d-ae2283e3eb60%40ibphoenix.com.

 

[Mark Rotteveel]

On 15-10-2023 13:14, Karol Bieniaszewski wrote:
> isn't it simpler to upgrade to Firebird 3 or 4 and use the RDB$ADMIN role?

RDB$ADMIN also exists in Firebird 2.5, but in Firebird 3.0 and earlier
you would need to be able to specify the role, but the OP said they
can't use roles. In Firebird 3.0 you might be able to use a mapping to
automatically assign the role.

In Firebird 4.0 you would be able to assign it as a default role, which
would automatically confer the rights. That said, I wouldn't want a
normal application user to have full admin rights on a database.

On the other hand, the OP could also spend some time to create a script
to confer all necessary privileges to a user, and make it a template and
execute it on each database with the desired user.

Mark
--
Mark Rotteveel

[Elmar Haneke]

The replacement is by request. This is not something I can manage. It is mandatory as given from the superiors.

ok that's an reasonable answer for "why".

Role based is a no-go as far as I understand. There is old software which can not or at least will not be rewritten, and with role based approach it just doesnt work by some reason, as far as I understand there is some store procedures which do admin stuff or something.

That's rather strange.

You have a lot of databases around, currently users are working with local databases on single user installations without servers involved.

Database internally uses username "sysdba" in some procedures/triggers etc.

You intend to host all these Databases on a public database server.

Since none of the users are SYSDBA on that new server in each of that databases the name "sysdba" has to be changed to something different as "user1", "user2" etc.

Certainly recreate and datapump is the better solution as it is a supported method of working with databases. In case of problems you get reasonable error messages and you can find help in solving that.

Binary replace of username "sysdba" may work, but it may also have side effects. It is not a supported mechanism, and you might be on your own if it results in any trouble.

There is more than 400 clients which works in own database files, so we need to support them. They are using currently local databases, which now are move on a public server, and they need to direct access them from anywhere.

Do you really expect that to work without modifying client software?

As you use v2.5 there is no wire encryption available and a VPN is a good idea.

When connecting "from anywhere" performance might degenerate due to higher latency in connection. V3 is more efficient on that than v2.5

So far we were doing this user thingy from IBExpert by extracting the data and pushing it back to a new database with proper credentials.

 Yet for a large databases this is more than a pain, and with the crashes which occurring during the extraction and the regeneration the things is more than awful to be done at the moment.

Perhaps it is a good idea to ask for help on that trouble.

 That's why I were looking for more convenient and fast way to do it.
 Seems like my problem is more than well known problem with practically hit-the-wall solutions which may or may not works, and usually all requests for help like mine as far as i saw were whiteknighted by "read the documentation" answers in the forums, and the documentation usually  face again the wall with this post : https://www.firebirdfaq.org/faq108/
This sends me to the idea of manually binary replacement in the file, and here I am. 

That's all more or less.

All answers on the list tend to direct you to consider going a direct way.

Elmar

[Dimitry Sibiryakov]

Elmar Haneke wrote 16.10.2023 12:14:
> When connecting "from anywhere" performance might degenerate due to higher
> latency in connection. V3 is more efficient on that than v2.5

Most optimization of network protocol was already done in 2.5 so 3.0 won't
provide additional gain.

--
WBR, SD.

[Pavel Cisar]

Mark,

if they would be able to use v3+, then easiest way would be to use
databases.conf and set each database to act as its own security
database, so all clients would have security separated from each other.
No need to remove SYSDBA etc. then, they would just give them their own
distinct passwords.

Pavel Cisar
IBPhoenix

Dne 16. 10. 23 v 12:14 'Mark Rotteveel' via firebird-support napsal(a):

[Mark Rotteveel]

On 16-10-2023 12:32, Pavel Cisar wrote:
> if they would be able to use v3+, then easiest way would be to use
> databases.conf and set each database to act as its own security
> database, so all clients would have security separated from each other.
> No need to remove SYSDBA etc. then, they would just give them their own
> distinct passwords.

You're right, assuming that wouldn't clash with that "no SYSDBA"
requirement.

Mark
--
Mark Rotteveel

[Pavel Cisar]

Dne 16. 10. 23 v 12:45 'Mark Rotteveel' via firebird-support napsal(a):

>
> You're right, assuming that wouldn't clash with that "no SYSDBA"
> requirement.

Yes, but it depend on why they want to disable SYSDBA. With multiple
independent users sharing the same server with single security database,
these users will share the same SYSDBA (password) which is a problem.
So, it's likely that their requirement is based on this problem (prevent
that any user could access databases of other users as SYSDBA). I.e.
classic web hosting with db offering scenario problem that Firebird 3
reworked security was designed to solve.

The second possible reason is that SYSDBA is well-known name, and hence
a target for hacking attempts for any server exposed to the internet,
which they want to close. But to hack into Firebird this way is not
easy. It requires knowledge of the database location to try brute force
on attachment, and there are AFAIK countermeasures in v3 security that
will slow down any brute force attack attempts on service manager after
few unsuccessful authentications.

best regards
Pavel Cisar
IBPhoenix

[Yordan Yanakiev]

yes. this is the main reason as i understand =  ( but even if it isnt - i am unable to argue on the topic why. it is just a task which is mandatory to be completed by the requirements ).
Now as You mention the FB 3 is doing this also as a base - i wonder if there is some tool which is making direct transition 2.5 -> 3.0 without issues, and will be Delphi 4/7 apps having issue connecting to the result db ?

[AlexPeshkoff]

Nobody can garantee version upgrade without issues. 

I.e. you can backup in 2.5 and restore in 3.0 w/o problems, but what bout existing delphi application - who knows how will it behave.

But if you care about security (I suppose yes, or why avoid SYSDBA ?) that upgrade is required. Pre FB3 passwords are transmitted over the wire in almost unencrypted way (i.e. one intercepted from the packet can be used to attach database w/o decrypt). I.e. with that authentication it does not matter how do you call DB owner :-)

понедельник, 16 октября 2023 г. в 22:15:33 UTC+3, yor...@yanakiev.org:

[Yordan Yanakiev]

AlexPeshkoff - thank you for the clarification. Well.. seems like upgrade is no-go, so back to the main topic then.  :'(