> -----Original Message-----
> From: GRIDPP2: Deployment and support of SRM and local storage
> management [mailto:[log in to unmask]] On Behalf Of Sam
>
> Although, I'm surprised if that's the case, because Ewan ran dpm-dbchk
> against the Oxford db quite a few times (so it shouldn't have any
> "weird" entries left).
>
Well, sort-of. I ran it a fair few times in 'dry run' mode and fixed quite a few of the problems that it found, but never quite had the chance to run it with the DPM offline and in downtime. The downtime we had for the headnode upgrade to SL6 wound up getting completely filled with some mysql authentication fun and games[1] so there wasn't time to use it for a full dpm-dbck run.
Given the mostly well-sortedness of the DPM now though, it should be a relatively straightforward exercise to do a full run in the future, but it will require the DPM being offline. It might be a good thing to do at the next site downtime (hello forthcoming electrical supply work :-) ).
Ewan
[1] So, at least in my experience if you dump the databases from an old DPM (where 'old' is a slightly uncertain quantity since the database had been originally created over a decade earlier) and just blindly reload it into a new one, the schema of the mysql user table is different in ways that make it work for some things and mysteriously fail in extremely strange ways for others. In the end it was fixed by creating a clean DPM headnode on a temporary box, dumping its mysql db, and loading that into the new headnode's mysql with all the mysql permissions stuff disabled. Which was fun.
|