Bug 185540
Summary: | mysql user removed and not recreated during upgrade | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jason Vas Dias <jvdias> |
Component: | mysql | Assignee: | Tom Lane <tgl> |
Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 5 | CC: | byte, dtimms, hhorak, pvrabec, tgl |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-03-17 16:48:12 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 185168 | ||
Bug Blocks: |
Description
Jason Vas Dias
2006-03-15 17:25:08 UTC
I'm inclined to think that this is not the fault of the mysql package, but somewhere else. How could his system have gotten into a state where the mysql user is listed in /etc/shadow but not /etc/passwd? The mysql RPM certainly doesn't muck with those files directly. It just does %postun server if [ $1 -ge 1 ]; then /sbin/service mysqld condrestart >/dev/null 2>&1 || : fi if [ $1 = 0 ] ; then userdel mysql >/dev/null 2>&1 || : fi which certainly looks like it should not cause such a problem during an upgrade. Tom/Jason, sorry to lead you on a bum steer. It hit me last night that early in February, when I installed FC5T2 + updated, that I connected to another of my machines on FC4 and meant to sftp in my favourite /etc/hosts (with add blocking, internal addresses etc). But a brain slip had me copy in /etc/passwd. Since I didn't have a backup on the new machine, I retrieved /etc/passwd from another FC5T2 machine (with same root/users) that I was tesing on, and this got me going again ie could log in as user davidt. I though I had solved my problem. But thanks to Jason's help, I've remembered overnite that I had done this: I think the recovery passwd machine did not have mysql installed at that stage ! So that is the likely cause of the mismatch between passwd and shadow that was causing service mysqld start to fail, and may have been causing the rpm scripts to bomb out (and other pup upgrades). I guess more robustness in such a situation could be programmed in, or at least logged to messages / root mail so that an admin could know there is something going wrong. E.g. at boot, the p/shadown and g/gshadow could be tested for correctness and linking. Probably not needed for a Fedora user machine, but could be nice on Redhat commercial machine and hence be value added to Fedora. OK, sorry for the confusion - it appears the missing mysql user was NOT caused by the mysql upgrade - closing this bug. |