Howto: Disable SELinux on Centos

How to Disable SELinux in Centos Linux

Occasionally, you will have trouble with selinux on Centos and need to temporarily disable selinux. Here is how you change selinux settings in centos and other red hat linux distributions:

• Edit /etc/selinux/config (e.g. $sudo vi /etc/selinux/config)


• Find the line:
  
  SELINUX=enforcing


• • a) If you simply want to set selinux to permissive mode - which will still warn you when something would have been denied
    
    change to
    
    SELINUX=permissive
  
  
  • b) If you are sure you want to completely disable selinux
    
    change to
    
    SELINUX=disabled
  
  
  and save (in vi type [Esc] :wq)
  

  



• SELinux will be disabled after reboot. To turn selinux off immediately, without rebooting use:
  
  $ sudo setenforce 0

• If everything works, edit your /etc/grub.conf and change it from this:
  

  



• To this:
  

  

That is how to disable selinux on Centos. Note: there is no way to uninstall selinux from Centos. This is as disabled as selinux gets.

You usually will not need to disable selinux completely. This may be useful for troubleshooting, but I would recommend trying to disable IPv6 and disable your firewall first (service ip6tables stop; service iptables stop) and see if you have another problem. Disabling selinux can come in handy for various testing environments and may solve a few obscure problems with certain software.

Links:

• Linux Security Cookbook
• SELinux Wikipedia
• SELinux Sourceforge
• Centos SELinux HOWTO

"Howto: Disable SELinux on Centos" continued here...

Quick Tech Tips - Part 2

When faced with a computer you know nothing about, you will want to at least know the basic system information to avoid headaches. This is not only useful for troubleshooting, and applies to client machines also - can you tell me what processes are running on your system right now? So how should you approach an unfamiliar computer system? How do you get the system specs, logs, and other information you might need to fix a problem, pass on to a technician, or list in your asset log?

This is what I do to gather specs and system information before starting to work on a system that I know nothing about:

Windows


• Backup the system: Start->Run...->ntbackup


• Start->Right Click My Computer->Properties


• Start->Run...->taskmgr


• Start->Run...->msinfo32


• Start->Run...->msconfig


• Start->Run...->eventvwr


• Start->Run...->cmd; ipconfig /all


• Start->Run...->gpedit.msc


• Start->Run...->regedit

Linux


• Backup the system: tar or rsync


• dmesg


• uname -a


• free


• top


• lsmod


• lspci


• cat /proc/cpuinfo


• cat /var/log/messages


• vi /etc/sysctl.conf


• cd /etc/sysconfig; cat [things that you want info about] (e.g. cd /etc/sysconfig; cat network)


• ifconfig /all


• You will find much more information browsing around the /proc virtual filesystem, so e.g. to get the current max threads in the kernel, use: cat /proc/sys/kernel/threads-max

Am I missing a tech tip you use regularly? Add it in the comments below!

"Quick Tech Tips - Part 2" continued here...

Tuning Basics

When you run into performance problems, it's easy to add network equipment, servers, or bandwidth to cope with the load. However, you will often need to fix the issues without spending additional capital. This means tuning. Unfortunately, many websites on tuning simply give specific values without any explanation, such as a set of sysctl values for Linux or a bunch of registry keys for Windows. These values are often tuned to the poster's hardware and environment, and may even introduce new and obscure problems if you apply them without knowing what they do and how they apply to your environment.

So why am I writing a blog on tuning, then? Well, I would like to present techniques for identifying bottlenecks and tuning your systems correctly. I will also provide specific tools for monitoring and testing performance where applicable. Finally, I will list specific tuning options at times (mostly so I can find them again), but I will always preface these with an explanation, including the details of my environment and system specs. 

Let's start with the basic rules of system tuning:

• Identify the problem first
  
• Only tune if it will actually help (For example, tuning can't fix a bad switch port. Troubleshoot and eliminate obvious problems first.) 
• Don't ever tune a live server (If you have an emergency, clone the box to a VM or spare box instead)
• Back up the current system state and all data before you touch anything
• Make a performance baseline
• Make a performance goal
• Document everything
• Back up the current system state and all data before you touch anything
• Write down what you change when you change it
• Classify results in multiple categories - keep track of what hurts, what helps, and what doesn't affect performance
• Make regular backups (or better, snapshots) as you progress so you can revert
• Test each change separately
• Test in a pre-production environment before going live - don't assume it will work in your datacenter because it works in your lab.

Check back often (I will try to post at least once a week), and if there's a specific question you have or benchmarks you'd like to see, let me know and I'll do what I can to help.

"Tuning Basics" continued here...