CentOS 5.2 -> 5.3 Update?

17 posts / 0 new
Last post
#1 Thu, 04/02/2009 - 12:12
relak

CentOS 5.2 -> 5.3 Update?

So today I went ahead and did a yum update, which updated my system from CentOS 5.2 to CentOS 5.3. Most things appear to be working properly, except that virtualmin doesn't seem to be used when doing a "yum update" anymore, nor does it appear that any of the virtual hosts are running with suexec any longer, despite the module is installed and loaded.

I'm guessing this may be caused by the update overwriting some things, but I'm wondering if there's any easy way to fix this which wouldn't involve me needing to totally reinstall virtualmin, setting up all the mail stuff, and re-importing the virtual hosts.

Thu, 04/02/2009 - 12:19
Joe
Joe's picture

<div class='quote'>but I'm wondering if there's any easy way to fix this which wouldn't involve me needing to totally reinstall virtualmin</div>

Egads! Don't reinstall!

I'm sure this is all minor.

Suexec: What's in the suexec_log in /var/log/httpd?

yum+Virtualmin: What do you mean &quot;virtualmin doesn't seem to be used&quot;? Do you still have the virtualmin-release package installed? Is the /etc/yum.repos.d/virtualmin.repo file still existent?

What else is wrong? Those two seem <i>really</i> simple. Reinstalling should definitely not be your first instinct here.

--

Check out the forum guidelines!

Thu, 04/02/2009 - 12:27 (Reply to #2)
relak

It's not my first instinct, more of a last resort. ;)

What I mean is, before the update when I'd do a &quot;yum update&quot; it would actually say something about checking the virtualmin repository. Now the repo file is still in the /etc/yum.repos.d/ directory for virtualmin, but when I do an update it doesn't appear to check it as it did before.

What I mean by suexec not appearing to work is that where things running in the users home directories would read/write as the user as well, it now appears to do so as &quot;apache:apache&quot; instead. Only thing I've really seen this in so far (all I've checked) has been PHP scripts. There's no signs of errors within the apache error log for suexec, nor in the actual suexec log. However, in the apache config the module is loaded, the module exists, and as far as I can tell it's not causing errors.

Thu, 04/02/2009 - 12:42 (Reply to #3)
relak

Ok I think I know why the repository isn't working.. probably because the servers release version is now 5.3 and there's no existing virtualmin repository for centos 5.3 here:

http://software.virtualmin.com/gpl/centos/

I'm not sure if I should wait on this or just hard code 5.2 in place of $releasever for the .repo (probably not a good idea huh?)

As for suexec, still no clue why that isn't working. Checked and re-checked things and can't quite explain why.

Thu, 04/02/2009 - 12:45 (Reply to #4)
Joe
Joe's picture

<div class='quote'>Ok I think I know why the repository isn't working.. probably because the servers release version is now 5.3 and there's no existing virtualmin repository for centos 5.3 here:</div>

Fixed. Try it again.

--

Check out the forum guidelines!

Thu, 04/02/2009 - 12:57 (Reply to #5)
relak

Hmm, maybe it was only part of the problem... I still get nothing about checking virtualmin anymore:

<div class='quote'># yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.trouble-free.net
* updates: centos.mirror.nac.net
* centosplus: yum.singlehop.com
* addons: mirror.atlanticmetro.net
* extras: yum.singlehop.com
Setting up Update Process
No Packages marked for Update</div>

Thu, 04/02/2009 - 12:58 (Reply to #6)
Joe
Joe's picture

So, are the virtualmin repos &quot;enabled=1&quot;?

--

Check out the forum guidelines!

Thu, 04/02/2009 - 13:00 (Reply to #7)
relak

This is what's within the &quot;/etc/yum.repos.d/virtualmin.repo&quot; file:
<div class='quote'>[virtualmin]
name=Red Hat Enterprise $releasever - $basearch - Virtualmin
baseurl=http://software.virtualmin.com/gpl/rhel/$releasever/$basearch/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin
gpgcheck=1

[virtualmin-universal]
name=Virtualmin Distribution Neutral
baseurl=http://software.virtualmin.com/gpl/universal/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin
gpgcheck=1</div>

Thu, 04/02/2009 - 13:01 (Reply to #8)
relak

Also, side note, this is how it installed off the install.sh script on the fresh CentOS 5.2 install. I haven't custom modified anything on the server.

Thu, 04/02/2009 - 13:05 (Reply to #9)
relak

Forum edit here seems to be broken too. :P

Anyhow, when I change a portion of the repo file to:
<div class='quote'>[virtualmin]
#name=Red Hat Enterprise $releasever - $basearch - Virtualmin
#baseurl=http://software.virtualmin.com/gpl/rhel/$releasever/$basearch/
name=CentOS $releasever - $basearch - Virtualmin
baseurl=http://software.virtualmin.com/gpl/centos/$releasever/$basearch/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin
gpgcheck=1</div>

I now get this when I call yum update:
<div class='quote'># yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirrors.liquidweb.com
* updates: centos.mirror.nac.net
* centosplus: yum.singlehop.com
* addons: mirror.sanctuaryhost.com
* extras: yum.singlehop.com
virtualmin | 951 B 00:00
virtualmin-universal | 951 B 00:00
Setting up Update Process
No Packages marked for Update</div>

Thu, 04/02/2009 - 13:12 (Reply to #10)
relak

Nothing in /etc/yum.conf blocking repositories.

Thu, 04/02/2009 - 13:22 (Reply to #11)
Joe
Joe's picture

That shouldn't make any different. the rhel repo is a link to the centos repo. They are binary compatible systems, so the packages are exactly the same.

I suspect yum was caching the bum data from before the 5.3 repo existed. If you were to change back and do a yum clean metadata, I bet it would fix itself up. But it doesn't matter. Pointing to centos or rhel is fine. You'll get the same packages.

Still a bit weird, though.

Anyway, it seems to be working now, though, right?

--

Check out the forum guidelines!

Thu, 04/02/2009 - 13:33 (Reply to #12)
relak

For the most part, yeah. Now I just need to figure out what's going on with suexec.

Thu, 04/02/2009 - 14:23 (Reply to #13)
relak

Did some thinking on the suexec thing then started looking deeper into the users issues. Then it hit me that PHP doesn't ever run under suexec unless you're running it as a cgi through some special setup versus under mod_php normally.

Then I realized that they changed from a perl forum over to a php based one. Which explains why what is happening is happening. Though I'm surprised that virtualmin doesn't seem to set up php as a cgi under suexec by default. Either that or whatever it did set up was removed on the system update.

Thu, 04/02/2009 - 14:34 (Reply to #14)
andreychek

Virtualmin supports PHP in 3 setups -- mod_php, fcgid, and cgi.

The only one that won't work under suexec is the mod_php option.

I *think* fcgid is the default, as it's pretty good speed-wise, but also has the security benefits of suexec.
-Eric

Thu, 04/02/2009 - 13:01 (Reply to #15)
Joe
Joe's picture

Well, that's weird. What's in /etc/yum.conf? Is there something there excluding other repos?

--

Check out the forum guidelines!

Thu, 04/02/2009 - 12:44 (Reply to #16)
Joe
Joe's picture

OK, for yum, check to be sure the &quot;enabled=&quot; line for virtualmin and virtualmin-universal are both set to 1.

For suexec, check to be sure the execution mode for scripts in Virtualmin is set to one of the &quot;Run CGI scripts as domain owner?&quot; options (in Server Configuration-&gt;Website Options for the domain).

Just for grins, check to be sure you have a correct suexec:

suexec -V

It should have DOCROOT set to /home.

If those are true, then let us see the VirtualHost section of httpd.conf for one of the effected domains.

While you're in httpd.conf, make sure the suexec module is being loaded.

--

Check out the forum guidelines!

Topic locked