That's right. Anyone using the ReST API needs to have the credentials and could use those to do other queries as well. The ReST API follows a role authorization model, so you can restrict what a user might do. But the least powerful role "Monitor" still allows read access to all URLs while restricting all POST, PUT, DELETE ops. We have an item somewhere on our roadmap to allow for a more granular definition of what a user might read, but no real schedule for that today.
 
Mit freundlichen Grüßen / Kind regards

IBM Spectrum Scale
  •  
  •      
  • Dr. Alexander Wolf-Reber
    Spectrum Scale Release Lead Architect
    Department M069 / Spectrum Scale Software Development

    +49-7034-2745404
    a.wolf-re...@de.ibm.com

IBM Deutschland Research & Development GmbH / Vorsitzende des Aufsichtsrats: Matthias Hartmann / Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

 
 
----- Original message -----
From: "Buterbaugh, Kevin L" <kevin.buterba...@vanderbilt.edu>
Sent by: gpfsug-discuss-boun...@spectrumscale.org
To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org>
Cc:
Subject: Re: [gpfsug-discuss] Get list of filesets_without_runningmmlsfileset?
Date: Mon, Jan 21, 2019 5:36 PM
 
Hi All,
 
I just wanted to follow up on this thread … the only way I have found to obtain a list of filesets and their associated junction paths as a non-root user is via the REST API (and thanks to those who suggested that).  However, AFAICT querying the REST API via a script would expose the username / password used to do so to anyone who bothered to look at the code, which would in turn allow a knowledgeable and curious user to query the REST API themselves for other information we do not necessarily want to expose to them.  Therefore, it is not an acceptable solution to us.
 
Therefore, unless someone responds with a way to allow a non-root user to obtain fileset junction paths that doesn’t involve the REST API, I’m afraid I’m at a dead end in terms of making our quota usage Python script something that I can share with the broader community.  It just has too much site-specific code in it.  Sorry…
 
Kevin
 
P.S.  In case you’re curious about how the quota script is obtaining those junction paths … we have a cron job that runs once per hour on the cluster manager that dumps the output of mmlsfileset to a text file, which the script then reads.  The cron job used to just run once per day and used to just run mmlsfileset.  I have modified it to be a shell script which checks for the load average on the cluster manager being less than 10 and that there are no waiters of more than 10 seconds duration.  If both of those conditions are true, it runs mmlsfileset.  If either are not, it simply exits … the idea being that one or both of those would likely be true if something were going on with the cluster manager that would cause the mmlsfileset to hang.
 
I have also modified the quota script itself so that it checks that the junction path for a fileset actually exists before attempting to stat it (duh - should’ve done that from the start), which handles the case where a user would run the quota script and it would bomb off with an exception because the fileset was deleted and the cron job hadn’t run yet.  If a new fileset is created, well, it just won’t get checked by the quota script until the cron job runs successfully.  We have decided that this is an acceptable compromise.
 
On Jan 15, 2019, at 8:46 AM, Marc A Kaplan <makap...@us.ibm.com> wrote:
 
Personally, I agree that there ought to be a way in the product.

In the meawhile, you no doubt already have some ways to tell your users where to find their filesets as pathnames.
Otherwise, how are they accessing their files?

And to keep things somewhat sane, I'd bet filesets are all linked to one or small number of well known paths in the filesystem.
Like  /AGpfsFilesystem/filesets/...  Plus you could add symlinks and/or as has been suggested post info extracted from mmlsfileset and/or mmlsquota.

So as a practical matter, is this an urgent problem...?  Why?  How?
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
 
Kevin Buterbaugh - Senior System Administrator
Vanderbilt University - Advanced Computing Center for Research and Education
 
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
 

_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

Reply via email to