Backup issues

[vetch101]

Hi all,

I'm loving the latest RC... Thanks for all the hard work!

I've recently created a new domain in ISPCP, and have been happily using the site to host a database driven web-site. I've just checked the backups though, and in the backups directory, there's no sql backup for that domain though all the others appear to be working...

I checked the ispcp-backup-all-mngr.log and found this error:-

mysqldump: Got error: 1045: Access denied for user 'xxxxxxx'@'localhost' (using password: YES) when trying to connect

I've checked the sql_user table in the ISPCP database.
All the other database user passwords are stored in plaintext, whilst the latest one isn't stored plain text...
It looks like a hash of some description, I think...
It may be that this has changed between ispcp versions since I may have only just updated prior to creating the site...

Is this correct?

How can I go about fixing this? If I change the password to plain text, should it work? If I play with the settings for that database in the ISPCP database, what are the potential consequences? And can I break access to the site whilst I try to resolve this...

The only other thing I'm wondering about is - is my password too complex...? It's about 32 alphanumeric characters... Could that have influenced it?

Many thanks in advance for any suggestions...

Cheers,

Jx

[sci2tech]

What version do you use? I fixed this in r1361 (last trunk). also after upgrading to last trunk you must login as administator so all password to be encrypted. Password that is already encrypted will be encrypted again => error so make a backup of that value and rewrite in database after that (login as administrator). Always after upgrading log in as administrator and perform any database update if available.

[vetch101]

(09-30-2008 10:05 PM)sci2tech Wrote:  What version do you use? I fixed this in r1361 (last trunk). also after upgrading to last trunk you must login as administator so all password to be encrypted. Password that is already encrypted will be encrypted again => error so make a backup of that value and rewrite in database after that (login as administrator). Always after upgrading log in as administrator and perform any database update if available.

Thanks for the quick reply...

Is there an easy way to find out which trunk I'm using...?
I'm pretty sure I took one from a couple of weeks ago...

Are you saying that pulling down the latest will fix this?

When I log in as administrator, will it then encrypt all the database passwords? So I'll need to take a copy of the currently (encrypted) password, and then put it back into the database afterwards... Is that correct?

Alternatively, could I change the password in the database back to the plain text password and wait for the stable release?

Will that work as a short term fix?

Cheers,

Jx

[sci2tech]

(09-30-2008 10:26 PM)vetch101 Wrote:  Is there an easy way to find out which trunk I'm using...?

I don`t think it is. Just if you still have donloaded trunk look at changelog file in root of package.

(09-30-2008 10:26 PM)vetch101 Wrote:  Are you saying that pulling down the latest will fix this?

yes

(09-30-2008 10:26 PM)vetch101 Wrote:  When I log in as administrator, will it then encrypt all the database passwords? So I'll need to take a copy of the currently (encrypted) password, and then put it back into the database afterwards... Is that correct?

yes

(09-30-2008 10:26 PM)vetch101 Wrote:  Alternatively, could I change the password in the database back to the plain text password and wait for the stable release?

Only if you downgrade your trunk

(09-30-2008 10:26 PM)vetch101 Wrote:  Will that work as a short term fix?

that is a fix that will be in stable release
Cheers,
Daniel

[vetch101]

(09-30-2008 10:56 PM)sci2tech Wrote:  

(09-30-2008 10:26 PM)vetch101 Wrote:  Is there an easy way to find out which trunk I'm using...?

I don`t think it is. Just if you still have donloaded trunk look at changelog file in root of package.

(09-30-2008 10:26 PM)vetch101 Wrote:  Are you saying that pulling down the latest will fix this?

yes

(09-30-2008 10:26 PM)vetch101 Wrote:  When I log in as administrator, will it then encrypt all the database passwords? So I'll need to take a copy of the currently (encrypted) password, and then put it back into the database afterwards... Is that correct?

yes

(09-30-2008 10:26 PM)vetch101 Wrote:  Alternatively, could I change the password in the database back to the plain text password and wait for the stable release?

Only if you downgrade your trunk

(09-30-2008 10:26 PM)vetch101 Wrote:  Will that work as a short term fix?

that is a fix that will be in stable release
Cheers,
Daniel

Hi,

Once again, thanks for the help...

I'll copy the encrypted password out of the database, update to the latest trunk, log in as admin, run the database update and drop the password back in, then I'll run the backup scripts to make sure that the change has been successful...

I'll post here to let you know how it goes...

Many thanks,

Jx

[sci2tech]

Good luck

[vetch101]

(10-01-2008 02:07 AM)sci2tech Wrote:  Good luck

Hi,

Ok - I've updated to r1363...

I still have the same problem - with just the new password stored as a hash/encrypted file...

I've also logged in as admin, and checked for database upgrades, or updates in the panel, and there don't appear to be any...

What's the next step?

Plus, the other thing I've noticed is that since moving to the latest version (or rather the previous one that I was running prior to this latest update), I was getting periodic outages on some of my sites... When I browsed them, I was just not getting anything showing, they would time out... But other sites on the same server and IP address were working ok...

I tried restarting apache, but it didn't work... They started working again after a reboot, but given I've only been using the latest version for about 2 or 3 days, that's not a great amount of uptime...

I hadn't had that problem before, but I have just migrated servers, so I guess the issue could be related to that...

Cheers,

Jx

---

(10-02-2008 05:44 AM)vetch101 Wrote:  

(10-01-2008 02:07 AM)sci2tech Wrote:  Good luck

Hi,

Ok - I've updated to r1363...

I still have the same problem - with just the new password stored as a hash/encrypted file...

I've also logged in as admin, and checked for database upgrades, or updates in the panel, and there don't appear to be any...

What's the next step?

Plus, the other thing I've noticed is that since moving to the latest version (or rather the previous one that I was running prior to this latest update), I was getting periodic outages on some of my sites... When I browsed them, I was just not getting anything showing, they would time out... But other sites on the same server and IP address were working ok...

I tried restarting apache, but it didn't work... They started working again after a reboot, but given I've only been using the latest version for about 2 or 3 days, that's not a great amount of uptime...

I hadn't had that problem before, but I have just migrated servers, so I guess the issue could be related to that...

Cheers,

Jx

Ok - so I've just run the ispcp-backup-all script... now all the backups are failing to log in on the mysqldump... Is there a manual way to generate the hashes?

Cheers,

Jx

[vetch101]

Hi all,

Just so you know - I logged into the admin panel and copied the old plain text passwords into the change password field of each of the database users...
As I did that, they were converted into the hashes/encrypted form, and now the ispcp-backup-all script is running through without any errors...

Will this cause problems for me when I next need to upgrade the ISPCP? Will all the (currently encrypted) passwords be re-encrypted, ending up with the wrong values in the database?

Once again, many thanks for all the help,

Jx

[sci2tech]

(10-02-2008 05:44 AM)vetch101 Wrote:  I tried restarting apache, but it didn't work... They started working again after a reboot, but given I've only been using the latest version for about 2 or 3 days, that's not a great amount of uptime...

Next time try to restart with apache reload or apache force-reload instead restart. Nothing was modified in the way that main domain is processed from rc6. Also i don`t have this issue.

(10-02-2008 05:44 AM)vetch101 Wrote:  Ok - so I've just run the ispcp-backup-all script... now all the backups are failing to log in on the mysqldump... Is there a manual way to generate the hashes?

If you have a backup of database before update to hashed version you can drop table sql_user and mail_users and load versions from backup. Then delete from table config CRITICAL_UPDATE_REVISION record. After that log in as administrator, and you will see a message "critical update has been performed" on first login and password are encrypted. Try then manually run backup script and see if any new error appear.
Other way is to manually change from control panel as client every sql password.
Please see that in r1363 there are some modification to ispcp.conf. you have to add them manually

[vetch101]

(10-02-2008 06:56 AM)sci2tech Wrote:  

(10-02-2008 05:44 AM)vetch101 Wrote:  I tried restarting apache, but it didn't work... They started working again after a reboot, but given I've only been using the latest version for about 2 or 3 days, that's not a great amount of uptime...

Next time try to restart with apache reload or apache force-reload instead restart. Nothing was modified in the way that main domain is processed from rc6. Also i don`t have this issue.

(10-02-2008 05:44 AM)vetch101 Wrote:  Ok - so I've just run the ispcp-backup-all script... now all the backups are failing to log in on the mysqldump... Is there a manual way to generate the hashes?

If you have a backup of database before update to hashed version you can drop table sql_user and mail_users and load versions from backup. Then delete from table config CRITICAL_UPDATE_REVISION record. After that log in as administrator, and you will see a message "critical update has been performed" on first login and password are encrypted. Try then manually run backup script and see if any new error appear.
Other way is to manually change from control panel as client every sql password.
Please see that in r1363 there are some modification to ispcp.conf. you have to add them manually

Hi Sci,

Once again - thanks very much for your help with this one! Much appreciated...

Firstly, I'll bear in mind the apache reload/force reload option... Sounds like it's definitely worth trying...

Secondly, I decided to do it through the control panel for every client (I don't have that many, and I thought it would be easier than pulling out of backups...

Ah - modifications to ispcp.conf for r1363 - I hadn't seen that...
Excuse my ignorance, but where will I find the relevant information about the changes I need to make?

Cheers,

Jx