Does Gadgetron support external xml config files not stored in $GADGETRON_HOME/config ?
Right now it seems to me that the mriclient only sends the filename to the Gadgetron server instance and the latter appends $GADGETRON_HOME/config to it in order to build the complete path to the config file.
Unless a workaround exists, this poses a problem to us where the $GADGETRON_HOME location on the cluster (/usr/local/gadgetron by default on Linux) is not user accessible due to restricted admin rights.
Thoughts ?
Ghis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, it is either a problem or a design feature depending on your point of
view.
My thoughts were that people should not be able to add/change
configurations thus hacking a reconstruction system if they don't have the
appropriate privileges. For instance, somebody could add a grappa.xml which
is different from the system one and change the behavior for other user
without being aware of the consequences.
For such situations where people want to "mess" with the installation they
should do a local install (in their home) of the gadgetron and run that.
They can change the XML files in there.
That said, although I did it that way on purpose, there may be reasons to
change it.
Does Gadgetron support external xml config files not stored in
$GADGETRON_HOME/config ?
Right now it seems to me that the mriclient only sends the filename to the
Gadgetron server instance and the latter appends $GADGETRON_HOME/config to
it in order to build the complete path to the config file.
Unless a workaround exists, this poses a problem to us where the
$GADGETRON_HOME location on the cluster (/usr/local/gadgetron by default on
Linux) is not user accessible due to restricted admin rights.
Also, if people would like a setup where such "hacking" is possible, they
can just make $GADGETRON_HOME/config world writable or writable for a group
with those privileges.
Well, it is either a problem or a design feature depending on your point of
view.
My thoughts were that people should not be able to add/change
configurations thus hacking a reconstruction system if they don't have the
appropriate privileges. For instance, somebody could add a grappa.xml which
is different from the system one and change the behavior for other user
without being aware of the consequences.
For such situations where people want to "mess" with the installation they
should do a local install (in their home) of the gadgetron and run that.
They can change the XML files in there.
That said, although I did it that way on purpose, there may be reasons to
change it.
On Thu, Jun 5, 2014 at 11:47 AM, Ghislain Vaillant ghisvail@users.sf.net
wrote:
Does Gadgetron support external xml config files not stored in
$GADGETRON_HOME/config ?
Right now it seems to me that the mriclient only sends the filename to the
Gadgetron server instance and the latter appends $GADGETRON_HOME/config to
it in order to build the complete path to the config file.
Unless a workaround exists, this poses a problem to us where the
$GADGETRON_HOME location on the cluster (/usr/local/gadgetron by default on
Linux) is not user accessible due to restricted admin rights.
Thoughts ?
Ghis
support for xml Gadgetron config files outside $GADGTRON_HOME/config
what we do is install gadgetron somewhere that is shared by all the nodes:
e.g. GADGETRON_HOME=/users/inatisj/gadgetron
set this with the CMAKE_INSTALL_PREFIX
Does Gadgetron support external xml config files not stored in $GADGETRON_HOME/config ?
Right now it seems to me that the mriclient only sends the filename to the Gadgetron server instance and the latter appends $GADGETRON_HOME/config to it in order to build the complete path to the config file.
Unless a workaround exists, this poses a problem to us where the $GADGETRON_HOME location on the cluster (/usr/local/gadgetron by default on Linux) is not user accessible due to restricted admin rights.
what we do is install gadgetron somewhere that is shared by all the nodes: e.g. GADGETRON_HOME=/users/inatisj/gadgetron set this with the CMAKE_INSTALL_PREFIX
Sure. You could even symlink everything but the config folder, or cp -R the whole directory, to a user writable location. I just wonderered whether I overlooked a much simpler option.
If this is a design decision, then I'll just let it go.
Thanks,
Ghis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
what we do is install gadgetron somewhere that is shared by all the nodes:
e.g. GADGETRON_HOME=/users/inatisj/gadgetron set this with the
CMAKE_INSTALL_PREFIX
Sure. You could even symlink everything but the config folder, or cp -R
the whole directory, to a user writable location. I just wonderered whether
I overlooked a much simpler option.
If this is a design decision, then I'll just let it go.
Does Gadgetron support external xml config files not stored in $GADGETRON_HOME/config ?
Right now it seems to me that the mriclient only sends the filename to the Gadgetron server instance and the latter appends $GADGETRON_HOME/config to it in order to build the complete path to the config file.
Unless a workaround exists, this poses a problem to us where the $GADGETRON_HOME location on the cluster (/usr/local/gadgetron by default on Linux) is not user accessible due to restricted admin rights.
Thoughts ?
Ghis
Well, it is either a problem or a design feature depending on your point of
view.
My thoughts were that people should not be able to add/change
configurations thus hacking a reconstruction system if they don't have the
appropriate privileges. For instance, somebody could add a grappa.xml which
is different from the system one and change the behavior for other user
without being aware of the consequences.
For such situations where people want to "mess" with the installation they
should do a local install (in their home) of the gadgetron and run that.
They can change the XML files in there.
That said, although I did it that way on purpose, there may be reasons to
change it.
On Thu, Jun 5, 2014 at 11:47 AM, Ghislain Vaillant ghisvail@users.sf.net
wrote:
Also, if people would like a setup where such "hacking" is possible, they
can just make $GADGETRON_HOME/config world writable or writable for a group
with those privileges.
On Thu, Jun 5, 2014 at 12:01 PM, Michael Hansen hansenms@users.sf.net
wrote:
what we do is install gadgetron somewhere that is shared by all the nodes:
e.g. GADGETRON_HOME=/users/inatisj/gadgetron
set this with the CMAKE_INSTALL_PREFIX
--
Souheil Inati, PhD
Staff Scientist
FMRIF/NIMH/NIH/DHHS
souheil.inati@nih.gov
301-402-9409
On 6/5/14, 11:47 AM, "Ghislain Vaillant" ghisvail@users.sf.netamp#103;amp#104;amp#105;amp#115;amp#118;amp#97;amp#105;amp#108;amp#64;amp#117;amp#115;amp#101;amp#114;amp#115;amp#46;amp#115;amp#102;amp#46;amp#110;amp#101;amp#116; wrote:
Does Gadgetron support external xml config files not stored in $GADGETRON_HOME/config ?
Right now it seems to me that the mriclient only sends the filename to the Gadgetron server instance and the latter appends $GADGETRON_HOME/config to it in order to build the complete path to the config file.
Unless a workaround exists, this poses a problem to us where the $GADGETRON_HOME location on the cluster (/usr/local/gadgetron by default on Linux) is not user accessible due to restricted admin rights.
Thoughts ?
Ghis
support for xml Gadgetron config files outside $GADGTRON_HOME/confighttps://sourceforge.net/p/gadgetron/discussion/general/thread/2bb86b13/?limit=25#04b8
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gadgetron/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Sure. You could even symlink everything but the config folder, or cp -R the whole directory, to a user writable location. I just wonderered whether I overlooked a much simpler option.
If this is a design decision, then I'll just let it go.
Thanks,
Ghis
It is a design decision, but we can certainly discuss whether it was a good
one.
We could support some alternative location. Any suggestions for how that
should be specified?
On Thu, Jun 5, 2014 at 12:44 PM, Ghislain Vaillant ghisvail@users.sf.net
wrote: