A default is already set at package install/update but somehow was lost for unknown reasons (on multiple servers):
Feb 28 23:09:26 server cockpit-bridge: PHP Notice: Undefined index: AllowGroups in /usr/libexec/nethserver/api/system-openssh/validate on line 61
Feb 28 23:09:26 server cockpit-bridge: PHP Warning: Invalid argument supplied for foreach() in /usr/libexec/nethserver/api/system-openssh/validate on line 61
Feb 28 23:09:26 server /usr/libexec/nethserver/api/system-openssh/update[6765]: /var/lib/nethserver/db/configuration: OLD sshd=service|AllowEveryone|none|AllowGroups||LoginGraceTime|2m|MaxAuthTries|6|PasswordAuthentication|yes|PermitRootLogin|yes|Protocol|2|SubsystemSftp|yes|TCPPort|2222|UsePAM|yes|access|green,red|status|enabled
Feb 28 23:09:26 server /usr/libexec/nethserver/api/system-openssh/update[6765]: /var/lib/nethserver/db/configuration: NEW sshd=service|AllowEveryone|none|AllowGroups||LoginGraceTime|2m|MaxAuthTries|6|PasswordAuthentication|0|PermitRootLogin|yes|Protocol|2|SubsystemSftp|yes|TCPPort|2222|UsePAM|yes|access|green,red|status|enabled
Feb 28 23:09:26 server /usr/libexec/nethserver/api/system-openssh/update[6765]: /var/lib/nethserver/db/configuration: OLD sshd=service|AllowEveryone|none|AllowGroups||LoginGraceTime|2m|MaxAuthTries|6|PasswordAuthentication|0|PermitRootLogin|yes|Protocol|2|SubsystemSftp|yes|TCPPort|2222|UsePAM|yes|access|green,red|status|enabled
Feb 28 23:09:26 server /usr/libexec/nethserver/api/system-openssh/update[6765]: /var/lib/nethserver/db/configuration: NEW sshd=service|AllowEveryone|none|AllowGroups||LoginGraceTime|2m|MaxAuthTries|6|PasswordAuthentication|0|PermitRootLogin|0|Protocol|2|SubsystemSftp|yes|TCPPort|2222|UsePAM|yes|access|green,red|status|enabled
Feb 28 23:09:26 server /usr/libexec/nethserver/api/system-openssh/update[6765]: /var/lib/nethserver/db/configuration: OLD sshd=service|AllowEveryone|none|AllowGroups||LoginGraceTime|2m|MaxAuthTries|6|PasswordAuthentication|0|PermitRootLogin|0|Protocol|2|SubsystemSftp|yes|TCPPort|2222|UsePAM|yes|access|green,red|status|enabled
Feb 28 23:09:26 server /usr/libexec/nethserver/api/system-openssh/update[6765]: /var/lib/nethserver/db/configuration: NEW sshd=service|AllowEveryone||AllowGroups||LoginGraceTime|2m|MaxAuthTries|6|PasswordAuthentication|0|PermitRootLogin|0|Protocol|2|SubsystemSftp|yes|TCPPort|2222|UsePAM|yes|access|green,red|status|enabled
Feb 28 23:09:26 server cockpit-bridge: Type of argument to keys on reference must be unblessed hashref or arrayref at /usr/libexec/nethserver/api/system-openssh/update line 42.
install and configure a local LDAP accounts provider (I guess this is not a strict requirement but doesnât harm)
go to Software Center and update nethserver-cockpit (1.4.4 => 1.4.5) and nethserver-openssh (1.4.0 => 1.4.1)
go immediately to the SSH Cockpit UI and press Save
log out
log in again and go back to SSH Cockpit UI. Save button does not work any more.
At step 3 the resulting DB record is
[root@vm5 ~]# config show sshd
sshd=service
AllowEveryone=
...
âŠwhich is no more allowed by the validator API. However to hit the bug, the new UI code must be (re)loaded (here I did with log-out log-in cycle). The old UI code does not submit the AllowEveryone parameter at all.
Workaround
After you hit the bug
config setprop sshd AllowEveryone none
Then reload (Ctrl+Shift+R) the browser page (or maybe log out and log in again).
The bug is there, though it is not so easy to reproduce.
It seems to fall in the class of issues originated by updates. The UI code loaded by the browser is stale and does not suit the new underlying API.
We can address this kind of issues with either forcing a reload of the Cockpit UI web page after Software Center updates, or by paying more attention when we code the APIs.
The reload is already done after applications install, but AFAIK you canât force a full UI reload without restarting cockpitâŠ
The problem is more related to the core itself than to extra apps.
I donât see what we can notify to the user: the fix is a full cockpit restart and usually the user shouldnât do that.
Also, please note that such bug has been hit only once in 57 cockpit releases.
I think that new features just need a little bit of extra care from developers
Restarting the cockpit-ws is an hack just to force the reload of the web page. I really dislike it (see also Why cockpit is not restarted).
At least after applying updates in the Software Center, we could check if the UI and the API are at the same version. If it is not true, warn the user and say âhey, reload your page (Ctrl+Shift+R)â.
Iâm not sure about âonly onceâ but I agree it is rare enough to not require an immediate change. However letâs keep it in mind for future releases.
We cannot forget it! And also the QA team has to be aware of possible regressions in this area.
I confirm it, when I code I always restart cockpit due to this difference between the UI display and the new code of the API.
We can test the API code, does the prop exists, does the prop is not equal to '', we can put default values in template (I am double minded on it, except if the value is FIXME)âŠ
All of this is a kind to hide something under the carpetâŠI prefer an error in the Browser, like this we know that something is wrong
This is just a raw idea: compare the ânethserverâ cockpit app version in the cockpit manifest.json. The UI can have it statically bound (during RPM build), whilst the API could query it dynamically.
@dnutan can you give it a spin? Please note that the bug fix does not fix also broken systems. The manual workaround above is still required by affected systems (only 3 hopefully).
