Dear colleagues, I greet you all!
Happy New Year! All the best and may your wishes come true! May everyone have everything they wished for!
Good evening and good mood!
Today during the standard update apt-get upgrade
The update of HCP 1.9.1 got caught
Yesterday 1.9.0 was installed and it was unexpected.
As a result, the console now displays the update process all day and is stuck on Installation tasks complete, performing clean-up…
=============================================================================
Hestia Control Panel Software Update Log
=============================================================================
OPERATING SYSTEM: Ubuntu (22.04)
CURRENT VERSION: 1.9.1
NEW VERSION: 1.9.1
RELEASE BRANCH: release
BUILD TYPE: Production release
INSTALLER OPTIONS:
=============================================================================
Send email notification on upgrade complete: true
Send installed log output to admin email: false
=============================================================================
[ * ] Backing up existing templates and configuration files...
=============================================================================
[ ! ] Performing system health check before proceeding with installation...
[ * ] Health check complete. Starting upgrade from 1.9.1 to 1.9.1...
=============================================================================
[ ! ] The latest version of Hestia Control Panel is already installed.
Verifying configuration...
[ ! ] Updating default web domain templates...
[ ! ] Updating default mail domain templates...
[ ! ] Updating default DNS zone templates...
[ * ] File Manager is up to date (7.12.0)...
[ * ] Roundcube is up to date (1.6.9)...
[ ! ] Update Hestia PHP dependencies...
[ * ] Updating Cloudflare IP Ranges for NGINX...
[ * ] phpMyAdmin is up to date (5.2.2)...
=============================================================================
Installation tasks complete, performing clean-up...
=============================================================================
[ * ] Rebuilding user accounts and domains, this may take a few minutes...
- admin...
I have a huge request, if anyone has already tried themselves in this process, please tell me the recipe for action.
I found the PID of the process that hangs and completed the # kill -9 [PID]
Then I immediately received a message by email that version 1.9.2 was a successful update.
Then I doubted even more and went to the console to do it again and make sure # v-rebuild-users
And again the process hung for an infinite time
Then I try to rebuild one by one for one user, then it works. But this is torture
This inspired me and it seemed logical to me to run
bash -x /usr/local/hestia/bin/v-rebuild-users 2>&1 | tee /tmp/v-rebuild-users.debug
for everyone at once.
And here a surprise awaited me.
Execution stopped precisely at the rebuilding of the admin user, which had been successfully completed before.
And that’s all.
It still hangs.
It doesn’t make sense for me to restart
v-rebuild-user admin
, because it was just completed successfully.
And where it hangs now, I have a hard time understanding.
Please, friends, at least give me a hint in the direction.
I’m already very tired, I’ve been sitting with this question for about a week.
Dear colleagues, please give me your opinion, should it be like this or is my case isolated?
The matter with my question remains a problem.
I run the script
v-rebuild-user admin
with debugging
The script hangs on the attempt to change the shell nologin
I take the command
The password entry question returns.
I suggest the user password Admin
Not suitable.
I check the user in the system and his password, there is both a user and a password hash.
Is it possible to allow script execution without PAM Authentication?
sudo chsh -s /usr/sbin/nologin admin --force
Friends, please help me decide
Is the repair suitable?
Or will I have to install a new HestiaCP
root@makc1:~# cat /etc/pam.d/chsh
#
# The PAM configuration file for the Shadow `chsh' service
#
# This will not allow a user to change their shell unless
# their current one is listed in /etc/shells. This keeps
# accounts with special shells from changing them.
auth required pam_shells.so
# This allows root to change user shell without being
# prompted for a password
auth sufficient pam_rootok.so
# The standard Unix authentication modules, used with
# NIS (man nsswitch) as well as normal /etc/passwd and
# /etc/shadow entries.
@include common-auth
@include common-account
@include common-session
root@makc1:~#
Forgive my lightness.
For two weeks now, this question has been creating background noise in my brain. Fatigue is taking its toll )
Maybe I should just update the list and add the missing parts?
Thank you, friends!
I got expert experience and became stronger)
Thanks to you, your support and my own efforts.
Now my feelings are overwhelmed with pride!
The issue has been successfully resolved!
Everything works!
Thank you, Friends!
All the best to you,
Money-making interesting work,
More female attention to the male community))