Jump to content

Using DDEV for local ProcessWire development (tips & tricks)


bernhard
 Share

Recommended Posts

  • 3 weeks later...

For several days I've had issues with connecting to my host from within the ddev container when using RockShell for a quick

php rockshell db-pull staging

I got the following error:

Quote

Received disconnect from ... port 22:2: Too many authentication failures
Disconnected from ... port 22

Turned out that the problem was that I had too many SSH keys in my container (4) and the webhost seemed to block the request before ddev could use the correct key.

The solution was to put only the two necessary keys in a dedicated folder ~/.ssh/ddev and then provide that folder as parameter on ddev auth ssh:

ddev auth ssh -d ~/.ssh/ddev

It have been tough days having to restore the database manually from staging to my local development 😄 

I guess nobody will ever have problems with this as it's a quite specific situation but maybe it helps someone googling for it...

  • Like 1
Link to comment
Share on other sites

Not sure how rockshell works, but I find SSH's config file very helpful. Perhaps something like this in ~/.ssh/config this could help here (if not already in use)?

Host *
    IdentitiesOnly=yes
    
Host staging
    IdentityFile ~/.ssh/<YOUR STAGING KEY FILE>
    #User bernhard ## Uncomment and change if server account doesn't match your local name
    #Port 22 ## Uncomment and change if server not listening on port 22

Any time an ssh connection is attempted to staging, it should use the correct identity file (or files if you add more IdentityFile lines,) rather than have SSH try all your keyfiles until the server complains.

Link to comment
Share on other sites

Hey @netcarver thx ssh config files are great for sure, but they do not work when using DDEV because you are in a container and not on your host's filesystem with the ssh config file in place.

That's why ddev has the ability to do "ddev auth ssh" where it grabs all SSH keys from the host and copies them into the container. Then you can do ssh magic in the container just as if you were working on the host. Almost. The issue I explained above was only occuring inside the container. On the host machine "ssh foo" just worked because the ssh config file was in place.

Hope that makes sense.

RockShell's db-pull command uses exec() to connect to the remote server via SSH, then it creates the remote dump, it copies it to the local filesystem, then it restores the dump and then it triggers all migrations.

That way you can quickly develop locally, do anything you want, try crazy stuff and if you want to start over you just do "php rockshell db-pull staging" and you get a clean version that you have on your remote. Same goes if you added a feature locally and you want to make sure that everything works when pushing to remote. Then you can do a db-pull as well and fire all migrations to see if you forgot anything.

Hope that makes sense as well.

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

It's just a link to the docs, but maybe it's not so obvious for some that you can even use DDEV to share the project on your local network, so you (or hackers) can access the site from a mobile phone or any other device: https://ddev.readthedocs.io/en/latest/users/topics/sharing/#exposing-a-host-port-and-providing-a-direct-url

ddev config --host-webserver-port=8080 --bind-all-interfaces

 

  • Like 1
Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...