Skip to main content

Posts

Showing posts from November, 2012

Installing RHEL EPEL Repo on Centos 5.x or 6.x

How to install RHEL EPEL repository on Centos 5.x or 6.x   The following article will article CentOS 5.x-based or Centos 6.x-based  system using Fedora Epel repos, and the third party   remi   package repos. These package repositories are not officially supported by CentOS, but they provide much more current versions of popular applications like PHP or MYSQL. Install the extra repositories The first step requires downloading some RPM files that contain the additional YUM repository definitions. Centos 5.x wget http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm sudo rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm  Centos 6.x wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm sudo rpm -Uvh remi-release-6*.rpm epel-release-6*.rpm Once installed you should see some additi

Hardening the Linux server - Part 1

Part 2 >> Hardening the Linux server - Part 1 An introduction to GNU/Linux server security Summary:   Servers—whether used for testing or production—are primary targets for attackers. By taking the proper steps, you can turn a vulnerable box into a hardened server and help thwart outside attackers. Learn how to secure SSH sessions, configure firewall rules, and set up intrusion detection to alert you to any possible attacks on your GNU/Linux® server. Once you've gained a solid foundation in the basics of securing your server, you can build on this knowledge to further harden your systems. Objectives In this tutorial, you learn about basic concepts in security administration, including how to secure Secure Shell (SSH) remote logins, create firewall rules, and watch logs for possible attacks. System requirements To run the examples in this tutorial, you need to install Ubuntu Server Edition on a computer or a virtual machine, such as Sun

Linux Flushing File System Caches

We may drop the file system caches on Linux to free up memory for applications. Kernels 2.6.16 and newer provide a mechanism via the /proc/ to make the kernel drop the page cache and/or inode and dentry caches on command. We can use this mechanism to free up the memory. However, this is a non-destructive operation that only free things that are completely unused and dirty objects will not be freed until written out to disk. Hence, we should flush these dirty objects to disk first. We can run “sync” to flush them out to disk. And the drop operations by the kernel will free more memory. We can flush caches of the file systems by two steps: Flush file system buffers Call the sync command: # sync   Free pagecache, dentries and inodes To use /proc/sys/vm/drop_caches, just echo a number to it. To free pagecache: # echo 1 > /proc/sys/vm/drop_caches To free dentries and inodes: # echo 2 > /proc/sys/vm/drop_caches To free pagecache, dentries and inodes:

The Linux boot process

Summary:   The process of booting a Linux® system consists of a number of stages. But whether you're booting a standard x86 desktop or a deeply embedded PowerPC® target, much of the flow is surprisingly similar. This article explores the Linux boot process from the initial bootstrap to the start of the first user-space application. Along the way, you'll learn about various other boot-related topics such as the boot loaders, kernel decompression, the initial RAM disk, and other elements of Linux boot. In the early days, bootstrapping a computer meant feeding a paper tape containing a boot program or manually loading a boot program using the front panel address/data/control switches. Today's computers are equipped with facilities to simplify the boot process, but that doesn't necessarily make it simple. Let's start with a high-level view of Linux boot so you can see the entire landscape. Then we'll review what's going on at each of the individ