Setting for Usermin start at boot is not respected!

Submitted by Blueforce on Tue, 08/25/2020 - 17:59 Pro Licensee

Hi,

We do not use Usermin on our servers and has "Start at boot time" set to "No"! This setting is NOT respected and often after a update and/or restart this is changed to "Yes" and Usermin is started! Why do Virtualmin not respect my setting? I DON'T want Usermin running!

And is there other settings that gets reset or changed without my knowledge?

Using latest Virtualmin Pro on CentOS 7

Regards, Leffe

Status: 
Active

Comments

Ilia's picture
Submitted by Ilia on Wed, 08/26/2020 - 08:57

Hi, Leffe!

Perhaps, the best way would be is to remove Usermin?

yum remove usermin

And is there other settings that gets reset or changed without my knowledge?

Does this happen after system reboot or after Usermin package upgrade?

Ilia's picture
Submitted by Ilia on Wed, 08/26/2020 - 09:18

Leffe, I have double checked it for you and after an upgrade Usermin indeed is getting enabled automatically. I would suggest removing Usermin in case you're not using it.

The other work-around, is to mask the service, to make sure it will not be re-enabled or started without your permission -

systemctl mask usermin

Submitted by Blueforce on Thu, 08/27/2020 - 05:21 Pro Licensee

Hi Ilia,

I don't want to remove Usermin, if I do I for sure get a customer that "demands" it... ;-)

Masking the service seems to be a good solution - Tanks! Or just to try to remember to shut it down after a update and set it to not start on boot-up now that I know that it do that by design.

Thank you for your help Ilia, always first class support! :)

Regards, Leffe

Ilia's picture
Submitted by Ilia on Thu, 08/27/2020 - 05:26

Assigned: Unassigned ยป

Jamie, shouldn't we respect that and keep it disabled? I assume, we should change post install script, so it would only enable the service on initial install, not when running upgrades?

I don't want to remove Usermin, if I do I for sure get a customer that "demands" it... ;-)

Do you mean it will certainly rain, if you leave your umbrella at home? :-)

Thank you for your help Ilia, always first class support! :)

Thank you for your kind words.

Submitted by Blueforce on Thu, 08/27/2020 - 05:35 Pro Licensee

"Do you mean it will certainly rain, if you leave your umbrella at home? :-)" - Exactly! :-)

Submitted by JamieCameron on Fri, 08/28/2020 - 21:08

The problem here is that the RPM package includes the links under /etc/rc.d that indicate if the script is started at boot or not, so when they are deleted the RPM re-install just re-creates them! So there isn't any good way to persist this disabled state across reboots..

Ilia's picture
Submitted by Ilia on Sat, 08/29/2020 - 01:49

Perhaps, we could creat a file under Usermin config dir, when it's first time used, and use it in post-install script to test against it? If file exists and the link doesn't it would indicate that service was manually disabled?

Submitted by JamieCameron on Sat, 08/29/2020 - 14:48

I suppose the init script could check some flag file indicating that it's really been disabled, but that could be confusing for the admin if they re-enable it outside of Webmin.

Ilia's picture
Submitted by Ilia on Sat, 08/29/2020 - 16:27

I think we should only enable the service on initial install, thus once. Upgrade must not change service status.

Don't package managers return any accessible, environmental variables, for the post-install script to know that it's an upgrade? If not we could create a flag after initial link was created and never run it again on upgrades?