NYIT

Fall 2012

TERM PAPER:01 Title: OS Patching, Updating, Upgrading & Core dump Management

Name: Class ID#: School ID#: Course: Course ID: Date:

Shivapuram Mithilesh 19 0837622 Operating Systems Security CSCI-620-M01 1/17/12

Assignments Content
1. Overview .3 2. Patching Linux .4 3. OS UPGRADING 18 4.OS UPDATING.22 5.LINUX CORE DUMPS..25 6.CONCLUSION....29

1. Overview
With the advent of ever-evolving technologies like SANs, virtualization and server consolidation, data centers are glowing with even more shimmering lights, and humming from the buzz of smaller form factor stand-alone servers, farms of virtual machine servers and rows of blade centers. The ease of using server templates, cloning and automated installations have definitely had a great impact on the number of servers you end up managing today. What may have been a 10:1 server to technician ratio several years ago has now changed, and enterprise sized server farms of several hundred machines are managed by just a handful of people. Simply put...if you can build it faster, better and cheaper, someone will take notice and expect more. Along with the growing data center, you also have the rise of Linux as an enterprise level operating system. As more tech houses use this constantly maturing operating system, they run into issues like support, hardware compatibility and finding ways to get more bang for their buck using open source components in their existing infrastructures. Now, aside from finding better ways to manage your hardware, using tools, monitoring processes and other fun IT stuff, one of the biggest headaches IT has to face is keeping your machines up to date. Yes...were talking about patching. When it comes to patching, Microsoft has the edge by far. Regardless of the number of patches Microsoft puts out every year, being the popular operating system that it is, it gets pretty good support from the industry when it comes to facilitating patch management. Aside from using Microsoft Update to patch your machines, there are plenty of third-party tools that support the Windows operating system. For Linux, on the other hand, youll only find a few third party tools. You can use the built-in update processes that the OS has to offer, but it can quite clumsy, especially if scheduling is required, or if there are package dependencies to consider. The few third party tools available can be rather limiting as well, since the majority only work with RedHat. You also need to deal with a vast number of machines in your server farm. How can you manage large scale patch deployments across thirty, sixty or even several hundred servers? In this article, I try to cover some of the basics of patching Linux using built-in mechanisms, whats available in the third-party tool market and, some of the obstacles Ive run into when trying to manage a small to large data center full of Linux servers.

2. PATCHING LINUX
There are four basic reasons patching your Linux machines are important:

Security Maintenance Supportability Error Fixing

Security
Possibly the most important reason to update your OS is to maintain a secure environment for your machines applications. Applying security patches will update your machine and plug up security holes left by outdated software or poorly written applications. You really want to keep others from accessing your file system through some newly found vulnerability. If someone should get in, that person can possibly get important data, change security settings on the machine or even install some little piece of software you may not so easily catch. For example, software like rootkits can be installed and will use newly added processes, wresting some control from the unwary administrator. Even more, now that a machine is potentially under the control of someone else, it may become the unwilling participant in a bot attack involving other commandeered machines, coming from your network or across the Internet. There are plenty of ways to keep your machines safe, but most importantly, keep up with the all the latest security alerts. Checking up on updated packages occasionally can save you from having to deal with the repercussions of having your data stolen or rebuilding your machine. Vendors and distributors like RedHat, SuSE and Ubuntu have special alert services and websites that get updated with the latest security news and information. You can also look up security based web sites like Secunia or the United States Computer Emergency Readiness Team (US-CERT) for more information on current vulnerabilities and how theyre affecting other computers in the wild.

Maintenance
Maintaining a solid working environment is the second reason for keeping your machine up to date. Having the latest/greatest software keeps you up with the times. As we all know, technology doesnt slow down, and new software features are always popping up. For example, an applications previous version may have needed an interface to a MySQL database, but with the advent of a new XML feature, the database requirement

becomes non-existent. By updating your software, you can use the newer XML feature, and enjoy the benefits of updated technology. Patching your Linux machine may also present another challenge...dealing with dependencies. If you patch your OS the wrong way, you may run into dependency conflicts that, if not resolved, could prevent you from updating your application. Lets take an application like Gallery, a web based open-source photo album, as an example. You definitely wouldnt be able to run Gallery with an older mySQL installation on your computer. Certain requirements would not be met and during the Gallery installation you would get messages coming back about first having to update other dependent packages. You would then have to update those dependencies as well for your Gallery installation to succeed. Theoretically, you could spend quite some time trying to find the appropriate packages, until you get it all straightened out.

Supportability
If you are going run Linux in an enterprise environment where you have various levels of expertise on-staff, it is important to make sure that you have your OS at a supportable level. Sure, Linux may be a free operating system, but if your operations are the type that support life or manage your companys finances, you need to have access to a high level of expertise-youll never know for sure if youre going to need it, and while support is not cheap, its necessary. To qualify for support from most vendors, if not all, you need to have a supportable version of the OS to call in for. Just ask yourself this...In 2007, who supports RedHat Linux 6.0? Running an older version of an OS can potentially be more expensive to support, as fewer people work with it. Thus, its to your benefit to upgrade that RedHat server to a newer version, if not the latest. The big Linuxdistributions will usually list their supported OS levels, and also give end-of-life information so you can know when you should upgrade those older machines and OSes.

Error Fixing
The last reason for why you want to install newer software packages is to replace software that is problematic. Memory leaks, for example, are problems caused by errors that may have been missed during development. Software performance can also be fixed or improved on a well-maintained machine. Just keep in mind that though most of these

updates are listed as optional, but they can also be listed in a critical category if their defects can lead to security holes or other vulnerabilities.

2.1 How to Patch Your Linux Installation

Like all OSes, every once in a while you need to update the software running on your Linux server. You can do this in one of three ways:

Download the updated packages and manually install them yourself. Use a built-in open source application that comes with the OS distribution. Use a third party application that downloads the file and then runs the installation for you. Lets look at these in more detail.

Manual Updates
One way you can update your RedHat or SuSE machine is by going to your particular vendors Web or FTP site, and downloading the packages directly from the online file repository or a trusted mirror site. For recent products, like Novells SLES or RedHat Enterprise Servers, once you get the file onto your machine you can then run the RedHat Package Manager (aka rpm) and update the target program you choose.

FIGURE 2.1:RPM

After downloading the rrdtools latest RPM, you can run rpm -i to install the new package, or rpm -u if you are updating rrdtool. The next RPM command queries all the installed RPMs, and extracts only the information you want, using the grep command. The third command uninstalls the rrdtool using rpm -e. Finally, the last line confirms that the application rrdtool is not installed anymore.

FIGURE 2.2:UPDATE OF RPM

If you have a location of a package available via a URL, you can point RPM to update it for you. This image shows the update, the confirmation, and the removal of the livnarelease-6-1 package. In a perfect world, once you run the rpm command, youre done in a moment or two. Confirmation may be a short message provided by the package installation, or you just get a command prompt ready for your next Linux command. However, since we dont live in a perfect world, things can get a little confusing. You may run into a dependency issue where another package on your machine has to be updated before you can update your target program.

FIGURE 2.3:FAILED RPM INSTALLATION

A failed RPM installation will generate the above message and not continue the install. Things can get worse when you realize that these packages that need updates also require further updates themselves, turning a simple upgrade into a longer exercise of having to figure out how to deal with all these dependencies and sub-dependencies.

2.2 Built-In Tools

Because manually updating your OS can become pretty complicated, Linux distros come with applications that do the downloading and installation for you. All it takes is a simple command line argument and some time, as the application downloads, verifies and installs your patches. Youll especially need the time if this is a newly installed machine, or one that hasnt been updated in a very long time, or if you have a slow connection. One way to shorten your update time is to build your own repository, and synch it with other mirror sites. That way, if your own repository is on your network, your updates will not have to cross numerous other ones to get to your Linux machine, significantly speeding up the patching process. In this case, SuSE Enterprise Linux Server 9 gave you the option of configuring a YaST Online Update (YOU) server using its YaST management tool. With a little fiddling around, you can schedule a file synch between

your YOU server and the available Novell repositories, to update your machines by pointing them to your own internal update server.

As things are always changing, newer versions of RedHat and OpenSuSE use an open source utility called yum (for YellowDog Updater, Modified) which works with RPM based installations and updates. Yum has been slowly replacing up2date in the RedHat/Fedora realm, while also being reworked in SuSEs Linux versions. Even though you can run yum from a command line, various graphical tools have been created to facilitate the update operation making it easier to keep your machines up to date.

FIGURE 2.4:YUM UPDATER

You can install single or multiple packages using YUM (YellowDog Updater, Modified). In versions 7, 8 and 9 of SuSEs Enterprise Linux Server, SuSEs main administrative utility YaST (short for Yet another Setup Tool) has a subcomponent called YaST Online Update or YOU. As opposed to the YOU server mentioned above, this utility is the client end of SuSEs patch management tool. The YOU client gives you an ncurses interface or GUI that downloads and installs RPMs from Novells SuSE portal site using a registered login. You could also point to other SLES repositories, without having to edit any configuration files. Its a pretty straight forward process to run; the only problem Ive encountered with YOU is remembering to have the update point to the correct repository. If the update fails and cant find any new packages, it may be because youre using an outdated version of YaST that lacks the updated server listing. This is usually resolved by updating YOU to its latest version, which has the updated pointers to newer download sites.

FIGURE 2.4:SuSE

SuSEs YOU (YaST Online Update) is a great GUI-based tool that simplifies package management and updating. Another option for updating your newer SuSE Linux Enterprise servers is the command line interface called rug. It works with the ZenWorks Management Daemon (zmd) and gives you various command line options. Rug stands out because of a nice feature that sorts similar software into channels. This helps focus your update installation on the software you need, without requiring you to install updates that you dont. The use of ZenWorks with Linux is obviously something that came about after Novells purchase of SuSE in 2003. A systems administrator can still use YOU to update his server, but you have to remember to first register your machine through YaSTs built-in module in order to access the official Novell repositories. Ubuntu, a Debian based Linux distro, uses a different utility called apt (for Advanced Package Tool). This Gnu/Linux package management tool predates RedHats RPM system and also relies on the need to connect to an external repository. In order to get the latest packages installed on your Ubuntu box, you run the apt-get program; you can then either specify which package you want to update, or update all updatable applications on your machine.

FIGURE 2.5:Ubuntu updater

Package management in the Ubuntu distro can be done using apt-get. This particular command updates your list of packages.

FIGURE 2.6: Package management in the Ubuntu

Ubuntu uses the Synaptic Package Manager for its graphical based updates.

2.3 Third Party Tools

Aside from the Linux vendor based utilities like ZenWorks and YaST, there are also third party commercial applications geared to facilitate the patching process. Some of these server based applications will download Linux packages from the vendor, store the updates in a central repository, and provide either automated or manual installation of packages to waiting Linux servers. These applications, especially for Linux, are few in number-you can spend a considerable amount of time trying to find a straight-forward technology that isnt just a small piece of a larger entire enterprise level package (like ZenWorks). The apps I found mostly patch

the Microsoft Windows OS, while a handful of solutions will patch RedHat Linux. Support for SuSE can also be found, but other Linux distros were pretty much left out, except in a couple of products. Patchlink Update is one solution that patches Windows and RedHat systems, but will also cover SuSE, Solaris, AIX, NetWare and OSX. Seeing that RedHat and SuSE are two of the dominant Linux distros in enterprise computing, support for these two distributions puts Patchlink in a very advantageous position over its competitors. Its an agent based architecture that lets you choose how you want to install your patches-either by a scheduled or a manual update.

FIGURE 2.7:PATCH LINK

The great thing about Patchlink is that it touches a lot more operating systems than most update tools. From a top level perspective, to have one application take care of most of your patching needs across various operating systems and supporting software is a dream come true. You get to avoid running multiple patching systems for each OS, saving time and resources that you can deploy elsewhere.

FIGURE 2.8:PATCHLINK UPDATER

The great thing about Patchlink is that it touches a lot more operating systems than most update tools. Optimism aside, Patchlink does have its setbacks. For one, I havent seen any great performance from its system discovery tool: its slow and takes a while to start up on a two-year old server. In fact, Ive seen it take up to 10 -15 minutes to get going. Patchlink, like similar applications, needs a little hand-holding when deploying updates. One thing Ive learned is that if you are using a scheduling feature that will download, install and reboot your servers, dont go tell your users that their servers are going to be automatically rebooted at 10 pm, for example. Patching can be slow, and delays on the network can delay the actual system restart, frustrating both the sys admin and his clients. The common practice to avoid delayed downtimes is to just patch the machines ahead of time and then reboot the server. One other gotcha about Patchlink Update is that its base concept is very security-centric. Patchlink doesnt take care of the occasional maintenance patches-it only covers security based updates that fix vulnerabilities when the updated software is available. Finally, Patchlink does not release kernel updates. Seeing that the kernel is the heart of your Linux system, this can be a little bothersome. The only solution is to patch the kernel yourself. Though not a traditional patch management system, one product line that holds some promise is BlueLanes set of PatchPoint and Virtual Shield products. These products are

appliance-based gateways that sit between your network and your unpatched servers. They protect the servers by cleaning up the network traffic going to the protected servers, and then mitigate any incoming hazardous vulnerabilities.

2.4 Problems with Patching

So you think that patching a Linux server is pretty straight-forward? Youre probably 90% right in that assumption, but there are several issues that need to planned for or addressed when you are considering running updates on your servers.

Networks: The Bigger They Are...

If youre running a small shop, patching your 5 to 10 servers will probably not be a big problem. Given a particular span of time, you should be able to have them all updated before the next big patch cycle. Still, it will take some coordination among your users, developers and management to minimize the effects of scheduled downtime. Youll have to help specify how long the machines will be unavailable, have an idea of the number of reboots involved, and make sure that someone knowledgeable enough with the machine is ready to test whatever application the machine is running once the patching is done. Now, take that same process and multiply the number of those machines by 10-or even 20. Big shops will not only have a large number of machines to patch, but the number of those affected by downtime will surely rise as these enterprise level services will now affect users numbering in the hundreds You will also have to deal with larger scale development schedules, and the fun politics that can come from the management and community. There is no perfect solution for this: strategies and non-strategies will dictate the tools youll need to get all these servers patched. Concepts from clustering servers to social engineering will help get you around the various roadblocks youll encounter as you try to coordinate and compromise on reboot times ranging across all hours of the day and night. Youll need to provide assurances about when the systems will come back up, since the word patching can be synonymous with un-scheduled downtimes due to either incompatibilities between vendor software and OS updates, or just human error. Youll also need to prepare for such occasions by having reliable backups available, prepped fail-over systems that are ready to go if the primary system doesnt come back

up, and the experience of a well-educated sys admin who can help troubleshoot problem updates after their installation. These are just some of the issues I run into when trying to manage a large network of Linux servers in an enterprise environment. Without the right size staff, a lot this would be difficult to get done, making the management of a small IT shop look like a piece of cake by comparison. Another problem with big shops is that they tend to have a variety of configurations when it comes to their OS installs. Because of this, its hard to pick and choose what patches should be applied to your machines-you dont really have the time to sit there and pick and choose which patches need to be installed first. In response to this dilemma, you may opt to just install all of the available updates you need. The world would be perfect if we could have servers running a single upgradeable app, but it just isnt so. Instead, you have machines running Tomcat or Apache HTTP Server as your primary app, yet you also rely on the services provided by ntp, openssh or xinetd. These services, as well as many others, are updated over time, and should be upgraded when given the chance. So, dont just update that one important app-update them all. It may save you potential headaches in the future. The only exception to this patch everything rule is kernel patches. They usually require a restart of the system, whereas other patches require a daemon restart or no restart at all. If updating the machine means not having to reboot the server, then thats just one less thing to worry about, so save the kernel patching for a better time.

Disk Space
One of the problems Ive run into when it comes to patching a Linux OS is disk space. Hard drive capacity to cost ratios are getting better all the time: the amount of money spent on a 20 GB hard drive a few years ago will now buy you a 500 GB drive, so its never a bad idea to have too much disk space. Application logs, home directories, dump files and third party software will always be there. This requires you to keep track of the available disk space you have on your machine, though; remember to always have enough space when you download your patches. Thanks to the large disk capacities of today, running out of disk space is probably the last thing on your mind, but in the cases of virtualized machines or older hard drives, capacity can be an issue. If a machine is in

the process of downloading a large number of patches, its going to need the space to store these packages so that the installation process can access the files and execute the install.

FIGURE 2.9:

contents of the /var/cache/yum

The contents of the /var/cache/yum sub-directories can show lots of valuable space wasted away holding old RPMs you dont need anymore. In SuSEs Enterprise Server, for example, all of these files are stored in organized local directories on the updated server itself. Once YaST Online Update has been executed and these RPMs are used, they can be manually removed if needed. In older versions of YaSTs Online Update, you could check the Remove installation files box at the end of the update, which would remove the downloaded RPM files once the machine was done installing them.

Scheduling
Getting folks to work together can be a grueling exercise in itself, as the different folks who administer, develop and use a specific server may have trouble coordinating an appropriate downtime period: this is especially true for enterprise applications that require a 24/7 uptime. One of the options that may come up is a late night restartyes...someone has to do it. In most cases, the best time to restart a server is when there will be the least amount of activity on it; this could be lunchtime, right after normal working hours or midnight. Either way, its got to be done, but be sure youre ready to respond if something should go wrong. One option is to schedule your downtime during a larger scale planned outage. Just be aware of possible system dependencies that your application may rely on, like network connectivity or authentication. Those opportune times may not be as good as you think they are, and this can lead to further havoc if you cant verify that your machine is back in a good state.

Now, for proper scheduling to happen, you need to have a clear and effective Service Level Agreement (SLA) with your clients. Without this in place, no rules are set and you, as the sys admin, wont have any ground to stand on when it comes to working with others schedules. Hours of operation need to be defined with those who depend on your system, so that you can easily identify downtime windows for working on a machine.

Fail Over
One effective way to shorten or eliminate downtime during a patch cycle is to configure fail-over partners. Generally, this just means building two machines that run the same app, but keeping one server as a primary box and the second server as a backup. This keeps one machine available to the user community while the second server is in hot failover mode, in case the first server should go down. When it comes to patching, the Sys Admin can patch the backup box, have the production application operation confirmed, and switch the applications functionality from the primary server to the secondary server. This can be done using built in clustering utilities or a manual DNS change. Either way, this helps prevent any long-term downtime, so users can continue with their work with minimal or no interruption at all.

Start Up Scripts
Patches are great, but if youre not careful and dont bother to test your machine before you reboot, you may find that your start-up scripts may have been rearranged: this is especially likely to happen to third-party and custom applications. This change in the start-up order can hang the machine during the start-up process, if the moved item is dependent on the network daemon being up for it to start. In some cases, an application will be moved to a position before the network startup script is executed causing the app to hang because of the lack of a networking process for it to start with. To avoid problems, after applying the last patch, check your startup scripts in /etc/init.d/rcx.d or /etc/rcx.d (depending on your flavor of Linux) and verify that your scripts havent been renamed and moved up earlier in the start-up process. This will save you the trouble of having to reboot the machine into single-user mode or using a rescue disk so that you can rename the startup files.

FIGURE 2.10:STARTUP SCRIPTS

Be sure to check your startup scripts after patching your machines. Reorganized RC directories can keep your machine from starting up correctly, especially for applications that require network connectivity.

3. OS UPGRADING There is one thing to understand about updating Linux: Not every distribution handles this process in the same fashion. In fact, some distributions are distinctly different down to the type of file types they use for package management.

Ubuntu and Debian use .deb Fedora, SuSE, and Mandriva use .rpm Slackware uses .tgz archives which contain pre-built binaries And of course there is also installing from source or pre-compiled .bin or .package files. As you can see there are number of possible systems (and the above list is not even close to being all-inclusive). So to make the task of covering this topic less epic, I will cover the Ubuntu and Fedora systems. I will touch on both the GUI as well as the command line tools for handling system updates. 3.1 Ubuntu Linux Ubuntu Linux has become one of the most popular of all the Linux distributions. And through the process of updating a system, you should be able to tell exactly why this is the case. Ubuntu is very user friendly. Ubuntu uses two different tools for system update:

apt-get: Command line tool. Update Manager: GUI tool.

Figure 3.1: Ubuntu Update Manager.

The Update Manger is a nearly 100% automatic tool. With this tool you will not have to routinely check to see if there are updates available. Instead you will know updates are available because the Update Manager will open on your desktop (see Figure 1) as soon as the updates depending upon their type:

Security updates: Daily Non-security updates: Weekly If you want to manually check for updates, you can do this by clicking the Administration sub-menu of the System menu and then selecting the Update Manager entry. When the Update Manager opens click the Check button to see if there are updates available. Figure 1 shows a listing of updates for an Ubuntu 9.10 installation. As you can see there are both Important Security Updates as well as Recommended Update. If you want to get information about a particular update you can select the update and then click on the Description of update dropdown. In order to update the packages follow these steps: 1. 2. 3. 4. Check the updates you want to install. By default all updates are selected. Click the Install Updates button. Enter your user (sudo) password. Click OK.

Figure 3. 2: Updating via command line

The updates will proceed and you can continue on with your work. Now some updates may require either you to log out of your desktop and log back in, or to reboot the machine. There are is a new tool in development (Ksplice) that allows even the update of a kernel to not require a reboot. Once all of the updates are complete the Update Manage main window will return reporting that Your system is up to date.

Now let's take a look at the command line tools for updating your system. The Ubuntu package management system is called apt. Apt is a very powerful tool that can completely manage your systems packages via command line. Using the command line tool has one drawback - in order to check to see if you have updates, you have to run it manually. Let's take a look at how to update your system with the help of Apt. Follow these steps: 1. Open up a terminal window. 2. Issue the command sudo apt-get upgrade. 3. Enter your user's password. 4. Look over the list of available updates (see Figure 2) and decide if you want to go through with the entire upgrade. 5. To accept all updates click the 'y' key (no quotes) and hit Enter. 6. Watch as the update happens. That's it. Your system is now up to date. Let's take a look at how the same process happens on Fedora (Fedora 12 to be exact).

3.2 Fedora Linux

Fedora is a direct descendant of Red Hat Linux, so it is the beneficiary of the Red Hat Package Management system (rpm). Like Ubuntu, Fedora can be upgraded by:

yum: Command line tool. GNOME (or KDE) tool.

.

PackageKit: GUI

Figure 3.3: GNOME PackageKit

Depending upon your desktop, you will either use the GNOME or the KDE front-end for PackageKit. In order to open up this tool you simply go to the Administration sub-menu of the System menu and select the Software Update entry. When the tool opens (see Figure 3) you will see the list of updates. To get information about a

particular update all you need to do is to select a specific package and the information will be displayed in the bottom pane. To go ahead with the update click the Install Updates button. As the process happens a progress bar will indicate where GNOME (or KDE) PackageKit is in the steps. The steps are: 1. 2. 3. 4. Resolving dependencies. Downloading packages. Testing changes. Installing updates. When the process is complete, GNOME (or KDE) PackageKit will report that your system is update. Click the OK button when prompted. Now let's take a look at upgrading Fedora via the command line. As stated earlier, this is done with the help of the yum command. In order to take care of this, follow these steps:

Figure 3.4: Updating with the help of yum. 1. 2. 3. 4. 5. 6. 7. 8. 9. Open up a terminal window (Do this by going to the System Tools sub-menu of the Applications menu and select Terminal). Enter the su command to change to the super user. Type your super user password and hit Enter. Issue the command yum update and yum will check to see what packages are available for update. Look through the listing of updates (see Figure 4). If you want to go through with the update enter 'y' (no quotes) and hit Enter. Sit back and watch the updates happen. Exit out of the root user command prompt by typing "exit" (no quotes) and hitting Enter. Close the terminal when complete.

4. OS update
You can update your system in two different ways:

from packages; from an ISO image.

4.1Updating from packages

The procedure is described below.

4.1.1. Overlay and Portage tree update

Since our binary repos are regularly updated, make sure you have the latest version of Portage and Calculate overlay before you install or update any packages. Your system is updated with a single command: eix-sync Once eix-sync is running, it will update consecutively:

all of your overlays; your Portage tree; Your eix data base.

4.1.2. Software update

For Calculate Linux 11.0 release, we created binary packages repositories for four distros: CLD, CLDG, CLDX and CDS; now all versions of CL have binary profiles, so by default, update is performed from binary packages. To change the default update method enter the following: eselect profile set X where X is the number under which the desired profile is listed. If you do not know this number, you can view the list of profiles available for your architecture by entering: eselect profile list To update from binary packages use the "binary" profile. To update the whole of packages installed on your system, execute: emerge -uD world

If you have modified USE-flags, enter: emerge -uDN world Some package you want to update may require a masked dependency, or changes in USE flags. "--autounmask" should help to resolve dependencies.

4.1.3. Update configuration files

When you update packages, the configuration files of the programs are not overwritten by default. To view and apply new settings, execute:
dispatch-conf

The main commands of this utility are: "PageUp"/"PageDown" - browse the configuration file, "u" - replace the current configuration file with the new one, "z" delete the new configuration file, "q" - quit. If you want your configuration files to be corrected automatically, set the variable "cl_autoupdate_set" in /etc/calculate/calculate2.env, as shown below:
[main] cl_autoupdate_set = on

In this case, always make sure that all config modifications are done correctly and use templates.

4.2 Updating from an ISO file

It is possible to upgrade your system by installing a new image into the free system partition. Main settings such as user accounts, network settings, mount points, screen resolution and other will be transferred, and additional settings will be adjusted by templates during installation, as well. If you have Calculate Directory Server installed, make sure that the /var/calculate directory is mounted from a separate partition on your hard drive. If it is not so, transfer your data and add the required mount point in /etc/fstab The update procedure is described below:Open the console with root privileges and follow these steps:

4.2.1. Update the installer

For a correct update, always use the latest version of calculate-install. You can update it by executing:

eix-sync && emerge calculate-utilities

4.2.2. Download the ISO image of the last assembled Stage

Weekly stages of our distros are accessible from the http mirror http://mirror.cnet.kz/calculate/, in "stages". Download the latest available image:
cd /var/calculate/remote/linux wget http://mirror.cnet.kz/calculate/CLD/stages/i686/cld-20111017-i686.iso

The command shown above must contain the correct path to the file image of your distro of the appropriate architecture.

4.2.3. Install a new version of the system

cl-install

If you update Calculate Directory Server, save a copy of your server settings and the LDAP database by executing the following:
cl-backup

Reboot your computer. To restore the LDAP database and the server settings enter:
cl-rebuild

The main advantages of this method are:

reliability - you can always boot into the previous system, if the new one should ever become unstable; speed - it will require about 5-7 minutes to complete the system upgrade.

5.Linux Core Dumps

Note that most of the theory (particularly the low level segmentation fault details) is also valid for Windows platforms and other operating systems. The commands to configure core dumps and retrieve them are Linux specific though. I also assume that the program you are trying to debug is FreeSWITCH, but you can easily change the program name to the one is misbehaving in your case and you should be fine.

What is a core dump?

Sometimes problems with FreeSWITCH, Asterisk or just about any other program in Linux are hard to debug by just looking at the logs. Sometimes the process crashes and you dont have a chance to use the CLI to look at stats. The logs may not reveal anything particularly interesting, or just some minimal information. Sometimes you need to dig deeper into the state of the program to poke around and see what is going on inside. Linux process core dumps are meant for that. The most typical case for a core dump is when a process dies violently and unexpectedly. For example, if a programmer does something like this: *(int *)0 = 0; Is usually not that straight forward, it may be the that the programmer did not expect certain variable to contain a NULL (0) value. The process is killed by the Linux kernel because by default, a Linux process does not map the memory address 0 to anything. This causes a page fault in the processor which is trapped by the kernel, the kernel then sees that the given process does not have anything mapped at address 0 and then sends the SIGSEGV (Unix signal) to the process. This is called a segmentation fault. The default signal handler for SIGSEGV dumps the memory of the process and kills the process. This memory dump contains all the memory for this process (and all the threads belonging to that process) and that is what is used to determine what went wrong with the program that attempted to reference an invalid address (0 in this case, but any invalid address can cause it).

How can I make sure the core dump will be saved?

Each process has a limit for how big this core can be. If the limit is exceeded no core dump will be saved. By default this limit is 0!, that means no core will be dumped by default.

Before starting the process you must use ulimit. The ulimit command sets various limits for the current process. If you execute it from the bash shell, that means the limits are applied to your bash shell process. This also means any processes that you start from bash will inherit those limits (because they are child processes from your bash shell).
ulimit -a

That shows you all the limits for your bash shell. In order to guarantee that a core will be dumped you must set the core file size limit to unlimited.
ulimit -c unlimited

If you are starting the process from an init script or something like that, the init script has to do it. Some programs are smart enough to raise their limits themselves, but is always better to make sure you have unlimited core file size for your bash shell. You may then want to add those ulimit instructions inside your $HOME/.bashrc file.

Where is the core dump saved?

Each process has a working directory. That is where the process core dump will be saved by default. However, some systemwide settings affect where the core is dumped. /proc/sys/kernel/core_pattern and /proc/sys/kernel/core_uses_pid are 2 files that control the base file name pattern for the core, and whether the core name will be appended with the PID (process ID). The recommended settings are:
mkdir -p /var/core echo "/var/core/core" > /proc/sys/kernel/core_pattern echo 1 > /proc/sys/kernel/core_uses_pid

You can confirm what you just did with:

cat /proc/sys/kernel/core_pattern /proc/sys/kernel/core_uses_pid cat

These settings will cause any process in the system that crashes, to dump the core at:
/var/core/core.<pid>

What if I just want a core dump without killing the process?

In some situations, if a process becomes unresponsive or the response times are not ideal. For example, you try to execute CLI commands in Asterisk or FreeSWITCH but there is no output, or worst, your command line prompt gets stuck. The process is still there, it may be even processing calls, but some things are taking lot of time or just dont get done. You can use gdb (The GNU debugger) to dump a core of the process without killing the process and almost with no disruption of the service. I say almost because for a large process, dumping a core may take a second or two, in that time the process is freezed by the kernel, so active calls may drop some audio (if youre debugging some real time audio system like Asterisk or FreeSWITCH). The trick to do it fast is to first create a file with the GDB commands required to dump the core. Latest versions of CentOS include (with the gdb RPM package) the gcore command to do everything for you. You only need to execute:
gcore $(pidof freeswitch)

To dump the core of the running process. If you are in a system that does not include gcore, you can do the following:
echo -ne "generate-core-file\ndetach\nquit" instructions.txt > gdb-

The 3 instructions added to the file are:

generate-core-file detach quit

This will do exactly what we want. Generate the core file for the attached process, then detach from the process (to let it continue) and then quit gdb. You then use GDB (you may need to install it with yum install gdb) to attach to the running process, dump the core, and get out as fast as possible.

gdb /usr/local/freeswitch/bin/freeswitch instructions.txt

$(pidof

freeswitch)

-x

gdb-

The arguments to attach to the process include the original binary that was used to start it and the PID of the running process. The -x switch tells GDB to execute the commands in the file after attaching. The core will be named core.<pid> by default and the path is not affected by the /proc/sys/kernel settings of the system. This core can now be used by the developer to troubleshoot the problem. Sometimes though, the developer will be more interested in a full back trace (stack trace), because the core dump itself cant be easily examined in any other box than the one where was generated, therefore it might be up to you to provide that stack trace, which you can do with:
gdb /usr/local/freeswitch/bin/freeswitch core.<pid> (gdb) set logging file my_back_trace.txt (gdb) thread apply all bt full (gdb) quit

Then send the file my_back_trace.txt to the developer, or analyze it yourself, sometimes is easy to spot the problems even without development experience!

6. Conclusions
One thing Im always telling others is to make sure theyve got their bases covered. Security patches arent designed to break your software, after all; their developers designed them to protect your machine. Even so, problems can arise after a reboot. If a particular patch does break an application, it could be for a variety of reasons, ranging from poorly written software to out-dated standards that fall out of support in the newer software versions you are installing. You should definitely do the following...

Even if there are 25 or 50 patches needed, be informed of whats being done to your machine. Focus on your machines core services, and understand how they may be affected by the new patches. Coordinate the change with those involved with the system youre patching. Check your backups and make sure they are available. Make sure you have the right resources available in case you need help. Test the patches on non-critical machines, especially if theyre similar to the production boxes youre scheduled to patch. Reboot the machine, if possible, since startup processes may have changed during the update. Finally, confirm that everything works the way it should after youre done. When I used to install car alarms long ago, most of our customers at the alarm shop werent there because they were being proactive. They were there at the shop because they were the victims of an intrusion and decided to get an alarm after the fact. The same goes with keeping your machines patched and well protected. From a security standpoint, patching is a basic procedure that can keep your machines safe, even if you think youre in the safest network around. Just remember, though, that even as no process is perfect, no network is perfect either. If someone should get past your firewalls, intrusion detection systems and the DMZ, at least you know that youve done your job and added an extra line of defense for your Linux machines.

REFERENCES: [1] Wikipedia {www.wikipedia.org] [2]Linux [www.linux.com] [3] Red hat [www.redhat.com] [4] http://www.anomaly.org/wade/linux.html [5] http://lxr.free-electrons.com/ [6] http://kernelbook.sourceforge.net/ [7] Ubuntu Pocket Guide and Reference by Keir Thomas [8] Understanding the Linux Kernel, by Daniel Bovet and Marco Cesati