Per the Interbase Operations Guide, GBAK allows the IB server location to be specified like this:
-se localhost:service_mgr
Or if we were remoting to a server named "test" we could specify:
-se test:service_mgr
This would restore the data local to server "Test", or in the former example it would restore on the machine you're running the restore on which would give better performance.
How can this be specified in TIBRestore? There is a protocol property with TCP or Local. Does specifying the local protocol use localhost service_mgr? Or is it controlled by passing localhost as the server name?
If you're on a server named "jupiter" restoring to a server named "pluto" over a TCP/IP connection:
gbak -r user -joe -pass blurf# -se jupiter:service_mgr /backup/foo.ibk pluto:/companydb/foo.ib
From what I recall, you can also use a TCP/IP address, instead of the destination server name (i.e., 10.20.30.254 instead of pluto). That part is not really stated as such in the documentation but works on TCP/IP.
See the official examples for examples.
Related
I want a fast and flexible file server but I don't need encryption or authentication. How can I use SFTP for this on Linux systems?
SFTP happens to be used by SSH servers but it's a well-developed protocol that works well on its own. The sftp-server developed by OpenSSH has no dependency on an SSH server; sftp-server uses standard input/output. (Other SFTP servers are similar.)
It is trivial to share a filesystem via SFTP, similar to what you might do with NFS but without the need for root access. I'll use socat as the daemon for this ad-hoc example, but xinetd would make a more permanent solution. The location of sftp-server is from my Ubuntu installation of the openssh-sftp-server package.
On the server:
$ mkdir shared_to_the_world
$ cd shared_to_the_world
$ socat tcp-listen:1234,reuseaddr,fork exec:/usr/lib/openssh/sftp-server
On the client:
$ mkdir /tmp/sftp_test
$ sshfs -o reconnect,ssh_command="nc my_sftp_server_address 1234 --" : /tmp/sftp_test
$ cd /tmp/sftp_test
Now your client (and anyone else's!) can seamlessly work with the files in the shared directory on the server. Both read and write are enabled, so be careful.
Consider using socat listen's "bind" and "range" options to limit the access to your server.
You can’t use SFTP without SSH. Take a look at : https://www.ssh.com/ssh/sftp/ (emphasis mine) :
“ SFTP (SSH File Transfer Protocol) is a secure file transfer protocol. It runs over the SSH protocol.. It supports the full security and authentication functionality of SSH.
...
SFTP port number is the SSH port 22 ... It is basically just an SSH server. Only once the user has logged in to the server using SSH can the SFTP protocol be initiated. There is no separate SFTP port exposed on servers. “
I want to export some data from MongoDB Atlas.
If I execute the command below, It tries connect localhost and export the data.
mongoexport --uri="mongodb+srv://<username>:<password>#name-of-project-x2lpw.mongodb.net/test" --collection users --out /tmp/testusers.json
Note: If you run this command from Windows CMD, it works fine
After researching the problem and with the help of a user, everything seems to point to a DNS problem and to the related resolv.conf file.
Below the original /etc/resolv.conf:
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0
search name.com
At the beginning that resulted into a connection failure as shown below:
But if I would change that address into the following public available address according to what advised on this post to 1.1.1.1 the connection is successful, see below:
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 1.1.1.1
options edns0
search name.com
Which resulted into a connection success as shown below:
HOWEVER the problem is that instead of explicitly connecting to the name of the MongoDB cluster, it will connect to the localhost, which is very strange as I successfully exported the files I was looking for from the real connection.
Which means that the machine was correctly connecting to the database but via localhost.
Everything seems to lead, also according to this source and also here to a DNS problem while connecting to MongoDB via terminal to export collections.
Now from this last post it not advisable to manually change this address for several reasons, therefore right after successfully exporting the data using DNS 1.1.1.1 I changed it back to its original DNS 127.0.0.53.
However I don't think this should be a proper behavior as every time I need to export data I will have to continuously and manually change this address.
What could be the reason for this strange behavior? And therefore what could be a long term solution without manually switching between DNS addresses?
Thanks for pointing to the right direction for solving this issue.
It seems you all ready have the answer in the links you mentioned. I will summarize this:
Install resolvconf (for Ubuntu apt install resolvconf), add the line nameserver 8.8.8.8 to /etc/resolvconf/resolv.conf.d/base, then run sudo resolvconf -u and to be sure service resolvconf restart.
To verify run systemd-resolve --status.
You should see on the first line your DNS server like here:
DNS Servers: 8.8.8.8
DNS Domain: sa-east-1.compute.internal
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
This solution persists between reboots.
I am building a docker image off postgres image, and I would like to seed it with some data.
I am following the initialization-scripts section of the documentation.
But the problem I am facing now, is that my initialisation scripts needs to ssh to a remote database and dumb data from there. Basically something like this:
ssh remote.host "pg_dump -U user -d somedb" > some.sql
but this fails with the error that ssh: command not found
Question now is, in general, how do I ssh from a docker container to a remote server. In this case, specifically how do I ssh from a docker container to a remote database server as part of the initialisation step of seeding a postgres database?
As a general rule you don't do things this way. Typical Docker images contain only the server they're running and some core tools, but network clients like ssh or curl generally aren't part of this. In the particular case of ssh, securely managing the credentials required is also tricky (not impossible, but not obvious).
In your particular case, I might rearrange things so that your scripts didn't have the hard assumption the database was running locally. Provision an empty database container, then run your script from the host targeting that empty database. It may even work to set the PGHOST and PGPORT environment variables to point to your host machine's host name and the port you publish the database interface on, and then run that script unmodified.
Looking closer at that specific command, you also may find it better to set up a cron job to run that specific database dump and put the contents somewhere. Then a developer can get a snapshot of the data without having to make a connection to the live database server, and you can limit the number of people who will have access. Once you have this dump file, you can use the /docker-entrypoint-initdb.d mechanism to cause it to be loaded at first startup time.
I add a server and there are Error like this
I use pgadmin4
How I can Fix this?
Firstly, check if the server is listening.
Use the following command on your server:
netstat -nlt|grep :5432
If it's ok, SSH (or whatever method you use to access the server) to your server and view the file:
/etc/postgresql/9.1/main/postgresql.conf
Find the line start with:
listen_addresses=
If the value after "=" is 'localhost', it means that you cannot connect from outside. To be able to do so, change it to:
listen_addresses='*'
Now you will be able to connect from anywhere, outside from the server itself. And, don't forget to restart you DBMS and check if it works.
Ah. One more thing, you may also need to give your user access rights to your database as well.
Open the file:
/etc/postgresql/9.1/main/pg_hba.conf
And add:
host all all * md5
You also need to restart you DBMS to fire up changes.
P/s: You should enable SSL.
I am currently deploying to Digital Ocean using Meteor Up. If I don't specify a MONGO_URL in the mup.json, can I get the value from the command line while the website is running, i.e. I don't want to shutdown the site?
If I go to the app directory and run meteor mongo --url, I get the following error:
mongo: Meteor isn't running a local MongoDB server.
This command only works while Meteor is running your application
locally. Start your application first. (This error will also occur if
you asked Meteor to use a different MongoDB server with $MONGO_URL when
you ran your application.)
If you're trying to connect to the database of an app you deployed
with 'meteor deploy', specify your site's name with this command.
Even if I run the app from the app directory, it will only give the localhost MONGO_URL. I need the MONGO_URL for the deployed app.
I have also taken a look at a similar question as suggested by some of the answers. I disagree that it is "impossible" to get the MONGO_URL without some other program running on the server. It's not as if we are defying the laws of physics here, folks. Fundamentally, there should be a way to access it. Just because no one has yet figured it out doesn't mean it is impossible.
meteor mongo --url should return the URL.
Try opening another shell in the app directory and running that command.
Meteor Up packages your app in production mode with meteor build so that it runs via node rather than the meteor command line interface. Among other things, this means meteor foo won't work on the remote server (at least not by default). So what you're really looking for is a way to access mongo itself remotely.
I recently set up mongo on an AWS EC2 instance and listed some lessons learned here: https://stackoverflow.com/a/28846703/2669596. Some details of how you do it are going to be different on Digital Ocean, but these are the main things you have to take care of once mongo itself is installed:
Public IP/DNS Address: This is probably fine already since you can deploy to the server.
Port Security Rules: You need to make sure port 27017 is open for TCP access, at least from your IP address. MongoDB also has an http interface you can set up; if you want to use that you'll need to open 28017 as well.
/etc/mongod.conf (file location may differ depending on Linux flavor):
Uncomment port=27017 to make sure you have the default port (I don't think this is actually necessary, but it made me feel better and it's good to know where to change the default port...).
Comment out bind_ip=127.0.0.1 in order to listen to external interfaces (e.g. remote connections).
Uncomment httpinterface=true if you want to use the http interface.
You may have to restart the mongod host via sudo service mongod restart. That's a problem if you can't have downtime, but I don't know of a way around that if you change the config file.
Create User: You need to create an admin and/or user to access the database remotely.
Once you've done all of that, you should be able to access the database from your local machine (assuming you have the mongo client installed locally) by running
mongo server.url.com:27017/mup-app-name -u username -p
where server.url.com is the URL or IP address of your remote server, mup-app-name is the appName parameter from your mup.json file, username is the user you created to access the database, and you'll be prompted for that user's password after you run the command (or you could put it after -p on the same line, depending on the password).
There may also be a way to do this by setting up nginx to reverse-proxy 127.0.0.1:27017 on your remote server, but I've never done it and that's just me speculating.