On 30 Jan 2007, at 03:47, Alessandra Forti wrote:
> Hi Frederic,
>
>> I fully agree.
>
> good!
>
>> I am a big fan of one liners as well.
If you read Lana's code it's not a one liner as it has to do some
rather complex sweeps through the DPNS namespace - Lana's also done
rather a good job of error trapping - something it's harder to do in
one liners. (I'd rather have seen python or perl than C++ though, and
she's making it difficult for herself (all those mallocs), but hey...)
Anyway, I recompiled it from source and ran it on Glasgow's DPM. You
can get that binary from
http://www.physics.gla.ac.uk/~graeme/misc/UpdateACLForMySQL
if you decide you trust me more ;-)
Fiddly notes:
Error output seems to go to a file called
UpdateACLForMySQL_logfile.log (rather than being printed to STDERR).
When the application runs successfully you'll get some STDOUT like this:
svr018:~# ./UpdateACLForMySQL
value of groupname=atlas/Role=lcgadmin
value of gid=117
after update acl and rescode=0
parent_fileid=2308 and=56
end of loop
and log output like this
svr018:~# cat UpdateACLForMySQL_logfile.log
Log file generated by user root from machine
svr018.gla.scotgrid.ac.uk at 31/01/07 0:00:54 462255
At 31/01/07 0:00:54 462255, 3. : NO_ERROR in RecreateConfigFile
At 31/01/07 0:00:54 468551, main : Connected to MySQL server
successfully
At 31/01/07 0:00:54 469184, main : Getting the gid atlas/
Role=lcgadmin for the acl was found and is equal to 117
At 31/01/07 0:00:54 470077, main : Getting the root_fileid for /dpm/
gla.scotgrid.ac.uk/home/atlas/generated was successful and is equal
to 2307
At 31/01/07 0:00:54 878286, main : Updating all the acl was successful
At 31/01/07 0:00:54 878385, main : Application successfully terminated
Finally, there is something a little weird going on. The "root"
directory path seems to get its ACL owner/group changed in some
strange way, although the DPNS namespace UID/GID changes stays the same.
Here's an example:
dpns-getacl before running the script:
svr018:~# dpns-getacl /dpm/gla.scotgrid.ac.uk/home/atlas/dq2
# file: /dpm/gla.scotgrid.ac.uk/home/atlas/dq2
# owner: /C=UK/O=eScience/OU=Cambridge/L=UCS/CN=frederic brochu
# group: atlas
user::rwx
group::rwx #effective:rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x
then after:
svr018:~# dpns-getacl /dpm/gla.scotgrid.ac.uk/home/atlas/dq2/
# file: /dpm/gla.scotgrid.ac.uk/home/atlas/dq2/
# owner: /C=CH/O=CERN/OU=GRID/CN=Piotr Nyczyk 6217
# group: lhcb
user::rwx
group::rwx #effective:rwx
group:atlas/Role=production:rwx #effective:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:atlas/Role=production:rwx
default:mask::rwx
default:other::r-x
So somehow the owner and group changed in the ACL, however not in the
dpns namespace!
Marco also ran the script on his Melbourne T2 and saw a similar
effect. I'll bring this up with the DPM support team, but it's
fixable with dpns-chown, e.g.,
svr018:~# dpns-getacl /dpm/gla.scotgrid.ac.uk/home/atlas/generated
# file: /dpm/gla.scotgrid.ac.uk/home/atlas/generated
# owner: /C=CH/O=CERN/OU=GRID/CN=Piotr Nyczyk 6217
# group: biomed
user::rwx
group::rwx #effective:rwx
group:atlas/Role=lcgadmin:rwx #effective:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:atlas/Role=lcgadmin:rwx
default:mask::rwx
default:other::r-x
svr018:~# dpns-ls -dl /dpm/gla.scotgrid.ac.uk/home/atlas/generated
drwxrwxr-x 58 107 103 0 Jan 31 23:42 /dpm/
gla.scotgrid.ac.uk/home/atlas/generated
svr018:~# dpns-chown 107 /dpm/gla.scotgrid.ac.uk/home/atlas/generated
svr018:~# dpns-getacl /dpm/gla.scotgrid.ac.uk/home/atlas/generated
# file: /dpm/gla.scotgrid.ac.uk/home/atlas/generated
# owner: /C=UK/O=eScience/OU=QueenMaryLondon/L=Physics/CN=kondo gnanvo
# group: atlas
user::rwx
group::rwx #effective:rwx
group:atlas/Role=lcgadmin:rwx #effective:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:atlas/Role=lcgadmin:rwx
default:mask::rwx
default:other::r-x
So, use the dpns-ls command to get the UID of the person who really
owns the file.
Final note, looking at the SQL statements which are/can be
constructed by the code it's actually highly unlikely that you could
break your DPM. The worst you could probably do is add unauthorised
access by mistake, e.g., allowing dteam to write into the atlas area
or vice versa. But, yes, take a backup first...
Cheers
Graeme
--
Dr Graeme Stewart - http://wiki.gridpp.ac.uk/wiki/User:Graeme_stewart
GridPP DM Wiki - http://wiki.gridpp.ac.uk/wiki/Data_Management
ScotGrid - http://www.scotgrid.ac.uk/ http://scotgrid.blogspot.com/
|