Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RemoteBindAddress other than localhost makes nbackup unusable (is there already a workaround?) [CORE2089] #2523

Open
firebird-automations opened this issue Sep 18, 2008 · 9 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Cosmin Apreutesei (cosmin_ap2)

NBACKUP only works with localhost:full_db_path. This makes nbackup unusable if RemoteBindAddress is anything than localhost.

Possible workarounds:
- make RemoteBindAddress accept a list of IP addresses to bind to instead of just one (so I can add localhost to the list, and use that with nbackup), or
- allow nbackup to connect to hosts other than localhost like gbak does (I get it there's a request for that already, I'm not sure), or
- allow nbackup to attach locally to the database (i.e. without hostname -- with this setup I get "cannot attach to password database" to stderr and "operating system directive semget failed" in firebird.log -- this might be a just problem with my own setup, I cannot tell for sure).

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

Component: NBACKUP [ 10007 ]

description: It seems (from what I understood from previous mailing list questions) that nbackup only works with localhost:full_db_path. This makes nbackup unusable if RemoteBindAddress is anything than localhost (not a common setting?).

Possible workarounds:
- make RemoteBindAddress accept a list of IP addresses to bind to instead of just one (so I can add localhost to the list, and use that with nbackup), or
- allow nbackup to connect to hosts other than localhost like gbak does (I get it there's a request for that already, I'm not sure), or
- allow nbackup to attach locally to the database (i.e. without hostname -- with this setup I get "cannot attach to password database" to stderr and "operating system directive semget failed" in firebird.log -- this might be a just problem with my own setup, I cannot tell for sure).

=>

It seems (from what I understood from previous mailing list questions) that nbackup only works with localhost:full_db_path. This makes nbackup unusable if RemoteBindAddress is anything than localhost (not a common setting?).

Possible workarounds:
- make RemoteBindAddress accept a list of IP addresses to bind to instead of just one (so I can add localhost to the list, and use that with nbackup), or
- allow nbackup to connect to hosts other than localhost like gbak does (I get it there's a request for that already, I'm not sure), or
- allow nbackup to attach locally to the database (i.e. without hostname -- with this setup I get "cannot attach to password database" to stderr and "operating system directive semget failed" in firebird.log -- this might be a just problem with my own setup, I cannot tell for sure).

@firebird-automations
Copy link
Collaborator Author

Modified by: Cosmin Apreutesei (cosmin_ap2)

Version: 2.1.1 [ 10223 ]

Version: 2.1.2 [ 10270 ]

description: It seems (from what I understood from previous mailing list questions) that nbackup only works with localhost:full_db_path. This makes nbackup unusable if RemoteBindAddress is anything than localhost (not a common setting?).

Possible workarounds:
- make RemoteBindAddress accept a list of IP addresses to bind to instead of just one (so I can add localhost to the list, and use that with nbackup), or
- allow nbackup to connect to hosts other than localhost like gbak does (I get it there's a request for that already, I'm not sure), or
- allow nbackup to attach locally to the database (i.e. without hostname -- with this setup I get "cannot attach to password database" to stderr and "operating system directive semget failed" in firebird.log -- this might be a just problem with my own setup, I cannot tell for sure).

=>

NBACKUP only works with localhost:full_db_path. This makes nbackup unusable if RemoteBindAddress is anything than localhost.

Possible workarounds:
- make RemoteBindAddress accept a list of IP addresses to bind to instead of just one (so I can add localhost to the list, and use that with nbackup), or
- allow nbackup to connect to hosts other than localhost like gbak does (I get it there's a request for that already, I'm not sure), or
- allow nbackup to attach locally to the database (i.e. without hostname -- with this setup I get "cannot attach to password database" to stderr and "operating system directive semget failed" in firebird.log -- this might be a just problem with my own setup, I cannot tell for sure).

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Version: 2.1.2 [ 10270 ] =>

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

NBACKUP is expected to work locally without problems.

@firebird-automations
Copy link
Collaborator Author

Commented by: Cosmin Apreutesei (cosmin_ap2)

I know (I read CORE846), and yes, it works with local and localhost connection strings on both versions, but it doesn't work at all (below is which combinations I tried) if you have set RemoteBindAddress to anything _other_ than localhost (tested on 2.1.1 and 2.1.2).

So only when setting RemoteBindAddress to anything other than localhost is nbackup becoming unusable, otherwise it works fine.

Here's what I tried:

nbackup -U sysdba -P masterkey -B 0 /mydb.fdb /mydb.nbk -- unable to connect to localhost (instantly??)
nbackup -U sysdba -P masterkey -B 0 localhost:/mydb.fdb /mydb.nbk -- unable to connect to localhost (after an honest ~3s timeout)
nbackup -U sysdba -P masterkey -B 0 myhost:/mydb.fdb /mydb.nbk -- Failure: Error (2) opening database file myhost:/mydb.fdb (instantly)

If this is a known limitation then this ticket should be a request for improvement and certainly not a bug report. If that is the case then forgive my misunderstanding.

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Since 3.0 (with always present embedded access to databases) the issue will be gone.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Open [ 1 ]

Target: 3.0 Initial [ 10301 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ] =>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant