Ahem, I know this is a CentOS mailing list. BUT, as more and more people migrate from FC to CentOS, I thought placing this reminder here was worthwhile. [I am still running *cough* FC5 on my own desktop, so I am also running out of time]
https://www.redhat.com/archives/fedora-announce-list/2007-June/msg00006.html
Happy Centosing!
Akemi
On Wednesday, June 27, 2007 9:02 PM -0700 Akemi Yagi amyagi@gmail.com wrote:
Ahem, I know this is a CentOS mailing list. BUT, as more and more people migrate from FC to CentOS, I thought placing this reminder here was worthwhile. [I am still running *cough* FC5 on my own desktop, so I am also running out of time]
For those of us migrating from ancient versions of Fedora, what gotchas might one expect?
I'm working on migrating from a pre-SELinux Fedora, and SELinux has been the biggest headache so far. I'm also expecting to migrate Dovecot from 0.99 to 1.0, and there's a page on the Dovecot wiki about that. I've seen the recent list traffic about BIND's lack of default config, so I'm expecting that, and it's not a problem.
My plan is to install CentOS to a new box, and migrate services one by one as needed.
Kenneth Porter wrote:
On Wednesday, June 27, 2007 9:02 PM -0700 Akemi Yagi amyagi@gmail.com wrote:
Ahem, I know this is a CentOS mailing list. BUT, as more and more people migrate from FC to CentOS, I thought placing this reminder here was worthwhile. [I am still running *cough* FC5 on my own desktop, so I am also running out of time]
For those of us migrating from ancient versions of Fedora, what gotchas might one expect?
If you are using php, you may need to look at programs to make sure they run on newer versions of PHP and upgrade if required (horde needs to be greater than a certain level to run on php-5, for example)
I'm working on migrating from a pre-SELinux Fedora, and SELinux has been the biggest headache so far. I'm also expecting to migrate Dovecot from 0.99 to 1.0, and there's a page on the Dovecot wiki about that. I've seen the recent list traffic about BIND's lack of default config, so I'm expecting that, and it's not a problem.
WRT SELinux ... these are your friends:
chcon -R system_u:object_r:httpd_sys_script_exec_t <path> (lets apache run cgi scripts in directories not in /var/www/cgi-bin)
chcon -R -t httpd_sys_content_t <path> (lets apache access directories outside /var/www/)
many more SELINUX things from here:
man httpd_selinux
and here:
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/selg-overview.html
If you are dealing with apache and a modified httpd.conf file ... the first thing I recommend is that you use /etc/httpd/conf.d/ and a conf file for as many things as possible. Also, to use a different conf file for each kind of service/site within conf.d/
This keeps your httpd.conf file as close to standard as possible, and allows you to easily upgrade to new versions where module names are different, etc. It also allows you to move services/sites over and troubleshoot issues much more easily than a full migration of everything.
One thing I like to do is keep a non modified copy of httpd.conf from the original RPM ... and run a "diff" between the standard and my httpd.conf ... I then know what was changed on that machine ... and can either roll it into the new httpd on the new machine, or split it out to a conf.d/<file>.conf file.
If you did not save the httpd.conf file from your current httpd-<version>.rpm ... you can get it using cpio2rpm like this:
1. get a copy of the original RPM (should be available on a Fedora, RedHat, CentOS, SciLinux, WBWL etc. mirror site that you installed it from)
2. Create a directory and put the RPM in there.
3. CD to the new directory an make sure the only file in there is the RPM.
4. Use this command to extract all the files from that RPM to the current directory:
rpm2cpio <rpm_name> | cpio -idv
5. All the files are now in the current directory in the path that they would have been installed ... so this is the original config file:
<current_directory>/etc/httpd/conf/httpd.conf
My plan is to install CentOS to a new box, and migrate services one by one as needed.
That is the way I recommend doing it. Keep the old one working while you fix the issues on the new one.
Thanks, Johnny Hughes
Johnny Hughes wrote:
Kenneth Porter wrote:
On Wednesday, June 27, 2007 9:02 PM -0700 Akemi Yagi amyagi@gmail.com wrote:
Ahem, I know this is a CentOS mailing list. BUT, as more and more people migrate from FC to CentOS, I thought placing this reminder here was worthwhile. [I am still running *cough* FC5 on my own desktop, so I am also running out of time]
For those of us migrating from ancient versions of Fedora, what gotchas might one expect?
[snip]
WRT SELinux ... these are your friends:
WRT SELinux, just disable it is my suggestion. Or perhaps switch to another distro which is not yet infected.
Mike
On 9/21/07, Mike McCarty Mike.McCarty@sbcglobal.net wrote:
WRT SELinux, just disable it is my suggestion. Or perhaps switch to another distro which is not yet infected.
Why yes, ignoring security or bypassing it alltogether rather than learning how to protect your systems is an EXCELLENT idea. I highly recommend the 'head in the sand' approach. After all, if you can't see the bad guys poking you're server, they're not actually doing it, right?
Selinux is complicated, but it's getting far more easy to use than earlier versions (FC2 anyone?) and in combination with other tools, it can provide a rock solid security system.
For webservers, the belt+suspenders combination of mod_security and selinux is damn near unbeatable.
Jim Perrin wrote:
On 9/21/07, Mike McCarty Mike.McCarty@sbcglobal.net wrote:
WRT SELinux, just disable it is my suggestion. Or perhaps switch to another distro which is not yet infected.
Why yes, ignoring security or bypassing it alltogether rather than learning how to protect your systems is an EXCELLENT idea. I highly
Sarcasm is unbecoming. I suppose you are unaware of the long and bitter discussions on Fedora about SELinux?
recommend the 'head in the sand' approach. After all, if you can't see the bad guys poking you're server, they're not actually doing it, right?
SELinux does not prevent nor report people "poking your server".
Selinux is complicated, but it's getting far more easy to use than
SELinux is complicated, FULL STOP. It's a wrong-headed approach.
earlier versions (FC2 anyone?) and in combination with other tools, it can provide a rock solid security system.
Any security system which is not already rock solid is not going to be made any more secure from attack by adding SELinux. It might possibly suffer somewhat less damage, though that's debatable.
For webservers, the belt+suspenders combination of mod_security and selinux is damn near unbeatable.
You have personal experience with SELinux "saving" your system?
Mike
On 9/21/07, Mike McCarty Mike.McCarty@sbcglobal.net wrote:
Jim Perrin wrote:
On 9/21/07, Mike McCarty Mike.McCarty@sbcglobal.net wrote:
WRT SELinux, just disable it is my suggestion. Or perhaps switch to another distro which is not yet infected.
Why yes, ignoring security or bypassing it alltogether rather than learning how to protect your systems is an EXCELLENT idea. I highly
Sarcasm is unbecoming. I suppose you are unaware of the long and bitter discussions on Fedora about SELinux?
I'm aware of them, and I'm on the side supporting selinux, however it doesn't make much sense for desktop systems. Servers on the other hand can very much benefit from selinux.
SELinux does not prevent nor report people "poking your server".
Depends on how you define poking. Mine may be different but I consider portscans and such "The cost of doing business online". If someone's trying an apache/php etc exploit, that's a poke. And selinux does report the ones which attempt to read/write places where it's not supposed to.
SELinux is complicated, FULL STOP. It's a wrong-headed approach.
Complicated doesn't mean that it's wrong headed. it simply means it's complicated. By this logic people shouldn't use sendmail either (okay, I dislike sendmail but you get my point).
Any security system which is not already rock solid is not going to be made any more secure from attack by adding SELinux. It might possibly suffer somewhat less damage, though that's debatable.
This just isn't correct. Keeping programs from accessing things they don't need access to is ALWAYS better than not. With traditional DAC owner/group/world permissions, this just isn't possible once you start adding complexity.
For webservers, the belt+suspenders combination of mod_security and selinux is damn near unbeatable.
You have personal experience with SELinux "saving" your system?
Yes, actually. We have a few systems here which run older versions of insecure php applications. SELinux keeps folks from dropping shell scripts into place on the system (a fairly common attack) and mod_security keeps the sql injections out. Added system security features help, but on the older (RHEL3 boxen) attackers can mostly just walk right in.
On Fri, 2007-09-21 at 14:54 -0500, Mike McCarty wrote:
Jim Perrin wrote:
On 9/21/07, Mike McCarty Mike.McCarty@sbcglobal.net wrote:
WRT SELinux, just disable it is my suggestion. Or perhaps switch to another distro which is not yet infected.
Why yes, ignoring security or bypassing it alltogether rather than learning how to protect your systems is an EXCELLENT idea. I highly
Sarcasm is unbecoming. I suppose you are unaware of the long and bitter discussions on Fedora about SELinux?
---- and I am rapidly losing all respect for you as you seek another forum to pollute with your rant regarding SELinux - now on Fedora-list running 120+ messages
Anyone who continues this topic on this list is doing so needlessly because they can simply subscribe to fedora-list and save yet another list from being bogged down.
Craig White wrote:
and I am rapidly losing all respect for you as you seek another forum to pollute with your rant regarding SELinux - now on Fedora-list running 120+ messages
I'm not trying to move it over here at all. The topic already came up. I didn't try to move it here, nor am I looking for more fora into which to insert it.
Anyone who continues this topic on this list is doing so needlessly because they can simply subscribe to fedora-list and save yet another list from being bogged down.
I agree with this.
Mike