I guess we'll need to try both locations now: 

/etc/imapd.conf (or files in /etc/imapd.d ?) if the user did any custom configurations, and /etc/usr/imapd.conf for the system default.

(In reply to Stefan Hundhammer from comment #1)
> I guess we'll need to try both locations now: 

Yep, we have a process/library for this. It's a common problem in today's Linux.

But the question actually is whether to keep NFS Server / Client modules.

I am a bit confused why that error message appears. AFAICS in that test it appears while initializing "yast2 nfs-server".

That works without problems on my up-to-date TW VM. None of my systems, including that TW VM, has either /etc/imapd.conf or /usr/etc/imapd.conf; there is no IMAP installed.

I don't get that message, which should be the normal thing; after all, IMAP is purely optional.

Created attachment 871422 [details]
Error pop-up in yast nfs-server

"Unable to read the /etc/imapd.conf file.
 Setting the default setting for the domain to 'localdomain'."

The y2logs in that OpenQA test contain only the installation, not any of those YaST modules called in the installed system.

Error location:

https://github.com/yast/yast-nfs-server/blob/master/src/include/nfs_server/ui.rb#L266-L280

>    def BeginDialog
>      Wizard.SetScreenShotName("nfs-server-1-start")
>
>      start_nfs_server = NfsServer.start
>      domain = Convert.to_string(
>        SCR.Read(path(".etc.idmapd_conf.value.General.Domain"))
>      )
>      if domain == nil
>        Popup.Message(
>          _(
>            "Unable to read the /etc/idmapd.conf file. Setting the default setting for the domain to 'localdomain'."
>          )
>        )
>        domain = "localdomain"
>      end


That's not even a hard error; it's just an informational message that needs to be confirmed.

Duh; I misread this as "imapd.conf" all the time. It's really "idmapd.conf"; as in "ID map". /etc/idmapd.conf is indeed present on my Leap 15.5 and on my TW VM. It belongs to package nfs-client.

My bad. Sorry.

Still, that file is used only to read the default for the "domainname" field in the UI of YaST NFS server. The user can override it if desired.


% cat /etc/idmapd.conf
 
[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nobody

Created attachment 871426 [details]
Screenshot: YaST NFS Server main dialog

But it's indeed a good question how useful those YaST modules are these days, both yast2-nfs-server and yast2-nfs-client. They will both need quite some changes for the usr-merge:

src/yast 81 % grep -E 'SCR\.(Read|Write).*etc' yast-nfs-*/**/*.rb | sed -e 's/^/> /'
> yast-nfs-client/src/modules/Nfs.rb:      Convert.to_string(SCR.Read(path(".etc.idmapd_conf.value.General.Domain")))
> yast-nfs-client/src/modules/Nfs.rb:        SCR.Write(path(".etc.idmapd_conf.value.General.Domain"), @idmapd_domain)
> yast-nfs-client/src/modules/Nfs.rb:        SCR.Write(path(".etc.idmapd_conf"), nil)
> yast-nfs-server/src/include/nfs_server/ui.rb:        SCR.Read(path(".etc.idmapd_conf.value.General.Domain"))
> yast-nfs-server/src/modules/NfsServer.rb:        SCR.Read(path(".etc.exports")),
> yast-nfs-server/src/modules/NfsServer.rb:          SCR.Read(path(".etc.idmapd_conf.value.General.Domain"))
> yast-nfs-server/src/modules/NfsServer.rb:      if !SCR.Write(path(".etc.exports"), @exports)
> yast-nfs-server/src/modules/NfsServer.rb:        if !SCR.Write(path(".etc.idmapd_conf.value.General.Domain"), @domain) ||
> yast-nfs-server/src/modules/NfsServer.rb:            !SCR.Write(path(".etc.idmapd_conf"), nil)

Moving to our Trello task queue.

Hi, any chance you're looking at this soon? SR#1133228 has been waiting in staging for almost two months now and I'm wondering whether I should decline it while this issue gets addressed.

Ana, please, don't be blocked by YaST here. Just release it. If someone uses YaST and it's broken we'll find out later. The YaST NFS Server has lower priority than other team tasks now.

There was a new SR with nfs-utils (https://build.opensuse.org/request/show/1169773), any chance you can fix yast2-nfs?

(In reply to Lukas Ocilka from comment #13)
> Ana, please, don't be blocked by YaST here. Just release it. If someone uses
> YaST and it's broken we'll find out later. The YaST NFS Server has lower
> priority than other team tasks now.

openQA tests yast nfs server and client modules and that test fails, so it's not possible to "just release it", something needs to be done explicitly.

(In reply to Stefan Hundhammer from comment #10)
> But it's indeed a good question how useful those YaST modules are these
> days, both yast2-nfs-server and yast2-nfs-client. They will both need quite
> some changes for the usr-merge:
> 
> src/yast 81 % grep -E 'SCR\.(Read|Write).*etc' yast-nfs-*/**/*.rb | sed -e
> 's/^/> /'
> > yast-nfs-client/src/modules/Nfs.rb:      Convert.to_string(SCR.Read(path(".etc.idmapd_conf.value.General.Domain")))
> > yast-nfs-client/src/modules/Nfs.rb:        SCR.Write(path(".etc.idmapd_conf.value.General.Domain"), @idmapd_domain)
> > yast-nfs-client/src/modules/Nfs.rb:        SCR.Write(path(".etc.idmapd_conf"), nil)
> > yast-nfs-server/src/include/nfs_server/ui.rb:        SCR.Read(path(".etc.idmapd_conf.value.General.Domain"))
> > yast-nfs-server/src/modules/NfsServer.rb:        SCR.Read(path(".etc.exports")),
> > yast-nfs-server/src/modules/NfsServer.rb:          SCR.Read(path(".etc.idmapd_conf.value.General.Domain"))
> > yast-nfs-server/src/modules/NfsServer.rb:      if !SCR.Write(path(".etc.exports"), @exports)
> > yast-nfs-server/src/modules/NfsServer.rb:        if !SCR.Write(path(".etc.idmapd_conf.value.General.Domain"), @domain) ||
> > yast-nfs-server/src/modules/NfsServer.rb:            !SCR.Write(path(".etc.idmapd_conf"), nil)

For yast-nfs-server:

/etc/exports didn't change, for /etc/idmapd.conf it apparently only reads the domain which has "localdomain" as default in /usr/etc anyway, so the hardcoded fallback is fine. Just the dialog is a bit annoying and misleading.

Only theoretical issue is with writing. FWICT it would only write [General] Domain and not the other entries, but as the other values are defaults anyway that probably doesn't matter.

For yast-nfs-client there's no hardcoded default, FWICT it would try to write nil into ".etc.idmapd_conf.value.General.Domain". Not sure what effect that has.

We discussed in the team if we can continue supporting yast-nfs-server and yast-nfs-client, and how useful those modules still are in this day and age. There were arguments in favor and against it, but so far, we'd like to keep it.

But a full usr-merge migration just because of that idmapd.conf will not be possible anytime soon; our focus is Agama, and there are hard milestones and pending features for it.

So, a compromise could be to just drop support for the whole imapd thing.

In all the years that I have been working with Linux (since the late 1990s) and Unix (HP-UX, SunOS, Solaris) from the late 1980s I have never seen any environment where that ID mapping was actually used; in every instance user accounts and their IDs were centrally managed (NIS / YP or IMAP or even manually copied config files). Using idmapd IMHO is a fringe case within an obsolescent (not completely obsolete) technology like NFS; it's a crude workaround to a problem that shouldn't even exist in the first place in a sane IT environment.

So, I propose to drop the part about imapd and its config file(s) from both of those yast-nfs-{server,client} modules to extend their useful lifetime for another few years; that should consume considerably less development resources on the YaST side.

In this particular case, adding basic support for usr-merge as it is planned in TW would just mean adding a "localdomain" fallback for yast-nfs-client and removing the dialog in yast-nfs-server, which is arguably even less work than removing idmapd.conf support. Both options sound fine to me though.

access to idmapd.conf was removed in yast-nfs-{client,server} 5.0.1