On 27 April 2011 11:28, Santanu Das <[log in to unmask]> wrote:
> regarding krishan's problem: Does anyone know if 'dpmmgr' as dpm-user is now
> hard coded somewhere or it could be any user specified as 'DPM_DB_USER' in
> the site-info.def?
>
I believe it can be any user you need it to be - certainly, all of my
scripts specifically check to make sure what user they should be using
for the DPM DB is called.
Sam
> -Santanu
>
>
>
> On 26/04/11 15:18, Sam Skipsey wrote:
>>
>> On 26 April 2011 15:06, Peter Gronbech<[log in to unmask]>
>> wrote:
>>>
>>> Can anyone offer advice to Krishan please.
>>> Thanks Pete
>>>
>>> --
>>> ----------------------------------------------------------------------
>>> Peter Gronbech Senior Systems Manager and Tel No. : 01865 273389
>>> GridPP Project Manager Fax No. : 01865 273418
>>> Department of Particle Physics,
>>> University of Oxford,
>>> Keble Road, Oxford OX1 3RH, UK E-mail : [log in to unmask]
>>> ----------------------------------------------------------------------
>>>
>>>
>>> Hi All,
>>> We are currently upgrading our SE (SE_dpm_mysql) and are having
>>> some problems when running yaim. We are seeing the following two errors
>>> when running yaim
>>>
>>> /opt/glite/yaim/bin/yaim -c -s EFDA-JET-site-info.def -n SE_dpm_mysql
>>>
>>>
>>> 1. ERROR 1044 (42000) at line 1: Access denied for user
>>> 'root'@'localhost' to database 'dpm_db'
>>>
>>> our DPM_HOST, MYSQL_PASSWORD, DPM_DB_PASSWORD are defined in our
>>> site-info.def file
>>>
>> That's a bit odd. Can they log into the database themselves as root?
>> They need to check what the access permissions are for the root user
>> on the database. (Is the MySQL server on the same host as the DPM?)
>>
>>> 2. Error while upgrading DPNS schema
>>>
>>> INFO: Upgrading DPNS schema from 300 to 310
>>> DBD::mysql::db do failed: Duplicate column name 'banned' at
>>> ./cns-db-300-to-310 line 14.
>>> Issuing rollback() for database handle being DESTROY'd without explicit
>>> disconnect().
>>> ERROR: Error upgrading DPNS schema
>>> ERROR: Error during the execution of function:
>>> config_DPM_upgrade_mysql
>>> ERROR: Error during the
>>> configuration.Exiting. [FAILED]
>>> ERROR: One of the functions returned with error without specifying
>>> it's nature !
>>>
>> This happened because the schema update had previously been attempted
>> (hence the banned column existing), but the final steps of altering
>> the schema version encoded in the database failed (so YAIM doesn't
>> know that the schema was updated and tries to update it again the next
>> time it's run).
>> There was some discussion about this in the dpm-user-forum list (and
>> I've previously mentioned it to the storage group), the summary of
>> which is: some older versions of DPM used different names for the
>> columns that hold the schema version (major_number instead of major,
>> etc), which causes newer schema updates to fail to update the schema.
>> You can fix this by doing:
>>
>> USE cns_db;
>> ALTER TABLE schema_version CHANGE major_number major INTEGER(11);
>> ALTER TABLE schema_version CHANGE minor_number minor INTEGER(11);
>> ALTER TABLE schema_version CHANGE patch_number patch INTEGER(11);
>>
>> to fix the table names, and then:
>>
>> UPDATE schema_version SET major = 3, minor = 1, patch = 0;
>>
>> to set the schema to the version it should be (since the banned column
>> exists).
>>
>>
>> Sam
>>
>>
>>> Have anybody come across these issues, while upgrading?
>>>
>>>
>>> Many Thanks
>>>
>>>
>>> krishan
>>>
>
|