Every time there is a webmin update, my system shits itself and all of my client php websites go offline. Its always the same bloody problem.
My system runs multiple php versions (5.6,7.0,7.1,7.2,7.3,7.4) due to client needs.
If i go into client virtual servers and change their php version to another, that version of php-fpm also shits itself immediately and stops functioning. In the end, not a single version of php-fpm works (they all shut down with error codes).
I have complained about this before and it still has not been fixed. Something in the webmin update script is stuffing up my php configuration for all of the virtual servers on my system…its got that way I am hesitant to ever update webmin!
Once again i have to restore my server from a backup because of this…its annoying the absolute shit out of me! I cant keep doing this every time there is a webmin update.
below is some of the errors i encounter…
Jan 07 09:17:45 system1.hostdomain.com saslauthd[421]: pam_unix(smtp:auth): check pass; user unknown
Jan 07 09:17:45 system1.hostdomain.com saslauthd[421]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Jan 07 09:17:45 system1.hostdomain.com saslauthd[416]: pam_unix(smtp:auth): check pass; user unknown
Jan 07 09:17:45 system1.hostdomain.com saslauthd[416]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Jan 07 09:17:47 system1.hostdomain.com saslauthd[421]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
Jan 07 09:17:47 system1.hostdomain.com saslauthd[421]: : auth failure: [user=saufer@com.au] [service=smtp] [realm=com.au] [mech=pam] [reason=PAM aut
Jan 07 09:17:47 system1.hostdomain.com postfix/smtpd[1328]: warning: unknown[92.118.38.39]: SASL LOGIN authentication failed: authentication failure
Jan 07 09:17:47 system1.hostdomain.com postfix/smtpd[1328]: too many errors after AUTH from unknown[92.118.38.39]
Jan 07 09:17:47 system1.hostdomain.com postfix/smtpd[1328]: disconnect from unknown[92.118.38.39] ehlo=1 auth=0/1 rset=1 commands=2/3
Jan 07 09:17:47 system1.hostdomain.com postfix/smtpd[1328]: connect from unknown[46.38.144.146]
Jan 07 09:17:47 system1.hostdomain.com saslauthd[416]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
Jan 07 09:17:47 system1.hostdomain.com saslauthd[416]: : auth failure: [user=corky@com.au] [service=smtp] [realm=com.au] [mech=pam] [reason=PAM auth
Jan 07 09:17:47 system1.hostdomain.com postfix/smtpd[1687]: warning: unknown[92.118.38.56]: SASL LOGIN authentication failed: authentication failure
Jan 07 09:17:47 system1.hostdomain.com postfix/smtpd[1687]: too many errors after AUTH from unknown[92.118.38.56]
Jan 07 09:17:47 system1.hostdomain.com postfix/smtpd[1687]: disconnect from unknown[92.118.38.56] ehlo=1 auth=0/1 rset=1 commands=2/3
Jan 07 09:17:47 system1.hostdomain.com postfix/smtpd[1687]: connect from unknown[46.38.144.146]
Jan 07 09:17:55 system1.hostdomain.com saslauthd[420]: pam_unix(smtp:auth): check pass; user unknown
Jan 07 09:17:55 system1.hostdomain.com saslauthd[420]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
php7.3-fpm.service - The PHP 7.3 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.3-fpm.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2020-01-07 09:17:07 AEDT; 3min 25s ago
Docs: man:php-fpm7.3(8)
Process: 4995 ExecStart=/usr/sbin/php-fpm7.3 --nodaemonize --fpm-config /etc/php/7.3/fpm/php-fpm.conf (code=exited, status=78)
Main PID: 4995 (code=exited, status=78)
Jan 07 09:17:07 system1.hostdomain.com systemd[1]: Starting The PHP 7.3 FastCGI Process Manager…
Jan 07 09:17:07 system1.hostdomain.com php-fpm7.3[4995]: [07-Jan-2020 09:17:07] ERROR: [pool 157298130131546] cannot get gid for group ‘wordpress’
Jan 07 09:17:07 system1.hostdomain.com php-fpm7.3[4995]: [07-Jan-2020 09:17:07] ERROR: FPM initialization failed
Jan 07 09:17:07 system1.hostdomain.com systemd[1]: php7.3-fpm.service: Main process exited, code=exited, status=78/n/a
Jan 07 09:17:07 system1.hostdomain.com systemd[1]: Failed to start The PHP 7.3 FastCGI Process Manager.
Jan 07 09:17:07 system1.hostdomain.com systemd[1]: php7.3-fpm.service: Unit entered failed state.
Jan 07 09:17:07 system1.hostdomain.com systemd[1]: php7.3-fpm.service: Failed with result ‘exit-code’.
Is there a wordpress group on your system? That seems like it is the issue here. I haven’t seen this specific problem reported before, so I don’t think it is common…seems like it must be specific to your deployment.
None of the saslauth or postfix errors are relevant to PHP.
No there is no Wordpress user on the system. Wordpress doesnt run as its own user, it normally runs as the Virtual Server user.
I have multiple client domains on the system. The operating system is Debian 9 and webserver is Apache.
So as an example, say i have a virtual server with joomla website using php5.6. The php-fpm 5.6 server stops working after the webmin update. If i then change the php version to 7.0, then immediately the php-fpm 7.0 server stops working. If i then change the same virtual server over to php version 7.1, then php-fpm 7.1 server immediately stops working…this keeps happening until all php-fpm servers have stopped functioning.
The reality is, prior to the webmin update, all websites and the entire system have been functioning normally with all php-fpm versions working with existing virtual server websites…so its definately something in the webmin update that is changing system settings and stuffing my system.
In the past it was because the update was over writing Virtualmin>Services> php-fpm configuration> Edit Configuration Manually, for each virtual server (changing the “user” and “group” to incorrect values that do not exist on the system), however, this time that is not the case as far as i can tell…its something else this time.
The problem is, i cant run the update to try to figure out whats wrong because it takes out all my client websites.
I am not a programmer, but i think i need to see the webmin update changelog so i can just look at what changes are being made in the update.
Something is trying to start with the wordpress group. If there is no such group, it obviously can’t work. So find where that bogus config is, and sort it out (probably switching it to a group that does exist and is appropriate for the application). Virtualmin wouldn’t have created the offending config, unless there were a domain named that.
How am I supposed to do that when it doesn’t do this unless I run the webmin update.
I checked the etc passwd file and there is nothing related to WordPress in it prior to the update.
I am not sure how to problem solve this as in order to do that I have to run the webmin update which will then crash all of the php websites on my system until I figure it out. Its takes upwards of an hour to restore the server backup.
Also, my client websites use A records for dns controled by my clients not me.
The problem is with the configuration of php-fpm, not related at all to /etc/passwd (you already said you don’t have a wordpress user) or DNS.
I don’t know where it is coming from exactly, but you have configuration somewhere (not created by Webmin/Virtualmin, at last not in any way I can think of, unless maybe you once had a domain named wordpress and renamed it and something went wrong during the rename) that is trying to start a process as the wordpress group (which you’ve said doesn’t exist). Did you install an OS provided WordPress package, or otherwise setup WordPress in some custom way? Maybe migrated a WordPress site from some other server and maybe it had some extra config options that got pulled in by Virtualmin? I guess it happened sometime between when you made the backups that work and when this problem started happening.
I would grep for a group = wordpress in the php-fpm configuration files on your system (I don’t know exactly where those live, off hand). But that’s where you’re going to find the problem, so you can fix it so it stops happening.
Edit: Oh, I just read through again, and I think maybe it is some bogus config in Virtualmin (maybe from a migration from other control panel where Virtualmin didn’t quite do something right, or maybe from a failed rename, I’m not sure what else might do it). But, search the /etc/webmin/virtual-server directory for references to a wordpress user and/or group.
I have in the past (quite a few months…perhaps even a year ago) imported a virtual server from a previous virtualmin system i had. This particular virtual server had at least one wordpress website that was imported from cpanel system quite a few months before that (so we are talking 2 years ago that one of the websites was a cpanel one).
The trouble is, I am also getting errors with a Joomla website. I assume that the wordpress issue is stopping php so no surprise there i guess.
any ideas on how i can problem solve this without taking out all my clients websites? (considering i dont control the dns)
If it’s an upgrade of Webmin that does it, then the configuration problem has to be present already…it doesn’t change configuration files, it just re-reads them. So, search the /etc/webmin/virtual-server directory, as I recommended above for some reference to that wordpress group (or user, maybe, I dunno).
the group is supposed to be domain.com (which is the virtual server name as well).
I have struck this problem with webmin updates in the past, clearly whatever is doing this in the update script still has not been fixed!
Can someone please go into your updates files and fix whatever it is that is rewriting my php-fpm configuration with the wrong values for the conf file. I am certain that its making an assumption/guess (for whatever reason…bad programming perhaps?) about what the group name should be and that assumption is very wrong.
I note that on my server, some virtual servers have a user and group with just “domain” as the names. However, i dont think that virtualmin/webmin update script should be just automatically assuming that this is the name format. It needs to actually look in the users and group list in webmin and read them…because i can clearly see in wenbmin/users and groups, that the user/group for the website that caused the problem after the update is “domain.com” and that webmin changed it to “domain” in the php-fpm configuration after the update!
As soon as i changed the group name back to the correct one “domain.com”, everything appears to now work as expected (time will tell i suppose…its night time and I am off to bed. i hope i dont wake up in the morning to find a disaster!)
If there is a place where i can fix this myself please, I am all ears and happy to sort it in my own system so this doesnt happen again with webmin updates.
Your Virtualmin configuration for these domains is just wrong. Look in /etc/webmin/virtual-server/domains and find the group= and ugroup= values. They’re presumably wrong. Why they’d be wrong, I don’t know, though I gave some theories above.
Edit: to figure out what files to look at, you can find the id of a domain with:
One thing i really find frustrating about this forum is where we are pointed at locations using console/putty whatever, when you should be pointing us at fixes using the Virtualmin GUI interface.
Why do i need to go to all that trouble to find a domain id when its on the virtual server summary page in virtualmin? Why not just tell us, click on Virtualmin/Virtual server Summary/Domain ID?
Ok so i have found the ugroup entry and as you say, its incorrect (its seen below in Bold/Black…“ugroup=domain” which should be “ugroup=domain.com”). Thanks for that. I dont know why this entry is wrong, but at least i can now fix it permanently and will also check other virtual servers too.
Where using the GUI interface do i change this?
Is it a default setting in a template i have wrong or is it only for this particular virtual server that i need to change?
Or is it both?
i realise i can use file manager, but i want to find the module where this setting exists for virtual server/s and correct the issue there please.
This is not a thing that ever happens. Literally, I don’t think I’ve ever seen this problem before, even once. It’s something unique in your deployment, but I don’t know what.
I don’t think it’s changeable in the UI (the UI displays the UNIX username and group, but does not offer to change them, because they should never be changed). Yours is a special case. I don’t know why it was in this state (I gave some theories above).
It might be a misconfiguration in a template, but if domains you created in Virtualmin (rather than imported or restored from old backups) are working correctly then I think your templates are fine.
If it’s only effecting domains that fit the description of possible causes I’ve mentioned (migration/old backup restore/imported) then I would guess the latter. If it effects newly created domains (using the Create Virtual Server form and not migrating/restoring/importing), then the former. I doubt it is both, since you’ve said it only effects some domains.
Oh, and for this: It’s not a setting. It’s just wrong data. You can’t tell Virtualmin to do the wrong thing easily. You almost certainly could make a Server Template that uses the wrong thing, but I’d be guessing wildly about how you’d do that (it’s not common that someone overrides the user/group names in Server Templates, though I’m pretty sure you could…I don’t think you would have done it accidentally, as you would have had to have done some extensive reading to figure out how).
so when a new virtual server is created, where does Virtualmin get the ugroup id and name from? (I ask this because i do not recall having ever assigned a custom group name when creating a new virtual server. Is there a way i can check this?)
It is normally auto-generated from the domain name. And, normally it would be correct. It can be manually set, though, but it would also be used correctly everywhere. As I said this isn’t a thing you can configure wrong easily. This is just a few pieces of bad data, I’m still guessing it’s something that went wrong during either a migration from some other control panel, an old backup restore, or an import. Those code paths are less exercised and we’re often guessing at what is coming across; cPanel/Plesk/etc. don’t have documentation for their backup formats and they’ve changed several times over the years. Migrations are always gonna be a little spotty; the fact that they’re so good that it is surprising when it goes wrong is miraculous (Jamie is superhuman). But, sometimes it does go wrong.
If you can identify which of your domains were migrated, I’m willing to bet you’ll see a pattern emerge. I’d be surprised if newly created domains behave this way, especially if you didn’t do something weird in your Server Templates (using variables in weird ways).
In short: I think you’re making this way more complicated than it actually is. What I think happened is you migrated some domains. The group name was incorrectly detected/generated during that migration, or it didn’t get fixed in all config files, and nobody noticed. Then every time the re-check configuration ran, it broke service, you restored backups (with config files you’d manually munged to work, but not fixing the underlying cause), and then repeat every few months until you yell at us here in the forum about it and we get to the root cause.
Yes it may be a migrated domain, although im pretty sure i manually created it and just migrated
the website…however, i dont understand how it can be working then after webmin update stop working with incorrect ugroup?
Hopefully now ive changed it where you suggested it wont happen again with next webmin update. Time will tell.
What if the group id was, let’s say 1020, and was pre-existing upon migration on targeted machine, assigned to some other group name? What if the group name merely was already there upon migration? I don’t know exactly how these checks happen upon migration but it’s easy to mess it upon such clashes. For the future, @adamjedgar in case it’s Virtualmin bug, could you remember what you were trying to import (in terms of user and groups) and whether a group with the same name was present on targeted system prior to migration? I would also did the same checks for group id.
Have you tried simply running:
ls -lsa /home/migrated_virtual_server
Does everything look correctly out there? Are there only group ids set for the owner, by any chance?