Ok, we’ll set up a TeamViewer session this weekend.
I’ve sent you a private message to tell you about it
I would prefer to continue the chat session rather than Teanviewer session, thanks. Just let me know when you are around, and we can chat “live” …
Understood, i just ran out of “live chat” options.
I need to see things and then react, but ok…
First thing to do is add the ip-addresses of thr containers to ypur /etc/hosts file:
Then restart the containers.
Then go to phpmyadmin and add a proper user:
- Click on the correct database and then on ip_users
- Check that the password for the user was properly encrypted
- The password has to be something simple like ‘12345’
So now you have:
- proper ip-addresses for the containers
- containers restarted
- password properly set for the ‘a@a.com’ user
If everything else fails, start again.
Then i would have needed to see the installation screen by screen, because something goes wrong during installation and it’s un-replicatable in the development environment
I have time off and on to “live-chat” about these steps, in approximately 8 hours
Hi,
I ran your scripts, and added the following to /etc/hosts
## DOCKERHERO HOSTS BLOCK START ##
172.25.0.12 invoiceplane-nginx
172.25.0.11 invoiceplane-php
172.25.0.16 invoiceplane-dbadmin
172.25.0.13 invoiceplane-db
Do I have to restart my server for this work? Probaly not, as I can ping the above names.
I did not restart my server, but restarted the containers as requested.
I added a user, but:
- Check that the password for the user was properly encrypted
How? Please be specific.
The password field is not set to encrypt, should it be? The type is currently varchar(60).
Sorry wont be able to see you in 8hrs, going out (my 6pm)… will continue tomorrow hopefully …
How? Please be specific.
Screenshot the record from the ip_users table
In ipconfig.php: Should DB_HOSTNAME='invoiceplane_db' not be DB_HOSTNAME='invoiceplane-db' as that is the name in /etc/hosts?
Interesting thing I noticed:
Awhile back you made me change my database location to create a new one, i.e database folder, if you notice it has been given user systemd-coredump as well as all the files in it, is this correct?
drwxr-xr-x 5 casaos casaos 101 Mar 12 11:41 assets
-rw-r--r-- 1 casaos casaos 588 Mar 12 11:41 composer.json
-rw-r--r-- 1 casaos casaos 85K Mar 12 11:41 composer.lock
-rw-r--r-- 1 casaos casaos 7.2K Mar 12 11:41 CONTRIBUTING.md
drwxr-xr-x 6 systemd-coredump systemd-coredump 4.0K Aug 5 10:28 database
-rw-r--r-- 1 casaos casaos 2.5K Aug 4 08:50 docker-compose.yml
-rw-r--r-- 1 casaos casaos 697 Mar 12 11:41 favicon.ico
-rw-r--r-- 1 casaos casaos 5.0K Mar 12 11:41 Gruntfile.js
-rwxr-xr-x 1 casaos casaos 496 Aug 5 10:16 hosts.sh
-rw-r--r-- 1 casaos casaos 443 Mar 12 11:41 htaccess
-rwxr-xr-x 1 casaos casaos 11K Mar 12 11:41 index.php
-rw-r--r-- 1 casaos casaos 1.6K Aug 5 10:35 ipconfig.php
-rw-r--r-- 1 casaos casaos 1.5K Mar 12 11:41 ipconfig.php.example
-rwxr-xr-x 1 casaos casaos 5.0K Mar 12 11:41 LICENSE.txt
-rw-r--r-- 1 root root 54 Aug 1 10:05 {out}
-rw-r--r-- 1 casaos casaos 1.3K Mar 12 11:41 package.json
-rwxr-xr-x 1 casaos casaos 4.5K Mar 12 11:41 README.md
drwxr-xr-x 3 casaos casaos 28 Mar 12 11:41 resources
-rw-r--r-- 1 casaos casaos 25 Mar 12 11:41 robots.txt
-rw-r--r-- 1 casaos casaos 104 Mar 12 11:41 SECURITY.md
drwxr-xr-x 6 casaos casaos 204 Jul 23 09:16 uploads
drwxr-xr-x 20 casaos casaos 4.0K Mar 12 11:43 vendor
-rw-r--r-- 1 casaos casaos 123K Mar 12 11:41 yarn.lock
it has been given user
systemd-coredumpas well as all the files in it
I thought that user was shown after a system crash. Keep using it for now, but be prepared to chown it to another user
The password for the user wasn’t properly encrypted. It’s still 12345, which is wrong
Should
DB_HOSTNAME='invoiceplane_db'not beDB_HOSTNAME='invoiceplane-db'as that is the name in /etc/hosts
Yes, correct, hostname should be DB_HOSTNAME='invoiceplane-db'
So what must I do to encrypt it …
So what must I do to encrypt it …
-
Edit that record from the
ip_userstable -
at the
user_passwordfield, find ‘password_hash’ -
fill the user_password field with ‘12345’
-
Next: fill the
user_psaltfield:
Press “go”
If you log in with ‘a@a.com’ and password ‘12345’
you can log in without problems:
Tried exactly as you said, but still cannot log in.
What are those magic characters that I just typed into the user_psalt field. You did not elaborate. I just typed in your ones above.
When I type in the password 12345 and press Login nothing happens except the 5 stars in the password field get replaced by 7 stars …
What are those magic characters that I just typed into the
user_psaltfield
12345 gets encrypted. The salt is, to encrypt the password a bit more
Open ip_users in the phpmyadmin
Edit the user
Paste this password:
$2y$10$1Wg8riqAWJ7KtF1EYvS/deYj4aEsmnWbZ1Dtw0sM5s7hxDeSJxjuy
use a different salt! from above screenshot
bKGFrMBzy3
let’s hope that one works…
final checklist:
- edit ip_user record
user_passwordfield:12345- selectbox to
password_hashfunction user_psaltfield filled withbKGFrMBzy3
Save
The user_password field will contain an encrypted password and not just plain 12345
If this doesn’t work: delete all tables and re-install
No Difference with that salt … my password hash was the same as your one posted anyway.
I will delete the whole ip folder and start again, this is very frustrating.
If this doesn’t work: delete all tables and re-install
How?
The only takeaway I get from this is how to backup the database …
So now having started a fresh database, I can get in fine and do everything I need. (I have to re-do what I had setup in the past)
However to save database I need to get into phpMyAdmin and I can’t.
What was the steps to fix that again?
This is the current error:
I am using the passwords from here:
- PMA_USER=root
- PMA_PASSWORD=ipdevdb
Nevermind, found it:
Change the setting in configmuser.inc.php to $cfg['Servers'][$i]['host'] = 'db';
1 Like
So now having started a fresh database, I can get in fine and do everything I need
So everything worked out?
That’s great!
Yep, many thanks for the help.
I presume the localhost issue will be fixed in an upgrade?
I presume the
localhostissue will be fixed in an upgrade
Yes. We’re working on 1.6.1 beta 3 and it’s solved in that version.
After that, of course it’s solved in version 1.6.1