Bug 20064

Assinging to the registered maintainer.

CC: (none) => marja11
Assignee: bugsquad => guillomovitch

It seems gssproxy is quite strict about its configuration, and bails out when used with an invalid configuration file:
Jan  4 20:53:08 beria gssproxy[2566]: No service sections configured!
Jan  4 20:53:08 beria gssproxy[2566]: Error reading configuration 2: No such file or directory

I guess than previous version was more tolerant. In this case, restarting the service, as standard post-installation procedure, would explain the result. But it's difficult to consider the issue a bug, either in the program or in the package.

(In reply to Guillaume Rousse from comment #2)

> It seems gssproxy is quite strict about its configuration, and bails out
> when used with an invalid configuration file:

Well, in my opinion, any coder worth a damn should release the app with a operational configuration file, especially if they have enabled the service.

> Jan  4 20:53:08 beria gssproxy[2566]: No service sections configured!
> Jan  4 20:53:08 beria gssproxy[2566]: Error reading configuration 2: No such
> file or directory
> 
> I guess than previous version was more tolerant. In this case, restarting
> the service, as standard post-installation procedure, would explain the
> result. 

Pretty sure it is not a post-installation procedure problem since it has the same problem(s) on systemctl start gssproxy.

> But it's difficult to consider the issue a bug, either in the
> program or in the package.

Hmmm, I have numerous other services loaded that do not have problems except for cdra and it is intermittent.

>Pretty sure it is not a post-installation procedure problem since it has the >same problem(s) on systemctl start gssproxy.
As long as your configuration file is empty or invalid, gssproxy 0.5.1 will refuse to start. Feel free to complain upstream that it should instead consume memory running without any effect.

Seriously, are you really using kerberos with NFS ? If not, you don't need this service running. And nfs-utils should probably have an optional dependency, instead of a mandatory one.

(In reply to Guillaume Rousse from comment #4)
> >Pretty sure it is not a post-installation procedure problem since it has the >same problem(s) on systemctl start gssproxy.

> As long as your configuration file is empty or invalid, gssproxy 0.5.1 will
> refuse to start. 

Hmmm, after some research it seems to a distribution problem, not upstream.
upstream bugs penciled whipped with ERRATA.

> Seriously, are you really using kerberos with NFS ? 

Not that I know of. I am just a dumb user and pretty much expect Mageia services to run out of the box without error/warnings in the journal.

> If not, you don't need this service running. 

Copy that. Tried systemctl disable gssproxy, reboot, and journal still shows gssproxy errors.

> And nfs-utils should probably have an optional dependency, instead of a
> mandatory one.

Not sure that will work, quick check reveals 
nfs-client.target:After=rpc-gssd.service rpc-svcgssd.service gssproxy.service
nfs-server.service:After=rpc-gssd.service gssproxy.service rpc-svcgssd.service

FYI:
$ grep rcache /usr/lib/systemd/system/gssproxy.service
Environment=KRB5RCACHEDIR=/var/lib/gssproxy/rcache

$ ls /var/lib/gssproxy/rcache
ls: cannot access '/var/lib/gssproxy/rcache': No such file or directory
 directory does not exist

Workaround:
mkdir /var/lib/gssproxy/rcache

cut/pasted contents from https://bugzilla.redhat.com/show_bug.cgi?id=1208640#c5
into /etc/gssproxy/gssproxy.conf

Should be fixed in incoming release 0.6.1-1.mga6.

(In reply to Guillaume Rousse from comment #6)
> Should be fixed in incoming release 0.6.1-1.mga6.

No idea what was fixed, but still does not start and /etc/gssproxy/gssproxy.conf has my jan 22 date.

No clue as to why I see a  msec[22153]: /etc/gssproxy/gssproxy.conf
message in journal.

install script error message is a bit vague. Snippet follow:

     7/53: gssproxy              ########################
warning: %post(gssproxy-0.6.1-1.mga6.x86_64) scriptlet failed, exit status 1
ERROR: 'script' failed for gssproxy-0.6.1-1.mga6.x86_64
     8/53: lib64jansson4

Source RPM: gssproxy-0.5.1-1.mga6.src.rpm => gssproxy-0.6.1-1.mga6.src.rpm

I can't reproduce the issue, everything 'works' (meaning: runs without error in the background, without any effect) as expected.

The missing 'services' configuration are provided as separation configuration files under /etc/gssproxy, as for the fedora package.

(In reply to Guillaume Rousse from comment #8)
> I can't reproduce the issue, everything 'works' 

How sad. Yesterday's clean install of
     Jan 19 11:05 Mageia-6-sta2-x86_64-DVD.iso
plus updates on my test bed (tb) node has same problem.

I used mcc to remove gssproxy and answered yes to also remove nfs-utils.

Here on my web browsing (wb) node, I removed all remaining gssproxy directory/files
/etc/gssproxy
/etc/gssproxy/gssproxy.conf.rpmsave
/etc/systemd/system/gssproxy.service
/usr/lib64/gssproxy
/var/lib/gssproxy
/var/lib/gssproxy/default.sock
/var/lib/rpm-helper/systemd-migration/gssproxy


Ran "urpmi nfs-utils" and answered Yes to install gssproxy.
Stop/start/status gssproxy shows no problems.

Closing this bug report and off to fix my tb node and three VirtualBox guests installs.

Both nodes and 3 vb guests are working.

Status: NEW => RESOLVED
Resolution: (none) => FIXED