I installed successfully ddev for TYPO3 and now want to connect to the mariadb database. But what are the credentials? If I ssh into the container and want to connect I got a password prompt.
Access via external tools is described in Using Developer Tools with ddev.
Specifically you need to execute the following command to get the necessary credentials:
ddev describe
When upgrading my ddev and deleting all the containers, everything stayed the same except my new port number incremented up by one.
mariadb
Host: localhost:portNumberIncrementedByOne
User/Pass: 'db/db'
Related
I used to connect remote servers provided by Linode and GCP and I use Visual Studio Code via Sftp extension and all works just fine. However, with the same set of configurations, I couldn't connect to my Aws EC2 server.
The following is the sftp.json (with sensitive information changed)
And the aws security setting is as following
The strange thing is that I can ssh connect to the server on the terminal and I can use filezilla to send file with the same credential as well. But somehow I can't connect to it via Visual Studio Code sftp or SSH remote extension.
I searched the anwser on the internet and found an answer that worked for me.
The problem has to do with the Ubuntu 22.04 default server default key setting and not with the VSCode.
The solution is adding
PubkeyAcceptedKeyTypes=+ssh-rsa
in /etc/ssh/sshd_config
and then restart the service on the server with the following command
sudo systemctl restart sshd
The source of the answer comes from https://github.com/liximomo/vscode-sftp/issues/37 under the user windware-ono's answer.
The Omnibus version of Gitlab by default are using postgresql['enable'] = true, this seems that the postgresql can not be accessed by normal psql command, even in the Omnibus Gitlab container itself.
So is this true? If not how can I access this embedded postgresql from remote terminal?
This question is really what I want to do and it relates to my another post What's the default password for postgreSQL installed by Gitlab Omibus version?
If it is omnibus and you are using bundled postgres then you can use gitlab-rails dbconsole for accessing the database.
So you can try something like this docker exec -it CONTAINERID bash and then you can simply run gitlab-rails dbconsole.
Do let me know if this helps.
As the official document explained but not that specific and clear, https://docs.gitlab.com/omnibus/settings/database.html#configure-postgresql-block,
to expose the Postgresql from Gitlab Omnibus version。
postgresql['trust_auth_cidr_addresses'] and postgresql['listen_address'] are important and have to specified together, whereas this details not that much put on the documentation. Just tweak these two carefully then you can telnet PostgreSQL or login it remotely by using DBeaver as a sql client.
I installed Omnibus Gitlab using the docker image of gitlab-ce. Now my question is what's the default password for the embedded PostgreSQL database password?
I checked the Dockerfile and some scripts along with it from https://gitlab.com/gitlab-org/omnibus-gitlab, but could not find any clue.
Actually no need to access the remote PostgreSQL server which is embedded in the Omnibus version for users. If this is needed, just follow the documents to do more configuration to achieve this, like my another post answered. How to access/login postgres in gitlab omnibus docker container or from remote terminal?
After install pgAdmin III from Ubuntu Software Center, I opened it and it required to add a connection to a server. So I filled in information as below:
Upon clicking on Ok Button, it showed the error message
Error connecting to the server: could not translate host name
"http://127.0.0.1" to address: Name or service not known
As message indicated, I thought the postgres service was not started. Therefore, I went on go terminal console and start service by entering sudo service postgresql start, but it returned Failed to start postgresql.service: Unit postgresql.service failed to load: No such file or directory.
. What's wrong or missing for my pgAdmin III? I'm just using Ubuntu earlier and I have never this problem on windows. Thanks.
http://127.0.0.1 is more a URL, that field is looking for a host so simply remove the http:// to leave the localhost's IP address 127.0.0.1 or type localhost if that resolves to the correct address (it should, usually, via /etc/hosts or the like)
Also, Debian/Ubuntu tend to ship the database servers separately. For Ubuntu, the postgresql package (which requires postgresql-common) package should include /lib/systemd/system/postgresql.service therefore you should be able to sudo systemctl start postgresql
Do you have postgresql (as opposed to postgresql-client) installed?
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.