/etc/iraf/irafroot is inappropriate for site-shared installations

[WRSomsky]

/etc/iraf/irafroot is an inappropriate place to store the irafroot info when
iraf is being installed in a central NFS mounted software area and shared
among multiple workstations. One should NOT have to install an /etc/iraf/irafroot
file per workstation nor a per user ~/.iraf/irafroot file per user. When
installing w/ an installation prefix, iraf should be looking in $(prefix)/etc/iraf/irafroot
(or some equivalent) for this information.

[olebole]

The installation is actually configured by patching mkiraf.sh, setup.sh and ecl.sh resp. irafcl.sh to set the iraf root in the installation, so that these commands work without etc/iraf/irafroot. What would not work are the command line xc, mkpkg etc. (but they should work from within IRAF). In any case, they can get working by setting the iraf environment variable properly.

One problem here is that f.e. /usr/etc (for prefix /usr, i.e. for a system installation as a Debian package) is not suitable for configuration by the Linux filesystem hierarchy.

For a central NFS installation, one would need to adjust the clients anyway: at least, PATH needs to be adjusted to include the bindir(s) from the NFS tree. Why would one not adjust either the iraf environment variable here, or set /etc/iraf/irafroot? The place after mounting via NFS in any case cannot be pre-determined during the installation, as the actual mount point is not known at this time.

If you have however a patch that is flexible enough to resolve all cases, I am happy to apply it.

[WRSomsky]

In our use case, we have a central NFS directory mounted at /astro/apps9/ on each
workstation, w/in which is opt/iraf, opt/tui, opt/yabba, opt/dabba, opt/doo, etc...
each w/ their own bin/, lib/ and other directories w/in that. If a user wants to
use one of these packages, they modify their environment appropriately. Ideally,
this would simply be to just add /astro/apps9/opt/iraf/bin (for example) to their
path. It starts to get messy when they have to source some setup script w/in
their .bash/.cshrc file like 'source /astro/apps9/opt/iraf/lib/setup.csh' or
such. It gets really messy if they have to manually create files like
$HOME/.iraf/irafroot (though I admit, I've not looked at the user iraf setup scripts
yet) The route of creating an /etc/iraf/irafroot in system-space on every workstation that a user might want to run iraf on is, in my book "right-out", to quote from Monty Python and the Holy Grail. :-)

I've got a couple ideas of what might be worthy additions to help w/ this, but
let me think on it for a bit -- I'd like any suggestions I make to be at least three-quarters baked before proposing it.

[olebole]

The problem here is that during installation it is not known that the IRAF root is /astro/apps9/opt/iraf/ at the end. The only thing they need to set is the iraf environment variable, which should point to the root of the installation (with trailing slash, i.e. export iraf=/astro/apps9/opt/iraf/. As said, as long as one is just a user (i.e. only using the shell), even this is not required; the variable can be set in the top of

iraf/unix/hlib/ecl.sh

Lines 10 to 11 in 5c0a2a7

	# Determine IRAF root directory (value set in install script).
	d_iraf=/iraf/iraf/

For a NFS install, this should be overwritten with the final place, easiest with an additional step

$ make config iraf=/where/iraf/will/be/on/the/clients/ hlib=/where/the/scripts/actually/reside

with the proper values of iraf and hlib.

[WRSomsky]

One issue related to this I ran into during installation was the following: If you are using 'make prefix=.... install' as a non-root user (but you do have permission to write to $prefix/..), it *still* tries to install the file /etc/iraf/irafroot (no $prefix). I believe that was a fatal error, preventing the install from completing -- though I should double check that.

…

On Fri, Sep 22, 2023, 10:54 Ole Streicher ***@***.***> wrote: The problem here is that during installation it is not known that the IRAF root is /astro/apps9/opt/iraf/ at the end. The only thing they need to set is the iraf environment variable, which should point to the root of the installation (with trailing slash, i.e. export iraf=/astro/apps9/opt/iraf/. As said, as long as one is just a user (i.e. only using the shell), even this is not required; the variable can be set in the top of https://github.com/iraf-community/iraf/blob/5c0a2a736e4a7104cc254e71c06e3e65fc6df65b/unix/hlib/ecl.sh#L10-L11 For a NFS install, this should be overwritten with the final place, easiest with an additional step $ make config iraf=/where/iraf/will/be/on/the/clients/ hlib=/where/the/scripts/actually/reside with the proper values of iraf and hlib. — Reply to this email directly, view it on GitHub <#325 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM7N5ISFAUWWCIVRC6VX3ZDX3XGEFANCNFSM6AAAAAA5DJP2KI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[WRSomsky]

Ah... 'make config' ... That's not mentioned on the installation info page, https://iraf-community.github.io/install.html, and I didn't go rooting about in the Makefile to find it. I think that may be just what I need.

[olebole]

I am afraid that you should dig into the Makefile, because your need seems somehow special.

[WRSomsky]

Yeah, finally got a chance to take a look at 'make config'.
That gets done as part of 'make install', so it gets incorporated into the final result.

However there is still the issue that the 'install' target begins with:

        mkdir -p  $(DESTDIR)$(prefix)/lib/iraf ... $(DESTDIR)/etc/iraf

and ends with:

        echo $(prefix)/lib/iraf/ > $(DESTDIR)/etc/iraf/irafroot

So it always tries to write to /etc/... and fails

$(DESTDIR) isn't the solution for this, as that is for things like the Andrew filesystem that have an independant prefix for accessing a writable version of the filesystem. You can see this in the leading directories of that first command.

It would probably be sufficient remove the /etc mkdir from that first command, place it before the /etc echo and mark them both 'fail-able' by adding a '-' prefix thusly:

        -mkdir -p $(DESTDIR)/etc/iraf
        -echo $(prefix)/lib/iraf/ > $(DESTDIR)/etc/iraf/irafroot

though it still makes me uncomfortable that it's trying to write into /etc at all.

Myself, I would rather see it write to $(prefix)/etc/... and have the installing user be responsible for copying/linking it into /etc/ if it is really needed. But that's me.

[olebole]

I feel a bit unlucky with make them "failable". The main use case for the "install" target in the Makefile is a local installation for an end user, and the second use case is for distribution packagers (myself doing this for Debian). Installing on a centrally maintained installation tree seems quite rare these days, and I don't want to make it more complicated as it is at least for the end user.

A potential failure of the installation of /etc/iraf/irafroot due to missing permission is important for end users because they need to know that something went wrong and they have to debug&fix: therefore I am not willing to change the current default behaviour.

What I could imagine is an additional Makefile variable that disables writing the /etc/iraf/irafroot file, which is not set by default and should be set to yes in your use case.