I cannot find the post that suggested to use the generic agama installer, I need an offline installer for tw with agama, I only have access to a wpa2-enterprise network, its tricky to connect to such networks with an installer. Also I wanna be able to use my installer media as a repair tool sometimes and offline installers have way more tools to sustain such use case (in my opinion at least).
Also, for the PLM, I just would like to state my opinion about a more generic philosophy of things. I wish to see a future for OpenSUSE where the distro depends or integrates more on tech provided by other DEâs, whether it be to replace SDDM with PLM or to integrate Plasma Setup Experience with the user creation workflow. Currently, in my opinion, OpenSUSE acts more like Debian with implementation mindset, which is fine for Leap; but, TW lacks behind, only serving as a distro with up-to-date packages rather than to implement the new tech.
But again, I am not a regular OpenSUSE user, I just check out TW once a while to see whether there has been a meaningful change that will actually make my life easier, as I believe that systemd-boot integration with snapper is brilliant and I wish to see such snapshot mechanism on other distros. Yet TW has never made it easy for me install the OS, and I am concerned with the Yast installer activating root and using root pwd for sudo elevation, instead of wheel group.
Just install sudo-policy-wheel-auth-self after the initial install; that is the default for Leap but is available in Tumbleweed as well.
2 Likes
I find it concerning that that is the default behavior, I can also use visudo to add the wheel group and lock the root account; but, I do not see any circumstance where the current default setup is the correct choice, why is that configuration the default? Also, for some reason Agama does not do that, at least to my knowledge.
The default is actually the traditional default. Or at least was the traditional default until Ubuntu went with a different approach.
As for Agama, I think it depends on whether you setup a root account during install. If you do not set up a root account, it will setup âsuduâ the way that you prefer (as best I can tell).
3 Likes
Yes, thatâs exactly what it will do, if you donât set a root password
I wish the same applied to Yast, I need an offline installer to install tw, I cannot connect the agama installer to internet, why agama does not provide offline isos for tw as well?
For now, that means using the YaST installer. I suspect online installation is the priority these days (most users have good internet access), but perhaps it would still be nice if the openSUSE TW team provided an Agama-based âFullâ snapshot ISO for completely offline installation.
There would be another outcry of some users:
Either: why is package xyz not on the ISO?
Or: why does the ISO no longer fit on a traditional DVD-R? Why is it so big?
I know from another distro that they decided to increase the size of the installer ISO. It no longer fits on a standard DVD but needs DoubleLayer-DVD.
And yes, there are still user which do not use USB sticks but burn a DVD. And if you try to convince them to use an USB stick they go ballistic.
As usual, you canât please all users or cover every possible and impossible usecase.
For systems which do not have an internet connection, you most likely wonât use a standard rolling release distribution. For such use cases an own spin or specialized distro (or even IoT spin) is used or required.
Another point i do not understand is, when you say you want to use a rolling release and update it regularly, why canât you have the internet connection up st the time of installation 
3 Likes
I do not like writing in this tone; but, I am pretty sure there is some confusion. I DO HAVE internet connection on where I am; but, it uses WPA2-Enterprise which is fine for EVERY tool I have seen in my life with the sole exception of Agama installer. I do not need everything on my ISO; but, must acknowledge that even Arch ships their ISOs with iwctl which has the capability to connect to such networks. I opted to ask for a offline ISO as it seems to be the easiest path for OpenSUSE.
All cases where only one person acts as a system administrator and the root password is not given away, whether it be an individual laptop or a small home or office setup where other family/office members do not even need sudo.
I agree that this is seldom the case on corporate setups, and accordingly the current SLE default is the other one, inherited by Leap from 16.0 on.
Please file a issue over at
Then let me ask this, why do we even have sudo on the system, it would function perfectly fine without it where we can su and execute commands. My point is that the tranditional setup wastes the feature-set and flexibility of sudo. It can be argued that expiration of passed sudo is the advantage of using sudo vs root on the traditional setup; but, I do not think such advantage is relevant since you already know the login.
I do not think that there is a disadvantage of using the modern setup for home users since they will not notice the difference and the fact that its for home use does not make my security concerns any less relevant, I will advocate for security especially on this time since there is no disadvantage or inconvience.
Ultimately, it depends on your use case. TW used sudo with the traditional way of using the target userâs password, and changing that in the package, I imagine, would break existing installations and processes that depend on that expected behavior.
So putting a changed default that fits your requirements (which may not be the same as everyone elseâs) provides flexibility and options.
One reason to use the target accountâs password is preventing privilege escalation for compromised accounts. If a user with the ability to execute programs as root has a compromised password, escalating to having root privileges may be easier, depending on what the compromised account can do with sudo.
Personally, I am glad that when the default was changed to use the user password, it wasnât enforced through a change in the installed system defaults; I am a staunch advocate for not changing defaults on a running system without it being the userâs choice. Iâve had too many experiences over the years of a vendor making a change to a configuration default on a running system and having to chase down problems as a result. For new installations, sure, use the new default. Leave an already installed system alone.
2 Likes
Well, remove it. I do not have it. Never used it (or > 40 years).
henk@boven:~> sudo
The program 'sudo' can be found in following packages:
* sudo [ path: /usr/bin/sudo, repository: oss ]
* sudo [ path: /usr/bin/sudo, repository: oss ]
Try installing with:
sudo zypper install <selected_package>
henk@boven:~>
1 Like
I believe that the modern setup could be provided as an option while installing TW as in the current Yast installer there is no option to lock root while installing. I do agree that changing stuff might break things; but, as of my understanding, offering the option for newer systems would not have such impact and since TW is a rolling release, I believe it must follow the modern principles, as many new and old distros do.
If possible does anyone have a detailed guide on maybe achieving the setup I wish from a base install with Yast, I am a bit concerned about not being able to lock root correctly, is passwd -l sufficient? I am not well-versed for security, hence prefer people to do it for me, and that is why I use Fedora Kinoite, can TW be as secure?
Also, why are advised against using the live KDE installer, it looks as if it is capable of installing TW
Because such an install is not tested in openQA
Itâs been a while since I performed an installation, but with the YaST installer, you should be able to install sudo-policy-wheel-auth-self at installation time.
With Agama, you can set up a profile that does that, from my understanding, but I havenât had a need to look into that. Another option that a lot of folks use when doing custom installations is to run a post-installation script that configures the system the way they want, or to use a configuration management system as part of the deployment method.
Those are the ways to get images that have the defaults that you prefer and that meet your needs.
You certainly can explore that and submit a PR to implement such a change. Tumbleweed is a community-driven distribution, so if you feel that strongly about it, you can contribute changes for review and potential acceptance into the distro.
That is the way to âlockâ password login for ârootâ, login using another authentication token (e.g. an SSH key) might still be available and the original password can be âunlockedâ by passwd -u.
To set a void password for ârootâ you can edit the relevant line in /etc/shadow so that it reads something like root:*:20710::::::.
Personally I would not set up a system without a ârootâ password, especially when using /home encryption or SELinux: any serious problem with those and you are lost without ârootâ access but, as always, your system and your choice.
For details see man 1 passwd and man 5 shadow.