Sorry, I still don’t get it about the update. Nothing else on console after the API call.
After manually setting config setprop sshd AllowEveryone none
it passes the validate action an it works.
API exec: system-openssh/validate$ echo '{"name":"sshd","props":{"PasswordAuthentication":"yes","PermitRootLogin":"yes","TCPPort":"2222","AllowGroups":{},"AllowEveryone":"none"},"type":"service"}' | /usr/bin/sudo /usr/libexec/nethserver/api/system-openssh/validate | jq
nethserver.js:41 API exec: system-openssh/update$ echo '{"name":"sshd","props":{"PasswordAuthentication":"yes","PermitRootLogin":"yes","TCPPort":"2222","AllowGroups":{},"AllowEveryone":"none"},"type":"service"}' | /usr/bin/setsid /usr/bin/sudo /usr/libexec/nethserver/api/system-openssh/update | jq
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.
The “update” API script could set it to empty string after pressing the save button
Yes this is my concern
I reproduced the issue with the following steps:
- 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).
Edit: tracked by https://github.com/NethServer/dev/issues/6075
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.
@giacomo, @edoardo_spadoni what do you think?
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.
Can we “invite” the user to do it by some means?
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
Damned 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
I think you doesn’t have the information, since we do not version nor the API nor the UI.
I still think this is a bug, but most of the users will not even encounter it.
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.
[root@vm7 ~]# cat /usr/share/cockpit/nethserver/manifest.json
{
"version": 0,
...
Of course it can be improved!
…at least it can work for the core part.
There is a package to test!
@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).
https://github.com/NethServer/dev/issues/6075#issuecomment-593419169
To install it:
yum --enablerepo=nethserver-testing update nethserver-cockpit
It seems to be working.
Fix released
This topic was automatically closed after 4 days. New replies are no longer allowed.