|
Bugzilla – Full Text Bug Listing |
| Summary: | MicroOS Cockpit SELinux Application missing from menu on non-SELinux enabled system | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Robert Koktan <robert.koktan> |
| Component: | Cockpit | Assignee: | Alice Brooks <alice.brooks> |
| Status: | REOPENED --- | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | alice.brooks, amajer, Cockpit-bugs, jsindelarova, robert.simai |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | openSUSE Tumbleweed | ||
| Whiteboard: | |||
| Found By: | Field Engineer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Overview
Applications screen Error screen supportconfig |
||
|
Description
Robert Koktan
2024-07-03 12:52:05 UTC
Created attachment 875849 [details]
Applications screen
Created attachment 875850 [details]
Error screen
For missing Storage I'd guess it's a duplicate of https://bugzilla.suse.com/show_bug.cgi?id=1227299 That doesn't seem to be the same problem for the cockpit-selinux module, however. @Alice: another magically disappearing module. I'm not using SELinux there but can duplicate on regular Tumbleweed as well. Installed but it's missing from the menu. Found this in the logs menu... not sure it's related, but...
/usr/bin/cockpit-bridge
/usr/share/cockpit/storaged/manifest.json: Expecting ',' delimiter: line 31 column 22 (char 1213)
CODE_ARGS
(PosixPath('/usr/share/cockpit/storaged/manifest.json'), JSONDecodeError("Expecting ',' delimiter: line 31 column 22 (char 1213)"))
CODE_FILE
/usr/lib/python3.11/site-packages/cockpit/packages.py
CODE_FUNC
load_manifests
CODE_LINE
400
LOGGER
cockpit.packages
PRIORITY
3
PROCESS_NAME
MainProcess
SYSLOG_IDENTIFIER
/usr/bin/cockpit-bridge
THREAD_NAME
MainThread
_AUDIT_LOGINUID
0
_AUDIT_SESSION
3
_BOOT_ID
7019abb989b2471bbfa302eaf6bb5164
_CAP_EFFECTIVE
1ffffffffff
_CMDLINE
/usr/bin/python3 /usr/bin/cockpit-bridge
_COMM
cockpit-bridge
_EXE
/usr/bin/python3.11
_GID
0
_HOSTNAME
rpi3
_MACHINE_ID
5c963d6688c141df9207e17b3a984d50
_PID
6461
_RUNTIME_SCOPE
system
_SOURCE_REALTIME_TIMESTAMP
1720010301065643
_SYSTEMD_CGROUP
/user.slice/user-0.slice/session-3.scope
_SYSTEMD_INVOCATION_ID
819d083c2e3541a88cff68a98b81ecd7
_SYSTEMD_OWNER_UID
0
_SYSTEMD_SESSION
3
_SYSTEMD_SLICE
user-0.slice
_SYSTEMD_UNIT
session-3.scope
_SYSTEMD_USER_SLICE
-.slice
_TRANSPORT
journal
_UID
0
__CURSOR
s=0f5e08de4b4947e49c421727a8a58884;i=50fcb1;b=7019abb989b2471bbfa302eaf6bb5164;m=13f455e3ac;t=61c571b014a0c;x=b0a3445c98233a58
__MONOTONIC_TIMESTAMP
85703648172
__REALTIME_TIMESTAMP
1720010301065740
__SEQNUM
5307569
__SEQNUM_ID
0f5e08de4b4947e49c421727a8a58884
Created attachment 875853 [details]
supportconfig
In case it helps...
So as Robert Simai said the storage section not showing is in progress currently as part of a separate bug report As for selinux not showing, I've had a dig into this and looking at the supportconfig you sent over, selinux is disabled. The Cockpit module checks for the existence of the path `/sys/fs/selinux`, if this path doesn't exist on the system we don't show the Cockpit's selinux module since it's disabled so this is intended behavior duplicate *** This bug has been marked as a duplicate of bug 1227299 *** Reopen for the selinux part. Is there any chance we can output a more meaningful message? You'll easily run into this situation when you install the selinux module because you need it to admin another host from this instance. Similar to e.g. the podman module that checks if the podman service is running and tells the user. (In reply to Robert Simai from comment #8) > You'll easily run into this situation when you install > the selinux module because you need it to admin another host from this > instance. I guess that's nonsense as the module needs to be installed on the target system. Nonetheless, I wonder if we can output a more meaningful message. Hmm it's a difficult one. If you look at it from a systems management point of view, the correct behavior is to not show it on a system that doesn't have Selinux enabled. Since what are you going to be managing there I've double checked and if you network two systems, one with Selinux and one without, this behavior works fine. Selinux is shown on the system that does have it while on the original system it is hidden since Selinux is disabled or not installed I don't think a message in the style of Podman's "Service not running" would work particularly well, since Podman's is easily recoverable. Whereas Selinux's setup can be a lot more specific system wise and a bit more hands on. I'd suggest adding a message against the application in the apps screen however, a little note specifying that it's not in use for this system as Selinux is not enabled potentially with a link to the distributions documentation. That way it could also easily cover other apps that find themself in a similar position, this would require cockpit-packagekit to be installed however I'm open to thoughts on my proposal My apologies, there appears to be something wrong with my system where this is happening... "selinux" doe sin fact return "Disabled", however, in the /etc/selinux/config, the setting "SELINUX=enforcing" is present, so I'm not sure why selinux is disabled. I'll dig in to that now and let you know if the SELinux menu comes back once fixed. (In reply to Alice Brooks from comment #10) > I'd suggest adding a message against the application in the apps screen > however, a little note specifying that it's not in use for this system as > Selinux is not enabled potentially with a link to the distributions > documentation. That way it could also easily cover other apps that find > themself in a similar position, this would require cockpit-packagekit to be > installed however > > I'm open to thoughts on my proposal I guess you're right, it makes sense to add a note under Applications as this is the only link to the purposely hidden page. Or we leave it as it is. We could also think about adding it to the docs but I didn't find anything useful in the upstream docs for this module, and ours only refers to SLE Micro where a Tumbleweed user wouldn't look. I found "selinux=0" set in /etc/default/grub. I must have been doing some troubleshooting a while back and not recalled that I'd disabled SELinux. After re-enabling SELinux in grub and rebooting, the system fails to boot... I'm investigating... but you can probably close this bug as I imagine whatever's wrong is unrelated to Cockpit. Problem solved, SELinux enabled, and the SELinux menu now appears in Cockpit and I can drill down in to it as expected. > Problem solved, SELinux enabled, and the SELinux menu now appears in Cockpit and I can drill down in to it as expected. Awesome glad we were able to help! > I guess you're right, it makes sense to add a note under Applications as this > is the only link to the purposely hidden page. Or we leave it as it is. > > We could also think about adding it to the docs but I didn't find anything > useful in the upstream docs for this module, and ours only refers to SLE Micro > where a Tumbleweed user wouldn't look. I think doing both would be beneficial, if nothing else it at least it's documented somewhere Hi Jana. Could we add a little note under https://documentation.suse.com/sle-micro/6.0/html/Micro-6.0-cockpit/index.html#concept-SELinux to outline that the selinux module only appears if selinux was enabled at boot time, else it's hidden? (In reply to Robert Simai from comment #16) > Hi Jana. Could we add a little note under > > https://documentation.suse.com/sle-micro/6.0/html/Micro-6.0-cockpit/index. > html#concept-SELinux > > to outline that the selinux module only appears if selinux was enabled at > boot time, else it's hidden? Hi Robert, yes, no problem with that. |