Question- When something goes wrong is there a history of what Linux/OS is doing in the background?
Background- When migrating to suse and downloading a needed .deb app image I might attempt to run it in the GUI but nothing happens. I might later find that I need to check a box in permissions. That app image may also not run because I need to install a program/dependency or whatever it is. When you use the GUI nothing happens, there are no clues as to what went wrong, so it becomes difficult to ask for a solution.
When using Bash you are told that the program won’t run because it needs…permissions/a program.
Is there a way to view “the brain”s thinking after you pressed run or whatever? Perhaps like a crash log. I hope that makes sense.
That may depend on the GUI application in question. It may not always give you a useful error when something fails.
As you already mentioned starting an application from a terminal can be useful as part of a basic diagnostic process. Examining the journal is another.
For example to observe journal logging in real time…
journalctl -f
This follows the journal and displays new entries as they are generated. You can leave that running, try launching the application from the GUI, and see whether anything relevant gets logged. Sometimes a bit of filtering with grep is needed to reduce the amount of output and find what you’re looking for.
Note that absence of output doesn’t mean nothing went wrong. Some applications may not send their errors to the system journal. Some applications have their own log files or command-line options for producing additional diagnostic/debug output. The application’s documentation or --help option can be a good place to start.
If you have an issue with a particular application, start a dedicated topic and others can offer specific advice from there.
Please be aware that, Linux – because it’s a UNIX® operating system – is a multi-user operating system.
This means that, a “normal” user can perform their tasks within their environment.
But, not outside of that environment – including system administration …
Which is why, on UNIX® systems there’s this ominous user “root” and also, on everything else that’s been derived from UNIX® –
Android (is a Linux derivative)
macOS plus other Apple products (macOS is currently a BSD [Berkeley Standard Distribution] derivative)
Linux
Various Real-Time operating systems including those used by the automobile industry
The user “root” is also known as – “The root of all evil” – in other words: “To be used with caution.”
A “normal” user can only view “their” entries in the systemd Journal.
However, if a “normal” interactive user is a member of the “systemd-journal” group then, they can view all the entries in the Journal – which is really only useful for those interactive users who are system administrators.
The recommended method for system administration on a single user system is to use “sudo”.
Because the system has only a single user, there’s no real need to edit the default sudo configuration file [[ with “visudo” ]] : <Restricting sudo users>
## In the default (unconfigured) configuration, sudo asks for the root password.
## This allows use of an ordinary user account for administration of a freshly
## installed system.
Defaults targetpw # ask for the password of the target user i.e. root
ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL:ALL) ALL
This thread is tagged “Leap 16” but the OP once mentioned using Slowroll? Be aware that there might be different default configurations for sudo.
Please check if the package sudo-policy-wheel-auth-self is installed: if so, users in the wheel group can enter their own password in sudo to gain superuser power, so that knowing (or even defining) a root password is not needed.
AFAIK this is the default on Leap 16.x.
In Tumbleweed (and Slowroll) you can install the package above to have the same behaviour.
Bruno, I’ve had a bit of a journey…
I’ve realised that I’m not a programmer and really just want a stable Laptop with a simple interface so I’ve settled on Leap and Gnome. The other distros had far too much going on with all the added software and I found the Windows look of KDE on this 14" screen was too much of an eyestrain!
Let’s not make it overcomplicated at this moment. What you have to know is
that there is a system environment, managed by root, through sudo or su, and a user environment, each managed by users. These users have their own /home folder, like /home/dad, /home/kid1, /home/kid2, each with their own password.
The permissions on their homes’ folders detemine whether other users can read and/or write there.
On dependecies:
There are build-dependencies, for the time being not interesting
and runtime dependencies. zypper handles all that: you zypper install AAA` and it will tell you it is also gonna install BBB, GGG and CCC. Flatpaks and appimages run in a sandbox, i.e. isolated from your system environment, so they bring in their own runtime (dependencies), no need to add them.
Malcom, the Security Guide is addressing the case of multiple users – possibly with user authentication via LDAP – in other words, more than one system (usually the case for commercial sites) …
In such a scenario, it’s a good idea to restrict the usage of “sudo” to the site’s administrators.
And yes, the Agama installer does offer the option to skip setting a password for the user “root” but –
I haven’t checked if in the sudo configuration file the entry “Defaults targetpw” has been commented out.
And, I haven’t checked if, for this Use Case, the Agama installer sets the “shell” field of ‘/etc/passwd’ entry for the user “root” to the value: “/usr/sbin/nologin” or, not …
And, if the password of the user “root” hasn’t been set then possibly the system’s behaviour is the same as the current case for Fedora and Ubuntu → “sudo only” … <Fedora – Root Account>
Yes, you could have a good argument for the case of systems with SELinux activated – for such systems it’s possibly not a good idea to follow the Fedora and Ubuntu example and, the sudo configuration file needs to have the entry “Defaults targetpw” activated …
cat /usr/etc/sudoers.d/50-wheel-auth-self
Defaults:%wheel !targetpw
%wheel ALL = (root) ALL
cat /usr/etc/sudoers | grep targetpw
Defaults targetpw # ask for the password of the target user i.e. root
ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
